转自 http://www-128.ibm.com/developerworks/cn/webservices/ws-bpel/part1/index.html

级别: 初级    2003 年 3 月 01 日 王 强, 软件工程师, 日本富士施乐（FujiXerox）

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
引言
本文主要介绍的有3个方面的内容
• BPEL4WS语言的特点。
• BPEL4WS语言主要元素使用技巧提示。
• BPEL4WS语言利用外部Web服务的技巧提示。
（注：对于BPEL4WS的基本语法介绍由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍。）

1．BPEL4WS语言的特点
BPEL4WS语言从诞生到现在还不到一年的时间，我们可以说它是一门新的语言，但是它又不完全独立于现在已经存在的各种编程语言，从各方明进行总结，可以得出以下三个突出的特点：
〈一〉 BPEL4WS并不"新"：
为什么说它并不新呢？这主要是因为光就BPEL4WS语言本身的语法结构以及编程的思想来说，它是被广大程序员所熟悉的（当然，你得熟悉XML语言和基本的程序设计思想，还有就是得有分布式系统的概念，如DCOM,CORBA等）。
BPEL4WS的文法是完全基于XML规范的，如果不考虑它的程序语言特性，大家完全可以把它理解为普通的XML文档规范，也就是说可以把BPEL4WS中的所有节点对应到一个虚拟的DTD文件中。如果不考虑它的程序特性，大家在编写BPEL文件的时候就只是按照这个DTD所定义的规范在编写普通的XML文件罢了。BPEL4WS主要基于以下几个XML规范的，WSDL 1.1、XML Schema 1.0 和XPath1.0。WSDL消息和XML Schema类型定义提供了BPEL4WS流程所需要的所有数据模型，所有需要的外部资源和伙伴都被描述为WSDL服务。
如果对BPEL4WS语言的语法做较深入的研究，你就会发现它其实只是对原有编程语言思想的继承和发展。
● 关于继承，BPEL4WS语言拥有传统编程语言的一些基本特性，如：
赋值操作（由对〈container〉的操作完成）；
循环操作（由〈while〉操作完成）；
选择操作（由〈switch〉和〈case〉操作完成）；
远程调用操作（由〈invoke〉操作完成）；
错误捕捉操作（由〈catchfault〉和〈catchall〉操作完成）；
错误抛出操作（由〈throw〉操作完成）
Java,C#语言中的try操作（由〈scope〉操作完成）
● 关于发展，BPEL4WS语言是一门结合了商业处理特点的语言；
由于BPEL4WS语言是专为商业流程的执行所服务的，因此它也就自然而然的具有一门商业处理语言的特点，这体现在以下几个方面：
1>提供了对于远程调用（〈invoke〉）的同步和异步处理；
这主要是由商业处理的特点决定的，就拿民航订票来说吧，当你向民航订票系统的订票Web Service发出订票请求后，你不可能期望马上得到结果（同步），因为民航系统必须要首先要进行复杂的身份识别以确定你的系统是否有预订机票的权限，接着还要查询航班情况以确定是否你定的航班还有空座，然后才会给你答复，而你不可能一直等待得到答复，就算你愿意你的服务器恐怕也受不了这个负担。因此你必须选择异步方式，也就是发出请求后继续执行其他的操作，在这一点上有一点类似于TCP/IP协议和UDP协议的关系。
2〉提供了并行的操作（由〈flow〉操作支持）；
对于普通的程序设计语言来说，并行的概念只是用于表面。打个比方，也许有人会说，利用windows系统（或者unix, linux系统）的多任务执行能力，我可以让一个程序一边在后台执行计算而前台却进行复杂的人机交互工作，这不也是一种并行吗。的确，这也是一种并行，但它只是cpu级别的并行，而BPEL4WS语言所体现的并行性是一种更广范围的并行，是基于INTERNET的并行，在某些方面，类似于传统的并行处理系统（利用机群进行大规模复杂并行计算）。通过BPEL4WS，可以同时调用位于不同地方（不同城市甚至是国家）的Web Services进行处理（如计算，订货等）。
3〉提供了补偿的操作（由〈compensate〉操作支持）；
任何程序的执行都可能会出错，而后果也是不同的。有的操作出错并不会产生什么直接的后果，而有的操作出错的结果就必须被纠正，也就是必须执行一些补偿的操作。比如拿民航订票来说吧，假如顾客A在系统中预订一张机票，当民航系统的Web Services完成所有订票操作后，提交给顾客A请求确认时，顾客A由于其他原因取消了订票操作或者系统出现故障，那么就必须要执行补偿操作，取消所有已执行的操作，恢复数据库信息。从某个方面来说，这很类似于DBMS中的ROLLBACK操作，只不过在数据库系统中是微观执行的，而在BPEL4WS中是宏观执行的。
〈二〉 BPEL4WS并不"可执行"：
BPEL4WS虽然定义为一门商业执行语言，但实际上它并不执行商业流程中的任何细节，也就是说它一点也不涉及到商业数据的存储和处理。BPEL4WS语言从本质上来说应该是一门描述性语言，它只是描述了什么时候？以什么顺序？到哪儿？去调用那些Web服务？怎样组织这些调用？罢了。因此，在BPEL4WS中并没有出现复杂的数据结构和数据类型，也没有关于数据存储和持久化的操作，唯一涉及显式数据操作的地方就是〈container〉的使用了，但容器中的数据只是一些临时数据，一旦商业处理的流程结束，这些数据也就消失了，这些数据就好像是传统程序语言中的变量一样，但又没有那么复杂的数据类型。说BPEL4WS语言是商业流程执行语言是因为从宏观上看，所有的操作都由BPEL4WS来完成，而其背后的操作，如Web服务的调用等是不可见的，也就是说是不透明的。这就好比软件测试中的黑盒测试一样，用户只看到了自己应该看到的用户接口，而不用去关心这些功能到底是怎样实现的。
〈三〉 BPEL4WS是真正的分布式系统：
随着INTERNET的迅速发展，在分布式技术领域也不断涌现出新技术新思想。SOAP,XML以及基于它们的Web Services，这些新技术的出现为新的分布式处理模型提供了坚实的基础，而BPEL4WS的诞生，才是分布式技术的真正升华。比起传统的分布式系统来说，利用BPEL4WS实现的分布式系统具有更高的灵活性，这主要体现在以下几个方面：
1〉各个节点机可以为异构系统：
2〉可以在运行时动态选择节点机进行处理：
3〉可以采用各种通信协议进行通信，只要符合SOAP协议。
2.BPEL4WS语言主要元素使用提示。
BPEL4WS语言中的各个元素就好像是传统编程语言中的关键字一样，正是由这些基本的元素组合到一起，构成了BPEL4WS的语言结构。从总体上划分，BPEL4WS语言可以被划分为最重要的四个部分（并不是所有BPEL4WS元素都包含在其中，这只是按主要功能进行划分的）
1〉数据处理
2〉基本活动
3〉结构化活动
4〉作用域
由于篇幅的关系，在这里就不进行详细的介绍了，相关的内容可以查阅BPEL4WS语言规范。
（英文版： http://www.ibm.comhttp://www.ibm.com/developerworks/library/ws-bpel/）
在实际的开发中，对于初学者来说，最容易迷惑的恐怕是BPEL4WS语言中关于各个元素之间相互包容关系的理解，这一点也是BPEL4WS语言比传统编程语言较为难的一点。用传统的编程开发语言进行开发，往往各个元素之间是可以互相嵌套的，而在BPEL4WS语言中各个元素之间的包含关系有着严格的规定，但遗憾的是这在它的Specification中并没有明确的指示出来（即没有显式的总结出来），也许对于一个资深BPEL4WS开发人员来说，一切都是那么自然而然，但对初学者来说，我觉得首先掌握BPEL4WS中各个元素之间的相互包含依赖关系是十分重要的。
下面是我为大家总结的BPEL4WS语言中的最重要的各个元素之间的包含依赖关系对照表。纵坐标代表母元素，也就是父节点；横坐标代表子元素，也就是子节点。有黑点标识的表示子节点（横坐标）可以包含于父节点（纵坐标）中，反之则不然。

