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

1. Лекція 07. Розподілена система DCOM Діденко Дмитро Георгійович Старший викладач кафедри ММСА ННК «ІПСА» Національний технічний університет України «Київський політехнічний інститут» м. Київ, Україна

2. Питання заняття • Розподiлена система DCOM. Розподілена система DCOM

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

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

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

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

7. 2. Структури ActiveX, OLE, COM Розподілена система DCOM

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

9. 1. Відміна DCOM та CORBA 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). Розподілена система DCOM

10. 1. Відміна DCOM та CORBA (продовження) 2. Об'єкт DCOM створюється як екземпляр класу, доступ до якого здiйснюється за допомогою об'єкта класу. Пiсля створення екземпляра об'єкта класу стає можливим доступ до методiв iнтерфейсу. Кожний об'єкт класу має глобальний унiкальний iдентифiкатор класу CLSID (Class Identifier). 3. Об'єкти є нерезидентними, на вiдмiну вiд CORBA, i тому вилучаються, якщо немає посилань на об'єкт. Тому сам об'єкт не може мати глобального унiкального iдентифiкатора, а може викликатись лише за вказiвниками на iнтерфейси. Розподілена система DCOM

11. 3. Використання бiнарних iнтерфейсiв Розподілена система DCOM

12. 1. Робота з об’єктом • Ус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 або бути частиною додатка. Розподілена система DCOM

13. 1. Робота з об’єктом (продовження) • Для актив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снику. Розподілена система DCOM

14. 4. Оброблення подiй в DCOM Розподілена система DCOM

15. 1. Види передачі повідомлень 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й. Розподілена система DCOM

16. 5. Оброблення подiй в DCOM Розподілена система DCOM

17. 1. Misrosoft Message Queuing Передавання пов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ї. Розподілена система DCOM

18. 1. Маршалінг/демаршалінг Кл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домлення. Розподілена система DCOM

19. 6. Пересилання посилання на об'єкт DCOM Розподілена система DCOM

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

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

22. 1. Монікери Модель 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 об'єкта класу. Розподілена система DCOM

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

24. 1. Робота монікерів У загальному випадку мон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лькома процесами через створення екземпляра. Розподілена система DCOM

25. 1. Види монікерів • монiкер URL з посиланням на об'єкти, створенi з URL; • монiкер класу з посиланням на об'єкт класу; • композитний монiкер з посиланням на композицiю монiкерiв; • монiкер елемента з посиланням на монiкер композицiї; • монiкер вказiвника з посиланням на об'єкт вiддаленого процесу. Розподілена система DCOM

26. 8. Органiзацiя Active Directory Розподілена система DCOM

27. Питання заняття • Розподiлена система DCOM. Розподілена система DCOM

28. Питання? Розподілені інформаційні системи www.simulation.kiev.ua/dis/