Действительно ли CORBA является наследием?

Судя по имеющимся ответам, это попадает почти в религиозную тему. На 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, которые я видел, осуществляется на C ++ (который также является худшим языковым отображением).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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