1.2. Основні приклади технологій створення розподілених систем

З розвитком технологій розроблення розподілених систем виникла необхідність у стандартизації їхніх компонентів, а також механізмів їхньої взаємодії. Основою для цього стали існуючі стандарти мережевих протоколів.

Взаємозв'язок цих стандартів подано в таблиці 1.1 [7], причому стандарти вищого рівня ґрунтуються на стандартах нижніх рівнів, наприклад, для протоколу взаємодії розподілених об'єктів RMI такою основою є стандарт TCP/IP і т.ін.

Таблиця 1.1

Основні технології розробки розподілених систем

Рівні використання розподілених засобів	Назви технологій	Мета використання
Компонентні програмні застосунки	OM/DCOM, CORBA, EJB, COM+	Забезпечення підтримки логіки предметної області
Системні сервіси	JTS, MTS, JMS, JNDI	Транзакціональність, безпека, обмін повідомленнями
Проміжне програмне забезпечення	CORBA, RMI,COM/DCOM	Опис інтерфейсів
Взаємодія розподілених компонентів	IIOP, RMI, RMI-IIOP CORBA-COM	Взаємодія компонентів через мережу, перетворення даних
Мережеві протоколи	TCP/IP, SPX/IPX, Х.25	Забезпечення мережевої взаємодії

Далі подано короткі описи наведених у таблиці технологій.

1. Технологія СОМ/DCOM (Component Object Model). Багатокомпонентна модель об'єктів запропонована компанією Microsoft у 1993 р.. Технологія передбачає створення систем, що складаються з двох частин: клієнтської та серверної. Одна частина програмного забезпечення (сервер) надає для використання власні функції, а інша (клієнт) отримує до них доступ. При цьому абсолютно не важливо, де розташовані ці частини: в одному процесі, в різних процесах на одному комп'ютері або на різних комп'ютерах. Для створення на основі специфікації COM додатків також не важливо, яка мова програмування використовувалася при розробці. За умови дотримання вимог стандарту COM взаємодія клієнта з сервером здійснюється без перешкод.

Технологія COM подана як інтеграційна схема для підтримки OLE (Object Linking and Embedding) – технології побудови складених документів в ОС Windows 3.1. Спочатку технологія СОМ давала можливість реалізовувати компоненти, що взаємодіють в рамках одного адресного простору або між процесами на одному комп'ютері, і була засобом динамічної інтеграції двійкових компонентів. Крім OLE, модель СОМ покладена в основу таких технологій Microsoft, як монітор транзакцій Microsoft Transaction Server (MTS) і архітектура інтеграції прикладних компонентів ActiveX.

Додаткові можливості розробникам розподілених застосунків на основі COM дає модифікація базової технології – розподілена модель DCOM (Distributed COM). Перша реалізація DCOM з'явилася у 1996 р. в операційній системі Windows NT 4.0. Існують реалізації DCOM для Windows 98, 2000, XP, 7 і Sun Solaris, також є інформація, що передбачається перенесення технології DCOM під OPENVMS. Для написання DCOM-компонентів можуть використовуватися такі мови, як C++, Java, Object Pascal і Visual Basic.

Докладно цю технологію розглянуто у посібнику в розділі 2.

2. CORBA (Common Object Request Broker Architecture). Технологія запропонована консорціумом OMG (Object Management Group) – найбільшим у світі консорціумом зі створення програмного забезпечення, що включає понад 700 членів: компаній-виробників програмних продуктів, розробників прикладних систем, а також кінцевих користувачів. В OMG, наприклад, входять: Apple Computers, Borland International, Hewlett-Packard, IBM, Intel, Oracle та ін. Метою OMG є створення узгодженої інформаційної архітектури, що спирається на теорію і практику об'єктних технологій і надає можливість універсальної специфікації інтерфейсів функціональних ресурсів. Ця архітектура має забезпечувати повторне використання компонентів, їхню незалежність від операційних систем і мобільність.

Для опису інтерфейсів використовується декларативна мова IDL (Interface Definition Language). Описаний на IDL інтерфейс потім відображається в конкретну мову програмування. У даний час підтримуються такі мови: COBOL, С, C++, Smalltalk, Ada, Object Pascal, Java. Існують реалізації брокера об'єктних запитів для більшості операційних систем. Перша версія специфікації з'явилася у жовтні 1991 р., але не набула широкого поширення. Подальші, вдаліші версії, з'явилися у 1997 р. (СORBA 2.0 з відображенням для мови C++), 1998 р. (з’явилось відображення для мови Java) й 1999 р. (остаточна специфікація CCM – CORBA Component Model) [6].

