Thrift - библиотека для кросс-языкового взаимодействия через сеть

>Народ, а кто-то пользуется КОРБОй? Смысл есть?

Я пользуюсь Корбой. мне нравиться. для С++ TAO, для java пока стандартной хватает.

на мой взгляд удобно, клёво.

и честно не знаю чем Thrift лучше. глянул его аналог IDL по моему замороченней чем в Кобре

> ... а биндинги разрабатывались для компиляторов 15-летней давности. В общем, критика от ZeroC вполне справедлива.

ну не знаю. у меня tao_idl с gcc 4.1 и vc2005 хорошо дружит :-)

> ну не знаю.

теперь - знаешь

> у меня tao_idl с gcc 4.1 и vc2005 хорошо дружит :-)

Современные компиляторы умеют всё, что умели компиляторы 15-летней давности. Сюрприз? Но они умеют и еще много чего...

>ну не знаю. у меня tao_idl с gcc 4.1 и vc2005 хорошо дружит :-)

TAO единственные для С++ по сути кто даёт более-менее рабочий вариант CORBA, да еще и с фишками CORBA 3. Только вот придёшь ты с ним к другим разработчикам/компаниям работать - а там XML/SOAP/WSDL или еще хуже HTTP/XML. Иногда бывает и EJB, но проблем по работе с ним из чистого CORBA тоже довольно много. Были правда спецификации от OMG по interoperability CORBA to SOAP, но не уверен, что их кто-то реализовал как и множество других спецификаций от OMG (чего только стоит CCM с Persistence Service).

> у меня tao_idl с gcc 4.1 и vc2005 хорошо дружит :-)

Да еще и с качеством продукта TAO/ACE ты наверное знаком уже, раз используешь?

> Даже сраненький python - и тот поддержали! А Си-шарпа нету... это позорище, господа! Типичная линуксовая поделка. Можете о ней сразу забыть.

Да кому нахер этот Си-шарп нужен? Для облучёных M$-лучами? Куча народу на замечательном Питоне пишет.

> а кто знает аналоги данной штуки для питона, дабы выбрать лучшее. если быстрее соапа это хорошо.

для передачи данных - JSON

>Зная внутренности CORBA, SOAP, RPC и т.д. могу сказать, что ничего лучше CORBA никто еще не придумал, так как лучшие умы планеты думали и думают над спецификацией CORBA.

CORBA, как совершенно справедливо заметил Мичи Хеннинг (http://www.zeroc.com/riseAndFallOfCorba.html) - это геморр из геморров, особенно С++ биндинг. с этим однако можно было бы мирится (например на жаба все делается довольно просто), если бы небыло пары ужасных дырищь - 1)отсутствие какой либо секьюрити 2)абсолютная непроходимость через nat-ed firewalls. эти вещи похоронили CORBA.

> TAO единственные для С++ по сути кто даёт более-менее рабочий вариант CORBA

а что не так с omniORB?

>CORBA, как совершенно справедливо заметил Мичи Хеннинг (http://www.zeroc.com/riseAndFallOfCorba.html) - это геморр из геморров, особенно С++ биндинг. с этим однако можно было бы мирится (например на жаба все делается довольно просто),

C++ биндинг конечно не подарок, но был вполне неплохой для тех времён. Регламентация наименований и т.д конечно не всем нравилась, но все же. Да и где она была хороша скажите мне? COM/DCOM?

>если бы небыло пары ужасных дырищь - 1)отсутствие какой либо секьюрити 2)абсолютная непроходимость через nat-ed firewalls. эти вещи похоронили CORBA.

Security - тут что имеется ввиду? SSL был, CORBA Security Service был, реализаций нормальных не было - вот в чём проблема.

Насчет NAT/proxy - тут знакомая критика маркетологов. HTTP тут рекламируется? Когда последний раз в intranet пользовались NAT? Firewall и правда бывает, но все равно его подстраивают админы для каждого приложения, потому как ему все равно еще в БД ходить надо и т.д. Единственный плюс для прокола HTTP - Internet-сеть для неторопливых сервисов.

