Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
11
Добавлен:
23.02.2016
Размер:
93.7 Кб
Скачать

ПЗ АСУ ТП

Тема 3.1. Компонентна модель Microsoft COM/DCOM.

Лекція 9.

Компонентна модель Microsoft COM/DCOM

  1. Основні поняття та модель COM.

  2. OLE, ActiveX та DCOM.

1. Основні поняття та модель COM.

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

Уявимо собі, наприклад, коректор орфографії, реалізований у вигляді об'єкту СОМ. Такий об'єкт може підтримувати інтерфейс, що включає методи типу "НайтиСлово" (LookUpWord), "ДобавитьКСловарю" (AddToDictionary) і "УдалитьИзСловаря" (RemoveFromDictionary). Якщо пізніше розробник об'єкту СОМ захоче додати до цього об'єкту підтримку словника синонімів, то об'єкту знадобиться ще один інтерфейс, можливо, з єдиним методом, ніби "НайтиСинонім" (ReturnSynonym). Методи кожного з інтерфейсів спільно надають пов'язані один з одним сервіси: або коригування правопису, або доступ до словника синонімів.

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

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

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

Отримавши покажчик на потрібний йому інтерфейс об'єкту, що виконується, клієнт може використовувати сервіси об'єкту, просто викликаючи методи цього інтерфейсу. З точки зору програміста, виклик методу аналогічний виклику локальної процедури або функції. Але насправді код, що виконується по виклику методу, може бути частиною або бібліотеки, або окремого процесу, або операційної системи і навіть розташовуватися взагалі на іншому комп'ютері.

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

Початкова модель СОМ (рис. 1) була представлена Мicrosoft в 1993 році як інтеграційна схема для підтримки OLE (Object Linking and Embedding — зв'язування і впровадження об'єктів), технології побудови складених документів в ОС Windows 3.1. Спочатку інфраструктура СОМ дозволяла реалізовувати компоненти, що взаємодіють у рамках одного адресного простору або між процесами на одному комп'ютері, і була фактично засобом динамічної інтеграції двійкових компонентів. Окрім OLE, модель СОМ послужила основою таких технологій Microsoft, як монітор транзакцій Microsoft Transaction Server і архітектура інтеграції прикладних компонентів ActiveX.

Рис. 1. Архітектура Component Object Model

  1. OLE, ActiveX та DCOM.

Автоматизація

Електронні таблиці, текстові процесори і інші програми надають усі види корисних можливостей. Чом би не забезпечити доступ до них і іншого програмного забезпечення? Щоб це стало можливим, застосування повинні надавати свої сервіси не лише людині, але і програмам — вони мають бути програмованими. Забезпечення програмованості і є метою Автоматизації (Automation).

Додаток можна зробити програмованим, забезпечивши доступ до його сервісів через звичайний СОМ-інтерфейс. Проте так чинять рідко. Замість цього доступ до сервісів додатків здійснюється через диспінтерфейси (dispinterface). Вони дуже схожі на інтерфейси, (у нього є методи, клієнти здійснюють до нього доступ через покажчик інтерфейсу і т. д.), але мають і істотні відмінності. Зокрема, методи диспінтерфейсу набагато простіше викликати клієнтам, написаним на простих мовах типу Visual Basic. Це дуже важливо: адже більшість людей, бажаючих писати програми, що здійснюють доступ до внутрішніх сервісів застосувань, найчастіше вибирають Visual Basic і аналогічні середовища.

Щоб отримати уявлення про можливі вигоди Автоматизації, візьмемо, наприклад, Microsoft Excel — програму з широким вибором функцій, використовуваних тими, хто безпосередньо працює з Excel. Безумовно, на вбудованій в неї макромові можна написати цілі застосування, що використовують функції Excel.

Проте сьогодні Microsoft Excel підтримує Автоматизацію, а це означає, його внутрішні сервіси доступні через диспінтерфейси, підтримувані різними СОМ-об’єктами, що надають методи, скажімо, для обчислення середнього значення, перевірки правопису і багато інших. Застосування, що надбудовуються над Excel, більше не обмежені застосуванням внутрішньої макромови цієї програми, але навпроти, можуть бути написані практично на чому завгодно. Нині Excel — не лише інструмент для кінцевих користувачів, але і набір інструментів для розробників застосувань.

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

