本系列围绕 BPEL 的一些高级话题展开讨论,本篇是该系列中之一,侧重于 SOA 中服务协作的 UML
建模及其到 BPEL 的转换。
在对软件系统建模时,可以从多个切入点以不同的表现方式来描述。在面向服务体系架构(SOA)领域的建模中,大致可以从消息设计、服务设计、服务合成、服务协作、服务策略等主要的关注点来描述。其中,服务协作侧重于两个或多个服务之间的交互关系,常被称为面向服务的流程设计。而随着业务流程的复杂性与日俱增,这种面向编排和协调
Web 服务的服务协作价值也日益被人们所认识。根据 MDA 的思想,在 Web 服务模型的转换中,使用动态行为的平台无关模型
PIM 来定义业务流程,并提供将 PIM 转换成平台相关模型 PSM 的方法。在本文章中,将研究 Web 服务模型的动态行为转换,讲述用
UML 活动图定义业务流程,并提供一种如何从 UML 活动图转换成 BPEL 的方法。基于 IBM Rational Software
Architect 建模工具,通过扩展 UML Profile 进一步增强为服务协作的建模功能,并通过模型转换框架 (Model
Transformation Framework),定义 UML 到 BPEL 的模型转换规则,实现了服务协作的 UML 模型到
BPEL 之间的转换。
近几年来,因特网从最初的简单的信息存储发展到今天的错综复杂的各种电子商务、电子政务等方面的应用。这些错综复杂的应用会涉及到不同系统、不同平台、不同应用和不同部门的信息,甚至涉及到不同企业间的异构分布式交易。因而如何集成不同的异构的分布式的组件、系统、应用和网络成为了一个非常棘手但又必须解决的难题。幸运地是,基于
XML 技术的 Web 服务的出现为解决这一问题提供了最佳手段和契机。Web 服务是一种通过开放标准、Internet 以及基于业界标准的
Intranet 技术动态交互的应用程序,它可以将不同厂商、不同硬件、不同语言编写成的应用程序集成到一起。Web 服务建立在现有的和新兴的标准之上,例如,超文本传输协议(HyperText
Transfer Protocol,HTTP)、可扩展标记语言(eXtensible Markup Language,XML)、简单对象访问协议(Simple
Object Access Protocol,SOAP)、Web 服务描述语言(Web Service Description
Language,WSDL)以及通用描述、发现和集成(Universal Description Discovery and
Integration,UDDI)。
现实世界中的业务流程不仅复杂,而且结合了数不清的完整性控制:ACID 事务支持、长期运行的交互过程的状态持久性、嵌套和并行操作、补偿和例外机制、确认、以及关联能力。随着流程的复杂性与日俱增,能够使用可视化的组装方法设计、实现和归档高度独立和复杂行为的能力所具有的价值也日益被人们所认识。尽管
Web 服务为应用程序通过无边界网络相互传递消息和调用方法提供了一种方法,但是它们仍然不能利用自身的力量满足业务流程的操作需求。业务流程由一组独立和有序的操作组成,每个操作的执行结果都是适时、可预期和可重复的。通过编排和协调,使得
Web 服务能够满足这些需求。当前编排和协调 Web 服务有多种方式,如面向 Web 服务的业务流程执行语言(Business
Process Execution Language for Web Services,BPEL4WS 或 BPEL)、Web
服务编排接口(Web Services Choreography Interface,WSCI)、业务流程建模语言(Business
Process Modeling Language,BPML)、Web 服务对话语言(Web Services Conversation
Language,WSCL)、Web 服务流语言(Web Services Flow Language,WSFL)等。
近年来随着对象管理组织(OMG)对模型驱动架构(MDA)的推广,使得 MDA 在软件开发过程中起着越来越重要的位置。而如何使得
MDA 在 Web 服务世界中更好地应用成为了一项重要的研究课题。国内外一些研究机构和 IT 企业在这方面作了不同程度的研究,例如将
Web 服务模型转换成多种不同的实现平台:Java、.Net、Delphi 等。然而这些研究都仅仅集中于 Web 服务模型的静态结构转换。在本文章中,将研究
Web 服务模型的动态行为转换,这些动态行为模型描述了多种相互协作的完成一定任务或者实现系统一定功能的组件。根据 MDA 的思想,在
Web 服务模型的转换中,使用动态行为的平台无关模型(Platform Independent Model,PIM)来定义业务流程,并提供将
PIM 转换成平台相关模型(Platform Specific Model,PSM)的方法。
1.1 Web 服务与 BPEL、业务流程
软件业最终会接受这样的事实:跨多个操作系统、编程语言和硬件平台集成软件应用程序不可能由任何一种专门的环境来解决。传统上,这个问题一直是一个紧耦合问题,调用远程网络的应用程序通过自己发出的函数调用和请求的参数与远程网络紧密地联系在一起。
在 Web 服务出现之前,在大多数系统上,采用的是固定的接口,但对于环境或需要的改变,这缺乏灵活性或适用性。Web 服务所使用的
XML 可以用真正与平台无关的方式来描述任何(所有)数据,以跨系统交换数据,因此转向了松耦合应用程序。而且,Web 服务可以在较抽象的层面上工作,较抽象层面可以按照需要动态地重新评估、修改或处理数据类型。所以,从技术层面上讲,Web
服务可以更方便地处理数据,并且允许软件更自由地进行通信。
Web 服务是一个软件接口,它描述了一组可以在网络上通过标准化的 XML 消息传递访问的操作。它使用基于 XML 语言的协议来描述要执行的操作或者要与另一个
Web 服务交换的数据。一组以这种方式交互的 Web 服务在 SOA 中定义了特殊的 Web 服务应用程序。Web 服务采用一系列的相关协议来描述、传递服务和与服务交互。SOAP
协议对消息进行编码,这样就可以通过传输协议(如 HTTP、IIOP、SMTP 或其它协议)在网络上传递它们。WSDL 表示为一系列
XML 语句,这些语句组成了每个服务的接口的定义。UDDI 定义了服务如何公开它们自己以及如何在网络上相互发现。
Web 服务是独立的模块化的应用程序,它们常常不能利用自身的力量满足业务流程的操作需求。为满足日益复杂多变的业务需求,需要将这些
Web 服务链接在一起成为一个业务流程来实现更复杂的功能。业务流程指定了一组 Web 服务的操作的可能执行顺序以及这些 Web
服务间共享的数据等。
BPEL 是一种基于 XML 的工作流定义语言,它使企业能够描述既能使用又能提供 Web 服务的复杂的业务流程。它最初是由
Microsoft、IBM 和 BEA 共同开发,它融合了 Microsoft 和 IBM 各自开发的上一代流程语言:XLANG
和 WSFL。BPEL 的基本功能在于能够对 Web 服务加以编排和协调,以便它们开展协作和事务性行为。BPEL 规范已作为协议标准提交至
OASIS 标准机构进行审核和最终命名,以供公众使用。
BPEL 采用 XML Schema 编写,从形式上它定义了用于组成复杂的业务流程交互的基础和结构化活动,指定了业务流程是怎样使用
Web 服务来达到它的目的以及由业务流程提供的 Web 服务。BPEL 是一种以 XML 来描述企业內部流程的语言,使原本建立在不同产品上的商业流程也能像
Web 服务一样可以跨平台互通。
1.2 MDA 下的模型转换
MDA 技术的核心概念均是 OMG 的一系列标准:UML、OCL、MOF、XMI、CWM,其中元对象设施 (Meta Object
Facility,MOF)是 MDA 的核心部分。MDA 下的每一层模型都基于一个特定的元模型,即对表述模型的语言进行定义的模型,而所有的元模型又都基于
MOF。元模型是用来定义转换规则的重要元素,通过使用 MOF 结构定义,可以定义在建模语言之间的转换规则。
源模型与目标模型的转换可以通过在相应的基于 MOF 的源元模型与目标元模型之间定义转换规则来完成。如 图
1-1 所示,在源元模型与目标元模型之间定义一套对应语义的转换规则,这套转换规则必须使得两模型包含相同的语义内容。在源模型与目标模型之间通过专门的模型转换引擎来应用转换规则,完成从元模型到目标模型之间的转换。文章中的源元模型是
UML 活动建模语言,目标元模型是 BPEL 语言。
图 1-1 MDA 下的模型转换
SOA 是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。作为一种新颖的架构样式,SOA
最重要的特征是其能够复用和集成已有系统中的子系统资源,从而创建新的功能更强大的复杂系统。SOA 的实现并不是特定于某种语言、技术和平台,它通过两个抽象的概念
---- 服务(service)以及服务之间的连接器(connector)来达到实现独立性的特征。每一个服务封装了已有系统或子系统的功能,并对使用者屏蔽了实现的具体细节,如编程语言、操作系统或中间件等。每一个连接器定义了服务之间如何交互以及消息如何通过连接器完成服务间的交换,对于使用者来说它同样隐藏了消息交换的实现细节,如消息交换协议及其格式等。开发人员正是通过复用和集成这些服务以及服务间的连接器来构建新的应用。
在对软件系统建模时,可以从多个切入点以不同的表现方式来描述。每一个切入点往往是关注于某一个技术或业务领域。理解这些关注点及其之间的关系对于建模非常重要。如
图 2-1 所示,在 SOA 领域的建模中,大致可以从以下几个主要的关注点来描述:
- 消息设计 : 一个消息代表在 Web 服务描述语言(WSDL)规范中定义的一个概念;即,它是对服务(Service)和服务消费者(Service
Consumer)有意义的实际数据的一个容器。消息设计是指对在服务消费者与服务之间的任何操作所需的交换信息指定相应的消息模式(Schema)。
- 服务设计 : 服务设计关注于服务提供的每一个操作的描述,以及每一个操作请求和返回消息的描述。
- 服务合成 : 服务合成则是从服务之间的依赖关系角度来描述服务的特性。侧重于如何将几个简单的 Web 服务融合成一个功能更加强大的服务。
- 服务协作 : 不同于服务合成,服务协作侧重于两个或多个服务之间的交互关系。它也常被称为面向服务的流程设计。例如,业务流程执行语言(Business
Process Execution Language for Web Services,简称 BPEL)就是一种用来定义
Web 服务交互顺序及其协作的标准语言。
- 服务策略 : 服务策略(WS-Policy)是从 SOA 的非功能方面对 Web 服务及其操作、消息、协作等进行描述。通常,策略往往以宣言式的陈述附加到服务规约上。
图 2-1 面向服务体系架构 SOA 的建模
3.1 服务协作的 UML 建模
元模型在整个模型驱动架构中扮演着重要的角色,它提供了用来描述模型的元素、规则。 图
3-1 中描述的是 UML 活动图的元模型的一部分,其中包含了代表工作流(workflow)、对象流(object
flow)、活动(activities)、操作(actions)以及分叉(fork)、联结(join)等表示控制节点的元模型元素。这些元模型元素来源于
UML2.0 Superstructure Specification 中各种活动、操作模型元素。
图 3-1 UML 活动图元模型
以 BPEL1.1 Specification 中的贷款批准流程为例子。在收到贷款请求时,将请求的数值与数值(10000)比较。如果请求的数值比较少,那么将调用
Assessor 服务,否则将将调用 Approver 服务。如果 Accessor 认为该请求的风险比较高,它也将被传递给
Approver。当 Approver 完成或者 Accessor 接受时,将会返回批准信息。 图
3-2 显示了贷款批准流程的 UML 活动图。
图 3-2 贷款批准流程的 UML 活动图
3.2 基于 BPEL 的服务协作模型
根据前面的讲述,BPEL 可以看作是能够编排和协调 Web 服务的描述语言 WSDL 的一种扩展。也就是说 WSDL 是用来描述独立的
Web 服务及其结构信息的,而 BPEL 描述的则是一系列 Web 服务的编排和协调的方式。因此,可以用 UML 类图描述
Web 服务的静态结构,来表达 WSDL 的语义。当前已经有一些研究机构在关于 UML 类图与 WSDL 之间的映射关系和模型转换方面作了实际的工作。本文章的研究工作是在这些研究基础之上继续扩展,重点研究
Web 服务中动态模型与 UML 活动图之间的映射关系及模型转换。
从 图 3-3 BPEL1.1 的元模型中可以看出,业务流程
process 是元模型中最重要的元素,描述了业务流程模型的结构和控制信息。通常情况下,BPEL 业务流程接收请求。为了满足请求,该流程调用相关的
Web 服务,然后响应原始调用方。由于 BPEL 流程与其他 Web 服务通信,因此它在很大程度上依赖于复合型 Web 服务调用的
Web 服务的 WSDL 描述。BPEL 元模型元素依赖于 WSDL 元素如类型端口(port types)、消息(messages)、操作(operations)。
BPEL 使用 <process> 来定义流程,流程是包含业务流程定义的顶级 BPEL 元素。BPEL 使用
<variable> 声明保存每一个流程运行的上下文信息的变量。为了描述两个服务间的关系,BPEL 使用 <partnerLink>
定义合作伙伴链接。合作伙伴链接类型定义了关系中每个服务所扮演的角色(Role)并指定每个角色所提供的类型端口。一个 BPEL
流程由多个步骤组成,每个步骤称作活动(Activities)。BPEL 支持两种活动:基元活动和结构活动。其中基元活动表示基本构造,用于常见任务:使用
<invoke> 调用其他 Web 服务,使用 <receive> 接收请求、等待客户端通过发送消息调用业务流程,使用
<reply> 生成同步操作的响应,使用 <assign> 操作数据变量,使用 <throw>
指示故障和异常,使用 <wait> 等待一段时间,使用 <terminate> 终止整个流程。然后,可以组合这些基元活动以及其他基元活动,以定义准确指定业务流程步骤的复杂算法。为能够组合基元活动,BPEL
支持几个结构活动。其中最重要的是:顺序(<sequence>)允许定义一组将按顺序调用的活动;流(<flow>)用于定义一组将并行调用的活动;switch-case
构造(<switch>)用于实现分支;<while> 用于定义循环;使用 <pick>
能够选择多个替换路径之一。限于篇幅在此不多赘述,详细介绍可以参阅 BPEL1.1 Specification。
图 3-3 BPEL1.1 的元模型
3.3 从 UML 活动图元模型到 BPEL 元模型的映射
模型转换定义了如何从一种源模型转换成另外一种目标模型。模型转换的研究也有多年了,但直到目前为止也还没有一个统一的标准。现在对象管理组织(OMG)正在进行一个称之为
QVT(Query,View,Transformation)的项目,目的是为变换工具制定一个标准。PIM 模型使用平台无关的语言来说明,这种平台无关的语言使用平台无关的元模型来描述。同样的,PSM
模型使用平台相关的语言来说明,这种平台相关的语言同样使用平台相关的元模型来描述。为实现从 PIM 生成 PSM 的转换目的,须存在一个转换规则,按照此规则将平台无关的元模型转换为平台相关的元模型。本文中平台无关的元模型是
UML2.0 活动图元模型,平台相关的元模型是 BPEL1.1 的元模型,转换规则是基于 OCL 的规则约束,转换过程由一个转换引擎来完成。
从 UML 活动图元模型到 BPEL 元模型的映射表示可以从 UML 活动图模型生成的 BPEL 模型。 表
3-1 概要地展示了从 UML2.0 活动图元模型元素到 BPEL 元模型元素的映射,覆盖到了本文介绍的模型元素。
表 3-1 UML2.0 活动图元模型元素到 BPEL 元模型元素的映射
UML2.0
活动图元模型元素 |
BPEL
元模型元素 |
Activity |
一种基本的行为方式,本质上指可包含一系列动作和相关变量的行为序列 |
process |
BPEL 流程定义 |
ObjectNode,StructuredActivityNode(Variable),DataStore
|
对象节点 ObjectNode 用来指定对象数据流中的值;结构活动节点 Structured Activity
Node 是一种特殊的可执行节点,可包含其他活动节点及变量;数据存储 DataStore 用来存放缓冲数据信息; |
variable |
保存每一个流程运行的上下文信息 |
ControlFlow |
控制流 ControlFlow 包含一个或多个按照一定顺序执行的活动; |
sequence |
定义一组活动的调用顺序 |
AcceptCallAction |
用来接收请求信息的动作,以响应客户端的请求;等待客户端发送请求信息以启动活动流; |
receive |
使用 <receive> 接收请求、等待客户端通过发送消息调用业务流程 |
CallAction,CallOperationAction
|
操作调用,将请求动作转发给目标对象;可以是同步的,也可以是异步的; |
invoke |
流程用 <invoke> 活动调用伙伴提供的 Web 服务;可以是同步的,也可以是异步的 |
VariableAction,ReadVariableAction,WriteVariableAction
|
对变量进行读写操作,可以将一个变量赋予另一变量; |
assign |
用于将数据从一个容器复制到另一个容器,也可以用于通过使用表达式构造和插入新数据 |
ReplyAction |
接收一系列返回值,并用来响应 AcceptCallAction 动作; |
reply |
在流程中可以定义多个 reply 活动来回答该伙伴的调用 |
基于 UML2.0 标准,IBM Rational Software Architect ( 简称为 RSA) 提供了功能强大的
UML 建模,并提供了一个功能强大、易于扩展的模型转换框架(Model Transformation Framework)。模型转换框架是一个基于转换规则的执行引擎,基于该框架,可以很方便地定义模型转换规则,实现各种模型之间的转换。
通过扩展 UML Profile 进一步增强为服务协作的建模功能,如 图
4-1 所示描述了基于 RSA 创建的这种 UML profile 所包含了具体的元素内容。
图 4-1 为服务协作扩展的 UML Profile
通过使用这个 profile 中定义的 stereotype 对需要执行扩展转换规则的源模型对象作标记,扩展转换规则会根据特定的
stereotype 来过滤源模型对象确定执行情况。一般地,一个模型转换通常会根据功能划分成若干个转换,每个转换由若干规则组成,实现一部分独立的功能。在这些转换之间,通过转换上下文共享数据。这样,在对其进行扩展的时候,需要根据具体的需要,在某些阶段的模型转换中增加转换规则,并通过转换上下文共享数据。
基于 RSA 提供的模型转换框架 (Model Transformation Framework),添加 com.ibm.xtools.transform.core.transformationProviders
扩展点,并按照 3.3 节中定义的映射关系定义各种元素之间的转换规则。
列表 4-1 描述了为实现转换所定义的扩展点。
列表 4-1 为实现转换所定义的扩展点
<extension point="com.ibm.xtools.transform.core.transformationProviders">
<TransformationProvider
class="com.ibm.xtools.transform.uml2bpel.UML2BPELTransformationProvider">
<Priority
name="Highest">
</Priority>
<Transformation
version="1.0"
name="UML to BPEL"
transformGUI="com.ibm.xtools.transform.uml2bpel.TransformGUI"
author="wangxn"
groupPath="UML to BPEL Transformations"
sourceModelType="UML2"
targetModelType="Resource"
id="com.ibm.xtools.transform.samples.class2text.file.root">
<Property
name="%Property.classtotext.file.targetFile.name"
description="%Property.classtotext.file.targetFile.description"
value=""
id="targetFile">
</Property>
</Transformation>
</TransformationProvider>
</extension> |
类似的实现技术作者在他的另外一篇文章中已经做过一些介绍,有兴趣的读者请参阅他的另一篇文章:
使用 Rational Software Architect 建模并生成 Web 服务元数据 。
在对软件系统建模时,可以从多个切入点以不同的表现方式来描述。在 SOA 领域的建模中,大致可以从消息设计、服务设计、服务合成、服务协作、服务策略等主要的关注点来描述。其中,服务协作侧重于两个或多个服务之间的交互关系,常被称为面向服务的流程设计。而随着业务流程的复杂性与日俱增,这种面向编排和协调
Web 服务的服务协作价值也日益被人们所认识。根据 MDA 的思想,在 Web 服务模型的转换中,使用动态行为的平台无关模型
PIM 来定义业务流程,并提供将 PIM 转换成平台相关模型 PSM 的方法。在本文章中,将研究 Web 服务模型的动态行为转换,讲述用
UML 活动图定义业务流程,并提供一种如何从 UML 活动图转换成 BPEL 的方法。基于 IBM Rational Software
Architect 建模工具,通过扩展 UML Profile 进一步增强为服务协作的建模功能,并通过模型转换框架 (Model
Transformation Framework),定义 UML 到 BPEL 的模型转换规则,实现了服务协作的 UML 模型到
BPEL 之间的转换。
学习
获得产品和技术
讨论