集成 BPMN 与 SoaML: 第 2 部分. 实现集成的一些概念

简介

本系列的第一篇文章 集成 BPMN 与 SoaML，第 1 部分. 动机和方法 介绍了集成这些标准的价值主张，并演示了其中一种集成方法。集成标准让建模人员可以：

• 使用其免费功能来建模行为和结构，以便解决更广泛的问题
• 支持更多利益相关者的视图
• 提供一种手段来集成流程和以服务为中心的开发方法，以便利用其独特的功能

第 2 部分探讨了可用于指导这些标准建模语言集成的一些概念。这些概念包括：每种语言如何实现封装、合约（或接口）、结构和行为。这些概念为各标准之间的共性/差异分析提供了一个上下文，以便指导实际的集成。该分析从其他语言的角度来解释概念，以澄清各种概念在每个建模语言中的含义。

回页首

回顾第 1 部分：动机和方法

BPMN 与 SoaML 的集成必须通过将服务架构与定义、实现或使用它们的流程分开，为服务的构造和使用提供支持。借助此集成，建模人员能够：

• 识别来自 BPMN 流程的 SoaML 功能（或候选服务）
• 使用 SoaML 识别、指定和实现服务
• 使用 BPMN 定义一种方法来实现参与者所提供的 SoaML ServiceInterface 的操作
• 使用 BPMN 流程中的 ServiceTask，可以调用由 SoaML ServiceInterface 定义并由 SoaML 中的参与者提供的服务
• 在 BPMN 与 SoaML 之间共享信息规范（类、数据类型和消息）
• 使用 SoaML 定义 BPMN 中可响应业务事件数据对象的生命周期

第 1 部分还介绍了 BPMN 和 SoaML 的不同集成方法，包括无集成、模型交换和模型集成。模型集成是首选方法，因为它更侧重于如何可以同时使用这些建模语言并让它们互为补充，以便提供更好的价值主张。每个建模语言都可以用在最能发挥其作用的地方，并且可以在它们之间链接和共享信息。例如，如果需要的话，建模语言集成允许厂商创建一个以标准方式同时使用两种语言的工具。模型桥接类似于元模型集成，但是使用独立的中介/网桥元模型来实现的，这导致 BPMN 和 SoaML 之间的耦合较少，并允许分别开发和使用它们。

回页首

引导集成的一些概念

为了理解如何集成 BPMN 和 SoaML，必须理解每个规范如何满足一组核心概念。这有助于理解各个规范的优点和弱点，以及如何一起利用各种优点，同时避免弱点。

核心概念是：

封装

对封装元素或组件的一种描述，包括它与其他原型组件的潜在交互。

合约

组件之间的潜在交互的封装和规范，以及组件应遵守的协议

结构

封装组件的内部结构，包括其他组件的组装

行为

组件的内部行为实现或编排的表示，包括组件如何根据协商一致的合约来使用和/或提供服务

封装与合约

封装与合约最好一起解决，因为封装将内容分隔在不同的逻辑单元中，而合约则指定这些逻辑单元之间的连接。封装与合约主要处理问题分离和共性/变异性分析 - 分离出不同的东西和变化的东西，使他们能够被独立处理。封装与合约质量的措施往往涉及黏合和耦合措施。高度黏合与最小耦合往往带来更好的重用，以及更有弹性、更容易设计、实现、测试和维护的解决方案。

封装定义容器单元和对该容器单元的接口。合约指定和封装在被封装单元之间的交互。术语 “组件” 通常用于描述封装的单元。描述组件之间交互的合约涉及消息交换模式，其中包括：

• 数据或信息交换的规范（消息内容）
• 数据分组被交换到黏合的逻辑单元（消息）
• 制约这些消息的顺序的有效序列、协议或编排（消息交换模式）
• 可接受的服务质量和源于交换的价值

SoaML

SoaML 中的封装单元是 参与者 。参与者是 UML 组件的延伸，它定义提供和/或使用服务的组件，与如何实现服务、其他参与者可能使用服务的方式或者如何使用被请求的服务无关。

参与者用服务端口代表他们提供的服务，并用请求端口代表他们使用的来自其他参与者的服务。

图 1 显示一个参与者的典型 “黑盒子” 视图，它与其他任何参与者无关。关于 processPurchaseOrder 方法的信息，请参阅本文的行为部分。

