商业产品级的应用集成套件的出现很好的解决了上述早期系统的缺点。其具有专用的EAI平台、完整的集成框架和设施，用户开发维护部署简单，对原有系统不改动或改动小。因此，应用集成套件成为EAI趋势。

　　在企业应用集成（Enterprise Application Integration，EAI）领域，企业一直面临着削减成本和最大限度地利用现有技术的难题，但是与此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。从信息的整合再到功能与流程的整合，从企业内部的应用整合到跨企业边界的整合，企业整合的需求不断地变化和丰富。在当前激烈竞争的环境下，一个成功的企业在IT构建上需要解决下列问题：

　　如何实现应用系统的快速构建，迁移和伸缩，以满足不断变化的市场需求。

　　如何能够让已有的多种应用系统无缝的集成起来。

　　如何设计现代IT架构，使系统不仅功能强大和可靠，而且还有强大的灵活性和可扩展性，以满足不断增长的新需求。
 
　　与此相对应，EAI技术也在不断的向前发展。EAI技术的发展历史，可以从两个方面来描述，一是满足企业EAI需求的系统的体系结构，另个方面是EAI产品的系统构成。
 
　　1.1.1.1 系统构成
 
　　硬编码（没有EAI技术的技术）

　　最早期的系统应用集成，用户只着眼于解决眼前的一个系统和另外一个系统的互连互通，并不考虑这个系统的合理性和可扩展性。这种集成并不采用什么专门的EAI技术，只是使用硬编码来实现系统之间的点对点连接。这种方式，在有些特定情况下（比如很小规模的集成系统）可能会得到相对较高的性能，因为一切都是为特定情况定制开发的。但集成规模稍一复杂，这种方式代码量大，不可靠，无法维护等缺点就会显露无疑。 

　　基于基础中间件（MOM，AP Server）的集成

　　随着商业基础中间件（MOM，AP Server等）的广泛应用，EAI系统的构造开始转向构造基于这些基础中间件的系统。虽然基础中间件的使用在一定程度上简化了开发代码量，而且大大提高了EAI系统的运行时可靠性和效率，但其本质上仍是零散的定制开发，其缺少完整的适合企业应用集成特点的集成框架和设施，各个模块之间往往仍然是紧偶合的并绑定特有基础中间件的，而且，有些时候基础中间件的使用反而会增加系统的技术复杂性。

　　EAI套件

　　商业产品级的应用集成套件的出现很好的解决了上述早期系统的缺点。其具有专用的EAI平台、完整的集成框架和设施，用户开发维护部署简单，对原有系统不改动或改动小。因此，应用集成套件成为EAI趋势。
   
　　目前的先进的应用集成套件提供的集成框架都是满足SOA要求的，并且提供完整的从设计，开发到部署，运行监控一整套设施和工具，包含功能完善的企业服务总线，提供符合BPEL标准的BPM。

　　下图是Gartner Group在2001年对不同EAI系统的市场份额的分析。

　　1.1.1.2 体系结构

　　定制连接，两两互连

　　最早期的EAI解决方案就是将企业中需要互通信息，共享数据的系统两两桥接起来。桥接的技术也是为两个特定系统专门定制通讯链路来转换这两个系统的接口，协议以及数据格式等差异。

　　缺点：

　　全部使用专门为两个特定系统定制的连接，在企业系统众多的情况下连接急剧增加，难以开发，后期维护更加困难。剧Gartner Group在2003年4月发布的调查结果显示，大约有35%的企业软件预算用于维护大量已经存在的点对点应用连接上。CIO Insight在2003年2月也提出了类似观点，他们发现维护和管理这些点对点连接平均用去企业IT预算的29%。

　　由于这些专用连接完全互相独立，其只能满足系统两两互连通讯的需求，无法实现涉及多个应用系统的复杂业务流程。

　　中心——辐条（hub-spoke）式体系结构

