[转]SOA实践 - 使用IoC跟AOP重构SOA应用

[转]SOA实践 -- 使用IoC和AOP重构SOA应用

在上图中包括的几个类中：

CurrencyExchangePortType：服务端点接口，定义了Web Service的方法签名。

CurrencyExchangeService：Service接口，定义了获取服务端点接口的方法。

CurrencyExchangeServiceLocator：ServiceLocator类，实现了Service接口。

CurrencyExchangeBindingStub： Stub实现类，实现了服务端点接口，封装了对Web Service访问的底层逻辑。

使用Stub调用Web Service的过程也非常简单，读者可以参考清单 1：

清单 1：Web Service 调用代码示例

Business Delegate模式实现很好地实现了客户端与远程访问代码的解耦，但它并不关注Delegate与远程服务之间的解耦。为了更好解决Business Delegate和远程服务之间的依赖关系，并更好地进行配置管理，我们可以用IoC模式来加以解决。

IoC（Inversion of Contro）l意为控制反转，其背后的概念常被表述为"好莱坞法则"："Don't call me, I'll call you." IoC将一部分责任从应用代码交给framework（或者控制器）来做。通过IoC可以实现接口和具体实现的高度分离，降低对象之间的耦合程度。Spring是一个非常流行的IoC容器，它通过配置文件来定义对象的生命周期和依赖关系，并提供了良好的配置管理能力。

现在我们来重构我们的Web Service应用程序，我们首先为Business Delegate定义一个接口类型，它提供了一个应用级组件接口，所有客户端都应通过它来执行汇率计算，而不必关心实现细节，如清单 2 所示：

清单 2：接口定义的代码示例

从上面的类图我们可以看到，我们的测试程序（Main.java）通过Spring框架获取了BusinessDelegate的实例。而且Spring 框架还会根据配置中的依赖关系，在运行时将Web Service的客户端代理" 注射"到CurrencyExchangeManagerImpl实例中，这就是依赖注入（Dependency Injection）。通过这种方式解决了应用逻辑和BusinessDelegate之间的依赖关系，以及BusinessDelegate的实现与远程服务之间的依赖关系，如图 4 所示。

图 4: 示例程序的顺序图

Spring框架提供的ApplicationContext实现会根据配置文件中的描述信息来实现对象生命周期管理，配置管理以及依赖管理等功能。这一切对于应用程序是透明的，应用程序代码只依赖接口进行编程，而无需考虑其它复杂问题。无论是Web Service的配置发生变化，或是改用不同的服务实现时，都不会对客户端应用代码的产生影响。这很好地实现了业务逻辑与Web Service调用之间的解耦。

3.3 构建自己的 Web Service代理工厂

Spring所提供的JaxRpcPortProxyFactoryBean封装了构造Web Service客户端代理的细节，可以通过参数配置来创建Dynamic Proxy和DII类型的Web Service客户端代理。（如果您希望深入了解其实现细节可以参考org.springframework.remoting.jaxrpc包下的源代码。）但由于JaxRpcPortProxyFactoryBean需要使用者对WSDL中Port，Service，名空间等概念有深入的了解；而且如果Web Service使用了复杂数据类型，开发人员需要手工定义类型映射代码。所以JaxRpcPortProxyFactoryBean并不适合Web Service的初学者来使用。

为了进一步简化Web Service代理的创建，并帮助读者更好地理解类工厂在Spring框架下的作用。我们提供了一个基于静态Stub的Web Service客户端代理工厂实现。其核心代码非常简单，就是通过ServiceLocator提供的方法来创建Web Service客户端代理。

其主要代码如清单8所示：

清单8：静态代理工厂的代码

5.5 Interceptor与JAX-RPC Handler的关系与区别

SOAP Message Handler是JAX-RPC为用户自定义Web Service处理过程提供的一种扩展机制。在处理Web Service请求/响应过程中，Web Service 引擎会根据部署描述中的定义，按照一定的次序调用Handler的处理代码。用户编写的Handler实现可以截获并修改Web Service消息和处理流程，从而实现对Web Service引擎处理行为的定制和增强。

比如，我们可以实现一个服务器端Handler，记录Web Service在受到请求消息和发出响应消息之间的时间间隔来实现对服务器端业务性能的测定。而且我们只需在部署描述中增加Handler声明即可，无需修改任何服务器端代码。

从此可以看出，JAX-RPC Handler与我们在上文中所提供的AOP Interceptor都可以帮助我们的SOA应用程序实现关注分离（Separate Concern）的目标，在不改变应用代码的同时，增强或改变Web Service服务访问的功能。虽然我们可以利用它们实现一些类似的功能，但它们具有着不同的特点和适用范围。

JAX-RPC Handler是Web Service引擎的扩展机制。如果我们需要实现对SOAP消息进行的修改和处理，加入自定义的SOAP Header或对消息内容进行加密，Handler是我们的最佳选择。而AOP是针对对象级别的扩展机制，它更适合对应用层逻辑进行操作。

比如，我们在上文展示的利用AOP实现的CacheInterceptor，它缓存的是Web Service调用参数和结果。而我们也可以通过JAX-RPC Handler实现一个面向SOAP消息的实现，它将缓存Web Service的请求消息和响应消息。这两个实现相比，基于AOP的实现更加简单、直观、快速、对资源消耗也比较小。而面向SOAP消息的实现则更加灵活，对于不采用RPC方式的Web Service访问也能提供支持。

所以在具体的实践过程中，开发人员应该根据具体的需求选择合适的技术，也可以将这两种技术结合使用。

回页首

6.总结

"分而治之"的方法是人们解决复杂问题的一种常见做法。而IoC、AOP等技术都体现了这种思想。通过更好的切分程序逻辑，使得程序结构更加良好，更加富有弹性，易于变化。也使得开发人员可以更加专注于业务逻辑本身，而将一部分其他逻辑交给容器和框架进行处理。

在本文中，我们通过一个Web Service访问的实例，具体描述了SOA应用中所遇到的一系列具体问题，并描述如何利用IoC和AOP等技术进行代码重构，构建更加结构良好、灵活的SOA应用。综上所述，我们可以看到：

1使用IoC框架来实现对象的生命周期管理、配置管理和依赖管理，可以解除业务逻辑对服务调用的依赖关系；

2 使用AOP方法来解决Web Service调用中的crosscutting concerns，将为系统增加新的功能而不必更改应用程序。

3通过IoC和AOP来屏蔽Web Service访问的复杂性，使得开发人员可以更加专注于业务逻辑本身，也使得系统更加稳定和富有弹性。