Лекція 07. Розподілена система dcom

Діденко Д.Г. © 2010

Лекція 07. Розподілена система DCOM

Діденко Дмитро ГеоргійовичСтарший викладач кафедри ММСА ННК «ІПСА»

Національний технічний університет України «Київський політехнічний інститут»

м. Київ, Україна

www.simulation.kiev.ua/dis/ Розподілена система DCOM


2

1. Розподiлена система DCOM.

Питання заняття



3

COM (Component Object Model) — платформа компонентно-орієнтованого програмування розроблена в 1993 році компанією Microsoft; дозволяє використання міжпроцесної взаємодії (inter-process communication) та динамічного створення об'єктів у будь-якій мові програмування, що підтримує технологію. Використовується переважно у ОС Windows, хоча була реалізована на декількох платформах.

1. Визначення COM



4

Основним поняттям, яким оперує технологія COM, є COM-компонент. Програми, побудовані на технології COM фактично не є автономними програмами, а представляють собою набір взаємодіючих між собою COM-компонентів. Кожен компонент має унікальний ідентифікатор GUID і може одночасно використовуватися багатьма програмами. Компоненти взаємодіють між собою через COM-інтерфейси — набори абстрактних функцій і властивостей. Кожен COM-компонент повинен підтримувати стандартний інтерфейс «IUnknown», який об'єднує базові засоби для роботи з компонентом.

1. Основні поняття



5

Windows API об'єднує базові функції, що дозволяють використовувати COM-компоненти. Бібліотека MFC і, особливо, ATL/WTL забезпечують більш гнучкі і зручні засоби для роботи з COM.

1. Windows API



6

СОМ розроблено для пiдтримання складених документiв на основi технологiї зв'язування i впровадження OLE (Object Linking & Embedding) та елемента ActiveX, який включає додаткову можливiсть викликати компоненти в рiзних процесах, пiдтримувати сценарiї та групування об'єктiв в елементи керування ActiveX.

1. Мета розробки COM



7

2. Структури ActiveX, OLE, COM



8

До моделi DCOM додано можливiсть процесу працювати з компонентами, розмiщеними на iнших машинах, або на тiй же машинi, де виконується процес.

1. Відміна DCOM та COM



9

1. На вiдмiну вiд CORBA модель DCOM має бiнарнi iнтерфейси (binary interfaces) - таблицi з вказiвниками на реалiзацiю методiв. Бiнарний iнтерфейс визначається мовою IDL, яка має назву MIDL. Iнтерфейси мають унiкальний 128-бiтний iдентифiкатор iнтерфейсу IID (Interface Identifier).

1. Відміна DCOM та CORBA



10

2. Об'єкт DCOM створюється як екземпляр класу, доступ до якого здiйснюється за допомогою об'єкта класу. Пiсля створення екземпляра об'єкта класу стає можливим доступ до методiв iнтерфейсу. Кожний об'єкт класу має глобальний унiкальний iдентифiкатор класу CLSID (Class Identifier).

3. Об'єкти є нерезидентними, на вiдмiну вiд CORBA, i тому вилучаються, якщо немає посилань на об'єкт. Тому сам об'єкт не може мати глобального унiкального iдентифiкатора, а може викликатись лише за вказiвниками на iнтерфейси.

1. Відміна DCOM та CORBA (продовження)



11

3. Використання бiнарних iнтерфейсiв



12

• Усi об'єкти реалiзують стандартний об'єктний iнтерфейс IUnknown, основний метод якого Query Interface повертає на основi IID вказiвник на iнший iнтерфейс, реалiзований в об'єктi.

• Об'єкти, запити до яких створюються динамiчно пiд час виклику, повиннi мати реалiзацiю iнтерфейсу IDispatch, подiбного до DII CORBA.

• Iнтерфейси DCOM зберiгаються в бiблiотецi типiв (type library), яка може розмiщуватись в окремому файлi або бути частиною додатка.

1. Робота з об’єктом



13

• Для активiзацiї об'єкта в процесi використовують реєстри Windows i спецiальний процес - менеджер керування службами SCM (Service Control Manager). Реєстр застосовують також для записування вiдображення iдентифiкатора CLSID на локальнi iмена файлiв, що мiстять реалiзацiї класiв.

• Пiд час створенняя об'єкта процес переконується у завантаженнi об'єкта класу (на тiй самiй машинi), або, для вiддаленого хоста, клiєнт контактує iз SCM цього хоста, який за локальним реєстром у файлi, асоцiйованим iз CLSID, запускає процес, який мiстить цей об'єкт.

• Сервер виконує маршалiнг вказiвника на iнтерфейс i повертає його клiєнту, який пiсля демаршалiнгу вказiвника передає його замiснику.

1. Робота з об’єктом (продовження)



14

4. Оброблення подiй в DCOM



15

1. У базовому DCOM пiдтримується синхронна взаємодiя пiд час звернення клiєнта до об'єкта з блокуванням до отримання вiдповiдi. Однак iснують засоби розширення такої взаємодiї за допомогою iнтерфейсу зворотного виклику, який пiдтримується зв'язувальними об'єктами, що можуть мiстити вказiвники на iнтерфейс зворотного виклику клiєнта.

Клiєнт надає вказiвник на iнтерфейс зворотного виклику пiд час прив'язки до зв'язувального об'єкта. Розблокування синхронного виклику можливе на основi об'єкта вiдмiни (cancel object), який реалiзує метод cancel.

2. Асинхронний виклик здiйснюється в разi активiзацiї клiєнта i об'єкта з використанням методiв begin_m та finish_m, якi генеруються MIDL.

