SOA、BPEL、ESB的前生后世3

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都从微软去掉一样。那样的微软仍然是微软公司。但那真的还是微软吗？就如同人是一个完整的概念，你非要把人=头+手+脚+...就等于人，这样粗暴而简单的定义和认识，显然是不对的。