Ask developers.org.ua: Alternatives to CORBA?
motusОпубликовано 2.03.2007 в Разработка
Господа программисты,
прежде всего: не знаю, как вам, а мне посты про бизнес и производительность труда уже порядком поднадоели. такое впечатление, что кода тут никто не пишет вообще. 
посему призываю всех, кому есть что сказать по делу, написать по коротенькой заметке о каком-нибудь своем хаке, об интересном разделе из теории или просто о любимом языке или технологии.
для затравки - расскажите, кто что пользует для IPC между процессами на нескольких хостах? меня лично интересует поддержка в С++ и как минимум еще в каком-то скриптовом языке, но интересно услышать вообще чем народ пользуется и какие впечатления?
на прошлой работе мы активно (и, как я понимаю сейчас, довольно успешно) использовали CORBA - прежде всего в Java и C++, но из Python-а тоже неплохо получалось. я и сейчас, в принципе, рекомендовал бы корбу - технология это достаточно зрелая, а недостатков хотя и немало, но все они давно известны и вероятность новых граблей очень мала.
мое резюме по корбе примерно такое:
плюсы:
- масса отличных реализаций, как коммерческих, так и FOSS, практически под любую ОС, и варианты для embedded/legacy/real-time и пр платформ;
- масса подробной документации и отличные книги;
- наличие стардартов и реализаций практически для любого языка, как-то Java, C++, plain C, Python, Common Lisp, Erlang, etc.
- необходимость задания интерфейсов в IDL очень стимулирует грамотное разделение бизнес-логики на компоненты - часто какой-то сервис быстро лепится, например, на питоне, а потом, в случае необходимости, переписывается на С++. более того, очень часто оказывается, что корбу можно использовать просто для связывания разных языков, как, например, SWIG.
- в целом, технология более чем зрелая, и все горбы давно и неоднократно обсуждены и известны, так что риск наступить на какие-то неведомые доселе грабли очень невелик.
недостатки:
минусов, конечно, тоже хватает. по этому поводу написано много статей (интересно, кстати, почитать и ответы). ниже я перечислю те вещи, которые не нравятся в корбе мне лично.
- неважный маппинг в С++: стандарт был выпущен в доSTL-ную эпоху, поэтому приходится иметь дело с объектами типа CORBA::String, странноватыми подобиями вектора, в которые мапятся CORBA sequence, и подходом к управлению памятью a-la std::auto_ptr. все это не так страшно, и в принципе вполне можно использовать, например, STL algorithms с корбовыми последовательностями, но все равно, хотелось бы лучшего (PS: замечу, что с маппингом в Java и Python все гораздо ровнее).
- проблемы со связью через файрволы - опять же, все это решается, и в составе практически каждой реализации корбы есть свой кобовый шлюз, но все равно, корбу гораздо чаще используют для связи компонентов на middle tier, а не как открытый API для внешних приложений - несмотря на то, что задумывалась корба именно для последнего
я по поводу этих недостатков особо никогда не переживал, но тем не менее - корба развивается уже лет 10, и пора бы появиться технологиям посвежее? какие я знаю альтернативы:
- прежде всего: ICE. это прямой конкурент корбы, от корбового гуру Michi Henning-a. как по мне, от корбы ICE практически не отличается, вот только маппинг с С++ сделан получше. а так - та же корба, вид сбоку
- более заточенные на Java, но вроде как с маппингом в другие языки тоже - Hessian (бинарный) и Burlap (XML-based). тут я зню очень мало, так что поделитесь опытом, кто может.
- D-Bus - кто знает, как у него с коннектом между хостами? под большой нагрузкой кто-то его пробовал?
- ну, enterprisey варианты типа DCOM, EJB, SOAP мы рассматривать не будем
поделитесь опытом?
C++, CORBA, Java, альтернатива
(Еще не оценили)
Загрузка ...Понравилась статья? Подпишись на обновления по RSS/E-mail
Мне интересно.
А вот это действительно так! Согласен, надо это дело исправлять.
Я могу писать только про питон — не думаю что это многим интересно. Поэтому кручусь как могу.
Я могу писать только РНР и плюс какие-то общие вещи типа производительности труда итд
Я использую dbus, точнее его реализацию в QT - qdbus.
Под виндой есть win32dbus, пока проблем не возникало - отлично дружат.
Если мне кто-то красиво/умно расскажет про питон, я с удовольствием потрачу время на дальнейшее изучение, а так даже и не знаю, как взяться… Так что было бы здорово обзорную статью, что он умеет и чем хорош (чисто субъективно).
А PHP - это ж наше всё!
сорри господа, вчера завалился спать и вместо того, чтобы сохранить текст, опубликовал незаконченную статью
сорри. а теперь еще оказалось, что WordPress все мои линки поел - ща снова буду расставлять :-\
>ну, enterprisey варианты типа DCOM, EJB, SOAP мы рассматривать не будем
Вообще-то EJB общается как раз через CORBA
А при чем тут SOAP конкретно к enterprise-приложениям? Он и для других целей используется, но медленный сильно, потому что XML и.т.д.
Лично я буду против если dou превратится в “еще-один-сайт-про-программирование” - их же сотни как здесь так и на западе. С узкими вещами - лучше туда, там народ поймет вас лучше. Код мы и так пишем каждый день, зачем тут дублироваться, а вот вопросы, общие для нас, программистов, не так часто обсуждаются. Обзорные статьи по новым (и старым) - это дело, а детали - в топку, или сделать подразделы для узкоспециализированных обсуждений. Иначе один-два человека “в теме”, остальные … идут читать другие сайты
Думаю это не гут.
Макс Ищенко:
почему же - мне интересно. вот расскажи как ты несколько питоновских процессов на разных хостах связываешь? я вот пробовал omniORB - получается неплохо, могу поделиться опытом если кому интересно. а может есть какие-то более pythonic варианты?
Mr.K:
EJB использует IIOP, т.е. корбовый протокол, а это только подмножество корбы. есть спецификация на то, как связывать корбовые сервисы и EJB, и оно даже работает, но на практике писать всю эту обвязку очень геморройно - проще похерить EJB и использовать корбу с двух сторон.
а что, кто-то еще использует SOAP по своей воле?
divan:
а на нескольких хостах это работает? как насчет коннекта на разных платформах - 32 vs 64 bit, big/little endian?
2 roddy
Вряд ли крайности будут иметь место, но немного технических деталей на фоне общего обсуждения чисто украино-девелоперских проблем, имхо, не помешают.
Если тут:
http://www.developers.org.ua/ua-dev-network/
сделают ленту постов, то, возможно кол-во технической информации увеличится
+1
Идея мне кажется здравая - одновременно получим разнообразие тем на сайте и не раздуем центральный блог.
Никак. Последнее время такие задачи не попадаются.
Вообще, я стал боольшим поклонником HTTP, даже для не-веб разработок в т.ч. корпоративных. Тут тебе и либы для любых платформ языков и простота и инструменты отладки (включая curl и IE) и т.д и т.п.
Так что я бы в первую очередь взял именно его, хотя, конечно, требования бывают разные.
Вот, кстати, в тему: http://code.google.com/p/msgbus/
Ok, если Python, то, конечно же, Spread (http://twistedmatrix.com/projects/core/documentation/howto/pb.html) из популярной “команды” Twisted.
ICE - это GPL. hessian/burlap - это, те же веб-сервисы, но для тех мест где траффик нужно экономить.
Хороший вариант - JMS. Например http://activemq.apache.org/ Клиенты есть практически под что угодно. Что касается python, то кроме stomp-клиента есть http://code.google.com/p/pyactivemq/ т.е. когда в cpp-клиенте появится поддержка openwire, это можно будет использовать и из python…
Думаю, что иделогия веб-сервисов с бинарным XML будет прекрасной альтернативой.