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，这么多年下来，估计你的现状不比现在好多少。企业就是这么发展的，虽然可能你在聚会吃饭的时候大发牢骚埋怨公司的管理和战略和老板的决策，但真换你来做，你不见得会比你的老板强。就这个道理。现状已经形成，历史不能倒退，但未来还要前进，我们还不能把包袱扔掉，推倒重来。企业不是这么运作的。企业就是在不断困境和限制中不断前进，就看谁能把握好平衡和资源的调度，坚持执行好决策。
过去我就遇见一个局域网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了？哈哈。
看来，这并不是SOA。我们需要从另一个角度分析SOA。
SOA，中文全写是面向服务的体系结构。这个名称定义让我们很是似曾相识。
面向服务？？？我们听说过面向组件，面向对象，面向函数。是不是和这些有些渊源？
体系结构？我们听说过EJB、COM+、CORBA体系结构，难道和这些体系结构类似？
面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
这是完整的定义：
1 是一个组件模型
2 不同功能单元，称为服务
3 服务之间通过接口和约定联系起来
4 接口是中立的
这个定义是很虚的。
(？？ 这怎么和我多年前学习COM时说的一模一样？
我找到别的网站上的一篇文章说的：
SCA服务组件与传统组件的主要区别在于：
1. 服务组件往往是粗粒度的，而传统组件以细粒度居多。（不对，过去我们做COM，也有流程集合组件，是粗粒度的）
2. 服务组件的接口是标准的，主要是WSDL接口，而传统组件常以具体API形式出现。（不对，只是接口实现技术不同而已，有这样区别的么？）
3. 服务组件的实现与语言是无关的，而传统组件常绑定某种特定的语言。（不对，很多语言都能实现COM）
4. 服务组件可以通过组件容器提供QoS的服务，而传统组件完全由程序代码直接控制。（不对，传统组件也业由组件容器提供了若干服务）
)
虽然，一再声称WebService（XML\SOAP\UDDI\WSDL）不是SOA唯一的可接口中立的描述方法。但事实上，WebService是现在最成熟最有体系最获得业界厂商支持的接口中立描述方法。所以，无论业界厂商怎么辟谣说WebService不是唯一方法，但大家都已经默认。厂商的辟谣是因为有些遗留系统，现在没有WebService的改造能力了，不支持WebService，不辟这个谣，就要丢单子。而国外很多老掉牙还不舍得扔的系统。所以国外非常羡慕中国，一上手就是最先进的技术和标准，没有历史包袱，不走弯路，整合花销和风险和周期都会好很多。
SOA是一个组件模型。组件模型我们知道，COM+、EJB都是组件模型。组件有属性、方法、事件。组件运行在组件容器中。组件容器来保证组件的创建、并发、池化、日志、销毁。
而组件是脱胎于对象的。看看各个语言实现的组件模型，其实现都是应用对象模型。对象具有数据和方法，没有事件。而数据，也没有什么读写限制。这是组件和对象非常明显的区别。
我们曾经面向函数编程，更早时候我们还写过大流水没有函数的程序代码（现在想来甚是幼稚，简直是一团浆糊，但我现在代码复查的时候居然还能看见这类代码，其跟踪纠错、质量保证、变化裁减扩展、阅读理解都不符合，如何能商业化开发）。
但是函数无法表现函数间的关系。只好放到不同的源代码文件中表示逻辑群集。但这种表示方法很是糟糕。数据和方法仍然没有分离，也没有屏蔽可见级别。于是，我们必须走向面向对象。其实我们对OO，并不是像业界理论那样分析业务、映射成对象，然后设计对象。其最开始就是为了解决代码可视级别的事情，继承和多态并不是我们所考虑的。也没有很专业的去分析设计对象。但确实是人以群分物以类聚，实现出来的东西，等我们真正理解懂了OO的理论，回头看我们的代码，居然还真的很符合OO理论。让我感叹现在很多入道不几年的程序员，为了OO而OO，为了实践OO理论而强制自己写OO代码，最后是OO的表面形式，而思路却是大流水，连函数流程都阅读不出来，思路分叉判断很多。建议先踏实把面向函数用起来，再自然过渡到面向对象。
面向对象也有解决不了的问题。那就是没有事件和属性。于是面向组件产生。但是大家仔细分析源代码，属性和事件，都是通过面向对象的方法做到的。如一个属性，往往是Getxxx和Setxxx构成，一个事件是一个特殊形式的属性而已。
事情都是承接的，自然而然过渡的，就和面向大流水到了面向过程，然后是面向对象，然后是面向组件。
面向组件，我们又遇到了问题。而这些问题，都是由于我们顺其自然理解习惯而引起的。
很多人分析完业务，不管你是用UML还是什么组织结构-流程-考核的方法，你在软件设计的时候，总是要有个艰难的映射。就是把现实要映射成类，要影射成组件。而这个映射是如此的不符合顺其自然的思考习惯。你需要变换一种思路，而这分析和设计两种思路，老是拧不在一起。
我们不想继续拧巴了。我们就想很直白的说：我要完成这个事情。我现在有这么多信息，我输入进去，你就给我产出我需要的计算结果。OK，就这么简单。我不想再映射什么类，什么组件了。
这就是很自然的人类思考习惯。我们业界老前辈老专家兜兜转转，研究发表了N多理论和方法，但最终仍然科学理性拧不过人类顺其自然的分析习惯。又回来了。但这个回归已经升华了，我们在简单的接口之下再也不会有大流水的实现了。在我们的服务接口之下，我们自由的应用我们擅长的开发实现方法。我们再也不用和客户讲类映射，客户再也不用和我们讲业务流程了。我们统一了，我们就想这么做：我要完成这个事情。我现在有这么多信息，我输入进去，你就给我产出我需要的计算结果。OK，就这么简单。
让客户学会UML，不可能。过去让我们和客户，想拿RUP过程管理方法和UML事务描述方法来统一，只是个理论理想。
SOA，不是面向组件升级到面向服务这么简单。是我们的软件分析方法、软件设计方法、软件开发方法的变革。是业界对过去这些理论和产品的反思。业界对世界的抽象方法变了。
SOA需要将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。但怎么联系起来。高内聚，低耦合是我们一贯的原则。像过去我们互相开放DLL的方式根本不合适，都是硬编码进自己的系统中。一旦接口改变，都需要修改。幸好，业界发现了有个工作流的东西，听说可以驱动业务流程。于是，满心欢喜的奔了过去。
真正一用才发现不对。工作流的规范世界早已固定。工作流产生的时候，还没有SOA呢。SOA需要的业务流程连接，工作流的原理类似，但并不是最适合软件服务的连接。于是，业界又集体联合起来研发了BPEL，业务流程处理语言。但有些工作流厂商也唯恐被称为落后时代脚步，于是强嘴说自己已经是SOA了。于是，业界李鬼李逵一堆。各有各的利益，各唱各的调。
SOA这种世界观也需要落地到一个可实现的框架。于是SCA和SDO出现。SCA是SOA的落地架构框架规范，SDO是数据结构规范和数据存取原理规范。而这些规范，用现有的开发语言和技术框架都可以实现。所以，对于现有系统，无须认为现有的系统落后了，不符合SOA了，需要重新上一套SOA软件了。
但是，我粗略阅读SCA规范，特别类似于我过去熟悉的组件模型体系。只不过SCA在组件模型基础上又提供了服务定义和服务Wire。组件模型是提供了个体的规范，而SCA不仅提供了个体，更提供了个体之间连接的规范。组件模型让我熟悉了接口与实现的分离，让我熟悉了容器运行保护，让我熟悉了元数据管理。没有经过面向组件时代的人，不会感受到SOA到来的必要性。
我们曾经用组件模型开发应用软件，其目的就是想像这些组件都是独立的个体，然后我们用一种脚本把这些组件穿在一起（过去我想到是VBA脚本，然后是Javascript脚本，然后是ASP脚本，然后又关注了工作流，均不满意，最后才落眼到BEPL）。而如今，SCA、SDO、BEPL、ESB给我们多年的设想提供了可落实的体系模型。我们需要这样灵活组合的应用软件，我们不需要一个上千个参数配置的航母软件（如SAP R/3）。
只有了解了SOA、BPEL、ESB的前生后世，我们才能平和的看待这些技术，看待和这些技术相关的技术，我们才能有的放矢的去学习它、利用它，为我们更快速的适应客户需求变化而有益。
最后一句话：
对于我个人从业经验，我经历过面向过程、面向对象和面向组件三个架构思想的产品开发历史，我们一直试图解决软件组件粒度灵活组合的问题，我学习技术也一直是抱着解决问题而研究，而不是怕赶不上潮流而学习。我个人片面的认为SOA的架构思想就是我们过去应用的面向组件思想的延伸，然后再套上WebService的外壳，我们过去开发COM+，为了跨防火墙为了异构连接CORBA可费死了劲。SOA还结合了业务灵活的BPEL思想，整合了中间件消息总线WebService治理的技术思路。SOA整合了这么多架构思想和企业产品技术，根本目标就是使我们的IT更加灵活。我们过去做面向组件也是为了这个根本目标。SOA就是通过面向业务的分析方法+WebService中立技术+BPEL脚本业务编排+ESB服务治理总线中间件来达到IT灵活的。
SOA是面向服务，OO是面向对象。就这么简单，一个问题领域。SOA不是EAI，不是系统集成的一种方式。那是业界某些公司为了达到自己的利益目的做的宣传，混淆大家的视听。怎么学习面向的时候，没有人提这些系统集成。到了面向服务，就牵扯到系统集成了？被人忽悠了？过去我做企业集成，用的是读取数据库，然后是DLL，然后是WEBSERVICE，但没有使用SOA。
过去业务设计使用的是一种思路，软件设计使用的是另一种思路，老对接不上去，SOA统一了。都必须从业务角度看问题，而不能一方是流程，一方却是类图和时序图。
给大家举一个例子。
有一个业务，是用户在网站上选择自己想买的车型，然后点一下计算，就显示自己购这台车的总费用。
那这个功能就是一个软件服务。SAAS，软件即服务。
业务设计员设计好这个业务。功能设计员就定义了一个软件服务接口，可能叫CalcTotalFee(CarType:XML)。
用户输入的数据，被程序员程序处理成SDO传入，调用服务接口，返回总费用。但接口里面是怎么计算的，用了哪些OO技术或组件技术，或干脆就是大流水帐代码，那是你程序员自己的事情。而业务设计员和功能设计员是统一认识的。
这就是业务设计、功能设计、功能开发三者的关系。
有了SCA和SDO，SOA概念踏实多了，否则和过去的面向组件和现在微软鼓吹的webservice式的SOA很容易迷惑。
小结：
SCA是SOA的落地规范，否则SOA就是个概念。
BPEL是为了编排连接各个服务的，BPEL不是为了工作流审核审批的。根本就是两个目的两码事，不要混淆。用BPEL实现工作流，或者用工作流想实现BPEL，都是错误思路。
ESB是运行服务，并且驱动BPEL的。
SDO是为了规范接口间的传输数据的格式和数据操作的规.否则，你传输的XML就自己瞎编格式了
SCA和SDO是OSOA组织制定的
但微软也鼓吹自己的SOA，但没有具体理论（微软一向不爱宣称自己的理论，虽然微软做了很多专利和论文），微软有具体的WCF和微软的webservice实现模型作为SCA的对照，也有也有LINQ和ADO.NET作为SDO的对照。
因为微软的SOA服务组件，不遵守SCA/SDO规范，所以在微软的体系里很自在，和IBM阵营整合，就有些困难。因为大家往往用Visual studio工具开发webservice，而自动生成的这个框架，并不符合SCA/SDO标准。
如果你非要让我用什么谁加谁等于谁来说明SOA。我只能暴力的用SOA=WebService+SCA+SDO+BEPL+ESB来表达。如果你觉得SCA+SDO只是IBM、SUN、BEA之类制定的标准而不是业界SOA的标准，如果你觉得BEPL属于业务流程整编的范畴不是SOA模型的范畴，你可以执着的人为SOA=WebService。这种认识就类似于把WINDOWS、OFFICE、Visual Studio、SQLSERVER都从微软去掉一样。那样的微软仍然是微软公司。但那真的还是微软吗？就如同人是一个完整的概念，你非要把人=头+手+脚+...就等于人，这样粗暴而简单的定义和认识，显然是不对的。
我也不是准备写一本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，这么多年下来，估计你的现状不比现在好多少。企业就是这么发展的，虽然可能你在聚会吃饭的时候大发牢骚埋怨公司的管理和战略和老板的决策，但真换你来做，你不见得会比你的老板强。就这个道理。现状已经形成，历史不能倒退，但未来还要前进，我们还不能把包袱扔掉，推倒重来。企业不是这么运作的。企业就是在不断困境和限制中不断前进，就看谁能把握好平衡和资源的调度，坚持执行好决策。
过去我就遇见一个局域网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了？哈哈。
看来，这并不是SOA。我们需要从另一个角度分析SOA。
SOA，中文全写是面向服务的体系结构。这个名称定义让我们很是似曾相识。
面向服务？？？我们听说过面向组件，面向对象，面向函数。是不是和这些有些渊源？
体系结构？我们听说过EJB、COM+、CORBA体系结构，难道和这些体系结构类似？
面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
这是完整的定义：
1 是一个组件模型
2 不同功能单元，称为服务
3 服务之间通过接口和约定联系起来
4 接口是中立的
这个定义是很虚的。
(？？ 这怎么和我多年前学习COM时说的一模一样？
我找到别的网站上的一篇文章说的：
SCA服务组件与传统组件的主要区别在于：
1. 服务组件往往是粗粒度的，而传统组件以细粒度居多。（不对，过去我们做COM，也有流程集合组件，是粗粒度的）
2. 服务组件的接口是标准的，主要是WSDL接口，而传统组件常以具体API形式出现。（不对，只是接口实现技术不同而已，有这样区别的么？）
3. 服务组件的实现与语言是无关的，而传统组件常绑定某种特定的语言。（不对，很多语言都能实现COM）
4. 服务组件可以通过组件容器提供QoS的服务，而传统组件完全由程序代码直接控制。（不对，传统组件也业由组件容器提供了若干服务）
)
虽然，一再声称WebService（XML\SOAP\UDDI\WSDL）不是SOA唯一的可接口中立的描述方法。但事实上，WebService是现在最成熟最有体系最获得业界厂商支持的接口中立描述方法。所以，无论业界厂商怎么辟谣说WebService不是唯一方法，但大家都已经默认。厂商的辟谣是因为有些遗留系统，现在没有WebService的改造能力了，不支持WebService，不辟这个谣，就要丢单子。而国外很多老掉牙还不舍得扔的系统。所以国外非常羡慕中国，一上手就是最先进的技术和标准，没有历史包袱，不走弯路，整合花销和风险和周期都会好很多。
SOA是一个组件模型。组件模型我们知道，COM+、EJB都是组件模型。组件有属性、方法、事件。组件运行在组件容器中。组件容器来保证组件的创建、并发、池化、日志、销毁。
而组件是脱胎于对象的。看看各个语言实现的组件模型，其实现都是应用对象模型。对象具有数据和方法，没有事件。而数据，也没有什么读写限制。这是组件和对象非常明显的区别。
我们曾经面向函数编程，更早时候我们还写过大流水没有函数的程序代码（现在想来甚是幼稚，简直是一团浆糊，但我现在代码复查的时候居然还能看见这类代码，其跟踪纠错、质量保证、变化裁减扩展、阅读理解都不符合，如何能商业化开发）。
但是函数无法表现函数间的关系。只好放到不同的源代码文件中表示逻辑群集。但这种表示方法很是糟糕。数据和方法仍然没有分离，也没有屏蔽可见级别。于是，我们必须走向面向对象。其实我们对OO，并不是像业界理论那样分析业务、映射成对象，然后设计对象。其最开始就是为了解决代码可视级别的事情，继承和多态并不是我们所考虑的。也没有很专业的去分析设计对象。但确实是人以群分物以类聚，实现出来的东西，等我们真正理解懂了OO的理论，回头看我们的代码，居然还真的很符合OO理论。让我感叹现在很多入道不几年的程序员，为了OO而OO，为了实践OO理论而强制自己写OO代码，最后是OO的表面形式，而思路却是大流水，连函数流程都阅读不出来，思路分叉判断很多。建议先踏实把面向函数用起来，再自然过渡到面向对象。
面向对象也有解决不了的问题。那就是没有事件和属性。于是面向组件产生。但是大家仔细分析源代码，属性和事件，都是通过面向对象的方法做到的。如一个属性，往往是Getxxx和Setxxx构成，一个事件是一个特殊形式的属性而已。
事情都是承接的，自然而然过渡的，就和面向大流水到了面向过程，然后是面向对象，然后是面向组件。
面向组件，我们又遇到了问题。而这些问题，都是由于我们顺其自然理解习惯而引起的。
很多人分析完业务，不管你是用UML还是什么组织结构-流程-考核的方法，你在软件设计的时候，总是要有个艰难的映射。就是把现实要映射成类，要影射成组件。而这个映射是如此的不符合顺其自然的思考习惯。你需要变换一种思路，而这分析和设计两种思路，老是拧不在一起。
我们不想继续拧巴了。我们就想很直白的说：我要完成这个事情。我现在有这么多信息，我输入进去，你就给我产出我需要的计算结果。OK，就这么简单。我不想再映射什么类，什么组件了。
这就是很自然的人类思考习惯。我们业界老前辈老专家兜兜转转，研究发表了N多理论和方法，但最终仍然科学理性拧不过人类顺其自然的分析习惯。又回来了。但这个回归已经升华了，我们在简单的接口之下再也不会有大流水的实现了。在我们的服务接口之下，我们自由的应用我们擅长的开发实现方法。我们再也不用和客户讲类映射，客户再也不用和我们讲业务流程了。我们统一了，我们就想这么做：我要完成这个事情。我现在有这么多信息，我输入进去，你就给我产出我需要的计算结果。OK，就这么简单。
让客户学会UML，不可能。过去让我们和客户，想拿RUP过程管理方法和UML事务描述方法来统一，只是个理论理想。
SOA，不是面向组件升级到面向服务这么简单。是我们的软件分析方法、软件设计方法、软件开发方法的变革。是业界对过去这些理论和产品的反思。业界对世界的抽象方法变了。
SOA需要将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。但怎么联系起来。高内聚，低耦合是我们一贯的原则。像过去我们互相开放DLL的方式根本不合适，都是硬编码进自己的系统中。一旦接口改变，都需要修改。幸好，业界发现了有个工作流的东西，听说可以驱动业务流程。于是，满心欢喜的奔了过去。
真正一用才发现不对。工作流的规范世界早已固定。工作流产生的时候，还没有SOA呢。SOA需要的业务流程连接，工作流的原理类似，但并不是最适合软件服务的连接。于是，业界又集体联合起来研发了BPEL，业务流程处理语言。但有些工作流厂商也唯恐被称为落后时代脚步，于是强嘴说自己已经是SOA了。于是，业界李鬼李逵一堆。各有各的利益，各唱各的调。
SOA这种世界观也需要落地到一个可实现的框架。于是SCA和SDO出现。SCA是SOA的落地架构框架规范，SDO是数据结构规范和数据存取原理规范。而这些规范，用现有的开发语言和技术框架都可以实现。所以，对于现有系统，无须认为现有的系统落后了，不符合SOA了，需要重新上一套SOA软件了。
但是，我粗略阅读SCA规范，特别类似于我过去熟悉的组件模型体系。只不过SCA在组件模型基础上又提供了服务定义和服务Wire。组件模型是提供了个体的规范，而SCA不仅提供了个体，更提供了个体之间连接的规范。组件模型让我熟悉了接口与实现的分离，让我熟悉了容器运行保护，让我熟悉了元数据管理。没有经过面向组件时代的人，不会感受到SOA到来的必要性。
我们曾经用组件模型开发应用软件，其目的就是想像这些组件都是独立的个体，然后我们用一种脚本把这些组件穿在一起（过去我想到是VBA脚本，然后是Javascript脚本，然后是ASP脚本，然后又关注了工作流，均不满意，最后才落眼到BEPL）。而如今，SCA、SDO、BEPL、ESB给我们多年的设想提供了可落实的体系模型。我们需要这样灵活组合的应用软件，我们不需要一个上千个参数配置的航母软件（如SAP R/3）。
只有了解了SOA、BPEL、ESB的前生后世，我们才能平和的看待这些技术，看待和这些技术相关的技术，我们才能有的放矢的去学习它、利用它，为我们更快速的适应客户需求变化而有益。
最后一句话：
对于我个人从业经验，我经历过面向过程、面向对象和面向组件三个架构思想的产品开发历史，我们一直试图解决软件组件粒度灵活组合的问题，我学习技术也一直是抱着解决问题而研究，而不是怕赶不上潮流而学习。我个人片面的认为SOA的架构思想就是我们过去应用的面向组件思想的延伸，然后再套上WebService的外壳，我们过去开发COM+，为了跨防火墙为了异构连接CORBA可费死了劲。SOA还结合了业务灵活的BPEL思想，整合了中间件消息总线WebService治理的技术思路。SOA整合了这么多架构思想和企业产品技术，根本目标就是使我们的IT更加灵活。我们过去做面向组件也是为了这个根本目标。SOA就是通过面向业务的分析方法+WebService中立技术+BPEL脚本业务编排+ESB服务治理总线中间件来达到IT灵活的。
SOA是面向服务，OO是面向对象。就这么简单，一个问题领域。SOA不是EAI，不是系统集成的一种方式。那是业界某些公司为了达到自己的利益目的做的宣传，混淆大家的视听。怎么学习面向的时候，没有人提这些系统集成。到了面向服务，就牵扯到系统集成了？被人忽悠了？过去我做企业集成，用的是读取数据库，然后是DLL，然后是WEBSERVICE，但没有使用SOA。
过去业务设计使用的是一种思路，软件设计使用的是另一种思路，老对接不上去，SOA统一了。都必须从业务角度看问题，而不能一方是流程，一方却是类图和时序图。
给大家举一个例子。
有一个业务，是用户在网站上选择自己想买的车型，然后点一下计算，就显示自己购这台车的总费用。
那这个功能就是一个软件服务。SAAS，软件即服务。
业务设计员设计好这个业务。功能设计员就定义了一个软件服务接口，可能叫CalcTotalFee(CarType:XML)。
用户输入的数据，被程序员程序处理成SDO传入，调用服务接口，返回总费用。但接口里面是怎么计算的，用了哪些OO技术或组件技术，或干脆就是大流水帐代码，那是你程序员自己的事情。而业务设计员和功能设计员是统一认识的。
这就是业务设计、功能设计、功能开发三者的关系。
有了SCA和SDO，SOA概念踏实多了，否则和过去的面向组件和现在微软鼓吹的webservice式的SOA很容易迷惑。
小结：
SCA是SOA的落地规范，否则SOA就是个概念。
BPEL是为了编排连接各个服务的，BPEL不是为了工作流审核审批的。根本就是两个目的两码事，不要混淆。用BPEL实现工作流，或者用工作流想实现BPEL，都是错误思路。
ESB是运行服务，并且驱动BPEL的。
SDO是为了规范接口间的传输数据的格式和数据操作的规.否则，你传输的XML就自己瞎编格式了
SCA和SDO是OSOA组织制定的
但微软也鼓吹自己的SOA，但没有具体理论（微软一向不爱宣称自己的理论，虽然微软做了很多专利和论文），微软有具体的WCF和微软的webservice实现模型作为SCA的对照，也有也有LINQ和ADO.NET作为SDO的对照。
因为微软的SOA服务组件，不遵守SCA/SDO规范，所以在微软的体系里很自在，和IBM阵营整合，就有些困难。因为大家往往用Visual studio工具开发webservice，而自动生成的这个框架，并不符合SCA/SDO标准。
如果你非要让我用什么谁加谁等于谁来说明SOA。我只能暴力的用SOA=WebService+SCA+SDO+BEPL+ESB来表达。如果你觉得SCA+SDO只是IBM、SUN、BEA之类制定的标准而不是业界SOA的标准，如果你觉得BEPL属于业务流程整编的范畴不是SOA模型的范畴，你可以执着的人为SOA=WebService。这种认识就类似于把WINDOWS、OFFICE、Visual Studio、SQLSERVER都从微软去掉一样。那样的微软仍然是微软公司。但那真的还是微软吗？就如同人是一个完整的概念，你非要把人=头+手+脚+...就等于人，这样粗暴而简单的定义和认识，显然是不对的。