对BPEL的思考和评论
让我们近距离看一下上述过程的控制流程。这三个服务调用一起揭示了BPEL语言的关键动机，即简化异步服务交互的处理。在客户侧，客户端软件发出一条请求消息后就会被阻塞，直到收到该服务调用的响应消息。这就是IN-OUT消息交换模式。假设服务绑定使用SOAP over HTTP，这意味着该HTTP请求在响应通过相同的TCP/IP连接发出之前都应该被阻塞。同时，在另一侧过程自己也要等待提供商来执行submitQuote回调。
所有的这些在企业服务总线（ESB)环境中都有很大的意义。ESB的思想是：多个组件按标准方式进行连接，然后通过总线与其他组件进行通信。总线上交换的消息也是标准的（通常基于WSDL/XML）。一组适配器充当协议（例如SOAP over HTTP、email、FTP、RMI）和总线之间的网关。
WS-BPEL也是基于WSDL的，自然能绑定到基于XML的技术（如Web服务）。
此外，企业应用也可以被连接到服务总线上。一旦任何东西在总线上都可作为一个服务使用，就像与ESB的交互也是基于WSDL的一样，BPEL因其技术基础是WSDL而显得意义非凡。因此，ESB是BPEL引擎理想的栖息地。
ESB主要关注在基于XML的服务之间交换基于XML的消息。BPEL从来没有脱离XML文档。XPath一般用于剪贴输入文档的片段，然后将之保存到过程变量中。被调用的服务、被暴露的服务和过程变量都是以XML为基础的。执行逻辑也直接用XML表示。在某种程度上这是个优势，因为无需在XML信息结构和编程语言对象之间进行转换。对于复杂文档和对象结构，这种转换从来都不是透明和自动的，需要进行开发和运行时性能调优。
BPEL复杂的关联能力使之可以很方便地使用现有消息交换而无需任何修改。不用将过程实例ID放入消息或上下文的头部，BPEL引擎可以根据交换文档中的任何信息片段完成关联操作。这种在每一个文档交换中标识数据项和它们与其他文档交换匹配的方法可以非常灵活。这非常有用，因为在很多集成场景中你无权控制交换文档所用的通信协议。
但与业务过程管理（BPM）的联系从何谈起呢？从BPM建模者的角度看，这种关联是有疑问的。我唯一找到的现实联系是基于良好的市场营销而非特性。对于BPM建模者来说，BPEL缺少了几个重要的基本特性。但是当你在一个你无法控制和哪个伙伴进行文档交换的ESB环境中用它编写新服务的时候，BPEL（即使不包括扩展）是完备的。因此，就像Maserati和Hummer（译者：两种汽车品牌），喜好与否的关键在于你如何用它。
我能发现的唯一关联是BPEL过程可以用图表示，以及语言支持等待状态。这意味着某些由业务分析师创建的过程模型可以被转换成BPEL过程。但是这种方法有两个主要的局限性。第一，业务分析师被假定为非技术人员。所以，分析模型中的活动与现有Web服务相对应的机会非常少（意思是：不存在）。第二个问题是BPEL是块（block）结构。分析模型通常是以图为基础的。因此，一般说来，不加修改的把分析图转换成BPEL可执行过程是不可能的。这也是BPMN与BPEL难以映射，以及局限性如此之多的原因。
使用BPEL for BPM的最突出的矛盾在于：分析员被假定为不懂技术，而BPEL过程中的活动最终对应到Web服务调用。此外，BPEL过程的块结构天性对于建模也有太多的限制。分析员需要自由地画出方块和箭头，它总是产生一个图结构和任意循环（arbitrary cycles）。BPEL过程并没有变迁的概念。相反，一个BPEL过程是一个组合结构，其优异活动是一个顺序活动（sequence）。这个顺序活动包括一个嵌套的活动序列。其中一些是基本（或原子）活动，而另一些是复杂活动。复杂活动又会包含一个嵌套的活动序列。通过好的工具，这些自上而下的活动可以很方便地被用来创建一个BPEL过程。但是将一个分析模型映射到一个BPEL过程则是完全不同的事情，并且很难说这种不同很小。
使用BPEL for BPM的另外一个问题是BPEL有限的数据处理能力。从XML文档中提取内容片段是你在服务编制中最需要的功能。但对于BPM来说，过程步骤之间通常需要完成大量的数据处理。XPath和其他的基于XML的转换技术显然是不够的。
如果你是打算使用BPEL for BPM的架构师，你应该扪心自问一下是否想让核心业务数据出现在ESB中。在IT行业从存储过程转移到如JEE这样的企业技术过程中，对构建数据在“云中”的新应用的管理更方便了。BPEL引擎需要维护的数据和领域模型（如顾客、客户、提供商等等）有关。这些领域数据通常存储在IT基础设施的关系数据库中。核心业务过程中的信息必须能够很方便地链接到关系数据库中的领域数据。假如你的JAVA应用需要了解一个文档的客户引用怎么办？你想将那个文档作为过程参数传给BPEL引擎，然后使用XPATH从那个XML文档中抽取引用吗？这就暗示这个信息应该包含数据库的领域模型中，而不是在BPEL引擎中。BPEL并没有阻止你把这种信息存储在领域模型数据库中，但是它为这种做法添加了困难。你可能必须实现一个特殊的Web服务来获取存储在领域模型中的客户引用。所以，BPEL可能会很容易让你的领域模型信息支离破碎。要小心。
David的BPEL反例（Case against BPEL），Joe McKendrick就David Chappell的博客所写的文章，以及Jeff Davis的“BPEL怎么了（What's wrong with BPEL）”，都持类似的观点：BPEL不适合BPM。
别误会，我没有贬低BPEL。我的观点是BPEL非常适合将一组现有服务组合成一个新服务。但从我们目前所了解的情况看，它没有交付它对于BPM的承诺。