3.BPEL4WS语言利用外部Web服务的技巧提示。
既然BPEL4WS语言本身并不执行任何业务操作，那么这些操作就必须由相应的Web服务来执行，这一点一定要体现在BPEL4WS的程序中。而如何调用这些外部的Web服务呢？这就要用到Web服务描述语言（WSDL）了。在WSDL文件中详细的描述了相关Web服务的细节内容，包括接口定义，消息定义，操作定义，连接定义等。
目前可以得到外部Web服务详细信息的途径主要有3条途径：
1〉通过本地的WSDL文件获得相关的Web服务信息。
优点：使用方便
缺点：不够灵活；不能保持与最新Web服务信息的同步
2〉通过TCP/IP协议获得分布于INTERNET上的Web服务的详细信息。
优点：可保持信息的同步
缺点：不能对同种类Web服务进行灵活选择。
3〉通过UDDI注册中心获得已注册的Web服务的详细信息。
优点：非常灵活，可以对登记在UDDI注册中心的所有同种类Web服务进行灵活的选择。
缺点：实现起来难度较大。
在得到需要的WSDL文件之后，我们就可以开始利用其中的信息进行系统的构架了。但是对于外部WSDL文件的使用上，有一点比较容易使初学者感到迷惑，那就是外部WSDL文件中的哪些信息对我们来说是有用的而哪些信息对我们来说是没用的。对于这一点，虽然在BPEL4WS的Specification中间接的介绍了，但遗憾的是没有详细的罗列出来。因此在此有必要做出较为详细的说明。
对于BPEL4WS语言中的各个元素来说，它们使用外部WSDL中的有用信息是通过它们的属性值来体现的。举个例子，在使用〈invoke〉时，我们必须指定相应的参数才可以完成调用，否则系统有哪能知道要调用什么操作呢？〈invoke〉操作如下所示：
<invoke name="getResults"
              partner="getResultsService"
              portType="getResultsPT"
              operation="getResults"
              inputContainer="getResultsData">
</invoke>
在上面的代码中，红色的属性说明这些属性值应来自外部的WSDL文件中；蓝色的属性说明这些属性值应来自这个BPEL4WS文件本身。这就说明在利用BPEL4WS文件构造系统的时候，不仅要注意那些来自外部WSDL文件中的有用信息，还要注意利用你所设计的BPEL4WS文件本身中已定义的一些信息。对于这一点在BPEL4WS的Specification中没有显式的提出来，希望在这里可以得到大家的注意。
（注：在IBM公司Eclipse开发环境中嵌入的BPEL4WS开发环境可以实现BPEL文件本身相关信息的动态处理，如显示在下拉框中；但遗憾的是对于来自外部WSDL中的信息没有动态处理和显示的功能。）
在下面的部分中，总结了BPEL4WS语言中各个元素的属性值的数据来源，希望对大家有所帮助。
BPEL4WS主要元素参数分析
〈一〉 来源于BPEL文件自身的参数：
（1） Container/Input Container/Output Container/Fault Container:
<数据来源>
来源于BPEL文件中的〈containers〉节点中的〈container〉节点的"name"属性。
   <containers>
     <container name="request"
                messageType="lns:requestMessage"/>
     <container name="reply"
                messageType="lns:replyMessage"/>
   </containers>   
（2） Partner:
<数据来源>
来源于BPEL文件中的〈partners〉节点中的〈partner〉节点的"name"属性。
<partners>
      <partner name="customer"
               serviceLinkType="lns:buyServiceLinkType"
               partnerRole="customer"/>
      <partner name="seller"
               serviceLinkType="lns:sellServiceLinkType"
               partnerRole="seller"/>
   </partners>   
（3） Scope:
<数据来源>
来源于BPEL文件中的〈scope〉节点的"name"属性的值。
<scope name="buyScope" >
    <compensationHandler>
        <invoke partner="Seller" portType="SP:buy"
                operation="CancelBuy"
                inputContainer="getResponse"
                outputContainer="getConfirmation">
           <correlations>
              <correlation set="buyOrder" pattern="out"/>
           </correlations>
        </invoke>
    </compensationHandler>
</scope>    
（4） Set:
<数据来源>
来源于BPEL文件中的〈correlation〉节点的"set"属性的值。
<correlations>
       <correlation set="shipOrder" pattern="out"/>
</correlations>
（5） Pattern:
<数据来源>
来源于BPEL文件中的〈correlation〉节点的"name"属性。
<correlations>
       <correlation set="buyOrder" pattern="out"/>
</correlations>
〈二〉 来源于外部WSDL文件中的参数：
（1） Operation:
<数据来源>
来源于外部WSDL文件中的〈portType〉节点中的〈operation〉节点的"name"属性。
<portType name="buyServicePT">
<operation name="buyRequest">
  <input message="buyRequestMsg"/>
</operation>
</portType>
（2） PortType:
<数据来源>
来源于外部WSDL文件中的〈portType〉节点的"name"属性。
<portType name="buyServicePT">
<operation name="buyRequest">
  <input message="buyRequestMsg"/>
</operation>
</portType>
（3） FaultName:
<数据来源>
来源于外部WSDL文件中的〈portType〉节点中的〈fault〉节点的"name"属性。
<portType name="buyServicePT">
<operation name="buyRequest">
  <input message="buyRequestMsg"/>
</operation>
     <fault name="buyFault">
</fault>
</portType>
（4） MessageType:
<数据来源>
来源于外部WSDL文件中的〈message〉节点的"name"属性。
<message name="buyRequestMsg">
<part name="buyOrder" type="buy:buyOrder"/>
</message>
<message name="buyNoticeMsg">
<part name="buyNotice" type="buy:buyNotice"/>
</message>
（5） MyRole/PartnerRole:
<数据来源>
来源于外部WSDL文件中的〈serviceLinkType〉节点中的〈role〉节点的"name"属性。
<slnk:serviceLinkType name="buyLT"
   xmlns:slnk="http://schemas.xmlsoap.org/ws/2002/07/service-link/">
<slnk:role name="buyService">
  <slnk:portType name="buyServicePT"/>
</slnk:role>
<slnk:role name="buyServiceCustomer">
  <slnk:portType name="buyServiceCustomerPT"/>
</slnk:role>
</slnk:serviceLinkType>
（6） ServiceLinkType:
<数据来源>
来源于外部WSDL文件中的〈serviceLinkType〉节点的"name"属性。
<slnk:serviceLinkType name="buyLT"
   xmlns:slnk="http://schemas.xmlsoap.org/ws/2002/07/service-link/">
<slnk:role name="buyService">
  <slnk:portType name="buyServicePT"/>
</slnk:role>
</slnk:serviceLinkType>

结束语
在本文中简要的介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧。在以后的文章中，打算仔细的探讨有关利用BPEL4WS进行系统开发和商业流程架构的细节问题和技巧，希望能对大家有所帮助。
参考资料
1.BPEL4WS语言规范：
英文版： http://www.ibm.com/developerworks/library/ws-bpel/
2.Business processes: Understanding BPEL4WS, Part1-Part4:
http://www.ibm.comhttp://www.ibm.com/developerworks/library/ws-bpelcol/
3.W3C Note "Web Services Definition Language (WSDL) 1.1" 4.W3C Recommendation "The XML Specification"

级别: 初级    王强, 软件工程师

2003 年 3 月 01 日

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
在本文的上一篇文章中( 商业流程开发新纪元——BPEL4WS语言介绍，第1部分：特点介绍及使用技巧提示)，已经向读者介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧。在本文中将继续向读者介绍有关利用BPEL4WS语言进行系统开发时如何有针对性的利用现有成熟软件过程RUP(Rational Unified Process)。

引言

本文主要介绍的有2个方面的内容；

1，分析利用BPEL4WS进行系统开发与普通的软件开发过程相比有哪些应该特别加以注意的问题。
2，针对BPEL4WS语言的特点，介绍如何有针对性的利用成熟软件过程RUP进行系统开发。

（注：对于BPEL4WS的基本语法介绍以及RUP的详细内容由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍；在文中出现的"BPEL4WS系统"与"用BPEL4WS语言开发的商业系统"同义。）

回页首

利用BPEL4WS语言进行系统开发时所应注意的一些问题

BPEL4WS语言是一门专为创建商业处理流程而诞生的基于XML语言规范的高级抽象语言，它不仅在语言的Specification方面不同于传统的计算机语言，而且当利用BPEL4WS语言进行系统开发(即创建具体的商业流程)时也与传统的系统开发过程有一些不同之处。大家主要应该注意以下几个方面：

〈一〉并行操作；

BPEL4WS语言中的并行操作是由〈flow〉完成的。这种并行是通过同时调用Internet上位于不同地方（不同城市甚至是国家）的Web Services进行各种商业处理来完成的。就如图1所示，当处理流程开始后，进入〈flow〉结构，在〈flow〉中同时开始执行两个并行的〈sequence〉操作，〈flow〉操作也只有等到这两个〈sequence〉操作都完成后才可以结束。正是由于BPEL4WS具有这种并行特性，所以在建模的时候就要着重参照并发模型的建模方法。

