Анатомія топологічної моделі Rational Software Architect Version 7.5. Частина 1

Введення


Продукти IBM Rational Software Architect Standart Edition версії 7.5 і IBM Rational Software Architect for WebSphere Software версії 7.5 (для стислості, Rational Software Architect V7.5) включають потужний інструмент Deployment Architecture Platform, призначений для візуального моделювання IT-систем та їх складних взаємозв’язків. У його основі лежить потужна розширювана, сільнотіпізірованная модель, звана топологічної моделлю. Цей інструмент призначений для вирішення наступної проблеми.


Ви, ймовірно, часто стикаєтеся з необхідністю створювати схеми ваших IT-систем для обміну інформацією з вашими колегами з інших підрозділів (наприклад, підрозділи розробки або бізнес-підрозділів). Зазвичай, такі завдання вирішуються за допомогою записок, електронної пошти, таблиць, слайдів або діаграм Microsoft Visio. При цьому існувала й існує потреба у формальному методі опису таких схем і в системі, яка могла б перевіряти коректність таких описів. Відсутність такого рішення призводить до низки проблем конфігурування, викликаних розгортанням додатка “наосліп”, і постійно проявляються протягом його життєвого циклу. У міру зміни етапів життєвого циклу додатки (розробка, перенесення даних, тестування, промислова експлуатація) ситуація тільки погіршується. Це може призвести до неможливості реплікації успішно инсталлированной системи; єдиним виходом буде перепроектування. Часто шаблони і принципи побудови та розгортання подібних систем документовані письмово, але при цьому відсутня спосіб їх реалізації або можливість домогтися їх виконання.


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


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


Концепції топологічної моделі


За допомогою топологічної моделі можна описувати ІТ-системи або їх фрагменти, при цьому модель грає роль універсальної мови опису. Модель можна доповнювати новими типами (або їх екземплярами), відповідними різних предметних областях і визначеними в інших топологічних моделях. Кожен екземпляр, визначений в топологічної моделі, має слабкий зв’язок (loosely coupled) з можливостями системи і може визначати вимоги до них. У даній статті розглядаються наступні базові концепції топологічної моделі:



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


Малюнок 1. Спрощена UML-модель сутностей топологічної моделі
Спрощена UML-модель сутностей топологічної моделі

Топологія

Топологія є елементом верхнього рівня топологічної моделі. Вона описує топологічну модель і всі її елементи, включаючи одиниці і зв’язки між ними. В одних випадках топологія, що описує ІТ-систему, може зводитися до єдиного елементу. В інших – може являти собою декомпозицію безлічі компонентів і їх зв’язків до n-го рівня. Топології відповідає елемент topology, визначений у просторі імен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схеми топології (див. лістинг 1). Унікальними ідентифікаторами елемента topology є його ім’я і простір імен. Також для цього елемента можна вказати опис і ім’я для відображення візуальними засобами.


Лістинг 1. Основний простір імен, визначене в core.xsd




 <?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology
xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/”description = “Приклад топології, що ілюструє анатомію топологічної моделі”displayName = “Приклад елемента Topology”
name=”SampleTopology”
namespace=”developerworks.deploy”>
</core:topology>

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


Крім того, призначення топології може бути позначено при моделюванні за допомогою атрибуту decoratorSemantic. В IBM Rational Software Architect визначено ряд типових призначень топології, в тому числі analysis, infrastructure і deployment. У топології, наведеної у лістингу 2, атрибут decoratorSemantic має значення com.ibm.ccl.soa.deploy.core.dds, Що відповідає типовому призначенням analysis в Rational Software Architect.


Лістинг 2. Атрибут decoratorSemantic





<?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/” description = “Приклад топології, що ілюструє анатомію топологічної моделі”
displayName=”Sample Topology” name=”SampleTopology”
namespace=”developerworks.deploy”
decoratorSemantic=”com.ibm.ccl.soa.deploy.analysis.ads”>
</core:topology>

Одиниця (Unit)

Одиниця – Базовий тип, який представляє в топологічної моделі одиницю розгортання. У загальному сенсі одиниця являє собою окремий елемент ІТ-системи, з яким пов’язаний ряд вимог. Ці вимоги описують можливості, що надаються системою, і повинні бути задоволені при її розгортанні Одиниці відповідає елемент unit, визначений у просторі імен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схеми, яка описує топологію. Його унікальним ідентифікатором в рамках елемента топології (topology) є ім’я. Також для цього елемента можна вказати опис і ім’я для відображення візуальними засобами, як показано в лістингу 3.


Лістинг 3. Тип Unit




 <core:unit
displayName=”SampleUnit”
name=”sampleUnit”description = “Приклад одиниці”>
</core:unit>

Настроювальні одиниці


Настроювальні одиниці являють собою налаштування, виконувані під час розгортання. Топологічна модель дозволяє позначати настроювальні одиниці за допомогою атрибуту configurationUnit, Як показано в лістингу 4. Наприклад, сервер не є настроювальної одиницею, тоді як одиниця, що представляє джерело даних, створений на цьому сервері, є настроювальної.


Лістинг 4. Настроювальна одиниця




