本系列围绕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之间的转换。
1. 概念和原理
近几年来,因特网从最初的简单的信息存储发展到今天的错综复杂的各种电子商务、电子政务等方面的应用。这些错综复杂的应用会涉及到不同系统、不同平台、不同应用和不同部门的信息,甚至涉及到不同企业间的异构分布式交易。因而如何集成不同的异构的分布式的组件、系统、应用和网络成为了一个非常棘手但又必须解决的难题。幸运地是,基于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下的模型转换
2.SOA的建模
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.SOA中服务协作的UML建模及其到BPEL的映射
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-3BPEL1.1的元模型中可以看出,业务流程process是元模型中最重要的元素,描述了业务流程模型的结构和控制信息。通常情况下,BPEL业务流程接收请求。为了满足请求,该流程调用相关的Web服务,然后响应原始调用方。由于BPEL流程与其他Web服务通信,因此它在很大程度上依赖于复合型Web服务调用的Web服务的WSDL描述。BPEL元模型元素依赖于WSDL元素如类型端口(port types)、消息(messages)、操作(operations)。
BPEL使用
图 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元模型元素的映射,覆盖到了本文介绍的模型元素。
4. 基于IBM Rational Software Architect实现建模与转换
基于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为实现转换所定义的扩展点
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”>
description=”%Property.classtotext.file.targetFile.description”
value=””
id=”targetFile”>
类似的实现技术作者在他的另外一篇文章中已经做过一些介绍,有兴趣的读者请参阅他的另一篇文章: 使用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之间的转换。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突