Перманентність

Об'єкти складаються з методів і даних, і багатьом об'єктам необхідно зберігати свої дані впродовж періодів неактивності. На професійному жаргоні, об'єкту необхідно зробити свої дані перманентними (persistent), що зазвичай означає запис їх на диск. СОМ-объекты досягають цього різними шляхами. Один з найширше вживаних — структуроване сховище (Structured Storage).

Щоб зрозуміти ідею структурованого сховища, спочатку розглянемо, як додатки зберігають свої дані в звичайних файлах. Традиційні файлові системи забезпечують спільне використання додатками одного дискового пристрою без конфліктів між ними. Кожий додаток працює зі своїми власними файлами і, можливо, навіть з власними підкаталогами незалежно від того, чим зайняті в той же момент інші додатки. Додатками не вимагається взаємодіяти один з одним, щоб зберегти свої дані, оскільки у кожного окрема область для зберігання.

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

Те, що нам потрібне, — це спосіб спільного використання одного файлу декількома СОМ-об’єктами. Таку можливість і надає структуроване сховище. Створюючи, по суті справи, файлову систему усередині кожного файлу, структуроване сховище надає кожному компоненту, що становить деяке застосування, власний окремий шматок простору сховища, власні "файли". З точки зору користувача, файл тільки один. Проте з точки зору додатку, кожен компонент має власну область для зберігання даних, і усі такі області знаходяться усередині одного дискового файлу.

Щоб реалізувати усе це, структуроване сховище визначає два типи СОМ-об’єктів, кожен з яких підтримує відповідні інтерфейси. Ці об'єкти відомі як сховища (storage) і потоки (streams) і аналогічні відповідно до каталогів і файлів звичайної файлової системи. Файл структурованого сховища може містити дані багатьох СОМ-об’єктів, кожен з яких використовує для збереження своїх даних власне сховище або потік. Точно так, як і звичайна файлова система забезпечує спільне використання диска декількома додатками, структуроване сховище дозволяє різним додаткам спільно використовувати один файл.

Проте перманентність — це не лише структуроване сховище. Сом-об'єкт може зберігати свої перманентні дані і іншими способами, наприклад в звичайному файлі або в WWW. Крім того, клієнти об'єкту повинні мати можливість повідомити його, коли виконувати завантаження і збереження перманентних даних. Для цього об'єкт може підтримувати один (чи декілька) із стандартних інтерфейсів, призначених для цієї мети.

Монікери

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

Однакова передача даних і об'єкти з підключенням

Обмін даними — фундаментальна операція в програмуванні. Наприклад, коли користувач переміщає дані через буфер обміну (clipboard), додатки здійснюють їх копіювання. Різні типи системних програм, такі як драйвери, надають інформацію про свої пристрої програмам, що використовують їх. Враховуючи величезну кількість приводів для обміну даними між програмами, не варто дивуватися, що для цієї мети було винайдено надвелику кількість схем.

Стандартний спосіб обміну інформацією у світі СОМ — Однакова передача даних (Uniform Data Transfer). Як і будь-яка технологія ActiveX або OLE, застосування, що використовують його, повинні підтримувати певні інтерфейси СОМ. Методи цих інтерфейсів визначають стандартні способи для опису передаваних даних, для вказівки їх місця розташування і власне для їх пересилки. Вони навіть визначають простий механізм, що дозволяє одному застосуванню повідомити інше про те, що потрібні останньому дані сталі доступні. Хоча однакова передача даних навряд чи є найчудовішим аспектом СОМ, вона відіграє важливу роль в роботі СОМ-додатків.

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

Складені документи

