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

Это не просто CORBA, это RPC в целом. Это включает в себя такие вещи, как DCOM, Java-RMI, .NET Remoting и все другие.

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

Билл Джой, Том Лайон, Л. Питер Дойч и Джеймс Гослинг определили 8 заблуждений распределенных вычислений, то есть вещей, которые новички в распределенном программировании считают правдой, но которые на самом деле ложны, что обычно приводит к провал проекта или значительное увеличение затрат и усилий. RPC - идеальное воплощение этих заблуждений, потому что он основан на тех же неверных предположениях:

1. Сеть надежная.
2. Задержка нулевая.
3. Пропускная способность бесконечна.
4. Сеть безопасна.
5. Топология не меняется.
6. Есть один админ.
7. Транспортные расходы нулевые.
8. Сеть однородная.

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

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

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

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

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

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

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

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

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

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

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

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

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