图1：并行操作〈flow〉示例

〈二〉弱数据处理能力；

由于BPEL4WS语言在实际操作中不涉及到商业数据的存储和处理，也就是说所有有关于数据库的操作都隐式的由其调用的外部Web服务来完成，这些数据库操作不论对于开发人员和用户来说都是透明的。正因如此，在BPEL4WS中并没有出现复杂的数据结构和数据类型，也没有关于数据存储和持久化的操作，涉及到显式数据操作的地方就是〈container〉结构的使用了，而在〈container〉中的数据没有那么复杂的数据类型，因此我们可以说BPEL4WS语言是弱数据处理能力的。正是由于它的弱数据处理能力，决定了针对BPEL4WS语言的建模方法不太适合采用面向数据流的分析设计方法和针对算法的建模，因此面向对象的分析设计方法以及面向对象的建模自然而然就成为了最好的选择。

〈三〉分布式系统架构；

BPEL4WS的诞生，完全是由于分布式技术的飞速发展，SOAP,XML以及Web Services的出现为BPEL4WS语言的出现奠定了坚实的基础。在BPEL4WS中一个最重要的概念恐怕就是"伙伴"〈partner〉结构了，BPEL4WS中的主要操作都要指定相应的〈partner〉，〈portType〉和〈operation〉。〈partner〉实际上就指明调用了哪一个Web服务，〈portType〉指明了调用这个Web服务上的哪一个端口类型，〈operation〉指明了调用的具体操作（可类似看作调用一个函数）是〈portType〉中的哪一个。由于指定的"伙伴" 所位于的各个节点机可以为异构系统，且与这些"伙伴"之间进行的通信可以基于各种通信协议(只要符合SOAP协议)，所以决定了对于系统构件模型(component model)和系统实施模型(deploy model)的建模就变得相当的重要。只有在系统的分析和设计中清晰地体现出所有与系统相关的外部Web服务的有关信息，才能算是对系统的整体架构有一个完整的描述。

回页首

针对BPEL4WS语言的特点，合理结合成熟软件过程RUP进行系统开发

RUP(Rational Unified Process)即Rational统一过程，定义了一系列的过程元素，如角色，活动和产物，通过适当的组合，能够帮助软件开发组织有效地管理软件过程。RUP的特点体现在它是以用况驱动(use case driven)的，以体系结构为中心(architecture-centric)，迭代和增量(iterative process)的。在系统的整个开发生命周期内共有4个阶段：初始(inception)、细化(elaboration)、构造(construction)和移交(transition)，随着时间的推移，每个阶段所注重的焦点也不断发生变化，同时这四个阶段也是不断迭代完成的，每一次迭代都有增量的任务完成。

由于BPEL4WS语言自身所具有的特点，决定了在结合RUP使用的时候不能完全生硬的照搬RUP的整个过程，在一些方面要做一些适当的修改，这主要体现在以下几点：

〈一〉项目阶段重点的适度转移

从管理的观点来说，Rational Unified Process 的软件生命周期随着时间分为四个依次进行的阶段（初始、细化、构造和移交），每个阶段的结束都有一个主要里程碑，这些里程碑实际上就是每一阶段工作成果的输出。针对普通的项目开发来说，每一阶段的工作量大致可划分为：

　 先启 精化 构建 产品化
工作量 5 % 20 % 65 % 10%

在这里要做出一些改变的地方是精化和构建阶段。构建阶段的主要工作结果输出中有一项是实施模型，实施模型对在精化阶段创建的模型进行了扩展，在实施模型中要确定所有要用到的构件，并且必须决定如何将设计模型中的类和包映射到实施模型中的构件和子系统中。对于普通的项目来说，系统中所要用到的构件要么由自己开发，要么使用第三方提供的构件。但对于BPEL4WS系统来说，由于并不存在本地构件的使用，系统中所用到的所有业务处理功能全部都是通过调用外部的WEB服务来实现的，虽然我们也可以把调用这些外部的WEB服务看成是调用散布在Internet上的控件，就好像调用CORBA,DCOM一样，虽然结果是相同的，但由于这些外部的WEB服务都是由其他的商业团体提供的，再加上最重要的一点是同样功能的WEB服务可能有很多，而且分别由不同的团体提供（这也体现了UDDI的好处），这些WEB服务虽然功能上是相同的，但在接口细节及其他一些方面（如性能等）有很大的差别，所以作出合理的选择将是一件费时费力的工作，一旦没有作出较好的选择就有可能影响到实施阶段的工作，还有可能导致返工。因此，应将构建阶段中的实施模型中的一部分工作提前到精化阶段中完成，尤其是系统外部"伙伴"的确定是至关重要的。但在精化阶段由于用例（use case）的分析还不够深入，所以在精化阶段不可能全部完成实施模型的创建工作，也就是说在利用BPEL4WS语言进行系统开发时，实施模型的构建活动应该在精化阶段就开始，一直持续到构建阶段结束，因此工作量方面也要作出适当的调整，大体上向精化阶段增加5％－10％的工作量，具体根据情况而定，大致划分如下。

　 先启 精化 构建 产品化
工作量 5 % 25－30 % 55－60 % 10%

〈二〉部分核心工作流程的调整

在RUP中，项目开发可以包含几个主要的核心工作流程，包括业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理和环境。在这里要特别注意的除了实施（上面已经介绍过）以外，测试和配置与变更管理对于BPEL4WS系统来说是非常重要的。

测试：

测试的目的在于核实对象之间的交互、核实软件的所有构件是否正确集成、核实所有需求是否已经正确实施、确定缺陷并确保在部署软件之前将缺陷解决。在很多组织中，软件测试占软件开发费用的 30% 到 50%。但大多数人仍然认为软件在交付之前没有进行充分的测试。这个矛盾主要来自两个方面的原因，第一个，测试软件十分困难。给定程序具有无数的不同行为方式。第二个，测试通常是在没有明确的方法，不采用必须的自动化手段和工具支持的情况下进行的。由于软件的复杂性，无法实现完全测试，但采用周密的方法和最新技术水平的工具可以明显提高软件测试的生产率和有效性。

由于BPEL4WS系统的特点决定了我们应该在整个软件生命周期的早期就启动执行良好的测试，这将明显降低完成和维护软件的开支，关键是它还可以大大降低与部署质量低劣的软件相关的责任或风险。由于外部WEB服务具有一些不确定性（接口的可变性等），我们应该将初期测试的重点放在对于那些与外部WEB服务接口相关联的模块的测试上，要尽早建立合理的测试用例进行测试，而且一定要将测试用例和测试结果进行文档化，这样可以在最后进行整合测试时作为十分有价值的参考。

维护阶段的测试显得更加的重要，对于BPEL4WS系统来说，其系统维护成本通常要占到总成本的40%左右，而且维护成本会受到用户数目的严重影响，这是因为用户越多，所发现的错误也越多。在这里要专门提到的是有关于在发生在系统维护阶段的程序缺陷修复活动，有时看上去很轻微的错误，比如调用WSDL中提供的<operation>时，从<container>中取出的数据的数据类型与<operation>中的<message>的数据类型不符，本来应该是长整数，结果错用成整数，这类错误虽然很难发现，但一旦在维护阶段的实际使用中暴露出来后，修复工作还是较简单的（只限于这个子系统）。由于维护人员常常不是编写代码的开发人员，而是一些初级程序员或者新手，结果更大范围的修复工作常常会被忽视，尤其是涉及到其他子系统时。所以在BPEL4WS系统的维护阶段，测试变得更加的重要。每次发现错误修复后，必须重新运行先前的所有测试用例，这样才可以确保系统不会以更隐蔽的方式被破坏。

配置与变更管理：

在配置与变更管理中，最重要的是一个组织的配置与变更请求管理系统（CM 系统），因为在CM系统中存放了有关该组织的产品开发、部署和维护流程等的重要信息，并且保留了执行这些流程时产生的阶段成果。CM 系统是整个开发流程中的核心部分，它必不可少。对于BPEL4WS系统，我们已经注意到与我们息息相关的外部WEB服务具有无法避免的易变性（这是由于商业系统本身就是一个易变的系统，各种商业活动的规范和流程都可能随时改变，因此导致所提供服务的改变，正像《人月传说》中说的那样"不变只是愿望，变化才是永恒"），因此对于这些易变性的捕捉就变得十分的重要，这可能在开发阶段体现的还不是很明显，但在系统维护阶段就变得显而易见了，没人能保证自己系统用到的外部WEB服务的接口不会变，也没有人可以预测什么时候变，所以对于我们来说只能以不变应万变，做好配置与变更管理，而且要把重点放在系统中所调用的外部WEB服务的接口规则上，一定要保持同时更新，保证所涉及的每一个子系统能同步得到最新的变更通知。

