基于Spring技术应用的远程服务

来源：赛迪网

　　一.引言

　　从根本上分析，Remoting实际上是一种企业分布式计算的组件。在同一服务器（Java虚拟机）内进行调用的服务（或类）并不需要把自己暴露为一种远程服务；但是，如果你需要与一个外部程序(在不同的服务器上或在一个不同的组织中)进行通讯的话，那么，必须把它实现为一个远程服务。Spring框架为把业务类暴露为远程服务提供了一种独特而灵活的方式。

　　Spring Remoting架构的核心是服务对象，这些对象其实是一些POJO，也称作Spring bean。Spring框架能够把这些服务对象与基础结构细节（例如它们暴露为远程服务的方式）隔离开来；这样以来，开发者就可以专注于实现服务对象的业务接口而不是牵涉到这些细节中去。

　　这个Remoting模型提供了对业务服务的远程抽象。它负责编排和反编排方法参数并且还负责处理服务方法中抛出的任何异常—使用未检查的RemoteAccessException异常对它们进行包装。为了实现各种服务，Spring使用了若干设计模式。例如，它使用代理设计模式把你对HTTP POST请求的调用翻译成指向输出服务的URL。
本文将着重探讨如何使用Spring实现一个远程服务。也就是说，要展示使用Spring Remoting API把一个普通Java对象(POJO)转化成一个远程服务；这样以来，外部程序就可以从其业务实现中调用该服务。该演示使用一个示例贷款处理应用程序把一个业务服务实现为一个远程HTTP服务并且从一个测试客户端调用该类中的业务方法。

　　二.Spring Remoting工作机制

　　在本节中，让我们更为细致地分析Spring的Remoting工作机制。要把一个普通的Java类实现为一个远程服务，需要提供如下一些内容：

　　1.远程服务输出器（exporter）—这些类用于创建为客户端程序所调用的远程服务端点。服务导出器还管理任何用来查询远程服务的注册表。
　　2.代理工厂Bean—它们是用于创建代理的工厂类，客户端能够使用这些代理连接到远程服务。
　　3.HTTP Invoker—如前面所提及，Spring HTTP Invoker使用了一种Remoting模型，你可以使用这种模型实现跨HTTP的远程调用，同时使用Java串行化技术传递Java对象。这样使得从一个普通Java类中实现一个远程服务容易得多了，并且允许你专注于远程服务的业务接口而不必亲自考虑远程基础结构的实现细节。

　　该技术依赖于RMI Invoker的基础结构，但是使用HTTP作为传输协议。

　　在客户端方面，Spring HTTP Invoker提供两种类型的客户端：Java SE提供的标准API和Commons HttpClient API。默认情况下，它使用的是HttpClient。
接下来，让我们看一下Spring框架所支持的远程（Remoting）技术。

　　Spring框架支持的远程技术列举

　　Spring框架支持多种Remoting技术。下面，我们来对它们作逐一简单介绍。

　　1.远程方法调用（RMI）

　　RMI是一种分布式Java技术，远程Java对象的方法能够从一个不同的Java虚拟机上进行调用。它基本上是远程过程调用（RPC）的Java版本，但是，它还提供了连同相应的请求一起传递多个对象的能力。RMI使用真正的对象串行化来编排与反编排方法的参数而不会截断其相应类型。

　　Spring以两种方式支持RMI：传统型RMI和使用RMI Invoker的远程技术。

　　2.Hessian

　　Hessian是一个由Caucho Technology开发的轻量级二进制RPC协议。它使用一种定制的串行化技术来实现跨网络发送Java对象。除了对Java支持外，Hessian还提供对于例如PHP，Python，C++和C#等其它语言的实现支持。

　　3.Burlap

　　Burlap是一个轻量级的用于实现Web服务的XML-RPC协议。类似Hessian，它还使用一种专利性串行化机制来实现Java对象的串行化。有关Hessian/Burlap的更多信息，恕在此不多及。

　　4.HTTP Invoker

　　Spring提供一种专门的Remoting策略—HTTP Invoker，它使用标准的Java串行化机制并通过HTTP协议来暴露服务。这是一个很重要的特征，特别是当你想传递给服务的方法参数是复杂的类型对象而不仅是简单的文本消息时尤为重要。

　　5.EJB

　　Spring还支持EJB组件模型。EJB组件还提供其它的J2EE/Java EE服务，例如基于角色的认证和授权以及声明性和编程性事务管理。然而，EJB模型是一个重量级的组件模型，所以大多数业务应用程序往往敬而远之。

　　6.Java消息服务(JMS)

　　JMS API是一种消息发送标准—允许Java应用程序异步地创建、发送、接收和处理消息。它提供了松耦合的和可靠的分布式通信。默认情况下，JMS Remoting使用Java串行化，但是一个JMS提供者(例如，WebLogic JMS或JBossMQ)能够使用另外一个不同的机制（例如XStream API）以便允许通过其它技术实现消息发送。

　　7.Web服务

