Продукты 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-модель сущностей топологической модели
Топология является элементом верхнего уровня топологической модели. Она описывает топологическую модель и все ее элементы, включая единицы и связи между ними. В одних случаях топология, описывающая ИТ-систему, может сводиться к единственному элементу. В других - может представлять собой декомпозицию множества компонентов и их связей до 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, определенный в пространстве имен http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ схемы, описывающей топологию. Его уникальным идентификатором в рамках элемента топологии (topology) является имя. Также для этого элемента можно указать описание и имя для отображения визуальными средствами, как показано в листинге 3.
<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. Такую единицу можно считать слотом в топологии, значение которого должно быть выбрано впоследствии.
<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"> <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> <j2ee:unit.j2eeServerUnit description="Единица J2eeServer"> 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.
<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 предусмотрено следующее:
- Типы единиц J2eeServer и J2eeContainer, имеющие атрибут
containerVersion - Возможность ServletContainer, имеющая атрибут
containerVersion - Возможность J2eeDatasource, имеющая атрибут
jndiName - Возможность J2eeServer, которая может имет конфигурационные атрибуты наподобие
serverNameи т.п.
В листинге 15 приведен пример топологической модели, определяющей экземпляр единицы J2eeServer, содержащий следующие объекты:
- Возможность размещения J2eeContainer со значением атрибута containerVersion, равным
1.4 - Возможность размещения ServletContainer со значением атрибута containerVersion, равным
2.3 - Возможность-зависимость J2eeDatasource со значением атрибута jndiName, равным
jndi/datasource1 - Возможность J2eeServer, которая может содержать конфигурационные атрибуты сервера J2EE
Обратите внимание на 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.
<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, и содержащий следующие объекты:
- Требование к размещению, удовлетворяемое возможностью J2eeContainer
- Функциональное требование, удовлетворяемое возможностью J2eeDatasource
- Требование к элементу, удовлетворяемое единицей/единицами типа J2EE EJB-компонент.
Листинг 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"> <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="This is a stereotyped service component unit" displayName="ServiceComponentUnit" name="serviceComponentUnit"> <core:stereotype keyword="service" profile="serviceProfile"/> </core:unit> <j2ee:unit.j2eeServerUnit description="Единица J2eeServer"> 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, представляющий файловый ресурс.
<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"> <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> <j2ee:unit.j2eeServerUnit description="Единица J2eeServer"> 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.
<core:requirement name="r1"> <core:link.dependency name="link1" source="/Unit1/r1" target="/Unit2/c1"/> </core:requirement> |
Пример использования связи зависимости в предметной области
Предположим, что компонент-приложение J2EE, определенный в предметной области J2EE, может иметь требование к функционалу возможности J2eeDatasource, которую обеспечивает единица J2eeDatasourceUnit. Следовательно, между компонентом и источником данных может быть установлена связь зависимости, имеющая требование в качестве источника, а возможность - в качестве клиента, как показано в листинге 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"> <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> <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: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.
<core:unit displayName="HostUnit" name="hostUnit"> <core:link.hosting name="link1" source="/hostUnit" target="/hosteeUnit"/> </core:unit> |
Пример использования связи размещения в предметной области
Предположим, что дана топология, содержащая:
- Экземпляр единицы J2eeServer, предоставляющей возможности J2eeContainer и ServletContainer
- Экземпляр единицы HttpServer, предоставляющей возможность ServletContainer
В этой топологии также может быть описан экземпляр компонента-приложения J2EE, определенный в предметной области J2EE и содержащий:
- Требование к размещению, удовлетворяемое возможностью типа J2eeContainer, предоставляемой единицей J2eeServerUnit
- Требование к размещению, удовлетворяемое возможностью типа ServletContainer, предоставляемой единицей J2eeServerUnit
В данном случае между размещаемой единицей - компонентом-приложением 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"/> <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="Единица J2eeServer"> 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, для которого определено требование к элементу типа модуль Enterprise JavaBean.
- EJB-компонент
В рассматриваемом случае источником связи "часть-целое" будет являться компонент-приложение 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"/> <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"/> <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:capability.servletContainer displayName="Servlet Container Capability" name="servletContainer" linkType="any" containerVersion="2.3"/> </http:unit.httpServerUnit> <j2ee:component.ejb displayName="EJB Component" name="ejbComponent" conceptual="false" initInstallState="not_installed" publishIntent="publish"> <j2ee:capability.ejbModule displayName="EJB Component" name="ejbComponentCapability" linkType="dependency" id="EJBComponent" version="1.0"/> </j2ee:component.ejb> </core:topology> |
В этой части цикла были представлены базовые концепции топологической модели, лежащей в основе архитектуры развертывания Rational Software Architect V7.5. В ходе изложения был разработан пример топологии, иллюстрирующий различные аспекты топологической модели, включая топологию, единицу, требование, возможность и несколько видов отношений, которые могут связывать эти объекты. Был проведен анализ типовых решений, которые стоит принимать во внимание при описании типов и отношений предметной области с помощью топологической модели. Следите за выходом следующей части цикла, которая подробно расскажет о более сложных концепциях топологической модели:
- Абстракция, инкапсуляция и повторное использование топологий
- Отношение реализации
- Семантика и использование ограничений
- Семантика и использование специальных связей (например, отложенное размещение, взаимодействие, емкость размещения, совместное размещение (collocation), запрет совместного размещения (anticollocation))
- Добавление пользовательских атрибутов
- Использование переменных в топологии
Нариндер Макин - архитектор программного обеспечения в IBM Research Triangle Part Lab, г. Дарем, Северная Каролина. Он занимается инструментами развертывания в группе IBM Rational Software Architect . За последние 12 лет он работал над несколькими инструментами для разработки, управляемой моделью, и развертывания. Нариндер имеет несколько зарегистрированных патентов и опубликованных статей. Он имеет степень бакалавра по специальности Computer Science and Engineering, полученную в Технологическом Институте Камла Неру (Индия), а также степень магистра по специальности Computer Science Бриджпортского университета (штат Коннектикут, США).