<core:unit displayName=”SampleConfigurationUnit”
name=”sampleConfigurationUnit” description = “Приклад настроювальної одиниці”>
configurationUnit=”true”>
</core:unit>

Концептуальні одиниці


Іноді буває складно дати одиниці точне визначення під час аналізу. У цьому випадку топологічна модель, як аналітичне відображення ІТ-системи або її фрагмента, може виявитися нездатною відбити всі можливості і вимоги (чи навіть елементи) такої одиниці. Для позначення одиниць, визначених на рівні припущень, Служить необов’язковий атрибут conceptual, Що має за замовчуванням значення false, Як показано в лістингу 5. Таку одиницю можна вважати слотом в топології, значення якого повинно бути вибрано згодом.


Лістинг 5. Атрибут conceptual




 <core:unit displayName=”SampleConceptualUnit” name=”sampleConceptualUnit” description = “Приклад концептуальної одиниці”>
conceptual=”true”>
</core:unit>

Стереотип


Одиниці можна класифікувати, використовуючи в якості додаткових ключових слів стереотипи, як показано в лістингу 6. Ці ключові слова можна буде використовувати в різних випадках для того, щоб зв’язати одиницю з логікою поведінки, обумовленої профілем стереотипу. Крім того, стереотипи топологічної моделі забезпечують функціональну сумісність стереотипів, привнесених з інших профілів, визначених для компонентів за допомогою Unified Modeling Language (UML).


Лістинг 6. Ключові слова стереотипу




 <core:unit displayName=”ServiceComponentUnit” name=”serviceComponentUnit” description = “Приклад стереотипізованої одиниці – компонента сервісу”>
<core:stereotype
keyword=”service”
profile=”serviceProfile”/>

</core:unit>


Статус установки


Для одиниці може бути вказаний необов’язковий атрибут, що визначає статус її установки. Він може приймати наступні значення: unknown (невідомий), installed (встановлений), or not_installed (не встановлено). Статус установки має додаткові підстатус: початковий статус установки і цільової статус установки. Атрибути, що відповідають цим підстатус, мають за замовчуванням значення unknown. Поєднання початкового і цільового статусу установки одиниці дають публікатору топологічної моделі додаткову інформацію про розгортання одиниці. Ситуація, при якій початковий статус установки дорівнює installed, А цільовий статус дорівнює not_installed, Інтерпретується як видалення одиниці при публікації топологічної моделі. Крім того, для одиниці може бути вказаний атрибут publishIntent (Режим публікації), що приймає значення unknown (невідомий), publish (для публікації) і do_not_publish (не для публікації) (За замовчуванням – publish). Приклад використання цього атрибуту приведений в лістингу 7. Він служить підказкою публікатору, що дозволяє визначити, чи можна ігнорувати одиницю при публікації. Цей атрибут також дозволяє здійснювати поступову або ізольовану публікацію топологічної моделі на різних етапах розробки і розгортання.


Лістинг 7. Статус установки і режим публікації




 <core:unit displayName=”SampleConceptualUnit” name=”sampleConceptualUnit” description = “Приклад концептуальної одиниці” conceptual = “true”
initInstallState=”installed”
goalInstallState=”not_installed”
publishIntent=”do_not_publish”>
</core:unit>

Композиція


У залежності від призначення топологія може включати як одну, так і декілька одиниць. Наприклад, за допомогою набору топологій можна створити каталог одиниць, що входять в ІТ-систему. Подібні топології можуть включати мінімальну кількість окремих одиниць і придатні для багаторазового використання як елементів інших топологій. Топологія також може описувати ІТ-систему цілком: така топологія може утримувати велику кількість одиниць, відповідних компонентів ІТ-системи, як показано в лістингу 8.


Лістинг 8. Топологія, що містить кілька одиниць




 <?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/” description = “Приклад топології, ілюструє анатомію топологічної моделі ”
displayName=”Sample Topology”
name=”SampleTopology”
decoratorSemantic=”com.ibm.ccl.soa.deploy.
analysis.ads” namespace=”developerworks.deploy”
<core:unit description = “Приклад одиниці”>
displayName=”SampleUnit”
name=”sampleUnit”/>
<core:unit description = “Приклад настроювальної одиниці”>
displayName=”SampleConfigurationUnit”
name=”sampleConfigurationUnit”
configurationUnit=”true”/>
<core:unit description = “Приклад концептуальної одиниці”>
displayName=”SampleConceptualUnit”
name=”sampleConceptualUnit”
conceptual=”true”
goalInstallState=”not_installed”
initInstallState=”installed”
publishIntent=”do_not_publish”/>
<core:unit description = “Приклад стереотипізованої одиниці – компонента сервісу”>
displayName=”ServiceComponentUnit”
name=”serviceComponentUnit”>
<core:stereotype
keyword=”service”
profile=”serviceProfile”/>
</core:unit>
</core:topology>

Використання одиниць в предметних областях


