4.4.4. Формальний опис архітектури і проблеми реалізації

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

CORBA визначається за допомогою формалізованої специфікації, написаної мовою IDL. Появі чергової версії передує чітко організований процес адаптації нового стандарту, що звичайно завершується швидше, ніж аналогічні процедури в ISO. Як результат, CORBA може похвалитися значною кількістю реалізацій. Первісний варіант специфікації з'явився у 1991 році, і вже у 1992-му був випущений комерційний продукт — брокер об'єктних запитів DEC ObjectBroker.

Специфікація CORBA — це строго організований опис, не обтяжений деталями реалізації, що залишаються для розроблювачів конкретних продуктів. Передбаченість реалізацій від різних постачальників, з одного боку, стимулює конкуренцію і, як наслідок, удосконалення технології, але з іншого боку — породжує проблеми несумісності різнорідних продуктів. Так, специфікація CORBA включає визначення Basic Object Adapter, що забезпечує доступ до сервисів брокера об'єктних запитів з боку сервера об’єкту. Ця частина специфікації виявилася занадто загальною, так що розроблювачі одержали занадто великий ступінь свободи в реалізації власних об'єктних адаптерів. У підсумку, часто виявлялося неможливо перенести серверні компоненти архітектури з одного ORB на інший. У новій специфікації об'єктного адаптера (Portable Object Adapter, POA) виправлено цей недолік.

Різні брокери запитів взаємодіють між собою за протоколом General Inter ORB Protocol (GIOP). У зв'язку з активним перенесенням у середовище Web критично важливих корпоративних застосунків найбільший інтерес викликає реалізація протоколу GIOP на базі TCP/IP — протокол Internet Inter ORB Protocol (IIOP).

Специфікація СОМ розроблена Microsoft, належить Microsoft і контролюється тільки Microsoft. На відміну від CORBA – це не настільки строго організований документ. Деталей в описі досить, однак вони не завжди доречні. Так, наприклад, у специфікації докладно визначається модель Connectable Objects, що лежить в основі механізму обробки подій у Visual Basic, але не має явної підтримки в самій СОМ. А розділ опису бібліотеки типів, необхідного компонента для динамічного виклику методів, не містить практично ніяких подробиць реалізації, і розроблювачу доводиться шукати їх в інших джерелах, наприклад, у документації щодо SDK для ОС Windows.

Донедавна реалізації СОМ належали тільки самій Microsoft. І це можна вважати її перевагою, оскільки не виникало проблем несумісності продуктів різних постачальників. Зараз це питання може стати актуальним, якщо Microsoft дійсно зацікавлена в реалізації СОМ іншими виробниками. Засумніватися ж у такій зацікавленості змушує її удосконалена версія, СОМ+, що вводить у цю об'єктну модель ряд важливих функцій і служб, доступних тільки на платформах Microsoft.

Отже, СОМ не має такої широкої підтримки як CORBA, це рішення однієї компанії для одного сімейства операційних систем. Однак звернемо увагу на те, що цією компанією є Microsoft, а таким сімейством операційних систем – Windows.

Обидві специфікації поступово усе більше і більше розростаються. Так, постійно росте число підтримуваних API-інтерфейсів в архітектурі СОМ. У CORBA стає все більше IDL-інтерфейсів, що описують нові служби. І це ускладнює завдання підтримки документів у погодженому і зручному для використання вигляді, і для однієї компанії, як у випадку СОМ, і тим більше для цілого конгломерату організацій, який являє собою Консорціум OMG.

У CORBA деякі служби, наприклад, Collections і Queries, перекриваються по реалізованих функціях, і існує відразу три стандарти, що описують базові концепції метамоделі — Object Management Architecture, Meta-Object Facility і Business Object Facility.