Ask developers.org.ua: Alternatives to CORBA?

Господа программисты,

прежде всего: не знаю, как вам, а мне посты про бизнес и производительность труда уже порядком поднадоели. такое впечатление, что кода тут никто не пишет вообще. :-) посему призываю всех, кому есть что сказать по делу, написать по коротенькой заметке о каком-нибудь своем хаке, об интересном разделе из теории или просто о любимом языке или технологии.

для затравки — расскажите, кто что пользует для 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 мы рассматривать не будем :-)

поделитесь опытом?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


16 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Думаю, что иделогия веб-сервисов с бинарным XML будет прекрасной альтернативой.

ICE — это GPL. hessian/burlap — это, те же веб-сервисы, но для тех мест где траффик нужно экономить.Хороший вариант — JMS. Например http://activemq.apache.org/ Клиенты есть практически под что угодно. Что касается python, то кроме stomp-клиента есть http://code.google.com/p/pyact.../ т.е. когда в cpp-клиенте появится поддержка openwire, это можно будет использовать и из python...

Ok, если Python, то, конечно же, Spread (http://twistedmatrix.com/proje...) из популярной “команды” Twisted.

вот расскажи как ты несколько питоновских процессов на разных хостах связываешь?

Никак. Последнее время такие задачи не попадаются.;) Вообще, я стал боольшим поклонником HTTP, даже для не-веб разработок в т.ч. корпоративных. Тут тебе и либы для любых платформ языков и простота и инструменты отладки (включая curl и IE) и т.д и т.п. Так что я бы в первую очередь взял именно его, хотя, конечно, требования бывают разные.

+1 Идея мне кажется здравая — одновременно получим разнообразие тем на сайте и не раздуем центральный блог.

Если тут: http://www.developers.org.ua/u.../сделают ленту постов, то, возможно кол-во технической информации увеличится

2 roddyВряд ли крайности будут иметь место, но немного технических деталей на фоне общего обсуждения чисто украино-девелоперских проблем, имхо, не помешают.

Макс Ищенко:

Я могу писать только про питон — не думаю что это многим интересно.

почему же — мне интересно. вот расскажи как ты несколько питоновских процессов на разных хостах связываешь? я вот пробовал omniORB — получается неплохо, могу поделиться опытом если кому интересно., а может есть какие-то более pythonic варианты? Mr.K:

Вообще-то EJB общается как раз через CORBA

EJB использует IIOP, т.е. корбовый протокол, а это только подмножество корбы. есть спецификация на то, как связывать корбовые сервисы и EJB, и оно даже работает, но на практике писать всю эту обвязку очень геморройно — проще похерить EJB и использовать корбу с двух сторон.

А при чем тут SOAP конкретно к enterprise-приложениям?

а что, кто-то еще использует SOAP по своей воле?: -) divan:

Я использую dbus, точнее его реализацию в QT — qdbus.

а на нескольких хостах это работает? как насчет коннекта на разных платформах — 32 vs 64 bit, big/little endian?

Лично я буду против если dou превратится в «еще-один-сайт-про-программирование» — их же сотни как здесь так и на западе. С узкими вещами — лучше туда, там народ поймет вас лучше. Код мы и так пишем каждый день, зачем тут дублироваться, а вот вопросы, общие для нас, программистов, не так часто обсуждаются. Обзорные статьи по новым (и старым) — это дело, а детали — в топку, или сделать подразделы для узкоспециализированных обсуждений. Иначе один-два человека «в теме», остальные... идут читать другие сайты;) Думаю это не гут.

> ну, enterprisey варианты типа DCOM, EJB, SOAP мы рассматривать не будем Вообще-то EJB общается как раз через CORBA:) А при чем тут SOAP конкретно к enterprise-приложениям? Он и для других целей используется, но медленный сильно, потому что XML и.т.д.

сорри господа, вчера завалился спать и вместо того, чтобы сохранить текст, опубликовал незаконченную статью: -) сорри., а теперь еще оказалось, что WordPress все мои линки поел — ща снова буду расставлять: -\

Если мне кто-то красиво/умно расскажет про питон, я с удовольствием потрачу время на дальнейшее изучение, а так даже и не знаю, как взяться... Так что было бы здорово обзорную статью, что он умеет и чем хорош (чисто субъективно).А PHP — это ж наше всё!

Я могу писать только РНР и плюс какие-то общие вещи типа производительности труда итд

Я могу писать только про питон — не думаю что это многим интересно. Поэтому кручусь как могу.:)

не знаю, как вам, а мне посты про бизнес и производительность труда уже порядком поднадоели.

Мне интересно.

такое впечатление, что кода тут никто не пишет вообще.

А вот это действительно так! Согласен, надо это дело исправлять.

Подписаться на комментарии