　　借助于开源Web服务引擎Apache Axis并通过JAX-RPC技术，Spring为实现基于SOAP的Web服务提供支持。Web服务提供真正的平台独立的远程技术，但是它们的建立非常复杂，而且与常规HTTP远程调用相比还需要额外的SOAP消息处理的开销。因此，在不是真正需要平台独立性的情况下，你应该尽可能避免使用Web服务。另外，你还能够使用XFire（由Codehaus开发的一个轻量级SOAP库）对Web服务进行暴露。
其实，每一种远程技术都有其优点与不足，下面它们进行了简单的对比。

　　RMI：全面支持Java对象串行化。因此，你能够通过网络发送复杂数据类型。 RMI仅是一种Java到Java型远程方案。如果你拥有任何非Java客户端的话，那么你无法使用它。另外，你还无法通过HTTP协议存取对象，除非你有专门的“通道”实现RMI通讯。注意，它需要一个RMI编译器(为了生成代理和框架)和一个外部注册表(用于查询服务)。
　　Hessian/Burlap：跨防火墙工作良好。它们使用一种专利对象串行化机制。其中，Burlap仅支持Java客户端。它们能够串行化Hibernate对象，但是对集合对象执行“惰式”加载。
　　HTTP Invoker：基于HTTP的Java到Java Remoting；通过HTTP实现Java串行化；容易建立。 服务器和客户端应用程序都需要使用Spring。仅是一种Java方案。
　　EJB：支持Remoting J2EE服务，应用程序安全以及事务处理。EJB是一种重量级技术。它要求使用一个J2EE容器。
　　Web服务：平台和语言独立。要付出SOAP操作所带来的开销，并且要求使用一个Web服务引擎。

　　如你所见，每一种Spring Remoting技术都有各自的优缺点，但是大多数实际的应用程序都会要求使用一种轻量级Remoting技术。当实现远程服务时，使用例如EJB这样的重量级远程组件模型需要其它额外的开销。通常情况下，使用一种支持对象串行化能力的HTTP服务就足够了。

　　三.远程应用程序编程举例

　　现在，让我们开始讨论本文相应的示例程序。这个程序的设计目的如下：

　　◆基于接口的设计：一个基于接口的设计使客户端不必了解远程服务的实现细节；而且该实现能够在不需要对客户端代码进行任何修改的情况下作出改变。

　　◆测试驱动开发：该应用程序中的所有组件都应该是容器外可测试的。这个示例将使用JUnit来编写简单的单元测试以便对你编写代码时产生的每一个类的设计作出验证。

　　◆分层架构：一个分层的架构能够提供松耦合、隔离及灵活性。一个典型的J2EE应用程序都会实现分层—用户接口(UI)层，应用程序(或控制器)层，域(域模型或服务)层和基础结构层等。本文示例应用程序中提供了控制器、服务和域三个层。

　　◆分离关注点：既然Remoting功能与业务服务之间毫无联系，那么，关注点的分离在实现服务的过程中就起着相当重要的作用。

　　◆轻量级服务：本文示例使用了Spring HTTP Invoker API来实现远程服务。与其它组件模型比较，HTTP Invoker是相当轻量级的。

　　◆非入侵式：Spring是一个优秀的框架，非常适合于在业务应用程序中使用一种非入侵式API的情况。借助于例如Aspects和AOP等技术以及例如控制反转(IoC)，代理和工厂模式等设计模式，你可以把一项业务相关任务的实现细节封装到服务类中并且仅对客户端暴露接口。

　　除了这些目标外，该示例在设计上还遵循了一种敏捷软件开发方法来编写该示例应用程序所使用的类（请参考本文相应源码）。

　　业务需求分析

　　现在，既然你知道了明确应用程序的设计目标，那么接下来，让我们讨论实际的业务要求。这个示例应用程序是一个贷款处理系统(loanapp)，顾客用它来提交应用程序以实现家庭抵押贷款。该Remoting示例的业务用例是：针对一指定的家庭财产实现水灾认证检查。每一个家庭贷款应用程序都需要一个水灾认证检查以确保财产不是位于一个水灾地区。如果它位于一个水灾地区，那么要求该家庭的主人通过支付一种“813费”(813是用于标识水灾认证费的代码)来获得相应的水灾保险。

　　在水灾地图上，一般把高、中等或低风险地区作为“水灾危险地区”，而把最高风险地区作为“特殊水灾危险区域”。在高水灾风险地区(AE，A或AO地区)的财产每年都有大约1％的发生水灾的可能性，而对于一种达30年之久的财产抵押大约存在26％发生水灾的可能性。在VE或V地区(也是高风险地区)的房地产财产每年也都有大约1％的发生水灾的可能性，并且还会面临如沿海暴风雨这样的危险。而那些处于低级或中级水灾风险地区(B或C地区)的家庭显然是位于高风险地区之外的；尽管这些地方的水灾风险会大大降低，但是却不能被删除。

　　一旦借款人完成家庭贷款应用程序并且选择好贷款数额的相应利率，即会触发水灾认证检查。在抵押处理的贷款处理和保险阶段开始之前必须进行相应的水灾情况检查。

