А чем оно все-таки лучше ORBit2? Кто-нибудь из корбовских спецов может компетентно и внятно сравнить (может, и с другими ORB)?

Я не понял - в плане поддержки стандартных сервисов. У них на сайте вроде бы лежит документация только на Naming, а как на счет остальных?

Я не спец, но я скажу :)))

ORBit2 - это гномовское поделие, а потому некошерно для использования, например, в KDE :) Да и C++ родной...

А насчет стандартов - так за сертификат надо денег платить...

omniORB 4 обещает полную совместимость с CORBA 2.3 и часть фич из CORBA 2.4. Переход с omniORB 3.0.4 проходит простой перекомпиляцией.

А поругайте мне TAO :-) А то ведь г-н Шмидт с сотоварищи обещает CORBA-2.6 + RT Extensions.

Раздражает навязывание им своей структуры source tree и отсутствие врапперов компайлера и линкера (как например в mico), что негибко и значительно усложняет внедрение корбы в существующий проект.

Кроме того тесты производительности дают весьма странные результаты. Например ихний echo пущенный на двух машинах (клиент и сервер на разных) не загружает ресурсы (сеть, процессор) ни на одной на 100%. При этом mico на том же примере дает примерно в 7-9(!) раз большую производительность.

Как достоинство следует отметить простоту установки и настройки.

Я люблю TAO. Это на мой взгляд наиболее продуманный ORB для C++ из всех, что я успел посмотреть (ORBit-C++, omniORB, MICO, ORBacus, и т.д.). Правда и у него есть недостатки: несколько громоздк (для новичков), дибильная система настройки на платформу (это мое мнение), и до версии 5.2.3 не очень совершенная система перехвата исключений для компиляторов, которые не понимают нативные исключения.

TAO - это действительно самый хороший ORB imho.
У кого-нибудь есть TAO Developers Guide? Меня оченно жаба душит 250 долларов за него платить :(. А, например, 50 - вполне бы заплатил..

ORBit2 - это сильно урезанная, а потому и быстрая реализация CORBA. Идеальна для примитивных применений подобным COM (Ms Win), KParts (KDE), т.е. для сложных пользовательских интерфейсов.

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

-- inger

ТАО очень кошерная штука. Но его настройка на платформу, компилятор и т. п. очень утомляют. Опять же с счёт всей темплейтности кода пересобирать проект на ТАО совершенно отдельное удовольствие.

ОРБит - какашка, ибо не стабилен, тормознут, и нормального биндинга к плюсам до сих пор не существует.

А вот омниОРБ - легкий, быстрый, собирается на ура. И вообще я его люблю :) Ибо живу на 4-й версии начиная с их первых билдов. А что до стандартных сервисов, то Найминга мне пока хватает, а если приспичит - то можно и из ТАО выковырять в конце-то концов. Ибо что-то дописать в нутрь омни - легче лёгкого. В отличии от того же ТАО. Я вот например поддержку СР1251 прикуртил :). А по скорости он проигрывает ТАО сущие копейки - в пределах 3-5 процентов, что можно вообще списать на погрешность измерения.

Ну хорошо, уточним вопрос. Если не брать в расчет языковой аспект (ну не люблю я С++, люблю С и Java:), то какие фишки из ORBit выкинуты? Вроде, Naming есть. А других сервисов и в omni не значится. Или дело в чем-то другом?

Про кошерность - понятно. Хотя, насколько я знаю, ORBit не завязан на гном - его хоть в консольных аппликуха запускать можно...

Кстати, коллеги, вы тут себе противоречите. Один говорит "тормознут". Другой - "урезан и быстр". Так все-таки, где правда? Или он тормознут, когда вы хотите скорости, и быстр, когда вам нужно торможение?:)

ORBit быстр, сомнений нет, но уж очень примитивен он.

ORBit не быстр. Во всяком случае я когда выбирал ОРБ, то омни сделал ОРБит в два счёта. Правда тогда 2-й ОРБит был совсем не живой. Может быть что-то уже поменялось....

А чего тут некоторые пытаются притянуть стандартные сервисы к реализации ORB? Это разные вещи! И производительность ORB от сервисов не зависит.

Так и не ответили... То - быстр, то - не быстр:) И про примитивность подробнее никто рассказать не хочет. Хоть пару деталей, а, граждане?

Кстати, для svu: давайте, я выложу свой билд TAO для Alt, как предлагал пару дней назад, заодно и посмотрите, посравниваете? У меня сейчас просто совсем нет времени гонять тесты, к сожалению - "прыгать надо"... :-)

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

