《SOA、BPEL、ESB的前生后世.doc》由会员分享，可在线阅读，更多相关《SOA、BPEL、ESB的前生后世.doc（7页珍藏版）》请在金锄头文库上搜索。
1、SOA、BPEL、ESB的前生后世这篇文章涉及到SOA、SCA、SDO、工作流、BPEL、ESB、消息中间件、WebService、EAI、分析设计方法、面向对象、面向组件众多技术，不仔细看，你仍然会混淆SOA=WebService=EAI。BPEL=工作流。ESB=消息中间件。但这些混淆全是错误的，你需要在以下的阅读中体会他们的差异。这篇文章涉及到SOA、SCA、SDO、工作流、BPEL、ESB、消息中间件、WebService、EAI、分析设计方法、面向对象、面向组件众多技术，不仔细看，你仍然会混淆SOA=WebService=EAI。BPEL=工作流。ESB=消息中间件。但这些混淆全是错
2、误的，你需要在以下的阅读中体会他们的差异。如果你没有耐心去理解这些技术的差异和来龙去脉，那么你可以直接阅读最后一段，那里是总结。你可以无需了解过程，直接了解正确的结果。但可能会造成你只知道什么是正确的，但不明白为什么它是正确的。如果你正好想要这种结果，那么正合你的心意。SOA很难，是因为领导SOA影响力和市场产品的公司把许多东西都装进了SOA，以希望获得一揽子解决方案。这个解决方案从SOA项目的方案规划咨询方法到项目管理方法(如RUP，项目岗位角色职责流程评估)到业务描述方法(如UML)到中间件到业界标准(如WebService、SOAP、SCA、SDO)到系统整合诊断到系统整合接口设计(如如
3、何设计面向服务的接口)到系统整合的业务流程整合(如BPEL)，而业务流程整合往往被业界的工作流和业务基础平台牵扯。而国外项目一牵扯到系统整合，就牵扯到遗留系统，什么Corba、COBOL、PL、SAP、JAVA，更是让国内的程序员茫然失措。不仅仅是众多领域的名词、技术标准、产品名称让国内程序员心慌，而且国内的IT技术发展时间短，根本没多少遗留系统，而且国内的程序员也大多年轻，对过去的技术发展和遗留系统的产生和应用历史，也不太清楚。所以把各种因素都综合在一起，让程序员望而却步。而企业的CIO们，一看这么复杂，而且还搞不清楚有什么用，而且一定很贵，而且一定实施周期长风险大，就听说业界鼓吹SOA有利
4、于系统整合、SOA可以使你的IT和业务能灵活的随需应变，但业界也始终没有拿出让人易懂和信服的案例说明怎么就能灵活的随需应变和系统整合。于是，CIO们更是迷茫。我就拿自己所感受所经历的，跟大家分享一下。去年，做了一个中大的项目，项目周期耗时半年，中间当然还少不了经常斗争并合作着的IBM、SAP两个老熟人。项目是一个大型国企全国系统整合，从C/S的软件到B/S的软件都要整合在一个数据中心，并且在网络门户中可存取，还有专门的分析室使用数据中心数据进行商业智能分析。当然，少不了Webservice、XML、消息中间件、BEPL、ESB。过去局域网C/S管理软件系统之间的整合，往往是通过互相读取彼此的数
5、据库。但是在正规的项目中是不这样做的。为什么。因为读取和改写哪个表的哪个字段，需要定义一个特殊的数据库用户，这还防不胜防，不知道是哪个系统把数据改乱了，谁来承担责任。你如果只整合过两个系统之间的数据交换，而且是寥寥几个表的几个字段的数据彼此读写，觉得这还没什么，如果七八个系统都要整合在一起，互相读写，而且深度关联，就天下大乱了。你往往会感叹怎么CIO这么没眼光，用了不同公司的不同产品，现在遭到报应了吧。其实，话不能这么说，很多时候的项目的上线由于天时、地利、人和，各种因素影响，就是形成了现在你所看到的现状。如果你是CIO，这么多年下来，估计你的现状不比现在好多少。企业就是这么发展的，虽然可能你
6、在聚会吃饭的时候大发牢骚埋怨公司的管理和战略和老板的决策，但真换你来做，你不见得会比你的老板强。就这个道理。现状已经形成，历史不能倒退，但未来还要前进，我们还不能把包袱扔掉，推倒重来。企业不是这么运作的。企业就是在不断困境和限制中不断前进，就看谁能把握好平衡和资源的调度，坚持执行好决策。过去我就遇见一个局域网C/S管理软件系统整合的项目，人家不让读数据库。人家给写了一个DLL。可惜的是该死的PB写的DLL。我们这方是DELPHI写的DLL给他们。大家知道PB是伪编译代码，而且代码是Script形式的，而DELPHI是二进制，而且是结构化OO编程形式的。所以在数据内存表示和格式和数据类型上都不匹
7、配。最后都改成了字符串也不行。因为DELPHI的String，其实质上也是指针型的。好不容易周折解决了数据类型问题，还有数据批量传输的性能问题。一个DLL函数，我想把一条数据库记录传给对方，怎么拼这个字符串。当时想定义N个参数，最后由于对方需要的字段不断变动，最后接口老变，于是定义N个参数方案被废弃，改为传一条记录。记录的每个字段用特殊字符隔开，然后拼在一起，拼一个总的字符串，对方再拆出来处理。这还是一条记录就这么麻烦，对于N条数据被数据集修改，就要调用N次接口函数，处理速度太慢。而且，还面临双方数据事务的阻碍。另外，由于我们不断变动接口升级DLL，DLL版本黑洞也让我们叫苦不迭。这就是整合。
8、这还不算双方利益不统一引起的明争暗斗，延迟给接口，提供错误信息和接口，提供很有限的信息。使项目整合周期异常的长，中间充满了变数。所以，企业CIO一提到系统整合就头疼，能躲就躲。于是，WebService、XML、消息中间件、BEPL、ESB英明神武的上场了。咱们也别定义N个参数了，也别拼字符串了，也别DLL互相硬编码绑死了，也别费尽心思处理数据事务了。有XML给咱们批量传递数据，数据是有格式的。接口也别你是PB的DLL，我是DELPHI的DLL了，咱们都是统一的数据类型和接口调用方式，都是WebService了。咱们俩也别绑死了，都发送到ESB中吧，让ESB来处理事务、消息数据路由吧。咱们也别
9、互相硬编码，BEPL的XML格式描述的业务接口调用整合编排语言来帮忙，让ESB引擎来驱动执行BEPL。ESB有点像消息中间件，用于消息数据的安全的、事务的路由。ESB也有点像组件中间件，提供了组件注册，组件安全，组件版本、组件部署的功能(我怀疑很多功能是组件服务器功能增强后提供的，而不是ESB提供的)。但是ESB最独特的是提供了BPEL的解析执行监控管理。BPEL设计器提供了BPEL的编排，而ESB提供了脚本的执行。整合省了不少的事。但大家有没有注意到一件事，我这个整合之事，我并没有提到SOA。真是怪怪，满篇案例讲的洋洋洒洒，居然没有SOA这个字眼出现。那怎么国际巨头都拿这样类似的整合项目来鼓
10、吹他们的SOA呢。难道WebServvice+ESB+BPEL就等于SOA?那过去我们做的系统整合、EAI，岂不是我们N年前就SOA了?哈哈。看来，这并不是SOA。我们需要从另一个角度分析SOA。SOA，中文全写是面向服务的体系结构。这个名称定义让我们很是似曾相识。面向服务?我们听说过面向组件，面向对象，面向函数。是不是和这些有些渊源?体系结构?我们听说过EJB、COM+、CORBA体系结构，难道和这些体系结构类似?面向服务的体系结构(Service-Oriented Architecture，SOA)是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联
11、系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。这是完整的定义：1 是一个组件模型2 不同功能单元，称为服务3 服务之间通过接口和约定联系起来4 接口是中立的这个定义是很虚的。(? 这怎么和我多年前学习COM时说的一模一样?我找到别的网站上的一篇文章说的：SCA服务组件与传统组件的主要区别在于：1. 服务组件往往是粗粒度的，而传统组件以细粒度居多。(不对，过去我们做COM，也有流程集合组件，是粗粒度的)2. 服务组件的接口是标准的，主要是WSDL接口，而传统组件常以具体API形式出现
12、。(不对，只是接口实现技术不同而已，有这样区别的么?)3. 服务组件的实现与语言是无关的，而传统组件常绑定某种特定的语言。(不对，很多语言都能实现COM)4. 服务组件可以通过组件容器提供QoS的服务，而传统组件完全由程序代码直接控制。(不对，传统组件也业由组件容器提供了若干服务)虽然，一再声称WebService(XMLSOAPUDDIWSDL)不是SOA唯一的可接口中立的描述方法。但事实上，WebService是现在最成熟最有体系最获得业界厂商支持的接口中立描述方法。所以，无论业界厂商怎么辟谣说WebService不是唯一方法，但大家都已经默认。厂商的辟谣是因为有些遗留系统，现在没有Web
13、Service的改造能力了，不支持WebService，不辟这个谣，就要丢单子。而国外很多老掉牙还不舍得扔的系统。所以国外非常羡慕中国，一上手就是最先进的技术和标准，没有历史包袱，不走弯路，整合花销和风险和周期都会好很多。SOA是一个组件模型。组件模型我们知道，COM+、EJB都是组件模型。组件有属性、方法、事件。组件运行在组件容器中。组件容器来保证组件的创建、并发、池化、日志、销毁。而组件是脱胎于对象的。看看各个语言实现的组件模型，其实现都是应用对象模型。对象具有数据和方法，没有事件。而数据，也没有什么读写限制。这是组件和对象非常明显的区别。我们曾经面向函数编程，更早时候我们还写过大流水没有
14、函数的程序代码(现在想来甚是幼稚，简直是一团浆糊，但我现在代码复查的时候居然还能看见这类代码，其跟踪纠错、质量保证、变化裁减扩展、阅读理解都不符合，如何能商业化开发)。但是函数无法表现函数间的关系。只好放到不同的源代码文件中表示逻辑群集。但这种表示方法很是糟糕。数据和方法仍然没有分离，也没有屏蔽可见级别。于是，我们必须走向面向对象。其实我们对OO，并不是像业界理论那样分析业务、映射成对象，然后设计对象。其最开始就是为了解决代码可视级别的事情，继承和多态并不是我们所考虑的。也没有很专业的去分析设计对象。但确实是人以群分物以类聚，实现出来的东西，等我们真正理解懂了OO的理论，回头看我们的代码，居然
15、还真的很符合OO理论。让我感叹现在很多入道不几年的程序员，为了OO而OO，为了实践OO理论而强制自己写OO代码，最后是OO的表面形式，而思路却是大流水，连函数流程都阅读不出来，思路分叉判断很多。建议先踏实把面向函数用起来，再自然过渡到面向对象。面向对象也有解决不了的问题。那就是没有事件和属性。于是面向组件产生。但是大家仔细分析源代码，属性和事件，都是通过面向对象的方法做到的。如一个属性，往往是Getxxx和Setxxx构成，一个事件是一个特殊形式的属性而已。事情都是承接的，自然而然过渡的，就和面向大流水到了面向过程，然后是面向对象，然后是面向组件。面向组件，我们又遇到了问题。而这些问题，都是由于我们顺其自然理解习惯而引起的。很多人分析完业务，不管你是用UML还是什么组织结构-流程-考核的方法，你在软件设计的时候，总是要有个艰难的映射。就是把现实要映射成类，要影射成组件。而这个映射是如此的不符合顺其自然的思考习惯。你需要变换一种思路，而这分析和设计两种思路，老是拧不在一起。我们不想继续拧巴了。我们就想很直白的说：我要完成这个事情。我现在有这么多信息，我输入进去，你就给我产出我需要的计算结果。OK，就这么简单。我不想再映射什么类，什么组件了。这就是很自然的人类思考习惯。我们业界老前辈老专家兜兜转转，研究发表了N多理论和方法，但最终仍然科学理性拧不过人类顺其自然的分析习惯。又回来了。但