>а что не так с omniORB?

Он жив еще? Я давно его не встречал. Когда я его смотрел в последний раз, умел он мало чего. CORBA 3 (AMI, CCM), наверное, не поддерживает еще?

а что с качеством-то? качество вполне.

если не собирать под винду, то даже очень быстро собирается. на ноутбуке :-).

вот качество vs2005 (не по теме конечно), оставляет желать лучшего.

>> а что не так с omniORB?

> Он жив еще?

Вполне

> CORBA 3 (AMI, CCM), наверное, не поддерживает еще?

ХЗ. Мне это всё не нужно было. С меня хватило бы и возможностей сабжа :)

>а что с качеством-то? качество вполне. если не собирать под винду, то даже очень быстро собирается. на ноутбуке :-). вот качество vs2005 (не по теме конечно), оставляет желать лучшего.

Не знаю, мы встречали очень много багов и недоделок и под Solaris и под Win32. Есть еще кстати MICO, он даже CCM вроде умеет.

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

>ХЗ. Мне это всё не нужно было. С меня хватило бы и возможностей сабжа :)

Тебе никогда не было нужно вызвать метод асинхронно (AMI) ? :-)

> распространенность CORBA падает даже в довольно консервативном сегменте - телекоме.

И чем его заменяют - SOAP'ом?

>ХЗ. Мне это всё не нужно было. С меня хватило бы и возможностей сабжа :)

я не понял только, чем сабж так хорош? винду не поддерживает (может на цыгвине будет собирается когда туда 4gcc прикрутят, судя по требованиям)

кстати, кто качал сколько весит?

> Тебе никогда не было нужно вызвать метод асинхронно

Нет. Зачем? Есть EventService, в конце концов.

>мы встречали очень много багов и недоделок и под Solaris и под Win32

Соляру не юзал, под виндой были как-то баги с цыгвином, но прошли.

>Есть еще кстати MICO, он даже CCM вроде умеет.

mico - рип. там в последней версии много старого кода который не собирается.

>Регламентация наименований и т.д конечно не всем нравилась, но все же.

наименования - это наименьшее из зол. черезжопное управление памятью (куча правил на тему кто и что аллокирует и кто и что чистит) и полное игнорирование стандартных С++ контейнеров (нахрена например иметь кучу правил о том, как и когда аллокировать, деаллокировать, передавать в методы и возвращать из методов элементарную строку, когда можно использовать std::string и избавть напрочь программиста от всякого геморра с низкоуровневым управлением памятью? почему sequence<Type>-ы не мапить на std::vector<Type> и не трахаться низкоуровневым управлением памятью? и т.п. и т.д.). да что там говорить - попользуйтесь ICE и ощутите разницу.

>Security - тут что имеется ввиду? SSL был, CORBA Security Service был, реализаций нормальных не было - вот в чём проблема.

только ssl и есть. не видел ни одного ORB где бы CORBA Security Service был реализован. а что если нет возможности туннелить через SSL? это значит приплыли. зная адрес вашего апп.сервера любой продвинутый может сделать все что захочет - подключиться и манипулировать вашими объектами - ибо нет в CORBA такой стандартной фичи как авторизация. (единственный способ [скорее хак] - через интерсепторы вставлять и отлавливать некие токены непосредственно в/из протокол/а)

>HTTP тут рекламируется?

нет. SOAP - и не рекламирую - самому не нравится.

>> распространенность CORBA падает даже в довольно консервативном сегменте - телекоме.

>И чем его заменяют - SOAP'ом?

D-Bus'ом :)))

>Он жив еще?

жив. один из самых быстрых ORB.

>CORBA 3 (AMI, CCM), наверное, не поддерживает еще?

нет. он и OBV c portable interceptors не потдерживает.

>распространенность CORBA падает даже в довольно консервативном сегменте - телекоме.