2svu Да чего тут отвечать. ORBit2 по существу так и остался C'шным ОРБом. omniORB - C++'ная штука

А, так значит, для использования в C ORBit2 - самое то?!

Вопрос к знатокам CORBA .
Скажите например у меня в ТАОшном серванте есть массив ссылок на другие серванты sequence<SomeServant>
Так вот. Коннекчу я один раз эти ссыли в смысле, инициализирую соединение с сервантом, вызываю там какой-нить его метод.
А если потом я хочу эту ссылку убить и на ее место поставить ссылку на какой-нибудь другой удаленный объект. Как это делается?


CORBA::Object_var a_obj = this->naming_context_->resolve (name);
connectionPool[freeone]=A::_narrow(a_obj.in());

ну вот отюзал я этот connectionPool[freeone] а теперь хочу на его место поставить кого-либо другого..Чего мне со старым делать?

Пожалуйста ответтье.
Заранее спасибо.

Почему никто ещё не упомянул omniORBpy? В сочетании с интерактивной строкой python-а это идеальное средство для живой отладки CORBA сервисов :)

Намаялись мы с этим дерьмом, особенно много проблем в аппликациях которые делают fork().
Сейчас пришлось отказаться, вычищаем из всего проекта...
Если можно обойтись примитивным IPC, используйте лучше его а не CORBy

> Намаялись мы с этим дерьмом, особенно много проблем в аппликациях
> которые делают fork().
> Сейчас пришлось отказаться, вычищаем из всего проекта...
> Если можно обойтись примитивным IPC, используйте лучше его а не CORBy

С CORBA или именно с omniORB?

2BaT: именно с omniORB. Начальство жалось на коммерческую имплементацию и нас заставили использовать omniORB.
Для малюсеньких примитивных примеров вполне подходит.
Но когда наш проект разросса до приличных размеров тут и начали лезьт
из этого г-омниОРБА кишки.
Вобщем не ходите девки замуж...
Сейчас третий месяц благополучно переходим на самоделку типа
TIBCO message bus. Пока тфю,тфю, ... никаких проблем.
Работает быстрее потому как просто хорошо написано и без всякой
дури.
Для тех кто хочет использовать omniORB будет самое лучшее
посмотреть как он написан. Вобщем сыро для серьезных систем.
А вообще мы в этом проекте отказались от CORBA да и следующем
не будем ее использовать потому как приседаний много а толку мало.

2anonymous (*) (2002-10-19 04:28:56.247) > ...вообще мы в этом проекте отказались от CORBA да и следующем... Сразу видно какие "спецы" по CORBA взялись за проект. Прежде чем ругать, сначала надо изучить!

>Для малюсеньких примитивных примеров вполне подходит А не приходила-ли вам идея вообще отказаться от этого дурацкого OOD, C++ и бесполезных "приседаний", перейти на C с MPI и постить потом во все форумы какие вы крутые девелоперы и какой отстой omniORB и все эти OO-технологии???

Да чувак мы спецы, потому как пишем давно и много (кстати и зарплаты у нас поболее твоего будут :),
а ты видать на этом omniORB'е ничего сложнее "hello world"
не писал. (если вообще что - то путное в своей жизни ты написал :)
Насчет ООП я вообще необмолвился так что чувак не занимайся обсирательством без причины только ради показа какой ты крутой...
А насчет MPI ты парниша почти прав - MPI это здорово, если
ты конечно использовал его сам а не только читал о нем в книжках :)
Но и CORBA кое где применяема. Да кстати умник, что же ты походя
и TIBCO bus не поругал, она ведь тоже не "обьектно ориентированая"
в твоем скудоумном понимании? Или не знаешь что это такое? :)

