从EAI到SOA

最近写关于SOA的论文，对于EAI与SOA有些迷惑，在网上G了一下，发现了篇写的不错的的文章，摘录下来，共享下子
Title从集成的角度看，集成面临的问题如下
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关注于集成程序的打包和管理，然而集成程序依然只是二等公民，但JCA 1.0的缺点与规范的未成熟有关。首先，JCA不支持在EAI方案中要求的异步调用。第二， JCA 1.0仅支持从应用程序服务器到EIS的调用。最后，JCA 1.0不支持定义从EIS接收应用程序事件的任何语义。JCA是用驱动整合过程的入口目标对准基于入口的整合。JCA 1.5规范增加支持JMS插入功能，EIS事件通知和异步方法。

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的应用，就在情理之中了。