х.з. по крайней мере до недавнего времени - это была одна из ниш где она безраздельно царствовала.

>а что с качеством-то? качество вполне.

месиво из макросов слегка разбавленное кодом на c и С++.

>И чем его заменяют - SOAP'ом?

Полный разброд: от custom-протоколов на базе кодирования BER, до SOAP (например, в последнее время популярен в Parlay Group, которые на конференции в private-беседе сказали, что хотят оставить CORBA).

>Нет. Зачем? Есть EventService, в конце концов.

Ну так все и делали, т.к. реализация CORBA 3 до сих пор нигде в полном объеме не присутствует. Правда сейчас используется Notification Service (новая спека).

Даже и не знаю, что больший ужоснах :/

Но на ICE не переходят?

> наименования - это наименьшее из зол. черезжопное управление памятью (куча правил на тему кто и что аллокирует и кто и что чистит)

Управление памятью необходимо было регламентировать, иначе был бы такой сброд да и всё равно было большое пространство для действий.

>и полное игнорирование стандартных С++ контейнеров (нахрена например иметь кучу правил о том, как и когда аллокировать, деаллокировать, передавать в методы и возвращать из методов элементарную строку, когда можно использовать std::string и избавть напрочь программиста от всякого геморра с низкоуровневым управлением памятью? почему sequence<Type>-ы не мапить на std::vector<Type> и не трахаться низкоуровневым управлением памятью? и т.п. и т.д.). да что там говорить - попользуйтесь ICE и ощутите разницу.

Согласен!! Тремя руками - меня тоже всегда бесит, что STL не использовался, но так получилось больше исторически (посмотрите на дату первой спеки), а обновлять спецификацию по С++ никто впоследствии не стал. Это сейчас за реализацию STL можно более-менее не беспокоиться, а в те времена такой был разрброд.

>х.з. по крайней мере до недавнего времени - это была одна из ниш где она безраздельно царствовала.

Царствует там больше ITU-T со спеками на базе ASN.1 деклараций :) Но деклалировался всегда светлый путь к CORBA. Теперь вот больше в IT (SOAP).

>Но на ICE не переходят?

Нет - не встречал нигде. Иногда знакомые из Европы что-то бурчат про ActiveMQ, да собственно и всё. Еще в данный момент есть 2 спецификации от ITU-T: FastWS (бинарное-кодирование (PER) SOAP/WSDL) и недавно появилась Fast-InfoSet (обе пришли из IT), на которые ведётся телеком. Также основа сети 3G - SIP.

Все там собирается.

>месиво из макросов слегка разбавленное кодом на c и С++.

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

и т.д.

> Все там собирается.

не знаю. половина там примеров на BOA, который выкинули.

и, кстати там проблемы c IIOP были с другими CORBA.

j2se, omniORB, TAO, ORBit нирмально дружили,

а mico в одну сторону (не помню точно, кажеться mico клиенты с другими нормально работати, а вдругую сторону нет, или наоборот)

>Также основа сети 3G - SIP.

А он-то тут каким боком? Это-ж не RPC протокол.

>А он-то тут каким боком? Это-ж не RPC протокол.

Не RPC конечно, но общение осуществлять им тоже ведь можно (к сожалению) :)

>но общение осуществлять им тоже ведь можно (к сожалению)

Почему к сожалению? Какие есть открытые альтернативы? (H.323 не предлагать)

>Почему к сожалению? Какие есть открытые альтернативы? (H.323 не предлагать)

Да нет их в данный момент. Провозглашен путь к SIP (то бишь к текстовому протоколу). Выбирать не приходится. Партия так решила (ETSI/3GPP).

>Провозглашен путь к SIP (то бишь к текстовому протоколу)

Ну, это не так страшно. Ибо SIP - это не RPC и нагрузка по количеству передаваемых данных небольшая. Единственно, что для работы требуется текстовый парсер в SIP стэке, а это чревато боком, как говорится.

