本文介绍了Spring Integration如何简化企业应用程序集成，它作为轻量级的API，提供了一种改进传统集成解决方案的方式。文章探讨了为什么需要Spring Integration，其背后的动机和背景，以及如何整合和清理架构。通过具体的示例，展示了如何使用Spring Integration构建一个简单的电子邮件到博客发布系统，从而入门集成开发。此外，还讨论了Spring Integration可能的扩展和局限性，指出它作为ESB的替代方案，具有低摩擦和强大的功能。
为什么要进行Spring整合
Spring Integration是Spring框架的创建者提供的API，专用于企业应用程序集成（EAI）。 在集成方面，不乏“解决方案”：硬编码的Java客户端，其他ESB和消息队列等更传统的应用程序集成技术。 Spring Integration有时会以惊人的方式对每种情况进行改进！ Spring Integration非常轻巧，易于测试。 它几乎没有进入障碍，并且从概念上讲，它将比任何“我自己写的”解决方案都要简单。 从长远来看，它会更加灵活和有弹性。 只写自己的本能可以被抑制。 Spring Integration与EJB，RMI和JMS等标准技术一起使用，并通过允许您在一个地方对复杂的解决方案建模来增强它们。 这大大简化了这些技术的使用。 因为Spring Integration非常轻巧（您与应用程序一起部署了Spring Integration服务器；没有将您的应用程序部署到Spring Integration），所以专注于开发生命周期（便于配置的XML模式，友好的POJO API和强大的XML模式）。与Spring Framework和JEE集成），您会发现Spring Integration比许多其他ESB更合适。
Spring Integration本身具有强大的功能，但是不能否认它受益于Spring框架的强大功能。 例如，配置格式只不过是Spring模式，Spring模式反过来为您提供抽象的bean实例化。 使用Spring Integration几乎没有什么魔力，可以想象地可以编写一个main（String [] args）方法来完成XML配置所做的所有工作。 Spring Integration中提供的许多RPC和消息传递支持都建立在Spring框架的支持之上。 Spring集成配置文件中的所有内容仍然是标准的Spring应用程序上下文，并且受益于常规Spring Bean可用的相同依赖项注入和方面运行时。 使用Spring Integration，应用程序上下文就是总线。 例如，这将启用依赖于应用程序上下文事件的解决方案。 这是没有独立的“运行时”的另一个原因，因为只要存在上下文，总线就存在。
背景
企业应用程序集成（EAI）是一种技术应用程序，定义为应用程序之间的数据和服务集成。 它解决的问题是无限的，解决方案几乎是无数的。 工程师们数十年来一直在构建这些解决方案。 仅在最近的记忆中，我们才确定了该学科的最佳实践并将其分类。
现代EAI的模式通常归因于Gregor Hohpe等人的企业集成模式 [1]。 等等，它对集成解决方案共有的许多集成模式进行了分类和解释。 Hohpe等。 等，列出四种类型的集成样式：
- 文件传输：两个系统生成文件，这些文件的有效载荷是另一个系统要处理的消息。 这样的一个示例是轮询目录或FTP目录中的文件并对其进行处理。
- 共享数据库：两个系统在同一个数据库中查询要传递的数据。 例如，当您部署了两个EAR，它们的实体类（JPA，Hibernate等）共享公用表时。
- 远程过程调用：两个系统中的每个系统都公开另一个可以调用的服务。 EJB服务或SOAP和REST服务就是一个例子。
- 消息传递：两个系统连接到公共消息传递系统，并使用消息交换数据并调用行为。 例如，熟悉的中心辐射型JMS架构。
这些样式是完全不同的，因为没有一种解决方案可以一直使用。 这引起了中间件的整个领域，这些中间件试图基于这些模式来启用解决方案，通常称为企业服务总线（ESB）。 ESB是最终的中间人：它知道如何通过所有协议交流所有语言，并介导传递的消息。
这些建筑风格各不相同，每种都有自己的独特优势。 通常，JEE（或坦率地说，是任何其他现代开发平台）中的标准都不够完善，并且在与其他系统集成时不提供解决方案。 令人惊讶的是-鉴于有多少项目是维护项目-闪亮的新平台中只有很少的技术工具包专门用于利用旧服务或功能。
JEE及其后的Spring在简化企业编程模型方面取得了长足的进步。 JEE标准化并提供了解决常见企业问题的解决方案的商品：数据库访问，远程过程调用，事务，身份验证，目录服务等。EAI解决方案除了以下基础知识外，在JEE中没有直接支持：RPC，消息传递。
JMS，REST和SOAP应该与平台无关，但是假定使用同构消息协议。 例如，在该解决方案需要与旧的大型机应用程序集成时，这是不可能的，该旧的大型机应用程序的输入和输出是批处理文件，存储在某些FTP端点上。
简而言之：现代中间件能够很好地处理正常的案例，而无法处理奇特的用例。 对大多数公告板或电子邮件列表执行订阅过程。 通常，用户将电子邮件发送到某个应用程序，该应用程序最终会接收该电子邮件，将其解析为单词“ subscribe”，然后提取发送电子邮件，然后在将用户注册到邮件列表中之后发送回响应。 第一个本能可能是在CRON上或通过Quartz轮询电子邮件来构建某种计划的应用程序。 或者，也许要检查FTP上的批处理文件，然后再使用它们。 这将很快变得乏味且脆弱。
之后，复杂性急剧上升。 随着时间的流逝-应用程序变得越来越重要-与贸易伙伴，其他应用程序或其他平台集成的负担变得更加昂贵。 每个集成都为系统添加了一个新的点对点通道，必须进行维护。 最终，将每个端点与每个其他端点集成在一起的汇聚通道变成了难以解决的“意大利面条式架构”。
SpringSource的Spring Integration [2]通过简化编程范例对典型的ESB进行了改进。
如何整合和清理架构
企业应用程序集成有很多模式，需要处理的协议（端点）也一样多。 Spring Integration提供了使用与Spring框架相同的惯用法和便利来为ESB样式的解决方案建模的功能。 但是，ESB不仅提供了在不同的技术/协议上对消息传递解决方案进行建模的功能。
ESB的服务
大多数ESB都有一些共同点。 一些最重要的是：
- 路由 ：能够根据条件逻辑或已配置的路由规则来路由消息。
- 消息传递：将消息的有效载荷从一种类型转换为另一种类型–对于任何一种复杂的解决方案都是至关重要的。 在消息传递中，规范数据模型[3]模式要求系统提供通用格式。 自然，处理消息也是ESB的另一个重要部分。
- 中介：适配器和服务映射。
- 复杂事件处理（CEP）：通过关联处理聚合事件的能力。
- 调用：这应该是最明显的。 ESB需要能够使用和提供服务。
通常，ESB将包含以上所列服务之外的日志，审核，身份验证（安全）和管理等机制。
如果您的要求非常复杂，那么ESB可以提供很多价值。 值得将您在JEE平台上已经拥有的东西与ESB可以给您的东西进行对比。 下表比较了一些适用于ESB和JEE替代解决方案的常见用例。
ESB | 传统的JEE中间件 | |
消息队列 | 可通过XML配置，支持所有常用的消息传递模式 | 例如，如果您使用的是Spring JMS支持，则不要太投入。 |
RPC | 通常可以使用，出售和抽象大多数RPC服务 | 同样具有无限的可能性，但没有标准化的方法。 |
整合异构系统 | ESB旨在隔离使用，规范化然后出售不同消息的棘手问题。 | JEE很好地支持了一些用例。 但是，解决方案的确会变得复杂，Swift。 将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和域模型进行编码，或者可以将两者结合使用。 我选择在本文的解决方案中使用一些框架类，以使正在发生的事情变得显而易见并提供一致性。 有时，太多的魔力（虽然对启动者很有用）却令人困惑。
入门
企业应用程序集成速成课程
我们将通过实际构建一个非常简单的应用程序来演示开发周期。 该示例将很容易理解，但不会令人沮丧。 另外，它是一种很酷的工具！ 要求：允许通过电子邮件将博客发送到已知地址，然后该地址为您发布该博客。 这样做有几个很好的理由。
Blogger（[10] Google的博客服务）已经有了。 但是，我在博客上运行Apache Roller（[11]），因此可以使用这种解决方案。 撰写博客所需的惯性很大程度上是没有时间进入“发布”模式的副作用。 Roller的软件迫使用户登录并撰写博客条目。 这样做很麻烦，特别是如果您必须使用“所见即所得”编辑器。 构建此解决方案的第二个最佳理由是，它提供了尽可能少的活动部件的简单集成。 我们可以合理地希望在本文中对此进行剖析。 人为的，但很实用。
构建集成非常容易，而最好的“ IDE”就是纸和笔。 可以使用许多工具绘制图表。 将图转换为您喜欢的ESB的配置格式或工具很简单。 ESB使用相同的术语。 了解行话比了解任何一种工具或ESB更重要。
让我们回顾一下一些ESB 101定义。 消息是绑定到某个端点的有效负载。 端点是通道的末端。 通道是两个端点的命名连接。 通常，消息将从消息传递系统传入，然后传递到不了解该消息传递系统的应用程序。 或者，反之亦然：应用程序可能出售数据但不了解消息系统。 对于这些问题，需要一个通道适配器 。
而且，就是这样！ 这些是您谈论解决方案时需要知道的术语。 其他术语是这些术语之上的变体或规格，或者它们与集成模式有关，而与集成本身无关。
Spring集成概述
Spring Integration应用程序是使用Spring模式配置的简单Java程序。 如果您愿意的话，可以使用常规的Spring配置（而不是模式）来配置所有内容。 模式使事情变得更容易，就像使用模式更易于配置Spring中具有方面的事务功能一样。 Spring Integration为常规概念（集成名称空间）以及适配器特定的配置（如电子邮件或文件类型的配置）提供了方便的架构。
Spring Integration应用程序处理通过通道传播的消息的概念。 该消息的生命始于通常由适配器欢迎的端点。 当消息在处理管道中移动时，它可能会在总线内部进行转换，路由到其他通道，拆分，响应或中止并通过无效消息通道发送。 如果您使用Spring Integration接口进行编程-我们将在很大程度上使内容保持一致和尽可能清晰-那么您将处理一个Message对象，该对象类似于图1。
消息类是正在处理的消息的有效负载周围的包装器。 在这里，您可以方便地访问有效负载本身-然后可以将其强制转换-以及可以检查或更改的消息标题。 Spring Integration不需要您使用Message接口。 您的应用程序可能会公开一些期望参数与消息有效负载类型相同的方法。 例如，来自文件适配器（可以从文件系统发送的文件系统中提取的消息的适配器）发出的消息可以作为java.io.File的实例进行路由。
让我们看一下示例集成，该集成将接收到的电子邮件发送到电子邮件地址，进行转换，然后将其发布到博客。
我们示例中的配置位于src / main / resources / integrationsContext.xml中。 完整的源代码可以从这里下载。 该文件一开始看起来很正常。 XML的顶部是一个bean，其作用是将属性文件中的变量宏替换为该XML配置脚本。 然后，导入另一个包含我们要在此集成中使用的简单服务的spring文件。 没什么有趣的。
然后开始有趣的部分，依次声明4个bean：服务激活器（newBlogPublishingServiceActivator），转换器（emailToBlogTransformer），处理程序（outboundBlogPostHandler）和过滤器（emailsInFilterAgainstWhitelist）。 稍后将在配置中使用Bean。
实际配置的第一个节是poller元素，它是文档的默认轮询器。 轮询器的确切含义是：轮询不同端点以进行更改的机制，如果认为某些事情已更改，则让适配器对它做出React。 我们将其中一个配置为整个Spring Integration配置的默认轮询器，因为它比重复配置更容易。 见图2。
接下来的三个元素是三个通道的声明。 它们没什么意思-它们只是命名为渠道。 没有端点或适配器的通道是无用的。 见图3。
下一行配置电子邮件适配器。 电子邮件适配器查找进入系统的电子邮件，并将它们放在我们在上面声明的名为emailsIn的通道中。 您知道电子邮件系统在收到电子邮件时不会广播事件。尽管有例外情况（例如IMAP IDLE，Spring Integration也支持），但是通常您需要轮询电子邮件帐户中的新电子邮件。 如果有新消息，则一次读取一次，然后传递到处理管道中的下一个组件。 见图4。
该消息现在在通道emailsIn上传播，该电子邮件将发送到该通道的下一个组件，即转换bean。 转换器接受赋予它的任何内容，以某种方式对其进行更改（我们稍后将对此进行更多讨论），然后继续发送。 在这种情况下，将为Transformer提供一条包含MimeMessage类型的有效负载的消息，该消息用于创建BlogPost类型的对象。 BlogPost是特定于我们系统的域类。 在这里，我们将其用作DTO，但显而易见的是，它的来源无关紧要-如果需要，可以根据您的域进行工作。 这是转换器元素的最佳用法：从消息传递格式转换为系统通用的格式。 这与规范数据模式有关。
生成的BlogPost被包装在一条新消息中，该消息包含原始消息的标头。 标头正是您所期望的：可以查询特定于请求的值以获取额外的元数据。 例如，在内部，Spring Integration Bus会为所有内容分配一个ID。 该ID作为标题值公开，供您使用。 该ID被保证是唯一的。
然后，该消息将发送到过滤器emailsInFilterAgainstWhitelist，该过滤器将查询有效载荷以获取发件人的值。 这是为了确保您不会向博客发送垃圾邮件！ 这个示例非常简单，就像整个解决方案一样。 您可以想象查询Spring Security或LDAP或其他比这更好的工作。 见图5。
XML配置的最后一部分是service-activator元素，它接受赋予它的内容并可以使用它。 在这种情况下，我们告诉Spring Integration在ID为newBlogPublishingServiceActivator的bean上调用方法pubishIncomignBlogEntry。 该方法完成了实际获取有效负载并将其发送到将发布博客条目的服务的工作。
然后我们完成了。 看起来可能很多...但是基本上是有关XML的4节。 为了示例的清楚起见，通道的声明。 轮询器元素仅定义一次，因此在上下文中需要轮询器的所有内容都可以使用默认值。
可能的扩展
我们定义了三个渠道和四个组成部分。 通过设计构成我们解决方案的组件，我们使它们可在其他集成解决方案中重用。 集成流程不限于此示例。 我们可以在更复杂的集成中潜在地重用该转换器，过滤器甚至服务激活器。 唯一的重构将是Spring Integration XML文件。 有很多可能性。 好的ESB就是这样做的：它将流程设计和配置延迟到尽可能晚的时间。
很容易想象我们可以从这里获取解决方案。 以下是一些可能的补充。
- 使用jBPM（[12]）为某种审计工作流程增加对系统的支持。 假设我们要向解决方案中添加业务流程管理（BPM），以便在收到消息时将其存储在某种工作队列中，以供编辑者批准。 编辑过程可以根据需要在工作流引擎中进行。 当最终博客内容获得批准时，编辑者可以将最终条目发送给具有相同关键字或标识关键字的同一电子邮件，这些关键字或标识关键字可以用作相关ID。 相关性ID可用于使集成解决方案继续进行，以支持更新的条目。 参见[13]。
- 使用Spring Integration来“多播”博客。 当然，博客已发布。 但是这里还有另一个问题，最好使用一个古老的哲学问题来提出：“如果在树林中更新了RSS feed，并且没有人对其进行投票，那么它真的得到更新了吗？” 嗯，也许我在解释！ 博客的标题也可以通过Twitter宣布，可以使用收件人列表模式（[16]）通知博客聚合器（[14]，[15]等）。
- 更新过滤器示例以针对某种真实的授权服务进行身份验证。 也许使用LDAP或Spring Security。
- 除简单的电子邮件外，多元化的发布支持。 FTP，WebDav，文件系统（我什至在电子邮件适配器的源代码中留下了简单的文件目录适配器配置注释）等都是可行的入站类型。 一个更高级的示例可能启用来自移动客户端的SMS消息。 （当然，我不确定有多少人正在用手机编写博客条目。您永远不会知道。但是，只有一种发现方法！）。 目前尚无对此的支持，但是仔细检查一下Spring Integration源代码，就会发现构建自己的适配器很容易。 您可能会使用SMSLib [17]之类的东西。
Spring集成可能不足之处
Spring Integration的全新功能-非常强大。 您可以确信，它具有SpringSource的强大功能，并且会不断发展。 但是，这并不意味着它是完美的-远非如此！ 应用程序集成不是一个新领域，并且有数十年的解决方案和体系结构可以适应。 传统上，应用程序集成的某些用途涉及重量级适配器，例如用于与SAP或JDEdwards OneWorld集成的适配器。 Spring Integration不直接支持其中一些特定情况。
虽然Spring Integration确实提供了很多开箱即用的功能，但是它缺少对某些非常典型的适配器（如SFTP，HTTPS或AS2）的支持。 目前，某些专有解决方案将更好地支持这些要求。 有些解决方案可能会非常昂贵，因此您可以尝试改编第三方库并为Spring Integration编写自己的适配器。 如果您对Spring Integration编写适配器非常简单，那么您会感到惊喜。 只需看一下jSch [18]或Jakarta Commons VFS [19]或Jakarta Commons Net [20]，就可以找到解决方案的起点。
最后，Spring Integration可能不是您的最佳解决方案（现在）。 如果没有，请不要担心。 您在本文中学到的概念可以很好地转化为其他解决方案。 去吧，有罪不罚！
结论
Spring Integration代表了一种简洁，简洁的EAI方法和强大的替代ESB。 当今的ESB解决方案繁重，并且在某些环境中很难引入。 Spring Integration代表了一种强大的，低摩擦的替代方案，可以解决一些最复杂的集成问题。
资源资源
1个Amazon.com页面上的“企业集成模式”
2 Spring Source的Spring Integration， http：//www.springsource.org/spring-integration
3企业应用程序集成，“规范数据模型”， http：//www.eaipatterns.com/CanonicalDataModel.html
4 JCA规范， http：//java.sun.com/j2ee/connector/
5 BEA Tuxedo， http：//www.oracle.com/products/middleware/tuxedo/tuxedo.html
6 Mule主页， http：//mule.mulesource.org/display/MULE/Home
7 Mule Forge，Mule扩展的代工厂， http：//www.muleforge.org
8 Apache ServiceMix， http： //servicemix.apache.org/home.html
9 JSR 208，Java业务集成， http：//jcp.org/aboutJava/communityprocess/final/jsr208/index.html
10 Blogger，Google的博客服务， https：//www.blogger.com/start
11 Apache Roller， http：//roller.apache.org/
12 JBoss.org的jBPM信息， http： //www.jboss.org/jbossjbpm/
13企业应用程序集成，“聚合器”， http：//www.eaipatterns.com/Aggregator.html
14 Dzone博客聚合器， http： //www.dzone.com
15 JavaBlogs博客聚合器， http：//www.javablogs.com
16企业应用程序集成，“收件人列表”， http：//www.integrationpatterns.com/RecipientList.html
17 SMSLib，一个Java SMS库， http： //smslib.org
18 jSch， http：//www.jcraft.com/jsch/
19 Apache Commons VFS， http：//commons.apache.org/vfs/
20雅加达公共网络， http：//commons.apache.org/net/
21我的博客，http：//www.joshlong.com
关于作者
乔希·朗（Josh Long）是一位企业架构师，演讲者，是一位来自亚利桑那州凤凰城的充满爱心的丈夫。 当他不使用代码时，可以在本地Java用户组或本地咖啡馆找到他。 他在http://www.joshlong.com （[21]）上维护着一个博客，可以通过josh@joshlong.com与他联系 。
287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