Клiєнт виконує виклик методу begin_m, продовжуючи роботу. Результат звернення буферизується до моменту finish_m. Для об'єкта це припускається просто як звернення до методу m.

3. DCOM пiдтримує модель подiй пiд назвою "система публiкацiї/ пiдписки"(publish/ subscribe systems), за якою подiї групуються в класи подiй (event class), що мають свої iдентифiкатори CLSID i стандартну реалiзацiю. За умови пiдписання на подiї, поданої методом m_event, вказiвник передається на iнтерфейс методу в систему подiй.

1. Види передачі повідомлень



16

5. Оброблення подiй в DCOM



17

Передавання повiдомлень пiдтримує схоронний асинхронний зв'язок з використанням компонентiв черг QC (Queued Component), який являє собою iнтерфейс до системи черг повiдомлень MSMQ (Misrosoft Message Queuing). Асинхронний виклик для QC обмежується iнтерфейсами, що мiстять методи тiльки з вхiдними параметрами.

У разi прив'язування клiєнта до об'єкта, який мiстить методи з пiдтриманням QC, вказiвник повертається на iнтерфейс з асинхронним методом. Коли клiєнт звертається до такого методу, автоматично виконується маршалiнг i забезпечується локальне збереження звернення в пiдсистемi QC клiєнта. Пiсля завершення клiєнтом звертання i звiльнення iнтерфейсу збереженi методи передаються об'єкту через MSMQ.

Пiсля надходження повiдомлення про звернення до мiсця призначення пiдсистема QC викликає демаршалiнг звернення i об'єкт. Система MSMQ пiдтримує транзакцiйнi черги (transactional queues), зокрема вкладенi транзакцiї.

1. Misrosoft Message Queuing



18

Клiєнти пiдтримують стандартний i користувацький маршалiнги, якi визначають спосiб оброблення об'єкта замiсником.

За стандартного маршалiнгу для передавання IID (interface identifier) потрiбне лише завантаження коду маршалiнгу i побудова замiсника iнтерфейсу вiдправником.

У разi користувацького маршалiнгу результат маршалiнгу замiсника вiдправника передається отримувачу з подальшим демаршалiнгом замiсника з повiдомлення.

1. Маршалінг/демаршалінг



19

6. Пересилання посилання на об'єкт DCOM



20

На серверi об'єкта викликається менеджер SCM (service соntrol manager), якому передано iдентифiкатор CLSID з локального реєстру клiєнта. Менеджер SCM шукає CLSID у своєму локальному реєстрi пiсля створення екземпляра об'єкта класу. У SCM реєструється порт, з якого сервер буде отримувати вхiднi запити й iдентифiкатори нових об'єктiв. Ця iнформацiя прив'язки передається клiєнту, що дає змогу звертатися до об'єкта без втручання менеджера SCM.

1. Менеджер SCM (service соntrol manager)



21

За механiзмом активацiї JIT (just-in-time activation) сервер може вилучити об'єкт до припинення роботи з вiдповiдним клiєнтом, наприклад у разi обмеженої пам'ятi та потреби звiльнити мiсце для нових об'єктiв.

1. Механiзм активацiї JIT (just-in-time

activation)



22

Модель DCOM надає об'єкту низькорiвневi засоби iменувань, зокрема, вказiвники на iнтерфейси та посилання на схороннi об'єкти сумiсного використання кiлькома процесами - монiкерами (monikers). Монiкер мiстить iнформацiю вiдновлення об'єкта у станi його останнього використання клiєнтом.

Розрiзняють декiлька варiантiв монiкерiв, серед яких найбiльш вживаний файловий монiкер (file moniker) з посиланням на об'єкти, створенi з файлу локальної файлової системи. Файловий монiкер мiстить повне iм'я файлу, використовуваного для створення об'єкта i CLSID об'єкта класу.

1. Монікери



23

7. Прив'язування до об'єкта за допомогою монiкера

Крок Виконавець Опис

1 Клiєнт Прив'язування до об'єкта викликом методу Bindobject монiкера

2 Монiкер Пошук CLSID i вказiвка SCM створити об'єкт

3 SCM Завантаження об'єкта класу

4 Об'єкт класу Створення об'єкта класу i повернення посилання на iнтерфейс

5 Монiкер Указання об'єкта завантажити ранiше збережений стан

6 Об'єкт Завантаження з файлу свого стану

7 Монiкер Повернення клiєнту вказiвника на iнтерфейс об'єкта



24

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

Клiєнту повертається вказiвник за запитаний ним iнтерфейсом, що завершує операцiю прив'язування. Монiкер реєструє пов'язаний з ним об' єкт у таблицi запущених об'єктiв ROT (Running Object Table) клiєнтської машини. Саме цей об'єкт шукає монiкер передусiм у разi прив'язування до об'єкта, забезпечуючи сумiсне використання кiлькома процесами через створення екземпляра.

1. Робота монікерів



25

• монiкер URL з посиланням на об'єкти, створенi з URL;

• монiкер класу з посиланням на об'єкт класу; • композитний монiкер з посиланням на композицiю

монiкерiв; • монiкер елемента з посиланням на монiкер

композицiї; • монiкер вказiвника з посиланням на об'єкт

вiддаленого процесу.

1. Види монікерів



26

8. Органiзацiя Active Directory



27

1. Розподiлена система DCOM.

Питання заняття


Питання?

Розподілені інформаційні системи

www.simulation.kiev.ua/dis/

Лекція 07. Розподілена система dcom

Documents