Web Service实现SOA的关注点分离(1)

关注点分离(separation of concerns)是面向服务的架构(Service-Oriented Architectures，SOA)的核心原则。令人遗憾的是，该原则在实现SOA服务时常常起不到作用。我们通常会看到带有多个关注点(如安全、事务管理)的巨大的实现类，使用业务逻辑记录所有混合在一起的关注点。使用Spring Framework和Aspect Oriented Programming (AOP)原则，我们可以将关注点分离，以用于服务实现。

本文中我们将演示如何使用Apache Axis和Spring来开发Web service，并使用Acegi Security对其进行保护——同时保持关注点很好地分离。

动机和设计

本文中我们将使用的示例是名为FundsTransferService的服务，银行使用该服务将资金从一个账户转移到另一个账户。可以在本文的参考资料部分找到该服务的WSDL及所有源代码、配置文件和构建文件。我们有意让该服务保持非常简单，以便集中讨论本文更有意义的方面。在本服务的实现中，我们将涉及三个关注点:

• Web service管道，用来公开作为服务的功能
• 用于转移资金的业务逻辑
• 安全性，用于保证只有经授权的用户才能执行资金转移

而真正的系统很可能是必须处理其他的关注点，如事务管理、日志等。

我们想设计这样一种实现，处理每个关注点的代码与其他的代码完全分离。对于Web service管道，我们将使用Axis来公开作为服务的功能。用于将资金从一个账户转移到另一个账户的业务逻辑将封装在一组POJO(Plain Old Java Object)中。将通过Acegi Security框架来提供安全性。我们将使用Spring Framework及其AOP工具把各方面联系起来，使构成该Web service实现的所有代码之间的依赖性减到最小。

该实现的设计如图1所示。以黄色表示的对象就是我们需要实现的Web service。以蓝色表示的对象来自Axis;以粉红色表示的对象来自Acegi;以绿色表示的对象来自Spring。FundsTransferService是WSDL中所定义的服务接口。为了简化图表，我们将所有Axis类显示为名为Axis Engine的组件。BasicHandler也是Axis类，但由于它对于设计比较重要(稍后详述)，所以单独显示出来。FundsTransferServiceSoapBindingImpl是Axis的生成类，需要实现它来提供服务功能。将直接通过Spring委派业务逻辑POJO AccountMgrImpl(稍后也会对此进行详细解释)。AccountMgrImpl与AccountMgr接口捆绑在一起是不错的做法，因为这样就允许我们插入Spring以发挥其作用(尽管有其他方法可以不带接口使用Spring)。

图1.FundsTransferService实现的设计

现在回到BasicHandler。需要返回的原因涉及到如何选择以提供安全。在本例中，将在两个不同级别上处理安全性:Web service的安全性，及应用程序代码的安全性，如POJO。按照关注点分离的理念，我们提出允许进行分离的设计。Axis允许插入定制的处理程序，侦听请求和响应消息，以提供其他功能(如安全性)。因此，我们将创建名为AcegiBridgeAuthenticationHandler的定制处理程序，负责处理Web service安全。将扩展Axis类BasicHandler，以便可以将其插入Axis处理程序框架。Acegi将用于提供应用程序级的安全，如提供对POJO的访问控制。

为了使这些方面无缝工作，需要将Web service安全上下文连接到Acegi安全上下文——因此定制的Axis处理程序类的名称为AcegiBridgeAuthenticationHandler。它不仅将处理Web service安全性，还负责将从该过程获取的安全上下文连接到Acegi环境，这样Acegi就可以决定是否授权访问POJO。方法是从Web service请求消息中提取安全声明，进行验证，然后创建认证令牌，因为我们已经为本例选择了用户名/密码认证，所以为UsernamePasswordAuthenticationToken。然后将该认证令牌设置到Acegi SecurityContext中，这样稍后在控制访问业务逻辑POJO时，Acegi可以使用请求方的证书和权限。

下面将解释如何使用Spring把各方面联系起来。法宝就是图1中名为AOP proxy的小绿色对象，由Spring生成。该对象实现了AccountMgr接口，并担当业务逻辑POJO AccountMgrImpl的代理。这允许Spring插入Acegi的MethodSecurityInterceptor，当有人尝试在POJO上调用方法时，会执行访问控制检查。当FundsTransferServiceSoapBindingImpl将Web service请求委派给POJO时，实际上是委派给AOP代理的实例，而不是直接委派给AccountMgrImpl。由于FundsTransferServiceSoapBindingImpl扩展了ServletEndpointSupport，因此它可以访问Spring应用程序上下文，以获得配置了正确接口、侦听器和目标类的AOP代理的引用AccountMgrImpl。

图2中的序列图演示了客户端调用FundsTransferService时，将发生的处理流程。请求消息由Axis Engine接收，然后调用AcegiBridgeAuthenticationHandler。AcegiBridgeAuthenticationHandler将验证认证信息，然后创建UsernamePasswordAuthenticationToken。接着，将该令牌设置到Acegi的SecurityContext中，用于稍后使用。AcegiBridgeAuthenticationHandler成功返回后，Axis Engine将在FundsTransferServiceSoapBindingImpl上调用transferFunds()方法。FundsTransferServiceSoapBindingImpl将其委派给AOP代理，在初始化过程中，可以较早从Spring web应用程序上下文获取。AOP proxy将调用Acegi MethodSecurityInterceptor，这样就可以进行它的安全检查。MethodSecurityInterceptor从SecurityContext获取认证令牌，然后检查是否已经对其进行了认证。接下来，将使用认证令牌中的信息来确定是否应该授权客户端的访问，在AccountMgrImpl上调用transferFunds()方法。如果允许客户端进行访问，那么MethodSecurityInterceptor将允许调用该方法，然后进入AccountMgrImpl。最后AccountMgrImpl处理该请求，并返回结果，最终传送回客户端程序。

图2.演示服务实现处理流程的序列图

业务逻辑实现和配置

我们的讨论将从解释业务逻辑类的实现和配置开始，因为他们是最简单的。AccountMgr接口和AccountMgrImpl类的源代码参见参考资料。从源代码中可以发现，事实上实现并没有做任何事情，所以可以保持其简单，因为本文并不是关于如何编写转移资金代码的文章。

下面是Spring配置文件的部分代码(可在参考资料部分得到整个配置文件)，这些代码表明了如何配置业务逻辑的Spring beans，以便使用Spring的AOP工具。第一个bean条目是为AccountMgrImpl类创建bean。第二个bean条目是如何施展前面讨论的全部AOP代理魔法。使用从ProxyFactoryBean获取的id accountMgr来创建bean。当FundsTransferServiceSoapBindingImpl类向Spring请求具有该id的bean时，ProxyFactoryBean将返回AOP代理对象的实例。对它进行配置来实现AccountMgr接口，这样客户端程序会认为他们只是在使用业务逻辑对象。使用名为interceptorNames的第二个属性，创建名为securityInterceptor的bean(稍后将进行解释)，可以侦听方法调用以执行安全检查。这允许我们在业务逻辑代码中插入不带任何依赖性的Acegi安全机制。最后，将目标设置到accountMgrTarget bean，这样方法调用将最终传送到实际的业务逻辑类AccountMgrImpl。