二、商业需求
既然你已经知道了应用的设计目标，那么让我们来讨论一下实际的商业需求。样例应用程序是一个贷款处理系统，客户使用它为家庭抵押贷款提交应用。远程例子所使用的商业用例是来处理特定家庭财产的洪灾鉴定检查。 洪灾鉴定检查对于每个家庭贷款应用都是必不可少的，以确保财产不在洪灾区。如果它位于洪灾区，户主需要支付一种”813费用”(813是用来区别洪灾鉴定费用的代码)来得到洪灾保险。
洪水地图指的是高，中，低级别”洪灾危险区”的区域，最高危险等级的区域称为”特殊洪灾危险区”。在高洪灾危险区(AE，A，或者AO地区)的财产，任何一年都有1%的几率发生洪灾，并且在30年的抵押期中会有26%的几率发生洪灾。在VE或者V地区(也是高险)的不动产在任何一年都有1%的几率发生洪灾，还面临着沿海暴风雨的危险。在等级或中等洪灾危险区(B或C区)的家庭在高险区之外，那里洪灾危险系数有所减少但并没有消除。
洪灾鉴定检查一旦借用人完成了家庭贷款应用且为贷款数量选择了利率以后就会被触发。洪灾鉴定检查需要在贷款处理之前，这样抵押处理的签名承受阶段才能开始。
三、用例
这是在洪灾鉴定检查用例中所用到的步骤：
1. 客户完成贷款应用，输入细节信息如借用人姓名，财产名称，财产地址，城市，邮编，和贷款数额。
2. 用户选择一个贷款产品和利率并把贷款锁定为一段特定时间(例如30天或者45天)。
3. 贷款应用程序调用基于财产细节比如地址和邮编的洪灾鉴定检查。
4. 基于客户的财产所在邮编，如果指定的财产在洪灾区并且如果它需要洪灾鉴定，洪灾鉴定服务就确定下来(这种调用是同步的，所以客户端在继续贷款应用处理之前将要等待服务的反馈)。
5. 一旦洪灾检查请求返回，贷款就被提交给一个自动承受系统(AUS)来获得借用人的信用历史和贷款应用的风险评估。
四、技术设计
按照敏捷开发过程，下一步是为定义的需求进行技术设计。例子使用下面的设计(类和方法)来完成用例中的需求。
1. 客户类(FloodCertClient)调用洪水控制器类(FloodCertController)中的requestFloodCheck()方法。
2. 控制器然后通过在HTTP请求中发送贷款细节调用服务(FloodCertService)中的processFloodCheck()方法。
3. 洪灾服务调用FloodDAO类来访问后端数据库，检查指定财产是否需要洪灾鉴定。
4. DAO返回一个带有洪灾鉴定结果的结果对象，它被传到客户端在Web页面上显示。
由于远程服务是一个企业商业域模型的入口点，服务层做为一个整体来设计也是非常重要的下面是一些你在设计远程服务时要牢记在心的需要考虑的地方：
1. 远程调用类型(远程调用应该是无状态的还是有状态的?)
2. 远程调用引用类型(调用是同步的还是异步的?)
3. 客户端类型(Java，。NET，或是一些其他类型的客户端)
4. 操作系统(Windows，Unix，或者另一操作系统)
5. 事务(你是否需要远程服务成为事务类型的，这样任何数据库或者JMS队列在服务方法中的更新都会做为一个工作单元被提交或者回滚。)
为了实现用例所有的需求，贷款处理应用的例子将使用下面的技术和框架：
• Tomcat 5。5
• Spring 2。0
• JUnit
• Commons HttpClient
• Eclipse
• Ant
五、实现
HTTP invoker远程例子使用两个配置XML文件来为你写的实现洪灾远程服务的类定义Spring beans: loanapp-servlet。xml和loanapp-client。xml。
下面是用HTTP invoker为贷款处理应用例子实现远程服务的步骤:
1. 创建一个HTTP invoker服务输出者类(HttpInvokerServiceExporter)
2. 创建一个HTTP代理(使用HttpInvokerProxyFactoryBean)。你要细化这个类里的参数像serviceUrl和serviceInterface。
3. 为客户端调用远程HTTP服务定义一个URL映射。
4. 在loanapp-servlet。xml文件里配置Spring beans。
5. 在web。xml文件里配置Spring Web层(DispatcherServlet)。
6. 写客户类(使用HTTP或者Commons HttpClient)。
7. 写一个JUnit测试用例来调用客户类中的方法。
六、测试
下载的源代码包括一个JUnit测试客户端(FloodCertClientTest)，用来测试调用洪灾远程服务的客户类。它根据财产的不同邮编来调用具有不同测试贷款应用的客户端。基于提交的财产邮编，洪灾服务返回洪灾鉴定分析的结果。
七、两全其美的远程技术
Spring远程技术为把商业域服务实现为远程服务提供了一种简单灵活的解决方案。它也提供了多种协议下(当然在不同的URL)同一服务的灵活机制。例如，你可以把样例应用程序中的洪灾鉴别检查服务实现为一个RMI服务(Java客户端利用较快的Java-to-Java远程)，也可以是非Java客户端的HTTP服务。这样，你只需在一个地方写商业服务逻辑，但是却把服务实现为两种远程服务端点。
HTTP invoker框架以普通Java服务接口和持续使用和配置风格来实现Java类作为远程服务提供了必要的代理。这种解决方案展示了把HTTP通讯的简单性和Java内置的对象序列化结合起来的两全其美的远程解决方案。这使得HTTP invoker成为替代RMI或者Hessian/Burlap的一种很好的选择。
HTTP invoker的一个明显的局限性在于它只在Spring框架中提供。这意味着不管是客户端还是服务应用端都必须用Spring来实现。但是当你需要一个轻量，容易建立，并且灵活的远程解决方案时它就成为非常好的选择。