　　由于两两互连方式具有上述明显缺陷，中心——辐条式的解决方案应运而生。该方式提供一个应用集成中心（hub），这个中心具有自己的连接协议，所有需要集成的系统（spoke）都和该中心相连。原来用户每集成一个系统，都要考虑改系统和其他所有系统的点对点连接的协议，数据结构的转换，而在中心——辐条结构下，用户只需要考虑系统和集成中心的点对点连接上转换。这样，原来n个系统之间的nx(n-1)/2个点对点连接减少为n个连接。

　　一般集成中心和各个系统的连接及相应的转换使用集成中心中所谓适配器来完成。同时，这种方式也使的集中管理以及流程集成成为可能。另外，体系结构中开始出现集中式的资源中心（Repository）。资源中心将原来分散的各种资源（适配器，组件，运行信息等）集中管理起来，这为用户设计，开发，部署和维护管理EAI系统提供了很大的便利。 

　　缺点：

　　集中式的结构容易造成效率瓶颈，同时存在单点失效的问题。

　　ESB & BPM & BAM

　　随着IT技术的发展，企业应用集成的需求急剧增加，上述朴素的中心——辐条式结构已不能很好的满足这些需求，企业服务总线（Enterprise Service Bus）的体系结构逐渐浮出水面。这种体系结构继承了中心——辐条（hub-spoke）式体系结构将各个系统点对点连接转化为多个系统对中心的连接的理念。但在这种体系结构中，集成中心被扩展成可以分布在多个物理节点上的总线，从而有效解决了中心——辐条模式的单点失效和效率问题。

　　然而，ESB技术并不仅仅是简单的将集成中心被扩展成总线。企业服务总线本身提供各种消息路由，数据转换等各种EAI模式的支持。这种总线一般以成熟的消息中间件作为其物理消息传递背板，保证消息在分布式环境下可靠高效的传输。同时，企业服务总线作为应用集成系统的基础框架，大多数采用面向组件的技术，这实际上是SOA的雏形。

　　另外，ESB体系机构中往往包含商业流程管理（BPM）和商业活动监控（BAM）模块的实现。BPM作为ESB的消费者，可以将总线上的各个服务（或组件，适配器等）按照用户需要的商业逻辑组装起来，使这些服务按照业务逻辑顺序执行，从而实现用户完整的业务功能。而BAM提供对整个ESB，ESB上的服务和BPM的运行状态进行监控和管理。

　　下图是Gartner Group在2002年对EAI技术趋势的预测。

　　SOA & ESB/BPM/BAM

　　面向服务的体系架构（Service Oriented Architecture）是目前EAI领域最先进的体系结构。实际上，SOA的提出在很大程度上就是为了更好的满足企业应用集成的需求。SOA强调复用和松偶合，注重接口及其标准化描述，这些都为企业应用集成规划了非常好的框架体系结构。除了具有前面ESB结构的优点之外，基于SOA的应用集成系统具有更好的可扩展性和灵活性，用户可以在对已有系统影响最小的情况下开发应用新的业务模块（服务）或修改已有模块，从而快速满足业务需求的变化。

　　本质上说，SOA架构对应用集成的基本要求有以下几点：
 
　　SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用。这是对服务提供者本身的要求。

　　服务间保持松散耦合，基于开放的标准，服务的接口描述与具体实现无关。这是从服务消费者的角度应该看到（了解）的服务提供者的样子。

　　灵活的架构-服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明。这是对服务消费者消费服务提供者提供的服务的方式的要求。基于SOA架构的EAI产品一般使用企业服务总线（ESB）来满足（实现）这一要求。

　　可以看到，SOA的体系结构一般来说也需要企业服务总线的支撑，只是它对总线上的服务和总线本身的作用和位置有着更加明确的要求。

　　好的符合SOA的EAI系统也同样整合了对BPM和BAM的支持。这里特别要指出的是，在符合SOA的EAI系统中对BPM的支持具有更多优点。在传统ESB系统中，BPM往往是厂家相关的专门模块，这一模块存在于ESB之上并且是不可替换的。而在符合SOA的EAI系统中，BPM模块也作为一种服务（编排服务）其本质上和其他服务没有差别，这使得用户选择多种服务编排方式（即不同的BPM实现）成为可能。