Одиниці, як правило, відносяться до визначеної предметної області; топологія може включати одиниці з однієї або декількох предметних областей. Наприклад, для предметної області Java ™ 2 Platform, Enterprise Edition (J2EE) можуть бути визначені розширення базового типу одиниці, відповідні сервера J2EE (j2eeServer) і компоненту – додатком J2EE (component.ear). У топології, наведеної у лістингу 9, спільно використовуються базові типи одиниць і типи, визначені в предметній області J2EE. Зверніть увагу на те, що для одиниці – сервера вказані однакові значення початкового і цільового статусів установки. Однак значення статусу установки компонента – додатка J2EE говорить про те, що дана одиниця відсутня і підлягає встановленню. Зверніть увагу на URI простору імен предметної області J2EE xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/”, Доданий у топологію для забезпечення можливості використання визначених у ній типів.


Лістинг 9. Використання одиниць з різних предметних областей




 <?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology
xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/”
xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/”description = “Приклад топології, ілюструє анатомію топологічної моделі ”
displayName=”Sample Topology”
name=”SampleTopology”
decoratorSemantic=”com.ibm.ccl.
soa.deploy.analysis.ads”
namespace=”developerworks.deploy”>

displayName=”J2EE Server Unit ”
name=”j2eeServerUnit”
conceptual=”true”
goalInstallState=”installed”
initInstallState=”installed”/>
<j2ee:component.ear description = “EAR-компонент”
displayName=”EAR Component ”
name=”earComponent”
configurationUnit=”false”
goalInstallState=”installed”
initInstallState=”not_installed”/>
</core:topology>

Можливість

Можливість відображає в моделі деяку функцію одиниці, яка може бути надана іншим одиницям і включає конфігураційні параметри одиниці. Можливості відповідає елемент capability, визначений у просторі імен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схеми топології. Елемент сapability є частиною елемента одиниці (unit), його унікальним ідентифікатором є ім’я. Також для цього елемента можна вказати опис і ім’я для відображення візуальними засобами. Типи зв’язків, підтримуваних можливістю, визначаються атрибутом linkType, Як показано в лістингу 10.


Лістинг 10. Можливість




 <core:capability
displayName=”SampleCapability”
name=”sampleCapability” description = “Приклад можливості”>
linkType=”any”/>

Можливості, які використовуються в топологічної моделі, зазвичай діляться на дві великі групи: функціональні (dependency) можливості і можливості розміщення (hosting). Можливість розміщення відображає здатність одиниці розміщувати інші одиниці або надавати їм сервіси проміжного шару (до таких одиницям відноситься, наприклад, сервер додатків). Функціональна можливість відображає здатність одиниці (наприклад, джерела даних) виконувати якусь роботу для інших одиниць, розміщених спільно з нею або окремо. Модель не визначає формальних типів для вищезазначених категорій можливостей – для цього використовується атрибут linkType, Який приймає значення hosting або dependency відповідно. Як правило, значення атрибуту linkType для можливостей, що відносяться до категорії функціональних, так само dependency, Тоді як для можливостей, що відносяться до розміщення, значення цього атрибута дорівнює any, Враховуючи той факт, що від їх налаштувань можуть опосередковано залежати інші одиниці.


Приклад опису можливості розміщення приведений в лістингу 11.


Лістинг 11. Можливість розміщення




 <core:capability
displayName=”SampleHostingCapability”
name=”sampleHostingCapability” description = “Приклад можливості розміщення”>
linkType=”hosting”/>

Приклад опису функціональної можливості приведений в лістингу 12.


Лістинг 12. Функціональна можливість




 <core:capability
displayName=”SampleDependencyCapability”
name=”sampleDependencyCapability” description = “Приклад функціональної можливості”>
linkType=”dependency”/>

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


Приклад функціональної можливості, пов’язаної з настроювальної одиницею, приведений в лістингу 13.


Лістинг 13. Можливість залежності, пов’язана з настроювальної одиницею




 <core:unit
displayName=”SampleConfigurationUnit”
name=”sampleConfigurationUnit” description = “Приклад настроювальної одиниці”>
configurationUnit=”true”>
<core:capability
displayName=”SampleDependencyCapability”
name=”sampleDependencyCapability”
description = “Приклад функціональної можливості”>
linkType=”dependency”/>
</core:unit>

Функціональна можливість з наведеного вище прикладу може бути пов’язана також і з одиницею SampleUnit, як показано в лістингу 14.


Лістинг 14. Зв’язок можливості з одиницею SampleUnit




 <core:unit
displayName=”SampleUnit”
name=”sampleUnit”description = “Приклад одиниці”>
<core:capability
displayName=”SampleDependencyCapability”
name=”sampleDependencyCapability” description = “Приклад функціональної можливості”>

linkType=”dependency”/>

</core:unit>


Використання можливостей в предметній області


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



У лістингу 15 наведено приклад топологічної моделі, визначальною екземпляр одиниці J2eeServer, що містить наступні об’єкти:



Зверніть увагу на URI простору імен області J2EE xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/”, Доданий у топологію для забезпечення можливості використання типів даній області.


Лістинг 15. Топологічна модель




 <?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology
xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/”
xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/” description = “Приклад топології, що ілюструє анатомію топологічної моделі”
displayName=”Sample Topology”
name=”SampleTopology”
decoratorSemantic=”com.ibm.ccl.soa.deploy.analysis.ads”
namespace=”developerworks.deploy”>
<core:unit description=”This is a sample unit”
displayName=”SampleUnit”
name=”sampleUnit”/>
<core:unit description = “Приклад настроювальної одиниці”>
displayName=”SampleConfigurationUnit”
name=”sampleConfigurationUnit”
configurationUnit=”true”/>
<core:unit description = “Приклад концептуальної одиниці”>
displayName=”SampleConceptualUnit”
name=”sampleConceptualUnit”
conceptual=”true”
goalInstallState=”not_installed”
initInstallState=”installed”
publishIntent=”do_not_publish”/>
<core:unit description = “Приклад стереотипізованої одиниці – компонента сервісу”>
displayName=”ServiceComponentUnit”
name=”serviceComponentUnit”>
<core:stereotype keyword=”service”
profile=”serviceProfile”/>
</core:unit>
<j2ee:unit.j2eeServerUnit
description=”This is a J2eeServer unit ”
displayName=”J2EE Server Unit ”
name=”j2eeServerUnit”
conceptual=”true”
goalInstallState=”installed”
initInstallState=”installed”>
<j2ee:capability.j2eeServer description = “Приклад можливості – сервера J2EE”>
displayName=”J2EE Server Capability”
name=”j2eeServer”
linkType=”any”/>
<j2ee:capability.j2eeContainer description = “Приклад можливості – контейнера J2EE”>
displayName=”J2EE Container Capability”
name=”j2eeContainer”
linkType=”hosting”
containerVersion=”1.4″/>
<j2ee:capability.servletContainer description = “Приклад можливості – контейнера сервлетов J2EE”>
displayName=”J2EE Servlet Container Capability”
name=”j2eeServletContainer”
linkType=”hosting”
containerVersion=”2.3″/>
<j2ee:capability.j2eeDatasource description = “Приклад функціональної можливості – джерела даних J2EE”>
displayName=”J2eeDatasourceCapability”
name=”j2eeDatasourceCapability”
linkType=”dependency”
jndiName=”jndi/datasource1″/>
</j2ee:unit.j2eeServerUnit>
<j2ee:component.ear description = “EAR-компонент”
displayName=”EAR Component ”
name=”earComponent”
configurationUnit=”false”
goalInstallState=”installed”
initInstallState=”not_installed”/>
</core:topology>

Вимога

Вимога відображає в моделі потреба одиниці, яка повинна бути задоволена середовищем розгортання. Вимозі відповідає елемент requirement, визначений у просторі імен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схеми, яка описує топологію. Елемент requirement є частиною елемента одиниці (unit), його унікальним ідентифікатором в рамках одиниці є ім’я, як показано в лістингу 16.


Лістинг 16. Вимога




 <core:requirement  name=”r0″/>

Вимога може мати атрибут linkType, Що має за замовчуванням значення, рівне dependency. Він призначений для вказівки типу зв’язку, якій одиниця зв’язується з задовольняючим вимогу об’єктом. Атрибут вимоги dmoType задає необов’язкове обмеження типу задовольняє даній вимозі одиниці або можливості. Також для цього елемента можна вказати опис і ім’я для відображення візуальними засобами. Обов’язковість вимоги може бути задана за допомогою атрибуту use, Приймаючого одне з наступних значень: required (Обов’язково), optional (Необов’язково) і prohibited (Заборонено). За замовчуванням атрибут має значення required.


У лістингу 18 наведено приклад необов’язкового функціонального вимоги, яке повинно бути задоволене такою можливістю, як джерело даних J2EE, що позначається зв’язком залежності. Значення атрибута dmoType для функціональних вимог задає обмеження на тип задовольняє вимогу можливості.


Лістинг 18. Необов’язкове функціональне вимога




<core:requirement
displayName=”Datasource Dependency Requirement”
name=”r0″ description = “Приклад функціонального вимоги”>
linkType=”dependency”
dmoType=”j2ee:J2EEDatasource”
use=”optional” />

У лістингу 19 наведено приклад обов’язкової вимоги до розміщення, яке повинно бути задоволене такою можливістю, як контейнер J2EE Enterprise Java ™ Beans (EJB) за допомогою зв’язку розміщення. Значення атрибуту dmoType для вимог до розміщення задає обмеження на тип задовольняє вимогу можливості.


Лістинг 19. Вимога до розміщення




 <core:requirement
displayName=”EJB Container Hosting Requirement”
name=”r1″ description = “Приклад вимоги до розміщення”>
linkType=”hosting”
dmoType=”j2ee:J2eeContainer”/>

Крім того, можна створити вимога до елемента одиниці і за допомогою зв’язку “частина-ціле” вказати іншу одиницю, що задовольняє цій вимозі. Зверніть увагу, що в цьому випадку значення атрибуту dmoType повинно відповідати типу одиниці, а не можливості (як це було в попередніх випадках).


Лістинг 20. Вимога до елементу





displayName=”Unit Member Requirement”

name=”r2″ description = “Приклад вимоги до елементу, який вказує на те, що дана одиниця може включати в себе іншу одиницю ”
linkType=”member”
dmoType=”core:Unit”/>


Атрибут linkType може також приймати значення any, Але можливості, що відносяться відразу до всіх типів (dependency [Залежність], hosting [Розміщення] та member [“Частина-ціле”]), зустрічаються рідко. Також для вимоги може бути заданий атрибут extends, Що вказує відносний шлях до батьківського вимогу, розширенням якого є поточне вимога. Даний прийом використовується при визначенні областей і зустрічається рідко.


Використання вимог в предметній області


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


У лістингу 21 наведено приклад топології, що містить компонент-додаток J2EE, що відноситься до предметної області J2EE, і містить наступні об’єкти:



Лістинг 21. Топологія, що описує додаток J2EE




<?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology
xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/”
xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/” description = “Приклад топології, що ілюструє анатомію топологічної моделі”
displayName=”Sample Topology” name=”SampleTopology”
decoratorSemantic=”com.ibm.ccl.soa.deploy.analysis.ads”
namespace=”developerworks.deploy”>
displayName=”J2EE Server Unit ” name=”j2eeServerUnit”
conceptual=”true” goalInstallState=”installed”
initInstallState=”installed”>
<j2ee:capability.j2eeServer description = “Приклад можливості – сервера J2EE”>
displayName=”J2EE Server Capability” name=”j2eeServer”
linkType=”any”/>
<j2ee:capability.j2eeContainer description = “Приклад можливості – контейнера J2EE”>
displayName=”J2EE Container Capability”
name=”j2eeContainer” linkType=”hosting”
containerVersion=”1.4″/>
<j2ee:capability.servletContainer description = “Приклад можливості – контейнера сервлетов J2EE”>
displayName=”J2EE Servlet Container Capability”
name=”j2eeServletContainer” linkType=”hosting”
containerVersion=”2.3″/>
</j2ee:unit.j2eeServerUnit>
<j2ee:component.ear description = “EAR-компонент”
displayName=”EAR Component ” name=”earComponent”
configurationUnit=”false” goalInstallState=”installed”
initInstallState=”not_installed”>
<core:requirement description = “Приклад вимоги до функціонала джерела даних”>
displayName=”Datasource Dependency Requirement”
name=”r0″
dmoType=”j2ee:J2EEDatasource”
linkType=”dependency”
use=”optional”/>
<core:requirement description = “Приклад вимоги до розміщення в J2EE-контейнері”>
displayName=”J2EE Container Hosting Requirement”
name=”r1″
dmoType=”j2ee:J2EEContainer”
linkType=”hosting”/>
<core:requirement description = “Приклад вимоги до елементу – компоненту EJB, показує, що дана одиниця може включати одиниці типу EjbComponent ”
displayName=”EJB Component Member Requirement”
name=”r2″
dmoType=”j2ee:EjbModule”
linkType=”member”/>
</j2ee:component.ear> </core:topology>

Артефакт

У топологічної моделі артефакт являє розгортається об’єкт, який може міститися в одиниці. Артефакту відповідає елемент artifact, визначений у просторі імен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схеми топології. Елемент одиниці (unit) може містити один або декілька елементів artifact, унікальним ідентифікатором яких в рамках одиниці є ім’я, як показано в лістингу 22. Артефакт є абстрактним типом схеми топології. Для опису конкретного артефакту, як правило, створюються нові типи – розширення базового типу артефакту. У схемі топології оголошений широко застосовуваний тип артефакту artifact.file, Що представляє файловий ресурс.


Лістинг 22. Артефакт




 <core:artifact.file
displayName=”Sample File Jar ”
name=”a1″>
<core:fileURI>samplefile.jar</core:fileURI>
</core:artifact.file>

Використання артефактів в предметній області


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


Лістинг 23. Зв’язок компонента-додатки J2EE з EAR-файлом




 <?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology
xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/”
xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/” description = “Приклад топології, що ілюструє анатомію топологічної моделі”
displayName=”Sample Topology” name=”SampleTopology”
decoratorSemantic=”com.ibm.ccl.soa.deploy.analysis.ads”
namespace=”developerworks.deploy”>
displayName=”J2EE Server Unit ” name=”j2eeServerUnit” conceptual=”true”
goalInstallState=”installed” initInstallState=”installed”>
<j2ee:capability.j2eeServer description = “Приклад можливості – сервера J2EE”>
displayName=”J2EE Server Capability” name=”j2eeServer” linkType=”any”/>
<j2ee:capability.j2eeContainer description = “Приклад можливості – контейнера J2EE”>
displayName=”J2EE Container Capability” name=”j2eeContainer”
linkType=”hosting” containerVersion=”1.4″/>
<j2ee:capability.servletContainer description = “Приклад можливості – контейнера сервлетов J2EE”>
displayName=”J2EE Servlet Container Capability” name=”j2eeServletContainer”
linkType=”hosting” containerVersion=”2.3″/>
</j2ee:unit.j2eeServerUnit>
<j2ee:component.ear description = “EAR-компонент”
displayName=”EAR Component ” name=”earComponent”
configurationUnit=”false” goalInstallState=”installed”
initInstallState=”not_installed”>
<core:artifact.file
displayName=”EAR Component1 EAR ”
name=”a1″>
<core:fileURI>j2eeEarComponent1.ear</core:fileURI>
</core:artifact.file>
<core:requirement description = “Приклад вимоги до функціонала джерела даних”>
displayName=”Datasource Dependency Requirement” name=”r0″
dmoType=”j2ee:J2EEDatasource” linkType=”dependency”
use=”optional”/>
<core:requirement description = “Приклад вимоги до розміщення в J2EE-контейнері”>
displayName=”J2EE Container Hosting Requirement” name=”r1″
dmoType=”j2ee:J2EEContainer” linkType=”hosting”/>
<core:requirement description = “Приклад вимоги до елементу – компоненту EJB, показує, що дана одиниця може включати одиниці типу EjbComponent ”
displayName=”EJB Component Member Requirement” name=”r2″
dmoType=”j2ee:EjbModule” linkType=”member”/>
</j2ee:component.ear>
</core:topology>

