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

一.引言从根本上分析，Remoting实际上是一种企业分布式计算的组件。在同一服务器（Java虚拟机）内进行调用的服务（或类）并不需要把自己暴露为一种远程服务；但是，如果你需要与一个外部程序(在不同的服务器上或在一个不同的组织中)进行通讯的话，那么，必须把它实现为一个远程服务。Spring框架为把业务类暴露为远程服务提供了一种独特而灵活的方式。SpringRemoting架构的核心是服务对象，这些对象其实是一些POJO，也称作Springbean。Spring框架能够把这些服务对象与基础结构细节（例如它们暴露为远程服务的方式）隔离开来；这样以来，开发者就可以专注于实现服务对象的业务接口而不是牵涉到这些细节中去。这个Remoting模型提供了对业务服务的远程抽象。它负责编排和反编排方法参数并且还负责处理服务方法中抛出的任何异常—使用未检查的RemoteAccessException异常对它们进行包装。为了实现各种服务，Spring使用了若干设计模式。例如，它使用代理设计模式把你对HTTPPOST请求的调用翻译成指向输出服务的URL。本文将着重探讨如何使用Spring实现一个远程服务。也就是说，要展示使用SpringRemotingAPI把一个普通Java对象(POJO)转化成一个远程服务；这样以来，外部程序就可以从其业务实现中调用该服务。该演示使用一个示例贷款处理应用程序把一个业务服务实现为一个远程HTTP服务并且从一个测试客户端调用该类中的业务方法。二.SpringRemoting工作机制在本节中，让我们更为细致地分析Spring的Remoting工作机制。要把一个普通的Java类实现为一个远程服务，需要提供如下一些内容：1.远程服务输出器（exporter）—这些类用于创建为客户端程序所调用的远程服务端点。服务导出器还管理任何用来查询远程服务的注册表。2.代理工厂Bean—它们是用于创建代理的工厂类，客户端能够使用这些代理连接到远程服务。3.HTTPInvoker—如前面所提及，SpringHTTPInvoker使用了一种Remoting模型，你可以使用这种模型实现跨HTTP的远程调用，同时使用Java串行化技术传递Java对象。这样使得从一个普通Java类中实现一个远程服务容易得多了，并且允许你专注于远程服务的业务接口而不必亲自考虑远程基础结构的实现细节。该技术依赖于RMIInvoker的基础结构，但是使用HTTP作为传输协议。在客户端方面，SpringHTTPInvoker提供两种类型的客户端：JavaSE提供的标准API和CommonsHttpClientAPI。默认情况下，它使用的是HttpClient。接下来，让我们看一下Spring框架所支持的远程（Remoting）技术。Spring框架支持的远程技术列举Spring框架支持多种Remoting技术。下面，我们来对它们作逐一简单介绍。1.远程方法调用（RMI）RMI是一种分布式Java技术，远程Java对象的方法能够从一个不同的Java虚拟机上进行调用。它基本上是远程过程调用（RPC）的Java版本，但是，它还提供了连同相应的请求一起传递多个对象的能力。RMI使用真正的对象串行化来编排与反编排方法的参数而不会截断其相应类型。Spring以两种方式支持RMI：传统型RMI和使用RMIInvoker的远程技术。2.HessianHessian是一个由CauchoTechnology开发的轻量级二进制RPC协议。它使用一种定制的串行化技术来实现跨网络发送Java对象。除了对Java支持外，Hessian还提供对于例如PHP，Python，C++和C#等其它语言的实现支持。3.BurlapBurlap是一个轻量级的用于实现Web服务的XML-RPC协议。类似Hessian，它还使用一种专利性串行化机制来实现Java对象的串行化。有关Hessian/Burlap的更多信息，恕在此不多及。4.HTTPInvokerSpring提供一种专门的Remoting策略—HTTPInvoker，它使用标准的Java串行化机制并通过HTTP协议来暴露服务。这是一个很重要的特征，特别是当你想传递给服务的方法参数是复杂的类型对象而不仅是简单的文本消息时尤为重要。5.EJBSpring还支持EJB组件模型。EJB组件还提供其它的J2EE/JavaEE服务，例如基于角色的认证和授权以及声明性和编程性事务管理。然而，EJB模型是一个重量级的组件模型，所以大多数业务应用程序往往敬而远之。6.Java消息服务(JMS)JMSAPI是一种消息发送标准—允许Java应用程序异步地创建、发送、接收和处理消息。它提供了松耦合的和可靠的分布式通信。默认情况下，JMSRemoting使用Java串行化，但是一个JMS提供者(例如，WebLogicJMS或JBossMQ)能够使用另外一个不同的机制（例如XStreamAPI）以便允许通过其它技术实现消息发送。7.Web服务借助于开源Web服务引擎ApacheAxis并通过JAX-RPC技术，Spring为实现基于SOAP的Web服务提供支持。Web服务提供真正的平****立的远程技术，但是它们的建立非常复杂，而且与常规HTTP远程调用相比还需要额外的SOAP消息处理的开销。因此，在不是真正需要平****立性的情况下，你应该尽可能避免使用Web服务。另外，你还能够使用XFire（由Codehaus开发的一个轻量级SOAP库）对Web服务进行暴露。其实，每一种远程技术都有其优点与不足，表格1对它们进行了简单的对比。框架优点缺点RMI全面支持Java对象串行化。因此，你能够通过网络发送复杂数据类型。RMI仅是一种Java到Java型远程方案。如果你拥有任何非Java客户端的话，那么你无法使用它。另外，你还无法通过HTTP协议存取对象，除非你有专门的“通道”实现RMI通讯。注意，它需要一个RMI编译器(为了生成代理和框架)和一个外部注册表(用于查询服务)。Hessian/Burlap跨防火墙工作良好它们使用一种专利对象串行化机制。其中，Burlap仅支持Java客户端。它们能够串行化Hibernate对象，但是对集合对象执行“惰式”加载。HTTPInvoker基于HTTP的Java到JavaRemoting；通过HTTP实现Java串行化；容易建立。服务器和客户端应用程序都需要使用Spring。仅是一种Java方案。EJB支持RemotingJ2EE服务，应用程序安全以及事务处理EJB是一种重量级技术。它要求使用一个J2EE容器。Web服务平台和语言独立要付出SOAP操作所带来的开销，并且要求使用一个Web服务引擎。表格1：各种SpringRemoting技术优缺点比较如你所见，每一种SpringRemoting技术都有各自的优缺点，但是大多数实际的应用程序都会要求使用一种轻量级Remoting技术。当实现远程服务时，使用例如EJB这样的重量级远程组件模型需要其它额外的开销。通常情况下，使用一种支持对象串行化能力的HTTP服务就足够了。三.远程应用程序编程举例现在，让我们开始讨论本文相应的示例程序。这个程序的设计目的如下：◆基于接口的设计：一个基于接口的设计使客户端不必了解远程服务的实现细节；而且该实现能够在不需要对客户端代码进行任何修改的情况下作出改变。◆测试驱动开发：该应用程序中的所有组件都应该是容器外可测试的。这个示例将使用JUnit来编写简单的单元测试以便对你编写代码时产生的每一个类的设计作出验证。◆分层架构：一个分层的架构能够提供松耦合、隔离及灵活性。一个典型的J2EE应用程序都会实现分层—用户接口(UI)层，应用程序(或控制器)层，域(域模型或服务)层和基础结构层等。本文示例应用程序中提供了控制器、服务和域三个层。◆分离关注点：既然Remoting功能与业务服务之间毫无联系，那么，关注点的分离在实现服务的过程中就起着相当重要的作用。◆轻量级服务：本文示例使用了SpringHTTPInvokerAPI来实现远程服务。与其它组件模型比较，HTTPInvoker是相当轻量级的。◆非入侵式：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队列更新时都能够作为一个独立的工作单位被提交或回滚？)为了实现此用例的所有以上要求，本文中的