1、 EAI的概念
EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的 ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了 EAI，企业就可以将企业核心应用和新的Internet解决方案结合在一起。EAI将进程、软件、标准和硬件联合起来，在两个或更多的企业系统之间实现无缝集成，使它们就像一个整体一样。
随着EAI技术的不断发展，认识它的内涵也越来越多，它已经被扩展到业务整合的范畴。业务整合不仅要提供底层应用支撑系统之间的互连，同时要实现存在于企业内部应用与应用之间，本企业和其他合作伙伴之间的端到端的业务流程管理，它包括应用整合、B2B整合、自动化业务流程管理、人工流程管理、企业门户及所有应用系统和流程的管理和监控等方面。
2、EAI的发展历史
在20世纪60年代到70年代期间，企业应用大多是用来替代重复性劳动的一些简单设计。当时并没有考虑到企业数据的集成，惟一的目标就是用计算机代替一些孤立的、体力性质的工作环节。
20世纪80年代,企业规模开始扩大,企业业务和数据日趋复杂,一些公司开始意识到应用集成的价值和必要性,很多公司的技术人员试图在企业系统整体概念的指导下对已经存在的应用进行重新设计,以便将它们集成在一起。此时,点到点(Ｐｏｉｎｔ-ｔｏ-Ｐｏｉｎｔ)的集成技术开始出现,在各个应用系统之间通过各自不同的接口进行点到点的简单连接,实现信息和数据的共享。点到点的应用集成也被称为第0代ＥＡＩ技术。
20世纪80年代末和90年代初,随着企业规模的进一步扩大,应用系统不断增加,简单的点到点连接已经很难满足不断增长的应用集成要求,企业迫切需要新的集成方法:可以少写代码,无须巨额花费,就可以将各种旧的应用系统和新的系统集成起来。第1代ＥＡＩ技术的出现在一定程度上解决了这些问题,它采用ＣＯＲＢＡ/ＤＣＯＭ、ＭＯＭ(消息中间件)等技术,实现了对企业信息的集成,促进了企业的进一步发展。
20世纪90年代中后期,企业业务的迅速发展以及与电子商务的结合对应用集成解决方案提出了更高的要求,局限于信息集成的第1代ＥＡＩ集成技术很难实现企业业务流程的自动处理、管理和监控,基于业务流程管理/集成(ＢＰＭ/ＢＰＩ)的第2代ＥＡＩ集成技术成为更加合适的集成选择方案。第2代ＥＡＩ集成技术通过实现对企业业务流程的全面分析管理,可以满足企业与客户、合作伙伴之间的业务需求,实现端到端的业务流程,顺畅企业内外的数据流、信息流和业务流。
21世纪面向服务的集成，通过实现对企业业务流程的一体化与全面分析管理,可以满足企业与客户、合作伙伴间的业务需求，实现端到端电子商务集成，顺应企业内外的数据流、信息流与业务流。流程管理主要包括两个方面：业务流程管理和工作流程管理。业务流程管理是用来管理跨业务、跨部门、甚至跨企业边界的业务流程;工作流程是用来管理人员执行任务的流程。流程管理的另一个方面，是对流程的实时分析与监测。第三代EAI与第二代的差别在于(SOA)基于服务架构。把BPM与SOA结合起来，它在实现流程集成同时，以基于服务架构提供流程重组与发布。
3 、EAI的技术架构
3．1 EAI的四种类型
数据集成：数据集成的目标是通过利用消息和数据转换工具进行集成，以一致、可重复的方式在数据库间安全、可靠地传输数据，使得企业的各种数据库中的数据是一致和同步的，从而建立企业范围的统一信息视图。
应用集成：应用集成是以数据集成为基础，利用集散（Hub）、星型或者总线等架构，使一个应用的数据和功能与其他应用的数据和功能协作。应用集成常常利用消息代理或者应用服务器，并需建立企业范围的应用接口模型。
业务流程集成：业务流程集成是以数据和应用集成为基础，按企业的业务流程来集成多个系统的数据和功能。业务流程集成不仅仅在系统间共享数据，而是进行企业级的数据管理。业务流程集成需要使用流程自动化的建模工具，并需建立企业级的业务模型。
外部集成：外部集成是指与客户、合作伙伴及供应商进行交互和整合。外部集成需要利用前面3个类别的EAI集成所建立的企业范围的应用，常常利用公共的网络集成设备（例如Internet），并利用XML等开放的数据标准。常见的外部集成包括B2B和B2C等。
3．2 EAI的六个整合层次
EAI涉及多个整合层次，任何的EAI导入都必须藉由外部协作、业务流程管理、数据转换、应用接口、中间消息服务、系统连接传输这六个整合层次的集成，并附以信息安全管理和系统管理及监控方可达成真正的企业集成。其中外部协作层和业务流程管理层属于业务层面，数据转换层和应用适配层属于接口层面，中间消息服务层和系统连接层属于中间件层面：
3. 3 EAI技术解析
3.3.1通用对象请求代理结构CORBA
说到EAI就很难让人不联想到CORBA。毕竟，让不同编程语言协同工作的主要方法之一就是利用CORBA。作为一个分布式对象的体系结构，CORBA的最初目的就是能够使不同的编程语言、操作系统和软件平台之间实现协同工作。而且，发展到今天，CORBA2已经完全基于面向对象技术，CORBA3则是朝着基于组件的方向发展，其开放性使在不同的CORBA实现商之间进行沟通成为可能，部分甚至可以达到100%的源代码兼容。
· 优点：
· 以一种中间件的方式为不同编程语言提供协同工作的可能；
· 对操作系统没有特殊的要求和依赖，仅取决于实现商，但实现商可以选择；
· 有效长且成熟的发展历史，与许多流行的应用系统（如J2EE）在体系结构上关系密切。
· 缺点：
· 具体的性能与所选实现商的实现有关，且性能再好，中间件的一些服务始终都是瓶颈；
· 一般情况下需要修改源代码来实现对旧有应用软件的包装；
·适用：
当需要集成的两个企业应用软件互为异构，由不同的编程语言实现时，Java与C++就是一个很好的例子。要这两种语言进行协同工作的几乎惟一的方法就是利用CORBA。当然，使用JDK所提供的功能特性JNI也是可能的，但其复杂性以及对Java可移植性的破坏使其不能胜任该集成工作。且JNI不具备分布实施的能力，它的目标也不在于此。
CORBA很适合于通过修改源代码来包装现有应用软件，为其他异构系统提供新的CORBA分布式对象。对于远程方式的请求，IIOP协议会是一个好的选择，例如通过J2EE的RMIIIOP来调用CORBA的分布式对象。
3.3..2 Java2平台企业版J2EE
在近几年的企业应用系统开发中，J2EE无疑扮演了一个重要的脚色。开发业务逻辑或中间层组件的最重要的技术就是EJB，它提供了对主要的企业技术如事务、安全性以及持续性的支持，便利了业务组件的开发。尽管EJB受限于Java编程语言，但这种技术本身并不存在问题。同时，J2EE与CORBA技术所达成的一致性为低层组件的请求提供了可行之路，RMIIIOP和JMS等技术无疑为J2EE提供了强有力的功能核心。
· 优点：
· 基于规范的平台，不受限于特定的操作系统或硬件平台，有大量实现商可以选择；
· 提供现代的组件体系结构，这种结构简化了复杂组件的开发；
· 提供主要的企业技术如事务、安全性以及持续性的支持，并以声明和编辑方式对这些服务提供支持。
· 相对成熟，支持大量中间件技术，能够为EAI提供满意的性能及可升级性。
· 缺点：
· 受限于Java编程语言，尽管可通过其他中间件技术（如CORBA）支持；
· 实现商之间的可移值性还达不到100%；
· 与特定于某个操作系统或平台的实现技术相比，性能还有待进一步提高，且资源占用量较大。
· 适用：
J2EE规范本身就提供了一个巨大的企业应用集成平台，基于Java使其不依赖于运行的硬件平台和操作系统，然而也使其受限于单一语言开发。但这一开发平台，目前已经有不同的厂商提供了符合规范说明的各种实现方法。J2EE支持大量中间件技术，和现有的系统能够协同工作。HTTP，RMIIIOP，JMS，JDBC，JCA以及对XML，企业事务，企业安全方面的支持使其成为目前几种企业应用集成平台中的首选。
3.3.3 XML和XSLT
XML除了大量应用在因特网技术及文档描述中外，在数据交换中也承担了一个重要的角色。作为一个独立的平台，只需用标准文本，XML能够被所有程序语言读写，一旦使用了DTD或Schema，XML的解释程序就能对文件内容进行验证并处理。XSLT同样是基于XML技术的，但它的作用是重新格式化并传输XML数据文件，从而得到一个全新指定格式的XML文档。
· 优点：
· 内容由标准文本组成，任何平台和程序语言都可以使用；
· 各种程序语言的解释程序可以根据DTD或Schema对文件内容进行验证并处理；
· 格式的转换基本不受限制，可以满足不同应用系统的需求。
· 缺点：
· DTD在过去被大量的使用，但DTD本身不是XML，而是基于正则表达式的；
· 当XML内容较大时，解释程序的执行效率会是一个问题；
· 适用：
当不同的应用系统使用着各自的数据格式，或符合复杂的行业标准，而现在需要在各个应用系统之间交换数据，那么XML和XSLT提供了一个可行的手段。当然，XML并不能解决所有的数据交换问题，如何将各种不同的原始数据格式以XML文档来记录就是一件棘手的问题。但好的一面是各种平台及编程语言目前都已经很好的支持了XML及XSLT，一旦XML准备就绪，XSLT就准备将其转换成其他应用系统需要的数据格式。
3.3.4分布式组件对象模型DCOM
DCOM扩充了在网络中通过COM支持的对象，并允许COM应用软件分布在局域网中的多个计算机上。DCOM通过网络协议定义过程中的通信。在运行时，COM为客户程序和使用RPC的组件提供服务，而且遵循DCOM协议标准。
· 优点：
· 在Windows平台上提供基于COM体系结构的分布式处理；
· 在Windows平台上使用能够达到较为满意的性能要求。
· 缺点：
· 在跨平台使用中存在困难，且性能无法得到保障。
· 适用：
在Windows平台上进行集成实施的首选，但与其他平台及编程语言的协同工作需要借助于第三方厂商的支持。
3.3.5消息中间件MOM
企业消息传递使得应用程序能够跨多平台进行可靠的传输。通过使用可靠的消息队列，提供支持消息传递所需的目录、安全和管理服务，MOM确保验证过的应用之间消息传送的安全，它通常提供同步和异步的传输模式。在企业内部保证可靠的传输最通用的方法就是使用消息传递系统。CORBA和J2EE目前就支持MOM的工业标准接口。
·优点：
· 为不同的企业应用系统提供了跨多平台的消息传输；
· 除支持同步传输模式外，还支持异步传输，有助于在应用间可靠地进行消息传输。
· 缺点：
· 与其他中间件技术一样，高流量的性能瓶颈问题正在改善；
· 适用：
如果要在多个平台上的应用程序之间保证可靠的传输，且这些应用程序并不在同一时间运行时，应用之间的RPC直接通信或传输数据将不能胜任，而消息中间件MOM会是一个好的选择。即使当请求建立时，接收方应用程序没有运行，这个请求也不会丢失，这就是异步传输的优势。
3.3.6 J2EE连接器体系结构JCA
JCA是在J2EE1.3的版本规范中提出的，由EIS厂家来执行和提供。JCA的资源适配器是规范化的EIS代理，可插入到任务符合J2EE规范的应用服务器中，并通过应用服务器提供的标准EIS访问接口CCI来对EIS执行操作。JCA向基于EAI的应用程序开发者提供了通过一个将EIS整合进入J2EE的标准方法。此方法定义了一套开发者能在J2EE环境中使用的通用API和服务。
· 优点：
· JCA不仅能在数据上将EIS系统集成到J2EE应用中，它还能够将安全与事务等管理涉入到符合条件的EIS系统中。
· JCA的出现使得将遗留的EIS系统集成到J2EE应用中的操作复杂度由NxM减小为N+M。
· JCA由于基于Java技术，在多平台的移植过程中所遇到的阻力较小。
· 缺点：
· JCA是一种紧耦合的问题解决方案，它的实现需要涉及所希望集成的遗留EIS系统的API，并且对这些操作进行封装。
· JCA是基于Java技术的，尽管不需要所被集成的EIS系统也是Java实现，但通过JCA去使用该EIS的客户应用却必须是Java实现。
· JCA的实现并不容易，如果实现联接管理部分是JCA所必须的，则一旦加入了事务及安全管理则复杂度将急剧上升，如果是以CCI来实现则遇到的问题可能会更多。
·适用：
JCA所提供的好处基本上是面向J2EE应用服务器及EIS系统供应商的，因为他们的产品往往是符合各种标准与规范的，JCA所给出的统一规范对于他们来说无疑是降低风险并减少开发成本的好武器。但对于一般的企业自产的应用系统而言，JCA就未必能够发挥太大的作用，相反，它有可能成为开发过程中的瓶颈。原因有几点，第一，JCA即资源适配器的开发并不是所有的开发者都能够胜任，它的开发模式与编写普通代码不同，JCA将设计模式中的Factory等模式发挥得淋漓尽致。第二，JCA作为一个统一的规范，它的实现也需要很多的标准与规范来支持，如XA分布事务等。而一个企业的自产应用系统往往并不具有这些标准与规范，所实现的资源适配器并不能享受JCA所提供的众多优点。第三，企业自行开发的资源适配器最终还是要插入到各种J2EE应用服务器中去，但作为第三方的开发者，不了解所使用的J2EE应用服务器的相关特征，甚至应用服务器中存在的缺陷，尽管双方都遵循JCA规范，但实现的不同使得第三方所开发的资源适配器未必能正常发布或应用。
4、 EAI和SOA的区别
EAI和SOA都可以解决目前各个IT系统间的信息孤岛问题。EAI是采用集成的方式，把各个子系统连接起来，但是各个系统接口没有形成标准，所以具体实现起来比较困难。而且一个系统的改动可能会引起整个系统的不稳定性。此外，EAI是否会成为新的瓶颈也是许多人所担心的。SOA在系统架构的时候就考虑整合，利用共享的服务，共享的数据字典交互信息。