вигляді бібліотек, компонуемих з процесом. Спочатку вона розроблялася для підтримки так званих складових документів (compound documents). Як ми говорили в розділі 3, складові документи - це документи, побудовані з різнорідних частин, таких як текст (форматований), зображення, електронні таблиці тощо Кожна з цих частин може бути відредагована за допомогою асоційованого з нею програми. p align="justify"> Для підтримки незліченної безлічі складових документів Microsoft потрібен був узагальнений метод для розділення окремих частин і об'єднання їх в єдину сутність. Спочатку це призвело до технології зв'язування та впровадження об'єктів (Object Linking and Embedding, OLE), Перша версія OLE використовувала для передачі інформації між частинами документа примітивний і негнучкий спосіб обміну повідомленнями. Незабаром вона була замінена наступною версією, також називалася OLE, але побудованої на базі більш гнучкого механізму СОМ, що призвело до появи структури, представленої на рис. 5. <В
Рис. 5 - Загальна структура ActiveX, OLE і COM
На малюнку також показаний елемент ActiveX - цим терміном в даний час називають все, що відноситься до OLE, плюс деякі нововведення, до яких відносять гнучку (як правило) здатність компонентів виконуватися в різних процесах, підтримку сценаріїв і більш-менш стандартну угруповання об'єктів у так звані елементи управління ActiveX. Серед експертів з DCOM (навіть всередині Microsoft) не існує згоди з питання про точне визначення ActiveX, тому ми навіть не будемо намагатися дати подібне визначення. p align="justify"> Модель DCOM додала до цієї структури дуже істотну річ - здатність процесу працювати з компонентами, розміщеними на іншій машині. Однак базовий механізм обміну інформацією між компонентами, прийнятий у DCOM, дуже часто збігається з відповідними механізмами СОМ. Іншими словами, для програміста різниця між СОМ і DCOM часто прихована за різними інтерфейсами. Як ми побачимо, DCOM в першу чергу надає прозорість доступу. Інші види прозорості менш очевидні. p align="justify"> Як і в CORBA, об'єктна модель в DCOM побудована на реалізації інтерфейсів. Грубо кажучи, об'єкт DCOM - це просто реалізація інтерфейсу. Один об'єкт може реалізовувати одночасно декілька інтерфейсів. Однак на відміну від CORBA в DCOM є тільки бінарні інтерфейси (binary interfaces). Такий інтерфейс, по суті, являє собою таблицю з покажчиками на реалізації методів, які є частиною інтерфейсу. Зрозуміло, для визначення інтерфейсу і раніше зручно використовувати спеціальний мова визначення інтерфейсу (IDL). У DCOM також є така мова під назвою MIDL (Microsoft IDL - мова IDL від Microsoft), за допомогою якого генеруються бінарні інтерфейси стандартного формату. p align="justify"> Гідність бінарних інтерфейсів полягає в тому, що вони не залежать від мови програмування. У разі CORBA щоразу для підтримки нової мови програмування необхідно відображати опису IDL на...
