Порівняльний аналіз технологій CORBA і COM, Різне, Програмування, статті

Олександр Цимбал, www.interface.ru

В останні 2-3 роки різко зріс інтерес до так званих розподіленим системам. Під розподіленими системами звичайно розуміють програмні комплекси, складові частини яких функціонують на різних комп’ютерах в мережі. Ці частини взаємодіють один з одним, використовуючи ту чи іншу технологію різного рівня – від безпосереднього використання сокетів TCP / IP до технологій з високим рівнем абстракції, таких, як RMI або CORBA.

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

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

Зауважимо, що далеко не для всіх додатків вищеперелічені вимоги є суттєвими. Легко уявити розподілену систему, яка функціонує на невеликому (до 100) кількості комп’ютерів, що працюють в локальній мережі, де немає проблем з перезапуском одного або двох-трьох серверів в разі необхідності, а головними завданнями, для вирішення яких використовуються розподілені технології, є завдання використання функціональності декількох стандартних серверів додатків (наприклад, текстових процесорів, броузерів і електронних таблиць) в інтересах клієнтських задач. Необхідно мати на увазі, що термін “розподілені системи” відноситься до величезного числу завдань самого різного класу.

Даний огляд містить порівняльний аналіз двох найбільш популярних і комплексних систем створення розподілених додатків, а саме, CORBA консорціуму OMG і COM (DCOM, COM +) фірми Microsoft. Цей огляд призначений головним чином для менеджерів проектів, керівників інформаційних служб та ін, тобто для тих, кому доводиться приймати відповідальні, “стратегічні” рішення. Внаслідок цього, в ньому будуть відсутні чисто технічні аспекти обох технологій, які цікаві лише для розробників.

Крім того, при написанні огляду не ставилося завдання зробити остаточний висновок типу “… таким чином, CORBA (COM), безперечно, краще, ніж COM (CORBA) “. Пов’язано це не з модною в наш час “політкоректністю” або відсутністю у автора своєї точки зору з цього питання. Справа навіть не в тому, що існують певні труднощі з формалізацією такого порівняння – я міг би представити результати порівняльних аналізів, в яких використовуються чисельні оцінки (Бали), виставлені експертами, вагові коефіцієнти та інше, що надає звіту серйозний і вагомий вид. Справа в тому, що COM і CORBA можна порівнювати тільки з урахуванням певних припущень. Відмова від таких припущень легко дозволяє отримати який завгодно результат. Ось ці припущення:


Таким чином, головним завданням цього огляду є спроба допомогти керівнику того чи іншого рівня прийняти кваліфіковане рішення в кожному конкретному випадку. Оскільки і CORBA, і COM позиціонуються відповідно OMG і Microsoft як універсальні технології створення розподілених систем, ми будемо оцінювати і порівнювати їх саме з цієї точки зору. Передбачається, що для проекту використовується платформа Windows (в іншому випадку нема чого розглядати COM) і є достатньо коштів для закупівлі основних стандартних частин тієї чи іншої реалізації (інакше обговорення CORBA втрачає сенс).

Концептуальний фундамент технології


COM

Технологія створювалася фірмою Microsoft як засіб взаємодії додатків (у тому числі складових частин операційної системи) Windows, функціонують на одному комп’ютері, з подальшим розвитком для використання в межах локальної мережі. Головне завдання на момент створення – забезпечення технології Object Linking and Embedding (OLE 1.0). Характерно, що обмін даними між додатками (Dynamic Data Exchange, DDE) спочатку будувався не по COM-технології, а з використанням механізму повідомлень (messages). Розвиток технології йде по мірі додавання нових можливостей. Як універсальна технологія взаємодії додатків COM почав використовуватися з OLE 2.0 (1991). Концепція технології нерозривно пов’язана з її реалізацією. Поява нових можливостей – це просто поява нових бібліотек, функцій API і утиліт Windows. “Спільний знаменник технології” – двійкова структура об’єкта, хоча в даний момент існує мова опису структури об’єкта – Interface
definition Language (IDL).

CORBA

