ЛЕКЦІЯ 22. РОЗПОДІЛЕНІ МОДЕЛІ ПРОМІЖНОГО РІВНЯ ДЛЯ WINDOWS
План
22.1. Особливості COM
22.1.1. Основні поняття COM
22.1.2. Технологія ActiveX – основні можливості
22.2. Особливості DCOM
22.2.1. Основні поняття DCOM
22.2.2. Служби (сервіси) DCOM
22.3. MicrosoftTransactionServer
22.4. Особливості COM+
22.4.1. Основні поняття COM+
22.4.2. Служби (сервіси) COM+
Для спрощення розробки і інтеграції компонентних програмних систем, основна частина проміжного ПЗ повинна базуватися на деякій моделі, що визначає розподіл і зв'язок. Найпростіша рання модель – представлення всіх об'єктів у вигляді файлів (розподілена файлова система). Приклад – файлова система Unix.
Друга рання модель заснована на віддалених викликах процедур (Remote Procedure Calls, RPC). У цій моделі акцент робиться на приховуванні мережевого обміну за рахунок того, що процесу дозволяється викликати процедури, реалізація яких знаходиться на віддаленій машині. При виклику процедури параметри передаються на віддалену машину, де вона виконується, після чого управління передається в точку виклику процедури. Зовні це виглядає як звичайний виклик процедури.
Сучасні моделі базуються на взаємодії розподілених об'єктів. Ідея розподілених об'єктів полягає в тому, що кожен об'єкт реалізує інтерфейс, що приховує всі внутрішні деталі реалізації об'єкту від користувача. Інтерфейс містить методи, що реалізуються об'єктом, і все, що бачить процес – це інтерфейси.
Як вже зазначалося, найбільш відомими компонентними моделями є - COM (Component Object Model) (DCOM – розподілена компонентна модель, COM+), .Net, Java Beans, CORBA.
1. Component Object Model (COM) – початковий стандарт Microsoft для компонентів. Визначає протокол для конкретизації і використання компонентів усередині процесу, між процесами або між комп'ютерами. Основа для ActiveX, OLE і багатьох інших технологій. Може використосуватися в Visual Basic, C++ і ін.
2. Java Beans – стандарт Sun Microsystems для компонентів (тільки для Java)
3. CORBA (стандарт OMG, має громіздкий IDL-інтерфейс, складність відображення однієї мови реалізації в іншу).
22.1. Особливості COM
1. Компонентна модель COM (Component Object Model) є спадкоємцем засобів динамічного зв'язування даних DDE (Dynamic Data Exchange), що були ще в найперших версіях Microsoft Windows. Вона дозволяє розбити програму, що працює на окремому ПК, на компоненти, що характеризуються чітко визначеними інтерфейсами. Таким чином, за допомогою цієї моделі можна організувати розподілену систему в рамках одного ПК. Ця модель з'явилася в Windows 95.
2. Розподілена компонентна модель DCOM (Distributed Component Object Model) - розширення СОМ до рівня мережевих програм і включає середовище розподілених обчислень DCE (Distributed Computing Environment) і механізм віддаленого виклику процедур (RPC — Remote Procedure Calling).
3. Модель СOM+ - розширення DCOM можливостями розподіленої обробки транзакцій (MTS). Призначена для створення систем, розподілених в локальній мережі. Основною метою розробки COM+ було створення інфраструктури для розробки розподілених систем автоматизації підприємства. З'явилася в Windows 2000.
COM+/MTS = DCOM + MTS – спільне використання DCOM і MTS (MicrosoftTransactionServer).
Ці моделі передували появі .Net Framework. Хоча сьогодні ці компоненті моделі є застарілими, вони ще використовуються в WindowsXP, тому розглянемо їх більш детально.
22.1.1. Основні поняття СОМ
Визначення. Модель СОМ (Component Object Model) або її ще називають Модель багатокомпонентних об'єктів – це програмна модель, яка визначає набір правил, за якими повинні будуватися компоненти. Тільки при дотриманні цих правил компоненти забезпечують коректне і надійне функціонування.
В моделі СОМ Компонент - це сховище (у вигляді DLL або EXE файлу) для одного або декількох класів. Все, що знає програма-клієнт про клас, це його унікальний ідентифікатор і один або декілька інтерфейсів, які забезпечують доступ до реалізованих даним класом методів. Допускається реалізація компонента і програми-клієнта на різних мовах (Visual C++, Visual Basic). У реєстрі системи зберігається інформація про місце розташування компонента, який містить клас. Це дозволяє системі прозоро для клієнта перенаправляти виклики методів до потрібного компонента і повертати результати.
Таким чином, забезпечується виконання двох важливих принципів компонентного програмування:
- незалежність від мови програмування;
- прозорість місця розташування сервера для клієнта.
Модель СОМ складається з набору стандартних функцій і специфікацій (стандартів обміну, стандартів виклику функцій), які забезпечують розробку програм. Вона реалізована у вигляді DLL-бібліотек.
Правила визначають стандартний внутрішній інтерфейс між об'єктами і методику взаємодії об'єктів, а саме – виклик функцій і обмін даними між об'єктами.
Кожний інтерфейс, який підтримується об'єктом є контрактом між цим об'єктом і його клієнтами. Вони зобов'язуються: об'єкт — підтримувати методи інтерфейсу в точній відповідності з визначеннями останнього, а клієнт — коректно викликати методи. Щоб контракт був працездатним, об'єкт і його клієнти повинні домовитися про спосіб явної ідентифікації кожного інтерфейсу, про загальний спосіб специфікації методів інтерфейсу, а також про конкретну реалізацію інтерфейсу.
Модель СОМ існує у вигляді бібліотек, що компонуються з процесом.
Спочатку вона розроблялася для підтримки так званих складених документів (compound documents). Складені документи — це документи, побудовані з різнорідних частин, таких як текст (форматований), зображення, електронні таблиці і тому подібне. Кожна з цих частин може бути відредагована за допомогою асоційованого з нею застосування.
Модель СОМ побудована за принципом «клієнт-сервер».
Клієнтом є програма, яка викликає функції компоненту або використовує його дані.
Кожний об'єкт СОМ реалізований усередині деякого серверу, що містить код, який реалізує методи інтерфейсів об'єкта, а також контролює дані об'єкту, поки той активний. Один сервер може підтримувати (і часто підтримує) більше одного об'єкта деякого класу і навіть підтримувати декілька класів.
Сервери об'єктів СОМ. Розглянемо три основні типи серверів:
1. Сервер "в процесі" (in-рrocess): об'єкти реалізуються в DLL-бібліотеці, і, таким чином, виконуються в тому ж процесі, що і клієнт.
2. Локальний сервер (out-рrocess): об'єкти реалізовані в окремому процесі, що виконується на тому самому комп'ютері, що і клієнт.
3. Віддалений сервер: об'єкти реалізовані в DLL або в окремому процесі, які розташовані на віддаленому по відношенню до клієнта комп'ютері.
Можливість створення віддалених серверів підтримує Розподілена модель СОМ (DCOM).
Важливість і універсальність моделі СОМ полягає в тому, що з погляду клієнта, об'єкти, реалізовані в будь-якому з трьох видів серверів, виглядають однаково; доступ до методів об'єктів клієнт як і раніше здійснює за допомогою інтерфейсів.
22.1.2. Технологія ActiveX – основні можливості
Модель COM використовується як фундамент технологій компонентного програмування, які раніше називалися DDE, OLE Automation, ActiveX.
В даний час технологія ActiveX (технологія активних об'єктів) об’єднує декілька технологій, які базуються на моделі СОМ. Основне призначення ActiveX – забезпечення простої взаємодії компонентів в компонентній системі. Ця технологія зараз швидко розвивається у напрямі розширення типів об'єктів, які нею підтримуються і послуг, що надаються.
Основні технології, що входять зараз до ActiveX (рис. 22.1):
- OLE (Object Linking and Embeding) – технологія зв’язування і вставки об'єктів одного застосування в інше;
- Automation – технологія управління вставленими об'єктами і об'єктами інших застосувань;
- ADO (ActiveX Data Object) – технологія універсального доступу до різних джерел даних;
- елементи управління ActiveX – технологія створення елементів управління ActiveX (власних компонентів);
- документи ActiveX - технологія створення документів, працюючих в InternetExplorer, і перетворення документів у стандарт документів ActiveX;
- Active Server Pages – технологія створення і виконання сценаріїв на web-серверах.
- Remote Automation – технологія віддаленого управління і ряд інших.
Рис. 22.1. Загальна структура ACTIVEX, OLE і СОМ
Технологія OLE – зв'язування і вставка об'єктів
Типовий приклад цієї технології – вставка і зв'язування документів різних офісних застосувань (Word, Excel, PowerPoint).
22.2. Особливості моделі DCOM
22.2.1. Основні поняття DCOM
Розподілена компонентна модель об'єктів (DCOM) - це набір стандартів побудови, розміщення і взаємодії компонентів і механізмів, що реалізують їх, які дозволяють об'єктам усередині компонентів посилати виклики іншим компонентам, а також приймати і обробляти запити від інших компонентів незалежно від їх положення на комп'ютері або в мережі, від способів реалізації.
Вона поширює принципи виклику віддалених процедур (RPC) на об'єктні застосування COM. У DCOM взаємодія віддалених об'єктів базується на специфікації Distributed Computing Environment Remote Procedure Call (DCE RPC). Середовище приховує від клієнта деталі мережевої взаємодії.
DCOM розширює модель СОМ включенням 3-х основних елементів:
- способу створення віддаленого об'єкту;
- протоколу виклику методів цього об'єкту;
- механізмів забезпечення безпечного доступу до об'єкту.
DCOM надає декілька варіантів ідентифікації віддалених машин залежно від мережевих протоколів, вживаних для доступу до віддаленої системи. DCOM підтримує доменні імена, використовувані TCP/IP, а також адреси IP (Internet Protocol), імена NETBIOS і імена, які використовуються в NetWare IPX/SPX (рис. 22.1).
Рис. 22.2. Загальна архітектура DCOM
Для того, щоб активізувати об'єкт, тобто гарантувати, що він створений і поміщений в процес, з якого зможе приймати звернення до методів, DCOM використовує реєстр Windows в комбінації із спеціальним процесом — менеджером управління службами (Service Control Manager, SCM).
Сервер об'єктів містить заглушку для маршалінга і демаршалінга запитів, які він передаватиме реальному об'єкту. Зв'язок між клієнтом і сервером зазвичай реалізується шляхом викликів RPC, але, можуть бути використані і інші способи зв'язку.
Нагадаємо, що:
Маршалінг (від англ. Marshal — упорядковувати) — процес перетворення представлення об'єкту в пам'яті у формат даних, придатний для зберігання або передачі. Зазвичай застосовується коли дані необхідно передавати між різними частинами однієї програми або від однієї програми до іншої.
Протилежний процес називається демаршалінгом (або десеріалізацією).
Маршалінг задіюється при використанні різних механізмів RPC, де є необхідність в передачі даних між процесами і потоками.
Модель DCOM задає тип і структуру інтерфейсів, які забезпечують взаємодію компонентів в розподіленому середовищі. Кожен компонент в моделі DCOM повинен мати принаймні один інтерфейс, що підтримує основні механізми інтерфейсних посилань. У DCOM реалізований механізм повідомлення про події. Передбачені інтерфейси для доступу до метаданих, наявних в бібліотеці типів Type Library. Інтерфейс доступу до бібліотеки типів дозволяє динамічно виявляти інтерфейси і забезпечувати взаємодію компонентів в процесі виконання.
Інтерфейси компонентів DCOM описуються на мові Interface Definition Language (IDL), розробленій консорціумом Open Software Foundation (OSF).
Середовище компонентної розробки, базоване на моделі DCOM, підтримує розробку компонентів на трьох мовах - VisualBasic, VisualC++ і J++ (мова Java, реалізована Microsoft). Візуальна розробка компонентів підтримується за допомогою сторінок властивостей компонентів (property sheet) - вбудованих редакторів властивостей і їх агрегованих наборів. Саме середовище розробки і виконання компонентів є додатком, побудованим також на основі моделі DCOM, завдяки чому її можна розширювати за допомогою стандартних механізмів DCOM.
Платформа розподілених компонентів на базі моделі DCOM використовує ОС Windows NT і вище.
22.2.2. Служби (сервіси) DCOM
У складі служб середовища розподіленої обробки даних в цій платформі передбачені:
- протокол віддаленого зв'язку, що використовує механізм віддаленого виклику процедур RPC, реалізований Microsoft на основі стандартної специфікації RPC DCE (Distributed Computing Environment). Цей протокол забезпечує зв'язок розподілених компонентів через стандартний механізм посередників (proxy) і перехідників (stub);
- служба каталогів Microsoft Active Directory, яка об'єднує систему іменування DNS (Domain Name System) і протокол LDAP (Lightweight Directory Access Protocol);
- служба безпеки, що підтримує протокол SSL (Secure Sockets Layer), - він забезпечує захист даних на базі механізму відкритих ключів;
- служба системного адміністрування, що підтримує механізми моніторингу і контролю ресурсів і служб в розподіленому середовищі;
- служба розподіленої обробки транзакцій у вигляді сервера Microsoft Transaction Server (MTS), який інтегрує службу транзакцій в модель розробки компонентів і надає серверним компонентам транзакційне середовище виконання.
Забезпечення безпечного доступу до віддаленого об'єкту
Об'єктний RPC надає клієнтам спосіб створення віддалених об'єктів і виклику їх методів. Але можливість доступу до об'єктів на інших системах підвищує ризик створення або використання таких об'єктів процесами або особами, що не мають відповідних прав. Для мінімізації подібного ризику DCOM визначає стандартний спосіб доступу до служб захисту і їх використання.
Тут мають місце дві проблеми.
Перша полягає в контролі над тим, хто має право запускати сервери різних класів на даній віддаленій машині — це сфера дії захисту активізації (activation security).
Друга проблема полягає в тому, щоб гарантувати контроль прав на виклики клієнтами методів об'єктів, що вже виконуються, відома як захист викликів (call security). DCOM надає рішення обох проблем.
Захист активізації
Параметри реєстру машини в точності визначають, хто має право запуску серверів на даному комп'ютері. Загальніша установка вирішує або забороняє віддалену активізацію взагалі. Якщо вона відключена, жоден віддалений клієнт не зможе запускати сервери або під'єднуватися до якого-небудь об'єкту на даній машині. Можливо також визначення захисту активізації на рівні класу, що дозволяє контролювати, які віддалені клієнти мають право на запуск сервера деякого класу. Перелік тих, що мають дозвіл на це містить список управління доступом (access control list — ACL). І нарешті, до класів, для яких не встановлений захист активізації на рівні класу, може застосовуватися захист активізації за замовчанням. Як і при захисті активізації на рівні класу, захист активізації за замовчанням визначає тих, хто має право на запуск сервера в даній системі, за допомогою ACL.
Захист викликів
Після створення об'єкт готовий до прийому викликів своїх методів від клієнтів. Коли останні виконуються на інших комп'ютерах, можна задіювати ряд служб контролю доступу, найважливіші з яких:
- аутентифікація дозволяє упевнитися, що користувач саме той, за кого себе видає. За допомогою аутентифікації об'єкт достовірно визначає особу клієнта. Якщо підтримується взаємна аутентифікація, то і клієнт може бути упевнений в тому, що сервер є саме тим за кого себе видає;
- авторизація дозволяє визначити, що клієнт має право робити. Для ухвалення подібного рішення об'єкт може використовувати будь-яку схему;
- цілісність даних гарантує, що прийняті по мережі дані не були змінені при пересилці. У відсутність цієї служби хтось міг би "виловити" пакет з мережі, змінити його і послати первинному реципієнтові, причому останній не помітив би підміни;
- секретність даних гарантує, що дані, які пересилаються по мережі не будуть прочитані при передачі. Зазвичай для цього використовується шифрування даних, що може істотно знизити продуктивність.
Служби захисту можуть забезпечуватися різними механізмами. У зв'язку з великою кількістю механізмів, що забезпечують захист викликів, розробники DCOM зіткнулися з проблемою їх вибору. Було вирішено не вибирати якийсь один, а визначити загальні інтерфейси, здатні працювати з багатьма з існуючих варіантів. Проте, перша версія DCOM, випущена в 1996 році, підтримує лише механізми захисту Windows NT.
Переваги і недоліки моделі DCOM
Переваги
|
Недоліки
|
22.3. MicrosoftTransactionServer
MicrosoftTransactionServer(MTS) є сервером підтримки роботи застосувань, які входять до складу ПЗ проміжного рівня. Він здійснює автоматичне управління процесами і потоками, має вбудовані служби безпеки для контролю викликів і використання об'єктів, забезпечує підтримку розподілених транзакцій і надає графічний інтерфейс для реєстрації і управління компонентами (MTSExplorer), тобто фактично надає готові засоби вирішення завдань системного програмування, які виникають при розробці ПЗ проміжного рівня (middleware).
Він пропонує всі стандартні функції монітора транзакцій. Важливою властивістю MTS є те, що властивості транзакційності задаються на рівні контейнера COM. Крім того, в Windows входить служба Distributed Transaction Service, що відповідає за координацію розподілених транзакцій в базах даних.
MTS був однією з перших комерційних систем, що комбінували підтримку транзакцій і компонентів. Застосування, керовані MTS, є набіром COM-компонентів, оформлених у вигляді DLL-бібліотек. З технічної точки зору є декілька служб ОС, які контролюють роботу ініційованих компонентів COM і відповідають виклики з компонентів. Ці служби забезпечують автоматичну підтримку транзакцій, забезпечення безпеки, утворення пулів з'єднань з БД, підтримку потоків виконання і управління станом об'єктів.
Середовище DCOM/MTS зручне для створення розподілених застосувань, але прив'язане до платформи Windows, що не завжди прийнятно для корпоративних рішень.
22.4. Особливості COM+
22.4.1. Основні поняття COM+
COM+ – проміжне середовище для створення розподілених систем, що працюють в локальній мережі. Вона розробляється фірмою Microsoft з кінця 90-х років і вперше з'явилася у складі Microsoft Windows 2000. Основною метою розробки COM+ було створення інфраструктури для розробки розподілених систем рівня автоматизації підприємства (Enterprise Services). Основні переваги COM+.
Середовище COM+ управляє ходом виконання об'єктів COM+, компонентів COM+, що є екземплярами. Набор зв'язаних компонентів COM+, що знаходяться в одній динамічній бібліотеці, називається застосуванням COM+.
Застосування COM+ складається з набору компонентів і ролей для доступу до них. Відомості про зареєстровані застосування зберігаються в каталозі COM+.
Застосування COM+ бувають двох видів: бібліотечні і серверні.
Екземпляри компонентів бібліотечних застосувань виконуються в тому ж процесі, що і клієнт (in-process) який їх використовує, компоненти серверного – в окремому потоці сервера (out-process), що можливо виконується на віддаленому комп'ютері. Лише серверні застосування можуть використовуватися віддалено (remote server) шляхом реєстрації в каталозі COM+ на комп'ютері клієнта-посередника застосування COM+. Після встановлення посередників використання віддалених серверних компонентів COM+ не відрізняється від використання локальних.
На рис. 22.3. показана архітектура COM+ при використанні серверних застосувань. Об'єкти COM+ є екземплярами компонентів COM+, зареєстрованих в каталозі. Заглушка на стороні серверного процесу називається в COM+ перехоплювачем (interceptor).
Рис. 22.3. Архітектура COM+
Каталог COM+ кожного комп'ютера містить список зареєстрованих на комп'ютері локальних застосувань COM+, а також список встановлених посередників для зв'язку з застосуваннями віддалених комп'ютерів. Каталог влаштований ієрархічно, у вигляді дерева. Наприклад, вузол з описом застосування COM+ містить вузол із списком компонентів COM+, які входять до нього і вузол із списком ролей застосувань.
Середовище COM+, як і інші моделі (COM, DCOM) зручне для створення розподілених застосувань, але прив'язане до платформи Windows, що не завжди прийнятно для корпоративних рішень. Важливі проблеми, що виникають при побудові Windows-застосувань, — проблеми надійності, продуктивності і контролю версій використовуваних бібліотек компонентів (і пов'язаних з ними бібліотек DLL). Ці проблеми і покликана була вирішити нова компонентна модель, .NetFramework.
22.4.2. Служби (сервіси) COM+
Метою створення проміжного середовища COM+ було надання компонентам COM+ набору служб, що полегшують створення надійної і масштабованої розподіленої системи. Починаючи з Windows 2003/XP SP2, частина цих служб може бути доступна і без створення компонентів COM+, шляхом використання так званих служб без компонентів.
Переваги COM+
Синхронізація
Середовище COM+ дозволяє виключити проблеми з синхронізацією при обслуговуванні запиту клієнта шляхом так званих активностей. Активність починається у момент створення клієнтом COM+ об'єкту і закінчується при його видаленні. Протягом активності клієнт викликає методи компонента COM+, в ході яких може створювати інші об'єкти COM+, у тому числі розташовані на віддалених комп'ютерах, і викликати їх методи. При цьому COM+ гарантує, що протягом однієї активності в кожен момент виконується метод лише одного COM+ об'єкту з тих, що беруть участь в активності. Таким чином, активність є деяким логічним потоком. Об'єкти COM+ можуть як брати участь в активності (вимагати синхронізації), так і не брати участь, залежно від атрибутів відповідного компонента COM+ і поточного контексту при їх створенні.
Балансування навантаження
COM+ підтримує динамічне балансування навантаження. Для цього необхідно створити кластер COM+ на базі серверної версії операційної системи Microsoft Windows (Windows 2000 Advanced Server і подальших). Кластер COM+ складається з декількох серверів і маршрутизатором COM+, який розподіляє між ними запити. Для підвищення надійності такої системи можуть застосовуватися способи швидкої заміни маршрутизатора при його виході з роботи на базі Windows Clustering Services. Таким чином, середовище COM+ дозволяє за наявності достатніх фінансових ресурсів створити добре масштабовану систему без унікальної точки збою.
Just-in-time-активация і пул об'єктів
Середовище COM+ підтримує два види активації об'єктів – активація на вимогу клієнта і активація на час єдиного виклику з можливістю використання пулу об'єктів.
Розподілені транзакції
Одним з основних достоїнств середовища COM+ є підтримка розподілених транзакцій на базі координатора розподілених транзакцій. Налаштування транзакції компонента COM+ впливають на налаштування синхронізації і активації.
Відкладені компоненти
Для реалізації асинхронного віддаленого виклику в середовищі COM+ існують так звані відкладені (чекаючі) компоненти (queued componenets), які прозоро використовують MSMQ (черги повідомлень). Використання такого компонента подібно до асинхронного віддаленого виклику (рис. 14.
Рис. 22.4. Використання відкладених компонентів COM+
1. На початку використання відкладеного компонента на стороні клієнта створюється посередник, званий протоколистом (recorder), який зберігає історію викликів компонента.
2. Після завершення використання компонента, якщо не сталося відкату транзакції, протоколіст формує повідомлення MSMQ зі всіма викликами компоненти.
3. На стороні сервера повідомлення MSMQ очікується слухачем (listener), який не є COM+ компонентом. При появі повідомлення в черзі він створює спеціальну COM+ компонент, так званий помічник слухача (listener helper), який прочитує повідомлення з черги.
4. Після прочитування повідомлення помічник слухача створює виконавець (player), який і створює сам екземпляр відкладеного компонента, відтворюючи потім послідовність його викликів в рамках тієї ж транзакції. З точки зору відкладеного компонента виконавець є звичайним клієнтом.
Аналогічним чином відбувається отримання результату виклику віддаленого компонента: на сервері створюється протоколіст, а на клієнті – слухач і виконавець. Проте в цьому випадку до початку використання віддаленого компонента клієнту слід створити об'єкт (call-back object), що викликається, який прийматиме відповідь від сервера через виконавця, і передавати посилання на такий об'єкт (точніше, на його виконавця), серверу (рис. 22.5.).
Рис. 22.5. Взаємодія з відкладеним компонентом
Недоліки COM+
Хоча COM+ має обширні можливості для створення розподілених систем рівня підприємства, їй властиві і наступні недоліки:
1. Середовище COM+ розроблене до .NET Framework, тому в середовищі Enterprise Services існують обмеження на класи .NET Framework, що реєструються у якості обслуговуваних компонентів. При використанні компонентів Enterprise Services виявляються деякі особливості роботи з ними, що є наслідком складної взаємодії CLR і COM+.
2. Компоненти COM+ не можуть використовуватися поза довіреною мережею, оскільки для їх використання має бути відкритий, зокрема, доступ до порту RPC (135-й порт TCP). З цим портом пов'язаний великий і, ймовірно, ще незавершений список загальновідомих вразливостей.
Висновки
Моделі проміжного рівня утворюють каркас компонентної програмної системи. Вони містять набір важливих загальносистемних програмних засобів (сервісів) для спрощення розробки і інтеграції розподілених систем. Ці сервіси утворюють проміжний шар ПЗ між функціями ОС і прикладним ПЗ.
В цій лекції ми розглянули моделі проміжного рівня, які розроблені для ОС Windows. Ці моделі хоча і використовуються, мають низку недоліків.
Компонентна модель .NetFrameworkвирішує багато з цих проблем, надаючи зручніші і безпечніші засоби розробки і інтеграції компонентів.
Контрольні запитання і завдання для самостійного виконання
1. Яка різниця між моделями COM, DCOM, COM+?
2. Особливості моделі COM?
3. Особливості моделі DCOM?
4. Особливості моделі COM+?
5. Типи серверів, реалізовані в моделі COM та їх призначення?
6. Основні технології, що входять до ActiveX?
7. Основні служби моделі DCOM?
8. Призначення і основні функції MicrosoftTransactionServer?
9. Переваги моделі COM+?
10. Взаємодія з відкладеним компонентом в COM+?
(Для ознайомлення з повним текстом статті необхідно залогінитись)