〈三〉新的人员角色的增加

在RUP中，所有的人员按角色划分可分为分析员、开发人员、测试人员、经理、其他角色。由于在BPEL4WS系统中外部WEB服务对我们来说是最重要的问题，我们的一切操作都要依靠它们，所以我们必须针对它们提供专门的人员角色来负一些重要的活动。

对于分析员角色，我们应该设置专职人员负责外部WEB服务的调查工作（如接口规则以及性能特点的调查），他还要在测试阶段和测试人员合作一起负责相关测试用例的生成，这类人员的工作可以为系统的设计和测试提供充足的参考。我们可以把这类人员角色称为"外部服务审核员"。

对于其他角色，如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个系统所涉及的所有外部WEB服务的相关文档的收集和整理，我们可以把这类角色称为"外部服务文档管理员"，"外部服务文档管理员"的工作应该和"外部服务审核员"的工作紧密联系，并且这两种人员角色的工作与测试、配置与变更管理这两个系统核心流程紧密相关，如图2所示（这并不是说与其他的核心流程就没有关系了，这只是说与这两个核心流程的关系更加紧密罢了，这也是由BPEL4WS系统的特点所决定的）。

以上两种人员角色的工作十分的重要，他们的工作降低了复杂的外部Web服务可能对系统开发带来的干扰性程度，因此我们在作系统开发时要尽量分配专职人员负责这些工作。

图2：新增人员角色

回页首

给开发者的建议

BPEL4WS系统比起普通的分布式系统，它体现了一种更高级的分布式系统抽象模型，它体现了最新的分布式概念，它所依靠的一系列的新技术无一不体现了分布式和面向对象技术的飞速发展,而其中的WebServices技术正是基于组件的系统开发模式在多层分布式系统中的最好体现。新技术的出现自然要求整体软件开发过程也要随之进步、发展。现在越来越多的国内软件组织已经认识到了规范软件过程的重要性，作为软件从业人员，应该在提高自身技术水平的同时注意对自己在软件过程规范性方面的培养，有条件的软件组织最好对开发人员进行有关PSP（Personal Software Process）方面的培训并结合一个成熟的软件过程（如RUP）来规范组织的开发流程，争取使整个开发组织达到CMM2（可重复层）的水平，然后在此基础上逐渐过渡到TSP（Team Soft Process），当PSP/TSP在软件组织中确实开展起来，并且所有的软件人员都认识到了过程规范的重要性，那么无论是CMM3，CMM4甚至是CMM5，我想也就会变得不是那么可望而不可及了。但所有的过程都不是万能的，必须要结合自己组织的特点以及要开发系统的特点做出适当的调整才可以达到事半功倍的作用，一味的死搬硬套有时不仅不能起到积极的作用，还有可能挫伤软件人员的工作积极性，我们一定根据自己软件组织的特点，在实践中不断摸索经验和总结自身的特点，不断的持之以恒的改进自己的过程，我相信只有这样才能取得最令我们满意的效果。

回页首

结束语

在本文中向读者介绍了有关利用BPEL4WS语言进行系统开发时如何有针对性的利用现有成熟软件过程RUP(Rational Unified Process)。由于篇幅的限制，将有关如何合理利用UML(Unified Modeling Language)进行系统建模的介绍放在了下一篇文章中，并且在下一篇文章中还会举一个实际的例子(贯穿分析，设计和实现)来阐明有关利用BPEL4WS进行系统开发和商业流程架构时应注意的细节问题，希望能对大家的具体工作起到一些帮助作用。

在本篇文章中，如有任何错误或者不够完善的地方请您与我联系，我的邮箱地址是： qwang@mb1.ksp.fujixerox.co.jp，十分感谢您的反馈意见。

另外，由于我目前正在从事BPEL4WS语言的集成开发环境的设计和开发，如果您对这方面有什么好的建议也可以直接来信和我联系，谢谢。

回页首

参考资料

1．商业流程开发新纪元－BPEL4WS语言介绍，第1部分：特点介绍及使用技巧提示 http://www.ibm.com/developerworks/cn/webservices/ws-bpel/part1/index.shtml
2．BPEL4WS语言规范：
英文版： http://www.ibm.comhttp://www.ibm.com/developerworks/library/ws-bpel/
3．RUP(Rational Unified Process) http://www.rational.com/products/rup/index.jsp
4．CMM（Capability Maturity Model ）,PSP（Personal Software Process）,TSP（Team Software Process） http://www.sei.cmu.edu/

2003 年 8 月 01 日

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
在本文的前两篇文章中(商业流程开发新纪元——BPEL4WS语言介绍， 第1部分：特点介绍及使用技巧提示 第2部分：如何有针对性的利用RUP来规范BPEL4WS系统开发流程)，已经向读者介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧，在软件过程方面着重介绍了在利用BPEL4WS语言进行系统开发时如何合理利用现有成熟软件过程RUP(Rational Unified Process)进行有针对性的系统开发。在本文中将继续向读者介绍在我们的实际开发过程中如何合理利用UML(Unified Modeling Language)对BPEL4WS系统进行建模活动，由于篇幅限制，我将有关利用UML对BPEL4WS系统建模的介绍分为了三部分，本文是第一部分，在接下来的两篇文章中会介绍UML核心架构的使用问题并会给出一个简化的建模实例。 由于水平有限，在文章中不免会有错误和不足的地方，欢迎大家批评指正，在此仅希望大家在阅读完本文的内容后会对如何利用UML对BPEL4WS系统建模有一个概念上的理解，也希望能对您的工作有所帮助。

引言

本文主要介绍的有2个方面的内容；

为什么要利用UML对BPEL4WS系统进行建模。
用UML来构架BPEL4WS系统的体系结构。

（注：对于BPEL4WS的基本语法介绍以及UML的详细语言规范由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍；在文中出现的"BPEL4WS系统"与"用BPEL4WS语言开发的商业系统"同义）

回页首

正文

<一>为什么要利用UML对BPEL4WS系统进行建模

一切事情都是有因有果的，为了更好的学习如何对BPEL4WS系统建模，还是在一开始先让我们来看看我们之所以要利用UML对BPEL4WS系统进行建模的原因是什么，也就是看看用UML对BPEL4WS系统建模的重要性在哪里。

为什么要对BPEL4WS系统建模

建模是开发优秀软件的所有活动中的核心部分，其目的是把所要设计的结构和系统的行为沟通起来，并对系统的体系结构进行可视化和控制。我们对一个正在构建的BPEL4WS系统建模是为了能更好地理解它，而且对BPEL4WS系统建模还有可能为我们提供简化系统和复用组件的机会，同时我们为BPEL4WS系统建模可以更好的管理系统中潜在的风险。不成功的软件项目失败的原因各不相同，而所有成功的项目的成功原因在很多方面都是相似的。任何一个成功的软件组织有很多成功的因素，其中共同的一点就是对建模的采用。BPEL4WS系统模型是对现实商业流程的简化，BPEL4WS系统模型为我们提供了整个系统运作的蓝图。在BPEL4WS系统模型中既应该包括详细的计划，也应该包括从很高的抽象层次考虑系统的总体计划。通常来说，一个好的模型应包括那些与系统有紧密关系的主要元素，而忽略那些教松散的次要元素。每个BPEL4WS系统都可以从不同的方面用不同的模型来描述，而且每个模型都是一个在语义上闭合的系统抽象。我们所建立的模型应该既可以体现出BPEL4WS系统的结构性，强调整个系统的组织特性；同时也应该可以体现出BPEL4WS系统的行为性，即强调系统的动态方面。

也许有的开发者会问，BPEL4WS使用起来并不复杂，而且也没有复杂的数据结构和数据处理，那么我们为什么还要对BPEL4WS系统建模呢？BPEL4WS本身确实不是很复杂，但复杂的是千变万化的商业流程和商业行为，复杂的是分布在Internet上的大量的Web服务以及它们所提供的接口，我们对BPEL4WS系统建模是为了能够更好地理解我们正在开发的系统。我们通过对BPEL4WS系统建模，至少要达到以下四个目的：

建造的模型可以帮助我们按照实际情况或按照我们所需要的细化程度对系统进行可视化。
建造的模型可以详细的说明整个BPEL4WS系统的静态结构和动态行为。
建造的模型可以给出一个能指导我们构造BPEL4WS系统的模板。
建造的模型要能对我们在开发过程中做出的决策进行文档化。

