Блог

Почему веб-сервисы воспользовались преимуществами CORBA?

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

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

Также может быть фактором, что в сообщениях CORBA используются выровненные поля (для соответствия выравниваниям границ, поскольку они используются в структурах данных C / C ). Производные протоколы (такие как буферы протокола Google) не отправляют ненужные байты только для выравнивания. Следовательно, эти сообщения компактны, и эти протоколы могут быть предпочтительнее, когда требуются двоичные сообщения и быстрые предварительно сгенерированные анализаторы сообщений. Буферы протокола, которые кажутся мне довольно похожими на CORBA по дизайну (IDL-подобный компилятор, заглушки и вспомогательные устройства, двоичные сообщения, языковая совместимость), действительно далеки от упадка, будучи внутренне используемыми во многих сервисах Google.

Хотя платформа CORBA сложна, «правильно выполненный» стек веб-сервисов также не совсем тривиален, поэтому я не думаю, что сложность стандарта была проблемой. Аналогичным образом, хотя исходные документы спецификации OMG могут показаться ужасными, аналогичные спецификации SOAP / WDSL не менее сложны, вероятно, трудно документировать стандарт в удобном для чтения виде.

Протоколы CORBA не являются собственностью, они были реализованы в свободном программном обеспечении много раз, включая реализации JacORB, а также GNU / Classpath (ну, теперь OpenJDK также свободен).

Хотя изначально считалось, что CORBA предоставляет то, что веб-сервисы предоставляют сегодня, я думаю, я согласен, что, похоже, для этого приложения CORBA «проиграла».

Однако, как технология RPC, которая поддерживается на широком спектре платформ (встроенных), хорошо работает и тестируется на родном языке (C ) и может быть использована для реализации довольно производительных сценариев передачи данных, я действительно думаю, что CORBA по-прежнему занимает важную нишу. Это просто не имеет ничего общего с «Интернетом».

Чтобы напрямую обратиться к вопросу: мне нравится думать, что CORBA «потеряна», потому что, в отличие от веб-сервисов, она не нацелена на Веб, как она используется сегодня — Как в: туннелирование всего через порт 80, запуск приложений на 60% в браузере и на 40% на веб-сервере и т.д.

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

Веб-сервисы:

• Проще, хотя WS-* может добавить веса и сложности
• Используйте HTTP как проводной протокол вместо проприетарного
• Может туннелировать через порт 80 в брандмауэре
• Сервисы не такие полные

CORBA:

• Для работы требуется ORB
• Собственные поставщики или с открытым исходным кодом
• Может использовать HTTP, но также использовать проприетарные протоколы
• Предоставлять такие сервисы, как именование, каталог, транзакция, безопасность и т.д.

CORBA проиграл в первую очередь из-за двух вещей:

1) отсутствие хороших инструментов разработки / тестирования или IDE-плагинов 2) Смотрите (1) еще раз