spring远程编程

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

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

　　这个Remoting模型提供了对业务服务远程抽象它负责编排和反编排思路方法参数并且还负责处理服务思路方法中抛出任何异常—使用未检查RemoteAccessException异常对它们进行包装为了实现各种服务Spring使用了若干设计模式例如它使用代理设计模式把你对HTTP POST请求翻译成指向输出服务URL

　　本文将着重探讨如何使用Spring实现个远程服务也就是说要展示使用Spring Remoting API把个普通Java对象(POJO)转化成个远程服务；这样以来外部就可以从其业务实现中该服务该演示使用个举例贷款处理应用把个业务服务实现为个远程HTTP服务并且从个测试客户端该类中业务思路方法

　　 2.Spring Remoting工作机制

　　在本节中让我们更为细致地分析SpringRemoting工作机制要把个普通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技术下面我们来对它们作逐简单介绍

　　①远程思路方法(RMI)

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

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

　　②Hessian

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

　　③Burlap

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

　　④HTTP Invoker

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

　　⑤EJB

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

　　⑥Java消息服务(JMS)

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

　　⑦Web服务

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

　　其实每种远程技术都有其优点和不足表格1对它们进行了简单对比

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



　　表格1:各种Spring Remoting技术优缺点比较

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

　　 3.远程应用编程举例

　　现在让我们开始讨论本文相应举例这个设计目如下:

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

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

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

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

　　◆轻量级服务:本文举例使用了Spring HTTP Invoker API来实现远程服务和其它组件模型比较HTTP Invoker是相当轻量级

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

　　除了这些目标外该举例在设计上还遵循了种敏捷软件Software开发思路方法来编写该举例应用所使用类(请参考本文相应源码)

　　业务需求分析

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

　　在水灾地图上般把高、中等或低风险地区作为“水灾危险地区”而把最高风险地区作为“特殊水灾危险区域”在高水灾风险地区(AEA或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.操作系统(WindowsUnix或另种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层(Dispatc***ervlet)

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

　　7.编写个JUnit测试用例来客户端类中思路方法

　　测试

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

　　 4.整理总结

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

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

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