Почему CORBA потеряла популярность?

Ответ 1

Это не просто CORBA, это RPC вообще. Это включает такие вещи, как DCOM, Java-RMI,.NET Remoting и все остальные.

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

Bill Joy, Tom Lyon, L. Peter Deutsch и James Gosling определили 8 "Ошибок распределенных вычислений", то есть вещи, которые новички в распределенном программировании считают верными, но которые на самом деле являются ложными, что обычно приводит к провалу проекта или значительное увеличение затрат и усилий. RPC - идеальное воплощение этих ошибок, потому что оно построено на тех же неправильных предположениях:

• Сеть надежна.
• Задержка равна нулю.
• Полоса пропускания бесконечна.
• Сеть защищена.
• Топология не изменяется.
• Существует один администратор.
• Стоимость транспортировки равна нулю.
• Сеть является однородной.

Все это верно для локальных вычислений.

Возьмите надежность, например: если вы вызываете метод локально, тогда сам вызов всегда преуспевает. Конечно, сам вызываемый метод может иметь ошибку, но фактическое вызов метода всегда будет выполняться. И результат всегда будет возвращен, или, если метод завершится с ошибкой, будет сообщена ошибка.

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

Аналогично латентности: локально вызов метода по существу свободен. Сам метод может занять произвольное количество времени для вычисления ответа, но звонок является бесплатным. По сети вызов может занять сотни миллисекунд.

Вот почему почти все проекты RPC, включая CORBA, не удалось.

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

В Erlang процессы всегда имеют отдельные кучи и отдельные сборщики мусора, как если бы они выполнялись на разных компьютерах на разных континентах, даже если эти процессы выполнялись на одной и той же виртуальной машине на одном и том же ЦП в одном и том же адресном пространстве. Если вы передаете данные из одного процесса в другой, эти данные всегда копируются, как и должно быть, если процессы были на разных машинах. Вызовы всегда выполняются как асинхронные сообщения.

Таким образом, локальные и удаленные вызовы выглядят одинаково, а не проблема. Сделать их похожими на локальные вызовы.

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

Опять же, по сравнению с Erlang, сложность намного ниже. В Erlang отправка сообщения в процесс не сложнее, чем вызов метода в Java. Интерфейс в основном тот же, но только ожидания, которые различны: ожидается, что вызовы методов на Java будут мгновенными и синхронными, в Erlang ожидается, что сообщения будут асинхронными и иметь видимую задержку. Но на самом деле их использование более не связано с простым вызовом локальной процедуры.

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

Ответ 2

Технологии распределенных объектов, такие как CORBA и DCOM, имели проблемы с детализацией. Реализации, как правило, были слишком "частыми" для работы над сетью - и, как правило, просочились детали реализации, которые сделали решение хрупким.

Ориентация обслуживания получила известность как реакция на эти проблемы.

Ответ 3

Здесь есть раздел о проблемах и критиках в статье википедии: http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture