- •Розподілені системи обробки інформації
- •Передмова
- •Розділ 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. Підсумки порівняння
- •Літературні джерела
Розділ 4. Створення системи "клієнт - сервер" на основі технології corba
4.1. Загальні теоретичні відомості
Технологія CORBA (Common Object Request Broker Architecture) – передбачає використання загальної архітектури брокерів (посередників) об'єктних запитів. Особливість технології полягає в її незалежності від апаратної та операційної платформи. За принципами технології CORBA в системі клієнт-серверк функціональність сервера надається клієнту за допомогою звертання до CORBA-об'єктів, які є контейнерами інтерфейсів, до яких включаються методи, що надаються клієнтам.
Технологія CORBA розроблена групою OMG (Object Management Group), яка об’єднала зусилля як постачальників, так і користувачів інформаційних технологій. Сьогодні в OMG входять понад 800 компаній, серед яких: Air Force Institute of Technology, American Airlines, Apple Computers, AT&T, Bellcore, Boeing Computer Services, Borland International, Chase Manhattan Bank, Digital Equipment, Fujitsu, General Electric, Hewlett-Packard, IBM, ICL, Informix Software, Intel, Los Alamos National Lab., Microsoft, MIT, Oracle, Siemens AG, SunSoft, Sybase, Texas Instruments, US Defense Information Systems Agency та інші.
Стандарт CORBA складається з 4 основних частин:
-
Object Request Broker - посередник об’єктних запитів;
-
Object Services – об’єктні сервіси;
-
Common Facilities – загальні засоби;
-
Application та Domain Interfaces – прикладні та галузеві інтерфейси.
Відповідно до вищезазначених складових стандарту технології CORBA, взаємодія між клієнтом та сервером буде здійснюватися так, як зображено на рисунку 4.1.
На машині клієнта створюються об’єкти-посередники: Stub (заглушка) і ORB (Object Require Broker – брокер об’єкту, що запитується). Stub виступає у ролі повноважний представника об’єкту, за допомогою інтерфейсу об’єкту клієнт звертається до Stub так, ніби це є власне об’єкт.
Отримавши виклик методу, Stub транслює цей виклик об’єкту ORB, який відсилає у мережу широкосповіщувальне повідомлення. На це повідомлення відкликається один з об’єктів Smart Agent («розуний» агент), що встановлений у мережевому середовищі клієнта (як у локальній мережі, так і в Internet). Smart Agent моделює мережевий каталог, в якому зареєстровані відомі йому сервери об’єктів. Після цього він відшукує необхідну мережеву адресу сервера та передає запит об’єкту ORB на машині сервера. Відзначимо, що обмін даними між ORB (клієнта та сервера) і Smart Agent здійснюється з використанням спеціального протоколу UDP, який більш дбайливо використовує мережеві ресурси, ніж протокол TCP. Через ВОА (Basic Object Adapter – базовий об’єктний адаптер) дані отримує особливий об’єкт сервера, який зветься Skeleton (основа). Skeleton вміщує параметри виклику в стек адресного простору об’єкту та реалізує власне виклик.
Роль об’єкту ВОА полягає у фільтрації звернень до об’єкту сервера, за допомогою його методів сервер через Skeleton може об’явити деякі свої поля та властивості доступними тільки для читання або взагалі схованими від певного клієнта. (Оскільки в рамках технології дані, якими обмінюються клієнт та сервер, розглядаються просто як ланцюжки байт, клієнт повинен помістити в буфер виклику свій авторизований ключ в системах, які захищені від «сторонніх» клієнтів).
Особливістю COBRA є спосіб опису інтерфейсу об’єкту. Для таких цілей розроблено спеціальну мову IDL (Interface Definition Language – мова опису інтерфейсу). За синтаксисом вона схожа на мову C++. Після опису інтерфейсу в термінах цієї мови компілятор IDL автоматично створює об’єкти Stub і Skeleton. Обмін інформацією про інтерфейс між розробниками здійснюється в термінах мови високого рівня, в той час коли компілятор опису інтерфейсу переводить його текст в машинні інструкції конкретного комп’ютера (клієнта або сервера). У підсумку досягається високий ступінь незалежності обміну даними від апаратних засобів клієнта та користувача.
Для реалізації технології в мережевому середовищі клієнта повинен існувати хочя б один Smart Agent. Якщо обмін даними здійснюється через локальну мережу, Smart Agent встановлюється на головну машину (на клієнт-сервер або машину з SQL-сервером), а при обміні даними через Internet – на одному з вузлів мережі. При створенні сервера здійснюється автоматична реєстрація об’єктів в одному або декількох Smart Agent. Отже, Smart Agent «знає», за якими мережевими адресами розташовані його сервери. Така організація дозволяє підвищити надійність, оскільки у випадку, якщо в одному сервері збій, Smart Agent повторить виклик та при повторному збої переключиться на інший сервер.