在本节中，让我们更为细致地分析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
3.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服务
其实，每一种远程技术都有其优点与不足，表格1对它们进行了简单的对比。
|
框架 |
优点 |
缺点 |
|
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服务引擎。 |
表格1：各种Spring Remoting技术优缺点比较
如你所见，每一种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框架实现。但是，当你需要一种轻量级的易于安装而灵活的方案时，这是一种不错的选择。