>для передачи данных - JSON

это и есть реализация соапа, поправьте если не прав.

> а кто знает аналоги данной штуки для питона, дабы выбрать лучшее. если быстрее соапа это хорошо.

xml-prc подходит ?

> для передачи данных - JSON

именно. А язык будущего - потомок Javascript (&|) Lisp. Всё остальное отомрет.

> это и есть реализация соапа, поправьте если не прав.

никаким боком. Примеры: SOAP: http://en.wikipedia.org/wiki/SOAP#Example JSON: http://en.wikipedia.org/wiki/JSON#Supported_data_types.2C_syntax_and_example

>> для передачи данных - JSON

> это и есть реализация соапа, поправьте если не прав.

Отличная штука. Ты не прав, это даже не XML. Поддержтвается куча языков. В Python и JavaScript можно даже напрямую парсить eval-ом (не рекомендуется). http://json.org/

Я использую JSON. В Python подключаю для этого модуль simplejson, в JavaScript тоже один маленький скриптик с официального сайта. Это не обязательно, но так надёжней, чтобы eval не хакнули и стандарты лучше поддерживались. Proxy, NAT, HTTPS... пашет через всё, т.к. обычно через HTTP работает, но я и через сокеты его успешно гоняю. AJAX пашет в браузере с JSON на отлично. Больше мне ничего для передачи данных не нужно. Читать сообщения можно невооружённым глазом, ибо текст (не XML), т.е. отдладка идёт без проблем.

Кажется JSON по определению правил является подмножеством от YAML, но был разработан независимо. Парсеры от YAML парсят и JSON. Всё остальное слишком избыточно (был уже и XML/SOAP/WSDL в работе).

Телекомы всё больше используют XML и SOAP, а жаль, т.к. половина информации в запросах нафиг не нужна. M$-SOAP уже поддерживает передачу в формате JSON.

Пускай SOAP умрёт вместе с дотNET, и M$ за собой потянет. Apache Axis и дотNET по SOAP-у даже не совместимы...

> Пускай SOAP умрёт вместе с дотNET, и M$ за собой потянет.

И будет им Виста надгробным камнем :-)

Популярно о SOAP:

http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/

;)

интересная статья на сайте у IBM
The Python Web services developer: Messaging technologies compared
Choose the best tool for the task at hand.
http://www-128.ibm.com/developerworks/webservices/library/ws-pyth9/

Если коротко, то результаты таковы:
Technology;Connect time;Send string (21,000 characters);Receive string (22,000 characters);Send 5,000 integers;Client LOC;Server LOC;Actual message size sending 1,000 characters;Actual message size sending 100 integers
Raw sockets;0.002242;0.001377;0.001359;6.740674;57;25;2,279;85,863
CORBA;0.000734;0.004601;0.002188;1.523799;37;18;2,090;27,181
XML-RPC;0.007040;0.082755;0.050199;100.337219;29;17;4,026;324,989
SOAP;0.000610;0.294198;0.279341;1,324.296742;32;10;4,705;380,288

> The Python Web services developer: Messaging technologies compared

Это неопровержимо доказывает, что эффективные технологии не нужны :/

Я для себя давно вывел, что эффективность - категория относительная. Потому выбирать всегда буду сообразуясь с задачей и трудозатратами.
Толку от того, что Corba работает быстрее, если в комбинации "более мощное железо(которое дЕшево ныне до безобразия)+более дешевые разработчики+быстрее по времени разработки+дешевле при покупке" SOAP зарулит означенную корбу в моих конкретных условиях ?
Особенно учитывая что иногда приходится сознательно жертвовать скоростью работы в угоду скорости разработки...
Так что перфекционизм (неустанное стремление к совершенству) не в цене , тут вы правы ;)

> зарулит означенную корбу в моих конкретных условиях

чем? что в этом уродском SOAP лучше, чем в CORBA? (NAT и прочее не рассматриваем - только случай LAN).