在过去10多年里，EAI领域得到飞速发展，其中的某些基础技术已近成熟，在实用系统中得到广泛的应用。譬如我们在商品化产品中能看到的数据通讯性能，包括同步通讯性能(CORBA, RMI, Web Service等)，和异步通讯性能(Queue或Channel等)。这些性能在商品化系统中都有较好的支持。一些工业标准也相继制定。如J2EE为基于Java的中间件系统设计设定了标准；基于J2EE的JCA标准为连接器的实施制定了标准；UML中的数据流图和状态图为业务流奠定了理论基础；WfMC为工作流制定了一系列标准。
EAI 解决方案通常涉及到 JCA、JMS、Web 服务以及 XML 等多种企业级技术。这些技术都已经成为业界的标准，从而可以最大化地保护客户投资。这些技术既可以被包含在相关产品中供用户透明地使用，也可以由用户自己在应用程序中加以调用。此外，SOA（面向服务的架构）随着各大厂商的追捧而变得炙手可热。虽然 SOA 本身不是一个全新的概念， 但由于 Web 服务以及网格计算等技术的成熟，SOA 具备了更好的发展条件。对于 EAI 来说，基于 SOA 的企业应用系统可以随着企业业务的变化而逐渐变化，能够实现“柔性化”的软件系统，从而降低实施 EAI 的成本和风险，因此我们可以说 SOA 的兴起给了 EAI 厂商一个新的机会。
下面我们对其中的几种核心技术给予简单的说明：
4.1 消息代理
为了成功进行系统集成，特别是企业内部的EAI时，被集成的几个应用系统之间需要进行一一致的，可被理解的的通信联系。不仅如此，还要求这种通信是可靠的，不希望数据在传输过程中丢掉或被破坏掉，这是个棘手的问题。应用程序间通信可能是使用不同的协议和不同的数据格式。包含在此次通信中的所有应用程序并不是在同一时间运行的。比如，应用之间通过RPC直接通信或传输数据时，当请求建立时，如果接受方程序没有运行或出现故障，那么请求方就可能出现死机等待或请求数据丢失。这是我们不希望看到的。
比较好的解决方案是：在EAI中基于异步传输方式的消息机制。在异步传输中，消息传输客户机传送消息却不需要建立会话连接，换句话说，当消息被发送时，接受端客户机并不需要在运行，接受消息的是消息代理。如果发送失败，消息代理会不断地重发。这种异步方式也解决了消息的堵塞问题。
EAI中最常用的传输模型有：
- 点对点(PTP)消息传输。在这种模型中，消息制造者把每条消息以同步或异步方式传送刘一个特殊的消息代理队列中，这个代理队列是由接受方(也称客户)为保留它的消息而建立的，一个接受者一次可以拥有一个或多个队列；
- 发布／订阅(Pub／Sub)消息传递。使用这种模式，一个应用程序一次可以经过一个消息代理把消息发送到多个应用程序。在(Pub／Sub)域中，消息的目的地称为主题。想要消息的客户订阅主题，当一个消息发布到主题时，它就可以转发到所有的订阅者了。或者来跟踪消息是否传送成功，并在必要的时候重发该消息。这种担当中介的组件也叫M0M一面向消息的中间件。
4.2 JAVA
Java 消息传递服务（JMS）定义了一个可以用来在应用程序间交换消息的公共 API ，它允许应用程序间进行异步通信，可以被作为一种应用集成的手段。Java 2 连接器体系结构（JCA）定义了一种用来使 J2EE 应用程序与非 J2EE 环境用一种安全的、事务性的方式进行通信的方法。
4.3 Web Service
传统的EAI厂商依靠独有的数据总线技术在不同的软件包之间映射信息。这就意味着集成解决方案本身就变成了私有的和相对不可访问，因为它的内部通讯机制是不能解释的。然而Web Service对企业间EAI厂商的通讯层进行了标准化。对于Web Services，不少资深专家认为它将和P2P(Peer-to-Peer)一起，带动未来几年内rr软件的另一波革命。这个推测由各个重量级软硬件厂商，从微软、ⅢM、HP、Oracle，到Sun，纷纷宣布各自支持web Services的策略而得到进一步的证实和支持。请注意，尽管各种web Services概念不同：微软的产品是．NET，Sun的是Sun ONE ，Software AG则采用Gartner Group所说的“e—Services”，但他们思路却大同小异。
web Service 服务技术是XML、简单对象访问协议(SOAP)、WEB服务描述语言OVSDL)和统一发现目录(UDDD的整合技术。
web Service把用WSDL描述的WEB服务接口注册在intemet上的商业黄页—UUDI注册服务器上。同时，Web Service采用了文本格式的简单对象访问协议(SOAP)，从而允许它适用于任何设备，因为SOAP 可以通过任何传输层包括通用的HTTP协议进行传输。与传统的包括企业内部的EAI产品相比，基于HTTP协议的SOAP 提供了轻而易举地穿过防火墙的通讯技术，从而允许与B2B 合作伙伴快速集成。SOAP 还有另一项显著的优势：就是和CORBA、Java RMI及DCOM这些以专属二进制格式传送数据相比，SOAP 传输机制对程序语言、操作系统的独立。由于是纯文字XML格式，SOAP 信息可由任何一种程序语言所产生，被任何程序语言、甚至肉眼所解读。这个“late-binding”的特性，正是web Services时代所迫切需要的。这样的集成可以使WEB服务在大多数B2B案例中被快速采纳。
从理论上讲，开发人员可通过调用web Service编程接口就像调用本地服务一样，将Web服务集成到应用程序中，不同的是web Service的API调用可通过互联网发送给位于远程系统中的某一服务。例如，Microsoft Passport服务使得开发人员能够对某应用程序进行验证。通过Passport服务编程，开发人员可以充分利用Passport的基本结构，通过运行Passport来维护用户数据库，以确保它的正常运行、定期备份等。
web Services对软件世界的未来描绘了一个新的蓝图：应用程序在Web上提供服务。让其它机器上的程序透过web的窗口将它的API(应用程序接口)分享出来，直接让网络上其它的程序调用。对Services的调用，可能来自企业内另一台服务器，也可能来自交易伙伴的服务器，或是用户的手机、PDA，甚至 家电等。
4.4 BPEL
Web 服务的业务流程执行语言（Business Process Execution Language For Web Services，缩写为 BPEL4WS 或 BPEL）允许指定业务流程以及它们和 Web 服务的关系。其中指定了业务流程是怎样使用 Web 服务来达到它的目的，还指定了由业务流程提供的 Web 服务。用 BPEL 指定的业务流程是完全可执行的，且在符合 BPEL 的环境间是可移植的。无论实现 BPEL 业务流程的伙伴的 Web 服务是否基于 BPEL，BPEL 业务流程都能和这些 Web 服务互操作
4.5 SOA
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
