Статья поясняет моделирование реализации процесса BPEL в UML. Унифицированный язык моделирования (Unified Modeling Language, UML) предоставляет удобную, хорошо понятную, документированную и часто используемую поддержку для моделирования прецедентов, совместной работы, данных, интерфейсов, классов, компонентов, взаимодействия, состояний и деятельности. Его можно использовать для создания прикладных моделей, которые можно преобразовать в архитектуры для различных платформ. Преобразование из UML в исполняемый язык бизнес-процессов (Business Process Execution Language, BPEL), которое называется UML-to-BPEL и которое описывает эта статья, преобразует артефакты UML в артефакты BPEL.
Язык Business Process Execution Language for Web Services (BPEL4WS, или BPEL) - это стандарт на основе XML для создания спецификаций поведения бизнес-процессов, основанный на Web-сервисах. Он создан на базе языка определения Web-сервисов (Web Services Definition Language, WSDL) и определения схемы XML (XML Schema Definition, XSD). Преобразование из UML в BPEL может брать модели процессов, разработанные в средствах работы с UML (например, IBM Rational Software Architect или Rational Software Modeler), и преобразовывать их в корректные файлы BPEL, XSD и WSDL, что необходимо для реализации этих процессов.
В настоящее время преобразование UML-to-BPEL, которое можно выполнить в IBM Rational Software Architect (7.0.0.5), не является отдельным преобразованием, т.е. вы не запускаете одно только преобразование. Вернее сказать, что оно выполняется с помощью преобразования UML-to-SOA, т.е. из UML в сервис-ориентированную архитектуру (service-oriented architecture, SOA), когда это необходимо. Rational Software Architect предоставляет много полезных инструментов, которые помогают архитектору программного обеспечения (ПО) проектировать систему. Преобразования из UML, например в XSD и в WSDL, доступны только в Rational Software Architect, и преобразование UML-to-BPEL использует это ПО для генерации артефактов XSD и WSDL.
BPEL предоставляет нотацию XML и связанную с ней семантику для указания поведения бизнес-процессов на базе Web-сервисов. Процесс BPEL4WS определяется в терминах его взаимодействия с партнерами. Партнер может предоставлять сервисы для процесса, требовать сервисы у процесса или участвовать в двустороннем взаимодействии с процессом. Таким образом, язык BPEL обеспечивает интеграцию Web-сервисов. Он указывает порядок, в котором имеет смысл вызывать собрание сервисов, и он назначает ответственность за каждый из сервисов перед партнером. Его можно использовать как для указания общедоступных интерфейсов для партнеров, так и для описания исполняемых процессов.
UML - это стандарт группы по управлению объектами (Object Management Group, OMG). Он предоставляет нотацию для визуального моделирования, которая полезна для проектирования и понимания сложных систем. У UML есть несколько значительных преимуществ.
- Это наиболее широко известная объектно-ориентированная нотация для моделирования.
- Этот язык использует графическую нотацию, которую можно сразу понять.
- Он предлагает широкий набор семантик для фиксации ключевых возможностей объектно-ориентированных систем.
UML широко используется при разработке объектно-ориентированного ПО. Этот язык также используется (с некоторыми настройками) для компонентного ПО, моделирования бизнес-процессов, моделирования сервисов и проектирования систем. Это позволяет применить широкий опыт использования UML для совершенствования технологий Web-сервисов.
Преобразование в BPEL для Web-сервисов
Преобразование UML-to-BPEL использует для генерации файла BPEL следующий подход.
- Процесс BPEL генерируется на базе компонента UML.
- В процессе BPEL для каждого элемента UML Activity (действие UML) элемента UML Component (компонент UML) генерируется область BPEL.
- На базе информации о портах, которыми владеет элемент UML Component, генерируются ссылки партнера BPEL .
Требования к преобразованию UML-to-BPEL должны учитывать процесс моделирования элемента UML Activity.
Здесь необходимо сосредоточиться в основном на том, как преобразование UML-to-BPEL поддерживается в настоящее время в ПО Rational Software Architect версии 7.0.0.4, а также на некоторых ключевых требованиях моделирования в UML. Это необходимо для генерации артефактов BPEL. В данной статье используется пример модели, процесс заказа на покупку (Purchase Order Process). Он позволяет пояснить некоторые требования преобразования UML-to-BPEL при моделировании диаграммы действий (Activity diagram).
В настоящее время процесс преобразования UML-to-BPEL не требует расширения или изменения языка UML, но при моделировании диаграммы действий необходимо иметь под рукой некоторые подробности.
Подробное рассмотрение модели Purchase Order Process
Рассмотрим подробнее пример процесса. Элемент UML OrderProcessor Component содержит четыре порта.
- Порт Purchasing, который содержит предоставленный элемент Interface (интерфейс) под названием Purchasing ("Закупка").
- Порт Invoicing ("Выставление счета"), который содержит один предоставленный интерфейс под названием InvoiceProcessing ("Обработка счета") и один необходимый интерфейс под названием Invoicing.
- Порт Scheduling ("Планирование"), который содержит необходимый интерфейс под названием Scheduling.
- Порт Shipping ("Поставка"), который содержит один предоставленный интерфейс под названием ScheduleProcessing ("Обработка плана") и один необходимый интерфейс под названием Shipping.
Элемент UML processPurchaseOrder Activity - это собственное поведение элемента OrderProcessor Component. Он представляет собой действие, которое предоставляет все необходимые детали реализации компонента.
На рис. 1 показан элемент UML Activity, который является собственным поведением компонента OrderProcessor (UML Component). Компонент OrderProcessor ("Обработчик заказов") показан на рис. 2.
Рисунок 1. processPurchaseOrder ("Обработка заказа на покупку"), элемент UML Activity
Рисунок 2. OrderProcessor, элемент UML Component
Значения свойств устанавливаются следующим образом:
|
Purchasing::processPurchaseOrder(customerInfo:Customer, purchaseOrder:PurchaseOrder):Invoice |
Элемент Activity должен иметь параметры, которые соответствуют параметрам в операции задания значений (спецификации) для Activity. Элемент Activity, показанный ранее на рис. 1, содержит три узла Activity Parameter ("Параметр действия"), которые представляют элемент customerInfo:
- Customer
- purchaseOrder: PurchaseOrder
- invoice: Invoice
Примечание:
Параметры Activity должны обязательно совпадать с подписью параметров операции.
Преобразование UML-to-BPEL генерирует действие BPEL Receive с двумя выходными параметрами, которые проиллюстрированы в листинге 1.
Листинг 1. Действие BPEL Receive в процессе для элемента processPurchaseOrder
|
<bpws:receive createInstance="yes" name="processPurchaseOrder" operation="processPurchaseOrder" partnerLink="purchasingPurchasing" portType="ns2:Purchasing"> <wpc:output> <wpc:parameter name="customerInfo" variable="processpurchaseorder_customerInfo"/> <wpc:parameter name="purchaseOrder" variable= "processpurchaseorder_purchaseOrder"/> </wpc:output> </bpws:receive> |
Есть три раздела действий (Invoicing, Shipping и Scheduling) в действии Receive ("Получение"), которые представляют каждый порт в элементе Component. Они представляют свойства каждого раздела, поскольку они установлены на соответствующие им порты в компоненте. Алгоритм управления начинается с узла initialNode в действии Receive и соединяется с узлом forkNode. Три элемента controlFlow начинаются из узла forkNode, и каждый из них соединяется с отдельным элементом Action. Это указывает, что при достижении алгоритмом управления узла forkNode произойдут различные последовательности действий. Преобразование UML-to-BPEL генерирует действие BPEL Flow и три последовательности BPEL в алгоритме.
Алгоритм управления начинается с узла initialNode и соединяется с узлом forkNode. Три элемента controlFlow начинаются из узла forkNode, и каждый из них соединяется с элементом Action. Это указывает, что при достижении алгоритмом управления узла forkNode одновременно может выполняться несколько последовательностей действий. Преобразование UML-to-BPEL генерирует действие BPEL Flow и три последовательности BPEL в алгоритме.
Давайте изучим первый алгоритм управления, исходящий из узла forkNode. Алгоритм соединяется с элементом Action под названием initiatePriceCalculation ("Инициация расчета цены") (действие Call Operation, "Обработка звонка"), и операция UML для этого действия устанавливается следующим образом:
|
PurchaseOrderProcess::com::acme::credit: :Invoicing::initiatePriceCalculationOperation(customerInfo : Customer, purchaseOrder : PurchaseOrder) |
Следовательно, объект Action содержит три элемента inputPin ("входной контакт"). Самый правый элемент inputPin - это targetInputPin (имя контакта пустое, поскольку действие является частью раздела действий). Первый и второй элементы inputPin указывают, что для операции, связанной с элементом Action, есть два входных параметра. Имя контакта должно представлять объект данных. Этот объект может быть именем элемента UML Variable (переменная UML), UML Property (свойство UML) или UML Parameter (параметр UML), который должен существовать в элементе UML Activity или UML Component. В нашей модели параметрами в элементе Activity являются customerInfo ("Информация о клиенте") и purchaseOrder ("Заказ на покупку"). Преобразование UML-to-BPEL генерирует действие BPEL Invoke с двумя входными параметрами, как показано в листинге 2.
Листинг 2. Действие BPEL Invoke в процессе для initiatePriceCalculation
|
<bpws:invoke name="initiatePriceCalculation" operation="initiatePriceCalculation" partnerLink="invoicingInvoicingPartner" portType="ns3:Invoicing"> <wpc:input> <wpc:parameter name="customerInfo" variable="processpurchaseorder_customerInfo"/> <wpc:parameter name="purchaseOrder" variable="processpurchaseorder_purchaseOrder"/> </wpc:input> </bpws:invoke>
|
Алгоритм управления, исходящий из действия initiatePriceCalculation, соединяется с действием completePriceCalculation ("Полный расчет цены") (действие Call Operation) с помощью следующей установки для операции UML для элемента Action:
|
PurchaseOrderProcess::com::acme::credit::Invoicing::completePriceCalculation (shippingInfo : Manifest)
|
Элемент Action содержит два элемента inputPin (самый правый элемент inputPin - это targetInputPin, но его имя пустое, поскольку действие является частью раздела действий). Один элемент inputPin указывает, что для операции, связанной с элементом Action, есть один входной параметра. Имя элемента pin должно представлять объект данных. Этот объект может быть именем элемента UML Variable (переменная UML), UML Property (свойство UML) или UML Parameter (параметр UML), который должен существовать в элементе UML Activity или UML Component. В нашей модели shippingInfo ("Информация о поставке") - это свойство UML в элементе Component. Вы, возможно, заметили, что от действия requestShipping ("Запрос поставки") идет еще один входящий элемент управления. Он указывает, что действие completePriceCalculation должно быть выполнено перед завершением действия под названием requestShipping.
Преобразование UML-to-BPEL генерирует действие BPEL Invoke с входным параметров, целевую ссылку BPEL для действия requestShipping, а также ссылку, которая будет установлена в качестве исходной ссылки BPEL в действии Invoke для действия requestShipping, которое можно увидеть в листинге 3.
Листинг 3. Действие BPEL Invoke в процессе для completePriceCalculation
|
<bpws:invoke name="completePriceCalculation" operation="completePriceCalculation" partnerLink="invoicingInvoicingPartner" portType="ns3:Invoicing"> <wpc:input> <wpc:parameter name="shippingInfo" variable="shippingInfo"/> </wpc:input> <bpws:targets> <bpws:target linkName="processPurchaseOrderLink1"/> </bpws:targets> </bpws:invoke> |
Исходящий из действия completePriceCalculation алгоритм управления соединен с действием processInvoice ("Обработка счета") (действие Accept Call, "Принять звонок"). Триггеры, которые исходят из этого действия, содержат один элемент CallEvent, со следующей установкой для связанной с ним операции:
|
PurchaseOrderProcess::org::ordermanagement::InvoiceProcessing::processInvoice (invoice : Invoice)
|
Action содержит два элемента outputPins (самый правый элемент outputPin представляет свойство returnInforation для действия). Один элемент inputPin указывает, что для операции, связанной с действием, есть один входной параметр. Имя элемента pin должно представлять объект данных. Этот объект может быть именем элемента UML Variable (переменная UML), UML Property (свойство UML) или UML Parameter (параметр UML), который должен существовать в элементе UML Activity или UML Component. В нашем примере Invoice - это параметр в элементе Activity. Преобразование UML-to-BPEL генерирует действие BPEL Receive с выходным параметром.
Две других последовательности алгоритма управления из узла forkNode обрабатываются сходным образом. В конце генерируется действие BPEL Reply, поскольку операция Activity::specification содержит возвращаемый параметр. (В нашем примере операция спецификации элемента Activity - это PurchaseOrderProcess::org::ordermanagement::Purchasing::processPurchaseOrder.) Она показана в листинге 4.
Листинг 4. Действие BPEL Reply в процессе для элемента processPurchaseOrder
|
<bpws:reply name="processPurchaseOrder" operation= "processPurchaseOrder" partnerLink="purchasingPurchasing" portType= "ns2:Purchasing"> <wpc:input> <wpc:parameter name="result" variable="processpurchaseorder_result"/> </wpc:input> </bpws:reply> |
Листинг 5 демонстрирует полный файл BPEL, который генерируется преобразованием UML-to-BPEL для компонента orderProcessor.
Листинг 5. Полный список генерируемых процессов BPEL
|
<?xml version="1.0" encoding="UTF-8"?> <bpws:process xmlns:bpws=" http://schemas.xmlsoap.org/ws/2004/03/business-process/" xmlns:ns="http://org/ordermanagement/OrderProcessorArtifacts/" xmlns:ns0="http://org/crm/" xmlns:ns1="http://org/crm/domain/" xmlns:ns2="http://org/ordermanagement/Purchasing/" xmlns:ns3="http://com/acme/credit/Invoicing/" xmlns:ns4="http://org/ordermanagement/InvoiceProcessing/" xmlns:ns5="http://com/acme/shipping/Shipping/" xmlns:ns6="http://org/ordermanagement/ScheduleProcessing/" xmlns:ns7="http://com/acme/productions/Scheduling/" xmlns:wpc="http://www.ibm.com/xmlns/prod/websphere/business-process/6.0.0/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" expressionLanguage=" http://www.ibm.com/xmlns/prod/websphere/business-process/expression-lang/java/6.0.0/" name="OrderProcessor" suppressJoinFailure="yes" targetNamespace=" http://org/ordermanagement/OrderProcessor/"> <bpws:import importType=" http://schemas.xmlsoap.org/wsdl/" location="OrderProcessorArtifacts.wsdl" namespace=" http://org/ordermanagement/OrderProcessorArtifacts/"/> <bpws:import importType=" http://www.w3.org/2001/XMLSchema" location="../../../PurchaseOrderProcess/org/crm/PurchaseOrder.xsd" namespace="http://org/crm/"/> <bpws:import importType=" http://www.w3.org/2001/XMLSchema" location="../../../PurchaseOrderProcess/org/crm/Invoice.xsd" namespace="http://org/crm/"/> <bpws:import importType=" http://www.w3.org/2001/XMLSchema" location="../../../PurchaseOrderProcess/org/crm/Manifest.xsd" namespace="http://org/crm/"/> <bpws:import importType=" http://www.w3.org/2001/XMLSchema" location=" ../../../PurchaseOrderProcess/org/crm/domain/Customer.xsd" namespace="http://org/crm/domain/"/> <bpws:import importType=" http://www.w3.org/2001/XMLSchema" location="../../../PurchaseOrderProcess/org/crm/Schedule.xsd" namespace="http://org/crm/"/> <bpws:partnerLinks> <bpws:partnerLink myRole="PurchasingRole" name="purchasingPurchasing" partnerLinkType="ns:PurchasingPLT"/> <bpws:partnerLink name=" invoicingInvoicingPartner" partnerLinkType="ns:InvoicingPLT" partnerRole="InvoicingRole"/> <bpws:partnerLink myRole="InvoiceProcessingRole" name="invoicingInvoiceProcessing" partnerLinkType="ns:InvoiceProcessingPLT"/> <bpws:partnerLink name="schedulingSchedulingPartner" partnerLinkType="ns:SchedulingPLT" partnerRole="SchedulingRole"/> <bpws:partnerLink name="shippingShippingPartner" partnerLinkType="ns:ShippingPLT" partnerRole="ShippingRole"/> <bpws:partnerLink myRole="ScheduleProcessingRole" name="shippingScheduleProcessing" partnerLinkType="ns:ScheduleProcessingPLT"/> </bpws:partnerLinks> <bpws:variables> <bpws:variable name="id" type="xsd:string"/> <bpws:variable name="shippingInfo" type="ns0:Manifest"/> <bpws:variable name="schedule" type="ns0:Schedule"/> <bpws:variable name=" processpurchaseorder_customerInfo" type="ns1:Customer"/> <bpws:variable name=" processpurchaseorder_purchaseOrder" type="ns0:PurchaseOrder"/> <bpws:variable name=" processpurchaseorder_result" type="ns0:Invoice"/> </bpws:variables> <bpws:sequence name="Sequence"> <bpws:receive createInstance="yes" name="processPurchaseOrder" operation="processPurchaseOrder" partnerLink="purchasingPurchasing" portType="ns2:Purchasing"> <wpc:output> <wpc:parameter name="customerInfo" variable="processpurchaseorder_customerInfo"/> <wpc:parameter name="purchaseOrder" variable="processpurchaseorder_purchaseOrder"/> </wpc:output> </bpws:receive> <bpws:scope name=" processPurchaseOrder"> <bpws:flow name=" processPurchaseOrderFlow"> <bpws:links> <bpws:link name=" processPurchaseOrderLink1"/> <bpws:link name=" processPurchaseOrderLink2"/> </bpws:links> <bpws:sequence name="Sequence3"> <bpws:invoke name=" initiatePriceCalculation" operation=" initiatePriceCalculation" partnerLink=" invoicingInvoicingPartner" portType="ns3:Invoicing"> <wpc:input> <wpc:parameter name="customerInfo" variable="processpurchaseorder_customerInfo"/> <wpc:parameter name="purchaseOrder" variable="processpurchaseorder_purchaseOrder"/> </wpc:input> </bpws:invoke> <bpws:invoke name="completePriceCalculation" operation="completePriceCalculation" partnerLink="invoicingInvoicingPartner" portType="ns3:Invoicing"> <wpc:input> <wpc:parameter name="shippingInfo" variable="shippingInfo"/> </wpc:input> <bpws:targets> <bpws:target linkName=" processPurchaseOrderLink1"/> </bpws:targets> </bpws:invoke> <bpws:receive name="processInvoice" operation="processInvoice" partnerLink="invoicingInvoiceProcessing" portType="ns4:InvoiceProcessing"> <wpc:output> <wpc:parameter name="invoice" variable="processpurchaseorder_result"/> </wpc:output> </bpws:receive> </bpws:sequence> <bpws:sequence name="Sequence4"> <bpws:assign name="Assign1"> <bpws:copy> <bpws:from variable="processpurchaseorder_purchaseOrder"> <bpws:query queryLanguage=" http://www.w3.org/TR/1999/REC-xpath-19991116"><! [CDATA[/oid]]></bpws:query> </bpws:from> <bpws:to variable=" processpurchaseorder_customerInfo"> <bpws:query queryLanguage=" http://www.w3.org/TR/1999/REC-xpath-19991116"><! [CDATA[/firstname]]></bpws:query> </bpws:to></bpws:copy> </bpws:assign><bpws:invoke name="requestShipping" operation="requestShipping" partnerLink="shippingShippingPartner" portType="ns5:Shipping"> <wpc:input> <wpc:parameter name="customerInfo" variable="processpurchaseorder_customerInfo"/> <wpc:parameter name="shippingInfo" variable="shippingInfo"/> </wpc:input><bpws:sources> <bpws:source linkName="processPurchaseOrderLink1"/> </bpws:sources> </bpws:invoke> <bpws:receive name="processSchedule" operation="processSchedule" partnerLink="shippingScheduleProcessing" portType="ns6:ScheduleProcessing"> <wpc:output> <wpc:parameter name="schedule" variable="schedule"/> </wpc:output> <bpws:sources> <bpws:source linkName=" processPurchaseOrderLink2"/> </bpws:sources> </bpws:receive> </bpws:sequence> <bpws:sequence name="Sequence5"> <bpws:invoke name=" requestProductionScheduling" operation=" requestProductionScheduling" partnerLink=" schedulingSchedulingPartner" portType="ns7:Scheduling"> <wpc:input> <wpc:parameter name="customerInfo" variable="processpurchaseorder_customerInfo"/> <wpc:parameter name="purchaseOrder" variable="processpurchaseorder_purchaseOrder"/> </wpc:input> </bpws:invoke> <bpws:invoke name="sendShippingSchedule" operation="sendShippingSchedule" partnerLink="schedulingSchedulingPartner" portType="ns7:Scheduling"> <wpc:input> <wpc:parameter name="schedule" variable="schedule"/> </wpc:input> <bpws:targets> <bpws:target linkName=" processPurchaseOrderLink2"/> </bpws:targets> </bpws:invoke> </bpws:sequence> </bpws:flow> </bpws:scope> <bpws:reply name="processPurchaseOrder" operation="processPurchaseOrder" partnerLink="purchasingPurchasing" portType="ns2:Purchasing"> <wpc:input> <wpc:parameter name="result" variable="processpurchaseorder_result"/> </wpc:input> </bpws:reply> </bpws:sequence> </bpws:process> |
Интерпретация элементов UML преобразованием UML-to-BPEL
Преобразование UML-to-BPEL использует определенную информацию из модели UML для генерации артефактов BPEL. Некорректная или неполная модель может генерировать ошибки или неправильные артефакты BPEL (или и то, и другое). Вы захотите этого избежать, конечно. Последующие таблицы призваны помочь вам понять ожидаемые результаты, которые последуют в результате различных действий преобразования.
В табл. 1 перечислены элементы UML, которые поддерживает преобразование, и соответствующие конструкции или действия BPEL, которые это преобразование создает.
Таблица 1. Элементы UML и результаты BPEL
|
Элемент UML |
Результат преобразования |
|
Component |
Преобразование создает процесс BPEL с тем же именем, что и у компонента, если компонент содержит одно или более действий. Компонент предоставляет контекст для всех его собственных поведений и для переменных в соответствующем процессе BPEL. Если компонент содержит пустое действие, то преобразование создает пустое действие BPEL Scope для каждой операции в предоставленных интерфейсах. Пространство имен для процесса BPEL и связанного с ним файла артефактов WSDL включает в себя элемент для компонента и содержащих его пакетов. |
|
Component::ownedAttribute |
Если тип, который указан в свойстве Type атрибута, не является компонентом с портами, то преобразование создает переменную BPEL в соответствующем процессе BPEL. |
|
AcceptCallAction |
Генерируется действие BPEL Receive. Преобразование проверяет список триггеров, связанных с действием, чтобы определить, какая операция связана с типом CallEvent, и чтобы определить, какая операция соответствует операции BPEL. Когда имя "контакта" (pin) не пустое, и это имя должно соответствовать имени порта, преобразование генерирует партнера с помощью имени "выходного контакта" (output pin), который связан со свойством ReturnInformation действия. В противном случае преобразование использует свойство ActivityPartition::represents, где значение свойства ActivityPartition::represents должно быть либо портом, либо типом порта. Контейнер операции должен быть предоставленным интерфейсом в одном из портов, через которые он принимает вызов. Количество выходных контактов в действии должно соответствовать количеству выходных параметров операции. Действие должно также содержать дополнительный выходной контакт, который представляет свойство Return Information действия. |
|
AcceptEventAction без входных соединений AcceptEventAction с одним или более входным соединением AcceptEventAction с триггером, чье событие - это SignalEvent |
Алгоритм BPEL генерируется, когда есть одно или более событий SignalEvents в триггерах AcceptEventAction::triggers. BPEL не поддерживает множественные входящие алгоритмы управления (ControlFlow) и множественные входящие потоки объектов на один элемент InputPin действия. Генерируется действие BPEL Receive. Эта операция происходит в результате получения (reception), что указывает на получение сигнала. Примечание: Действие AcceptEventAction должно находиться в разделе ActivityPartition, который представляет порт (или тип порта), через который оно принимает событие. Предоставляемый интерфейс для порта должен содержать получение для каждого сигнала. Действие AcceptEventAction должно иметь элемент OutputPin для каждого сигнала, который связан с событиями SignalEvents в триггерах AcceptEventAction::triggers. Тип элемента pin должен соответствовать типу сигнала. |
|
AcceptEventAction с триггером, чье событие должно быть событием TimeEvent. Выражение времени связано со свойством TimeEvent::when. |
Генерируется действие BPEL wait. Атрибут For или Until действия BPEL wait устанавливается на базе выражения для времени. Чтобы указать значение для атрибута Until, выражение должно быть в следующем формате: год, месяц, дата, час, минута, секунда. Чтобы указать значение для атрибута For, выражение должно быть в следующем формате: количество лет, месяцев, дней, часов, минут и секунд. Примечание: Вы не можете указать несколько значений времени для событий. |
|
Действие, которое является собственным поведением компонента и методом работы, предоставляемым этим компонентом. |
Преобразование создает действие BPEL Scope на самом верхнем уровне процесса BPEL для компонента. |
|
Activity::Specification |
Если компонент содержит только одно действие, то преобразование создает действие верхнего уровня BPEL Receive для операции, которая связана со спецификацией. Если компонент содержит несколько действий, то преобразование создает действие BPEL Pick и тип события onMessage для каждой операции, которая связана с каждой спецификацией Activity::Specification. Если операция спецификации содержит выходной (Out) или возвращаемый (Return) параметр, то преобразование создает действие BPEL Reply. |
|
Activity::ownedParameter:Parameter |
Преобразование создает переменную процесса BPEL в том процессе BPEL, который соответствует компоненту. Имена переменных должны создаваться с учетом имени действия. Это обеспечит отсутствие конфликтов с параметрами других действий в компоненте. Имена параметров и типы операций, которые связаны со спецификацией действия, должны иметь параметры действия, которые совпадают и по имени, и по типу. |
|
Activity::ownedAttribute:Property |
Преобразование создает переменную BPEL в элементе Scope верхнего уровня для действия в процессе. |
|
Activity::variable:Variable |
Преобразование создает переменную BPEL в элементе Scope верхнего уровня для действия в процессе. |
|
ActivityFinalNode |
Преобразование создает действие BPEL Terminate. |
|
ActivityPartition::represents |
Значение свойства Represents должно быть портом (или типом порта). Преобразование создает ссылку на партнера BPEL для каждого предоставленного или необходимого интерфейса в порте. Это позволяет преобразованию идентифицировать правильного партнера BPEL для операции, которая связана с действиями в разделе. |
|
CallOperationAction |
Генерируется действие BPEL Invoke. Когда имя "контакта" (pin) не пустое, и это имя должно соответствовать имени порта, преобразование генерирует партнера с помощью имени целевого "входного контакта" (input pin). В противном случае преобразование использует свойство ActivityPartition::represents, а значение свойства ActivityPartition::represents должно быть либо портом, либо типом порта. Контейнер операции должен быть необходимым интерфейсом в одном из портов, через которые он выполняет операцию. Количество входных контактов (input pin) в действии должно соответствовать количеству входных ([in]) параметров операции. Действие должно также содержать дополнительный входной контакт, который представляет целевой входной контакт действия. Количество выходных контактов (output pin) в действии должно соответствовать количеству выходных ([out]) параметров операции. |
|
InitialNode |
Преобразование использует этот элемент для указания на начало действия BPEL; оно не создает никаких артефактов BPEL для этого узла. |
|
OpaqueAction |
Преобразование создает действие BPEL assign, когда имя операции использует выражение, подобное следующему: lvalue:= rvalue. Здесь lvalue устанавливает BPEL на тип variant, а rvalue устанавливает BPEL на тип, отличный от variant. Для нескольких назначений можно в качестве разделителя использовать точку с запятой (;): aVar:=bVar ; cVar:=dVar. Преобразование создает фрагмент когда BPEL Java™, когда свойство language ("язык") действия имеет значение Java. При этом в фрагмент кода помещается значение свойства body, которое связано с действием. Преобразование создает пустую задачу BPEL для выполнения человеком, когда свойство language действия имеет значение HTML или JSP (Java™Server Page). |
|
SendSignalAction |
Генерируется действие BPEL Invoke. Операция BPEL invoke соответствует получению свойства SendSignalAction::signal. Когда имя "контакта" (pin) не пустое, преобразование генерирует партнера с помощью имени целевого "входного контакта" (input pin). В противном случае преобразование использует свойство ActivityPartition::represents. Контейнер операции должен быть необходимым интерфейсом в одном из портов, через которые он посылает события. Имя целевого контакта должно соответствовать имени порта, когда имя контакта - не пустое. Либо значение свойства ActivityPartition::represents должно быть либо портом, либо типом порта. |
Преобразование соединений UML Activity
В табл. 2 перечислены типы соединений Activity, которые поддерживает преобразование, и соответствующие последовательности BPEL и ссылки, которые это преобразование создает.
Таблица 2. Типы соединений UML Activity и соответствующие последовательности и ссылки BPEL
|
Соединение UML Activity |
Результат преобразования |
|
ControlFlow |
Преобразование создает последовательность BPEL и ссылки для управления параллельным выполнением. |
|
ObjectFlow |
Преобразование создает последовательность BPEL и ссылки для управления параллельным выполнением. Если необходимо, преобразование генерирует переменные на базе имени потока объекта. Сгенерированное имя используется в том случае, если имя потока объекта пустое. |
Преобразование узлов управления или решений
В табл. 3 перечислены узлы управления или решений, которые поддерживает преобразование, и соответствующие выходные элементы BPEL, которые это преобразование создает.
Таблица 3. Узлы управления или решений UML и выходные элементы BPEL
|
Узел управления или решения |
Результат преобразования |
|
DecisionNode |
Преобразование создает действие BPEL Switch и ветвь BPEL Case для каждого исходящего из этого узла потока. В каждой ветви BPEL Case создается последовательность BPEL. Она содержит действие BPEL, которое генерируется из цели каждого исходящего потока. Каждая защита каждого исходящего потока устанавливает условие BPEL для ветви BPEL Case. Преобразование создает ветвь BPEL Otherwise для исходящего потока, когда значение защиты равно Else, а свойство language - пустое. |
|
ForkNode |
Преобразование генерирует код, который указывает начало действия BPEL flow: <flow name="ForkNode.name"> В действии <flow> преобразование создает вложенное действие BPEL Sequence для каждого потока, который существует в узле ForkNode. |
|
JoinNode |
Преобразование генерирует код, который указывает конец действия BPEL flow: </flow> |
|
MergeNode |
Преобразование создает связи BPEL между исходными узлами каждого входящего потока к узлу слияния и целевым узлом исходящего из узла слияния потока. |
В табл. 4 перечислены узлы объектов, которые поддерживает преобразование, и соответствующие действия BPEL, которые это преобразование создает.
Таблица 4. Узлы объектов UML и соответствующие действия BPEL
|
Узел управления или объекта |
Результат преобразования |
|
ActivityParameterNode |
Преобразование не создает соответствующие артефакты BPEL. Преобразование проверяет узлы объектов ActivityParameterNode, чтобы определить порядок последовательности, только если потоки объектов соединяются с узлом объекта ActivityParameterNode. Узел объекта ActivityParameterNode должен иметь соответствующие параметры действия. |
|
LoopNode |
Преобразование создает действие BPEL While для каждого узла LoopNode в действии UML, которое является собственным поведением компонента UML. |
|
LoopNode::decider |
Преобразование создает условие BPEL для действия BPEL while с помощью переменной BPEL, которая связана с выходным контактом (output pin). Связанный с ней выходной контакт должен иметь тип UMLPrimitiveTypes::Boolean. |
|
Элементы UML внутри узла LoopNode |
В действии BPEL while преобразование создает соответствующие действия BPEL для тех элементов UML, которые поддерживаются преобразованием UML-to-BPEL. |
|
InputPin |
Преобразование проверяет элементы InputPin, когда владелец входного контакта (input pin) представляет собой экземпляр действия AcceptCallAction, CallOperationAction или OpaqueAction. Количество входных контактов должно соответствовать входным ([in]) параметрам действия, связанным с тем действием, которое владеет входным контактом. Дополнительный входной контакт должен представлять целевой (<<target>>) входной контакт только тогда, когда действие является экземпляром действия CallOperationAction. Если входной контакт не связан с действием посредством соединения потока объекта, то имя контакта должно соответствовать параметру действия, переменной или атрибуту в действии или компоненте, который является владельцем действия. |
|
OutputPin |
Преобразование проверяет элементы OutputPin, когда владелец выходного контакта (output pin) представляет собой экземпляр действия AcceptCallAction, CallOperationAction или OpaqueAction. Когда действие является экземпляром действия CallOperationAction или OpaqueAction, количество выходных контактов должно соответствовать выходным ([out]) параметрам действия, связанным с тем действием, которое владеет входным контактом. Когда действие является экземпляром AcceptCallAction, дополнительный выходной контакт должен представлять свойство Return Information для действия, которое владеет контактом . Если выходной контакт не связан с действием посредством соединения потока объекта, то контакта должен иметь правильное имя, которое соответствует параметру действия, переменной или атрибуту в действии или компоненте, который является владельцем действия. Если выходной контакт не имеет никаких входящих или исходящих потоков объектов, преобразование использует соответствующую переменную BPEL, чтобы создать выходной параметр BPEL для соответствующей операции. Эта операция связана с действием, которое владеет контактом. |
В табл. 5 перечислены узлы циклов, которые поддерживает преобразование, и соответствующие действия BPEL, которые это преобразование создает.
Таблица 5. Элементы узлов циклов UML и генерируемые действия BPEL
|
Узел цикла или элемент узла цикла |
Результат преобразования |
|
LoopNode |
Преобразование создает действие BPEL While для каждого узла LoopNode в действии UML, которое является собственным поведением компонента UML. |
|
LoopNode::decider |
Преобразование создает условие BPEL для действия BPEL While с помощью переменной BPEL, которая связана с выходным контактом (output pin). Связанный с ней выходной контакт должен иметь тип UMLPrimitiveTypes::Boolean. |
|
Элементы UML внутри узла LoopNode |
В действии BPEL While преобразование создает соответствующие действия BPEL для тех элементов UML, которые поддерживаются преобразованием UML-to-BPEL. |
Где получить более подробную информацию
Теперь, когда вы поняли основы преобразования UML-to-BPEL и некоторые подробности того, как моделировать реализацию процесса BPEL в UML, вы, возможно, захотите прочитать некоторые статьи по этой тематике. Они перечислены в разделе Resources ("Ресурсы"), где можно найти готовые сценарии использования технологий.