4.2. Мова опису моделей взаємодії на основі xml

В якості мови опису моделей взаємодії програмних компонентів пропонується використовувати XML (Extensible Markup Language), підмножини SGML, найбільш потужної з сучасних мов подання та обробки документів. Як наслідок з цього, XML-орієнтовані програмні засоби мають значні функціональні властивості і можуть працювати на різних платформах та середовищах як засоби взаємодії програмних компонентів. Актуальності цієї проблеми відповідають провідні сучасні компонентні моделі (Corba, DCOM, COM, JAVA-моделі тощо), які включають до складу своїх функціональних можливостей різні аспекти XML, або розглядають XML як альтернативу сервісам Corba щодо забезпечення взаємодії компонентів [5, 11, 12].

Вважається, що опис моделі взаємодії з використанням XML має два підходи.

1) На основі опису XML-документу може бути сгенеровані тексти на певній мові програмування, які після компіляції включаються до складу середовища, що реалізує подання відповідної компонентної моделі. Усі особливості взаємодії окремих компонентів (пошук та встановлення зв’язків, звернення до функцій, обмін даними) знаходять своє відображення у сгенерованому текстові.

2) XML-документ оброблюється у первинному вигляді, тобто у режимі інтерпретації. При цьому, застосовуються типові засоби – парсери (програми, що виконують синтаксичний розбір XML-конструкцій), прикладні інтерфейси (наприклад, інтерфейс DOM [11] – документо-орієнтований інтерфейс) та ін.

На абстрактному рівні модель будь-якого XML-документу є продукційною системою, яка засобами XML-нотації подається як опис типу документу (Document Type Definition, DTD). Продукційна система відображає синтаксичну структуру документу, а певні елементи можуть мати і семантичні ознаки (наприклад, для певних типів файлів, імена яких знаходяться у DTD, наперед визначені можливі операції та засоби обробки). Як узагальнений приклад подання компонента засобами XML можна розглянути фрагмент відповідного опису для певного абстрактного рівня. Ось початковий фрагмент такої продукційної моделі:

<компонент> :=<особливості><інтерфейси><атрибути><методи><події>

<особливості>:=<версія><мова програмування><операційне середовище><ресурси>

<версія>:= <визначення версії>

<мова програмування>:=<визначення мови програмування>

<операційне середовище>:=<визначення операційного середовища>

<ресурси>:=<перелік ресурсів>

<інтерфейси>:=<пусто>|<інтерфейс><інтерфейси>

<атрибути>:=<пусто>|<атрибут><атрибути>

<методи>:=<пусто>|<метод><методи>

<події>:=<пусто>|<подія><події>

. . . .

При цьому взаємодія компонентів відбувається на основі моделі подій, коли певна подія в компоненті спричиняє активізацію методів в інших компонентах, які пов’язані з цією подією.

Описів DTD для цієї продукційної моделі може бути декілька. Всі вони будуть розрізнятися назвами тегів (структурних елементів XML-документу), методами подання параметрів та сутностей, іншими синтаксичними особливостями. Але на семантичному рівні вони будуть визначати одну й ту ж продукційну модель.

Нижче наведено кілька з найбільш відомих на цей час підходів та моделей на основі XML, які вже практично застосовуються для реалізації зв’язки компонентів у середовищах:

1) Підхід, який запропонувала фірма IBM на основі Bean Markup Language (BML) – XML-подібна мова для інтеграції JAVA-компонентів. Хоч цей підхід, в першу чергу, орієнтований на інтеграцію JavaBeans-компонентів, проте інтегрувати можна довільні компоненти, які подані у вигляді JAVA-класів. Існує два режими – інтерпретації (безпосередньо оброблюється відповідний XML-документ) та компіляції (на основі XML-документу генеруються JAVA-класи).

2) XML-орієнтований протокол віддалених викликів Remote Procedure Call (XML-RPC), націлений на кросплатформену взаємодію компонентів в розподіленому середовищі на базі Інтернет. Підхід здобув поширення завдяки дуже простій адаптації до проблем електронної комерції. XML-документи для цього протоколу відображають всю необхідну інформацію для віддаленого виклику до процедури.

3) Фірма Microsoft, проаналізувавши обмеження своєї розподіленої компонентної моделі DCOM, розробила власний варіант RPC-протоколу “The Simple Object Access Protocol” (SOAP), який визначається як метод обміну командами та параметрами між клієнтом та сервером, абстрагуючись від конкретних операційних систем, МП та моделей взаємодіючих компонентів.

4) Компонентний підхід “Coins” є однією з ідей реалізації високорівневого XML-протоколу серіалізації для обміну компонентами. Концептуальна основа “Coins” базується на створенні протоколу серілізації JavaBeans-компонентів, що є альтернативою стандартному протоколу серіалізації JAVA-об’єктів.

5) Консорціум W3C продовжив вдосконалення Corba-моделі. Найбільш суттєвим напрямком розвитку є розширення концепцій Corba на Інтернет-середовище – WebBroker, в його рамках розроблено серіалізацію повідомлень між об’єктами та подання інтерфейсів між об’єктами для репозиторію інтерфейсів засобами XML.

Серед множини компонентних моделей і підходів до інтеграції .є базові:

1) моделі та підходи, що забезпечують для компонентів звернення до методів, процедур, функцій, які визначені в інших компонентах;

2) моделі та підходи, що забезпечують переміщення компонентів у компонентному середовищі як окремих об’єктів компонентної моделі відповідно до правил інтеграції та взаємодії (моделі та підходи серіалізації);

