CORBA VS Webservices - PullRequest
       7

CORBA VS Webservices

5 голосов
/ 27 апреля 2011

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

Ответы [ 4 ]

6 голосов
/ 19 ноября 2012

Я подозреваю, что все началось с проблем с брандмауэром: запросы 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 также бесплатен).

4 голосов
/ 09 мая 2011

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

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

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

1 голос
/ 27 апреля 2011

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

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

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

CORBA:

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

CORBA проиграл в основном из-за двух вещей:

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

...