可以明确地讲，由于现在的商业系统变得越来越大、流程也越来越复杂，建模的重要性也相应的就越变越大，因为我们不能仅凭想象来完整地理解一个十分复杂的商业流程系统，所以我们要通过对它建模来使我们更好的了解它。

为什么选用UML作为BPEL4WS系统的建模语言

UML(Unified Modeling Language)即统一建模语言，是一种绘制软件蓝图的标准语言，它可以贯穿于软件开发的每一个阶段。虽然UML和RUP都是Rational公司的产品，但实际上UML是独立于具体的过程的，也就是说我们也可以采用其他的软件过程，但由于UML和RUP在某些概念方面是相同的（关于结合RUP的一些内容，在上一篇文章中有所介绍），所以结合RUP使用UML对系统建模可以达到事半功倍的效果。正像UML的一位创始人说的那样："在未来的5年内，UML与RUP将变成每一个软件开发人员都应了解和掌握的技术"，所以我认为不论你使不使用它们，你都应该了解他们，因为它们是无数前辈的经验总结，站在巨人的肩膀上成长进步又何乐而不为呢。对于我们来说最重要的是当我们利用UML对BPEL4WS系统建模时，我们可以很好的描述出BPEL4WS系统的静态特性和动态特性，而且还可以体现出BPEL4WS系统本身所具有的一些特点，这正是我们所需要的。

对于软件系统，有几种建模的方法。最普通的两种方法是从算法的角度建模和从面向对象的角度建模。传统的软件开发往往是从算法的角度进行建模，所有的软件都用过程或函数作为其主要构造块。这种观点导致开发人员把精力集中在控制流程和对大的算法进行分解上。除了用这种方法建立的模型是脆弱的之外，采用这种方法没有其他本质上的害处。但当需求发生变化以及系统增长时，用这种方法建造的系统就会变得难以维护。现代的软件开发采用面向对象的角度进行建模，所有软件系统都用对象或类作为其主要构造块，而且当前的大多数程序语言、操作系统和工具在一定的方式上都是面向对象的。所以我们可以肯定地说，面向对象方法是软件开发方法的主流部分，其原因很简单，因为事实已经证明，它适合于在各种问题域中建造各种规模程度和复杂度的系统，这也就是说我们也可以采用面向对象方法来对BPEL4WS系统进行设计和开发。其实这是显而易见的，因为整个BPEL4WS系统从本质上来说完全是基于面向对象技术和组件技术的。目前业界中最好最完备的面向对象建模语言就是UML(Unified Modeling Language)了，我们利用UML可以对要构建的系统进行可视化、详述、构造和文档化，而这几个方面也正是对BPEL4WS系统建模的主要目的。所以自然而然的，UML就成为了我们最佳的选择。

学习用UML建模要注意什么

整个UML语言规范是相当复杂的，所以我们学习时一定不能贪多贪快，要一边学习一边理解，要结合着UML的特点和构成结构来学习。

首先我们要知道，虽然我们在系统开发的过程中要使用UML，但是UML是独立于过程的，我们最好把它用于以用况为驱动，以体系结构为中心，迭代及增量的过程中，这样才能最大程度的发挥出它的特长。我们在整个系统的开发过程中，UML可以完成的工作包括：可视化；详述；构造；文档化，而这些工作正是任何一个系统开发过程中（当然包括BPEL4WS系统）最重要的工作，所以我们可以把UML用于复杂的软件密集型系统。

其次，我们在学习时要牢记构成整个UML的三个要素：

UML的基本构造块。
支配这些构造块如何放置在一起的规则。
运用于整个语言的一些公共机制。

只有完全掌握了每个UML元素的用法和特点，才能在对BPEL4WS系统建模的过程中做到心中有数，临阵不慌。

<二>用UML来构架BPEL4WS系统的体系结构。

系统体系结构或许是最重要的制品，它可以驾驭我们不同的观点，并且在整个项目的生命周期内控制对系统的迭代和增量式开发。随着软件过程的不断发展，体系结构这个名词已经变得越来越流行起来，那么到底什么是体系结构呢？总的来说，我们可以把体系结构描述成是一组有关下述内容的重要决策：

整个软件系统的组织；
对组成系统的结构元素及其所提供的接口的选择；
由各个系统元素间协作所描述的行为；
将系统结构和各个系统元素组合到各个子系统中；
指导整个组织的体系结构风格，静态和动态系统元素及其它们之间的接口、协作和组成。

(注：软件体系结构不仅关心结构和行为，而且还关心用法、功能、性能、弹性、复用、可理解性、经济技术约束及其折衷，甚至还要涉及到审美的考虑)

在我们对一个复杂的系统建模时，最好用5个互连的视图来描述这个系统的体系结构。每一个视图是在一个特定的方面对系统的组织和结构进行的投影，针对不同的系统，每个视图的重要性是不同的。比如说对于一般的MIS系统来说，用况视图和设计视图是最重要的部分，相比之下，其它视图如实现视图和实施视图就显得不是至关重要的了；而对于BPEL4WS系统来说，除了用况视图和设计视图很重要外，实现视图和实施视图对于整个BPEL4WS系统建模来说是十分十分重要的，这是由于BPEL4WS系统对存在于Internet上的Web服务的依赖性所造成的，只有构建好完整详细的实现视图和实施视图，我们才能在最大的程度上保证整个BPEL4WS系统建模的完整性和可靠性，才能最大程度的减少潜在的风险。

下面简要介绍一下这5种视图的特点：

用况视图（Use case view）：--〉包含用况

用况视图实际上并没有描述软件系统的组织，而是描述了形成系统体系结构的动力。对BPEL4WS系统建模时，整个用况视图的静态方面由用况图表现；动态方面由交互图、状态图和活动图表现。对于BPEL4WS系统来说，一个完备的用况视图可以在最大程度上体现出商业用户的需求，而且可以为系统开发后期的review和测试活动提供很好的参考，也是测试用例编写的基础。

设计视图（Design view）：--〉包含类、接口、协作

这种视图主要支持系统的功能需求，即系统提供给最终用户的服务。对BPEL4WS系统建模时，整个设计视图的静态方面由类图和对象图表现；动态方面由交互图、状态图和活动图表现。对于任何系统的建模活动来说，评价建模水平的标准归根结底还是主要由设计视图体现的，这是因为开发人员正是利用这个视图来完成所有的用户功能需求，而用户所关心的恰恰就是所建立的系统是否能满足用户的所有功能需求。

进程视图（Process view）：--〉包含形成系统并发与同步机制的线程和进程。

进程视图主要是针对系统的性能、可伸缩性和系统的吞吐量。对BPEL4WS系统建模时，整个进程视图的静态和动态方面的表现与设计视图基本相同，但进程视图注重于描述线程和进程的主动类，而在BPEL4WS系统中最重要的主动类就是流程本身了（整个流程本身被抽象成主动类），所以对于流程本身的描述，包括流程进程的并发和同步机制等内容，都要在进程视图中很好的体现出来。

实现视图（Implementation）：--〉包含用于装配与发布物理系统的构件和文件。

在BPEL4WS系统中，整个实现视图的静态方面由构件图表现；动态方面由交互图、状态图和活动图表现。在构建实施视图时要多注意构件图的构建，要利用构建图来体现出BPEL4WS系统所独有的特点。(具体对构件图建模的介绍在下一篇文章中)

实施视图（Deployment view）：--〉包含了形成系统拓扑结构的节点。

在BPEL4WS系统中，我们利用实施视图来描述对组成整个物理系统的部件的分布、交付和安装。整个实施视图的静态方面由实施图表现；动态方面由交互图、状态图和活动图表现。任何一个系统最终都是要交付用户使用的，而实施视图正是系统交付使用的基础，而且BPEL4WS系统在系统发布上的特点正是由实施图来体现的。（具体对实施图建模的介绍在下一篇文章中）

以上这5种视图每一种都可以单独使用，也可以互相作用，互相交互。在BPEL4WS系统中，我们一定要把体系结构作为一个重要的建模制品，并且要使UML注重于对整个BPEL4WS系统体系结构的不同视图进行建模。

回页首

给开发者的建议

