Вопрос

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

Это было полезно?

Решение

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

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

Но, сказав это, есть альтернативы, которые делают то же, что и CORBA, только лучше ...по крайней мере, так они утверждают.Например ЛЕД Зерока

Редактировать @fnieto вмешивается, чтобы сказать (или подразумевать), что ЛЕД не бесплатный, но ДАО есть.

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

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

Недостатком 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.

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

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

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

Но, конечно, ваш Пробег может быть разным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top