图 1. 参与者作为 SoaML 中的封装单元

如图 2 所示的 ServiceInterface 用于定义服务端口或请求端口的类型，并指定消息交换模式的详细信息。

• 消息交换 的定义包括，所提供的和所需要的接口的操作及接收，以及它们的输入和输出参数。
• 消息分组 由 ServiceInterface 本身定义。ServiceInterfaces 用于类型服务和请求端口。
• 消息编排 由 ServiceInterface 所拥有的行为定义。所拥有的行为指定了用于使用和提供服务操作的协议。SoaML 还支持使用 ServiceContract 作为一种用来指定涉及潜在的众多参与者的信息编排的更灵活的手段。

图 2. SoaML 中的 ServiceInteface

SoaML（和 UML）支持面向消息和面向远程过程调用（RPC）的服务交互。面向消息的交互是通过所提供的和所需要的接口中的接收（Receptions）完成的，它定义建模所交换消息内容的信号（Signals）。活动使用 SendEventAction 和 AcceptEventAction 来实际发送和接收事件。在接口中的操作以及 UML 活动 中的 CallOperationAction 和 AcceptCallAction 都支持面向 RPC 的交互。这些实际上是在 UML 中被规范化的，并通过 CallEvent 运行语义，CallEvent 是由一个 CallOperationAction 发送的。

SoaML ServicesArchitecture 在较高的层次描述了一组参与者之间的关系、它们扮演的角色以及根据商定的 ServiceContracts 交互，以便获得一些期望的结果。请参阅 developerWorks文章 "使用 SoaML 服务架构" 了解更多详细信息。

Manufacturer ServicesArchitecture

如图 3 所示，Manufacturer ServicesArchitect 显示了订单处理人、发票、生产和运输人组件如何根据 ServiceContracts 中捕获的协议进行交互，以便处理客户订单，生产产品，并装运它们。Process Purchase Order Activity 描述协作活动的顺序，并说明如何将服务操作用于实现所需的结果。

图 3. 在 SoaML 中的 ServicesArchitecture 和 ServiceContract

BPMN

在 BPMN 中，封装的单元也是参与者。通过一个池（Pool）表示它。一个 BPMN Collaboration 图形描述了参与者之间交换的消息。

BPMN 使用了一些概念来描述参与者和池之间的交互，这些概念包括编排、协作、会话和筹划。

编排

活动的顺序，活动表示消息的发送或接收、服务操作的使用，或由参与者执行的任务

协作

参与者之间交换的消息的规范

会话

这些消息被分组到逻辑单元，用于在运行时关联参与者的特定实例之间的交互

筹划

参与者之间的有效消息序列的规范

服务接口

由一个参与者提供并被另一个参与者使用的服务任务的规范。

图 4 是一个协作图。它用于提供在参与者之间交换的消息的未分组视图。

图 4. BPMN 协作

BPMN 也支持服务任务。服务任务可以指服务接口的操作。这使得 BPMN 还可以支持基于消息或基于 RPC 的交互方式。服务任务的意思是，调用由服务接口定义的操作。这和 UML 活动中的 CallOperationAction 是相同的。BPMN 没有指定这些服务接口如何与消息、会话或筹划相关联。相反，BPMN 将它们视作用于建模类似概念的不同方法。BPMN 也没有区分参与者池通过所提供和所使用的服务接口进行的交互有何不同。该操作是通过将信息绑定到服务本身来完成。

在 BPMN 中，使用会话（Conversation）对消息进行分组。会话还提供了指定关联信息的能力，这些信息可用于在某些运行环境中区分参与者的不同实例。BPMN 并不对类型和实例加以区分。它将参与者池视作一个原型实例。如果在其他协作中重用参与者，这有一定的影响。例如，参与者被重用的上下文是否是包含性还是排他性的，这是不明确的。在实践中，这不是那么重要，因为建模人员可以假定参与者可能涉及 BPMN 模型中包含的部分或全部交互。图 5 显示了在 BPMN 中的会话。该模型并不一定指定哪些参与者必须参与任何特定的环境，并且必须留给其他文档。

图 5. BPMN 会话

会话中包含的消息没有显示在会话图上。不过，可以通过其他机制（如属性视图）将它们列出在模型中。

