4.4.2. Об'єктні моделі

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

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

У CORBA інтерфейс об’єкту задається за допомогою визначеної групою OMG мови опису інтерфейсів (Interface Definition Language, IDL). Тип об’єкту — це тип його інтерфейсу. Інтерфейс ідентифікується іменем, представленим ланцюжком символів. У моделі CORBA визначений базовий тип для всіх об'єктів — CORBA::Object. Об'єкт підтримує тип свого безпосереднього інтерфейсу і, за принципом спадкування, всі його базові типи.

У СОМ об'єкт характеризується своїм класом. Клас — це реалізація деякої множини інтерфейсів. Множинне спадкування інтерфейсів не підтримується, натомість цей об'єкт може мати кілька інтерфейсів одночасно. У СОМ інтерфейс може визначатися шляхом успадкування іншого інтерфейсу. Для всіх інтерфейсів існує базовий інтерфейс — IUknown. Щоб перейти від інтерфейсу базового типу до успадкованого інтерфейсу або від одного з інтерфейсів об’єкту до іншого, клієнт має викликати метод QueryInterface, визначений у базовому інтерфейсі IUknown. Для ідентифікації класів та інтерфейсів СОМ використовуються ті самі універсальні унікальні ідентифікатори (UUID), що прийняті для ідентифікації інтерфейсів у специфікації DCE RPC. Можна застосовувати і символьні позначення інтерфейсу, але потім вони мають бути трансльовані в належний ідентифікатор UUID. Об'єкт у СОМ — це екземпляр класу. Клієнт одержує доступ до об’єкту за допомогою вказівника на один з його інтерфейсів (interface pointer).

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

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

Розходження між мовами IDL за версією OMG і Microsoft — одне з найбільш значних для двох об'єктних моделей. У CORBA мова опису інтерфейсів — найважливіша частина архітектури, основа схеми інтеграції об'єктів. Всі інтерфейси і типи даних визначаються на IDL. Різні мови програмування підтримуються завдяки заданим відображенням між описам типів даних на IDL у відповідні визначення конкретною мовою. Ці відображення реалізуються компілятором IDL, що генерує вихідні коди потрібною мовою. Насьогодні підтримується відображення в С, С++, SmallTalk, Ada95, Visual Basic, Кобол Cobol і Java. Сам IDL синтаксично нагадує декларації типів у С++, але аж ніяк не ідентичний цій мові.

Якщо в моделі інтеграції об'єктів CORBA мова IDL відіграє фундаментальну роль, то Microsoft IDL (MIDL) — лише один з можливих способів визначення інтерфейсів об’єкту. MIDL — не більш ніж корисний інструментарій для написання інтерфейсів. На відміну від CORBA IDL, MIDL не визначає загального набору типів даних, доступних різним мовам програмування. На MIDL можна визначити інтерфейси і типи даних, що зрозуміють програми на С і С++, але для Visual Basic і Java цього вже зробити не можна.

Обидві об'єктні моделі передбачають ситуацію, коли у клієнта вже у процесі виконання програми виникає потреба використовувати ті чи інші об'єкти. У цьому випадку в клієнта не буде скомпільованих команд для викликання методів, оскільки інтерфейс об’єкту не був відомий на етапі компіляції. Тому йому будуть потрібні спеціальні інтерфейси динамічного виклику. У CORBA механізм DII (Dynamic Invocation Interface) спирається на Interface Repositоry, що містить написані на IDL визначення типів даних і інтерфейсів. Конкретна реалізація такого репозитарію залежить від розроблювача брокера об'єктних запитів ORB. Крім динамічних викликів, репозитарій інтерфейсів у CORBA може використовуватися для систематичної організації і збереження даних визначеного проекту. У СОМ ті самі функції виконують інтерфейс Dispatch і бібліотеки типів Type Libraries.

CORBA і СОМ абсолютно по-різному підходять до проблем ідентифікації (identity) об'єктів і їхнього збереження в довгостроковій пам'яті (persistance). CORBA вводить поняття об'єктного посилання (object reference), що унікальним чином ідентифікує об'єкт у мережі. Тим самим екземпляру об’єкту дається право на існування протягом деякого часу. Об'єкти можуть активуватися, зберігатися в довгострокій пам'яті, пізніше знову реактивізуватися і дезактивуватися, і при цьому об'єктне посилання буде вказувати весь час на те саме конкретне втілення об’єкту. Для особливо значущих об'єктів, призначених для тривалого використання, об'єктні посилання можуть інтегруватися зі службою чи каталогами служби імен.

У СОМ поняття об'єктного посилання відсутнє. Найближчий аналог — це механізм moniker («прізвисько»), що забезпечує перетворення символьного імені об’єкту у вказівник інтерфейсу.