Відносини і Зв’язку

Опис типової ІТ-системи вимагає вказівки відносин між її елементами. Ці відносини визначають семантику системи, допомагаючи її розумінню і полегшуючи перевірку її коректності. Топологічна модель надає засоби для подальшої класифікації відносин, заснованої на їх семантиці. Модель присвоює цим відносинам імена, якщо їх семантика накладає на них деякі початкові вимоги. Між одиницями топології можуть бути встановлені різні відносини, що подаються зв’язками. У початковий набір типів зв’язків входять такі зв’язки, як Dependency (Залежність), Hosting (Розміщення) та Member (“Частина-ціле”). Кожна з них пов’язує джерело зв’язку з клієнтом зв’язку.


Зв’язок залежності


Тип зв’язку залежність використовується для з’єднання вимоги, що має обмеження на тип зв’язку dependency (Або any), З можливістю. Існування такого зв’язку показує, що функціональне вимога задовольняється функціональної можливістю. Цей зв’язок також дозволяє явним чином вказати відповідність певного вимоги певної можливості. Елемент link.dependency визначений у просторі імен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схеми топології. Елемент link.dependency є частиною елемента вимоги (requirement), пов’язаного з елементом одиниці (unit). Ідентифікатором елемента link.dependency в рамках вимоги є ім’я, як показано в лістингу 24.


Лістинг 24. Зв’язок залежності




 <core:requirement name=”r1″>
<core:link.dependency
name=”link1″
source=”/Unit1/r1″
target=”/Unit2/c1″/>
</core:requirement>

Приклад використання зв’язку залежно в предметній області


Припустимо, що компонент-додаток J2EE, визначений в предметній області J2EE, може мати вимога до функціоналу можливості J2eeDatasource, яку забезпечує одиниця J2eeDatasourceUnit. Отже, між компонентом і джерелом даних може бути встановлено зв’язок залежності, що має вимога в якості джерела, а можливість – в якості клієнта, як показано в лістингу 25.


Лістинг 25. Зв’язок залежності




<?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology
xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/”
xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/” description = “Приклад топології, що ілюструє анатомію топологічної моделі”
displayName=”Sample Topology” name=”SampleTopology”
decoratorSemantic=”com.ibm.ccl.soa.deploy.analysis.ads”
namespace=”developerworks.deploy”>
displayName=”J2EE Server Capability” name=”j2eeServer” linkType=”any”/>
<j2ee:capability.j2eeContainer description = “Приклад можливості – контейнера J2EE”>
displayName=”J2EE Container Capability” name=”j2eeContainer”
linkType=”hosting” containerVersion=”1.4″/>
<j2ee:capability.servletContainer description = “Приклад можливості – контейнера сервлетов J2EE”>
displayName=”J2EE Servlet Container Capability”
name=”j2eeServletContainer” linkType=”hosting” containerVersion=”2.3″/>
<j2ee:capability.j2eeDatasource description = “Приклад функціональної можливості – джерела даних J2EE”>
displayName=”J2eeDatasourceCapability” name=”j2eeDatasourceCapability”
linkType=”dependency” jndiName=”jndi/datasource1″/>
</j2ee:unit.j2eeServerUnit>
<j2ee:component.ear description = “EAR-компонент”
displayName=”EAR Component ” name=”earComponent”
configurationUnit=”false” goalInstallState=”installed”
initInstallState=”not_installed”>
<core:artifact.file displayName=”EAR Component1 EAR ” name=”a1″>
<core:fileURI>j2eeEarComponent1.ear</core:fileURI>
</core:artifact.file>
<core:requirement description = “Приклад вимоги до функціонала джерела даних”>
displayName=”Datasource Dependency Requirement” name=”r0″
dmoType=”j2ee:J2EEDatasource” linkType=”dependency” use=”optional”>
<core:link.dependency
name=”r0Toj2eeDatasourceCapability”
source=”/earComponent/r0″
target=”/j2eeServerUnit/j2eeDatasourceCapability”/>
</core:requirement>
<core:requirement description = “Приклад вимоги до розміщення в J2EE-контейнері”>
displayName=”J2EE Container Hosting Requirement” name=”r1″
dmoType=”j2ee:J2EEContainer” linkType=”hosting”/>
<core:requirement description = “Приклад вимоги до елементу – компоненту EJB,
member of type EjbComponent unit are allowed ”
displayName=”EJB Component Member Requirement” name=”r2″
dmoType=”j2ee:EjbModule” linkType=”member”/>
</j2ee:component.ear>
</core:topology>

