Является ли CORBA наследием?

Question

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

Answer 1

Есть еще ситуации, когда CORBA может быть хорошим ответом:

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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