SOA BPEL ESB的前生后世
我不是卖中间件的，所以我也不必鼓吹SOA概念和大道理。我也不是准备写一本SOA书的，所以我也不必写博客心得分享时咬文嚼字。
这篇文章涉及到SOA、SCA、SDO、工作流、BPEL、ESB、消息中间件、WebService、EAI、分析设计方法、面向对象、面向组件众多技术，不仔细看，你仍然会混淆SOA=WebService=EAI。BPEL=工作流。ESB=消息中间件。但这些混淆全是错误的，你需要在以下的阅读中体会他们的差异。如果你没有耐心去理解这些技术的差异和来龙去脉，那么你可以直接阅读最后一段，那里是总结。你可以无需了解过程，直接了解正确的结果。但可能会造成你只知道什么是正确的，但不明白为什么它是正确的。如果你正好想要这种结果，那么正合你的心意。
SOA很难，是因为领导SOA影响力和市场产品的公司把许多东西都装进了SOA，以希望获得一揽子解决方案。这个解决方案从SOA项目的方案规划咨询方法到项目管理方法（如RUP，项目岗位角色职责流程评估）到业务描述方法（如UML）到中间件到业界标准（如WebService、SOAP、SCA、SDO）到系统整合诊断到系统整合接口设计（如如何设计面向服务的接口）到系统整合的业务流程整合（如BPEL），而业务流程整合往往被业界的工作流和业务基础平台牵扯。而国外项目一牵扯到系统整合，就牵扯到遗留系统，什么Corba、COBOL、PL、SAP、JAVA，更是让国内的程序员茫然失措。
不仅仅是众多领域的名词、技术标准、产品名称让国内程序员心慌，而且国内的IT技术发展时间短，根本没多少遗留系统，而且国内的程序员也大多年轻，对过去的技术发展和遗留系统的产生和应用历史，也不太清楚。所以把各种因素都综合在一起，让程序员望而却步。而企业的CIO们，一看这么复杂，而且还搞不清楚有什么用，而且一定很贵，而且一定实施周期长风险大，就听说业界鼓吹SOA有利于系统整合、SOA可以使你的IT和业务能灵活的随需应变，但业界也始终没有拿出让人易懂和信服的案例说明怎么就能灵活的随需应变和系统整合。于是，CIO们更是迷茫。
我想起刘韧在2008CSDN技术大会的一句话：不讲假话，要讲实话；不讲道理，要讲经历。
我就拿自己所感受所经历的，跟大家分享一下。
去年，做了一个中大的项目，项目周期耗时半年，中间当然还少不了经常斗争并合作着的IBM、SAP两个老熟人。
项目是一个大型国企全国系统整合，从C/S的软件到B/S的软件都要整合在一个数据中心，并且在网络门户中可存取，还有专门的分析室使用数据中心数据进行商业智能分析。
当然，少不了Webservice、XML、消息中间件、BEPL、ESB。
过去局域网C/S管理软件系统之间的整合，往往是通过互相读取彼此的数据库。但是在正规的项目中是不这样做的。为什么。因为读取和改写哪个表的哪个字段，需要定义一个特殊的数据库用户，这还防不胜防，不知道是哪个系统把数据改乱了，谁来承担责任。你如果只整合过两个系统之间的数据交换，而且是寥寥几个表的几个字段的数据彼此读写，觉得这还没什么，如果七八个系统都要整合在一起，互相读写，而且深度关联，就天下大乱了。你往往会感叹怎么CIO这么没眼光，用了不同公司的不同产品，现在遭到报应了吧。其实，话不能这么说，很多时候的项目的上线由于天时、地利、人和，各种因素影响，就是形成了现在你所看到的现状。如果你是CIO，这么多年下来，估计你的现状不比现在好多少。企业就是这么发展的，虽然可能你在聚会吃饭的时候大发牢骚埋怨公司的管理和战略和老板的决策，但真换你来做，你不见得会比你的老板强。就这个道理。现状已经形成，历史不能倒退，但未来还要前进，我们还不能把包袱扔