Зв’язок розміщення


Тип зв’язку розміщення вказує на розміщення однієї одиниці в іншій одиниці, якщо вимоги однієї відповідають можливостям інший. По суті, цей зв’язок описує ставлення одиниці-джерела, що має можливість розміщення і одиниці-клієнта, для якої визначено вимога до розміщення. Зв’язки розміщення відповідає елемент link.hosting, Визначений у просторі імен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схеми топології. Елемент link.hosting є частиною елемента одиниці (unit), що розміщає іншу одиницю. Ідентифікатором елемента link.hosting в рамках елемента одиниці є ім’я, як показано в лістингу 26.


Лістинг 26. Зв’язок розміщення




 <core:unit displayName=”HostUnit” name=”hostUnit”>
<core:link.hosting
name=”link1″
source=”/hostUnit”
target=”/hosteeUnit”/>
</core:unit>

Приклад використання зв’язку розміщення в предметній області


Припустимо, що дана топологія, що містить:



У цій топології також може бути описаний екземпляр компонента-додатки J2EE, визначений в предметній області J2EE і містить:



В даному випадку між розміщуваної одиницею – компонентом-додатком J2EE і розміщає одиницею J2eeServer може бути створена зв’язок розміщення. Однак коректна зв’язок розміщення між компонентом-додатком J2EE і одиницею HttpServer не може бути створена, оскільки можливості одиниці HttpServer не задовольняють вимогам до розміщення даного компонента, як показано в лістингу 27.


Лістинг 27. Коректна зв’язок розміщення




 <?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology
xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/”
xmlns:http=”http://www.ibm.com/ccl/soa/deploy/http/1.0.0/”
xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/” description = “Приклад топології, що ілюструє анатомію топологічної моделі”
displayName=”Sample Topology” name=”SampleTopology”
decoratorSemantic=”com.ibm.ccl.soa.deploy.analysis.ads”
namespace=”developerworks.deploy”>
<core:unit description=”This is a sample unit”
displayName=”SampleUnit” name=”sampleUnit”/>
displayName=”J2EE Server Unit ” name=”j2eeServerUnit”
conceptual=”true” goalInstallState=”installed” initInstallState=”installed”>
<j2ee:capability.j2eeServer description = “Приклад можливості – сервера J2EE”>
displayName=”J2EE Server Capability” name=”j2eeServer” linkType=”any”/>
<j2ee:capability.j2eeContainer description = “Приклад можливості – контейнера J2EE”>
displayName=”J2EE Container Capability” name=”j2eeContainer”
linkType=”hosting” containerVersion=”1.4″/>
<j2ee:capability.servletContainer description = “Приклад можливості – контейнера сервлетов J2EE”>
displayName=”J2EE Servlet Container Capability”
name=”j2eeServletContainer” linkType=”hosting”
containerVersion=”2.3″/>
<j2ee:capability.j2eeDatasource description = “Приклад функціональної можливості – джерела даних J2EE”>
displayName=”J2eeDatasourceCapability”
name=”j2eeDatasourceCapability”
linkType=”dependency” jndiName=”jndi/datasource1″/>
<core:link.hosting
name=”j2eeServerUnitHostsearComponent”
source=”/j2eeServerUnit”
target=”/earComponent”/>
</j2ee:unit.j2eeServerUnit>
<j2ee:component.ear description = “EAR-компонент”
displayName=”EAR Component ” name=”earComponent”
configurationUnit=”false” goalInstallState=”installed”
initInstallState=”not_installed”>
<core:artifact.file displayName=”EAR Component1 EAR ” name=”a1″>
<core:fileURI>j2eeEarComponent1.ear</core:fileURI>
</core:artifact.file>
<core:requirement description = “Приклад вимоги до функціонала джерела даних”>
displayName=”Datasource Dependency Requirement” name=”r0″
dmoType=”j2ee:J2EEDatasource” linkType=”dependency” use=”optional”>
<core:link.dependency name=”r0Toj2eeDatasourceCapability”
source=”/earComponent/r0″
target=”/j2eeServerUnit/j2eeDatasourceCapability”/>
</core:requirement>
<core:requirement description = “Приклад вимоги до розміщення в J2EE-контейнері”>
displayName=”J2EE Container Hosting Requirement” name=”r1″
dmoType=”j2ee:J2EEContainer”
linkType=”hosting”/>
<core:requirement description = “Приклад вимоги до елементу – компоненту EJB,
member of type EjbComponent unit are allowed ”
displayName=”EJB Component Member Requirement” name=”r2″
dmoType=”j2ee:EjbModule” linkType=”member”/>
</j2ee:component.ear>
<http:unit.httpServerUnit
displayName=”Http Server”
name=”httpServerUnit”
conceptual=”false”>
<http:capability.httpServer
displayName=”Http Server Capability ”
name=”Http Server Capability”
linkType=”any”/>
<j2ee:capability.servletContainer
displayName=”Servlet Container Capability”
name=”servletContainer”
linkType=”any”
containerVersion=”2.3″/>
</http:unit.httpServerUnit>
</core:topology>

