4.2.3 Модель конфігурації компонентів на основі xml

В конфігураційних моделях XML-документи визначають структурні схеми та зв’язки (як статичні так і динамічні) між компонентами моделі. Головне призначення цих документів – адекватне відображення компонентної моделі ПрО, яке за допомогою наперед визначених правил може забезпечити реалізацію моделі у відповідне компонентне середовище (наприклад, COM, CORBA). Особливості певної моделі визначаються особливостями базових компонентів та правилами їх реалізації.

Моделі цього типу повинні:

1) Забезпечити ідентифікацію компонентів, як екземплярів моделі.

2) Реалізовувати включення кожного ідентифікованого компонента до складу моделі.

3) Забезпечити виконання операцій над атрибутами компонентів, якщо вони включені до складу інтерфейсу компоненту.

4) Забезпечити звернення до методів компонента, якщо вони включені до складу інтерфейсу компонента.

5) Забезпечити ідентифікацію типів та/або класів атрибутів компонентів та параметрів методів..

6) Забезпечити взаємодію компонентів.

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

Включення компоненти до складу моделі. В цілому, включення компоненти в модель може носити статичний, чи динамічний характер. Статичне включення передбачає попередній опис усіх компонентів моделі. Зокрема, такий підхід запропонований у BML, де в XML-документ включаються елементи (теги) <add>, які визначають окремі компоненти. Елементи <add> створюють ієрархічну структуру відповідно відношення включення, тобто контейнер, до складу якого входять компоненти, сам може бути елементом контейнера більш високого рівня.

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

В XML-орієнтованих компонентних моделях та підходах динамічне включення, як правило, є надбудовою над іншими технологіями. Зокрема, такий підхід забезпечує WebBroker, в якому обмін XML-документами базується на протоколах Інтернет.

Виконання операцій над атрибутами компонента. Це досить нетривіальна властивість компонентних підходів та моделей. Її складність полягаю в тому, що не всі атрибути компонента можуть бути безпосередньо доступні із зовні. Найбільш універсальним вирішенням цієї проблеми є підхід, що запропонований у таких моделях як JavaBeans та Enterprise JavaBeans [29]. Для кожного атрибуту компонента (за вийнятком логічних змінних) існують два спеціальні методи set<Ім’я атрибуту> та get<Ім’я атрибуту>, за допомогою яких інші компоненти можуть встановити та отримати значення відповідних атрибутів. Для атрибутів логічного типу такими методами є пара set<Ім’я атрибуту> та is<Ім’я атрибуту>.

За умови наявності цих методів в XML-документ можуть включатися імена атрибутів, а при обробці документу у компонентному середовищі їх імена будуть замінені на відповідні імена методів. Такий підхід застосовується у BML. Щоб відрізнити атрибути від інших змінних, вони визначаються спеціальними тегами <property>.

Звернення до методів компонента. Ця властивість по суті є аналогом підходу звернення до процедур в інших компонентах, що розглядався у попередніх підходах та моделях. Суттєва відмінність у даному випадку одна – ця властивість є лише одним з аспектів підходів та моделей конфігурації компонентів і її подання у XML-документі інформаційно та структурно пов’язане з поданням інших аспектів.

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

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

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

Наприклад, в BML існує тег <event-binding> (аналог тегу <event> в узагальненому прикладі, що наведений вище), який визначає певну подію і перелік компонентів, які активізуються цією подією. Методи, які описані в інших компонентах, реалізують інтерфейс, який зв’язаний з подією. Тобто, коли подія відбувається, виконується звертання до методу, який реалізує відповідний інтерфейс.