图11. 应用请求端缓存模式后的SOA Catalog Legacy Design Model
 
　　应用此模式后会得到一系列构件，如下所示：

　　·会创建一个AcceleratedCatalogService类。此类实现CatalogService接口，并封装其实现。这是典型的GoF装饰模式设计模式。AcceleratedCatalogService还具有对Cache类的引用。
　　·还生成了一个内存中的缓存实现。如果clustering属性设置为True，AcceleratedCatalogService将有一个对WebSphere动态缓存代理的引用。
　　·使用UML-to-Java转换将AcceleratedCatalogService和Cache类转换为对应的Java类（如图12中所示）。生成后，这两个类都放置在RetailWeb文件夹中（请参见图13）。可以在项目交换ZIP文件中找到通过UML-to-Java转换生成的AcceleratedCatalogService和内存中的Cache Java文件（请参见“下载”部分）。

　　图12. UML-to-Java转换

 
　　图13. UML-to-Java转换对话框
 
　　·Catalog控制器现在可以使用AcceleratedCatalogService替代CatalogService来访问遗留Catalog应用程序。现在只需使用一行代码，Catalog控制器就能够使用请求端缓存功能来缓存从遗留Catalog应用程序返回的Catalog了。

　　清单1. AcceleratedCatalogService
               
　　**
　　 public javax.xml.soap.SOAPElement getCatalog(
　　      javax.xml.soap.SOAPElement key,
　　      javax.xml.soap.SOAPElement requestTemplate)
　　      throws InvokerException, WriterException {
　　   Object catalog = null;
　　   String keystr = ((javax.xml.soap.Node) key.getChildElements().next()).getValue();
　　   System.out.println(keystr);
　　   // Get a refer to the backend catalog service
　　   com.ibm.retail.entity.catalog.CatalogService catalogImpl =
　　      new com.ibm.retail.entity.catalog.CatalogServiceImpl();
　　   // Use the generated Accelerated Catalog service
　　   com.ibm.retail.entity.catalog.CatalogService cachedCatalogImpl =
　　      new com.ibm.retail.entity.catalog.AcceleratedCatalogService　　(catalogImpl);
　　   catalog = cachedCatalogImpl.getCatalog(keystr);
　　   // Navigate the catalog to return a response template
　　   return Navigator.navigate(requestTemplate, catalog, context);
　　}

　　·使用Web Service Explorer测试实现。图14显示了对“Catalog A”的调用，此时客户机只关心Catalog的名称、说明和开始日期。

　　图14. 使用Web Services Explorer进行测试
 
　　如果在WSDL-to-Java生成过程中选中了monitor Web service复选框，SOAP调用请求应该出现在TCP/IP Tunneller中，带空SOAP响应（请参见图15）。此请求中的两个参数如下：

　　·此例中Catalog的主键是Catalog“A”。
　　·请求模板指示，仅应该返回名称、说明和开始日期。

　　图15. TCP/IP Tunneller
 
　　进行两次这样的调用，并观察输出控制台。第一次将看到遗留Catalog应用程序的输出如下（请参见图16）：

　　这要花相当长一段时间。

　　图16. WebSphere控制台输出
 
　　在第二次调用时，此消息将消失，因为Catalog A现在缓存于请求端。可以更改发送给支持WS响应模板的Catalog服务的请求参数来进行试验。

　　·请参见下载部分，其中提供了打包为项目交换文件的RSA项目。（要导入到RSA，请选择File>Import>Project Interchange。）

　　实现的结果

　　图17显示了应用请求端缓存模式后的序列关系图。Catalog控制器将始终首先访问缓存代理。只有未在缓存中找到相应项目时，控制器才会访问遗留Catalog应用程序并使用结果更新缓存。将请求端缓存应用到遗留Catalog服务具有以下好处：

　　·它提供了有关如何正确地在请求端实现缓存解决方案的指导。
　　·现在，支持WS响应模板的Catalog控制器能够仅用一行代码来创建支持缓存的代理。

　　图17. getCatalog()请求端缓存序列关系图
 
　　对Catalog控制器的根本更改是，从遗留Catalog实现更改到了缓存代理，如下所示：

　　清单2. 遗留Catalog服务实现
               
　　   com.ibm.retail.entity.catalog.CatalogService catalogImpl =
　　      new com.ibm.retail.entity.catalog.CatalogServiceImpl();
　　   catalog = catalogImpl.getCatalog(keystr);
   
　　将其更改为：

　　清单3. 缓存代理
                    
　　   com.ibm.retail.entity.catalog.CatalogService catalogImpl =
　　      new com.ibm.retail.entity.catalog.CatalogServiceImpl();
　　   com.ibm.retail.entity.catalog.CatalogService cachedCatalogImpl =
　　      new com.ibm.retail.entity.catalog.AcceleratedCatalogService　　(catalogImpl);
　　   catalog = cachedCatalogImpl.getCatalog(keystr);
   