Технологія створювалася консорціумом OMG як універсальна технологія створення розподілених систем в гетерогенних середовищах. OMG являє собою некомерційну організацію, що є співдружністю розробників програмного забезпечення та його споживачів, що об’єднали свої зусилля для створення специфікацій цієї технології. На даний момент в OMG складається більше 800 членів, включаючи всіх скільки-небудь серйозних виробників програмного забезпечення (і навіть c недавнього часу Microsoft). Перша специфікація CORBA з’явилася в 1991 р. Нові можливості офіційно вважаються доданими в CORBA в момент затвердження відповідної специфікації. Як правило, в розробці специфікації беруть участь найбільші фахівці в даній області. Розробка реалізації – завдання конкретної фірми. Зазвичай від затвердження специфікації до появи високоякісної реалізації проходить досить багато часу – іноді кілька років. “Спільний знаменник” технології – оголошення на мові IDL, який є “серцем” CORBA з моменту її появи. (Існують три різні мови описів з одним і тією ж назвою – OSF IDL, Microsoft IDL і OMG IDL).

Висновки

Технологія CORBA носить істотно більш загальний і універсальний характер, ніж COM, що закладено в її фундаменті. Випередження розробки специфікацій (у порівнянні з реалізаціями) дозволяє домогтися більш зв’язковий, цілісної і гармонійної системи. З іншого боку, при розробці реального проекту потрібно попередньо переконатися, що високоякісна реалізація того чи іншого сервісу CORBA вже доступна (джерелами проблем можуть служити, наприклад, Persistence Service і Security Service).

Комплексність системи

COM

COM містить все необхідне, що потрібно для побудови розподіленої системи: технологію віддаленого виклику методів (як статичних, так і динамічних), бази даних серверних об’єктів (бібліотеки типів), які можуть бути імпортовані для аналізу структури серверів COM, універсальний протокол обміну між клієнтами і серверами, специфікації так званих “складених документів” (ActiveDoc), об’єктний монітор транзакцій (MTS), компонентну модель (ActiveX) та ін Всі складові частини прекрасно відповідають один одному в рамках моделі COM. Унікальною можливістю COM є універсальна технологія доступу до баз даних – OLE DB / ADO.

CORBA

На даний момент CORBA не має своєї власної компонентної моделі; робота над нею почалася в 1998 р. і ще не завершена. Це головний серйозний недолік. Правда, він кілька компенсується наявністю заснованої на CORBA компонентної моделлю Enterprise JavaBeans, так що програмісти на Java знаходяться в привілейованому становищі. Все інше, що присутній в COM, є і в CORBA, і навіть більше того – за винятком універсальної технології доступу до БД. Знову-таки, Java-програмісти мають перевагу і тут – за рахунок наявності спільної для Java технології доступу до даних JDBC.

Висновки

На даний момент COM більш закінчена система, але на більш низькому рівні і при істотно більшій кількості обмежень, визначених самою концепцією системи.

Використовувані мови програмування

COM

Потенційно COM можуть підтримувати самі різні мови програмування – Все вирішує фірма Microsoft. Додавання деяких розширень або експертів (Wizard) в систему розробки дозволить використовувати для роботи з COM будь мова програмування. На даний момент найбільш широко використовуються Visual Basic, C + + і Delphi. Серйозні проблеми виникли при використання мови, на який покладалися особливі надії – з Java. Microsoft домоглася прекрасного взаємодії Java з COM, але досягнуто це було шляхом відмови від переносимості таких Java-програм на інші віртуальні машини Java. Не випадково продукт фірми Microsoft – J + + – не містить у назві “Java”. Взагалі, рівень стандартизації для COM досить слабкий. Це не обов’язково потрібно розглядати як недолік – зрештою, мова C років п’ятнадцять прекрасно обходився без формального стандарту.

CORBA

Під “стандартом” стосовно CORBA розуміється те, що офіційно затверджено консорціумом OMG. Треба сказати, що це дуже високий рівень “Легітимності”, так як авторитет OMG в комп’ютерному світі надзвичайно високий. На даний момент стандартизовано відображення мови IDL на 6 мов програмування – Ada, C, C + +, Cobol, Java і Smalltalk. Існують також відображення на Pascal (точніше, Delphi), Perl, Python і ще десяток мов.

Найбільш використовуваними мовами зараз є Java (внаслідок прекрасного взаємодії Java-технологій, особливо JDBC, RMI, JNDI і EJB, з CORBA), і C + + – як найефективніший, потужний і поширений мова комп’ютерної індустрії.

Висновки

