开发学院软件开发Java Spring Integration入门 阅读

Spring Integration入门

 2009-11-10 00:00:00 来源:WEB开发网   
核心提示:为什么使用Spring Integration Spring Integration是Spring框架创建的又一个API,面向企业应用集成(EAI),Spring Integration入门,说到集成,并不缺“解决办法”:硬编码的Java客户端、其它ESB产品,现在的ESB方案沉重且很难引入到一

为什么使用Spring Integration

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等人列出了四种集成风格:

文件传输:两个系统生成文件,文件的有效负载就是由另一个系统处理的消息。该类风格的例子之一是针对文件轮询目录或FTP目录,并处理该文件。

共享数据库:两个系统查询同一个数据库以获取要传递的数据。一个例子是你部署了两个EAR应用,它们的实体类(JPA、Hibernate等)共用同一个表。

远程过程调用:两个系统都暴露另一个能调用的服务。该类例子有EJB服务,或SOAP和REST服务。

消息:两个系统连接到一个公用的消息系统,互相交换数据,并利用消息调用行为。该风格的例子就是众所周知的中心辐射式的(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产品都有一些共性。其中最重要的有:

路由:能按条件逻辑或配置好的路由规则路由消息。

消息传递:对任何复杂的解决方案来说,将消息的有效负载从一种类型转换为另一种类型都至关重要。在消息传递中,标准数据模型[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和你的领域模型进行编码,或者,你可以将两者结合使用。本文中,我选择在解决方案中使用一些框架类,以让发生的事情明确,并提供一致性。有时候,太过不可思议反而会让人困惑,尽管对入门来说很有成效。

使用入门企业应用集成速成

我们实际构建一个非常普通的应用,以此来演示开发周期。该示例易于理解,但却没有斧凿之嫌。此外,它还是一个很酷的工具。需求是:允许通过电子邮件将博客发送到一个已知地址,然后由该地址发布博客。这么做有一些好的理由。

Blogger([10]Google的博客服务)已经有这个功能。但我在我博客上运行Apache Roller([11]),所以我可以使用这个解决方案。写博客的惰性很大程度上是没时间进入“发布”模式的副作用。Roller的软件强迫用户登录并撰写博客文章。这么做很麻烦,尤其是你每次都不得不对付WYIWYG(所见即所得)编辑器。第二,构建该解决办法最好的理由是,它提供了了一种简单的集成,能与尽可能少的运转部分集成在一起。我们可以在本文中仔细分析该办法。尽管这是假设的,但很有实际用途。

构建集成非常简单,最好的“IDE”只是一张纸和一支笔。可以在很多工具中画图。将图转换成你喜欢的ESB配置格式或工具非常简单。ESB使用相同的术语。了解术语要比了解任何一种工具或ESB更为重要。

让我们回顾一些ESB 101定义,权当补习了。消息是传递到端点的有效负载。端点是通道的终点。通道是两个端点间被命名的连接。通常,消息来自于消息系统,被分发到不了解消息系统的应用中。同样的事情或者会反过来以其它方式出现:应用可能会发送数据,但并不理解消息系统。针对这些问题,就需要通道适配器了。

就是这样!这些就是你需要了解的条目,以便讨论解决方案。其它条目都是这些条目之上的变异或详细说明,或者是关于集成模式的,而不是关于集成本身。

Spring Integration概况

Spring Integration应用就是使用Spring schema配置的简单Java程序。如果你倾向于用常规的Spring配置来配置一切,就可以不使用schema。Schema会使事情更为简单,这和用schema配置使用Spring中方面的事务功能会更加简单大致一样。Spring Integration为一般概念(集成命名空间)提供了方便的schema,还有适配器的具体配置,比如针对电子邮件或文件类型的配置。

Spring Integration应用处理从通道传递过来的消息概念。消息的生命周期始于一个端点,通常是对适配器做出的反应。消息在经过处理管道的过程中,会在总线内被转化、路由至其它通道、分发、响应,或者被中断并发送到一个死消息通道中去。如果你使用Spring Integration接口编程——我们将在很大程度上尽可能保持内容一致并明确,那你要处理Message对象,Message对象如图1所示。

Spring Integration入门

Message类是个包装器,包装被处理消息的有效负载。对它进行操作,很容易获得有效负载和消息头,你可以对有效负载进行类型转换,可以检查、改变消息头。Spring Integration不要求你使用Message接口。你的应用可以暴露一些方法,这些方法的参数类型跟你消息有效负载的类型相同。比如说,来自于文件适配器(可以从文件系统发送消息的适配器)的消息可能会被改为java.io.File实例。

让我们来看一个集成例子,它把电子邮件发送到一个电子邮件地址,转换电子邮件后再将其发布到博客中。

示例的配置在src/main/resources/integrationsContext.xml中。

integrationsContext.xml文件乍看起来很平常。XML顶端的bean负责将属性文件中的变量宏替换到该XML配置脚本中。后面导入了另一个Spring文件,该文件包含本集成中要使用的简单服务。再没什么特别的了。

接下来继续看相继定义的四个bean,它们还是有意思的:服务催化器newBlogPublishingServiceActivator、转换器 emailToBlogTransformer、处理器outboundBlogPostHandler和过滤器 emailsInFilterAgainstWhitelist。这四个bean会在配置的后面部分里用到。

实质配置的第一段是poller元素,它是文档的默认轮询器。确切来说,轮询器是一种机制,在有变化时轮询不同端点,并在感知到某些内容发生变化后让适配器对其做出响应,就像一个事件。出于简单,我们为整个Spring Integration配置一个默认的轮询器。见图2。

Spring Integration入门

接下来的三个元素是三个通道声明。他们毫无意义,只是命名的通道而已。没有端点或适配器的通道毫无用处。见图3。

Spring Integration入门

下一行配置了电子邮件适配器。电子邮件适配器查找发入系统的电子邮件,并将其放入名叫emailsIn的通道,该通道已经在上面定义了。电子邮件发进来时,电子邮件系统并不会播报事件。在出现异常的时候(比如Spring Integration也支持的IMAP IDLE),你通常需要一些东西来轮询电子邮件帐户以查找新的电子邮件。只要有新消息,它们就一次阅读一条消息,并将该消息传递到处理管道的下一个组件。见图4。

Spring Integration入门

图片看不清楚?请点击这里查看原图(大图)。

现在消息在emailsIn通道中传递,被传递到通道的下一个组件——转换器bean。转换器获取所有给它的内容,以某种方式改变消息(我们稍后会详细讨论这一点),然后顺便发送出去。这种情况下,会给Transformer给定一个包含MimeMessage类型有效负载的Message,转化器用于创建BlogPost类型的一个对象。BlogPost是我们系统特定的一个领域类。我们在这里把它作为DTO来用,但很显然,它来自哪里并不重要 ——如果你愿意,根据你的领域去处理它也可以。Transformer元素的最佳用法是:将消息格式转换为系统常见的格式。这跟标准数据模式相关。

由此产生的BlogPost封装在一条新消息中,其中包含原始消息的头信息。头信息正是你期望的那样:特定于请求的值,可以对其访问以获取更多的元数据。例如,从内部来说,Spring Integration总线给每样内容分配一个ID。该ID暴露为头信息值供你使用。该ID保证是唯一的。

然后消息被发送给过滤器emailsInFilterAgainstWhitelist,该过滤器访问有效负载获取发送者的值。这样做是为了确保在发布到博客的过程中你不会收到垃圾邮件。这个例子跟整个解决方案一样,简单的有些不合常理。你可以想象是去查询Spring安全或LDAP,或是比这个做得还要好的东西。见图5:

Spring Integration入门

图片看不清楚?请点击这里查看原图(大图)。

XML配置的最后一段内容是service-activator元素,它获取所有给它的内容并进行处理。在这种情况下,我们告知Spring Integration调用ID为newBlogPublishingServiceActivator的bean的 pubishIncomignBlogEntry方法。该方法负责实际获取有效负载,并将有效负载发送给发布博客条目的服务。

然后我们就大功告成了。内容看起来很多,但实际上就是相关XML的四段内容。声明通道是为了讲清楚例子。poller元素只定义了一次,这样,上下文中需要轮询器的所有内容都可以利用这个缺省的轮询器了。

可能的扩展

我们定义了三个通道、四个组件。通过这样设计构成解决方案的组件,我们能让这些组件在其它集成解决方案中可以重用。集成流程不仅仅限于此示例。我们可能会在更复杂的集成中重用转换器、过滤器,甚至是服务催化器。唯一需要重构的是Spring Integration XML文件。有很多可能性。一个好的ESB应该做到:尽可能晚地重构流程设计和配置。

这里我们很容易就能想象到可以在什么地方采用该解决方案。下面是一些可能的补充。

对于某些审计工作流,使用jBPM([12])对系统增加支持。假设我们想在解决方案中添加业务流程管理(BPM),比如在消息传入时,以某种工作队列的分类存储该消息,以便编辑器进行核准。编辑过程可以处理得跟工作流引擎内部要求的一样。最终的博客内容核准后,编辑器把定稿发送到同样的电子邮件地址,带着某种关键字或识别出能用作相关ID的关键字。相关ID可用来让集成解决方案继续进行,主要表现在更新的条目。见[13]。

使用Spring Integration“组播”博客。当然,博客已经发布了。但还有一个问题,用旧的哲学问题来描述再合适不过了:“如果在woods中RSS订阅已经更新了,而没有人轮询到它,那博客算真正更新了吗?”呃,也许我只是讲了大概的意思!也可以通过Twitter传播博客标题,可以使用接收者列表模式([16])通知博客聚合器([14]、[15]等)。

更新过滤器例子来验证某种真正授权的服务。也许能使用LDAP或Spring安全。

除了简单的电子邮件之外,多样化对发布的支持。FTP、 WebDav、文件系统(在源码中,电子邮件适配器的下面注释了一个简单的文件目录适配器配置)等都是可行的输入类型。更先进的例子则可以从移动客户端发送SMS消息。(当然,我不确定有多少人用他们的手机写博客。你永远也不会知道。不过只有一种方式能找到答案。)目前还没有对此的支持,但阅读了 Spring Integration的源码后会发现,很容易构建自己的适配器。你可以使用SMSLib[17]类似的库。

Spring Integration的不足之处

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则是一个功能强大、低摩擦的替代方案,它能温和地解决一些最复杂的集成问题。

Tags:Spring Integration 入门

编辑录入:爽爽 [复制链接] [打 印]
[]
  • 好
  • 好的评价 如果觉得好,就请您
      0%(0)
  • 差
  • 差的评价 如果觉得差,就请您
      0%(0)
赞助商链接