筹划图显示了 BPMN 中的消息编排。BPMN 筹划显示了参与者之间交换的信息的有效序列。图 6 显示了如何对作为会话一部分的消息模式进行排序。

图 6. BPMN 筹划

对一组相关消息进行分组的会话可以有一个相关的筹划，用于指定消息序列或协议。

BPMN 目前还没有用符号显示信息交换、在会话中的消息分组、在同一个图中使用筹划的信息协议。该信息在 BPMN 模型中可用，并且可以通过工具支持的属性和相关图表之间的导航来显示。

BPMN 筹划也可以显示，在参与者协作实现一些期望的结果时，所有参与者之间的消息的整体排序。

图 6 显示了整个采购订单流程的筹划，而不是参与某特定会话的参与者之间的特定交互的筹划。这种结合的筹划可以在建模流程的早期进行开发，以识别关键参与者以及它们如何交互。它的作用与 SoaML ServicesArchitecture 类似，显示参与者之间根据其商定的服务合约进行的预期交互，以及实现期望结果所需的总体活动。

图 7. 使用筹划来描述架构

总之，在 BPMN 中的消息模式被建模为：

• 消息交换 由协作图定义，协作图显示代表参与者的池之间的消息
• 消息分组 由会话图定义，会话图对协作图中显示的消息进行分组，以便关联在执行环境中特定参与者实例之间的交互
• 消息筹划 由筹划图定义，筹划图显示参与会话的参与者之间的消息的顺序

结构

结构定义一个系统如何从部件组装而成。它描述如何可以根据定义的合约，从其他连接的封装组件构造一个封装组件。结构定义如何组装和连接部件，使得它们之间的交互可以发生。结构可以是静态的，组装为有意设计的结果。结构也可以是动态的，在运行时的某些环境中发现、组装和拆卸，并为实现某种目的而被驱动。

结构是在类级别或实例级别定义的。对类级别，结构被定义为一组相关的元素的描述。对于实例级别，它被定义为代表某些已定义类的实例的部件之间的连接。这些定义是一些建模混乱的根源。在过去，UML 1.x 没有在元模型中明确区分类型和实例。所以建模人员会经常使用类图来指定一个上下文。图上的类和关联识别在该上下文中互连部件的结构。这是有问题的，因为示意图是视图，并不是模型，传达的是暗示的语义，而不是明确的语义。它对重用也很有意义。由于部件之间的连接是在类级别用关联定义的，一个类的所有实例都必须包括来自模型语义的所有示意图的所有关联。这限制了将类重用于其他目的，而不会牵扯到未使用的关联的能力。

UML 2 引入了一个 StructuredClassifier，用它来明确定义作为类型化元素的互连部件的概念，从而解决了这个问题。但是，使用类图来表示原型实例，并使用依赖关系 “线” 在类级别上显示部件的组装，这种实践仍然存在，而且 UML 2 可以直接支持该实践。本文的其余部分会试着准确描述关于类型和在某特定用途的组装结构中使用的该类型的实例之间的区别。

SoaML

在 SoaML 中的结构被建模为参与者的内部结构。参与者的部件是类型化元素，代表对其他参与者的实例的引用。部件是互连的，或通过 ServiceChannels 连接在一起。ServiceChannels 通过与 ServicesArchitecture 一致的（可选）方式连接部件的服务和请求端口。

在图 8 中，Manufacturer Participant 有一个内部结构，其中包含由服务渠道连接的 orderProcessor、invoice、productions 和 shipper 部件。服务渠道连接所提供和所使用的服务。它们还提供了一条通道，服务请求可以流过它。

SoaML Participant 可以利用它的内部结构作为提供服务和使用服务的手段。在图 8 中，Manufacturer participant 使用了代理连接器将服务委托给它的一个部件，以这种方式提供 Purchasing 服务。

图 8 中的架构 CollaborationUse 描绘了一个 Manufacturer Architecture 的实例，这曾在封装与合约部分中介绍过。角色绑定指示了 Manufacture 参与者如何遵守该服务架构。每一个部件都必须与它在服务架构中所绑定的角色的类型兼容。这在模型中提供了设计和实现之间的可追溯性。

可以利用的类图和依赖关系线来显示类似的信息。依赖关系线将位于参与者类的服务和请求端口之间。该关系线表示了服务的设计意图交汇，但它不是首选方法，因此本文不再进一步详细描述它。

图 8. 服务组装

