CORBA - наследие?

Для проекта распределенных вычислений, начинающегося сегодня, с 0 устаревшими компонентами, есть ли веские причины обратить внимание на CORBA?

По-прежнему существуют ситуации, в которых CORBA может быть хорошим ответом:

• когда вы создаете распределенную систему, включающую несколько языков программирования и несколько платформ,
• когда ваша система влечет за собой отправку сложных структур данных ... а SOAP этого не сокращает,
• когда у вас высокая скорость обмена сообщениями ... и HTTP этого не делает, или
• когда вам нужно взаимодействовать с существующими клиентами и / или службами CORBA.

Но, сказав это, есть альтернативы, которые делают то, что делает CORBA, только лучше ... по крайней мере, они так утверждают. Например, ZeroC's ICE

РЕДАКТИРОВАТЬ @fnieto вмешивается, чтобы сказать (или намекнуть), что ICE не бесплатен, но TAO - бесплатно.

Это неточно и вводит в заблуждение .

1. ICE - это программа под лицензией GPL, которую можно бесплатно загрузить. Вам нужно было заплатить за ICE только в том случае, если вы / ваша компания не готовы жить с условиями GPL. (Или если вам нужна поддержка.)
2. Я использовал ICE как пример альтернативы CORBA. TAO - это CORBA. Авторы ICE приводят убедительные аргументы в пользу того, почему они могут повысить производительность, не будучи совместимыми с CORBA.
3. TAO ни в коем случае не является единственной реализацией CORBA с открытым исходным кодом. Я могу думать о трех других, не в моей голове.

Обратной стороной ICE является отсутствие взаимодействия со стеками промежуточного программного обеспечения CORBA, но, по моему опыту, совместимость различных реализаций CORBA также может быть проблематичной. (Возможно, в этой области ситуация улучшилась ... но я не работал над CORBA с ~ 2002 года, поэтому я немного не в курсе.)

Судя по имеющимся ответам, это почти религиозная тема. На CORBA можно смотреть так же, как на полупустой / наполовину полный стакан: с одной стороны, CORBA устарела устаревшим мусором, а с другой стороны, она относительно стабильна с несколькими доступными реализациями и «дьяволом, которого вы знаете».

В своей работе я вижу CORBA, развернутую во встроенных системах, системах реального времени (CORBA имеет расширения RT) и т.п. Есть не так много альтернатив AFAIK.

Еще одним «преимуществом» CORBA является наличие нескольких высококачественных реализаций с открытым исходным кодом, например TAO, MICO, JacORB и т. Д., С различными моделями лицензирования и поддержки. Также доступны коммерческие версии.

Что касается «большинства» приложений CORBA, реализуемых на Java, по моему опыту это не так. Хотя отображение языка для CORBA и Java является одним из самых хороших (что, возможно, не о многом говорит), Java уже имеет очень хорошую модель распределенных вычислений, которая предлагает богатство, выходящее за рамки CORBA, и все приложения Java используют это больше, чем CORBA. Подавляющее большинство разработок CORBA, которые я видел, ведется на C ++ (который также является худшим языковым отображением).

Наконец, CORBA предлагает стандартизованные асинхронные вызовы на стороне клиента в форме AMI, но никогда не предлагал асинхронную обработку на стороне сервера. TAO предлагает нестандартную реализацию на стороне сервера под названием AMH.

Я считаю, что Corba был как бы возрожден оригинальной спецификацией EJB, поскольку EJB можно легко превратить в компоненты CORBA с помощью небольшой настройки. Я подозреваю, что большинство развертываний Corba на самом деле было реализовано на Java.

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

Существует множество очень привлекательных способов делать то же самое (за исключением упомянутого выше высокого класса).

• Облачные вычисления (веб-сервисы, масштабируемые вычисления, слабая связь, организация очередей).
• REST-сервисы (веб-сервисы lite).
• SOAP-сервисы (тяжелые веб-сервисы).
• Грид / кластерные вычисления (организация очередей, уменьшение карты и т.п.)

Но, конечно, ваш Milage может варьироваться.

Очевидно, это зависит от типа рассматриваемого сервера и межпроцессного взаимодействия. И я думаю, что Стивен Си и Крис Клиланд очень хорошо освещают положительные моменты Corba.

Наше приложение использует CORBA (Orbix) более 10 лет, поэтому теперь оно унаследовано. И по тому, как написано, CORBA - хорошая технология. Однако, если бы я начинал заново, я бы, вероятно, не использовал CORBA:

• Это сложно, и лишь небольшое количество людей в моей организации знают это очень хорошо, поэтому решать все сложные проблемы приходится именно им.
• Подбор персонала может быть проблемой. CORBA уже перестала быть крутой и не становится все круче. Хотя в Ирландии разработчики C ++ тоже немного скупы.
• Большинство консалтинговых фирм хотят использовать веб-службы для работы по интеграции, поэтому, если вы хотите, чтобы третьи стороны выполняли интеграцию, вам, вероятно, в любом случае потребуется api веб-служб.

Теперь, в зависимости от типа общения, которое я хотел, я бы, вероятно, рассмотрел:

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

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

CORBA, безусловно, старомодна, но она также предоставляет определенные высокоуровневые функции из коробки (см. Здесь ). Все эти функции могут быть реализованы с использованием современных веб-служб, но, вероятно, не стандартным способом и не без большой дополнительной работы.

Однако для 99% распределенных сервисов CORBA нежелательна. Это уродливо, сложно и трудно использовать.

Одна вещь, о которой здесь никто не упомянул, - это ОТКРЫТЫЕ, ОТКРЫТЫЕ СТАНДАРТЫ. Из всех существующих технологий (кроме SOAP) это единственный настоящий открытый стандарт white paper. Стандарт не зависит от технологий какой-либо одной организации. RMI (Sun / Oracle), DCOM (ныне несуществующий - Microsoft). Он полностью не зависит от поставщика и языка. За исключением SOAP, ни одна из других технологий DOS (технология распределенных объектов) не поддерживается.

Я архитектор программного обеспечения, и мне постоянно приходится делать выбор, какую DOS следует использовать при проектировании системы. Если бы не религиозная война, с которой я сталкиваюсь каждый раз, это была бы МАМА или CORBA.

Посмотрите на это с другой стороны, если бы он был настолько мертв, ни одна из сетей 3 / 4G не работала бы. 3GPP полностью соответствует требованиям CORBA. Европейская спутниковая система полностью соответствует требованиям CORBA. Спросите себя, почему? Это потому, что они должны быть основаны на архитектурах, нейтральных к поставщику и языку!

Я бы сказал, что текущий уровень зрелости веб-сервисов (включая REST) ​​и EJB-компонентов в мире Java (которые могут даже использовать CORBA изнутри) покрывают все, что необходимо для распределенных корпоративных систем.

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

Это не противоречит использованию WebServices (или действительно CORBA), но указывает на аспект выбора вашего продукта, который может быть упущен из виду при начальном волнении по поводу запуска некоторой распределенной обработки.