Как лучше организовать такое взаимодействие? CORBA вроде для этого была, но тяжеловата все-таки. А какие есть альтернативы? Может, попробовать Google protobuf + Apache Mina?

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

А>Как лучше организовать такое взаимодействие? CORBA вроде для этого была, но тяжеловата все-таки. А какие есть альтернативы? Может, попробовать Google protobuf + Apache Mina?

JNI, если в рамках одного приложения.

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

А>Как лучше организовать такое взаимодействие? CORBA вроде для этого была, но тяжеловата все-таки. А какие есть альтернативы? Может, попробовать Google protobuf + Apache Mina?

Hessian. Только мина вам зачем? Гоните прямо в сокет.

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

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

А>>Как лучше организовать такое взаимодействие? CORBA вроде для этого была, но тяжеловата все-таки. А какие есть альтернативы? Может, попробовать Google protobuf + Apache Mina?

А>JNI, если в рамках одного приложения.

нет, приложения разные, иначе не пришлось бы делать именно сетевое взаимодействие

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

А>Как лучше организовать такое взаимодействие? CORBA вроде для этого была, но тяжеловата все-таки. А какие есть альтернативы? Может, попробовать Google protobuf + Apache Mina?

Что то я не совсем понимаю чем же тяжела Corba. Зачем бред то такой писать не пойму. Не ну раз вас прямо так корба не устроила, ну что же. Пишите своё решение. Одним велосипедистом станет больше.

И да, что бы вам помогли нуж всётаки указывать о каком взаимодействии идёт речь. К примеру, пару метров XML данный можно по сокету пустить. А вот вот реплицированный запрос к бд, или какого нибуть рода отчёт сформировать, то это уже другое. Конкретней надо вырожать свои вопросы и пожелания, тогда и ответы будут удовлетворительные!

Здравствуйте, SToRM1k, Вы писали:

STR>Что то я не совсем понимаю чем же тяжела Corba. Зачем бред то такой писать не пойму. Не ну раз вас прямо так корба не устроила, ну что же. Пишите своё решение. Одним велосипедистом станет больше.

STR>И да, что бы вам помогли нуж всётаки указывать о каком взаимодействии идёт речь. К примеру, пару метров XML данный можно по сокету пустить. А вот вот реплицированный запрос к бд, или какого нибуть рода отчёт сформировать, то это уже другое. Конкретней надо вырожать свои вопросы и пожелания, тогда и ответы будут удовлетворительные!

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

я CORBA использовал не в одной системе, и знаю, чем она грозит. Давай-ка посмотрим, если у нас на стороне Java-приложения генерируется поток событий, который должен быть получен на другой стороне. Что в этом случае использовать? Callback-и? Фу, столько минусов, даже перечислять влом. Notification Service? Почему нет...ах да, нужно найти реализацию для Java, и для С++. Ок. берем JacORB, дальше ищем для С++...что, только ACE+TAO? Других бесплатных нет? Хорошо, компилируем этого монстра (ACE — нормальная по размерам, а вот TAO ). Дальше...ой, а мы не желаем использова Naming Service, нужно подключаться просто на определенный порт? Отлично, используем IOR Table, и пишем полстраницы кода биндингов.

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

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

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

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

А>я 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.

Здравствуйте, SToRM1k, Вы писали:

STR>А вот кстате какой-нибудь omniORB в полне универсален, у меня на нём операторский биллинг висит, до 900 звонков одновременных может обработать на стареньком п4,
поясните для неграмотных — это 900/100000000000 вызовов методов в минуту/секунду или что?

Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, SToRM1k, Вы писали:

STR>>А вот кстате какой-нибудь omniORB в полне универсален, у меня на нём операторский биллинг висит, до 900 звонков одновременных может обработать на стареньком п4,
D>поясните для неграмотных — это 900/100000000000 вызовов методов в минуту/секунду или что?

Хм.. Ну если тебе не лень посчитать то, каждый звонок пораждает 2 вызова на авторизацию, это проверка существует ли пользователь и запрос пароля. Далее идёт запрос маршрутизации. Запрос на старт звонка + каждые 10 секунд обновление информации о звонке и стоп, окончание звонка. Вот и представь 900 звонков при установлении сессии 3 запроса, и плюс на протяжении сессии каздый звонок в 10 секунд делает вызов. Мне откровенно говоря лениво считать, да и особого смысла не вижу в подщёте.

