XPDL与WS-BPEL的比较之一：规范发展篇

WfMC是国际工作流管理联盟的简称，目前业界习惯上以WfMC代替了该组织制定的XPDL、工作流参考模型等系列标准，也许这个系列称为WfMC与BPEL的对比更“悦耳”。

　　最早的工作流标准组织为国际工作流管理联盟WfMC，该联盟于1993年发布了工作流参考模型以及5类工作流标准接口。截至到2007年，业界已经有10+工作流标准组织，共计7+工作流参考模型，参考模型的文档页数也由最初的40页发展到目前平均的150页。

　　工作流标准发展概览图：

　　各个工作流标准组织的宗旨、制定的工作流相关标准和在工作流领域的最新进展：

组织名称	宗旨	工作流相关标准	目前的工作
WfMC	围绕BPM生命周期建立标准	Workflow Reference Model、 XPDL 、Wf-XML、ASAP	发展XPDL；发展ASAP并提交到OASIS组织。
OASIS	以XML为核心的各种标准，主要批准第三方的标准。	ebXML、BPEL	发展ebXML组件、ASAP等； 未来可能接受BPEL4People和WS-HumanTask等规范。
OMG	MDA、UML、CORBA	BPMN、BPDM	在业务流程模型之上生成可运行的代码
W3C	在TCP/IP HTTP之上建立程序可互操作的标准	WS-CDL、工作流所依赖的基础标准：SOAP、WSDL、XML等

 

WS-BPEL的发展进程：
2002年8月，IBM和微软联合已有的业务流程语言WSFL和XLang发布了BPEL4WS 1.0。
2003年3月，发布BPEL4WS 1.1，并正式提交给OASIS组织。
2005年底，BPEL4People白皮书首次公布。
2007年4月，该标准的2.0版本被OASIS正式批准，并重新命名为WS-BPEL 2.0。
2007年8月，BPEL4People 1.0和WS-HumanTask1.0草案发布，尚未提交给OASIS。

相比BPEL4WS,WS-BPEL2.0新增加的内容包括：
1.使用Xpath参数绑定增强了数据操纵能力。
2.可使用XSLT增强数据转换能力。
3.增加了新的节点类型：forEach、repeatUntil以及ExtensionActivity。
4.增强了错误处理：可在catch和rethrow中进行细粒度控制。高级的异常处理引入了终止处理。
5.允许本地伙伴链接，以支持高级的操作。
6.语法的提升。将"switch"修改为"if-elseif-else"，将"terminate"修改为"exit"等。

WfMC的发展进程：
1993年，WfMC发布了工作流参考模型以及5类工作流标准接口。
1998年11月，发布了WPDL(XPDL的前身)。
2002年10月，发布了XPDL1.0。
2005年10月，发布了XPDL2.0。
目前XPDL2.1正在制定，主要内容为增强与BPMN 1.1的兼容性，包括远程子流程节点的URL标识、协作单元的图形化信息、只读相关数据和仿真结果等系列内容。其进度表为：
2007-10-12，确认被提议的变更。
2007-11-15，确认BPMN1.1变更要目。
2007-12-15，起草供内部讨论的规范草案。
2008-01-15，更新并公布草案。
2008-02-20，为最终的XPDL2.1规范投票。

 

文章评论：

回复人: abird　 2008-02-03 17:44:40

留言限制在200字内，只好分为2次贴。顺序有误，先看后面的，再看前面的。 链接：http://www.blogjava.net/zhaobin/archive/2008/01/01/171982.html

回复人: abird　 2008-02-03 17:42:43

我非常赞同楼主的观点，目前我们正在做一个关于应用服务的标准，其中有流程服务标准部分，我们有意向参考WfMC的引擎接口，定义流程服务标准。 我有一个帖子，烦请楼主看看，提提意见，谢谢。 http://www.blogjava.net/zhaobin/archive/2008/01/01/171982.html 顺祝：新年快乐！

回复人: abird　 2008-02-03 17:42:34

看了James Zhang的关于XPDL和BPEL标准分析的这个系列文章，非常有感触，感谢James Zhang有如此精辟的分析。 不知道James Zhang能否看到这个留言，但还是要请教一下楼主的观点，关于“在引擎接口方面”，有多种多样的实现，这其实倒也无妨的。因为本身WfMC的引擎接口是按照C语言的哲学设计的，离现在的IOC/AOP等理念差远了，个人认为也只能作为功能性参考。

评论

1 楼 jmszhang 2008-02-11  

1.WfMC的Interface2/3是按照C语言的结构体等特点设计的，不会考虑Java面向对象的特点。
小例子：规范接口很多参数是数组式的，如果是Java语言实现，换成List、Iterator或者自定义的工作流对象多方便；很简单的例子，如果工作流产品设计的API没考虑到类似Java面向对象的特点，很多API的返回结果是数组，在Java Doc里说明第几个元素表示工作流对象的什么属性，做实际工作流开发的人用起来很麻烦。

2.WfMC接口里最常用的接口是connect和disconnect，如何和现在的面向方面的编程(AOP)结合。譬如用Spring里HibernateTemplate支持；同样如何解决工作流事务与应用事务如何统一进行管理，更多的QoS方面的考虑、配置方法的考虑。完全可以参照hibernate框架的处理。


看过标准草稿，很棒，但俺没有参与你们的工作，只能站在“领导者的角度”发几句感慨：
1.这个东东更多的需要考虑厂商利益和执行者利益吧，能顺便提高电子政务的业务效率就更好了。
2.听同事说IBM弃权（反对）JBI原因之一是因为JBI标准制定的太详尽了，实现者没有可挖掘的厂商特色而言。
3.BPEL2.0标准过程、组织过程非常详尽，上百家国际厂商投票，就没有咱们中国人呢。。