UML不仅是一种建模语言，它还包含了面向对象技术、组件技术等许多先进的软件开发技术和思想。在国外的软件公司UML基本成为了软件工程师必备的知识，也许你的工作暂时用不到UML，但了解和掌握UML对于提高一个软件开发人员的技术水平来说是颇有裨益的。国内许多公司由于公司规模以及其他一些现实的情况，不能很好的推广UML技术，往往只使用UML中的一小部分功能。很多公司在项目初期设计的时候还可以利用UML来进行设计，但往往到了项目结尾阶段就完全抛开了UML，又恢复到了以前较无序的开发状态，特别是测试用例的编写变得很不完善，直接后果就是降低了用户满意度，这是我们最不愿意看到的结果。国内软件业确实有自身的难处，但我们应该看到中国的软件行业正处于高速的发展过程中，作为一名软件开发人员，越早掌握一些新技术、新思想，不仅提高了自身的竞争力，同时对于整个国内的软件发展也贡献了自己的力量。在未来的5到10年内，中国极有可能会成为世界上最大的软件外包市场，日本、美国、欧洲的软件外包工程都会大量的发到国内，到那个时候，决定一个国内公司是否可以竞标到项目的标准除了规模以外，就只有管理和技术了，恐怕现在还很盛行的“关系”机制到时就吃不开了。总而言之，作为一名软件开发人员，一定要为自己树立较高的目标并对自己严格要求，要不断提高自身的价值，只有这样我们才能在越来越激烈的竞争中处于不败之地。

回页首

结束语

在本文中向读者简要介绍了有关利用BPEL4WS语言进行系统开发时如何利用UML(Unified Modeling Language)进行系统建模的概要介绍。在下一篇文章中，我将会介绍如何有针对性的利用UML核心架构对BPEL4WS系统进行建模的问题，UML的基础就是它的核心架构，掌握和熟练应用核心架构是重要且必要的，希望下一篇文章会对大家学习和掌握UML建模起到一定的帮助作用。

在本篇文章中，如有任何错误或者不够完善的地方请您与我联系，我的邮箱地址是：

国内邮箱： wq7961@263.net公司邮箱： wang.qiang@fujixerox.co.jp(如果用中文的话，最好发到国内信箱，谢谢)

十分期望收到您的反馈意见。

另外，由于我目前正在从事BPEL4WS语言的集成开发环境的设计和开发，如果您对这方面有什么好的建议也可以直接来信和我联系，谢谢。

回页首

参考资料

BPEL4WS语言规范 v.1.1
http://www.ibm.com/developerworks/library/ws-bpel/

UML(Unified Modeling Language)语言规范 v.1.5
http://www.omg.org/technology/documents/formal/uml.htm

RUP(Rational Unified Process)语言规范
http://www.rational.com/products/rup/index.jsp

2003 年 8 月 01 日

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
引言

在本文的前三篇文章中(商业流程开发新纪元--BPEL4WS语言介绍，第1部分：特点介绍及使用技巧提示，第2部分：如何有针对性的利用RUP来规范BPEL4WS系统开发流程，BPEL4WS语言介绍，第3部分：利用UML对BEPL4WS系统进行建模)，已经向读者介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧；在软件过程方面着重介绍了在利用BPEL4WS语言进行系统开发时如何合理利用现有成熟软件过程RUP(Rational Unified Process)进行有针对性的系统开发；在BPEL4WS系统建模方面简要介绍了在开发过程中为什么要利用UML(Unified Modeling Language)对BPEL4WS系统进行建模以及如何用UML来构架BPEL4WS系统的体系结构。在本中将向读者介绍如何有针对性的利用UML核心架构对BPEL4WS系统进行建模。希望本文的内容会对您对UML核心架构的理解有所帮助。

（注：对于BPEL4WS的基本语法介绍以及UML的详细语言规范由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍；
在文中出现的"BPEL4WS系统"与"用BPEL4WS语言开发的商业系统"同义）

正文

根据不同系统的不同性质，一些模型可能比另一些模型要重要。例如，对于数据密集型系统，表达静态设计视图的模型将占主导地位。对于图形用户接口密集型系统，静态和动态用况视图就显得相当重要。在实时系统中，动态进程视图尤为重要。而在多层分布式系统中，尤其是在BPEL4WS系统中，实现模型和实施模型相对于其它系统来说就变得更加的重要。

在利用BPEL4WS语言进行系统开发的过程中利用UML进行建模的方法和对普通的软件系统进行建模的方法大体上是相同的，但由于BPEL4WS系统本身的特点决定了只有针对性地进行建模活动才能取得更有价值的成果，再加上利用UML建模的过程实际上就是在遵循UML Specification的基础上，利用UML提供的一些核心要素对要开发的系统进行可视化、详述、构造和文档化的过程，所以我们可以针对UML的三个基本核心要素(基本构造块、规则、公共机制)来结合BPEL4WS语言的特点来有针对性地进行建模活动。而如何有针对性的利用UML核心架构对BPEL4WS系统进行建模成为了一个重要的问题，在下面的内容中将会较细致的介绍UML中主要元素的特点和如何在建模活动中有倾向性地向BPEL4WS系统靠拢。

<一>基本构造块

在UML中的基本构造块可以划分为主要的三大类，每一类又可以细分为上图所示的许多小类。对于一个小型的项目来说，也许我们只会用到这些元素的一部分，但对于一个规模较大、较复杂的项目，特别是像BPEL4WS系统这样的多层分布式系统来说，在我们建模的过程中，基本上会用到上面的每一种构造块，只是侧重点要根据项目的特点的不同而定了。在UML的构造块中，我们利用"事物"可以对BPEL4WS模型中最具代表性的成分进行抽象；利用"关系"把BPEL4WS系统中的各种相关事物结合在一起；利用"图"来聚集整个BPEL4WS系统中的相关的事物。接下来让我们来分析每一类基本构造块的特点，以及如何有针对性地利用它们对BPEL4WS系统进行建模。

<1.1>基本构造块中的4种事物：

<1.1.1>结构事物（Structural thing）：是整个UML模型中的名词。它们通常是模型的静态部分，在BPEL4WS系统中，我们可以利用结构事物来描述一些重要的概念或者物理元素，我们必须能够捕捉到整个BPEL4WS系统中存在的所有的相关的结构事物，只有在完整的系统语义的基础上，我们才可能进一步地发现和得到系统的动态特性。在利用UML建模时，我们一共可以用到7种结构事物，它们分别是：

类(Class):是对一组具有相同属性、相同操作、相同关系和相同语义的对象的描述。我们利用一个类可以实现一个或多个接口。在BPEL4WS系统中，类是最基础的系统构造部分，值得我们多加注意的是我们应该把外部服务抽象成类的概念来进行建模活动，这在后面的类图介绍中会进行解释。

接口(Interface):是描述了一个类或构件的一个服务的操作集合。因此，接口描述元素的外部可见行为。一个接口可以描述一个类或构件的全部行为或部分行为。值得我们注意的是，我们只是利用接口定义了一组操作的描述（即特征标记），而不是操作的实现，所有具体的实现都由类或者构件来完成。在BPEL4WS系统中，如果外部的Web服务提供给我们的服务是"暗盒操作"，也就是我们不知道操作的具体内部流程，我们就可以把这些操作抽象到某个接口中，而这些接口由那些抽象成类的Web服务来实现。

协作(Collaboration):定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他一些相关元素构成的一个群体，这些协作行为从范围上来说要大于所有元素的各自行为的总和。因此，协作是有结构、行为和维度的。要注意的一点是，一个给定的类可以参与几个协作，而这些协作表现了系统构成模式的实现。我们在对BPEL4WS系统建模的时候，在抽象出系统相应的用况之后，就要用协作来实现这些用况，用况就好比是一篇论文的前言，告诉了我们这篇论文是讲什么的，而协作就是具体的内容。

用况(Use case):是对一组动作序列的描述，系统执行这些动作序列将产生一个对某个特定的参与者有特定价值的结果。我们利用用况来对BPEL4WS模型中的行为事物结构化，我们通常通过协作来实现某一个用况。如果想建立一个完善的BPEL4WS系统模型，用况可以说是至关重要的部分，因为所有的用户需求我们都要在用况中体现出来，可以说用况是开发人员与用户进行交互的窗户，在系统的测试阶段，测试用例的创建也要以用况为基础，不论是BPEL4WS系统还是其他系统，用户满意度才是判断这个系统是否成功的最重要的因素。

主动类(Active class):是这样的一种特殊的类，其对象至少拥有一个进程或线程，并且它能够启动控制活动。主动类的对象所描述的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的。由于BPEL4WS流程本身就具有主动类的特征（每一个流程拥有自己的进程，并能自动启动控制活动），所以我们可以把流程本身抽象成主动类。

构件(Component):是整个系统中物理的、可替代的部件，它遵循且提供一组接口的实现。在一个系统中，你将遇到不同类型的部署构件，如 C O M +构件和Java Beans，以及在开发过程中所产生的制品构件，如源代码文件。通常构件是一个描述了一些逻辑元素（如类、接口和协作）的物理包。对于构件在BPEL4WS系统中的使用，我们可以把每一个为我们提供Web服务的服务站点抽象成是一个特殊的"构件"，具体介绍在构件图的介绍中说明。