Додатки з кожним днем стають все складнішими. У текстові процесори додаються графічні можливості, в електронні таблиці засобу побудови діаграм, і здається, усе закінчиться одним великим додатком для вирішення усіх завдань. Але насправді мета якраз не в цьому, а в інтеграції різних додатків. Наприклад, додавати підтримку графіки в текстовий процесор не потрібно буде, якщо усередині нього можна буде використовувати деякий вже існуючий графічний додаток. Завдання — забезпечити оптимальну спільну роботу додатків. Користувачеві повинно представлятися щось таке, що виглядає як один документ, хоча насправді над різними частинами такого документу спільно працюють різні додатки.

Для вирішення цієї проблеми призначена технологія OLE (що раніше називалася Документи OLE — OLE Documents). Підтримуючи потрібні СОМ-об’єкти, кожен з власним набором інтерфейсів, незалежні застосування можуть спільно працювати, щоб користувач отримав один складний документ. Усі ці інтерфейси носять абсолютно загальний характер — жодне застосування не знає, що є інші. Навіщо вбудовувати в текстовий процесор функції електронної таблиці? OLE допоможе просто задіювати у разі потреби існуюче застосування електронної таблиці.

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

При створенні складеного документу за допомогою OLE одно із застосувань завжди є контейнером. Як випливає з назви, контейнер визначає найзагальніший документ, в якому міститься усе інше. Інші застосування — сервери — можуть розміщувати свої документи усередині документу-контейнера.

При використанні OLE документ сервера може бути або пов'язаний, або впроваджений в документ контейнера. Пов'язаний документ сервера зберігається в окремому файлі, а в документі контейнера зберігається лише зв'язок з цим файлом. (Насправді зв'язком є монікер.) Впроваджений документ сервера зберігається в тому ж файлі, що і документ контейнера. (Два застосування при цьому спільно використовують загальний файл за допомогою структурованого сховища.)

Елементи ActiveX, що управляють

Чому для включення в текстовий документ електронної таблиці необхідно використовувати увесь Excel? Якщо потрібні тільки основні можливості електронних таблиць, то ймовірно, можна обійтися меншим, швидшим і дешевшим компонентом. Багатьом програмістам припала б до смаку можливість побудувати цілий додаток здебільшого з готових компонентів.

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

Елемент ActiveX, що управляє, — незалежний програмний компонент, що виконує специфічні завдання стандартним способом. Розробники можуть задіювати один або декілька таких елементів в додатку, щоб отримати переваги функціональних можливостей існуючого програмного забезпечення. В результаті програмне забезпечення побудоване в основному із вже готових частин — буде те, що називається компонентним програмним забезпеченням.

Елементи ActiveX, що спочатку управляють, були відомі під назвою елементи OLE або ОСХ, що управляють. Microsoft змінила назву, щоб відбити деякі нові можливості, ці елементи, що зробили, більше відповідними для Інтернету і WWW. Наприклад, елемент ActiveX, що управляє, може зберігати свої дані на сторінці десь в WWW або може бути викачаний з сервера WWW і потім запущений на машині клієнта. І контейнер, в якому працює елемент, що управляє, не зобов'язаний бути середовищем програмування — замість цього він може бути засобом перегляду WWW.

Елементи ActiveX, що управляють, — не окремі застосування. Навпаки, вони є серверами, які підключаються до контейнера елементів. Як завжди, взаємодія між елементом, що управляє, і його контейнером визначається різними інтерфейсами, підтримуваними СОМ-объектами. Елементи ActiveX, що фактично управляють, використовують багато інших технологій OLE і ActiveX. Наприклад, елементи, що управляють, зазвичай підтримують інтерфейси для впровадження і частенько надають доступ до своїх методів через диспінтерфейси Автоматизації.

Розподілена СОМ

Хоча СОМ із самого початку розроблялася з урахуванням підтримки розподілених систем, її первинна реалізація могла працювати тільки на одному комп'ютері. Об'єкти СОМ могли бути реалізовані в DLL або в окремому процесі, що виконується на тій же машині, що і їх клієнт, але не могли розташовуватися на інших машинах в обчислювальній мережі. Ця ситуація змінилася з появою розподіленою СОМ (Distributed СОМ — DCOM). Тепер об'єкти СОМ можуть надавати свої сервіси і клієнтам на інших машинах.

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

Соседние файлы в папке ПЗ АСУ ТП_Гузнин