BPMN

BPMN 并不对类型和实例加以区分。BPMN 定义了流程组件及其实现。这些流程组件之间的关系是使用会话建模的，可通过协作与筹划对它们进行阐述。会话可以包括在运行时使用的关联信息，以便在可能长期运行的流程中区分参与者的不同实例。该关联信息不可用于在示意图中定义类型化元素。

图 9 中的会话图为处理订单所需的参与者的组装提供了上下文。每个参与者池代表一个可能存在于实际运行流程的某运行时环境中的原型实例。

图 9. 使用 BPMN 会话的流程组装

限制的示例

图 9 中的 Scheduler 参与者提供了 Order Processor 参与者所使用的 Schedule 功能，如连接它们的会话所示。例如，您还可以重用 Scheduler，在一所大学中为学生安排课程。这种用途可显示在另一个会话图中。这是什么意思？这是否意味着所有 Scheduler 都必须连接到一个 Order Processor 和一个 University Class 才能正常工作？当然不是。但是，一个 Scheduler 可能需要来自其他参与者的服务才可以正常工作。在 Scheduler 的所有用途中都需要这些相连的参与者。BPMN 模型不能区分这两种情况，因为 BPMN 并不对类型和实例加以区分。

在实践中，这不是什么个大问题。您可以为 Scheduler 参与者创建不同的示意图，或分开 BPMN 模型。这些指示了它在特定上下文中需要哪些会话和筹划才能正常工作。您可以创建其他 BPMN 模型，针对不同目的显示 Scheduler 的不同用法。建模人员通过不同的模式及其上下文来区分这些不同的用法，此外，对于所有实例需要什么和在特定上下文中需要什么之间的区别，并不存在问题。

这是 BPMN 和 SoaML 的功能没有重叠并且 SoaML 提供了免费功能的情况。BPMN 可以在会话图中描述原型实例，而 SoaML 可以在参与者的内部结构中定义这些实例的具体组装。因此，SoaML 和 BPMN 也可以结合起来，类似于 W3C Service Component Architecture (SCA) 合成物与 Business Process Execution Language (BPEL) 合作伙伴引用之间的关系。

行为

UML 和 BPMN 可以描述多种用途的行为，这些行为包括：

• 阐述需求
• 对活动排序，以便实现某个结果
• 描述一个实体如何随着时间的推移而改变其状态
• 描述实际、预期或期望的活动序列
• 实现和使用服务

行为被进一步分类为执行行为（由对象本身执行的活动）和自发行为（因一个或多个参与对象的交互所产生的活动序列）。

可以从不同的视图查看行为。公共流程代表从外面可以观察到的行为。内部流程代表那些实现和使用服务的行为。内部流程往往是隐藏的，以避免暴露私有的、专有的或竞争性的信息。

SoaML

UML 和 SoaML 有许多不同类型的行为，这些行为包括：

• 活动
• 交互
• 状态机
• 不透明的行为（例如，在某些语言中的代码，包括 UML Action Language）

这些不同的方法一般在语义上是等效的，并用建模人员和利益相关者可能会觉得方便的不同符号代表。对于 BPMN 集成，本文的重点是 UML 活动模型。

图 10 显示了一个典型的 UML 活动，它是参与者拥有的，并且是用于该参与者所提供操作的方法。在封装与合约一节中显示，OrderProcessor 参与者拥有一个 processPurchaseOrder 行为，它被忽略，以便隐藏不必要的详细信息。图 10 中详细显示了该行为。

图 10. UML 活动在 SoaML 中实现和使用服务

在 UML 中的 ActivityPartition 可以代表任何东西，就像在 BPMN 中的通道那样。不过，UML2 定义了一些具有特定语义的特殊活动分区。所显示的分区是 “部件” 分区，因为它们代表了所属分类器的端口。这意味着，在分区中的 CallOperationActions 必须将自己的目标 “ Information ”（即 InputPin）设置为分区所引用的部件。在本例中，那是参与者的请求端口。该图中省略了目标输入引脚的详细信息，因为在活动分区中更容易显示这些信息。

在活动分区中的 CallOperationActions 调用了由其他参与者提供的服务操作。这些操作最终将通过服务渠道（一个 UML 连接器）连接到请求端口。这些被调用的操作是在端口所需的接口中指定的，说明活动可能会通过该端口调用哪些操作。

