Spring技术应用中的远程服务详解 （2）

远程应用程序编程举例

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

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

◆测试驱动开发：该应用程序中的所有组件都应该是容器外可测试的。这个示例将使用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框架实现。但是，当你需要一种轻量级的易于安装而灵活的方案时，这是一种不错的选择。（