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

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/