　　Aspect日志记录模式

　　此模式讨论的目标之一就是要包含用于记录服务和缓存的使用情况的方法。可以在运行时环境中使用此类日志来评估缓存的实际好处，也可以在开发期间作为进行调试的额外工具使用。由于日志记录并不是服务或缓存功能的直接子功能，因此并不能真正将其作为模式核心设计的一部分进行考虑。相反，最好将此类功能视为与缓存和模式设计互不相关，理想的情况是，应该以不太突出的方式在缓存和服务的设计和实现中创建和应用它。

　　AspectJ适时出现了，可用作将日志记录之类的功能与此处开发的缓存和服务之类的已编译功能结合到一起的优秀体系结构机制。Eclipse组织提供了大量描述AspectJ技术的文档。

　　由于AspectJ是新技术，并包含另一个编程语言（Java语言的一个变体），很多人因为不知道要花多少精力来学习它，从而不愿意选择这个可能非常有用的技术。为了让这项技术能在较大的开发组织中更为广泛地使用，我们提供了在建模级别利用预定义Aspect的方法。即，具有AspectJ知识的架构师和个人可以创建和部署基于AspectJ的代码，以供设计人员和实现人员使用，允许他们通过建模抽象确定和应用Aspect。其他都在底层进行处理。

　　设置Aspect

　　Aspect日志记录模式实现可以通过使用菜谱导入到Rational Software Architect中。首先导航到菜谱中的“Apply patterns to a service implementation”部分，然后展开名为“Applying the aspect logging pattern”的部分。在此步骤中找到相应的资产，并选择Import（请参见图18）。

　　图18. 导入Aspect日志记录模式实现
 
　　通过导入Aspect日志记录模式实现，会将Aspect日志记录模式实现安装到RSA中。

　　为了使此功能有效，必须给RSA Eclipse外壳安装可选的AspectJ开发人员工具以及Aspect日志记录模式。此功能包含一个新的首选项页面(Windows>Preferences>SOA IF>AspectJ Model-Based Logging)。可以在此页上定义AspectJ模板（生成并包含在已编译的Aspect的AspectJ代码中），请参见图19。Add Default Templates按钮将添加用于进行日志记录的数个简单Aspect，但可以创建任何Aspect代码来与Java方法关联。

　　图19. 在RSA内使用AspectJ设置Aspect
 
　　通过这样定义Aspect，可允许以后修改Aspect代码，以便通过后续生成操作得到新的经过改进的日志记录代码。并不需要在进行日志记录时停止此功能。完全可以对Aspect代码进行更改，从而使其不仅记录服务和缓存调用，还可以执行其他操作，如检索统计数据甚至能在检测到警报条件时调用某个Web服务。对于此类技术，唯一的限制就是您的需求和您的想象力。

　　应用Aspect日志记录功能

　　Catalog服务的非功能需求之一是能够跟踪遗留Catalog应用程序的每个调用。Aspect日志记录功能非常适合以非侵入的方式提供这种横向(Cross-Cutting)关注。以下的部分将说明可以如何在Rational Software Architect的模型驱动的开发环境中将Aspect日志记录模式应用到Catalog控制器。

　　·再次打开SOA Catalog Entity Design Model。图9显示了SOA Legacy Catalog Application Design Model的内部结构。
　　·找到AcceleratedCatalogService类，并右键单击getCatalog()。图20显示了如何使用<<Log>>关键字给getCatalog()操作添加标注。

　　图20. 将Aspect日志记录功能应用到Accelerated getCatalog()操作

 
　　图21. 选择特定的Aspect
 
　　·选择AcceleratedCatalogService类，并再次进行UML-to-Java转换。这次会创建一个额外的AcceleratedCatalogServiceLogger aj文件。以下是生成的aj文件的代码：

　　清单4. 生成的aj文件
               
　　package com.ibm.retail.entity.catalog;

　　public aspect AcceleratedCatalogServiceLogger {
　　   pointcut SimpleConsoleOut (AcceleratedCatalogService cls) : target(cls) && (
　　      call( * getCatalog(String) )
　　   );

　　   before(AcceleratedCatalogService cls) : SimpleConsoleOut (cls) {
　　String op = thisjoinPointStaticPart.getSignature().getName();
　　String cl = thisjoinPointStaticPart.getSignature().getDeclaringType　　().getName();
　　System.out.println(“Entering ” + cl + “->” + op);
　　   }

　　   after(AcceleratedCatalogService cls) : SimpleConsoleOut (cls) {
　　String op = thisjoinPointStaticPart.getSignature().getName();
　　String cl = thisjoinPointStaticPart.getSignature().getDeclaringType　　().getName();
　　System.out.println(“Exiting ” + cl + “->” + op);
　　   }
　　}
 
　　现在，每次在支持AspectJ的项目中进入和退出AcceleratedCatalogService.getCatalog()操作时，都会向控制台输出一条简单的消息。

