EAI将应用程序连接在一起，这致使很长一段时间，企业应用集成都是个大新闻。然而，随着面向服务架构（SOA）的出现，EAI就时常被忽略了。实际上，根据实践者所述，他们在运行业务的时候同时用到了EAI和SOA技术。

　　举一个最好的例子，SAP环境已经被看做是SOA的一种转移，很庆幸SAP本身提供的一些工具。但是这并不是个简单的选择。SAP技术解决方案部门高级副总裁兼总经理Sanjay Chikarmane表示现在和很多年前的不同之处在于几乎所有现代化应用都有一些标准接口已暴露或者可以暴露，典型地是基于Web服务。然而，他指出，正因为SOA的出现，EAI并没有离开，EAI是SOA一种很好的互补功能。

　　在一些案例中，EAI是至关重要的功能。例如，他指出，如果你有一个使用Web服务来暴露采购订单的应用程序，Web服务可能符合某一标准，但是正在传输的数据，可能没有类似的标准。“这样的事情通常都有两部分，标准部分和数据部分，”他说。

　　已经暴露的数据，像采购订单，在SAP应用程序中可能以一种方式表达，但是在企业的其他应用程序中采用不同的方式表达。因此，Chikarmane指出，这中间你需要一个中介来将一个应用程序的PO版本翻译成另一个应用程序的PO版本。

　　“这也就是EAI的用武之地了，不管这两端是否使用Web服务。仍旧需要让数据对于两端都是可理解的，”他如是说道。

　　像其他一些主要的软件厂商，随着集成需求的出现，SAP开发了自己的EAI产品，该产品最终包含了SOA。最初叫做Exchange Integration (XI)，它是一种EAI工具，NetWeaver产品线的一部分，被重新命名为NetWeaver Process Integration (PI)，有时就称为SAP PI。该产品现在包含SOA 功能。最新版本为PI 7.3，可用于集成SAP和SAP应用、SAP和非SAP应用，甚至是非SAP和非SAP应用。

　　咨询公司Nagarro SAP实践主管Manish Agarwal认为，SAP PI对于EAI和SOA都很重要。但是，他指出，因为SAP相对于市场比较晚，很多SAP 用户已经用其他来自第三方的工具标准化了，像TIBCO。他们中的很多人几乎继续使用其他中间件，实现非SAP 集成。然而，他强调，SAP PI是一个基于标准的产品，因此，它能够充分地与其他非SAP产品实现交互。“SAP PI的好处是，相对于其他EAI产品，它可以轻松地同SAP集成，因为它是SAP的产品。因此，这里面有一些即开即用的内容，允许快速集成到SAP中，”他说。

　　KPIT Cummins NetWeaver Services实践总监Mayur Khera认为，EAI和SOA之间的选择需要具体问题具体分析。“从架构的角度来看，可能尽可能多的倾向于SOA更好，除非第三方网站或者公司不接纳它，”他说。例如，他指出银行网站可能提供电子汇款功能，但是一些银行需要保险费用，并不是所有客户都准备支付。“这是一个客户驱动的抉择，但从集成师的观点来看，我们鼓励采纳SOA,”他补充道。

　　Khera表示当需求是SAP大牌SAP的时候，他们通常使用SAP PI EAI。“当我们有一个需求是，接口需要是面对非SAP应用程序，我们就利用基于WEB服务的功能，在PI内部编写，因此我们可以冲一个进程到另一个进程重用这个接口。”

　　“我所强调的是我不会同SAP PI联姻的。关键在于SOA原则需要保持强健，架构师需要理解这种原则。然后，任何工具都可以使之成功，”他补充道。