Обидві технології не відчувають особливих проблем з точки зору взаємодії з мовами програмування. Деякі переваги має CORBA – за рахунок більш суворої стандартизації і більше багатого вибору доступних засобів розробки.

Рівень абстракції

COM

COM реалізує високий рівень абстракції – всі питання низького рівня, такі, як взаємодії з операційною системою або мережевими засобами, “Заховані” від прикладного програміста.

CORBA

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

Висновки

Обидві технології реалізують приблизно однаковий і досить високий рівень абстракцій.

Підтримка компонентної моделі

COM

Компонентна модель Microsoft, що базується на COM-технології, в основі має двійкову структуру об’єктів. Це не викликає жодних проблем при орієнтації на одну платформу і операційну систему. Безумовним достоїнством такої моделі є простота створення компонентів з використанням різних мов програмування. З іншого боку, така компонентна модель неминуче пов’язана з певними обмеженнями та недоліками. Одним з найбільш серйозних недоліків є те, що її не можна, строго кажучи, назвати об’єктно-орієнтованої.

CORBA

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

Висновки

Це та область, де COM поки має суттєві переваги порівняно з CORBA. C іншого боку, при розробці реальних проектів використання на стороні сервера компонентів Enterprise JavaBeans, побудованих поверх інфраструктури CORBA, надає розробнику значні переваги в порівнянні з компонентами ActiveX.

Універсальний протокол обміну

COM

Передача даних між клієнтом і сервером заснована на наборі типів, які називаються OLE Automation types. В принципі, схема маршалинга (в тому числі типи переданих даних) визначається парою стандартних інтерфейсів COM. Реалізувавши по-своєму деякі з методів цих інтерфейсів, можна визначити свою схему маршалинга. Втім, це нетривіальна задача, і зазвичай розробники використовують вже готову стандартну реалізацію. Упаковка даних та їх передача можуть бути реалізовані поверх різних мережевих протоколів.

CORBA

CORBA значно суворіше і формально підходить до механізмів обміну і передачі даних. Визначено протокол CORBA (General Inter-ORB Protocol, GIOP) – і його реалізація на базі протоколу TCP / IP (Internet Inter-ORB Protocol, IIOP). CORBA здатна передавати дані різних типів, включаючи структури (Struct) та об’єднання (union), у тому числі містять рекурсивні визначення. Передбачена система опису і контролю типів – як на рівні IDL-декларацій, так і динамічна. Для кожної мови використовується своє відображення даних IDL. У версії 2.3 з’явився новий, запозичений з RMI механізм передачі об’єктів CORBA – так звана “передача за значенням (objects-by-value)”. У попередніх версіях CORBA при виклику віддалених методів об’єкти можна було передавати тільки за посиланням.

Висновки

CORBA надає значно більше можливостей, і ці можливості строго формалізовані – В іншому випадку було б неможливо забезпечити спільну роботу різних засобів від різних виробників програмного забезпечення.

Підтримка з боку різних виробників і відкритість

COM

На даний момент офіційним “хранителем стандарту” технології COM є консорціум Open Group, хоча “головним гравцем на цьому полі” є, звичайно ж, Microsoft. Підтримкою технології COM займаються багато невеликі фірми – деякі з них створюють компоненти ActiveX, деякі – як Software AG – займаються перенесенням фрагментів COM на інші платформи, деякі – Як Borland – створюють RAD-інструменти, засновані в тому числі і на COM. У будь-якому разі, тільки Microsoft вирішує, яка частина технології і в якому вигляді потрапляє з лабораторій Microsoft у відкриті специфікації.

CORBA

Ситуація з CORBA зовсім інша. CORBA є результатом спільних зусиль величезного числа фірм, серед яких Sun, Oracle, IBM, Netscape / AOL, DEC / Compaq, JavaSoft, Borland / Visigenic (зараз у зв’язку зі злиттям Inprise і Corel прийнято рішення про відновлення імені Visigenic), BEA, Iona і багато інших. Можна сказати, що всі виробники програмного забезпечення, яке має функціонувати на різних платформах і під управлінням різних операційних систем, вибрали CORBA як стандартну інфраструктуру створення програмних продуктів. Природно, всі специфікації CORBA є повністю відкритими. В таборі прихильників CORBA проглядається чітка тенденція до тісної взаємодії і деякої уніфікації використовуваних технологій (як приклад можна привести відмова Sun і ORACLE від створення власного ORB та ліцензування Visigenic VisiBroker).