Детальніше цю технологію розглянуто у посібнику в розділі 4.

3. СОМ+ (Component Object Model +) – технологія створення розподілених систем, що діють в локальній мережі призначених для доступу до інформації баз даних. Вона розроблялася фірмою Microsoft з кінця 90-х років і вперше з'явилася у складі операційної системи Microsoft Windows 2000. Основною метою розробки середовища COM+ було створення інфраструктури для побудови розподілених систем автоматизації роботи підприємства. Основні переваги середовища COM+:

• підтримка як синхронної, так і асинхронної взаємодії програмних компонентів;

• спільна робота з координатором розподілених транзакцій (distributed transactions coordinator, DTC);

• використання ролей (roles), для обмеження доступу до компонента; адміністратором ролі зв'язуються з обліковими записами.

Середовище COM+ керує ходом виконання компонентів COM+. Набір зв'язаних компонентів COM+, що містяться в одній динамічній бібліотеці, називається програмним застосунком COM+. Застосунок COM+ складається з набору компонент і ролей для доступу до них. Відомості про зареєстровані застосунки зберігаються у каталозі COM+.

На рис. 1.3 зображено архітектуру середовища COM+ при використанні серверних застосунків. Об'єкти COM+ є екземплярами компонентів COM+, зареєстрованих в каталозі. Заглушка на стороні серверного процесу називається в COM+ перехоплювачем (interceptor) [16].

Рис. 1.3 Архітектура середовища COM+

.

4. Технологія Remote Method Invocation (RMI). На початку лютого 1997 р. компанією JavaSoft було випущено нову версію JDK (Java Development Kit – набір розробника Java) JDK 1.1, в якій з'явилася вбудована підтримка віддаленого виклику методів (Remote Method Invocation – RMI). Технологія RMI забезпечує вирішення завдань, що виникають при функціонуванні розподілених об'єктних застосунків, а саме:

• визначення місцезнаходження віддалених об'єктів;

• отримання посилань на віддалені об'єкти;

• виклик методів віддалених об'єктів і отримання результатів їх виконання.

Ці завдання є типовими для всіх технологій, що підтримують роботу розподілених об'єктних застосунків, але технологія RMI забезпечує вирішення ще одного завдання, яке розширює можливості розподілених застосунків – це можливість завантажувати потрібний байт-код класу об'єкта з віддаленого вузла, якщо в приймаючій віртуальній машині даний клас не визначений.

Найширше використовується реалізація RMI, здійснена в Java 2 Standard Development Kit (SDK) версії 1.3 фірми Sun Microsystems. У складі SDK підтримку технології RMI забезпечують такі програми: rmic, rmiregistry та rmid.

Програма rmic використовується для генерації клієнтського і серверного сурогатів (stub і skeleton відповідно) до байт-коду серверного об'єкта.

Програма rmiregistry реалізує сервіс іменування, який використовується серверними об'єктами для власної реєстрації під певним ім'ям, щоб клієнти могли одержати за цим ім’ям посилання на реальний віддалений об'єкт. Цю програму необхідно запускати на тому ж вузлі, на якому функціонує серверний об'єкт.

Програма rmid – програма-демон (демон – це системна програма UNIX), що підтримує сервіс активації (activation) сервера.

На рис 1.4 зображено розподілений RMI-застосунок, який використовує регістр для отримання посилання на віддалений об'єкт.

Рис. 1.4. Розподілений програмний RMI-застосунок

Сервер (server) звертається до регістру (registry), щоб зв'язати ім'я з віддаленим об'єктом, тобто здійснити реєстрацію. Клієнт (client) знаходить віддалений об'єкт за його ім’ям в регістрі сервера, а потім викликає його методи.

На ілюстрації також показано, що система RMI використовує існуючий Web-сервер (Web-server) для отримання байт-кодів класів від сервера до клієнта, коли в виникає така необхідність для створення відповідних об’єктів [7].

5 . Enterprise JavaBeans (EJB). Технологію запропоновано фірмою Sun Microsystems у 1998 р. За визначенням Sun, EJB – це модель для створення і розгортання серверних компонентів багаторазового використання, написаних мовою програмування Java. Компонентом, за визначенням Sun, є наперед розроблені фрагменти програмного коду, які можуть бути встановлені у працюючі прикладні системи. Отже, розробка конкретних застосунків стає (в ідеальному випадку) збіркою з готових EJB-компонентів. Прикладні бізнес-функції предметної області реалізуються у вигляді окремих EJB-компонент. Готові компоненти зберігаються на EJB-сервері і в сукупності реалізують потрібну бізнес-логіку. Всі сервісні функції, такі як служба іменування компонентів, підтримка транзакцій, забезпечення безпеки тощо, виконуються EJB-сервером (або EJB-контейнером), який також підтримує взаємодії EJB-компонентів із зовнішнім програмним середовищем і забезпечує створення та руйнування екземплярів EJB-компонентів (рис. 1.5) [3].

