Архітектура DCOM

Архітектуру СОМ (Component Object Model) та її варіант DCOM (Distributed СОМ) розробила фірма Microsoft. Історичним попередником цієї архітектури була OLE 1. Вона була зосереджена на документоцентричних застосуваннях, давала змогу вбудовувати документи різних застосувань один в одний. Архітектура OLE 2 розглядала загальнішу проблему надання сервісів програмними компонентами для інших компонентів. Тому в основі OLE 2 є СОМ. Сьогодні термін OLE використовують тільки для технологій пов'язаних документів, а термін ActiveX — для технології на базі СОМ.

Об' єкти СОМ діють у деякому середовищі, яке Їх створює, контролює під час роботи та знищує (сервер). Кожен об'єкт підтримує один або кілька інтерфейсів. Кожен інтерфейс складається з методів. Множинність інтерфейсів дає змогу підтримувати старі та нові версії, групувати функції тощо (CORBA, наприклад, не допускає множинності інтерфейсів. Для неї інтерфейс — це тип об'єкта. Java ж реалізує множинність).

Об' єкт СОМ — це примірник класу. Його створюють на підставі звертання до бібліотеки СОМ, щО містить прототипи всіх доступних класів. Бібліотека СОМ запускає сервер підтримки об'єкта, створює об'єкт. Після створення об'єкта звертання надходить уже безпосередньо до нього, його інтерфейсів.

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

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

СОМ вирізняє два типи успадкування: успадкування реалізації та успадкування інтерфейсу. у випадку першого типу успадковуваний код батька. Це означає, що під час створення об'єкта формуються також і всі батьківські об'єкти. У СОМ реалізовано лише успадкування інтерфейсу. Об'єкт успадковує тільки визначення методів батька та підтримує Їх. Це полегшує реалізацію поліморфізму. Справді, успадкування реалізації у випадку взаємодії об'єктів передбачає два різні шляхи створення об'єктів: успадкування та прямий виклик. Крім того, успадкування реалізації менш гнучке: якщо реалізація одного з батьків змінилася, то потрібна підтримка як старої; так і нової реалізації: Взаємодія об'єктів допускає також множинний та умовний вибори. Вона може діяти в умовах неповної визначеності та неоднозначності вибору.

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

Розробники, створюючи архітектуру СОМ, намагалися з'ясувати причини відставання розвитку програмних систем порівняно з розвитком обладнання. Серед головних причин вони назвали відсутність ринку програмних компонентів. Їх виготовляють різні виробники для виконання спеціалізованих функцій. Компоненти можна якісно тестувати та використовувати багаторазово. Це дає змогу здешевити ПЗ. Однак підходи, що є сьогодні й орієнтовані на багаторазове використання ПЗ, недостатні, оскільки:

• бібліотеки хоч і не залежать від мови програмування, проте складні в розширенні та запровадженні нових версій;

• об'єкти повторно використовують на рівні робочих груп. Застосовувати їх ширше не можна з таких причин: по-перше, немає стандартів для компонування двійкових об'єктів у єдине ціле (тому Java використовує інтерпретатор). Об'єкти, що взаємодіють, повинні бути скомпільовані одним компілятором. Тому наявні бібліотеки об'єктів С++ розповсюджують разом з початковими текстами. Породжені об'єкти тісно пов'язані з батьківськими. Автор породженого методу повинен мати доступ до тексту батьківського методу. Однак автори не зацікавлені у поширенні початкових текстів; по-друге наявні різні об'єктні мови та середовища проектування; по-третє, якщо змінюється один з об'єктів застосування, то це потребує перекомпіляції всього застосування.

Усі ці проблеми дає змогу вирішити СОМ. За допомогою СОМ можна зручно структурувати сервіси. Проект визначений як сукупність об'єктів, після цього визначають інтерфейси кожного об'єкта. СОМ зменшує різницю між системним програмним забезпеченням та застосуваннями. Звертання до всього ПЗ виконується однаково. СОМ не зважає на мову програмування. Важливим є тільки визначений двійковий інтерфейс. СОМ дає змогу контролювати версії. Старі інтерфейси не змінюються (СОМ це забороняє). Нові можливості реалізовані через новий інтерфейс.