Как соотносятся понятие CORBA и SOA? 

Ранее рассматривались понятия CORBA и COM. А как в эту картину вписывается SOA?

CORBA - это технологическая база: механизм удаленных вызовов плюс мощная компонентная модель (основа для будущей j2ee). На основе этой технологии можно построить SOA-решение в виде набора слабосвязанных сервисов (CORBA-компонентов - "сервантов"). А можно построить классическое сильносвязанное приложение.
Это как с веб-сервисами - можно их использовать как инфраструктуру для SOA-решения, а можно реализовать классическую двухзвенку.
SOA-решение можно построить с использованием практически любой технологии: CORBA, RMI, RPC, WS, да хоть локальные java-вызовы - при соблюдении парадигмы это будет SOA в рамках отдельно взятой JVM )))

ekr, спасибо   

Всем привет!
Насколько ESB является продолжением CORBA? Можно ли говорить, что корба - не очень хорошее решение? В чем его сложность, о которой все пишут. Сильносвязанное приложение - чем плохо?

Ну и про ESB вообще - что это скорее (чего больше в этом понятии):

технология для интеграции существующих приложений

или

технология для построения новых распределенных приложений

???

Читаю литературу и никак не пойму, то разговор про распределение, то про интеграцию... %)

Если ESB - Enterprise Service Bus , то это для интеграции приложений на основе обмена асинхронными сообщениями. Это реализация спецификации JMS, т.е. системы асинхронных сообщений. Можно считать, что интеграция с помощью ESB нескольких существующих приложений дает новое распределенное приложение.

CORBA - спецификация для синхронного взаимодействия, подобно RMI, но без привязки к java.  

Таким образом, разница в способе коммуникации между приложениями: асинх - синх , т.е. как JMS - RMI 

Это сообщение отредактировал(а) COVD - 27.3.2008, 15:48

CORBA - это не решение, а спецификация. Обычно её критикуют за нечёткость формулировок, допускающих различное толкование, от чего реализации CORBA оказались несовместимыми между собой (главным образом реализации от Microsoft и Sun). Кроме того, её критики часто указывают на её слишком большой объём, что она слишком избыточна для нужд бизнеса и именно по-этому полностью она так и не была реализована, только частично.

ESB же - это просто класс продуктов, обычно присутствующий в линейках решений SOA. Для ESB, насколько я знаю, чётких спецификаций нет и ESB-решения разных производителей довольно сильно отличаются друг от друга.


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

Если взять два вполне себе самостоятельных "существующих приложения" и интегрировать их между собой, то результатом интеграции будет новое распределённое приложение, а не результат простой суммы первого и второго. Вспомним Арестотеля: Я бы предложил здесь пользоваться терминологией теории систем, тогда мы говорим так: программная система включает в себя в качестве подсистем другие программиные системы (которые тоже могут включать в себя множество всякой всячины). Больше про теорию систем можно почитать у Р. Акоффа.

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

Не обязательно. Может быть очень даже синхронными.


Вовсе не обязательно. Есть SOA-решение от MS и других вендоров, реализованных не на Java вообще.


CORBA - механизм удаленных вызовов (RPC), подобно RMI плюс мощная компонентная модель.


Да, разница есть, но это не фишка ESB. ESB может связывать сервисы как синхронно, так и асинхронно.


Когда это MS реализовывал CORBA? Их COM/DCOM - противник CORBA в области технологий удаленных вызовов. SUN тоже не полностью реализовывает её - только ORB (ядро удаленных вызовов), о компонентной модели ни духом.


Что за дуализм? ))) Нет плохого или хорошего. Есть подходящее для текущей задачи или нет.
Если 100 подсистем крупной конторы сильно связать при интеграции, то это пипец при поддерже и развитии. 

А решения для SMB строить на SOA - мочить воробьев из авиационной пушки с вращающимся блоком стволов )

Есть некий "калькулятор" на с++. Есть вычислительная задача, разбиваемая на части. Части скармливаются калькуляторам, от них получается ответ. Запрос-ответ сохраняется в БД. После вычисления какого-то количества частей - считается какой-то конечный результат.

Как правильно решить эту задачу? Раньше она была решена с помощью корба, а именно VisiBroker использовался. В чем я выйграю, если перепишу систему под web-сервисы? и будет ли вообще выйгрыш? Затраты на переписывание не в счет.

Какие проблемы есть у корба? Все таки ее почти не используют на данный момент и примерно с 2004 года тон статей о ней в большей мере таков: эх, хорошая технология, но... и дальше про web-сервисы.

Наверное, проиграете на пересылке данных (что, наверняка, не принципиально в "запрос-ответ" ) , потому что описание обьектов в виде xml явно избыточно. Зато, возможно, систему будет проще поддерживать, модернизировать, распространять (внедрять).    

Что сейчас используется для хостинга web-сервисов?

Если с win-платформой мне более-менее ясно в свете использования .Net, с которым я знаком в достаточной мере. То linux вызывает небольшие опасения. Есть Apache axis c++. Можно использовать его. Но насколько оно надежно и опробировано. Можно ли хостить службы также как в wcf: просто запуская какой-то процесс?

Идея в использовании промежуточного слоя, чтобы не копаться во всем этом. Что можно использовать вместо ORB?

Это сообщение отредактировал(а) GraDea - 16.4.2008, 08:10