平常都会收到mail，讨论工作流和BPEL技术问题，但很多人的问题仅仅是“请问现在什么工作流产品比较好”，这样的问题我一般就没有回复了，
因为的确不好回答，而且这样问的人也太多了。但来的mail中也有问的问题非常不错的（其中包括部分老总级管理人员的问题），下面这个就是
HW
的一个人的来信交流，为了privacy起见，删掉了一部分内容。
1
、
HW
您好：我是工作流方面的兴趣爱好者，当然也只是一个新手，请问BPEL有没有什么比较好的全面的文章推荐？（除了BPEL2.0的规范外）还有就是我想找一个开源项目进行研究，你觉得activeBPEL怎么样？可以推荐一下吗?
HongSoft
您好！BPEL虽然也发展了好多年了，现在使用也开始多了起来，但目前的确没有什么比较全面的文章。开源项目方面，我也跟踪了很多BPEL项目，activeBPEL我也看了很久，目前不看好它。现在BPEL方面我在全力使用jBPM_BPEL项目。应该说jboss旗下的几个项目发展都还不错，hibernate/jboss seam等，jbpm现在也被spring纳入支持列表中。
2
、
HW
您好：非常感谢您的回信，据我所知现在工业界（如IBM,Microsoft,BEA, Oracle等）都非常推崇BPEL，我想问一下你觉得这个语言是否真的很有潜力成为工业界中业务集成方面的标准语言？那WS-CDL这项标准你怎么看待它？会广泛的被用到吗？还有就是关于activeBPEL，能否帮忙讲解一下它有什么缺点啊？相反jBPM_BPEL它有哪方面的优点？>是否有分布式工作流技术的项目啊，（个人感觉一个集中引擎总会产生一些效率之类的瓶颈问题）？是这样的，我们在考虑能否把工作流技术运用到电信业务的集成系统中去，电信业务对系统容量，实时性和稳定性方面要求非常高，读了您的一些文章，感觉你在这方面经验非常丰富，所以向你请教了，问了这么多问题，呵呵，假如对口的话，能够进行一些合作最好了，还有就是不知道你现在是否听说过IBM及Microsoft都在推SOA，你他们推的产品和jBPM_BPEL是否有些竞争关系？。谢谢了！！打扰了！呵呵
HongSoft
您好：
1
） WS-CDL的问题
CDL的全拼是Choreography Description Language，顾名思义它是用来描述Choreography的。它和BPEL的区别是：a)CDL提供一个在所有的参与者间交换的形式化描述，BPEL提供的则是本参与者对外的形式化描述定义；b)CDL提供一个全局的消息交换协议。
而BPEL是描述“我和其他人”通信的消息交换协议。理论上看CDL比BPEL更好，但实际上它有2个缺陷：a)业务集成需求的产生，是因为工业界中已经存在的很多的legacy系统，这些系统已经按它自身的业务规则，实现了自己的功能；在这样的情况下，突然安插一个Choreography进来，必然对legacy系统的实现和稳定性产生非常大的影响，这个是业务集成领域应该避免的。b)BPEL从工业界产生，被世界各大公司支持；而CDL的时间和支持力度，则明显不足。
从上面的比较和目前工业界的实际情况看，我认为BPEL肯定会成为工业界中业务集成方面的标准语言。
2
） BPEL的问题
activeBPEL和jbpmBPEL的比较，应该说可以从很多方面来看。从系统结构，技术实现等技术角度来看，activeBPEL比jbpmBPEL要差；jbpmBPEL在jboss旗下，它的技术实力要可靠，后续支持也要可靠；active本身是家商业公司，担心它的开源程度和信心不够...等等。
3
） 工作流的问题
我们用Shark和jBPM就已经做过分布式工作流技术的项目，项目有用到电信的故障运维业务中去，也有用到700W用户的网站项目中去。当然是否用分布式工作流技术，还需要具体分析。IBM及Microsoft都在推SOA，这个应该说和所有的BPEL产品都有一定的竞争关系，但我认为更大的是合作关系。SOA是套架构，我们要做的BPEL产品只是这个体系中的一个组成。IBM及Microsoft都有太多自己特性的东西是客户不一定想要的，比如对数据库的指定，在电信领域指定用DB2或者SQL Server就不太可能。在这样的情况下，我们可以理解为IBM及Microsoft帮我们铺路，我们在最少投入的情况下，力求达到最大的产出。
我说的几点是我个人理解，不知道能否让您明白。 希望多交流。
3
、
HW
您好：非常感谢您的回复，考虑到电信业务的系统容量，实时性方面的要求，我们对分布式的工作流很感兴趣，想具体了解一下分布式工作流技术如何运用到业务集成，呵呵，准确的说应该是基于BPEL的分布式引擎之类的东东（因为这边的业务集成主要涉及到如何灵活的快捷的进行业务组合，说工作流可能不是很准确，呵呵），能否详细讲解一下分布式工作流引擎的一些工作原理之类的？呵呵。谢谢了。说白了就是希望利用已有的各种service的能力，加快业务的开发和部署时间（web service是一个不错的选择，但目前为止性能方面还是个比较大的问题，但考虑到各大IT厂商对其的关注度和投入，基本上也是我们非常重视的一个选择），同时又希望保证系统的各种性能，主要还是系统容量和实时性。希望能够加强交流，合适的话能够进行一些合作最好，呵呵。期待您的回复。打扰了！
HongSoft
您好：您说到“分布式工作流引擎的一些工作原理”，这里分为2类：
1
） 非BPEL类： 就是按WFMC的标准，架构的系统为 一个工作流执行服务=多个工作流引擎，这个是标准实现，每个引擎的具体架设方法是不同的。
2
） BPEL类 ：这个方法本来就是分布式的，基本是强制性的，不需要我们自己去考虑。
您说到的“加快业务的开发和部署时间”是个比较大的问题，具体可以参考一下我做的smart系统，基本上把开发时间降到了最低，但有一定的局限性；其他的方法也可以一起讨论，和和。
4
、
HW
您好：不是很明白您说BPEL这个方法本来就是分布式的。。。
可能大家对分布式的理解不一样吧？由BPEL所组合的各种service由于是统一的web service接口，天生就是分布式的，但所有的控制逻辑都停留在BPEL引擎上，在这种情况下，我们担心会产生瓶颈，或许在企业内部的系统集成方面不会出现这种问题，但象电信业务，如短消息，预付费这种本身对性能要求非常高的情况下是否会出现瓶颈？呵呵。对BPEL这块接触的还不是很深入，呵呵，打扰了。
HongSoft
您好：在BPEL中，service可以按coordination方式组合，在这个方式下，BPEL引擎一般不只一个，而是多个BPEL引擎的协同。一般来说是按功能进行分解为1，2，3号引擎（这三个引擎的功能是不同业务的实现）；然后如果3号的负载特别重，可以分为3.1和3.2号子引擎（这两个引擎的功能是同一个业务的实现）。
电信企业内部的系统集成我是做过的，比如故障运维。而您说的电信业务比如短信这样的对性能要求非常高的系统下用工作流引擎，我也是做过的。对后者，我们是改造了jBPM引擎，添加了自己业务的activity，然后用图形的形式表达出来，业务人员可以用图形化的方式来新建/修改业务；发布自己的流程定义后，业务就能自动执行了。不过我们是在
某
SP
内部使用，而你们可能是需要对应为非常多个的SP，负载要比我们做的业务重一些。我们在高峰期每秒60个流程Instance被create，平均起来每秒20-30个流程Instance。这个系统现在是在稳定的运行中。 Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1069051