Висновки

COM і CORBA мають зовсім різний рівень відкритості та підтримки з боку провідних фірм в комп’ютерній індустрії.

Розвиненість сервісної частини


COM

COM надає мінімальний набір абсолютно необхідних коштів – кодогенератори c IDL, утиліти управління доступом (dcomcnfg) і ін Як правило, розробники користуються тими чи іншими інструментами, вбудованими в конкретні засоби розробки (прикладом може служить утиліта роботи з бібліотеками типів або експерт створення ActiveX-об’єктів в Borland Delphi / C + +
Builder).

CORBA

CORBA має дуже розвинену сервісну частину; наприклад, тільки для пошуку серверних об’єктів за різними критеріями можна використовувати 4 різних сервісу CORBA. Крім того, OMG прагне до максимальної стандартизації допоміжних можливостей CORBA.

Висновки

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

Самодокументірованіе системи

COM

COM предусіатрівает можливість створення локальної бази даних, що зберігає інформацію про COM-об’єктах, їх інтерфейсах, методах і т.д. для сервера додатків COM. Така база даних називається бібліотекою типів (type library). Використання бібліотек типів не є обов’язковим для OLE, хоча це необхідно в технології ActiveX. Для отримання інформації з type library користувач повинен явно імпортувати її, для чого необхідно вибрати відповідну запис реєстру Windows на конкретному комп’ютері.

CORBA

CORBA має аналог бібліотеки типів COM – це так званий Репозитарій Інтерфейсів (Interface Repository). Щоб оцінити принципову різницю в підході CORBA в порівнянні з COM, досить сказати, що Репозитарій Інтерфейсів CORBA сам представляє з себе об’єкт CORBA з усіма витікаючими з цього можливостями. Крім репозитарія Інтерфейсів, CORBA використовує Репозитарій Реалізацій (Implementation Repository), який представляє з себе базу даних, яка містить інформацію про сервери додатків CORBA.

Висновки

Засоби інтроспекції (самодокументрованія) CORBA значно більш розвинені, потужні, гнучкі і універсальні, ніж аналогічні засоби COM. CORBA-програмісти отримують додаткові переваги в порівнянні зі своїми колегами, що працюють з COM, при використанні Java (Java-технології дуже тісно пов’язані з CORBA). Пов’язано це з тим, що Java передбачає свій рівень інтроспекції, додатковий по відношенню до CORBA.

Технологія та опис проекту

COM

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

CORBA

Проект з використанням CORBA завжди починається з написання IDL-специфікацій (Особливий випадок – використання Java, коли в принципі можливо генерувати стандартний код CORBA безпосередньо на базі класів Java, хоча навряд чи це розумно для великих проектів.). Ці IDL-специфікації прекрасно відображають суть виконуваних дій з точки зору функціонування розподіленої системи. Синтаксис OMG IDL дуже схожий на синтаксис С + + (включаючи ті ж самі директиви препроцесора). Таким чином, IDL-специфікації можуть з успіхом використовуватися як частина документації проекту.

Висновки

Описи OMG IDL більш достовірні й істотно більш наочні, ніж описи Microsoft IDL, в ролі суттєвої частини специфікації проекту.

Види об’єктів


COM

Об’єкти COM завжди розглядалися (і продовжують розглядатися) як серверні об’єкти, які просто реалізують той чи інший набір методів. Різні об’єкти, що реалізують один і той же інтерфейс і створені за допомогою звернення до однієї і тієї ж фабриці класів, не відрізняються один від одного. Об’єктна посилання, яку отримує клієнт, є дороговказом на інтерфейс і не містить інформації про конкретний об’єкт. Іншими словами, COM оперує об’єктами, які не мають стану. У загальному випадку, якщо клієнт, використовуючи одну і ту ж об’єктну посилання, в циклі викликав десять разів один і той же метод, він не може бути впевнений, що він звернувся до одного, а не до двох, п’яти або десяти різних об’єктів. Природно, об’єкти без стану не має сенсу зберігати довше, ніж існує сервер додатків, в якому вони були створені. Такі об’єкти стосовно розподіленим системам називаються тимчасовими (transient). COM-об’єкт – це конкретна мінлива C + +, Visual Basic або Pascal, що знаходиться в оперативній пам’яті і існуюча, поки працює створив її сервер додатків. Він може бути створена за запиту клієнта або заздалегідь (наприклад, за допомогою MTS). При роботі з COM зіставити з об’єктом будь стан – завдання прикладного програміста. Це можна зробити, використовуючи певний режим створення об’єктів (вибравши модель управління потоками), зберігати стан об’єкта на стороні клієнта (Якщо це можливо) або використовувати так звані монікери, які можна розглядати як узагальнення поняття ключа запису в базі даних. Кожен з цих способів має дуже суттєві обмеження.