Рис. 1.5. Реалізація технології EJB

6. Технологія .NET Remoting корпорації Microsoft. Реалізація технології базується на власній концепції корпорації щодо побудови прикладних програмних систем – концепції ASP.NET, яка поєднує технологію розробки програмних систем для WWW (ASP) і технології розробки прикладних програмних систем (СОМ+, OLE DB, MTA, MTS).

Під час розроблення програмних систем на основі .NET для реалізації як клієнта, так і сервера використовується .NET Framework. Технологія .NET Remoting у цьому випадку є найкращим вибором для реалізації розподіленої обробки. З іншого боку .NET Remoting надає безпрецедентний рівень сумісності із старими технологіями на той випадок, коли розподілений програмний застосунок вже реалізовано з використанням іншої технології віддаленого доступу.

Наприклад, у разі застосування технології COM/DCOM використовується системний шар засобів взаємодії технологій .NET і СОМ з .NET Framework. Цей шар надає повний набір потрібних функціональних можливостей та надає можливість переходити до використання технології .NET Remoting поступово.

Якщо система побудована не на основі розподіленої технології Microsoft, а на базі, наприклад, RMI або CORBA, то за рахунок підтримки в .NET Remoting відкритих стандартів таких, як XML і Simple Object Access Protocol (SOAP), забезпечується взаємодія між програмними застосунками на різних платформах і від різних постачальників.

Детальніше цю технологію розглянуто в посібнику у розділі 3.

7. Технології, що використовуються в системах з відкритим кодом для побудови розподілених систем. Потреба в застосуванні можливостей відкритих систем зумовлена, зокрема, зростанням кількості різноманітних апаратних платформ, на яких виконуються програмні застосунки, призначені для вирішення все більш широкого діапазону завдань.

Впровадження гетерогенних систем¹ і бажання розділяти між ними дані та функції обробки, привели до необхідності організації їхньої спільної роботи. Імпульс щодо застосування можливостей відкритих систем виходить як від розробників, стурбованих необхідністю скорочувати витрати і час на перенесення своїх застосунків на різні платформи, так і від виробників, які прагнуть розробляти нові платформи, на яких може виконуватися широкий діапазон застосунків.

Комітет IEEE POSIX 1003.0 зупинився на визначенні, яке дає широке і вичерпне трактування поняття відкритих систем. Відповідно до цього визначення відкритою є "система, що реалізує відкриті специфікації на інтерфейси, сервіси і підтримувані формати даних, достатні для того, щоб забезпечити належним чином розробленим застосункам можливість перенесення з мінімальними змінами на широкий діапазон систем, спільної роботи з іншими застосунками на локальній і віддаленій системах та взаємодії з користувачами у стилі, що полегшує їм перехід від системи до системи" [2].

Ключовий момент у цьому визначенні – це використання терміну "відкрита специфікація", що у свою чергу визначається як "загальнодоступна специфікація, яка підтримується відкритим, оприлюдненим погоджувальним процесом, направленим на постійну адаптацію нової технології, і відповідає стандартам".

Відповідно до цього визначення відкрита специфікація не залежить від специфіки апаратного і програмного забезпечення або від продуктів конкретного виробника. Вона однаково доступна будь-якій зацікавленій стороні. Більше того, відкрита специфікація знаходиться під контролем комп'ютерної громадськості і тому всі, кого вона стосується, можуть брати участь у її розробці.

Як зазначалося раніше, розвиток програмних систем викликав появу ідеї побудови розподілених програмних комплексів. Звичайно, це стосується і систем з відкритим кодом. Розглянемо реалізацію розподіленої обробки інформації в таких системах на прикладі використання технологій DCOP та D-Bus в UNIXm-орієнтованих системах.

DCOP (Desktop Communication Protocol) – система комунікації процесів, а також програмних компонентів. Основна мета цієї системи – забезпечення взаємодії процесів і розподілення складних завдань. Отже, DCOP – система керування, що надає можливість програмним застосункам або скриптам використовувати інші застосунки. Вона побудована на базі протоколу X Window System Inter-Client Exchange.

Примітка 1. X Window System – віконна система, що забезпечує стандартні інструменти і протоколи для побудови графічного інтерфейсу користувача. Використовується в UNIX-подібних ОС.