Здравствуйте, SToRM1k, Вы писали:

STR>Вот и представь 900 звонков при установлении сессии 3 запроса, и плюс на протяжении сессии каздый звонок в 10 секунд делает вызов. Мне откровенно говоря лениво считать, да и особого смысла не вижу в подщёте.
т.е исходя из средней длины разговора скажем в три минуты получается ~((3+180/10)*900)/180 = 105 вызовов/сек. это нагрузка веб сайта (крутого правда, рсдн ИМХО меньше), а не серьезного ipc.
кстати в omniorb уже починили callback-и или они так и жрут по "метру" на вызов даже без аргументов?

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

А>Как лучше организовать такое взаимодействие? CORBA вроде для этого была, но тяжеловата все-таки. А какие есть альтернативы? Может, попробовать Google protobuf + Apache Mina?
что понимается под взаимодействием? нужны ли навороты вроде сервис локатора, исключений или можно обойтись посылкой сообщений. пару лет назад в ентерпрайз модно было в вебсервисы всё заворачивать, а потом хореографировать или оркестрировать через BPEL движки, ну это когда бюджет был соответствующий применяемым методам.
без более подробного описания того что надо боюсь дельного ничего не посоветуешь

PS для простого клиент-сервера сейчас модно делать RESTfull вебсервисы с xml или json ом внутри — просто потому что уже привыкли + вебморду натянуть просто на такое 8)

Здравствуйте, dotidot, Вы писали:

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

А>>Как лучше организовать такое взаимодействие? CORBA вроде для этого была, но тяжеловата все-таки. А какие есть альтернативы? Может, попробовать Google protobuf + Apache Mina?
D>что понимается под взаимодействием? нужны ли навороты вроде сервис локатора, исключений или можно обойтись посылкой сообщений. пару лет назад в ентерпрайз модно было в вебсервисы всё заворачивать, а потом хореографировать или оркестрировать через BPEL движки, ну это когда бюджет был соответствующий применяемым методам.
D>без более подробного описания того что надо боюсь дельного ничего не посоветуешь

D>PS для простого клиент-сервера сейчас модно делать RESTfull вебсервисы с xml или json ом внутри — просто потому что уже привыкли + вебморду натянуть просто на такое 8)

не-не, сценарий взаимодействия простой, никаких наворотов. сообщений будет достаточно, потому и начал смотреть на фреймворки по сериализации.
идет обмен управляющими командами в обе стороны, и от одной из сторон идет поток событий (в пике событий ~100 в секунду. не так круто, как у яйценосного биллинга, но чем богаты)

Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, SToRM1k, Вы писали:

STR>>Вот и представь 900 звонков при установлении сессии 3 запроса, и плюс на протяжении сессии каздый звонок в 10 секунд делает вызов. Мне откровенно говоря лениво считать, да и особого смысла не вижу в подщёте.
D>т.е исходя из средней длины разговора скажем в три минуты получается ~((3+180/10)*900)/180 = 105 вызовов/сек. это нагрузка веб сайта (крутого правда, рсдн ИМХО меньше), а не серьезного ipc.
D>кстати в omniorb уже починили callback-и или они так и жрут по "метру" на вызов даже без аргументов?

Точо, хороший вопрос. А кстати, в omniORB есть поддержка bidirectional iiop, или на каждый callback устанавливается новое сетевое соединение, по старинке? если по старинке, то это создает много проблем при развертывании, если между клиентом и сервером стоит файервол (на самом деле это уже в сторону, не мой случай. у меня все будет крутиться на одной физической машине).

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

А>идет обмен управляющими командами в обе стороны, и от одной из сторон идет поток событий (в пике событий ~100 в секунду. не так круто, как у яйценосного биллинга, но чем богаты)
я использую google-protobuf с велосипедным rpc сделанным через correlation id в сообщениях, завернутый в собственный простой бинарный протокол. Но такая жуть получилась только потому что приходится в рамках одного tcp соединения быть (мобильные платформы чтоб их), а нужны и методы и односторонний поток сообщений, видео
в общем меня можно считать специалистом по эзотерическим велосипедам кстати даже с такими наворотами оно всё гораздо проще чем корба (есть опыт длительного геморроя с omniorb).