节点(Node):是在运行时存在的物理元素，它表示了一种可计算的资源，它通常至少有一些记忆能力和处理能力。一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点。在一般的系统建模时，如在C/S模式的时候，节点往往就是客户机和服务器；而在N-Tier模式时，也就是多层架构时，除了客户机和服务器外，还要将应用服务器，也就是中间层建模为相应的节点。在BPEL4WS系统中，比较特殊的一点是我们应该将一个服务提供商抽象成是一个节点，在这个特殊的节点中提供了一系列的Web服务，更详细的内容在实施图的说明中介绍。

<1.1.2>行为事物（Behavioral thing）：是UML模型的动态部分。我们可以把它们看作是模型中的动词，它们描述了系统中存在的行为动作。在利用UML对BPEL4WS系统进行建模时，共有两类主要的行为事物可以供我们使用：

交互(Interaction):是这样一种行为，它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起行为）和链（对象间的连接）。

状态机(state machine):是这样一种行为，它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。

在这里，由于篇幅关系，只介绍了行为事务的基本概念，在我们对BPEL4WS系统建模的时候，对于行为事务的建模是体现在相应的系统图模型中，这在下面的图模型说明中会有介绍。

<1.1.3>分组事物（Group thing）：是UML模型的组织部分。它们一般是由整体系统分解下来的小的功能集合。在所有的分组事物中，最主要的分组事物是包，而在对BPEL4WS系统建模时我们利用最多的也是包。

包(Package):是把元素组织成组的机制，这种机制具有多种用途。结构事物、行为事物甚至其他的分组事物都可以放进包内。包不像构件（仅在运行时存在），它纯粹是概念上的（即它仅在开发时存在）。在BPEL4WS系统中，包的使用比较自由，我们可以根据自己的需要划分系统中的各个部分，例如可以按外部Web服务的功能来划分这些Web服务。