　　·使用Web Service Explorer测试实现。图22显示了对“Catalog A”的调用，此时客户机只关心Catalog的名称、说明和开始日期。

　　图22. 使用Web service explorer进行测试
 
　　如果在WSDL-to-Java生成过程中选中了monitor Web service复选框，SOAP调用请求应该出现在TCP/IP Tunneller中，带空SOAP响应（请参见图23）。此请求中有两个参数。

　　·此例中Catalog的主键是Catalog“A”。
　　·请求模板指示，仅应该返回名称、说明和开始日期。

　　图23. TCP/IP Tunneller
 
　　图24显示了到控制台的消息的日志记录。

　　图24. WebSphere控制台输出
 
　　查看WebSphere控制台输出大图。

　　同样请参见下载部分，其中提供了打包为项目交换文件的RSA项目。（要导入到RSA，请选择File>Import>Project Interchange。）

　　实现的结果

　　我们通过使用Aspect日志记录功能实现了以下好处：

　　·我们在Aspect应用时采用了MDD方法。
　　·架构师/开发人员不再需要学习Aspect语意。相反，现在可以将日志记录之类的横向关注方法应用于模型的操作。
　　·对于特定项目，现在可以由体系结构团队标识和开发Aspect，所得到的Aspect库能分发给开发团队，以供导入RSA。
　　·通过数次单击鼠标，就可以为AcceleratedCatalogService.getCatalog()操作创建日志记录Aspect。

　　关于模式可组合性的说明

　　通过所给出的三个用法模式（WS响应模板、请求端缓存和Aspect日志记录）的示例，了解到重要的一点是，它们可以应用到相同的应用程序/服务设计和实现领域，而不会对彼此造成负面影响。对于希望获取和开发基于成功设计和实现工作经验的模式的人员来说，模式可组合性概念非常重要。

　　此处所讨论的三个模式均是经过精心设计的，能够确保各自关注自己所处理的特定问题，而不会对设计的其他可能方面做任何假设。例如，WS响应模板模式并不处理或尝试实现缓存或日志记录。缓存模式并不要求进行缓存的服务实现其他接口（如映射接口）。

　　良好模式实现的重点在于，应用程序设计/实现严格限制为模式语意本身，而不涉及任何其他方面。通过将模式的影响限制为仅涉及与其直接相关的方面，可提高其与其他现有的和将来出现的模式的可组合性。

　　结束语

　　本文所讨论的Catalog服务说明了自顶向下的SOA服务标识方法可如何引导发现通常由遗留应用程序提供的可重用IT服务。不过，与遗留应用程序所考虑的问题相比，可重用IT服务经常具有完全不同的非功能需求（互操作性、性能、事务性、可跟踪性），以便满足要求极高的SOA体系结构的需求。

　　本文讨论了Catalog服务的性能和可跟踪性方面的非功能需求。请求端缓存模式应用于模型驱动的开发环境中的Catalog服务控制器，以优化Catalog服务实现。这个特定的模式源自使用基于经验的开发的另一个SOA上下文，并在其他SOA应用程序和类似工作中得到了应用。Aspect日志记录模式也应用于模型驱动的开发环境中的Catalog服务控制器，用于提供Catalog服务调用的非侵入可跟踪性。

　　本文说明了可以如何使用模式来满足优化可重用服务实现时的非功能需求。通过将这些非功能需求与上下文、问题以及模式的“使用场合”部分仔细匹配，也可以使用它们来帮助在构造企业体系结构时降低复杂性和提供体系结构可跟踪性和可靠性。

　　作者简介

　　Harini Srinivasan是IBM Enterprise Integration Group中的SOA Design Requirements团队的成员。她感兴趣的领域包括Web和SOA应用程序性能分析、用于构建SOA解决方案的模型驱动的开发方法、应用程序和运行时的设计与优化。在加入IBM Software Group的EIS团队前，她在IBM T.J Watson Research Center的Software Technology部门担任助理研究员。
 
　　Jim Conallen是IBM软件集团的Rational模型驱动开发策略团队的软件工程师，在该团队中他积极地参与将对象管理组织（Object Management Group，OMG）的模型驱动体系架构（Model-Driven Architecture，MDA）计划应用到IBM的Rational模型工具中。Jim多次作为会议演讲人和并撰写过很多的文章。他的专业领域包括Web应用程序开发，他开发Web Application Extension for UML（WAE），一种可以令开发人员利用UML在适当的抽象和详细层次上对以web为中心的架构建模的UML扩展。此工作作为IBM Rational Rose和IBM Rational XDE Web建模功能的基础。
 
　　Eoin Lane博士是高级解决方案工程师，负责对主要IBM SOA工作的应用程序开发模式进行收集和开发，并通过IBM模式治理过程对这些模式进行处理，以促进其推广应用。Eoin也是用于帮助SOA开发的模型驱动的开发（Model Driven Development，MDD）、基于资产的开发和可重用资产规范（Reusable Asset Specification，RAS）方面的专家。