Является ли CORBA наследием?
Для проекта распределенных вычислений, начинающегося сегодня, с 0 устаревшими компонентами, есть ли веские причины для изучения CORBA?
8 ответов
Есть еще ситуации, когда CORBA может быть хорошим ответом:
- когда вы строите распределенную систему, включающую несколько языков программирования и несколько платформ,
- когда ваша система влечет за собой отправку сложных структур данных... а SOAP не обрезает,
- когда у вас высокий уровень обмена сообщениями... а HTTP его не обрезает, или
- когда вам нужно взаимодействовать с существующими клиентами и / или сервисами CORBA.
Но, сказав это, есть альтернативы, которые делают то, что делает CORBA, только лучше... или так они утверждают. Например, ZeroC ICE
РЕДАКТИРОВАТЬ @fnieto вмешивается, чтобы сказать (или подразумевать), что ICE не является бесплатным, но TAO есть.
Это неточно и вводит в заблуждение.
- ICE является программным обеспечением GPL и доступно для бесплатной загрузки. Вы должны были заплатить за ICE только в том случае, если вы / ваша компания не готовы соблюдать условия GPL. (Или если вам нужна поддержка.)
- Я использовал ICE как пример альтернативы CORBA. Тао - это Корба. Авторы ICE приводят убедительные аргументы в пользу того, почему они могут добиться лучшей производительности, если не будут соответствовать требованиям CORBA.
- 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 можно легко превратить в bean-компоненты CORBA с помощью небольшой конфигурации. Я подозреваю, что большинство развертываний Corba фактически были реализованы на Java.
Что касается популярности, я думаю, что в течение ряда десятилетий могут существовать некоторые высокопроизводительные развертывания, но для большинства людей Corba мертв.
Есть много очень сексуальных способов сделать то же самое (за исключением высокого класса, упомянутого выше).
- Облачные вычисления (веб-сервисы, масштабируемые вычисления, слабая связь, организация очередей).
- REST услуги (веб-сервисы лайт).
- SOAP-сервисы (тяжелые веб-сервисы).
- Грид / Кластерные вычисления (организация очередей, уменьшение карт и т. П.)
Но, конечно, ваш Milage может меняться.
Очевидно, это зависит от типа сервера и межпроцессного взаимодействия, которое вы рассматриваете. И я думаю, что Стивен Си и Крис Кливленд очень хорошо освещают позитивы Корбы.
Наше приложение использует 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) и EJB-компонентов в мире Java (которые могут даже использовать CORBA под прикрытием) покрывают то, что необходимо для распределенных корпоративных систем.
Я бы посоветовал, чтобы один аспект, на который вы должны внимательно посмотреть, - это степень асинхронного взаимодействия, которая вам нужна в вашей распределенной системе. Я постулирую, что любая распределенная система нетривиального масштаба нуждается в асинхронной связи, и выбранная инфраструктура должна поддерживать асинхронную обработку, обычно это означает очереди.
Это не противоречит использованию Web Services (или даже CORBA), но оно указывает на аспект выбора вашего продукта, который может быть упущен из виду при начальном волнении по поводу запуска некоторой распределенной обработки.
Нет. Не используйте корбу. (Ответ из будущего - 2021 год)
Если кто-то случайно прочитает этот очень старый вопрос, он может подумать, что корба жива. Унаследованные приложения, которые были созданы примерно в 2000–2005 годах, иногда все еще содержат corba.
Компании тратят большие деньги на избавление от корбы по нескольким причинам.
- Это старое
- Очень сложно найти разработчиков, которые знают Corba или готовы работать с этой старой технологией.
- Отсутствие хорошей документации, и это не обсуждается на форумах, таких как stackoverflow.
- Трудно перенести его в облако (Azure, AWS) в основном потому, что
- IOR содержит внутренний IP-адрес, поэтому вам может потребоваться настроить его для использования FQDN, добавления iptables или какого-либо решения для маршрутизации / прокси.
- Иногда приложение запускается каждый раз на другом порту, поэтому вам нужно ограничить порт.
- Если вы хотите использовать corba в EJB, ... обратите внимание, что EJB также очень старый и не лучший выбор
REST api - лучшее решение на сегодняшний день. Он очень распространен, работает по http, https, что проще перенести в облако, это знает практически каждый BE-разработчик. Вы можете использовать REST с любого языка, существуют фреймворки, которые упрощают его использование.