从EAI到SOA

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

从EAI到SOA
1.史前时代，无论原始的socket，或者后来的RMI，都只能在同一平台上传输数据，无法处理异构系统数据传递，比如RMI没有办法和.NET通信。
这个阶段的问题是：1.点对点的传输通道依赖，如果目标地址变化或者故障，就出问题。没有提供更多的交换管理能力。点对点的交换越多，管理成本就越高；2。数据格式绑定，依赖于双方的严格的私有格式。
扩展——EDI的出现解决了异构系统的数据传递格式标准。

2. EAI时代。这个时代要解决的是数据交换管理。
技术平台上看：基于中间件系统，采用了集中式管理的消息交换管理系统，就是所谓的信息总线技术——MQ技术。
统一消息格式是基本工作，对消息传递管理是其核心。包括了两种不同的消息传递方式。时代特征导致它的问题：只关注于消息的格式和传递，而忽略的各个系统的集成程序：没有提供对于这些集成程序的打包和管理。

扩展——JCA. 相对于JMS，JCA关注于集成程序的打包和管理，然而集成程序依然只是二等公民，但JCA 1.0的缺点与规范的未成熟有关。首先，JCA不支持在EAI方案中要求的异步调用。第二， JCA 1.0仅支持从应用程序服务器到EIS的调用。最后，JCA 1.0不支持定义从EIS接收应用程序事件的任何语义。JCA是用驱动整合过程的入口目标对准基于入口的整合。JCA 1.5规范增加支持JMS插入功能，EIS事件通知和异步方法。

3. SOA时代的到来。数据交换和信息共享之后，就是服务管理以及流程管理。
ESB是SOA的最佳技术平台。ESB与MQ一样也提供统一的消息格式，并管理消息传递；
不同的是，ESB重新发现了集成程序的价值，在集成环境中，集成程序代表其背后的应用系统，这些程序提供了各个子系统的应用服务，它们才是集成环境中最有价值的部分，是集成环境中的First Class，并对这些程序提供统一的打包方式，并提供运行时管理。

另一方面，ESB把集成程序进一步分解为服务（业务逻辑）以及Endpoint（服务的入口点）。这样服务不仅仅是可重用，而且是可组装编排; 可快速注册发布; 质量可监控；生命周期可管理的，也正是因此，所谓的BPEL等面向业务的能力开始显现，最终实现SOA的理念：在整个IT范围内实现服务治理和优化，从而直接推动业务的优化。

EAI和SOA的区别
前EAI时代，有个啥事都给自己跑腿送信，遇到对方不在只能一遍遍的跑。
EAI时代，应用服务器是企业的收发室，只知道信件本身，对于信件收发者的身份却不知道，更不知道信件所处的流程体系。
SOA时代，ESB是企业的办公室，不仅知道信件本身，对于信件收发者的身份都清楚，还可以知道信件所处的流程体系。就可以很容易的组合各个服务，建立起各种组合服务，就像现实世界的专员（specialist），响应业务的变化。

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

 

转载于:https://www.cnblogs.com/hibernate3-example/archive/2007/08/24/2493229.html