- •Розподілені системи обробки інформації
- •Передмова
- •Розділ 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. Створення систем клієнт-сервер на основі зовнішнього базового сом-об’єкту
2.6.1. Основні поняття
Нагадаємо, що сервер СОМ являє собою Windows-застосунок (*.ехе), або динамічну бібліотеку(*.dll), який містить один або декілька COM-об'єктів одного або різних класів. Відрізняють три типи COM-серверів.
Внутрішній сервер (inprocess server) реалізується динамічними бібліотеками (*.dll), які підключаються до клієнта і працюють в одному адресному просторі.
Зовнішній локальний сервер (local server) створюється окремим процесом (*.exe), який працює на одному комп'ютері з клієнтом. У процесі виконання він розташовується у власному адресному просторі, відмінному від адресного простору клієнта.
Зовнішній віддалений сервер (remote server) створюється процесом (*.exe), який працює на іншому комп'ютері по відношенню до клієнта.
На відміну від вбудованих, зовнішні СОМ-сервери не експортують функції DllRegisterServer, DllUnregisterServer, DllGetClassObject і DllCanUnloadNow. Отже, для реєстрації в системному реєстрі Windows, зовнішні СОМ-сервери використовують інші методи — треба просто запустити сервер на виконання, включивши в командний рядок запуску ключ /regserver. У відповідь середовище Delphi самостійно зареєструє сервер і СОМ-об'єкти та завершить на цьому операцію без запуску сервера на виконання. Для видалення елемента реєстрації із системного реєстру потрібно використовувати ключ /unregserver.
2.6.2. Засоби організації потокової взаємодії клієнта і сервера
При створенні СОМ-об’єкту з використанням візарда обирається модель потоків, яку буде підтримувати СОМ-об'єкт. Вибір здійснюється шляхом встановлення параметра Threading model. Обираючи підтримку моделі потоків, можна поліпшити продуктивність COM-об’єкту, оскільки численні клієнти можуть отримувати паралельний доступ до СОМ-сервера.
Таблиця 2.1 включає різні моделі потоків, які можна визначити для СОМ-об’єкту.
Таблиця 2.1
Характеристики моделей потоків, які підтримують СОМ-об’єкти
|
Модель потоків |
Опис |
Аргументи за і проти |
|
1 |
2 |
3 |
|
Single |
Використовується у випадку, коли клієнт створює єдиний потік, у якому створює СОМ-об’єкт та формує свої запити. У СОМ-сервері створюється також один потік, у якому ці запити обробляються. Сервер не забезпечує підтримку потоків. Він серіалізує запити клієнта, щоб СОМ-застосунок одержував один запит за один раз. Це фіксується при реєстрації прапорами: для DLL – прапор ThreadingModel не встановлено для EXE – прапор IsMultiThread не встановлено. Така модель звичайна для внутрішніх серверів. |
Клієнт не створює потоку. Немає поліпшення продуктивності. |
|
Apartment (секціоно-вана) |
Використовується у випадку, коли клієнт створює декілька потоків, у кожному з яких породжує СОМ-об’єкт. Такі COM-об’єкти здатні оброблювати запити тільки від тих клієнтів, які їх створили. |
Об'єкти можуть отримувати доступ до своїх власних даних застосунка, але глобальні дані мають бути захищені засобами синхронізації. Локальні змінні потоку доступні через численні виклики. Модель забезпечує підвищення продуктивності. |
Таблиця 2.1 (закінчення)
|
1 |
2 |
3 |
|
Free (вільна) |
Використовується у випадку, коли клієнт створює декілька потоків, у кожному з яких породжує СОМ-об’єкт. Такі СОМ-об'єкти здатні оброблювати виклики від будь-якої кількості потоків у будь-який час, але не підтримується синхронізація локальних і глобальних даних. |
Об'єкти повинні захистити всі локальні і глобальні дані, використовуючи критичні секції або іншу форму синхронізації. |
|
Both |
Підтримуються обидві моделі (Free та Appartment). Використовується у випадку, коли клієнт створює декілька потоків, у кожному з яких породжує СОМ-об’єкт. Такі СОМ-об'єкти здатні оброблювати виклики від будь-якої кількості потоків у будь-який час та підтримується синхронізація локальних і глобальних даних потоків. |
Максимальна продуктивність і гнучкість. Не вимагає, щоб застосунок забезпечив підтримку потоку для параметрів вихідних викликів. |
|
Neutral |
Численні клієнти технології СОМ+ можуть звертатися до об’єкту у різних потоках одночасно, але COM перевіряє, щоб жодні виклики не суперечили один одному. |
Ця модель доступна тільки для COM+. Для COM − це модель Apartment. |
Примітка 1. Локальні змінні завжди зберігаються, незалежно від моделі потоків, оскільки локальні змінні завантажені в стек і кожен потік має власний стек.
Примітка 2. Модель потоків визначає, як об'єкт зареєстрований у системному реєстрі. Необхідно переконатися, що обрана об'єктна реалізація відповідає обраній моделі потоків. Для внутрішніх серверів, встановлення моделі потоків приводить до встановлення ознаки моделі в ключі ThreadingModel реєстрації CLSID.
Примітка 3. При зверненнях клієнтів до зовнішніх СОМ-серверів ініціюється COM найвищої викликаної моделі потоків. Наприклад, якщо СОМ-сервер включає free-threaded об'єкт, створюється free threading модель. Щоб вручну анулювати ознаку моделі потоків використовується змінна CoInitFlags.
Розроблення об’єкту, що підтримує вільну модель потоків. Використовувати Free-модель, краще ніж моделі Apartment в тому разі, коли об'єкт має бути доступний більш ніж з одного потоку. Загальний екземпляр СОМ-об’єкту надається застосункам клієнта підключеним до об’єкту, розташованого на віддаленій машині. Коли віддалений клієнт викликає метод на цьому об'єкті, сервер створює новий потік у пулі потоків на машині сервера. У цьому випадку користувач виконує виклики фактичного об'єкту і, оскільки об'єкт підтримує вільну модель потоків, потік може зробити прямий виклик методу об’єкту.
Для підтримки об'єктом Apartment моделі, виклик має бути переданий у потік, у якому об'єкт був створений, і результат має бути переведений назад у той самий потік, перед поверненням клієнту. Цей метод вимагає додаткового маршалінгу.
Щоб підтримувати Free-модель, необхідно використовувати критичні секції або деяку іншу форму синхронізації, щоб захищати дані застосунка.
Free модель для вбудованого сервера може поліпшити продуктивність, діючи як зовнішній об'єкт в агрегації з free-маршалінгом.
Розроблення об’єкту, що підтримує Apartment threading модель. Щоб реалізувати Apartment threading model (single-threaded) модель потоків, необхідно діяти за кількома правилами:
-
перший потік (WinMain) у застосунку повинен створювати СОМ-об’єкт, у цьому самому потоці має бути виконана деініціалізація СОМ;
-
якщо деякий потік одержав вказівник на інтерфейс, то він повинен використовуватися тільки у цьому потоці;
-
кожен потік в apartment threading моделі повинен мати цикл обробки повідомлень.
Сервер, що підтримує apartment model, забезпечує серіалізацію доступу до всіх глобальних даних (як наприклад, рахувальник екземплярів об’єкту).
Розроблення об’єкту, котрий підтримує нейтральну модель потоків. При використанні СОМ+ (технологія Microsoft Transaction Server − MTS) можна використовувати модель потоків, яка є проміжною між вільною моделлю й апартаментной моделлю. Модель допускає використання багатьох потоків для доступу до об'єкту. При цьому немає необхідності піклуватися про забезпечення додаткового маршалингу в потоці, в якому був створений об'єкт, більш того об'єкт гарантований від виникнення конфлікту при звертанні до нього.
При розробленні об’єкту з нейтральною моделлю потоків варто дотримуватися тих самих правил, як при написанні апартаментного потоку, за винятком того, що необхідно забезпечити синхронізацію даних об’єкту.