Здравствуйте, <Аноним>, Вы писали:

А>день не задался? почему такой раздражительный какие у проблемы? ты не хочешь о них поговорить? подумай, а я пока разъясню насчет "бреда".

У меня таки как раз проблем никаких нет и не было. Поговорить, ну давай поговорим.

А>я CORBA использовал не в одной системе, и знаю, чем она грозит. Давай-ка посмотрим, если у нас на стороне Java-приложения генерируется поток событий, который должен быть получен на другой стороне.

М, возможно у вас поток событий генерится в 40 мегобайт в секунду? тогда да. Корба будет не комфортно себя чувствовать. Для всего остального в IDL придуманы контейнеры.

А> Что в этом случае использовать? Callback-и? Фу, столько минусов, даже перечислять влом. Notification Service?

Новое балавство для ленивых программистов?

А>Почему нет...ах да, нужно найти реализацию для Java, и для С++. Ок. берем JacORB, дальше ищем для С++...что, только ACE+TAO? Других бесплатных нет? Хорошо, компилируем этого монстра (ACE — нормальная по размерам, а вот TAO ).

А>Дальше...ой, а мы не желаем использова Naming Service, нужно подключаться просто на определенный порт? Отлично, используем IOR Table, и пишем полстраницы кода биндингов.

Ну судя по этому, с корбой вам ещё много времени нужно провозится, что бы подружится.

А>ИТОГ: размер дистрибутива увеличился на 20 мегабайт. Имело ли это какой-нибудь смысл — вряд ли. Зато скорость инициализации всех этих чудовищных компонент увеличит время старта на 3-4 секунды (TAO, зараза, долго поднимается. А вот какой-нибудь omniORB стартует быстрее, но у него не реализован Event Service). Критично ли это? Для кого-то нет, для меня-да.

А вот кстате какой-нибудь omniORB в полне универсален, у меня на нём операторский биллинг висит, до 900 звонков одновременных может обработать на стареньком п4, и ты знаешь я думаю твоё приложение по кол-ву запросов не переплюнет биллинговую ситсему, так что не надо мне сказки разказывать. А для того что бы использовать omniORB даже ни какие сторонние пакеджы не нужны. Для этого и был придуман стандарт ORB.