(注：包是用来组织UML模型的基本分组事物。它也有变体，如框架、模型和子系统等（它们是包的不同种类）。在JAVA中已经直接支持了包的概念，而在C#中虽然没有明确提出包的概念，但是C#中的命名空间概念实际上与包的概念是一致的)

<1.1.4>注释事物（Annotation thing）：是UML模型的解释部分。我们可以用注释事物来描述、说明和标注整个UML模型中的任何元素。有一种最主要的注释事物，我们称为注解。

注解(Note)：是一个依附于一个元素或一组元素之上，对它进行约束或解释的简单符号。注解可能是大家最容易忽视的部分，当我们编码的时候，程序注释的重要性我想大家都知道，而当我们对BPEL4WS系统或其他系统建模的时候，确容易忘掉为我们建立的系统模型元素加上详细的注释，对一个中小型系统来说，也许并不会有太大的危害，而对于一个复杂的系统模型来说，也许一时的偷懒会造成以后致命的潜伏的错误，所以宁可在建模时放慢进度也要争取建立一个完备的系统模型，为以后的review和测试阶段打下良好的基础。

<1.2>基本构造块中的4种关系：

依赖（Dependency）：
是两个事物之间的一种语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在BPEL4WS系统中，我们要善于挖掘系统中存在的依赖关系，如在BPEL4WS系统中，外部Web服务之间就可能存在着依赖关系。

关联（Association）：
是一种结构关系，我们用它来描述一组链，链是对象之间的连接。不论是对BPEL4WS系统还是其他系统来说，关联关系恐怕是我们在建模时用到的最多的一种关系，系统元素之间的关系如果不能明显的由其他三类关系来表示，都可以抽象为关联关系。

(注：聚合是一种特殊类型的关联，它描述了整体和部分间的结构关系)

泛化（Generalization）：
是一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象，也就是我们在面向对象学中常常提起的继承。用这种方法，子元素共享了父元素的结构和行为。在BPEL4WS系统中，泛化关系的使用并没有什么特殊的地方，只要注意能清楚明了地刻画出系统相关元素之间所存在的继承关系就行了。

实现（Realization）：
是UML元素之间的语义关系，其中的一个元素制定了由另一个元素保证执行的契约。在图形上，我们可以把实现看作是泛化和依赖关系两种图形的结合体。

在BPEL4WS系统中，一般来说，我们会在两个地方需要使用实现关系，一是用在接口和实现它们的类或构件之间，另一种是用在用况和实现它们的协作之间，这些地方都是具有BPEL4WS系统特性的地方，大家在建模的时候要多加注意。

<1.3>基本构造块中的9种图：

类图（Class diagram）：展现了一组对象、接口、协作和它们之间的关系。
在对面向对象系统的建模中所建立的最常见的图就是类图。我们可以用类图来给出系统的静态设计视图，我们可以通过主动类的类图给出整个系统的静态进程视图。类图恐怕是大家最熟悉使用的一种图形了，因为自从有了面向对象的理论以后，类和类图就成为最基础的面向对象理论。在对BPEL4WS系统建模的时候，开始时最困难的部分可能就是识别系统中到底有哪些相关对象，也就是抽象出有哪些类，对于识别对象并抽象出类的方法，由于篇幅关系在这里就不详细说了，大家可以参看清华大学出版的一本很有名的书《面向对象的分析》（邵维忠，杨芙清），很实用的教材。在这里要提醒大家注意的是，在BPEL4WS系统中，应该把所有的外部Web服务抽象成类（用版类Stereotype扩展过的），而对于流程本身，也应该抽象成类的概念，这样所有BPEL4WS系统的元素都被抽象成类这种有固定形态特点的事物，这样就为以后的系统动态分析打好了基础。

对象图（Object diagram）：展现了一组对象以及它们之间的关系。
对象图描述了在类图中所建立的事物的实例的静态快照。虽然对象图也给出了系统的静态设计视图或者静态进程视图，但它们都是从真实的或原型案例的角度建立起来的。对于BPEL4WS系统的建模来说，对象图并不是重点，因为过细致的对象图会降低系统模型的抽象程度，这是不利于我们从更高的层次理解整个系统的架构和运作，但有的时候对象图也是必不可少的，特别是当我们要表示出位于某个确定状态的类对象之间的关系时。

用况图（Use case diagram）：展现了一组用况、参与者（一种特殊的类，可以为用户或者是别的系统）及其它们之间的关系。
我们通常利用用况图给出整个系统的静态用况视图。这些图对于系统的行为进行组织和建模是非常重要的。值得注意的是，在用况图中，我们应该很好地利用用况之间的泛化关系，也就是继承关系，这样可以更清晰地把一个较复杂的商业用况划分为几个较简单的用况（父用况和子用况），这对于我们在BPEL4WS系统中理解一些复杂的商业行为很有好处。

顺序图（Sequence diagram）：
在系统中，顺序图是一种强调消息的时间顺序的交互图。对于BPEL4WS系统的建模来说，顺序图应该说是最重要的一种图，虽然顺序图和协作图是同构的，也就是说是可互相转化的，但由于顺序图强调了时间上的概念，这与一个实际商业流程的运作是完全一致的，再加上BPEL4WS系统中所调用的各种外部Web服务在顺序图中可以很好的、形象的表现出来，所以当我们要对具体的商业流程建模的时候，顺序图是我们最好的选择。

协作图（Collaboration diagram）：
协作图也是一种交互图，不过它主要强调了收发消息的对象的结构组织的交互图。对于一般的系统建模（如MIS系统）来说，协作图与顺序图是一样重要的，而对于BPEL4WS系统来说，由于我们所关心的商业流程是有时间顺序的，所以我们应该先考虑创建完备的顺序图，对于一些用顺序图表示不太适合的交互（如涉及到复杂的消息传递），我们可以用协作图将其表示出来。

(注：在这里，我要对交互图作一些补充说明，首先，顺序图和协作图都是交互图，而且顺序图和协作图是同构的，这也就意味着它们是可以相互转换的。另外一点需要注意的事，我们在系统建模的时候应该使交互图专注于整个系统的动态视图，这是因为UML中的交互图本质上展现了一种交互，而这种交互是由一组对象和它们之间的关系组成的，包括了在它们之间可能发送的消息)

状态图（Statement diagram）：展现了一个状态机，它由状态、转换、事件和活动组成。
状态图也主要专注于整个系统的动态视图，系统的状态图对于接口，类或协作的行为建模尤为重要，而且它还强调了对象行为的时间顺序，这一点是非常有助于对反应式系统建模的，也就是说对BPEL4WS系统建模来说是非常重要的（因为BPEL4WS系统实际上也带有一部分反应式系统的特点）。在为BPEL4WS系统所建立的模型中，状态图最重要的用处就是为流程本身的状态以及外部Web服务的状态建模。随着流程的运行，系统各个部分的状态可能都会发生变化，我们一定要能捕捉到这些变化，并把这些变化体现在相应的状态图中。

活动图（Activity diagram）：是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。
活动图在专注于系统的动态视图的同时，强调了对象间的控制流程，这对系统的功能建模特别的重要。在利用活动图对BPEL4WS系统建模的时候我们要注意，最好能把商业流程中发生的一系列商业事件（如客户身份认证，信用卡号认证等）以一一对应的关系对应到流程的活动图中的每一个活动；如果有必要的话，再对每一个活动进行更深层次的分析，构建出每一个活动本身的交互图和活动图。

构件图（Component diagram）：展现了一组构件之间的组织和依赖。
对于构件图，我们首先要知道的是构件图不能反映出系统的动态特性，构件图专注于描述系统的静态实现视图。在我们对任何一个系统建模时（当然包括BPEL4WS系统），构件图不可避免的要与类图相关联，因此我们通常把构件映射成一个或多个类、接口或协作。对于一般的系统来说，大部分的构件都存放在本地系统上，我们可以从大体上把这些构件分为两类，一类是"内部构件"，也就是自己开发的构件；另一类是"外部导入构件"，也就是通常所说的第三方构件，而对于BPEL4WS系统来说，由于它本身的特殊性（对外部Web服务的依赖性）决定了我们在建模时一定要用构件图完整地体现出整个流程所涉及到的所有的外部Web服务以及本地提供的Web服务，我们可以把每一个为我们提供Web服务的服务站点抽象成是一个"构件"，而在这个特殊的"构件"中为我们提供了一系列的Web服务功能。

实施图（Deployment diagram）：展现了对运行时处理节点以及其中的构件的配置。
通过构造系统的实施图，我们就可以构造出整个系统体系结构的静态实施视图。在我们对BPEL4WS系统建模的时候，实施图往往都要与构件图相关，通常在系统的每个节点中都包含一个或多个构件。我们可以扩展实施图中节点的概念，在扩展出的新的节点的概念中，一个节点不一定就是一个处理节点，我们可以将一个服务提供商抽象成是一个节点，而一个服务提供商可能会为我们提供几种不同的Web服务（即几个不同的服务站点），那这些服务站点就可以被抽象为"构件"，这样就可以很好的与构件图结合起来对BPEL4WS系统建模。

(注： 在对BPEL4WS系统建模时，并不限定仅使用这9种图，但这9种图在实际应用中是最常用也是最方便使用的)

<二>规则

在对BPEL4WS系统建模的时候，我们不能简单地把UML构造块按随机的方式放在一起。像任何语言一样，UML有它自身的一套规则，这些规则描述了一个结构良好的模型看起来应该像什么。对于为BPEL4WS系统所构建的模型，我们要求这个模型应该在语义上是前后一致的，并且与所有的相关模型协调一致。在建模的时候，UML有用于描述如下事物的语义规则：

命　　名：为事物、关系和图起名。

范　　围：给一个名称以特定含义的语境。

可见性：怎样让其他人使用或看见名称。

完整性：事物如何正确、一致地相互联系。

执　　行：运行或模拟动态模型的含义是什么。

值得注意的一点是，当我们对BPEL4WS系统进行建模时除了要建造一些结构良好的模型以外，我们在系统的开发期间所建造的模型往往需要发展变化，并可以由许多人员（所有的项目涉及人即Stakeholders）以不同的方式、在不同的时间进行观察。由于这个原因，下述的情况是常见的，即我们不仅要建造一些结构良好的模型，也要建造一些这样的临时模型：

省　　　略：隐藏某些元素以简化视图。

不完全性：可以遗漏某些的元素。

不一致性：不保证模型的完整性。

在BPEL4WS系统开发的整个生命期内，随着系统细节的展开和变动，不可避免地要出现这些不太规范的模型。但我们应该时刻牢记，我们的任务是专注于BPEL4WS系统中最重要的分析、设计和实现，而为了解决这些重要问题，将促使我们不断地修改我们所建立的模型、完善我们所建立的模型，这样随着时间的推移和系统设计的深入，我们为BPEL4WS系统所建立的模型将具有更好的结构。

<三>公共机制

在UML中有4种贯穿整个语言且一致应用的公共机制，因此使得UML变得较为简单；而特别值得我们注意的是，对于BPEL4WS系统的建模来说，这些机制显得尤为的重要，如果没有这些公共机制，我们是不可能构建出语义上完备的BPEL4WS系统的。这4种公共机制分别是：

<3.17>详述：在建模的过程中，我们利用UML的图形表示发来对BPEL4WS系统进行可视化，利用UML的详述来描述BPEL4WS系统的细节问题。在文章前面提到的注释的问题实际上就是详述机制的问题，一个完备的BPEL4WS系统不仅要包括完整的系统模型元素，还要有详细的详述才能称得上是一个健壮的系统。

<3.2>修饰：UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上以扩展其含义。在BPEL4WS系统中，我们可以较自由的对系统中的各个元素进行修饰以扩充其含义，但要注意要保证这种扩充是在受控制的范围中。

<3.3>通用划分：在对BPEL4WS系统建模时，我们可以采用两种通用划分的手段，一种是对类和对象的划分（类是一个抽象，而对象是这种抽象的一个具体形式）；第二种是对接口和实现的分离（接口声明了一个契约，而实现则表示了对该契约的具体实施，它负责如实地实现接口的完整语义）。

<3.4>扩展机制：扩展机制是对已有的UML语义按不同系统的特点合理地进行扩展。

UML扩展机制包括：

<3.4.1>构造型（Stereo type）：
我们在对BPEL4WS系统建模的时候，会发现现有的UML构造块不能完整无歧义地表示出BPEL4WS系统中的每一元素，因此我们可以利用构造型来扩展UML的词汇，我们可以利用它来创造新的构造块，这个新创造的构造块既可以从现有的构造块派生，又专门针对我们要解决的问题。

<3.4.2>标记值（Tagged value）：
利用标记值，我们可以扩展UML构造块的特性，我们可以根据我们的需要来创建详述元素的新元素。

<3.4.3>约束（Constraint）：
如果我们需要对UML构造块的语义进行扩展，我们就可以使用约束机制，这种机制使我们可以增加新的规则和修改现有的规则。

(注：由于BPEL4WS系统本身所固有的特点，决定了在我们对其进行建模时不得不对UML中的一些部分进行扩展，但有一点我们必须要注意，那就是我们一定要让我们对UML所作出的扩展保持在我们的控制范围内，简单的说就是我们只可以以受控的方式来进行扩展，而不能任意地、无限制地进行扩展，我们必须保证我们利用UML扩展机制对BPEL4WS系统所作的建模活动是可理解、可控制的，如果任意地扩展，就会使我们在对系统进行建模的过程中偏离利用UML建模的真正目的--信息交流)

给开发者的建议

"不积跬步无以至千里"，学习掌握UML的过程是一个漫长的过程，有时还会觉得有些乏味，但当你真真掌握了它并灵活的运用它在你的工作中的时候，你就会发现你不曾想到的乐趣。现在UML2.0已经问世了，而BPEL4WS语言也有了新的版本，它们都添加了很多的新的东西，也去掉了一些旧的东西，但我相信本文的内容对于新的Specification来说也是同样适用的，对于新技术新知识我觉得我们应该抱着一种积极的态度去学习和掌握它们，而不应该处于一种被动的状态，越早行动起来就能越早的收到回报，千万不要犹豫不决，就像《谁偷了我的奶酪》中说的那样，让我们都作一只敢于迎接变化的小老鼠吧！

结束语

在本文中向读者简要介绍了有关如何有针对性的利用UML核心架构对BPEL4WS系统进行建模的问题。在下一篇文章中，我将会在简要的介绍一些有关商业系统和商业流程的特点之后，为大家举一个实际的例子(贯穿分析，设计和实现)来阐明有关利用BPEL4WS进行系统开发和商业流程架构时应注意的细节问题，例子可能不长，但会涵盖UML中最重要的部分。

参考资料

BPEL4WS语言规范 v.1.1
http://www.ibm.com/developerworks/library/ws-bpel/

UML(Unified Modeling Language)语言规范 v.1.5
http://www.omg.org/technology/documents/formal/uml.htm

RUP(Rational Unified Process)语言规范
http://www.rational.com/products/rup/index.jsp