从EAI到SOA

（2008-1-12更新） 

写在前面
SOA现在越发闹腾的厉害了，各种宣传越来越多，都把SOA吹上天；到底SOA是什么，有啥神奇之处，真的想宣传说的那么好吗？看了种种文章，只是越发混沌。
罢了，俺做技术的，商业上的宣传，俺不在意。既然SOA只是理念，那么俺就从它的支持技术来看看，从过去到现在的区别，看看SOA到底是啥！

从EAI到SOA
从集成的角度看，集成面临的问题如下
A. 数据集成，包括信息交换和交换管理
B. 业务集成，包括服务管理和流程管理

1.史前时代
现象：
1.1. 采用原始交换手段—— 点对点的传输通道依赖，机制是Socket或者后来的RMI。存在两个问题：1. 只能在同一平台上传输数据，无法处理异构系统数据传递，比如RMI没有办法和.NET通信；2.如果目标地址变化或者故障，就出问题。由于没有更多的交换管理能力，点对点的交换越多导致的管理成本就越高；
1.2. 数据格式绑定，依赖于双方的严格的私有格式。

1.3 扩展——EDI的出现解决了异构系统的数据传递格式标准。

2. EAI时代。
现象：
2.1. 基于中间件系统，采用了集中式管理的消息交换管理系统，就是所谓的信息总线技术——MQ技术，包括了两种不同的消息传递方式。
相对以前，统一了内部信息格式（这是基本工作），提供较好的数据交换管理。存在的问题：1. 只关注于消息的内部格式和传递，而忽略的各个系统的集成程序：没有提供对于这些集成程序的打包和管理；2.系统是紧耦合的，不同消息系统间的通信困难。

2.2 扩展——JCA. 相对于JMS，JCA关注于对于旧有系统数据访问，相当于访问数据库的JDBC；

2.3 发展：采用开放的自解释的XML作为系统通信格式，采用松耦合的Web Service作为通信手段。

3. SOA时代。
现象：
3.1. 天然的引入XML和Web Service技术。
3.2. 出现了ESB这样的技术平台。ESB是SOA的最佳基础平台。ESB与MQ一样也提供统一的消息格式，并管理消息传递；不同的是，ESB重新发现了集成程序的价值——在集成环境中，集成程序代表其背后的应用系统，这些程序提供了各个子系统的应用服务，它们才是集成环境中最有价值的部分，是集成环境中的First Class；并对这些程序提供统一的打包方式，并提供运行时管理。另一方面，ESB把集成程序进一步分解为服务（业务逻辑）以及Endpoint（服务的入口点），这样服务不仅仅是可重用，而且是可组装编排; 可快速注册发布; 质量可监控；生命周期可管理的，也正是因此，
3.3. 出现了所谓的BPEL等面向业务的能力开始显现，提供流程管理。

EAI和SOA的区别
EAI时代是企业的收发室，只知道信件本身，对于信件收发者的身份却不知道，更不知道信件所处的流程体系。
SOA时代是企业的办公室，不仅知道信件本身，对于信件收发者的身份都清楚，还可以知道信件所处的流程体系。就可以很容易的组合各个服务，建立起各种虚拟专员（specialist），响应业务的变化。

SOA的产商利益
SOA的基础框架提供了支撑平台，也就是可能性。但要实现SOA的理想，却还需要对业务重新梳理，发现和重用IT资产，正如ERP那样，这才是SOA实施的关键所在；而IBM这样的公司正拥有这样的咨询能力，所以IBM每年都投入大量的资金来推动SOA的应用，就在情理之中了。