1. Вступ 3
2. Огляд COM-технології 3
2.1. Склад COM-об'єкта 4
2.2. Інтерфейси 4
2.3. Властивості COM-об'єктів 6
2.4. COM-сервери 7
2.5. Механізм маршаллінга 7
2.6. Фабрики класів 8
2.7. Бібліотеки типів 9
2.8. Диспетчерський інтерфейс 10
2.9. Прив'язка ідентифікаторів 11
2.10. Інтерфейси користувача 11
2.11. Подвійні інтерфейси 12
3. Розширення COM 12
3.1. OLE/Active document 13
3.2. Automation 13
3.3. ActiveX control 14
3.4. Взаємодія між візуальні об'єкти 14
3.5. OPC 14
4. Засоби розробки COM-додатків 15
Введення
У даній роботі коротко розглянута технологія COM, яка в даний час широко застосовується при розробці програмного забезпечення, інтеграції програмних продуктів в єдині інформаційні системи. Метою розробки COM-технології було прагнення до інтеграції програмного забезпечення через стандартизацію механізмів взаємодії програмних модулів між собою. На основі цієї технології, яка є масштабується, розроблена величезна кількість технологій, які стали стандартами у різноманітних сферах застосування інформаційних технологій - від управління технологічними процесами в промисловості до домашніх персональних комп'ютерів. Масове застосування COM частково пов'язане з потужністю її розробника, фірми Microsoft. З цим доводиться рахуватися, і кожний програмний продукт, випущений під платформу
Windows, для досягнення комерційного успіху зобов'язаний відповідати інновацій Microsoft.
Огляд COM-технології
Технологія COM (Component Object Technology) - об'єктно-орієнтована програмна специфікація, запропонована Microsoft. COM призначена для підвищення надійності взаємодії програмних продуктів між собою. Дана технологія не визначає структуру програмного продукту, мова програмування та інші деталі реалізації.
COM є стандартом, що регламентує модель програмного об'єкта, що відповідає вимогам COM-технології. Програмний об'єкт, створений згідно специфікації COM називається COM-об'єктом. Ця технологія визначає механізм взаємодії COM-об'єктів між собою.
COM відноситься до так званих двійковим стандартам, тому що додається до оттранслірованному в двійковий код програмного об'єкту. Взаємодія
COM-об'єктів забезпечується набором визначених підпрограм, що називаються інтерфейсами, доступ до яких забезпечується через унікальні ідентифікатори інтерфейсів GUID (Global Unique Interface
Identifyer), унікальність яких гарантує операційна система. Такий механізм схожий з використанням покажчиків при доступі до об'єктів в об'єктно-орієнтованих мовах програмування, що дає можливість прозорого управління об'єктами, тому що доступ до них забезпечується через покажчики. COM-технологія розширює цей механізм, переносячи застосування покажчиків (у вигляді GUID) для доступу до об'єктів на рівень операційної системи. Таким чином, COM-об'єкти можуть бути прозоро один для одного модифікуватися, тому що доступ до об'єктів забезпечується через GUID. COM технологія включає в себе також бібліотеку, в якій міститься набір стандартних інтерфейсів, які визначають ядро функціональності COM і невеликий набір API функцій, розроблених для створення COM-об'єктів і управління ними.
Архітектура COM є розширюваної, і на ній базуються інші технології Microsoft, такі як OLE і ActiveX. Ці технології в даний час є розширеннями операційної системи, і визначають свої власні правила роботи і пропонують свої бібліотеки для створення об'єктів і для управління об'єктами на основі даних технологій.
Використовуючи COM як основу, розробники програмного забезпечення отримують можливість створювати свої власні розширення таким чином, що програмні об'єкти створені, за правилами COM-технології можуть працювати з іншими COM-об'єктами через уніфікований механізм взаємодії, який пропонує COM.
COM використовує таке поняття як «клас», яке за змістом означає те ж саме, що і в об'єктно-орієнтованих засобах розробки. COM-об'єкт є об'єктом COM-класу (COM class). COM-класи, для розрізнення з класами в об'єктно-орієнтованих мовах, за допомогою яких може створюватися додаток, звичайно називаються соклассамі (CoClass). Далі в тексті буде використовуватися термінологія, що виходить із об'єктно-орієнтованого програмування.
1 Склад COM-об'єкта
В COM-технології розрізняються наступні будівельні блоки, які використовуються для створення об'єктів:
. Interface (COM-інтерфейс) - безліч прототипів функцій
(методів), чисто визначених. Термін «чисто певний метод» або «абстрактний метод» виходить теорії об'єктно-орієнтованого аналізу, і означає, що у визначенні класу відсутня реалізація методу, а є тільки його визначення. Від такого класу не можна створювати об'єкти.
Його призначення - описати фундаментальні спільності для всіх похідних класів;
. COM object (COM-об'єкт) - об'єкт класу CoClass, який містить реалізацію COM інтерфейсу;
. COM/ActiveX server (COM сервер або ActiveX сервер) - модуль, такий як EXE, DLL або OCX, який містить машинний код COM або ActiveX об'єктів;
. Class factory (фабрика класів) - об'єкт, який може створювати COM-об'єкти з CoClass;
. Type library (бібліотека типів) - файл, що містить інформацію про типи даних, які використовує COM/ActiveX сервер.
2 Інтерфейси
Інтерфейси є основними будівельними одиницями COM. Вони об'єднуються на семантично пов'язані групи підпрограм, через які COM-об'єкти здійснюють взаємодію:
COM визначає такі ключові аспекти, пов'язані з COM-інтерфейсами:
. Методи інтерфейсу абстрактні (чисто визначені). Інтерфейс являє собою набір прототипів методів, чиє призначення полягає лише у визначенні інтерфейсу. Визначення прототипів методів включає в себе визначення числа і типів переданих значень, що повертається значення, а також очікуваного поведінки об'єкта. Як методи реалізовані, у визначення інтерфейсу не включається. Таким чином, реалізується поліморфізм інтерфейсу, тому що кожен нащадок, які успадковують інтерфейс, може включати власну реалізацію методу;
. Інтерфейс підпорядковується бінарного стандарту. Так як всі методи інтерфейсу абстрактні, інтерфейс представлений як покажчик на vtable (virtual table). Кожен запис в vtable є посилання на відповідний метод класу, який містить реалізацію інтерфейсу. Визначення інтерфейсу як покажчика встановлює протокол для доступу до COM-об'єкту, який є двійковим. Таким чином, отримання доступу до реалізації методу інтерфейсу об'єкта являє собою через послідовну процедуру отримання покажчиків:
З GUID система пов'язує покажчик на інтерфейс. Покажчик на інтерфейс, в свою чергу є покажчиком на vtable, через яку забезпечується покажчик на таблицю покажчиків на код з реалізаціями методів. Безліч об'єктів одного класу в системі використовують одну загальну vtable, і для кожного такого об'єкта створюється структура з приватними даними, необхідними для коректного виконання функцій.
. Інтерфейс включає в себе певну функціональність. Методи інтерфейсу семантично пов'язані за функціональністю та призначенням. Згідно з цим, методи інтерфейсу зазвичай іменується згідно зі своїм призначенням, і ім'я передує заголовної I. Для прикладу, метод IMalloc призначений для розміщення і звільнення пам'яті;
. Інтерфейс має унікальний ідентифікатор. Інтерфейси розрізняються за допомогою використання глобальних ідентифікаторів GUID, які використовуються для посилання на ідентифікатори конкретних інтерфейсів IID (Interface Identifier). Кожен інтерфейс має свій IID, і при реєстрації в системі отримує пов'язаний з ним
GUID. Використання GUID досконаліше, ніж використання символьних імен, оскільки гарантує відсутність конфліктів імен при оновленні програмних продуктів (виходу нових версій) і при використанні програмного забезпечення від різних виробників;
. Інтерфейс не може змінитися після реєстрації в системі.
Кожен інтерфейс призначений для виконання певного завдання, і визначає, які дані надходять на обробку і які дані виводяться. Таким чином, після того, як інтерфейс опублікований в системі, і став доступний для використання, він не повинен змінюватися. Будь-яка зміна в семантиці інтерфейсу веде до необхідності оявленія нового інтерфейсу. Однак існує можливість безпечної реалізації многоінтерфейсних об'єктів за допомогою використання для доступу до різних версій інтерфейсу різні IID.
. Інтерфейси успадковують функціональність від одного базового предка.
Всі інтерфейси прямо або опосередковано є нащадками інтерфейсу
IUnknown. Цей інтерфейс забезпечує базову функціональність інтерфейсу, яка включає в себе динамічний опитування об'єкта
(dynamic quering) і керування життєвим циклом об'єкта
(lifetime managment). Ця функціональність забезпечується трьома методами інтерфейсу IUnknown: QueryInterface, AddRef і Release.
Кожен клас, який реалізує інтерфейс, повинен реалізувати ці три методи, поряд з методами, успадковані від іншого інтерфейсу, і своїми власними методами. Нижче подано короткий опис функціонального призначення згаданих методів:
- QueryInetrface забезпечує опитування об'єкта і доступ до вказівником на інтерфейс. QueryInerface є першим записом у vtable, і пропонує ефективний шлях для визначення можливостей об'єкта, в простому випадку через цей метод при встановленні зв'язку забезпечується передача покажчика на інтерфейс IUnknown тому об'єкту, який намагається отримати доступ до даного об'єкту.
Даний метод також робить можливим оновлення COM об'єкта без втрат на оновлення інших залежних об'єктів, тому що об'єкт може бути динамічно опитано клієнтами через вказівник на IUnknown. Це функція носить назву dynamic quering;
- AddRef і Release знаходяться на другому і третьому місцях у vtable. Це прості рахункові функції, які надаються для управління часом життя об'єкта.
Поки внутрішній лічильник об'єкта, що відображає кількості разів виклику AddRef і Release більше нуля (виклик AddRef може збільшувати його значення), об'єкт залишається в пам'яті. Як тільки значення лічильника досягає нуля
(виклик Release може зменшувати його значення), реалізація інтерфейсу може безпечно видалити всі залежні нижележащие об'єкти. Це функція носить назву lifetime managment;
3 Властивості COM-об'єктів
COM-об'єкт - це об'єкт CoClass, що є класом, які реалізують один або більше інтерфейсів. COM-об'єкт надає функції, які доступні через вказівник на один з його інтерфейсів.
У зв'язку з цим, COM-об'єкт володіє наступними особливостями:
. COM-об'єкт захищений від прямого зміни зовнішніми програмами в своїх даних, тому що доступ до COM-об'єкту можливий тільки через вказівник на інтерфейс;
. COM-об'єкт може бути використаний додатками, реалізованими практично на будь-яких сучасних засобів розробки додатків (алгоритмічних мовах), з будь-якою внутрішньою організацією програми, головне, щоб засіб розробки дозволяло працювати з покажчиками на структури, на масиви і на функції. < p> 4 COM-сервери
Об'єкт COM-класу повинен мати у своєму складі фабрику класів, і ідентифікатор класу CLSID (Class Identifier), так щоб COM-об'єкт міг бути створений на основі існуючого модуля.
COM-сервер - це програма, або бібліотека, що надає певний набір сервісних функцій для клієнтських програм або бібліотек.
COM-сервер складається з COM-об'єктів. Наприклад, COM-сервер, який включає в себе код елементів управління ActiveX (ActiveX control) - є ActiveX-сервером. Для розробника є велика кількість бібліотек, які можна використовувати для створення COM-об'єктів.
Як приклад можна навести бібліотеку Microsoft Active Template
Library, що надає набір шаблонів, на основі яких можна створювати свої власні програмні продукти, побудовані по COM-технології. Наприклад, шаблон для COM-сервера включає в себе код для основних функцій, які повинен забезпечувати COM-сервер: реєстрація сервера в системі, завантаження/вивантаження сервера, створення об'єктів, управління фабриками класів, забезпечення видачі інформації про сервер, включаючи: тип сервера, help-файл, ім'я сервера, бібліотека типів і т.д.
Клієнти не повинні знати, яким чином сервер виконує свої функції, і клієнти не повинні знати, де знаходиться сервер - все взаємодія здійснюється через покажчики на інтерфейс сервера.
COM-сервер може бути наступних типів:
. In-process server (внутрішній сервер) - програмний DLL модуль, що працює в робочому просторі пам'яті клієнтського застосування:
. Local server (локальний сервер) - програмний EXE модуль, який працює в окремому адресному просторі;
. Remote server (віддалений сервер) - програмний EXE модуль, що працює на віддаленій машині:
5 Механізм маршаллінга
Різниця між внутрішнім і віддаленим серверами в тому, який тип міжпроцесної зв'язку використовується. У даному випадку існує необхідність використання посередників, які забезпечують передачу параметрів і виклик функцій. Такий механізм називається маршаллінгом (marshalling). Оскільки у випадку, коли клієнт і сервер знаходяться в різних адресних просторах, доступ до ресурсів не може бути здійснено безпосередньо через покажчики. Тому посередники з боку клієнта (proxy) здійснюють упаковку аргументів у пакети маршаллінга (marshalling packets), і забезпечують віддалений виклик процедур (Remote Procedure Call). Посередник з боку сервера (stub) реалізують розпакування параметрів, і приміщення їх в стек. Далі здійснюється виклик безпосередньо реалізації методу. По суті, сервер може створювати клієнтський виклик процедури у своєму власному адресному просторі.
Посередники використовують COM-засоби, для здійснення взаємодії в різних процесах. Для взаємодії об'єктів, що знаходяться на різних машинах, використовуються засоби розширення COM - розподілена COM (Distributed COM або DCOM). COM пропонує стандартний механізм маршаллінга - інтерфейс диспетчеризації (Dispatch
Interface).
6 Фабрики класів
Фабрики або виробники класів (class factories) - спеціальний тип COM-об'єктів, що використовується для створення та реєстрації
COM-об'єктів. Виробники класів реалізують стандартний механізм створення об'єктів COM-класів. Класи без ідентифікаторів класу
(CLSID) і фабрики класів можуть бути створені за допомогою виклику конструктора. Використання фабрики класів для створення об'єктів означає, що для клієнтського застосування, якому необхідно створити об'єкт класу, не потрібно знати про це класі нічого, крім його ідентифікатора CLSID. Фабрика класів візьме виклик конструктора на себе, включаючи передачу аргументів на конструктор і інші специфічні дії. Клас фабрики класів може бути об'єднаний з багатьма COM-класами, для кожного з яких можуть створюватися об'єкти. При створенні самого об'єкта фабрики класів, в конструктор передається ідентифікатор CLSID класу, для створення об'єктів якого призначається фабрика. Цей ідентифікатор визначає, об'єкти якого класу можуть бути створені за допомогою даної фабрики класів. Таким чином, кожен екземпляр фабрики класів в системі може бути використаний для створення об'єктів тільки одного певного класу.
Створення об'єкта класу проводиться за допомогою таких дій:
. виклику глобальної API-функції CoGetClass, яка шукає в системному реєстрі зареєстрований клас з даними
CLSID, визначає шлях до сервера, завантажує сервер і видає покажчик на інтерфейс виробника класів
(зазвичай IClassFactory) ;
. Покажчик на IСlassFactory може бути використаний для виклику методів виробника класів, наприклад:
CoCreateInstance (створення об'єкта);
Альтернативою розглянутого методу може служити виклик глобальної API-функції CoCreateInstance, яка виконує перерахований вище дії і створює об'єкт класу з ідентифікатором
CLSID, але таким чином можна створити тільки один об'єкт даного класу, тому що функція не повертає вказівник на інтерфейс виробника класів.
7 Бібліотеки типів
Бібліотека типів (type library) надає інформацію про використовувані типи об'єктів та інтерфейси, які надаються
ActiveX-серевером. Бібліотека типів за змістом аналогічна, наприклад, заголовки (header) для розробок на мові C і будь-якого іншого модуля, що містить інформацію про використовувані типи даних і об'єктах. Більшість інформації подібного роду може бути записано в бібліотеку типів. Отримати інформацію з бібліотеки типів можна шляхом опитування запущеного об'єкту або ж через загрузки безпосередньо бібліотеки типів. Після створення бібліотеки типів, до неї забезпечується доступ через спеціальний тип інтерфейсів: ITypeLib,
ITypeInfo і ITypeComp. Інтерфейс ITypeLib забезпечує доступ до інформації про типи в бібліотеці типів, а також до описів конкретних об'єктів, які, у свою чергу, можуть бути отримані через інтерфейс ITypeInfo.
Бібліотека типів містить інформацію про те, який інтерфейс, в якому COM-об'єкт міститься, кількість і тип методів інтерфейсів і їх параметрів. Ці описи включають в себе унікальні ідентифікатори класів (CLSID) та їх інтерфейсів (IID), через які здійснюється коректний доступ до об'єктів. У бібліотеці типів також може міститися наступна інформація:
. Описи користувацьких типів даних, пов'язаних з призначеними для користувача інтерфейсами;
. Функції, які експортуються ActiveX-сервером, але які не є інтерфейсними методами;
. Інформація про енумерованних типах даних (символьних константах);
. Посилання на описи типів в інших бібліотеках типів.
Використання бібліотеки типів дуже важливо для об'єктів, які призначені для розповсюдження та подальшого використання багатьма користувачами. Також існує ще ряд причин використання бібліотек типів:
. Об'єкти, які використовують безпосередню прив'язку до vtable, повинні бути описані в бібліотеці типів, тому що посилання в vtable формуються під час компіляції;
. Об'єкти, створені з класів, які підтримують інтерфейс IProvideClassInfo, повинні мати бібліотеку типів. Об'єкти, що мають у своєму складі дані інтерфейс, є типізований COM-об'єктами, тому що надають інформацію про використовувані типах (з бібліотеки типів);
. Елементи керування ActiveX повинні мати бібліотеку типів, що міститься безпосередньо в DLL або OCX файлі, що містить код ActiveX-сервера;
. Додатки, які є Automation-серверами, повинні мати бібліотеку типів, для більш зручно зв'язування з клієнтами;
. Використання бібліотеки типів у будь-якому випадку полегшує роботу із зовнішніми програмами, які можуть дізнатися про використовувані типи даних, і таким чином виключається використання більш громіздкого методу передачі параметрів у системі через універсальний механізм;
8 Диспетчерський інтерфейс
Диспетчерський інтерфейс (dispatch interface) - стандартна спеціальна реалізація інтерфейсу IDispatch, яку пропонує COM.
Дана реалізація забезпечує виконання процедур пізнього зв'язування (late binding) і маршаллінга. Диспетчерський інтерфейс зберігає усередині себе таблицю диспетчерських ідентифікаторів (dispID), кожен з яких є унікальним ідентифікатором члена інтерфейсу, і таблиця, по суті, реалізує відображення відповідного dispID на ім'я кожного члена інтерфейсу. Клієнт, що бажає одержати доступ до ресурсів сервера (до методу або властивості), повинен знати dispID для відповідного ресурсу. Таку інформацію можна отримати через виклик методу інтерфейсу IDispatch, який називається GetIDsOfNames, і який є першим записом у vtable для інтерфейсу IDispatch. Таким чином, клієнт отримує інформацію типи даних, які використовуються сервером, і отримує таблицю диспетчерських ідентифікаторів, з відображенням імені кожного ресурсу сервера на відповідний dispID. Дана операція і з боку клієнта, і з боку сервера, при використанні стандартної реалізації інтерфейсу IDispatch реалізується автоматично. Ця процедура називається пізнім зв'язуванням, тому що здійснюється на етапі виконання програми, а не на етапі компіляції. Маючи для кожного імені ресурсу сервера відповідний dispID, клієнт може здійснити звернення до нього, використовуючи метод інтерфейсу dispID, який іменується Invoke. Метод Invoke має сигнатуру, яка допускає виклик з будь-якою кількістю параметрів, чим забезпечується його універсальність. Реалізація Invoke розпаковує параметри і здійснює виклик відповідного методу або властивості і здійснює контроль над видачею винятків при виконанні методу або властивості. Коли виконання методу або обробка властивості закінчується, що повертають значення методу або властивості відправляються назад клієнтові. Якщо звернення клієнта до сервера переходить через кордони процесу або машини, то автоматично реалізуються всі дії з організації маршаллінга. Така прозорість є основною перевагою використання інтерфейсу диспетчеризації.
Основним недоліком диспетчерського інтерфейсу є обмеження на типи даних, які можна використовувати при передачі параметрів. Це випливає з необхідності упаковки і розпаковування параметрів при здійсненні маршаллінга. Допускається використовувати 13 стандартних типів даних. На користувацькі типи даних встановлюються досить суворі обмеження. Якщо вимоги завдання не вкладаються в ці обмеження, розробник має можливість реалізувати маршалліг, шляхом написання свого proxy/stub коду. Ще одним недолік проявляється в тому, що при компіляції програми не виконується перевірка відповідності типів викликаються функцій, тому що зв'язування диспетчерських інтерфейсів здійснюється на етапі виконання програми, і таким чином, не контролюється виклик
Invoke з невірним набором аргументів, що викликає помилку виконання.
9 Прив'язка ідентифікаторів
COM пропонує можливість прив'язки диспетчерських інтерфейсів на етапі компіляції. Якщо об'єкт описаний в бібліотеці типів, то dispID може бути прочитаний для кожного ресурсу об'єкта, тому що dispID є для кожного методу або властивості фіксованим, і є частиною опису використовуваних типів даних об'єкта. Така процедура називається прив'язкою ідентифікаторів (ID bindig). Метод GetIDsOfNames викликається компілятором під час трансляції програми, таким чином, прив'язка ідентифікаторів є формою раннього зв'язування (early binding). В результаті, на етапі виконання, під час першого виклику сервера клієнтом, не потрібно виклик процедури прив'язки інтерфейсів, що прискорює роботу. Ще однією перевагою даного підходу є перевірка відповідності типів у зверненнях до ресурсів сервера.
Основним недоліком є відсутність можливості перевірки імені ресурсу, якщо він раптом змінився. У клієнтському об'єкті всі виклики будуть здійснюватися через одного разу пов'язані на етапі компіляції інтерфейсні ідентифікатори.
10 Інтерфейси користувача
Vtable-інтерфейси (vtable interfaces) або призначені для користувача інтерфейси - визначаються користувачем, і допускають викликати методи інтерфейсу, користуючись посиланнями з vtable, за умови, якщо відомий порядок запису посилань на методи, число і тип переданих аргументів.
Перші три записи в vtable відповідають трьом методам інтерфейсу
IUnkown, за якими йдуть посилання на інші підтримувані інтерфейси. Якщо об'єкт не реалізує диспетчерський інтерфейс, то слідом за IUnkown безпосередньо йдуть посилання на методи користувацьких інтерфейсів, тобто, стає можливе звернення до методів і властивостей об'єктів безпосередньо через посилання з vtable.
У випадку якщо сервер має бібліотеку типів і реалізує диспетчерський інтерфейс, то клієнт може отримати інформацію з бібліотеки типів, без здійснення виконання функцій через прив'язки.
Достатньо отримати ідентифікатори dispID диспетчерського інтерфейсу, і здійснити прив'язку безпосередньо до vtable. Таким чином, можна здійснити більш швидкий доступ до ресурсів об'єкта, здійснюючи прямий виклик через посилання в vtable, не використовуючи диспетчерський інтерфейс. Код безпосередньої прив'язки до vtable може бути автоматично згенерований на етапі компіляції. Зрозуміло, такий метод виклику функцій набагато швидше, ніж методи прив'язки ідентифікаторів (тому що дзвінок здійснюється через Invoke, що викликає процедури упакування/розпакування параметрів) і пізнього зв'язування (тому що здійснюється повний цикл роботи з диспетчерським інтерфейсом).
11 Подвійні інтерфейси
Незважаючи на те, що COM надає можливість звернення до ресурсів серверів використовуючи vtable-інтерфейси, що підвищує швидкість взаємодії клієнта і сервера, що деякі клієнти можуть бути розроблені таким чином, що звертаються до об'єктів тільки через інтерфейс диспетчеризації. Це можуть бути, наприклад, що інтерпретуються макромови, які містять у собі засоби для роботи з COM-об'єктами, і в яких не реалізовані можливості для прив'язки до vtable. Таким чином, COM пропонує те, що називається подвійним, або подвійним інтерфейсом (dual interface). Подвійні інтерфейси пропонують два шляхи для доступу до ресурсів сервера: через диспетчерський інтерфейс і через vtable-інтерфейс. Подвійний інтерфейс визначається як спадкоємець IDispatch.
Переваги використання подвійних інтерфейсів:
. Подвійні інтерфейси пропонують можливість отримання покажчиків на ресурси сервера з їх іменами при компіляції об'єкта, таким чином, дозволяючи створювати клієнтів, з прив'язкою до vtable на етапі компіляції;
. Подвійні інтерфейси дозволяють клієнтам здійснити прямий доступ до ресурсів сервера через vtable-інтерфейси, що збільшує швидкість взаємодії об'єктів;
. Подвійні інтерфейси маю переваги перевірки відповідності типів на етапі компіляції (переваги раннього зв'язування);
. Клієнти, що не працюють безпосередньо з vtable-інтерфейсами мають можливість взаємодіяти з об'єктами через диспетчерські інтерфейси;
. Подвійні інтерфейси надають можливість маршаллінга для обох своїх частин - для диспетчерського інтерфейсу і vtable-інтерфейсу. При зверненні до сервера, що знаходиться в іншому адресному просторі здійснюється автомаршаллінг при зверненні через будь-яку частину інтерфейсу.
Існує набір обмежень щодо використання подвійних інтерфейсів. Вони в основному пов'язані з типами даних, оскільки подвійний інтерфейс є спадкоємцем інтерфейсу IDispatch. Однак, існує шлях для часткового уникнення таких обмежень, визначити не подвійний інтерфейс, а два окремих, один з яких - диспетчерський, інший - для користувача (без обмежень на тип даних). Таким чином, можна здійснити доступ до ресурсів сервера як через диспетчерський, так і через vtabl-інтерфейс.
Розширення COM
Одним з розширенням технології COM є OLE, що представляє собою бібліотеку власних інтерфейсів, типів даних і підпрограм, призначених для забезпечення функціональності OLE. Кожна функція іменується з префіксом IOle.
Ще одним розширенням COM є не так давно створена технологія ActiveX. Основні відгалуження ActiveX носять назви
ActiveX Documents (документи ActiveX) і елементи управління ActiveX
(ActiveX controls). ActiveX «молодше» OLE, і була розроблена як COM-розширення, оптимізоване за швидкістю і за розміром. Однак, OLE з появою ActiveX вже була непогано розвинена, і зараз відмінності між цими двома технологіями починають зменшуватися, а їх функціональності все більше перекриватися.
1 OLE/Active document
Документи OLE (OLE/Active documents) - один з набору сервісів, які пропонує технологія OLE. Об'єкти OLE documents мають всі властивості OLE по зв'язку та впровадження даних, візуального редагування, підтримки drag-and-drop, активізації за місцем (in-place-activation).
Використовуючи OLE document можна визначити будь-який кількість інтерфейсів, через які забезпечується стандартне поводження об'єкта, таке як візуальне редагування і drag-and-drop. За допомогою реалізації цих інтерфейсів, об'єкти OLE documents можуть бути вільно об'єднані в єдину систему взаємодіючих об'єктів з різними форматами даних, таких, як звукові фрагменти, текстові документи і растрові зображення.
Об'єкт OLE documents може бути реалізований як внутрішній і зовнішній COM-сервер. Такий об'єкт складається з двох частин: візуальної
(presentation data), призначеної для відображення візуальної частини об'єкта і з внутрішньої частини (native data), яка використовується для редагування об'єкта. Об'єкти OLE documents можуть бути контейнерами документів (document container) і серверами документів (document server). Сервер документів забезпечує функціональність об'єктів OLE documents. У середовищі контейнера документів може бути активізовано будь-який сервер документів.
2 Automation
Технологія автоматизації (automation) пропонує можливість програмного управління однієї програми іншим. У даній технології розрізняються дві складові компоненти:
. Клієнтська частина, яка називається контролером автоматизації
(automation controller);
. Серверна частина, яка носить назву об'єкта автоматизації (automation object) - об'єкт, яким управляє клієнт.
Об'єкти автоматизації можуть бути реалізовані як внутрішні, зовнішні і віддалені сервера. Технологія автоматизації характеризується двома положеннями:
. Об'єкти автоматизації повинні мати можливість визначити безліч властивостей і команд через описи типів, тобто вони повинні отримати інформацію про інтерфейсах об'єкта, з яким йде взаємодія, про методи інтерфейсів і про типи аргументів. Така інформація надається через бібліотеки типів.
Однак, використання бібліотеки типів не обов'язково при використанні інтерфейсу диспетчеризації, тому що за допомогою останнього здійснюється прив'язка інтерфейсів на етапі виконання програми (недоліком такого підходу є відсутність перевірки відповідності типів на етапі компіляції);
. Об'єкти автоматизації повинні надавати свої методи загальнодоступними для зовнішнього використання, так, щоб ними могли користуватися зовнішні програми. Для цього, в об'єктах автоматизації повинен бути реалізований інтерфейс диспетчеризації.
Основною перевагою технології автоматизації є можливість створення об'єктів, що працюють у будь-якому процесному просторі. Таким чином, замість створення невізуальних OLE-об'єкта краще використовувати Automation. Ще одна перевага технології Automation полягає в механізмі взаємодії додатків, що реалізовується інтерфейсом диспетчеризації, який автоматизує процес маршаллінга. Однак, цей механізм обмежує набір типів даних, які можна використовувати при автомаршаллінге.
3 ActiveX control
Технологія ActiveX розширює COM і OLE новими функціями, специфічними для елементів керування ActiveX (ActiveX control).
ActiveX control - візуальні об'єкти управління, що реалізуються як внутрішні COM-сервера, і які включаються до OLE-контейнери, і працюють у їхньому середовищі. Елементи керування ActiveX не є закінченими додатками, але являють собою об'єкт, який вирішує деяку приватну завдання і може бути вбудований в різні додатки. Основними характерними рисами ActiveX controls є можливість обробки подій, прив'язки до джерел даних і підтримка ліцензування.
Елементи керування ActiveX особливо широко використовуються в розробці Web-додатків, де ActiveX controls використовуються як інтерактивні об'єкти на Web-сторінках. По суті, ActiveX стає стандартом, спеціально спрямованим на інтерактивну частину
World Wide Web, наприклад, для перегляду в Web-браузері не гіпертекстових документів, доступ до баз даних і т.д.
4 Взаємодія між візуальні об'єкти
Об'єкти автоматизації, документи OLE і елементи управління
ActiveX є загальними використовуваними об'єктами для всіх додатків.
Менш загальне використання COM-об'єктів присутній у міжпроцесної об'єктах, які візуально відображаються і використовуються в многопроцессних додатках. Ці типи об'єктів набагато складніше створювати, тому що протокол взаємодії, що застосовується в управлінні візуальними об'єктами в мнопроцессних додатках стандартизований тільки для візуальних об'єктів, які використовують інтерфейс OLE document. Отже, необхідно створити для користувача інтерфейси об'єктів і їх реалізації, які будуть керувати маршаллінгом інтерфейсів. Також, це можна реалізувати через:
. Використання подвійного інтерфейсу IDispatch, який підтримує автомаршаллінг;
. Написання власного класу, що реалізовує маршаллінг.
5 OPC
Специфікація однієї з модифікацій OLE, яка називається OPC
(OLE for Process Control) була розроблена групою фірм, що займаються розробкою програмного забезпечення для систем промислової автоматизації. Дана технологія включає в себе набір стандартних угод, що застосовуються в системах промислової автоматизації. В даний час особливий розвиток отримало використання OPC як сполучною механізм взаємодії окремих компонент SCADA-систем, а також систем різних виробників один з одним, забезпечуючи ефективний за часом і вартості інтеграцію компонент програмного забезпечення. Зв'язок з OPC здійснюється прозоро для розробника, використовуючи всі засоби, які надає COM, що дозволяє не внедряясь в техніку зв'язку організовувати взаємодіючі в єдиних інформаційних системах програмні компоненти.
Засоби розробки COM-додатків
Основним інструментом розробки COM-додатків, що закономірно, є продукти Microsoft, що відносяться до сімейства візуальних засобів програмування Visual Studio. Усі компоненти цього сімейства пропонують засоби роботи за технологією COM, і спрямовані в основному саме на розробку продуктів в рамках цієї технології.
Основною фігурою для розгляду в цьому розділі буде сімейство засобів розробки додатків фірми Inrise Inc. Пов'язані з класу RAD (Rapid Application Development) - засоби швидкої розробки додатків. Це продукти Borland С + + Builder і Borland
Delphi, які, починаючи з версії 3 підтримують розробку COM-додатків.
С + + Builder і Delphi (далі, просто C + + Builder, т . к. обидва цих продукту надають ідентичні можливості, навіть більше того, використовують одні й ті ж об'єктні бібліотеки) пропонують набір готових компонент, використовуючи які, як шаблони, можна легко почати розробку програми в рамках COM. C + + Builder пропонує набір класів з реалізацій основних функцій інтерфейсів IDispatch, призначених для користувача і подвійних інтерфейсів, роботи з бібліотеками типів і фабриками класів. Форма, створена у візуальному редакторі легко портіруют в COM-клас, з перенесенням всіх властивостей і методів автоматично до бібліотеки типів. Робота над описом інтерфейсів і об'єктів не вимагає знання мови опису інтерфейсів IDL (interface definition language) і мови опису об'єктів ODL (object definition language), тому що вся робота ведеться у візуальному редакторі. Код на IDL все одно створюється, але цей процес може бути для розробника прозорий.
