1. Технологія com(Component Object Model)

Модель компонентних об’єктів ( COM ) Microsoft спирається на використання інтерфейсів. Перевагою використання побудованого на інтерфейсах програмного коду є можливість розробки різних компонент-орієнтованих систем, включаючи розподілені компонент-орієнтовані системи.

Щоб краще зрозуміти суть моделі COM, необхідно розглянути причини, які призвели до її розробки. Модель COM досить довго перебувала на задньому плані тільки через те, що корпорація Microsoft не потурбувалась над тим, щоб пояснити спільноті розробників, що це таке і для чого створено. Більшість розробників помилково прийняли її за обновлену версію OLE, старої технології, основаної на динамічному обміні даними, і створеної для зв’язку і впровадження об’єктів при інтеграції продуктів MS Office. Фактично, модель COM була представлена як OLE2, що мало на увазі лише нову версію старих проблем OLE. Таким чином, пройшло немало часу, перш ніж всі зрозуміли, що модель COM володіє значно більшими можливостями, ніж це розуміється в парадигмі «інтерфейс-орієнтовна розробка компонентних систем». Модель COM дозволяє успішно розв’язувати наступні проблеми:

• Багаторазове використання програмного коду. Порівнюючи із звичайною об’єктно-орієнтованою моделлю, модель COM володіє додатковими перевагами, оскільки дозволяє використовувати не тільки файли вихідного коду, але і бінарні файли відкомпільованого коду.

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

• Незалежність від компілятора і постачальника. Мається на увазі проблема використання бібліотек DLL, що випускаються різними постачальниками програмного забезпечення, які використовують різні компілятори і різний формат імен. Модель COM абсолютно не чутлива до цієї проблеми. Незалежність від мови, в свою чергу, забезпечує також повну незалежність від компілятора, що використовується кожним конкретним постачальником програмного забезпечення.

• Незалежність від розміщення. Клієнт не зобов’язаний знати, де саме розміщений компонент, що являє собою сервер. Його може містити внутрішній процес бібліотеки DLL, локальний сервер EXE, віддалена бібліотека DLL або віддалений сервер EXE.

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

• Контроль версій. Що трапиться при спробі встановити стару версію бібліотеки DLL зверху більш нової? В моделі COM – це не проблема, як і багато іншого.

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

Для вдалої реалізації моделі об’єкта COM необхідно дотримуватися декількох нескладних правил:

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

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

• кожний клієнт повинен мати можливість скористатися будь-яким об’єктом COM незалежно від мови програмування, на якій написаний клієнт або об’єкт COM;

• об’єкт COM повинен поставлятися в бінарному(відкомпільованому) вигляді;

• оновлення об’єктів COM не повинно приводити до втрати дієздатності вже існуючих клієнтів. Тобто нові версії об’єктів COM повинні працювати як з новою версією клієнта, так і зі старою.

  • Об’єкт COM повинен допускати змінення свого місця знаходження в сітці. Клієнт повинен мати можливість взаємодіяти з віддаленим об’єктом COM тим самим способом, що й з локальним.