CORBA

Поняття “об’єкта” в CORBA принципово відрізняється від свого COM-аналога. Об’єкт CORBA не є змінною мови програмування і в загальному випадку час його існування не пов’язано з часом роботи серверних або клієнтських додатків. СORBA-об’єкт не займає ніяких ресурсів комп’ютера – оперативної пам’яті, мережевих ресурсів і т.п. Ці ресурси займає тільки так званий “Сервант” (servant), який є “інкарнацією” одного або декількох CORBA-об’єктів. Саме сервант є змінною мови програмування. Поки не існує сервант, співставлений з конкретним об’єктом CORBA, цей об’єкт не може обслуговувати виклики клієнтів, але, тим не менш, він існує. Результатом створення об’єкта (при цьому зовсім не обов’язково при цьому створюється і зіставляється з цим об’єктом відповідний сервант!) є так звана “об’єктна посилання” CORBA. Об’єктна посилання зіставлена з цим, і тільки з цим об’єктом, і це зіставлення залишається коректним протягом усього терміну існування CORBA-об’єкта (може бути, протягом кількох років). Об’єктна посилання CORBA правильно інтерпретується ORB’амі від будь-якого виробника програмного забезпечення. Після знищення CORBA-об’єкта всі об’єктні посилання на нього назавжди втрачають сенс. За допомогою об’єктної посилання клієнт викликає методи об’єкта, при цьому інкарнації цього об’єкта можуть бути різні серванти (не більше одного одночасно), які фізично можуть знаходитися навіть на різних комп’ютерах.

Висновки

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

Способи взаємодії

COM

COM підтримує як статичний, так і динамічний спосіб взимодействия клієнта і сервера. Під динамічним способом розуміється підхід, коли перевірка, чи реалізує сервер потрібний метод, а також всі необхідні дії по виконанню віддаленого виклику виконуються на етапі роботи клієнтського додатку, а неетапі його компіляції. При статичному виклику ці дії виконуються саме на етапі компіляції. Зрозуміло, статичний спосіб переважніше у всіх відношеннях (коли він можливий взагалі). Для його використання сервер COM повинен створити й експортувати бібліотеку типів, яка потім імпортується клієнтом і використовується як частина клієнтського процесу.

CORBA

CORBA також підтримує статичний і динамічний спосіб організації віддалених викликів.

Висновки

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

Продуктивність

COM

COM демонструє дуже високу продуктивність. Читач, який цікавиться цим питанням, знайде велику кількість дуже цікавої інформації в прекрасної книзі R. Orfali і D. Harkey “Client / server Programming with Java and CORBA “, second edition, Wiley, 1998. Зрозуміло, продуктивність істотно залежить від того, який спосіб – статичний або динамічний – Ви використовуєте.

CORBA

Для коректного порівняння CORBA і COM з точки зору продуктивності необхідно скласти цілу систему тестів. Крім того, необхідно врахувати вплив використання тієї чи іншої мови програмування. На основі інформації, що приводиться Orfali і Harkey, а також результатів невеликого порівняльного тестування, проведеного самим автором огляду (використовувався Borland C + + Builder 4.0 і VisiBroker 3.3 для C + +), можна сказати, що CORBA демонструє навіть дещо вищу продуктивність. Ще раз повторимося: продуктивність дуже сильно залежить від кількості і типів аргументів методів (не забувайте, що їх потрібно упакувати і передати по мережі, а потім розпакувати), від вибраної моделі управління потоками, від використовуваних мов програмування (клієнт і сервер при цьому не обов’язково повинні бути написані на одній мові), від конкретної реалізації CORBA і багатьох інших факторів.

Висновки