Примітка 2. Inter-Client Exchange або IPC (Inter-Process Communication) – набір засобів обміну даними між множиною потоків в одному або кількох процесах UNIX-подібних ОС. Процеси можуть бути запущені на одному або більше комп'ютерах, зв'язаних між собою мережею. IPC-засоби розподіляються на засоби обміну повідомленнями, синхронізації, використання розподіленої пам’яті й підтримки віддалених викликів.

Ефективність використання IPC залежить від пропускної спроможності апаратних засобів, затримки взаємодії між потоками, а також від типу даних.

Використання DCOP надає нові можливості без необхідності написання нових застосунків. Застосунки і бібліотеки KDE добре підтримують DCOP, завдяки цьому більшість застосунків KDE можуть контролюватися скриптами через механізм DCOP.

Примітка 3. KDE (K Desktop Environment) – вільне середовище робочого стола для UNIX-подібних операційних систем. Побудоване на основі Qt-кросплатформного інструментарію розробки інтерфейсу користувача. Працює переважно під UNIX-подібними системами, які використовують графічну підсистему X Window System. Нове покоління технології KDE 4 працює в операційних системах Microsoft Windows і Mac OS X.

У сучасних KDE-системах кожен застосунок KDE підтримує базовий набір інтерфейсів DCOP, навіть якщо програміст явно не вносив у коді їхню підтримку. Технологія DCOP також робить можливим додавання нових функцій, які не були передбачені при створенні застосунку.

Модель DCOP. Кожен застосунок, що використовує DCOP, має статус клієнта. Клієнти взаємодіють між собою через сервер DCOP, призначений для здійснення відправлення повідомлень/запитів у потрібному напрямі. Всі клієнти — рівноправні.

Можливі два типи дій з DCOP: повідомлення без очікування і запити з очікуванням даних.

Усі дані відправляються послідовно, використовуючи вбудовані оператори QDataStream, доступні в усіх класах Qt. Існує також простий IDL-подібний компілятор (dcopidl і dcopidl2cpp), що генерує заготовки і скелети класів користувача. Використання компілятора dcopidl додатково забезпечує перевірку сумісності типів.

Подальшим розвитком DCOP стала система D-Bus.

D-Bus (Desktop Bus ) – стандартизована система міжпроцесної взаємодії, створена під впливом системи DCOP, замінила систему DCOP у KDE4. Вона надає застосункам кілька шин для передавання повідомлень, відрізняється високою швидкістю роботи, інтегрується в багато робочих середовищ. D-Bus доступна для Qt, Glib, Java (GCJ), Mono, Qt, Python і прозора для мережі.

Створенню D-Bus сприяли певні історичні передумови. Програмні застосунки робочого столу повинні тісно взаємодіяти між собою. У графічному середовищі KDE для забезпечення взаємодії застосунків використовувалася DCOP, але інші настільні середовища (наприклад, GNOME) не мали аналогічних систем.

Існувала можливість комунікації за допомогою протоколу SOAP (Simple Object Access Protocol)¹, але CORBA (основа SOAP) використовує велику кількість ресурсів (KDE і GNOME пройшли етап його використання за час свого існування), а SOAP і XML-RPC призначені для веб-сервісів.

Виникла необхідність організувати обмін повідомленнями між застосунками двох різних середовищ в умовах обмежених ресурсів. Для вирішення цього завдання і було створено проект D-Bus. Реалізація виявилася вдалою і тому проект KDE4 переведено на використання D-Bus.

Принципи роботи D-Bus. D-Bus надає можливість використовувати в системі кілька шин:

1) системна шина – створюється при старті демона (системної програми UNIX) D-Bus. За її допомогою відбувається спілкування різних демонів, але вона практично недоступна для прикладних застосунків;

2) сесійна шина – створюється для авторизованого користувача системи. Для кожної такої шини запускається на виконання окрема копія демона, за допомогою якої здійснюється зв’язок між прикладними застосунками.

Кожне повідомлення D-Bus, що передається шиною, має свого відправника і свого одержувача, їх адреси називаються шляхами об'єктів. Кожен застосунок складається з набору D-Bus-об'єктів, а повідомлення пересилаються не між застосунками, а між об'єктами цих самих застосунків.

Кожен об'єкт може підтримувати кілька інтерфейсів, які подаються у вигляді іменованих груп методів і сигналів аналогічно інтерфейсам JLIB, Qt або Java.