　　用例分析

　　下面是实现水灾认证检查用例相应的步骤：

　　1.顾客通过输入细节数据（例如借款人名，属性名称，属性地址，城市，邮政区码和贷款数额）完成贷款应用程序。

　　2.用户选择一个贷款产品和利率并且在一个特定的时间周期(例如，30或45天)内锁定此项贷款。

　　3.本文loanapp程序基于细节属性（例如地址和邮政区码）调用一个水灾认证检查。

　　4.基于客户端的邮政区码属性，水灾服务决定是否指定的属性处于一个水灾地带以及是否它要求水灾认证(这个调用是同步的；所以，在继续贷款应用程序处理之前，客户端需要等待服务的响应)。

　　5.一旦水灾检查请求返回，贷款即被提交到一个自动化保险系统（AUS）以得到该借款人的信用历史以及该贷款应用程序的风险评价。

　　技术设计

　　根据敏捷开发过程的思想，接下来应该是对上面定义的要求进行技术设计。本示例中使用了下列设计(类和方法)来实现用例中的要求：

　　1.客户端类(FloodCertClient)调用水灾控制器类(FloodCertController)的requestFloodCheck()方法。

　　2.然后，该控制器又调用服务(FloodCertService)中的processFloodCheck()方法，通过在HTTP请求中发送贷款细节实现。

　　3.水灾服务调用FloodDAO类来存取后端数据库并且检查是否指定的属性需要进行水灾认证。

　　4.DAO返回一个含有水灾认证结果的结果对象。然后，该结果数据被返回到客户端并显示于Web页面。

　　既然远程服务充当进入一个企业的业务域模型的入口点，那么把服务层作为一个整体进行设计还是很重要的。下列是在设计远程服务时你需要牢记的一些问题：

　　1.远程调用类型（远程调用是无状态的还是有状态的？）

　　2.远程调用激活类型（同步还是异步调用？）

　　3.客户端类型(Java，.NET或一些其它类型的客户端)

　　4.操作系统(Windows，Unix或另一种OS)

　　5.事务（你是否需要该远程服务是事务性的以便在服务方法中实现任何数据库或JMS队列更新时都能够作为一个独立的工作单位被提交或回滚？)

　　为了实现此用例的所有以上要求，本文中的示例贷款处理应用程序需要使用下列技术和框架：

◆Tomcat 5.5
◆Spring 2.0
◆JUnit
◆Commons HttpClient
◆Eclipse
◆Ant

　　Spring配置

　　本文中的HTTP Invoker Remoting示例使用了两个配置XML文件，这两个文件中定义了相应于你编写的实现水灾远程服务的类的Spring bean；它们分别是loanapp-servlet.xml和loanapp-client.xml。

　　实现

　　下列是基于HTTP Invoker技术针对示例贷款处理应用程序实现一个远程服务所需的步骤：

　　1.创建一个HTTP Invoker服务输出器类(HttpInvokerServiceExporter)。

　　2.创建一个HTTP代理(使用HttpInvokerProxyFactoryBean)。你需要在这个类中指定如serviceUrl和serviceInterface等参数。

　　3.定义一个URL映射，以便客户端调用远程HTTP服务。

　　4.在loanapp-servlet.xml文件中配置Spring bean。

　　5.在web.xml文件中配置Spring Web层(DispatcherServlet)。

　　6.编写客户端类(使用HTTP或Commons HttpClient)。

　　7.编写一个JUnit测试用例来调用客户端类中的方法。

　　测试

　　本文下载源码文件中包含了一个JUnit测试客户程序(FloodCertClientTest)用于测试调用水灾远程服务的客户端类。它通过若干不同的测试贷款应用程序（使用不同的邮政区码属性）来调用客户端。凭借提交的邮政区码属性，水灾服务就能够返回水灾认证分析的结果。

　　四.总结

　　Spring远程技术为把业务域服务暴露为远程服务提供了一种简单而灵活的方案。同时，它还为暴露多种协议（当然，位于不同的URL处）之下的相同服务提供了相当的灵活性。例如，你可以把本文示例程序中的水灾认证检查服务实现为一种RMI服务（对于Java客户，应该利用更快速的Java到Java远程技术，而对于非Java客户则宜使用一种HTTP服务）。这样以来，你可以仅在一处编写业务服务逻辑，但是最终可以把该服务暴露为两个远程服务端点。

　　HTTP Invoker框架为普通Java服务接口提供了必要的代理；同时，还为把Java类实现为远程服务提供一致的用法和配置风格。这是一种把两个世界的实现达到最佳结合的远程方案—把HTTP通讯的简单性与Java内置对象串行化技术结合在一起。这使得HTTP Invoker无论对RMI还是对Hessian/Burlap都成为一种优秀的选择。

　　当然，HTTP Invoker的一个重要局限性就是它仅为Spring框架所提供—这意味着，客户端和服务应用程序都必须使用Spring框架实现。但是，当你需要一种轻量级的易于安装而灵活的方案时，这是一种不错的选择。