І COM, і CORBA демонструють приблизно однакову (і дуже високу) продуктивність. Для CORBA говорити про конкретні цифри можна тільки для конкретної реалізації. В якості прикладу наведемо такий факт: Inprise / Visigenic Visibroker прозорим для розробника чином працює по-різному в залежності від того, чи знаходяться клієнтський і серверний об’єкт в одному адресному просторі, в різних адресних просторах, але на одному комп’ютері, або на різних комп’ютерах. Продуктивність при цьому може відрізняється на порядок.

Масштабованість

COM

Проблеми забезпечення масштабованості не були закладені в фундамент технології, якщо не вважати орієнтацію на використання тільки об’єктів без стану. Суттєвою перешкодою для створення масштабованих програми є дуже жорстка зв’язок між клієнтом і сервером (об’єкт, тобто сукупність ресурсів на сервері, не може бути видалений, поки клієнт явно не вкаже, що цей об’єкт більше не потрібний). У реальних проектах необхідно управляти станом об’єктів, і це ускладнює створення масштабованих програм, так як це обов’язок не COM, а програміста. Сильною стороною COM є гнучка модель управління потоками. Основним інструментом, що підвищує рівень масштабованості COM-систем, є MTS.

CORBA

На відміну від COM, CORBA із самого початку розглядали як технологія створення масштабованих систем. Поділ власне об’єктів CORBA і їх сервантів, схеми відповідності між ними, характеристики об’єктних адаптерів, моделі управління потоками і з’єднаннями, схеми активації серверів додатків, універсальні рішення щодо збереження стану об’єктів, автоматичне управління контекстом транзакцій і безпеки – все це дуже сприяє вирішення даної проблеми.

Висновки

Масштабованість системи багато в чому залежить від якості розробки проекту, продуманості прийнятих рішень і кваліфікації менеджерів проекту і розробників. При порівнянні технологій можна говорити про передумови, які сприяють (або, навпаки, перешкоджають) досягненню потрібних вимог. За інших рівних умов CORBA має величезні переваги по cравненію з COM.

Стійкість до збоїв

COM

Стійкість до збоїв COM-систем знаходиться на невисокому рівні, в тому числі через уже згаданої надмірно жорсткої прив’язки клієнтів і серверів. Основним засобом забезпечення стійкості до збоїв (воно ж засіб управління навантаженням серверів) є диспетчер, який дозволяє перенаправляти виклики клієнта на різні сервера додатків COM. Не надто сприяє відмовостійкості системи та необхідність виконання “вручну” великого кількості дій з управління транзакціями.

CORBA

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

Висновки

Проблема забезпечення стійкості до збоїв, так само як і проблеми забезпечення масштабованості, не розглядалися як першочергові при розробці концепції COM. З CORBA ситуація обстоит багато в чому краще, але проблеми залишаються і тут. Обидві технології не мають (або майже не мають) стандарних засобів забезпечення стійкості до збоїв. Такі компоненти, як VisiBroker Smart Agents, не є стандартним засобом CORBA (хоча вони і здатні вирішити багато проблем при роботі з реальними проектами.)

Управління транзакціями

COM

Монітором транзакції в COM є MTS. Сервер додатків COM повинен бути написаний в спеціальному стилі для того, щоб мати можливість взаємодіяти з MTS (такий сервер додатків повинен бути реалізований у вигляді DLL). MTS дозволяє досить гнучко управляти режимами виконання транзакцій в системі і підтримує двофазне завершення транзакцій. Одним з істотних недоліків схеми управління транзакціями COM є необхідність явної передачі контексту транзакції в якості аргументу при виклику віддалених методів. Така схема не є ні ефективною, ні гарантує від помилок (Особливо при залученні в транзакцію великої кількості об’єктів).

CORBA

Управління транзакціями бере на себе так званий Сервіс Управління Транзакціями CORBA (Object Transaction Service, OTS). Він є істотно більш гнучкою, продуманою і формалізованої системою, ніж MTS, і містить все необхідне в рамках CORBA-моделі. Сервер додатків CORBA та Сервіс транзакцій запускаються і працюють незалежно один від одного. Важливою особливістю CORBA є тісна взаємодія OTS і ORB, що забезпечує автоматичне поширення контексту транзакцій в многопоточной розподіленому середовищі. Специфікація CORBA передбачає (необов’язкову) підтримку вкладених транзакцій.

