- •Розподілені системи обробки інформації
- •Передмова
- •Розділ 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.6.3. Методи формування екземпляра сом-об’єкту
Зовнішні СОМ-сервери можуть підтримувати один із трьох методів створення екземпляра. Метод створення екземпляра визначає, скільки екземплярів сервера буде створено у відповідь на запит клієнтського застосунка. Метод створення визначається параметром Instancing конструктора СОМ-об’єкта, можливі значення якого подано нижче.
Single Instance (єдиний екземпляр) означає, що для кожного клієнтського застосунка допускається створення тільки одного екземпляра СОМ-об’єкту. Застосунок, що запитує екземпляр СОМ-об’єкту, буде працювати з власною окремою копією СОМ-сервера.
Multiple Instance (множина екземплярів) означає, що СОМ-сервер здатний створювати декілька копій СОМ-об’єкту. Коли клієнтський застосунок запитує екземпляр СОМ-об’єкту, новий сервер не запускається (якщо тільки не виявиться, що жоден екземпляр сервера не запущений раніше). Замість цього вже запущений сервер створює новий екземпляр СОМ-об’єкту. Значення Multiple Instance встановлюється за замовчуванням.
Internal only (тільки внутрішній) використовується тільки для СОМ-об'єктів, які будуть недоступними для клієнтських застосунків. Єдиний застосунок, якому дозволено запитувати створення екземпляра СОМ-об’єкту, це сам СОМ-сервер.
Бажано створювати СОМ-сервери, що підтримують метод Multiple Instance. Нехай, наприклад, створюється СОМ-сервер, що керує доступом до послідовного порту. Якщо двом паралельно виконуваним клієнтським застосункам буде потрібно передати дані в порт за допомогою СОМ-сервера, то сервер, який підтримує метод Multiple Instance, зможе відкрити порт і обслужити обидва клієнтські застосунки одночасно.
З іншого боку, якби СОМ-сервер підтримував метод Single Instance, то запит першого клієнта на доступ до сервера приводив би до створення екземпляра сервера, запит другого клієнта приводив до запуску другого екземпляра сервера. Оскільки перший екземпляр відкриє послідовний порт для передавання, другому екземпляру доступ до порту буде закритий, що призведе до припинення виконання другого клієнтського застосунка.
Звичайно, існують ситуації, коли такий ефект навіть бажаний, і саме для них потрібно створювати сервер, що підтримує метод Single Instance. Однак, якщо немає вагомих аргументів для іншого варіанта, необхідно створювати сервер, що підтримує метод Multiple Instance. Зазначимо, що у середовищі Delphi майстер СОМ Object Wizard за замовчуванням пропонує саме варіант Multiple Instance. Якщо деякий метод формування екземпляра обраний при розробленні сервера, це не означає, що його не можна змінити надалі. Для призначення серверу іншого методу формування екземпляра досить, фактично, внести зміни усього в один рядок програмного коду, а саме: в секції ініціалізації, розташованій у модулі реалізації СОМ-класу:
initialization
TTypedComObjectFactory.Create(ComServer, TComOuts, class_ComOuts, ciMultiInstance, tmApartment);
2.6.4. Формування екземпляра зовнішнього сом-об’єкту
Методика формування екземпляра СОМ-об’єкту, що міститься в зовнішньому сервері, практично та сама, що і для вбудованого сервера. Треба, як і раніше, викликати метод CreateComObject, передавши йому GUID СОМ-об’єкту, що планується сформувати.
Але в цьому випадку Delphi працює інакше. Замість використання ключа реєстру InProcServer32 середовище звертається до ключа LocalServer32. У цьому ключі буде зберігатися повний шлях до ехе-файла сервера. Метод CreateComObject запускає застосунок сервера. Метод Application.Initialization запустить процес ініціалізації, у ході якого сервер, зокрема, зареєструє свій генератор класів у внутрішній таблиці активних об'єктів Windows. За допомогою цієї таблиці операційна система відслідковує стан всіх активних СОМ-об'єктів.