Вобщем еще раз - omniORB не годится для больших и комплексних
проектов - весьма сыр и имеет массу side effects которые обычно проявляются при повышении сложности модулей в проекте.
Например omniORB плохо сочетается с NSPR (нам пришлось
подкручивать сорсы чтобы они заработали вместе :(

Написал я в этот форум чтобы предостеречь реальных программеров,
а не лохов типа тебя, от напрасной траты времени на это
недоделанное произведение. Ищите ребята другую имплементацию CORBA.
:)

2 anonymous (*) (2002-10-20 08:03:52.953):
Есть TAO с весьма хорошей лицензией, очень стабильный с хорошим супортом. Какого хрена вы на omniORBe писать начали вообще не ясно. Когда выбирали реализацию, где вы все крутые программеры были?

>>"Да чувак мы спецы, потому как пишем давно и много (кстати и зарплаты у нас поболее твоего будут :), "
хоть адресовано это было и не мне, скажу, что вот это пустое пальцезакидательство нужно убирать из сообщений..

2anonymous (*) (2002-10-20 08:03:52.953) Судя по тону и стилю, ты не софт пишешь, а братков разводишь. Тогда зарплата у меня действительно меньше. Но тогда и нечего гнать то на корбу, то на omniORB, то на меня! А о том какой сырой и бесполезный omniORB напиши его "криворуким" "лошкам-разработчикам". И можешь ещё прибавить как ты крут и как далеко у тебя пальцы гнуться.

P.S. Я не ругал ни MPI ни C: каждой задаче - свои средства. А omniORB - штука очень полезная и мощная (если правильно использовать).

Для пальцованного анонимуса: а) Пальцы сожми, жить проще будет. б) Любой мультитредный проект будет плохо жить в парадигме fork-and-forget. в) Я смотрел внутрь омниОРБа. Очень аккуратно и красиво написан. Можно в качестве примеров к GoF давать. г) Я на нём делаю не самые маленькие проекты. С достаточно большой нагрузкой. Всё змечательно живёт. д) Примеры side effect's омниОРБа в студию. А так - пустословие сплошное. И, к стати, не сам ли Луговский боится показывать свою личность???? BTW, у меня всё равно длинее. Это так. Что бы флейм пресечь.

Теоретический вопрос

>Любой мультитредный проект будет плохо жить в парадигме fork-and-forget

Кстати, давно хотел спросить у знающих людей: почитал кое-что про программирование под Unix и сразу возникло подозрение, что C++ плохо сочетается с fork без дополнительных ухищрений - при вызове fork происходит логическое копирование объектов без вызова соответствующей операции копирования C++ и, в случае, если объект держит некоторые внешние ресурсы, отличные от файлов (например ссылку на удаленный объект в CORBA), то могут возникать неприятности. Так ли это? (В принципе, если в объекте C++ хранить например PID, то проблема решается).

Последовал совету "крутого" анонимуса и "Васька" и посмотрел исходные коды. Мои выводы:
1. Разные подсистемы написаны различными людьми и с
различным качеством.
2. Код кое-где сырой.
3. Нашел одну ошибку прямо в первом попавшемся файле, в подсистеме TCP/IP. Ошибка достаточно мелкая, но показательная, типа:
1. x = malloc(a)
2. strncpy(x,buf,a);
3. x[a] = 0;
Выводы о качестве делать не буду, поскольку не люблю флэйма.
Вопрос к CORBA программистам - существуют ли отличные от omniORB бесплатные и доступные в исходных кодах реализации CORBA для Linux и Windows?

Вопрос к анонимусу упомянувшем TAO: Пожалуйста проясните, что это такое, и где его найти в сети.
Вопрос не праздный поскольку наш новый заказчик требует наличия CORBA интерфейса к нашей системе, а у нас нет пока никаких идей что и где взять.

На freshmeat - The ACE Orb

Человеку. рекомендовавшему - ?это?

15 метров сжатых исходников - однако ;)

Bacek вы делаете достаточно смелые утверждения насчет плохой жизни мултитредного проекта с fork. По всей видимости это вопрос плохого или хорошего дизайна проекта.

По поводу разных подсистем в омниОРБе - да встречаются кое-где различные подходы к программированию. Но сейчас Дунка Грсби очень сильно вычищает код и прогресс заметен на лицо.

И, если не серкрет, в котором из tcp* файлов Вы нашли такую ошибку? Просто я просматривал код омни и таких ляпов мне на глаза не попалось.

Из бесплатных ОРБов для линукса/виндов это omniORB, TAO - www.riverace.org, www.cs.wust.edu/~schmidt. Можно ещё попробовать ORBit - www.gnome.org и разработки IONA - www.orbix.com кажется. И вообще Дуг Шмидт и Стви Виновски одни из крупнейших исследователей в области CORBA. Одна их книжка Advanced CORBA programming in C++ много стоит. Кстати - весьма рекомендую.

По поводу плохой жизни мультредный/форкнутых программ - это, к сожалению, суровая правда жизни. Как в случае попыток использования мультитредных модулей в том же апаче, так и использования не thread-safe подсистем в тредной программе....