Висновки

На рівні специфікацій Сервіс транзакцій CORBA має певні переваги перед MTS. На практиці для реалізації цих переваг потрібно зробити певні дії. Особливо це стосується двофазного підтвердження транзакцій при роботі з гетерогенними базами даних. Наприклад, для реалізації такої схеми при роботі з Java необхідно мати спеціальні JDBC-драйвера, які, наскільки мені відомо, зараз не дуже доступні для широкого кола баз даних. В цьому плані COM має серйозні переваги за рахунок взаємодії MTS зі стандартною технологією доступу до баз даних OLE DB / ADO.

Забезпечення безпеки

COM

На даний момент система безпеки COM базується на системі безпеки Windows NT / Windows 2000; крім того, передбачений захист даних при їх передачі з використанням Socket Security Layer (SSL). Окрема проблема – Забезпечення безпеки при передачі компонентів ActiveX з використанням протоколу HTTP. Тут використовується система електронних підписів, ліцензій і т.п. – Кажучи спрощено, клієнт виконує код компонента, який прийшов з “правильного” сервера.

CORBA

З CORBA справи йдуть складніше – головним чином, в силу того, що ставилася завдання створити універсальну систему безпеки, яка могла б використовувати всі основні існуючі в цій галузі технології. Робота над Сервісом Безпеки (Security Service) тривала протягом 2 років, і її специфікація була прийнята в 1996 р. Вона містить близько 250 сторінок. Вона дозволяє забезпечити рівень безпеки B2 (рівень, близький до вищого рівня захисту, який використовується в державних установах). Передбачена ідентифікація користувача, списки прав доступу до ресурсів, система аудиту та багато іншого. Особливо приємно, що розробник не повинен явно взаємодіяти з цим сервісом – це завдання для ORB. Основне навантаження покладено на системних адміністраторів. Все це прекрасно, але існує одна невелика проблема – Де взяти повномасштабну, високоякісну реалізацію цього сервісу? Такі реалізації існують (Gradient, Concept-5), але їх використання обмежено за межами США. Сервіс безпеки від Borland / Visigenic в цьому році ще не з’явиться (хоча робота над ним йде).

Висновки

На даний момент для реальних проектів для обох технологій використовуються подібні рішення в галузі забезпечення безпеки (ідентифікація на рівні операційної системи та кодування інформації за допомогою SSL). Природно, можливі варіанти. Потенційно CORBA надає істотно більші можливості – проблеми тут організаційного, а не концептуального плану.

Взаємодія з Internet

COM

Основою взаємодії через Internet при роботі з COM є розширення можливостей протоколу HTTP, виконані Microsoft. Броузери Microsoft (Internet Explorer 3 і вище) дозволяють виконувати код ActiveX-компонентів, отриманих з Web-серверів. Крім того, URL доступні при використанні COM – З ними можуть працювати монікери.

CORBA

Специфікації CORBA не обумовлюють використання Internet в якості особливого випадку. Інтеграція CORBA і Internet виконується природним чином – За рахунок використання протоколу IIOP, побудованого поверх TCP / IP. URL-імена можуть бути використані в якості імен для Служби іменування CORBA. На практиці виробники програмного забезпечення надають розширення CORBA, що спрощують роботу з Internet (VisiBroker URL Naming Service) або вирішальні ті чи інші проблеми – наприклад, “обхід” обмежень, що накладаються на аплети Java, використовуваних як CORBA-клієнтів (наприклад, Borland / Visigenic
GateKeeper).

Висновки

CORBA (особливо при використання Java) без будь-яких проблем може бути інтегрована з Internet. Взаємодія COM і Internet засновано на використанні ActiveX і вимагає використання тільки броузерів, що підтримують тег Microsoft. Непрямим чином проблеми спільної роботи COM і Internet можуть виникнути через несумісність віртуальної машини Java Microsoft з іншими віртуальними машинами.

Швидкість розробки систем

COM

Швидкість розробки COM-систем може бути дуже високою за рахунок інтенсивного використання компонентної моделі ActiveX, а також універсальних підходів, таких, як OLE DB. Не складає особливих труднощів створення Internet-додатків з оглядачем Microsoft в якості клієнтського додатку.

CORBA