Зв’язок “частина-ціле”


Зв’язок “Частина-ціле” вказує на те, що одна одиниця є частиною іншої. При цьому клієнт зв’язку є частиною, а джерело – цілим. По суті, цей зв’язок описує ставлення джерела зв’язку – одиниці, що є цілим (для якою визначено вимога до елементу, із зазначенням певного типу одиниці) і клієнта зв’язку – одиниці, що належить даному типу. Зв’язку “частина-ціле” відповідає елемент link.member, Визначений у просторі імен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схеми топології. Елемент link.member є частиною елемента одиниці (unit), для якої визначено вимога до елементу. Ідентифікатором елемента зв’язку “Частина-ціле” в рамках елемента одиниці є ім’я, як показано в лістингу 28.


Лістинг 28. Зв’язок “частина-ціле”




<core:unit displayName=”ContainerUnit” name=”containerUnit”>
<core:requirement
displayName=”Membership Requirement ”
name=”membershipRequirement” dmoType=”core:Unit”
linkType=”member”/>
<core:link.member name=”link1″ source=”/ContainerUnit”
target=”/MemberUnit1″/>
</core:unit>

Приклад використання зв’язку “частина-ціле” в предметній області


Припустимо, що між деякими компонентом-модулем Enterprise JavaBean і компонентом-додатком J2EE існує зв’язок “частина-ціле”, яка вказує на те, що модуль є частиною програми, як показано в лістингу 29.


Топологічна модель для даного прикладу буде включати:



У розглянутому випадку джерелом зв’язку “частина-ціле” буде компонент-додаток J2EE, а клієнтом – EJB-компонент.


Лістинг 29. Зв’язок EJB-компонента і J2EE-компонента




<?xml version=”1.0″ encoding=”UTF-8″?>
<core:topology
xmlns:core=”http://www.ibm.com/ccl/soa/deploy/core/1.0.0/”
xmlns:http=”http://www.ibm.com/ccl/soa/deploy/http/1.0.0/”
xmlns:j2ee=”http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/” description = “Приклад топології, що ілюструє анатомію топологічної моделі”
displayName=”Sample Topology” name=”SampleTopology”
decoratorSemantic=”com.ibm.ccl.soa.deploy.analysis.ads”
namespace=”developerworks.deploy”>
<core:unit description=”This is a sample unit”
displayName=”SampleUnit” name=”sampleUnit”/>
displayName=”J2EE Server Capability” name=”j2eeServer” linkType=”any”/>
<j2ee:capability.j2eeContainer description = “Приклад можливості – контейнера J2EE”>
displayName=”J2EE Container Capability” name=”j2eeContainer”
linkType=”hosting” containerVersion=”1.4″/>
<j2ee:capability.servletContainer description = “Приклад можливості – контейнера сервлетов J2EE”>
displayName=”J2EE Servlet Container Capability” name=”j2eeServletContainer”
linkType=”hosting” containerVersion=”2.3″/>
<j2ee:capability.j2eeDatasource description = “Приклад функціональної можливості – джерела даних J2EE”>
displayName=”J2eeDatasourceCapability”
name=”j2eeDatasourceCapability” linkType=”dependency” jndiName=”jndi/datasource1″/>
<core:link.hosting name=”j2eeServerUnitHostsearComponent” source=”/j2eeServerUnit”
target=”/earComponent”/>
</j2ee:unit.j2eeServerUnit>
<j2ee:component.ear description = “EAR-компонент”
displayName=”EAR Component ” name=”earComponent”
configurationUnit=”false” goalInstallState=”installed” initInstallState=”not_installed”>
<core:artifact.file displayName=”EAR Component1 EAR ” name=”a1″>
<core:fileURI>j2eeEarComponent1.ear</core:fileURI> </core:artifact.file>
<core:requirement description = “Приклад вимоги до функціонала джерела даних”>
displayName=”Datasource Dependency Requirement” name=”r0″
dmoType=”j2ee:J2EEDatasource” linkType=”dependency” use=”optional”>
<core:link.dependency name=”r0Toj2eeDatasourceCapability”
source=”/earComponent/r0″ target=”/j2eeServerUnit/j2eeDatasourceCapability”/>
</core:requirement>
<core:requirement description = “Приклад вимоги до розміщення в J2EE-контейнері”>
displayName=”J2EE Container Hosting Requirement” name=”r1″
dmoType=”j2ee:J2EEContainer” linkType=”hosting”/>
<core:requirement description = “Приклад вимоги до елементу – компоненту EJB,
member of type EjbComponent unit are allowed ”
displayName=”EJB Component Member Requirement” name=”r2″
dmoType=”j2ee:EjbModule” linkType=”member”/>
<core:link.member
name=”earComponentContainsejbComponent”
source=”/earComponent”
target=”/ejbComponent”/>
</j2ee:component.ear>
<http:unit.httpServerUnit
displayName=”Http Server” name=”httpServerUnit” conceptual=”false”>
<http:capability.httpServer displayName=”Http Server Capability ”
name=”Http Server Capability” linkType=”any”/>
<j2ee:capabil

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*