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


НазваЛекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Дата конвертації10.04.2013
Розмір445 b.
ТипЛекція


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

  • Діденко Дмитро Георгійович

  • Старший викладач кафедри ММСА ННК «ІПСА»

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

  • «Київський політехнічний інститут»

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


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

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



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

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



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

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



1. Windows API

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



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

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



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



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

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



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).



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нтерфейси.



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



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 або бути частиною додатка.



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снику.



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



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й.



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



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ї.



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домлення.



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



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.



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

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



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 об'єкта класу.



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



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лькома процесами через створення екземпляра.



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

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

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

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

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

  • монiкер вказiвника з посиланням на об'єкт вiддаленого процесу.



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



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

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



Питання?

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

  • www.simulation.kiev.ua/dis/



Схожі:

Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 01. Структура І основні задачі створення розподілених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Визначення розподіленої системи Розподілена система це комплекс незалежних комп'ютерів, які користувач сприймає як єдину об'єднану...
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 06. Промисловий стандарт corba діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Першi версiї специфiкацiї з'явились на початку 90-х рокiв. Поширеними є версiї 4 i 3
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Прототипом системи є система afs на 10000 робочих станцiй I має ту ж саму afs virtue органiзацiю
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 03. Програмне забезпечення проміжного рівня Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Концепції програмних рішень Основними програмними компонентами рiс є ос I системи промiжного рiвня
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 04. Зв'язок процесів на рівні протоколів Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Т. к. Ріс побудовані з використанням принципа відкритості, то використовуються стандартні протоколи обміну даними між процесами
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 12. Моделi I системи узгодження Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Типи моделей узгоджень Системи узгодження передбачають вiддiлення обчислювальних процесiв вiд механiзмiв їх узгодження
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 05. Зв'язок на основі повідомлень І потоків Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Зв'язок на основi повiдомлень Зв'язок на пiдставi повiдомлень дозволяє уникнути блокування клiєнта у процесi здiйснення операцiї,...
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 15. Розподiлене пiдтвердження та вiдновлення процесiв Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Розподiлене пiдтвердження (Distributed commit) являє собою бiльш загальне завдання порiвняно з атомарним груповим розсиланням i передбачає...
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 09. Файлова система nfs діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Мережева файлова система nfs (Network File System) компанiї Sun Microsystems надає клiєнту набiр протоколiв подання розподiленої...
Лекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 11. Розподiленi системи документiв Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
За стандартизацiю протоколiв удосконалення мiжоперацiйної взаємодiї та удосконалення систем на основi World Wide Web (www) з 1994...

Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка