- •Розподілені системи обробки інформації
- •Передмова
- •Розділ 1. Огляд компонентних технологій створення розподілених програмних систем
- •1.1. Узагальнена архітектура і механізм функціонування об'єктних розподілених систем
- •1.2. Основні приклади технологій створення розподілених систем
- •1.3. Переваги використання розподілених технологій
- •Розділ 2. Розроблення розподілених систем на основі модели com/dcom у Delphi
- •2.1. Використання dll у Delphi
- •2.1.1. Поняття dll
- •2.1.2. Створення dll у середовищі Delphi (експорт)
- •2.1.3. Використання dll у Delphi (імпорт)
- •2.1.4. Створення динамічних бібліотек для редагування ресурсів
- •2.2. Основи сом-технології
- •2.2.1. Загальний опис
- •2.2.2. Базові поняття
- •2.2.3. Бібліотека сом
- •2.2.4. Бібліотека типів
- •2.3.2. Сервер сом у Delphi
- •2.3.3. Бібліотека типів у delphі
- •2.4. Створення системи клієнт-сервер на основі базового com-об’єкту у складі внутрішнього сервера
- •2.4.1. Створення сом-сервера
- •2.4.2. Створення сом-клієнта
- •2.4.3. Використання сом-об’єкту в клієнтській програмі
- •2.5. Механізм міжпроцесного обміну
- •2.6. Створення систем клієнт-сервер на основі зовнішнього базового сом-об’єкту
- •2.6.1. Основні поняття
- •2.6.2. Засоби організації потокової взаємодії клієнта і сервера
- •2.6.3. Методи формування екземпляра сом-об’єкту
- •2.6.4. Формування екземпляра зовнішнього сом-об’єкту
- •2.6.5. Створення сом-сервера
- •2.6.6. Створення сом-клієнта
- •2.7. Автоматизація
- •Створення сервера автоматизації;
- •2.7.1. Базові поняття
- •2.7.2. Сервер автоматизації
- •2.7.3. Контролер автоматизації
- •2.8. Створення системи клієнт-сервер на основі внутрішнього сервера автоматизації
- •2.8.1. Об'єкт автоматизації. Клас tAutoObject
- •2.8.2. Вбудований сервер автоматизації
- •2.8.3. Створення клієнта автоматизації
- •2.9. Зовнішній сервер автоматизації
- •2.9.1. Основні визначення
- •2.9.2. Виконання маршалінгу з рядками, шрифтами і зображеннями
- •2.9.3. Перетворення наявного застосунка в сом-сервер автоматизації
- •2.9.4. Створення клієнта автоматизації
- •2.10. Події в сом і зворотні виклики на основі інтерфейсів диспетчирування
- •2.10.1. Створення сервера автоматизації
- •3. Формування бібліотеки типів
- •4. Формування методів
- •5. Реєстрація сервера
- •2.10.2. Створення клієнтського застосунка
- •2.10.3. Підключення множини клієнтів до сервера
- •2.11. Інтерфейси зі зворотним викликом
- •2.11.1. Створення сервера
- •2.11.2. Створення клієнтського застосунка
- •2.12. Технологія ActiveХ
- •2.12.1. Використання готових елементів АctiveХ
- •2.12.2. Розроблення власних елементів АctiveХ
- •2.12.3. Поширення елементів керування ActiveХ і форм ActiveХForm у Web-середовище
- •2.14. Dcom технологія
- •2.14.1. Загальна схема взаємодії сом-клієнта і сом-сервера
- •2.14.2. Розроблення системи «клієнт-віддалений сом-сервер»
- •Розділ 3. Проектування розподілених систем на платформі Microsoft .Net
- •3.1.1. Здійсненя викликань з типів .Net до типів сом
- •3.1.2. Звернення клієнта сом до збірки .Net
- •3.2. Об’єктно-орієнтована архітектура .Net Remotіng – основа створення розподілених систем Mіcrosoft .Net.
- •3.2.1. Створення системи клієнт-сервер на основі технології Remoting
- •Розділ 4. Створення системи "клієнт - сервер" на основі технології corba
- •4.1. Загальні теоретичні відомості
- •4.2. Створення серверного застосунка
- •1. Створення файла опису інтерфейсу
- •Викликання конструктора створення corba сервера
- •Формуємо модуль Unit1
- •Формуємо реалізацію методу
- •4.3. Створення клієнтського застосунка
- •Викликання конструктора corba-клієнта
- •2. Формування форми
- •3. Запуск застосунка
- •Приклад програмних кодів сервера
- •4.4. Порівняльний аналіз технологій сом і соrва
- •4.4.1. Основні принципи об'єктних моделей
- •4.4.2. Об'єктні моделі
- •4.4.3. Підтримка операційних систем
- •4.4.4. Формальний опис архітектури і проблеми реалізації
- •4.4.5. Підсумки порівняння
- •Літературні джерела
2.14. Dcom технологія
Технологія DCOM (Distributed Component Object Model) дозволяє створити систему клієнт-сервер, яка працює на основі технології СОМ, за умови розташування СОМ-клієнта і СОМ-сервера на різних комп'ютерах, що включені у локальну або глобальну мережу. Технологія дозволяє клієнту викликати процедури, які виконуються у рамках іншого процесу.
2.14.1. Загальна схема взаємодії сом-клієнта і сом-сервера
Для здійснення міжпроцесної взаємодії COM-технологія використовує механізм локального виклику процедури (Local Procedure Call, LPC). LPC – це засіб зв'язку між процесами на одній машині. LPC являє собою спеціалізований засіб зв'язку між різними процесами в межах однієї машини, побудований на основі механізму віддаленого виклику процедури (Remote Procedure Call, RPC).
Механізм LPC використовується практично при будь-якому викликанні функції Win32. Виклик функції Win32 викликає функцію в DLL, що через LPC викликає код Windows, фактично виконуючи роботу. Така процедура ізолює програму, що перебуває у своєму процесі, від коду Windows. Оскільки у різних процесів різні адресні простори, програма не зможе зруйнувати операційну систему.
COM використовує досить схожий механізм. Клієнт взаємодіє з DLL, що являє собою компонент. Ця DLL виконує за клієнта маршалінг і виклики LPC. У СОМ такий компонент називається заступником (proxy). У термінах СОМ, заступник – це компонент, що діє як інший компонент. Заступники повинні міститися в DLL, оскільки їм необхідний доступ до адресного простору клієнта для маршалінгу даних, переданих функціям інтерфейсу. Але маршалінг – це лише половина справи; компоненту ще потрібна DLL, яка називається заглушкою (stub), для демаршалінгу даних, переданих клієнтом. Заглушка виконує також маршалінг даних, що повертаються компонентом назад клієнтові (рис. 2.10).
Стандарт RPC визначений OSF (Open Software Foundation) у специфікації DCE (Distributed Computing Environment) RPC. RPC забезпечує комунікацію між процесами на різних машинах за допомогою різноманітних мережевих протоколів. Розподілена модель COM (Distributed COM, DCOM) використовує RPC для зв'язку мережею.
Коли клієнт і компонент перебувають на різних машинах, СОМ, вірніше його вдосконалена розподілена версія DCOM, заміняє локальну міжпроцесну взаємодію мережевим протоколом. Ані клієнт, ані компонент "не знають" про мережу. Сервер СОМ з'єднується зі спеціальним резидентним процесом віддаленого комп'ютера, що контролює віддалений запуск сервісів на ньому (наявність такого процесу диктується звичайними міркуваннями безпеки). Цей процес, який називається Service Control Manager (SCM), здійснює запуск сервера на віддаленому комп’ютері й повертає вказівник на інтерфейс клієнтському комп'ютеру і клієнтському процесу. А в усьому іншому, маршалінг здійснюється в такий самий спосіб, як і у випадку локального сервера, за винятком того, що proxy-об'єкт й stub-об'єкт, спілкуючись за допомогою механізму RPC, фізично перебувають на різних комп'ютерах (рис. 2.11).
Отже, компонентні застосунки не обмежуються рамками однієї машини, причому прозорий механізм розподілу застосунків поширюється і на Internet.