D-Bus також передбачає концепцію сервісів. Сервіс – це унікальне місцеположення, що надається застосунку на шині. При запускові кожен застосунок реєструє один або кілька сервісів, які він займатиме доти, поки самостійно їх не звільнить; до цього моменту жоден інший застосунок зайняти його не зможе.

Сервіси роблять доступною ще одну функцію: запуск застосунків у разі надходження повідомлень для них. Для цього має бути ввімкнена автоактивація, а в конфігурації D-Bus за цим сервісом має бути закріплений один застосунок. Тоді D-Bus зможе його запустити у разі появі повідомлення.

Після закриття застосунку асоційовані сервіси також звільняються, а D-Bus посилає сигнал про те, що сервіс закритий. Інші застосунки можуть одержувати такі сигнали і відповідним чином реагувати на них.

Після підключення до шини застосунок має вказати, які повідомлення йому треба одержувати. Зробити це можна шляхом додавання масок збігів (matchers). Маски є наборами правил для повідомлень. Фільтрація може ґрунтуватися на інтерфейсах, шляхах об'єктів і методах. Таким чином, застосунки одержуватимуть тільки те, що їм потрібно, а проблеми доставки у цьому випадку бере на себе D-Bus.

Повідомлення в D-Bus бувають чотирьох видів: виклики методів, результати викликів методів, сигнали і помилки. Перші призначені для виконання методів над об'єктами, підключеними до D-Bus; методи повертають результат виклику або код помилки через повідомлення відповідних типів. Сигнальні повідомлення сприймаються об’єктами як завгодно (вони можуть навіть не отримувати їх зовсім).

Щоб повідомлення досягло певного об'єкта, необхідно мати спосіб, що дозволяє послатися на об'єкт. У технології D-Bus кожен об'єкт має унікальне ім'я, яке виглядає як визначення шляху до файлу у файловій системі. Наприклад, об'єкт може бути іменований як /org/kde/kspread/sheets/3/cells/4/5.

Імена об'єктів розміщуються в просторах імен, щоб забезпечити розмежування різних програмних модулів. Просторам імен зазвичай дається префікс, специфічний для розробника, наприклад /org/kde.

Примітка. Для реалізації технології D-Bus використовується будь-яка мова програмування, для якої визначено D-Bus біндінг. D-Bus біндінги – це групи пакетів, які містять мову програмування і інтерфейси платформи для D-Bus API¹ [1].

Сфера застосування розглянутих технологій одна – створення об'єктних розподілених систем, але між ними існують значні відмінності, які визначають вибір тієї або іншої технології в кожному конкретному випадку. Порівняння технологій за основними характеристиками наведено в таблиці 1.2.

Таблиця 1.2

Характеристики технологій DCOM, CORBA, RMI, DCOP/D-Bus

Характерис-тика	Назва технології
	DCOM	CORBA	RMI	DCOP/D-Bus
Доступність	Фірмова технологія	Відкрита специфікація	Відкрита специфікація	Відкрита специфікація
Платформа	Працює на будь-якій платформі, для якої існує реалізація СОМ сервісу	Працює на будь-якій платформі, для якої існує реалізація брокера об'єктних запитів CORBA	Працює на будь-якій платформі, для якої існує реалізація віртуальної машини Java	Працює переважно під UNIX-подібними, з графічною підсистемою X Window System
Протокол	Використовує Object Remote Procedure Call протокол	Використовує Internet INTER-ORB Protocol	Використовує Java Remote Method Protocol	Використовує набір засобів Inter-Client Exchange або IPC
Передача параметрів	Всі параметри визначаються в IDL-файлі. Залежно від визначення параметр може передаватися за значенню або за посиланням	Параметри, описані як IDL-інтерфейс, передаються за посиланням, інші передаються за значенням	Об'єкти, що реалізують інтерфейс java.rmi.Remote, передаються за посиланням, інші за значенням (вони повинні реалізовувати інтерфейс java.io.Serializable)	Обмін даними здійснюється шляхом обміну повідомленнями різних типів
Можливість передачі складних типів даних	Для передавання складних типів даних їх треба визначити мовою Microsoft IDL	Для передавання складних типів даних їх треба визначити мовою IDL	Об’єкт будь-якого класу може бути переданий як параметр, але для цього він має бути визначений як такий, що реалізує інтерфейс java.io.Serializable	Посилання на об’єкти передаються через простори імен
Мова	Будь-яка.	Будь-яка, для якої існує відображення в мову IDL і навпаки	Java	Будь-яка, для якої існує D-Bus біндінг
Виключні ситуації	Не підтримуються стандартними сервісами	Підтримуються	Підтримуються	Підтримуються