Spring Integration是Spring框架创建的又一个API，面向企业应用集成（EAI）。说到集成，并不缺“解决办法”：硬编码的Java客户端、其它ESB产品，还有消息队列等更加传统的应用集成技术。Spring Integration对以上各种解决方法都有所改进，改进的方式有时还颇具戏剧效果。Spring Integration非常轻量、易于测试；几乎没有入门门槛，概念上比任何“自己编写”的解决方法都要简单。长远来看，它更为灵活、更具有适应性。一旦使用，你就会恋上它。Spring Integration可以和EJB、RMI、JMS这些标准技术协同使用，能让你在一处对复杂的解决方法进行建模，从而对标准技术有所增强。这在很大程度上简化了这些技术的使用。由于Spring Integration非常轻量（与应用一起部署Spring Integration服务器，不用将应用部署到Spring Integration中去），而且很注重开发生命周期（方便配置的XML schema、友好的POJO形式API、与Spring框架和JEE的强大集成），所以你会发现跟其它很多的ESB产品相比，Spring Integration要更加适用。
Spring Integration本身就很强大，毋庸置疑，它从Spring框架中得到了强大的支持。比如说，配置格式无非还是Spring schema，这些配置格式反过来又为你抽象出了bean示例。Spring Integration的使用没什么神奇之处，你可以自信地编写main(String [] args)方法来完成XML配置所做的一切。Spring Integration中很多对RPC和消息的可用支持都以Spring框架的
支持为基础。Spring Integration配置文件中的所有内容仍是标准的Spring 应用上下文，和通常的Spring bean一样，它也受益于依赖注入和运行时可用的方面（Aspect）。使用Spring Integration，应用上下文就是总线了。比如这能使依赖于应用上下文事件的解决方案成为可能。这是没有独立“运行时”的另一个原因，因为只要上下文可用，总线就存在。
背景
企业应用集成（EAI）是集成应用之间数据和服务的一种应用技术。它解决无限的问题，解决方案也几乎没有穷尽。工程师们已经为这些解决方案的创建努力了数十年。就在最近，我们才确定了原则的最佳实践，并对这些方案进行了分类。
现代EAI的模式通常要归功于Gregor Hohpe等人编著的《企业集成模式》[1]，该书对集成解决方案共有的很多集成模式进行了分类和阐述。Hohpe等人列出了四种集成风格：
1. 文件传输：两个系统生成文件，文件的有效负载就是由另一个系统处理的消息。该类风格的例子之一是针对文件轮询目录或FTP目录，并处理该文件。
2. 共享数据库：两个系统查询同一个数据库以获取要传递的数据。一个例子是你部署了两
个EAR应用，它们的实体类（JPA、Hibernate等）共用同一个表。
3. 远程过程调用：两个系统都暴露另一个能调用的服务。该类例子有EJB服务，或SOAP和REST服务。
4. 消息：两个系统连接到一个公用的消息系统，互相交换数据，并利用消息调用行为。该风格的例子就是众所周知的中心辐射式的（hub-and-spoke）JMS架构。
这些风格迥然不同，因为没有一种解决办法能在任何情况下都良好运转。这导致整个中间件领域都在基于这些模式寻求可用的解决办法，通常被称为企业服务总线（ESB）。ESB是最终的中间人：它知道如何使用各种语言在各种协议上调解传递的消息。
这些架构风格是不同的，它们各有所长。通常，JEE标准存在着不足（坦率地说，现今的任何开发平台都是一样），与其它系统集成时这些标准并不能提供解决方案。考虑到很多项目都是维护项目，新平台中又有多少技术会使用旧服务或功能呢？少之又少，这太令人惊讶了。
JEE以及后来的Spring在简化企业编程模型方面都有了长足的进步。JEE进行了标准化并商
业化了常见企业问题——数据库访问、远程过程调用、事务、认证、目录服务等等。除了基本的RPC和消息，JEE中并没有对EAI解决方案的直接支持。
JMS、REST和SOAP都与平台无关，但这是假设有单一的消息协议。比如说，有一个旧的主机应用，其输入、输出都是存放在一些FTP端点上的批处理文件，解决方案要求集成该应用就是不可能的。简单来说：现今的中间件能很好地处理常见问题，但在特殊情况的处理上就有所不足了。对大多数公告板或列表，还是采取订阅流程。通常，用户给应用发送，应用最终接收、针对“订阅”解析邮件、提取发送的邮件，然后在邮件列表中登记用户后发送响应。第一反应可能就是基于CRON或通过Quartz构建定时器应用，以轮询，或是为稍后使用的批处理文件去检查FTP。这种办法很快就会变得单调而脆弱。
之后复杂性会急剧上升。随着时间的推移，应用变得更为重要，与商业伙伴、其它应用、其它平台集成的负担也变得更加昂贵。对必须进行维护的系统来说，每次集成都增加了系统间点对点的新通道。最终，集成各个端点的通道就会成为一个维持不了的烂摊子、复杂的架构。
SpringSource的Spring Integration[2]简化了编程方式，以此改进了标准的ESB。
如何巩固、梳理架构
企业应用集成有很多模式，同样有很多需要处理的协议。Spring Integration提供ESB风格解决方案的建模能力，但使用方法及其便利性与Spring框架并无二致。ESB不仅能提供消息解决方案的建模能力，还有其它不同的技术/协议。
ESB中的服务
大多数ESB产品都有一些共性。其中最重要的有：
1. 路由：能按条件逻辑或配置好的路由规则路由消息。
2. 消息传递：对任何复杂的解决方案来说，将消息的有效负载从一种类型转换为另一种类型都至关重要。在消息传递中，标准数据模型[3]模式要求系统提供通用的格式。处理消息自然也是ESB的另一个重要组成部分。
3. 调解：适配器和服务映射。
4. 复杂事件处理（CEP）：根据相关性将总线上的事件处理为聚集的能力。
5. 调用：这应该是最明显的一个。每个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业务集成规范（spring系列框架有哪些JBI；JSR 208[9]）。JBI是构建ESB产品的JCP规范。由于出身JBI，ServiceMix不如Mule那般灵活，但它正在进行改进。容器正转向OSGi基础设施。
这里没有列出其它所有有价值的ESB产品，要是有机会你还是要对它们多了解一下。有些非常有价值，值得研究。
Spring Integration开箱即用的功能表现得很好，非常易于使用。开发用例非常引人注目：如果你已经被POJO和近年来测试友好的框架宠坏了，那这个框架也是你的拿手好戏。只要你愿意，你可以使用接口或标准框架类，你还可以完全为POJO和你的领域模型进行编
码，或者，你可以将两者结合使用。本文中，我选择在解决方案中使用一些框架类，以让发生的事情明确，并提供一致性。有时候，太过不可思议反而会让人困惑，尽管对入门来说很有成效。
使用入门
企业应用集成速成
我们实际构建一个非常普通的应用，以此来演示开发周期。该示例易于理解，但却没有斧凿之嫌。此外，它还是一个很酷的工具。需求是：允许通过将博客发送到一个已知地址，然后由该地址发布博客。这么做有一些好的理由。
Blogger（[10]Google的博客服务）已经有这个功能。但我在我博客上运行Apache Roller（[11]），所以我可以使用这个解决方案。写博客的惰性很大程度上是没时间进入“发布”模式的副作用。Roller的软件强迫用户登录并撰写博客文章。这么做很麻烦，尤其是你每次都不得不对付WYIWYG（所见即所得）编辑器。第二，构建该解决办法最好的理由是，它提供了了一种简单的集成，能与尽可能少的运转部分集成在一起。我们可以在本文中仔细分析该办法。尽管这是假设的，但很有实际用途。
构建集成非常简单，最好的“IDE”只是一张纸和一支笔。可以在很多工具中画图。将图转换成你喜欢的ESB配置格式或工具非常简单。ESB使用相同的术语。了解术语要比了解任何一种工具或ESB更为重要。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论