 | Уровень сложности: сложный Наталья Балаба-Лясковски, инженер-программист, IBM
20.05.2009 Типичный цикл разработки включает создание модели бизнес-анализа для выделения и понимания бизнес-целей с дальнейшим преобразованием её в модель архитектуры системы. Инструментарий трансформации бизнес-процессов в модель сервисов из состава IBM® Rational® Software Architect поможет Вам в создании этой модели. Эта статья (Часть 2, ссылка на Часть 1 приведена в разделе Ресурсы) описывает пошаговый сценарий создания собственной декомпозиции процесса для трансформации ваших бизнес-процессов в модели сервисов. Статья ориентирована на читателей, знакомых с разработкой расширений для трансформаций.
Обзор инструментария трансформации бизнес-процессов в модели сервисов
Механизм трансформации бизнес-процессов в модель сервисов из состава IBM Rational Software Architect состоит из первичной трансформации (main transform) и трех стандартных расширений.
Первичная трансформация создает UML-компонент (Unified Modeling Language), описывающий провайдера сервиса. Также она добавляет к данному компоненту UML-порты, представляющие интерфейсы, которые предоставляет сервис или которых он требует. Наконец, создается элемент CollaborationUse для связывания этого компонентного представления сервиса в архитектурной модели с элементом сотрудничества (Collaboration) модели бизнес-анализа. Каждый порт компонента ассоциируется с подходящей ролью. Элемент CollaborationUse, порты и ролевые ассоциации вместе представляют собой связку, используемую при проверке контракта, установленного соглашением о взаимодействии. Проверка контракта позволяет легко обратиться к исходной модели бизнес-анализа, чтобы убедиться, что компонент реализует процесс так, как описано в модели бизнес-анализа.
Рисунок 1. Основной результат работы инструмента трансформации: порты, связка проверки контракта, элемент CollaborationUse и ролевые ассоциации
Первичная трансформация не предоставляет какой-либо внутренней декомпозиции сгенерированных компонентов. Причина в том, что эти детали зависят от реализации, специфики и ограничений среды развертывания.
Задача формирования внутренней декомпозиции возлагается на расширения первичной трансформации. Каждое расширение создает собственную декомпозицию бизнес-процесса и описывает внутренние детали работы. Хотя с инструментарием трансформации поставляется не так много расширений, вы можете создавать различные декомпозиции сервисов путем разработки и регистрации собственных расширений для удовлетворения специфических требований.
Сценарий использования собственного расширения
В этом примере примем, что вы уже создали модель бизнес-анализа для новых сервисов и для моделирования интеграции унаследованных систем в решение. Эта модель описывает группу сервисов, работающих совместно и образующих рынок медицинских услуг (Medical Marketplace). Этот рынок предоставляет множество медицинских услуг под одной крышей. Каждый запрос клиента за услугой обрабатывается, при этом выбирается подходящий сервис и предлагается клиенту. Когда сервис отрабатывает, взимается оплата, и отклик клиента вносится в базу данных рынка (см. рисунок 2).
Рисунок 2. Модель бизнес-анализа с бизнес-процессами рынка медицинских услуг
Сосредоточимся на сервисе получения оплаты (Payment Collector service), который отвечает за проведение денежных сумм и получение оплаты после предоставления медицинских услуг. Ему необходим механизм учета записей о проведенных операциях. Для этого он использует сервис журналирования (Logger service). Эти сервисы ориентированы на использование существующего Java-кода.
Допустим, что существуют унаследованные сервисы биллинга и журналирования (Billing and Logging), реализованные как Java-библиотеки. Сервис биллинга предоставляет Java-интерфейс Billing. Его конкретная реализация представлена классом com.acme.billing.MedicalBilling использует сервис журналирования, определенный в другой унаследованной библиотеке, com.acme.logging (см. рисунок 3).
Рисунок 3. Унаследованные Java-библиотеки, содержащие реализации сервисов биллинга и журналирования
Законченное SOA-решение будет развернуто на языке Services Component Definition Language (SCDL). Задачей разрабатываемого собственного расширения будет являться генерация SCDL-модуля, который будет связываться с унаследованной Java-библиотекой.
Основные необходимые шаги для расширения бизнес-процесса до модели сервисов
- Создайте проект плагина Eclipse (Eclipse plug-in).
- Создайте класс трансформации (см. пример в листинге 1).
Листинг 1. Код для создания класса трансформации
package com.ibm.xtools.transform.cfm.example.transform;
import com.ibm.xtools.transform.cfm.example.rules.MyPopulateComponentRule;
import com.ibm.xtools.transform.core.Transform;
public class MyTransform
extends Transform {
//id of the transformation
public static final String TRANSFORM_ID =
"com.ibm.xtools.transform.cfm.example.transform.MyTransformId";
public MyTransform() {
super(TRANSFORM_ID); // instantiate transformation using id
add(new MyPopulateComponentRule());//program transformation with this rule
}
}
|
Замечание:
При создании идентификатора расширения (extension ID) постарайтесь сделать его уникальным. Это важно, поскольку когда конфигурация трансформации показывает, что процесс необходимо преобразовать, и указывает для этого конкретный идентификатор расширения, расширение именно с этим идентификатором будет выбрано и использовано для трансформации процесса.
- Встройте функциональность в класс
MyPopulateComponentRule. Код, представленный в листинге 2, описывает ключевую функциональность этого правила.
Листинг 2. Код MyPopulateComponentRule
public class MyPopulateComponentRule extends ModelRule {
/*
* canAccept method asserts wither or not the extension is applicable
*/
public boolean canAccept(ITransformContext context) {
// the rule will be invoked if the current node on the source side is
// an instance of UML Collaboration and the node on the target side
// is instance of UML Component
return context.getSource() instanceof Collaboration
&& context.getTarget() instanceof Component;
}
/*
* createTarget method will perform additional (to main) transformation of the
Collaboration(service) in the source
* model to the elements in the target model
*/
protected Object createTarget(ITransformContext context) throws Exception {
Component collaborationComponent = (Component) context.getTarget();
Component java_adapter = createJavaConverter(collaborationComponent);
assert (java_adapter != null);
Property attribute = collaborationComponent.createOwnedAttribute(
"java_adapter", java_adapter);
for (Iterator e = collaborationComponent.getOwnedPorts().iterator(); e.hasNext();) {
Port port = (Port) e.next();
// there will only one port that provides interface to the outside.
if (!port.getProvideds().isEmpty()) {
Port in_port = java_adapter.createOwnedPort("in_" + port.getName(), null);
Interface anInterface = (Interface) port.getProvideds().get(0);
addProvidedInterface(anInterface, in_port);
createConnector(collaborationComponent, port, in_port, null, attribute,
ConnectorKind.DELEGATION_LITERAL);
} else if (!port.getRequireds().isEmpty()) {
Interface anInterface = (Interface) port.getRequireds().get(0);
Type type = createUsage(java_adapter, anInterface);
Port out_port = java_adapter.createOwnedPort("out_" + port.getName(), type);
createConnector(collaborationComponent, out_port, port, attribute, null,
ConnectorKind.DELEGATION_LITERAL);
}
}
return collaborationComponent;
}
/*
* auxiliary method – creates java adapter component for the role,
which represents Collaboration (service) itself
*/
private Component createJavaAdapter(Component collaborationComponent) {
for (Iterator e = collaborationComponent.getOwnedPorts().iterator(); ehasNext();) {
Port port = (Port) e.next();
if (!port.getProvideds().isEmpty()) {
return (Component) collaborationComponent..createPackagedElement(port.getName() +
"Adapter",UMLPackage.Literals.COMPONENT);
}
}
return null;
}
…
}
Create the extension condition class:
/**
* com.ibm.xtools.transform.cfm.example.condition.MyExtensionCondition
*/
public class MyExtensionCondition
extends TransformCondition {
public MyExtensionCondition() {
super();
}
protected boolean isContextSatisfied(ITransformContext context) {
return (context.getSource() instanceof Collaboration)
&& CommonConfigUtil.getExtensionIdFor(
(Collaboration) context.getSource(), context).equals(
MyTransform.TRANSFORM_ID);
}
}
|
Условие будет проверяться в процессе выполнения для выяснения того, был ли бизнес-процесс сконфигурирован для преобразования с помощью собственной трансформации или нет.
- Зарегистрируйте Ваше расширение в XML-файле плагина. В листинге 3 приведен пример декларации собственного расширения.
Листинг 3. Пример кода XML-файла плагина, описывающего собственное расширение
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.2"?>
<plugin>
<extension
point="com.ibm.xtools.transform.core.transformationExtensions">
<TransformationExtension
author="you"
description="my custom extension"
document="optional"
enabled="true"
id="com.ibm.xtools.transform.cfm.example.transform.MyTransformId"
name="My custom extension"
targetTransformation="com.ibm.xtools.transform.cfm.wbm.transforms.MainTransform"
version="1.0.0">
<TransformDefinition
acceptCondition="com.ibm.xtools.transform.cfm.example.condition.MyExtensionCondition"
class="com.ibm.xtools.transform.cfm.example.transform.MyTransform"
id="com.ibm.xtools.transform.cfm.example.transform.MyTransformId"/>
<ExtendTransform
targetTransform="com.ibm.xtools.transform.cfm.wbm.transforms.OwnedBehaviorTransform">
<AddTransform id="com.ibm.xtools.transform.cfm.example.transform.MyTransformId"/>
</ExtendTransform>
</TransformationExtension>
</extension>
</plugin>
|
Целевой трансформацией этого примера собственного расширения является базовая трансформация бизнес-процессов в модели сервисов:
com.ibm.xtools.transform.cfm.wbm.transforms.MainTransform
Также это собственное расширение указывает, какое условие расширяемости должно использоваться для определения применимости расширения:
com.ibm.xtools.transform.cfm.example.condition.MyExtensionCondition
И, наконец, это собственное расширение указывает расширяемое направление преобразования:
com.ibm.xtools.transform.cfm.wbm.transforms.OwnedBehaviorTransform
Развертывание собственного расширения
- Сконфигурируйте трансформацию.
- После завершения предыдущих этапов экспортируйте ваш плагин в папку плагинов и перезапустите Rational Software Architect.
Ваше собственное расширение будет доступно для использования из интерфейса конфигурации, как показано на рисунке 4.
Рисунок 4. Настройка трансформации для использования собственного расширения
- Настройте один из процессов на использование собственного расширения.
- Сохраните конфигурацию и запустите трансформацию.
- Работая с результатом трансформации, продолжайте развивать модель, используя делегирование унаследованному коду (см. рисунок 5).
Рисунок 5. Сервис получения оплаты, трансформированный с помощью собственного расширения декомпозиции
Созданная декомпозиция проиллюстрирована на рисунке 5. Теперь все готово для следующего шага.
Делегирование вызовов Java-библиотеке
Роль Java-адаптера заключается в делегировании вызовов сервиса Java-библиотеке. Для его моделирования:
- Создайте второе свойство (часть) сервиса получения оплаты, введя
BillingComponent, и добавьте два порта:
- Добавьте первый в myRoleAdapter, установив требуемый интерфейс как
com.acme.billing.Billing
- Добавьте второй в Billing component, установив тип как
com.acme.billing.MedicalBilling (см. рисунок 6).
Рисунок 6. Сопряжение расширения с унаследованным кодом
Замечание:
Сервис биллинга использует другой сервис - сервис журналирования. Если реализация сервиса журналирования имеется наряду с реализацией сервиса биллинга, вы можете моделировать сервис журналирования так же, как и сервис биллинга. Если же реализация сервиса журналирования отсутствует, его можно смоделировать как часть функциональности компонента myRoleAdapter.
Теперь эту модель можно использовать в SOA-трансформации для создания артефактов, пригодных для развертывания. SOA-трансформация преобразует сервис получения оплаты в проект модуля бизнес-интеграции в IBM®WebSphere® Integration Developer (IBM®WebSphere® Integration Developer business integration module project). Составляющие Java-адаптера и MedicalBilling преобразуются в компоненты Service Component Architecture (SCA) этого модуля. В SCA-компоненте, созданном на базе MedicalBilling, появятся ссылки на реализацию в унаследованных Java-библиотеках.
Заключение и содержание Части 3
Как показано в этой статье, инструментарий трансформации бизнес-процессов в модели сервисов обеспечивает взаимосвязь между бизнес-моделированием в WebSphere Business Modeler и проектированием модели на UML. Компании со специфическими средами развертывания и требованиями к реализации могут адаптировать трансформацию с учетом их потребностей. Созданные трансформацией артефакты могут использоваться для дальнейшего моделирования в Rational Software Architect. Также они могут быть преобразованы в проект WebSphere Integration Developer с использованием инструмента SOA-трансформации из состава Rational Software Architect.
Дальнейшая информация о SOA-трансформации будет представлена в следующей статье этой серии - "Переход к SOA: Часть 3. Преобразование UML в SOA." Эта статья в деталях описывает переход от UML-модели программного сервиса к предметной SOA-реализации с использованием инструмента трансформации UML в SOA из состава Rational Architect версии 7.0.0.2 и выше. Этот инструмент служит объединяющей конструкцией для различных расширений трансформации для конкретных программных реализаций и сред исполнения.
Ресурсы Научиться
Получить продукты и технологии
Обсудить
Об авторе | | | Наталья Балаба-Лясковски (Natalia Balaba-Liaskovski) – инженер-программист, занимается поддержкой инструментария IBM Rational. |
Выскажите мнение об этой странице
| |
