BPEL 或 ESB：应该使用哪一个？

今天在DW上无意看到一篇文章，觉得写的很好，大家不妨也瞅瞅。http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html

全文从各个方面阐述当面对一个问题的时候，解决方案的抉择问题。其中心内容就是当发布一个服务以供外围系统使用的时候，这时候你手中的两件利器BPEL和ESB你究竟青睐谁更多一些，其实上也就是当BPEL和ESB在功能上有重叠的问题，给架构者带来了取舍的难题。

在文中归纳的所有观点中，我觉得有一点点中了其中利害关系：
如果需求是以数据为中心的，则显然要选择 ESB
如果需求是以流程为中心的，则显然要选择 WS-BPEL

没错，说的准确到位，在我们的项目中也一直是遵守这个原则的，作者的观点和我们的执行没有冲突。是否是在SOA的实践中同时找到了组建的规则呢？真的这么巧合吗？

我作为一个底层的编码人员，所以只能以有限的认识谈观点。感觉文中不乏忽悠的地方，所以很多地方的理解还不是深刻到位，所以有说的不对的地方，还请大家指教。我感觉这篇文章的教育意义并不是很大，至少在我看来，我不会因为在适用场合中因为选择ESB或者是BPEL的问题上犯愁。举个例子来对比说明一下：
ESB和BPEL在SOA的实现过程中扮演着重用的角色，同样姚明和麦迪也是火箭队不可或缺的关键先生，但是ESB擅长处理数据，尤其是海量数据，能够提供路由转发规则极其复杂的数据服务，但是他对数据的流程操作就显得的相形见拙了；但是BPEL作为一门流程定义语言，他完善的数据操作规范，使得他对数据各类操作游刃有余，但是你要让BPEL传输10K以上的数据，并实现多点传输的话，那真是要了命了，你的Server绝对抱怨你不懂的利用它。所以虽然ESB和BPEL都能够作为Web Service，但是它们的适用场景不用说就是前面提到的两点。这里回过头来说姚明和麦迪，虽然两人都能拿球得分，但是姚明擅长的位置是中锋，习惯得分方式是内线强大，但是麦迪舒服的位置的小前锋，习惯的得分方式是外线干拔跳投，所以说这个时候你还需要去告诉埃德尔曼，姚明应该打中锋，麦迪应该占前锋的位置吗？哈哈，这不是开玩笑么！

再说说文中说到ESB和BPEL重叠的地方，ESB可以通过中介流来调用其他服务，而BPEL可以通过
内部流程调用其他服务，也就是说它们都能够利用或者重新组装其他服务来提供新的服务这项本领，所以功能上重叠了。晕载，晕载，如果这样将功能重复强加于二者身上，不免有些牵强了。没错，ESB可以调用其他服务，但是ESB能控制如何调用？调用多少次？分之调用？能够回退调用吗？能够人工干预吗？反过来，BPEL调用其他服务传递的参数还是局限于SOAP消息，BEPL能接受其他格式，诸如文本文件的数据么？说到数据传递，这是ESB的强项，虽然BPEL也能干一些，但是仅仅局限于利用XSLT，对于复杂的路由规则，消息转换或者协议分发，那就无所作为了。

所以我个人理解，在SOA的实现过程中ESB和BPEL不会出现抉择上的难题。如理解有误，欢迎大家指正，讨论。