Тут несколько раз поднимался вопрос о возможности и оправданности написания бизнес-логики на функциональных языках. Так что могу внести свою лепту в оное обсуждение. Распределенная система на Ерланге / Тикле, кою мы ваяли последние 1.5 года, начала продаваться. Пока только избранным покупателям, ибо еще есть разного рода сырости, но в течении месяца мы ее, полагаю, высушим.
Кратко о самой системе : ядро системы + логическая обвязка ( бизнес-правила ). Сам движок остается неизменным для всех областей применения, меняется только обвязка. Нынешняя обвязка предназначена для использования в паспортных столах любых муниципальных образований.
Пока что параметры системы таковы :
Сервер :
— чистый ерланг и Мнезия
— около 5К строк серверного кода ( движок правил, прокси и т.д ). Сгенерированный код для парсеров / лексеров правил сюда, понятно, не включается.
— около 10К строк бизнес-логики
— работает с очень даже приемлемой скоростью на гниловатом железе ( Целерон-3, 800 мгц)
Клиент :
— Тикль + чуть-чуть С++
— около 8К строк занимает фреймворк собственной выделки
— около 26К строк — формочки и бизнес-логика
— около 800 строк на С++ ( BOOST )
— может работать на Пне-2
Системы с меньшей функциональностью на жабе ( по оценкам изготовителей
этих систем ) занимают свыше 600 К строк. Сейчас с ними связался — говорят, что по функциональности сравнялись, но обьем кода вырос до 1200 К строк.
Здравствуйте, gandalfgrey, Вы писали:
[cut] G> ВотЬ !
А можно какие-нибудь комментарии по поводу того — что понравилось в эрланге, на какие грабли наступали. Что использовали кроме мнезии, скажем eUnit пользовали?
Re: Бизнес-логика на Erlangе
От:
Аноним
Дата:
11.05.07 08:38
Оценка:
Здравствуйте, gandalfgrey, Вы писали: G> Клиент :
простите за глупый вопрос, а как делали связку между тиклевским клиентом и сервером? через сокеты?
Здравствуйте, Курилка, Вы писали:
К>А можно какие-нибудь комментарии по поводу того — что понравилось в эрланге, на какие грабли наступали. Что использовали кроме мнезии, скажем eUnit пользовали?
Ежели говорить о внешних библиотеках, то ничего, кроме leex, не использовали. Это генератор лексеров, и очень удобный. Все остальные потребности с лихвой перекрывались самой OTP. Когда-то мы использовали SOAP и, соответственно, XML — но и это все в стандартной поставке присутствует.
Что понравилось в Ерланге :
— изоляция процессов ( и захочешь, а не нагадишь )
— принцип "let it crash" ( пусть процесс помрет от несварения данных, а мы это обработаем )
— ОЧЕНЬ удобная работа с паттерн-матчингом
— сообщения ! что, в принципе, лежит рядом с изоляцией
— полиморфизм по произвольным паттернам ( функции с одним именем могут принимать и строку, и число, и тупль... но это будут разные функции )
— динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
Что НЕ понравилось :
— не возможности автоматически заставить кодописателя производить генерализацию и обобщения функций. У нас в системе сейчас поддержано около 90 типов запросов, и во многих случаях на каждый из них написана функция из 10-15 строк, которая почти не отличается от других таких же. Но это, конечно, проблема не конкретно Ерланга — он всего лишь способствует этому из-за краткости кода.
Были непонятки с Мнезией, но это было уже давно...
Здравствуйте, Аноним, Вы писали:
А>простите за глупый вопрос, а как делали связку между тиклевским клиентом и сервером? через сокеты?
Разумеется ! Система распределенная, части ее разбросаны по разным узлам, так что ничего, кроме TCP/IP, через сеть не пролезет
На тиклевой стороне использовалась сишная либа EI, которая идет вместе с OTP, и маленький переходник на плоском С в тикль. Он тоже не ручками был писан ( не весь ), а сгенерен при помощи приблуды CRITCL — она позволяет писать С код прямо внутри тикля, создает необходимые стабы и т.д.
G> Ежели говорить о внешних библиотеках, то ничего, кроме leex, не использовали. Это генератор лексеров, и очень удобный. Все остальные потребности с лихвой перекрывались самой OTP. Когда-то мы использовали SOAP и, соответственно, XML — но и это все в стандартной поставке присутствует.
эээ, xmerl знаю, а SOAP откуда в OTP появился — просвети, плизз
Кстати Ульф (вроде или Тоббе) говорил, что xmerl далеко не лучший парсер, у себя там они свой парсер юзают, правда публично он не доступен.
G> — не возможности автоматически заставить кодописателя производить генерализацию и обобщения функций. У нас в системе сейчас поддержано около 90 типов запросов, и во многих случаях на каждый из них написана функция из 10-15 строк, которая почти не отличается от других таких же. Но это, конечно,
проблема не конкретно Ерланга — он всего лишь способствует этому из-за краткости кода.
А можешь на словах пояснить, в чём суть? Почему нельзя было обобщённые функции сделать?
Здравствуйте, Курилка, Вы писали:
К>эээ, xmerl знаю, а SOAP откуда в OTP появился — просвети, плизз
Ну, XML-RPC — но это же ничем от SOAPа не отличается К>Кстати Ульф (вроде или Тоббе) говорил, что xmerl далеко не лучший парсер, у себя там они свой парсер юзают, правда публично он не доступен.
А сейчас нам это не актуально — с сервера уходит стандартное сообщение, и приходит такое же. XML все ж какой-то замороченный, да и тормознутый ( особенно на клиенте ). Отказались мы от него, и не жалеем
К>А можешь на словах пояснить, в чём суть? Почему нельзя было обобщённые функции сделать?
Можно ! Но когда функцию быстрее и проще написать по-новой, не очень хочется раздумывать над обобщениями. Это чисто психологическая проблема
Здравствуйте, gandalfgrey, Вы писали:
G>А сейчас нам это не актуально — с сервера уходит стандартное сообщение, и приходит такое же. XML все ж какой-то замороченный, да и тормознутый ( особенно на клиенте ). Отказались мы от него, и не жалеем
А что ходит тогда у вас? Обычные эрланговые сообщения? Для чего вы соап-то использовали?
Здравствуйте, Курилка, Вы писали:
К>А что ходит тогда у вас? Обычные эрланговые сообщения? Для чего вы соап-то использовали?
СОАП мы использовали раньше. И это было так замороченно, что просто беда ( особенно на клиенте ).
То-есть мы засовывали данные в XML и отдавали их клиенту — или наоборот.
Сейчас ничего этого нет. Просто сообщения. Мы получили выигрыш еще и со стороны уменьшения трафика на гнилых соединениях, типа модема. Соответственно, большая экономия времени передачи данных.
Здравствуйте, gandalfgrey, Вы писали:
G> Приветствую всех !
G> Тут несколько раз поднимался вопрос о возможности и оправданности написания бизнес-логики на функциональных языках. Так что могу внести свою лепту в оное обсуждение. Распределенная система на Ерланге / Тикле, кою мы ваяли последние 1.5 года, начала продаваться. Пока только избранным покупателям, ибо еще есть разного рода сырости, но в течении месяца мы ее, полагаю, высушим. G> Кратко о самой системе : ядро системы + логическая обвязка ( бизнес-правила ). Сам движок остается неизменным для всех областей применения, меняется только обвязка. Нынешняя обвязка предназначена для использования в паспортных столах любых муниципальных образований.
Не порадуешь дизайн-документом, описывающим общую архитектуру?
Здравствуйте, gandalfgrey, Вы писали:
G>СОАП мы использовали раньше. И это было так замороченно, что просто беда ( особенно на клиенте ). G>То-есть мы засовывали данные в XML и отдавали их клиенту — или наоборот. G>Сейчас ничего этого нет. Просто сообщения. Мы получили выигрыш еще и со стороны уменьшения трафика на гнилых соединениях, типа модема. Соответственно, большая экономия времени передачи данных.
Дак если у вас всё "родное" и на Эрланге, то резона соап юзать я не вижу, только если красивые плакатики с буковками SOA рисовать
Вот если бы были внешние системы, то уже можно было бы подумать, хотя тоже SOAP имхо только для "дырки наружу" использовать смысл имеет.
Здравствуйте, Gaperton, Вы писали:
G>Не порадуешь дизайн-документом, описывающим общую архитектуру?
Вот бы он еще был, этот документ, в собранном виде.... Сейчас архитектура описывается кучей бумажек, каждая из которых состоит из призывов, лозунгов и запретов, и в целом похожа на речи Геббельса. Типа, "Вы сами хотели тотальной войны !" (с)
То-есть везде разбросаны мааааленькие кусочки того, как надо делать, как не надо делать, и какие принципы должны соблюдаться. Например, правила обработки ошибок для бизнес-логики :
— ежели набор входных данных формально правилен, но не соотвествует реально хранимым данным, то это обрабатывает бизнес-логика
— во всех остальных случаях запрос от клиента ДОЛЖЕН скончаться в муках, а клиентская прокся это обработает сама
Или отложенная обработка правил в соответствии с моделью :
— с каждой итерацией множество отложенных правил сужается
— не обрабатывать это специальным образом, ибо если это не так, то это ошибка предметной модели, и сервер все равно сделает лог все этого при издыхании соединения с клиентом
Собрать все в одну кучку надо....но ручонки не доходят совершенно
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>Не порадуешь дизайн-документом, описывающим общую архитектуру? G>Вот бы он еще был, этот документ, в собранном виде.... Сейчас архитектура описывается кучей бумажек, каждая из которых состоит из призывов, лозунгов и запретов, и в целом похожа на речи Геббельса. Типа, "Вы сами хотели тотальной войны !" (с) G>То-есть везде разбросаны мааааленькие кусочки того, как надо делать, как не надо делать, и какие принципы должны соблюдаться. Например, правила обработки ошибок для бизнес-логики : G> — ежели набор входных данных формально правилен, но не соотвествует реально хранимым данным, то это обрабатывает бизнес-логика G> — во всех остальных случаях запрос от клиента ДОЛЖЕН скончаться в муках, а клиентская прокся это обработает сама
G>Или отложенная обработка правил в соответствии с моделью : G> — с каждой итерацией множество отложенных правил сужается G> — не обрабатывать это специальным образом, ибо если это не так, то это ошибка предметной модели, и сервер все равно сделает лог все этого при издыхании соединения с клиентом
G>Собрать все в одну кучку надо....но ручонки не доходят совершенно
Да лана. Просто схему процессов, и отметить отношения между ними — кто кого супервайзит, кто — листенит, кто кому мессаги шлет. Нотация UML для диаграммы классов подойдет, ассоциации подписываем стереотипами.
Здравствуйте, Gaperton, Вы писали:
G>Не порадуешь дизайн-документом, описывающим общую архитектуру?
Вдогонку о том, что у нас есть :
1. Движок правил. Компилирует скрипты описания взаимосвязей между типами обьектов и пропертями в соответствующие им лямбды
2. Движок запросов. Компилирует структуру запросов ( они описаны во внешних файлах и часто меняются ) опять-таки в лямбды, которые разбирают запрос и вычерпывают все необходимые для него данные
3. Динамическое создание функций для работы с базой, отталкиваясь от актуальной структуры базы
4. Прокся клиентов и прокся запросов. Когда что-то падает, остальное продолжает работать. И когда у нас появляется 2 камня, параллельная работа разных клиентов ускоряется в 2 раза. Или выполнение параллельных запросов от одного клиента
5. Непрерывное соединение по TCP/IP без поддержания контекста предыдущей сессии. Думали, чесали репу, постановили — предыдущую сессию не восстанавливать
6. Движок основных скриптов обработки — задействован в малой степени. Будем переделывать сам язык скриптов, ибо синтаксис оказался неудобоваримым для продАвцев, они же установщики
Все времяемкие операции сервер делает при старте / рестарте, а потом пользуется плодами оного, обычно в виде лямбд.
Клиентам мы поставляем сервер в виде системного сервиса, дабы не прибили его случайно умные админы
Здравствуйте, Курилка, Вы писали:
К>Дак если у вас всё "родное" и на Эрланге, то резона соап юзать я не вижу, только если красивые плакатики с буковками SOA рисовать К>Вот если бы были внешние системы, то уже можно было бы подумать, хотя тоже SOAP имхо только для "дырки наружу" использовать смысл имеет.
Дык ить ! Сейчас у нас СОАП и не используется. Для внешних систем есть Сишная либа, которая реализует ерланговский протокол.
Или речь о том, почему СОАП вообще стали приделывать ?
Здравствуйте, gandalfgrey, Вы писали:
G>Дык ить ! Сейчас у нас СОАП и не используется. Для внешних систем есть Сишная либа, которая реализует ерланговский протокол.
А если внешняя система на Java? Есть, конечно, jinterface, да и слишком теоретически, нет потребности — нет задачи
G>Или речь о том, почему СОАП вообще стали приделывать ?
Ну вообще это были просто "мысли вслух"
Но, если не секрет, то интересно и почему вообще
Здравствуйте, Курилка, Вы писали:
К>Ну вообще это были просто "мысли вслух" К>Но, если не секрет, то интересно и почему вообще
Исключительно из соображений моды ! Ну и хотелось поначалу, чтобы все ж по какому-то стандартному протоколу шел обмен — это чтоб могли внешние системы подключаться. Но потом решили, что когда необходимость в этом ДЕЙСТВИТЕЛЬНО возникнет, приделаем уж что-нибудь