在长时间运行的双向会话中，活动可能必须响应回调函数，或者响应那些必须由使用该服务的参与者提供的服务接口定义的操作。在图 10 中，Invoicing 服务提供了计算发票的操作，但需要此服务的所有用户实际处理发票。这是在发票分区使用 AcceptCallAction 进行建模的。这个动作的目标输入引脚也是发票端口。当参与者提供 Invoicing 服务，然后回调订单处理器，以便处理该发票的时候，这个操作将被执行。

UML 活动还允许输入引脚和其他动作在活动中引用活动参数节点及任意数据存储。例如，在 processSchedule AcceptCallAction 的输入引脚上引用 schedule 数据存储。

BPMN

BPMN 支持许多不同的流程建模功能，可以使用这些功能来支持不同的利益相关者理解和推理流程的需求，并支持不同的建模人员捕获和阐述流程细节的需求。这些不同的 BPMN 功能的更加面向服务的视图拥有类似于 SoaML 行为的编排。协作、会话和筹划是正式化参与者之间的交互的封装与合约的不同方面的视图。

编排

定义在流程中实现并可能使用服务的活动和任务的顺序

协作

描述当消费者和提供者通过交互来实现某个结果时它们之间交换的消息

会话

描述消息的组织，包封参与者之间的交互，并提供所需的信息，以便识别和关联所涉及的特定参与者。

筹划

指定协作参与者之间的有效交互，包括消息交换模式的排序。

BPMN 提供捕获行为概念的许多示意图。图 11 显示了协作图，阐述在先前的协作图和通信图中所示的 Order Processor 参与者。它显示了 Order Processor 参与者（用池表示）的内部流程，以及与其他参与者交换的消息。Service Task Initiate Price Calculations 代表一个服务操作的调用。Price Data 消息表示服务任务参数。

类似于 UML ActivityPartictions，池中的 BPMN Lanes 可以表示任何东西。在图 11 中，Order Processor 中的通道代表用来交换消息的会话，而且这些会话符合描述那些会话的筹划。为 Collaboration 定义的 Conversation 可用于创建 Lanes。

图 11. 流程在 BPMN 中实现和使用服务

例如，Order Processor 发送一个 Price Data 消息并接收一个 Invoice Response 消息，通过发票 Conversation 调用 Initiate Price Calculations 服务。根据 Invoicing 会话，在该通道上的一切活动都被认为与 Order Processor 和 Invoicer 之间的交互有关。如图 12 中可以看到，这些活动的顺序与针对该通信定义的消息的筹划是一致的。

图 12. 关联通道与 BPMN 中的会话

发票泳道中的 Service Tasks 是指一个 Interface 的操作。该操作的参数是它的输入和输出消息。这些消息必须以某种方式对应于由描述参与者之间的交互的协作和会话所定义的消息。图 13 显示了图 12 所示的 Invoicing 会话的扩展，作为捕获所交换信息的排序的一个筹划。

图 13. 连接 BPMN 会话与筹划

通道之间的关联、在通道中的活动（包括服务任务及其定义接口）、邮件、会话和筹划都没有在本文中任何（一张）BPMN 图中显示。然而，该信息可以在模型元素属性中被捕获。利用通道代表会话并没有在 BPMN 中正式规定，但这是一个有用的建模约定。

回页首

结束语

BPMN 和 SoaML 是 OMG 采用的两项重要标准。尽管这些标准之间存在明显的重叠，但每种标准都有特定的关注点。BPMN 专注于流程模型，从业务流程中的活动的简单编排入手，可以通过扩展来支持流程之间的协作，然后通过再次扩展来支持流程之间的交互的筹划。SoaML 专注于服务架构，以及使用服务合约封装服务架构中的参与者之间的交互，以便对服务水平协议 (SLA) 进行建模。本文探讨了 SoaML 和 BPMN 对封装、合约、结构和行为等概念的支持，以便了解两种语言之间的异同。在下一篇文章 “集成 BPMN 与 SoaML，第 3 部分：映射 BPMN 与 SoaML” 中，将说明：

• 如何跨语言映射公共的元素
• 如何使用此映射来指导如何在相同或相关的项目上（单独或结合）使用这两种建模语言
• 如何充分利用其独特的、免费的特性做到这一点，同时避免因它们的重叠所导致的冗余。