如何巩固、梳理架构
企业应用集成有很多模式，同样有很多需要处理的协议。Spring Integration提供ESB风格解决方案的建模能力，但使用方法及其便利性与Spring框架并无二致。ESB不仅能提供消息解决方案的建模能力，还有其它不同的技术/协议。
ESB中的服务大多数ESB产品都有一些共性。其中最重要的有：
路由：能按条件逻辑或配置好的路由规则路由消息。
消息传递：对任何复杂的解决方案来说，将消息的有效负载从一种类型转换为另一种类型都至关重要。在消息传递中，标准数据模型[3]模式要求系统提供通用的格式。处理消息自然也是ESB的另一个重要组成部分。
调解：适配器和服务映射。
复杂事件处理（CEP）：根据相关性将总线上的事件处理为聚集的能力。
调用：这应该是最明显的一个。每个ESB都要能消费、提供服务。
除了上面列出的服务，ESB通常还要包括记日志、审计、认证（安全）和管理等机制。
如果你的需求更加复杂，那ESB会提供很大的价值。对比你在JEE平台中已经获得的东西和ESB能带给你的东西很有价值。下表比较了适合于ESB、可使用JEE作为替代解决方案的常见用例。
ESB
传统JEE中间件
消息队列
可通过XML配置，支持所有常见的消息模式。
比如说，如果你使用Spring JMS支持就不会很复杂。
RPC
通常可以消费、提供和提取大部分RPC服务
同样有无限的可能性，但没有标准方法。
整合异构系统
ESB旨在分离消费、标准化、提供不同消息过程中的不确定性。
JEE只能很好地支持一些用例。但这些解决方案往往会很快让事情变得复杂。SOAP消息到FTP？批处理文件记录到EJB调用？JEE对每一个都只提供了一半的解决方案。
安全
支持良好
支持良好
传统的主机系统
对JEE等支持的互操作习惯有非常好的支持，包括批处理文件
除了CORBA，JEE对旧系统没有更多的支持，除非这些系统的前端已经使用了SOAP。
灵活的路由
路由决策在整个被支持的组件中尽可能延迟
JMS、EJB等技术指定可用性和路由的配置不尽相同。很难找到一个鸟瞰图。
集成非标准需求的易难性
相对容易，特别是用Spring Integration作为所有内容的POJO，也不用和应用服务器集成；相反，你的解决方案在所有ESB产品中并不是标准的
需要深入了解JCA[4]，或是类似于BEA Tuxedo[5]这样一个系统。解决方案在所有JEE应用服务器中都是标准的（尽管结果可能会有所不同）。
流行的解决方案
Spring Integration是新生事物，当然会遭受质疑。Mule[6]是一个非常受欢迎的的ESB产品，值得密切关注。Mule似乎有很大的影响力，在解决方案的灵活性上也令人印象深刻。通过MuleForge[7]实现的开源扩展使其成为几乎所有问题令人信服的选择。它是一个标准的服务器：能部署并运行解决方案。Maven插件有助于开发的生命周期。
ServiceMix[8]也比较受欢迎。ServiceMix原本基于Java业务集成规范（JBI；JSR 208[9]）。JBI是构建ESB产品的JCP规范。由于出身JBI，ServiceMix不如Mule那般灵活，但它正在进行改进。容器正转向OSGi基础设施。
这里没有列出其它所有有价值的ESB产品，要是有机会你还是要对它们多了解一下。有些非常有价值，值得研究。
Spring Integration开箱即用的功能表现得很好，非常易于使用。开发用例非常引人注目：如果你已经被POJO和近年来测试友好的框架宠坏了，那这个框架也是你的拿手好戏。只要你愿意，你可以使用接口或标准框架类，你还可以完全为POJO和你的领域模型进行编码，或者，你可以将两者结合使用。本文中，我选择在解决方案中使用一些框架类，以让发生的事情明确，并提供一致性。有时候，太过不可思议反而会让人困惑，尽管对入门来说很有成效。