EAI方案的提供商已经可以在他们的方案中管理上期所涉及的中间件栈。从企业投资这种方案的角度来说，功能的繁多不是问题。

　　然而，EAI方案仍因为某些缺点受到批评：

　　专有的开发接口：集成逻辑（进程，转换规则，工作流服务等）不能被移植到EAI解决方案中。这一事实意味着，与企业有密切联系的关于结构性的IS方面的厂商，专业顾问通过覆盖发送价格，并削弱了相关集成耐久性的发展。

　　专有的通信协议：虽然大范围内，在通过EAI解决方案转让和监测邮件方面没有困难，在不同的厂商的EAI解决方案上同样不适用的。目前，如果在两个单独的EAI平台上，它是不可能监督端对端的业务流程的。虽然SOAP/HTTP不提供EAI解决方案的互操作性的桥梁，它不仅解决了最基本的无会话RPC 的发出的问题，俯瞰其他基本架构服务（安全，保证交付等）。这限制了企业两个不同的EAI解决方案之间的互操作性。

　　应用服务器之间和EAI解决方案之间缺乏一致性：厂商往往提出论点，即连接器能够整合现有的应用程序而不改变其代码。这是真实的。然而，事实是一个“智能”网络的通讯应用往往影响其职能范围，这往往需要加以改进。例如，应用程序可能需要与EAI的工作流程管理器沟通，或只是提供一条信息到一台连接到企业应用集成解决方案总线的远程服务器后，交易已被处决。接口往往通过一些专有的标准的XML接口（如C或形式的Java API）应用服务器进入整合服务。如SOAP/HTTP，仍然十分简陋，不完全符合要求。

　　过度许可费用：主要的EAI厂商以功能丰富的战略我为基础。由此而来的高研发成本导致高价格，这使得EAI解决方案难以进入所有的大型企业。一个EAI中间件堆栈体积也很大（如：一些连接器），而且维护昂贵。

　　缺乏可扩展性：大多数的EAI解决方案基于在集中星型结构架构原则上的机构。以这种模式大规模扩大EAI架构很难。迁入总线型架构，驱逐的全部或部分基于分布式异步中间件的中央集成逻辑“智能”的连接器，通过EAI市场的引导者却已经成功。我们应该指出，一个总线架构对于部署和管理更为复杂，但是也可以作为hub & spoke架构来配置。

图1：  EAI方案从轮辐式结构向总线结构转化

图2： 各个厂商间的不同EAI方案破坏了服务质量(QoS)

　　除了EAI方案本身的缺点和其他一些强制性标准的问题外，这种架构的设计和实现也存在困难。比如：

• 　　很难调和每个应用程序的数据模型和安全模型。
• 　　很难在组成部分中做出功能独立的体系结构的应用模块。
• 　　EAI项目不同的小组之间的通信困难。
• 　　政治上的困难，有关的权力再分配所造成的IS的城市化。
• 　　开发人员和管理员的困难是在经济背景下，通过减少预算和劳动力，将新的架构模式集成。

　　根据Forrester 研究中心估计，由于以上原因，“35%的EAI项目在指定的预算和期限内都没有完成”，而且“EAI”这个名词已经出现在流行词语的黑名单里，等于被IT管理者所摒弃。许多EAI方案的提供商也不再提及，取而代之的是像“应用集成”，“集成架构”等新提法。

　　不管用什么称呼或技术，应用集成始终有个问题悬而未决。尽管和EAI本身的机密相关的问题能够被厂商和标准化组织所解决。但市场看上去并没有朝这个方向迈进，而是迈向一个软件的新时代：ESBs。