CORBA є спадщиною?

Для розподіленого обчислювального проекту, що розпочався сьогодні, з 0 застарілими компонентами, чи є вагомі причини розглянути CORBA?

Все ще існують ситуації, коли CORBA може бути гарною відповіддю:

• коли ви будуєте розподілену систему, що включає безліч мов програмування та декілька платформ,
• коли ваша система спричиняє надсилання складних структур даних ... і SOAP їх не вирізає,
• коли у вас високий рівень обміну повідомленнями ... і HTTP не скорочує його, або
• коли вам доводиться взаємодіяти з існуючими клієнтами та / або послугами CORBA.

Але сказавши це, є альтернативи, які роблять те, що робить CORBA, тільки краще ... або так вони стверджують. Наприклад ICE ZeroC

EDIT @fnieto звучить, щоб сказати (або натякнути), що ICE не є безкоштовним, але TAO є.

Це є неточним та оманливим .

1. ICE - це програмне забезпечення GPL, яке можна безкоштовно завантажити. Вам потрібно було заплатити за ICE лише у тому випадку, якщо ви / ваша компанія не готові жити за умовами GPL. (Або якщо вам потрібна підтримка.)
2. Я використовував ICE як приклад альтернативи CORBA. ТАО - це КОРБА. Автори ICE доводять достовірні аргументи, чому вони можуть отримати кращі показники, не відповідаючи CORBA.
3. 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 можна легко перетворити на боби CORBA за допомогою трохи конфігурації. Я підозрюю, що більшість розгортань Corba насправді були реалізовані на Java.

Що стосується популярності, я думаю, що деякі розгортання високого класу можуть залишитися протягом декількох десятиліть, але для більшості людей Корба мертва.

Існує безліч дуже сексуальних способів робити ті самі речі (за винятком вищезазначеного).

• Хмарні обчислення (веб-сервіси, масштабовані обчислення, вільне з'єднання, чергування).
• Послуги REST (веб-сервіси lite).
• Послуги SOAP (важкі веб-послуги).
• Обчислення сітки / кластера (черги, зменшення карти та подібні)

Але звичайно ваш Мілаж може змінюватися.

Очевидно, це залежить від типу сервера та міжпроцесорного зв'язку, який ви розглядаєте. І я думаю, що Стівен Сі та Кріс Кліленд дуже добре висвітлюють позитивні сторони Corba.

Наша програма використовує 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) ​​та у світі Java EJB (які можуть навіть використовувати CORBA під ковдрами) охоплюють те, що потрібно для розподілених корпоративних систем.

Я б порадив, що одним із аспектів, на який слід уважно розглянути, є ступінь асинхронної взаємодії, яка потрібна у вашій розподіленій системі. Я постулюю, що будь-яка розподілена система нетривіального масштабу потребує асинхронних комунікацій, а обрана інфраструктура повинна підтримувати асинхронну обробку, як правило, це означає черги.

Це не суперечить використанню WebServices (або, насправді, CORBA), але вказує на аспект вибору вашого продукту, який можна пропустити при початковому хвилюванні розпочатої розподіленої обробки