是我Out了，还是SOA瞎扯蛋？

最近一直在看关于SOA的书籍，总是感觉SOA和实际情况格格不入 ，甚至SOA的一些概念自相矛盾。

就以BPEL而言，SOA的书籍上说，BPEL是SOA"落地"的要件之一。SOA把业务都看作粗粒度的服务构成，然后通过BPEL进行编排以完成业务目标。

首先我质疑的就是，所有的业务目标都可以用这种“粗”粒度的服务完成吗？

我的答案当然是否定的。在此，我也引用IBM的develope works上的一段话，佐证我的观点。

http://www.ibm.com/developerworks/cn/webservices/0803_wangxn_BPEL_2/
业务流程的完全自动化虽然非常不错，但在实际中却是不可能实现的，因为有些活动要求相关人员做出判断，或要借助人员的专业知识（例如手动处理异常情况或审批请求等），这些活动将始终由人进行。

BPEL被迫加入人工任务，这就和SOA的初衷矛盾了。人工任务大多数时候是细粒度的，另外，人工任务用得着BPEL吗？

不知道是我Out了，还是SOA瞎扯蛋？

感觉有点偏激了。
个人觉得，虽然SOA不像商业宣传那样能够解决一切问题。
但不可否认，它确实解决了问题。
这不就够了么。

不是你OUT是   两点:一. 你对SOA期待太高了,SOA不够IN 二:你对SOA还没有理解透彻 你不够IN
开个玩笑的

bpel用来用去
感觉就像一门面向过程语言
不要被它的可视化所迷惑

从BPEL的角度看
WS 就像一些可以通过网络调用的函数库
面向过程语言（BPEL） 通过一些现有的函数库（WS或称为原子服务） 定制一些新的函数
并发布出来

1) 这个应该是BPEL的本职工作。
2) 但是这个工作的用武之地太小了。
3) 于是乎，IBM等大公司的专家一拍脑袋认为BPEL应该要处理我们遇到的所有业务流程，但是我们遇到的流程很少是粗粒度的，多数是细粒度的，且不可避免有人工参与，那就把人工任务也当作webservice来调用吧。。。。。

最后bpel 4 people出炉了，我们膜拜之。。。。

呵呵~ 看样子我也Out了~ 哎~~

BPEL 主要用在系统间的流程，系统内流程用BPEL就太重了

SOA 中不用一定要用BPEL的

EOS好像就是这么干的 不过就是你不用BPEL 但是XML这个介质还是没办法避免的 而且XML分为数据区域和控制区域的设计也没有办法改变

EOS这种垃圾也好意思拿出来说阿!

"但是XML这个介质还是没办法避免的"

就冲这句话，我就觉得有问题！单个系统的扩展性和可维护性（或者说松耦合）完全与xml无关，我不明白xml为什么不可避免。如果一个系统内部还采用xml来作为通讯的载体，那是脑子进水了。

看来咱也out了