对BPEL的想法和评论

　　让我们聚焦到上述流程的控制流方面。这3个服务调用的组合揭示了BPEL语言的关键动机之一，也就是异步服务交互的简易处理。customer端的客户软 件将发送请求消息，并阻塞直到接收到该服务调用的响应消息为止。这就被称为IN-OUT消息交换模式。这种情况下，服务绑定使用HTTP协议上的SOAP协议，也就意味着http请求阻塞直到通过同一TCP/IP连接接收到响应为止。而另一方面，流程本身需要等待，直到supplier执行 submitQuote回调。

　　所有的这些在ESB环境中有重大的意义。ESB的理念就是多个组件可以用一个标准化的方式进行连接，然后通过总线于其它任意组件进行交互。标准化的消息 (一般基于WSDL/XML)在此总线上进行交换。然后，一系列适配器起到协议与总线间网关的作用，可以是HTTP上的SOAP，email,FTP, RMI等协议。

　　WS-BPEL也是基于WSDL的，而WSDL象Web service一样自然地绑定到基于XML的技术上。

　　企业应用也能被连接到服务总线上。一旦总线上的每样东西都以服务形式出现，那么BPEL就更有意义了，因为BPEL本身也基于WSDL，就象与ESB的交互也是基于WSDL的。所以ESB是BPEL引擎的理想环境。

　　EBS几乎都关注于基于XML的服务间XML消息的交换。BPEL从未离开过XML文档级别。一般地，XPath用于剪切和粘贴处理文档的片段，并将之存 储于一个流程变量中。被调用的服务，暴露的服务和流程变量都基于XML。在XML世界中直接描述此执行逻辑。某种意义上，这是一个优势：象XML这样的结 构化信息与编程语言中的对象之间不需要处理事务。对于复杂的文档和对象结构，这些事务不再透明化的或自动化的了，因此它们需要开发的功力和运行时的表现。

　　BPEL复杂的关联(correlation)能力使得不做任何修改实现平衡已存在消息的交互变得简便起来。不需要再消息中或上下文头部信息中传递流程执 行的ID。反而是，由BPEL引擎实现交换文档上下文中基于任意信息片段的关联。实际数据项再每个文档交换中被标识得方式以及它们如何与其它文档交换进行 匹配都是非常灵活的。在许多集成场景中，比如，有通讯协议的地方你不需要控制被交换的文档，这非常好。

　　但是其与BPM的关联源自何处呢？以BPM建模者的观点来看，关联是有疑问的。我能找到的仅有的联系是良好的市场手段而不是它们的特性方面。对于BPM建 模者，BPEL严格来说缺少一系列的基础特性。但当其用于在ESB环境中(在此环境中，你不控制你交换文档的合作者partner)组装出新的服务时， BPEL(甚至不用扩展)就已经非常完整了。就象Maserati对Hummer，增值很大成分依赖于用例。

　　我可以找到的仅有的关联是：BPEL流程可以用一个图来描述，且此语言支持等待状态。这意味着由业务分析者创建的某些流程模型可以被转换成BPEL流程。 但这种方式存在2个主要的限制。首先，业务分析者被认为是非技术人员。所以业务模型种的活动与有效的web service对应起来的机会非常小(或者说不存在)。第二个问题是：BPEL是块结构的。业务模型一般是基于图的。所以，一般来说在转换为BPEL可执 行流程时，让分析者的分析图足够智能是不可能的。这就是为什么将BPMN隐射为BPEL很难和有诸多限制的确切原因。

　　对于BPM使用BPEL的最突出的矛盾在于分析者被认为是非技术人员，且BPEL流程中的活动又归结未web service的调用，并且BPEL流程的块结构特性对于建模来说太受限制了。分析者需要画方框和箭头的自由，这总是导致图结构和任意循环。BPEL流程 不存在迁移(transition)的标记。反而是，BPEL流程是一个复合结构，在复合结构中顶级活动可以是一个序列(sequence)。序列将包含 一系列嵌套的活动。一些可以是基础(或称为原子)活动，另一些可以是复杂活动再包含一系列嵌套活动。利用优秀的工具，这种自上而下的活动可以非常容易地创 建一个BPEL流程。单要将一个分析模型隐射成一个BPEL流程就有些不同了且至少来说都很难。

　　另一个在BPM中使用BPEL存在疑问的方面是有限的数据操作特性。在服务编排中经常需要从一个XML文档中提取出一些内容片段。但对于BPM，经常需要在流程的各个步骤之间进行众多的数据处理。XPath和其它基于XML的转换技术不够简便。

　　如果你作为一个架构师考虑BPM使用BPEL，你应该问自己一个问题：你是否需要ESB中的核心业务流程数据。

　　从存储过程到企业技术(如JEE)，便于对创建新应用的管理数据都放在”云”(cloud)中。BPEL引擎需要维护的数据与领域模型相关，如 customer,client,supplier,product等等。这些领域数据一般都存储于IT基础设施的关系数据库中。如果你的应用需要知道文 档的客户引用怎么办？你想将其作为BPEL引擎的一个流程变量询问那个文档，然后从XML文档中提取XPaht的引用么？答案是这样的信息应该被包含在数 据库中的领域模型中，而不是在BPEL引擎中。BEPL并不是不能将这些信息存储在领域模型数据库中，而是更难。你必须实现一个特定的web service来获取存储于领域模型中的客户引用。所以BPEL好象使得获取你分区的领域模型信息更容易了。请注意这点。

　　David的”Case against BPEL”, Joe McKendrick的”story on David Chappell”s blog”以及Jeff Davis的”What”s wrong with BPEL”, 给出了BPEL不适合BPM类似的的观点。

　　别被我错导了。这并不是对BPEL的批斗。关于BPEL，我的观点是其是组装新服务为其它服务提供功能的很好的技术。但是，其并没有达到其对BPM的承诺，至少是我们现在所知道的BPM。