3) моделі та підходи, що визначають структурні властивості та правила інтеграції сукупності компонентів моделі.

Моделі звернення до процедур є найбільш прості моделі і визначають лише правила взаємодії пари компонентів. Моделі такого типу мають наступні властивості:

– ідентифікація компоненту, в якому знаходиться необхідна процедура (метод, функція).

– ідентифікація процедури, яка буде виконуватись.

– ідентифікація типів та/або класів параметрів процедури та результату (якщо вони присутні у зверненні).

– ініціація параметрів процедури необхідними значеннями.

Розглянемо більш детально окремі риси цих моделей.

Ідентифікація компонентів. Існує два аспекти ідентифікації компонентів – визначення класу, до якого належить компонента, та визначення екземпляру класу. Клас компонентів вміщує необхідні метадані, які потрібні для управління компонентою (її створення, опис інтерфейсів і т.і.). Новому екземплярові класу привласнюєтся унікальний ідентифікатор, за допомогою якого інші компоненти можуть з ним взаємодіяти. Звичайно, компонент може бути самостійною одиницею і не мати класу. У цьому випадку компонент повинний мати самодостатній характер, тобто мати необхідні метадані, у тому числі і дані, що описують її інтерфейси.

Наведемо кілька прикладів ідентифікації компонентів. У BML існує тег <bean> (аналог тегу <component> в узагальненому прикладі) з параметрами class та id. Перший визначає клас компонента, а другий привласнює їй унікальне ім’я, що ідентифікує її у рамках даної моделі. Зовсім інший підхід у XML-RPC. Для цього протоколу не суттєвим є опис компонента, а важливим є ідентифікація процедури. Тому одночасно з ідентифікацією процедури визначається і компонента, в якій вона знаходиться.

Ідентифікація процедури. Для ідентифікації процедури існує два аспекти. По-перше, необхідно визначити ім’я процедури, а по-друге, необхідно врахувати сигнатуру процедури. Сигнатура процедури (методу, функції) визначається впорядкованою множиною параметрів та результатів з ідентифікацією їх типів чи класів. Це є суттєвим аспектом, бо компонент може мати кілька процедур з однаковим іменем але різними семантиками. Розрізняються ці процедури за сигнатурами.

Вирішення першого питання забезпечується поданням у XML-документі пари – ім’я компонентаі назва процедури. Наприклад, в XML-RPC для цього застосувається складне ім’я – <ім’я компонента.<назва процедури>. В моделі Corba віддалене звернення до процедури має двокроковий характер. Спочатку для інтерфейсу, до якого входить опис метода (процедури), шукається компонент, а вже потім вказується метод. Для кожного з цих двох кроків (як вже наводилось вище) існують відповідні XML-орієнтовані підходи.

Питання щодо сигнатури методів вирішуються відповідно до способу організації інтерфейсів між компонентами. Наприклад, в моделі Corba існують статичні та динамічні інтерфейси. Для організації статичних інтерфейсів проблема сигнатури вирішується згідно з правилами об’єктної орієнтації (перевантаження методів) МП компонента (якщо ця МП не є об’єктно-орінтованою, то всі процедури повинні мати унікальні імена). Для динамічних інтерфейсів під час роботи компоненти можна запросити опис інтерфейсів та їх методів, а потім визначити потрібну процедуру.

Ідентифікація типів та/або класів параметрів процедур і їх результатів. Ця властивість необхідна для:

– адекватної трансформації внутрішнього подання даних компонента в XML –документ і навпаки;

– визначення сигнатури процедури.

Принципових відмінностий для подання типів даних та класів у різних підходах та моделях не має. Всі розбіжності можна звести до наступних особливостей:

– відмінності у кількості типів даних та класів, які підтримуються компонентним підходом чи моделлю;

– відмінності у назвах тегів, що описують параметри та результати;

– відмінності у кількості повідомлень (XML-документів), у яких описують параметри та результати.

Так, в BML нема власних наперед визначених типів. Замість цього для будь-якого типу чи класу у XML-документі присутня його назва як строка символів, а вже безпосередня обробка виконується у відповідному JAVA-класі, якому потрібні ці дані. В той же час XML-RPC має власну множину визначених типів, більшість з яких є простими типами даних. А в моделі Corba та протоколі SOAP, крім базових типів, існують і складні типи – масиви, структури. Крім цього, для них встановлені формальні правила співвідношення (відображення) типів даних компонентів і їх поданням в XML-документах.

Corba має ще одну характерну властивість. В ній існують окремі типи XML-документів для передавання параметрів віддаленій процедурі (Request-message) і отримання відповіді з результатами роботи процедури (Response-message). Аналогічну властивість має і протокол SOAP. Такий підхід реалізується у тих випадках, коли потрібна асинхронна взаємодія об’єктів. Компонент може ініціювати виконання процедури в іншому компоненті, а сама буде продовжувати свою роботу. Отримання відповіді буде сигналізувати про закінчення виконання процедури.

Ініціація параметрів процедури необхідними значеннями. Ініціація даних потрібна у таких випадках:

– для визначення “умовчаних” даних;

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

Ця властивість XML-орієнтованих підходів та моделей є типовою і тому, в цілому, може існувати одна суттєва розбіжність – включати дані як один із параметрів елемента (тега) в XML-документі чи подати їх як значення цього тегу (ці особливості описуються відповідним DTD).

Наведені механізми XML-орієнтованих підходів та моделей використані при практичної реалізації моделей взаємодії програм і систем в ІТК (см. розділ 2 книги 2 звіту заданим проектом).