Швидкість розробки CORBA-систем сильно залежить від використовуваної технології. Напевно, максимально ефективним способом створення розподілених систем зараз є використання Java-технологій, заснованих на CORBA – Enterprise JavaBeans і так званих Application Server’ов, наприклад, BEA WebLogic і Inprise Application Server. Використання цих технологій дозволяє надзвичайно швидко створювати високоефективні, масштабовані, транзакційні сервера додатків. Клієнтська частина таких систем може бути написана на будь-якій мові програмування, що підтримує CORBA.

Висновки

За інших рівних умов CORBA дозволяє створювати розподілені системи швидше, ніж COM, за рахунок більшої функціональності middleware і, відповідно, меншою навантаження на прикладного розробника.

Простота використання

COM

COM дуже простий для простих невеликих додатків і надзвичайно складний як інструмент створення комплексних систем. Він містить велику кількість “Вузьких” місць – недостатньо гнучку стандартну схему маршалинга, відсутність стану об’єктів, низька стійкість до збоїв. Технологія не є об’єктно-орієнтованої в класичному розумінні цього слова, що в загальному разі не сприяє простоті її використання. Перевагою технології є комплексність та універсальність підходів в рамках COM-моделі.

CORBA

Складність CORBA полягає в її величезних можливостях. Програмісту необхідно знати велику кількість інтерфейсів з різних сервісів CORBA, правильно використовувати можливості об’єктних адаптерів і багато іншого. Оскільки CORBA використовує різні схеми відображення IDL на різні мови програмування, то програмісту в загальному випадку треба знати їх особливості для 2-3 найбільш широко використовуваних мов – у першу чергу, C + + і Java.

Висновки

Об’єктивно CORBA складніше за рахунок того, що вона призначена для рішення істотно складніших завдань, ніж COM. При розробці реальних проектів потрібно мати на увазі, що розподіл “інтелектуальної” навантаження серед учасників розробки для COM і CORBA дещо відрізняється: у разі COM потрібні більш кваліфіковані (але більш вузько спеціалізовані) програмісти, а для CORBA можна задіяти програмістів середнього рівня, але надзвичайно важливо мати кваліфікованих архітектора проекту та керівників груп програмістів.

Взаємодія з іншими технологіями

COM

COM є досить замкнутої і “самодостатньою” системою. Останнім час Microsoft тісно взаємодіє з OMG на базі створення специфікації моста “COM-CORBA”. Внаслідок істотних відмінностей в можливостях, не представляє праці імітувати поведінку COM-об’єкта як CORBA-об’єкта, але не навпаки.

CORBA

CORBA як технологія в даний момент (до створення специфікацій, а потім і реалізацій своєї компонентної моделі) є скоріше інфраструктурою для створення розподілених систем. Не дивно, що в цій якості вона активно взаємодіє з іншими технологіями – в першу чергу з RMI і Enterprise JavaBeans. CORBA дуже тісно – на рівні протоколу ESIOP – Взаємодіє з широко використовуваною, але морально застарілою технологією
DCE.

Висновки

CORBA є істотно більш відкритою, універсальною і гнучкою системою, ніж COM. І COM, і CORBA здатні тісно та ефективно взаємодіяти зі стандартними засобами забезпечення безпеки.

Загальні висновки

Незважаючи на зовнішню схожість, що викликано спільністю розв’язуваних задач, між COM і CORBA, мабуть, більше відмінностей, ніж подібності. У більшості випадків або недоцільно використовувати CORBA (для невеликих і простих проектів під Windows просто через відносно високих витрат на придбання програмного забезпечення, ліцензій тощо), або практично неможливо використовувати COM (для складних, масштабованих, високонадійних проектів або просто при роботі в гетерогенних середовищах, а не тільки в Windows). Windows-додатки, орієнтовані на взаємодію з Microsoft Office, завжди будуть використовувати COM; проекти з використанням Java і будь-яких Java-технологій (крім Microsoft J + +), як то кажуть, “сам бог велів” будувати на основі CORBA. У багатьох випадках вибір технології диктує вибір тієї чи іншої частини проекту: якщо ви плануєте працювати, наприклад, з ORACLE 8i, то, безумовно, набагато краще орієнтуватися на CORBA. Область, де ці технології реально конкурують, на мій погляд, дуже невелика.

Як неважко помітити, автор цього огляду є прихильником CORBA, чого і бажає всім своїм читачам.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*