亲身经历讲述SOA、BPEL、ESB的前生后世

这篇文章涉及到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们更是迷茫。

　　我就拿自己所感受所经历的，跟大家分享一下。

　　去年，做了一个中大的项目，项目周期耗时半年，中间当然还少不了经常斗争并合作着的IBM、SAP两个老熟人。

　　项目是一个大型国企全国系统整合，从C/S的软件到B/S的软件都要整合在一个数据中心，并且在网络门户中可存取，还有专门的分析室使用数据中心数据进行商业智能分析。

　　当然，少不了Webservice、XML、消息中间件、BEPL、ESB。

　　过去局域网C/S管理软件系统之间的整合，往往是通过互相读取彼此的数据库。但是在正规的项目中是不这样做的。为什么。因为读取和改写哪个表的哪个字段，需要定义一个特殊的数据库用户，这还防不胜防，不知道是哪个系统把数据改乱了，谁来承担责任。你如果只整合过两个系统之间的数据交换，而且是寥寥几个表的几个字段的数据彼此读写，觉得这还没什么，如果七八个系统都要整合在一起，互相读写，而且深度关联，就天下大乱了。你往往会感叹怎么CIO这么没眼光，用了不同公司的不同产品，现在遭到报应了吧。其实，话不能这么说，很多时候的项目的上线由于天时、地利、人和，各种因素影响，就是形成了现在你所看到的现状。如果你是CIO，这么多年下来，估计你的现状不比现在好多少。企业就是这么发展的，虽然可能你在聚会吃饭的时候大发牢骚埋怨公司的管理和战略和老板的决策，但真换你来做，你不见得会比你的老板强。就这个道理。现状已经形成，历史不能倒退，但未来还要前进，我们还不能把包袱扔掉，推倒重来。企业不是这么运作的。企业就是在不断困境和限制中不断前进，就看谁能把握好平衡和资源的调度，坚持执行好决策。

　　过去我就遇见一个局域网C/S管理软件系统整合的项目，人家不让读数据库。人家给写了一个DLL。可惜的是该死的PB写的DLL。我们这方是DELPHI写的DLL给他们。大家知道PB是伪编译代码，而且代码是Script形式的，而DELPHI是二进制，而且是结构化OO编程形式的。所以在数据内存表示和格式和数据类型上都不匹配。最后都改成了字符串也不行。因为DELPHI的String，其实质上也是指针型的。好不容易周折解决了数据类型问题，还有数据批量传输的性能问题。一个DLL函数，我想把一条数据库记录传给对方，怎么拼这个字符串。当时想定义N个参数，最后由于对方需要的字段不断变动，最后接口老变，于是定义N个参数方案被废弃，改为传一条记录。记录的每个字段用特殊字符隔开，然后拼在一起，拼一个总的字符串，对方再拆出来处理。这还是一条记录就这么麻烦，对于N条数据被数据集修改，就要调用N次接口函数，处理速度太慢。而且，还面临双方数据事务的阻碍。另外，由于我们不断变动接口升级DLL，DLL版本黑洞也让我们叫苦不迭。

　　这就是整合。这还不算双方利益不统一引起的明争暗斗，延迟给接口，提供错误信息和接口，提供很有限的信息。使项目整合周期异常的长，中间充满了变数。所以，企业CIO一提到系统整合就头疼，能躲就躲。

　　于是，WebService、XML、消息中间件、BEPL、ESB英明神武的上场了。

　　咱们也别定义N个参数了，也别拼字符串了，也别DLL互相硬编码绑死了，也别费尽心思处理数据事务了。

　　有XML给咱们批量传递数据，数据是有格式的。接口也别你是PB的DLL，我是DELPHI的DLL了，咱们都是统一的数据类型和接口调用方式，都是WebService了。咱们俩也别绑死了，都发送到ESB中吧，让ESB来处理事务、消息数据路由吧。咱们也别互相硬编码，BEPL的XML格式描述的业务接口调用整合编排语言来帮忙，让ESB引擎来驱动执行BEPL。

　　ESB有点像消息中间件，用于消息数据的安全的、事务的路由。ESB也有点像组件中间件，提供了组件注册，组件安全，组件版本、组件部署的功能(我怀疑很多功能是组件服务器功能增强后提供的，而不是ESB提供的)。但是ESB最独特的是提供了BPEL的解析执行监控管理。BPEL设计器提供了BPEL的编排，而 ESB提供了脚本的执行。

　　整合省了不少的事。

　　但大家有没有注意到一件事，我这个整合之事，我并没有提到SOA。真是怪怪，满篇案例讲的洋洋洒洒，居然没有SOA这个字眼出现。那怎么国际巨头都拿这样类似的整合项目来鼓吹他们的SOA呢。难道WebServvice+ESB+BPEL就等于SOA?那过去我们做的系统整合、EAI，岂不是我们N年前就SOA了?哈哈。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。