使用可重用资产构建 SOA 应用程序，第 4 部分: 请求端缓存模式

文档选项 未显示需要 JavaScript 的文档选项 样例代码

级别： 中级

Harini Srinivasan (harini@us.ibm.com), 软件工程师, IBM　
Jim Conallen (jconallen@us.ibm.com), 高级软件工程师, IBM　
Dr. Eoin Lane (eoinlane@us.ibm.com), 高级软件工程师, IBM Corporation

2007 年 5 月 15 日

本系列文章探索菜谱、软件模式和模型等可重用资产，并说明它们可以如何促进 SOA 解决方案的开发。本文是其中的第 4 部分，讨论在实现可重用服务时用于处理性能方面的非功能需求的请求端缓存模式。请求端缓存模式源自实际的 SOA 工作，并已在很多其他 SOA 应用程序和工作中再次应用。将使用 Aspect 日志记录功能模式来处理可跟踪性方面的非功能需求。本文还将说明此模式的 Rational® Software Architect™ 实现可如何在模型驱动的开发环境中用于进行服务实现优化工作。

引言

本系列之前的部分介绍了 SOA Implementation and Optimization of Services Recipe 以及随其一起提供的参考示例。此菜谱作为可重用资产提供，介绍了有关如何使用非功能需求来确定需要使用哪个体系结构模式的规定性指南，以构建体系结构一致的应用程序，并提供体系结构可跟踪性和可靠性。此菜谱包含一个参考示例，以说明如何使用利用 IBM Rational Software Architect (RSA) 的建模功能的模型驱动的开发 (MDD) 方法来开发用例和进行分析、设计及服务建模。

本系列的第 3 部分还介绍了如何使用自顶向下方法将遗留应用程序作为服务公开。随 SOA Implementation and Optimization of Services Recipe 提供的参考示例详细说明了如何通过“lookup item”业务流程的领域分解标识和指定可重用 Catalog 服务模型。然后还将 WS 响应模板模式应用到 Catalog 服务模型，以支持对粗粒度接口的请求方细粒度访问，从而提供更为灵活的服务模型。之所以使用此模式，是因为它满足了此服务实现所需的灵活性和互操作性非功能需求。随后使用了 Catalog 服务实现的控制器（用于实现服务业务逻辑）来连接到遗留 Catalog 应用程序。这是遗留应用程序的典型示例，提供了提供服务时所必需的核心功能。不过，此应用程序现在必须作为服务公开，而且将需要满足与创建原始应用程序时不同的一组非功能需求。

本文重点讨论如何满足这个新的 Catalog 服务的其他非功能需求。这些非功能需求与服务性能、服务可伸缩性和可跟踪性相关。在面向服务的体系结构中，创建服务时经常并不知道服务的用户数量，因此经常要考虑性能和可伸缩性方面的非功能需求。一个大家熟知的处理性能非功能需求的模式就是缓存模式。本文将详细讨论请求端缓存模式；此模式用于处理请求端的缓存。

我们还提供了一个示例来说明如何将一个 Aspect 应用于模型驱动的开发环境中。我们所考虑的特定 Aspect 是日志记录 Aspect，用于满足服务可跟踪性非功能需求。

应用恰当的模式

SOA 所注重的是业务敏捷性，实现此敏捷性的一个方法是标识核心业务组件。标识了此类组件后，就可以标识和指定与其关联的业务流程和服务。业务流程分解可以发现提供这些业务流程和服务所需的可重用 IT 服务。另外，还需要指定 IT 服务的输入和输出消息以及这些服务操作的域对象。从 IT 角度而言，这些服务可以建模为用例，可以对用例的非功能需求进行跟踪（在 Requisite Pro 之类的工具中进行）。对于这些变化，如何管理此环境的复杂性呢？具体来说，我们要采用何种方式构建这些服务，才能确保满足其非功能需求呢？

模式是可用于管理此复杂性的一种方法。 模式是对上下文中某个问题的可重复解决方案，通常使用模式规范进行描述。模式规范包括“使用场合”部分，在其中给出应该使用此模式的情况。解决方案的可行性最终由非功能需求确定，如可伸缩性、性能、安全性、事务性、可维护性以及互操作性。通过将这些非功能需求映射到模式规范中的“使用场合“部分，我们可在体系结构决策方面实现可跟踪性和可靠性。

本系列文章讨论四个 SOA 模式。其中每个模式分别满足 SOA 应用程序所常见的特定非功能需求。下面的列表给出了各个模式，并简要描述了各自所处理的非功能需求（有关模式规范的全面说明，请参见参考资料）：

• WS 响应模板模式提供服务接口灵活性、互操作性和可维护性。有关 WS 响应模板模式规范的信息，请参见参考资料部分。
• 请求端缓存模式规范可提高服务性能。有关请求端缓存模式规范的信息，请参见参考资料部分。
• 首选数据源模式是用于服务聚合的微流模式。
• 日志记录模式提供服务调用可跟踪性。有关模型驱动的开发和 Aspect 的信息，请参见参考资料。

在详细讨论这些模式前，考虑以下所示的 n 层体系结构将有所帮助。三层体系结构包括表示层、业务层和持久层。在 SOA 环境中，处理可重用 IT 服务的实现时，可以将业务层进一步划分为服务层、控制器层和实体/对象管理层（请参见图 1）。在应用服务器容器的上下文中考虑分层将有助于理解。

服务层负责指定在该服务中使用的操作以及这些操作所使用的消息的内容。它还负责对进出容器的消息进行序列化和反序列化。控制器层负责实现服务的业务逻辑，具体通过调用其他服务、其他控制器或实体管理层实现。实体管理层负责实体管理，并确保容器内该对象的事务完整性。

我们在第 3 部分中讨论的 WS 响应模板可应用于服务层。（其他直接影响服务定义的模式——如 WS-security 模式——也可应用于这个层。）请求端缓存模式应用于控制器层。Aspect 日志记录模式也能应用于控制器层。我们将在后续文章中对其进行详细分析的首选数据源模式可应用于控制器层。会话 Facade、消息 Facade 和业务委托核心 Enterprise Java™Bean 模式属于控制层。但实体数据管理模式和数据访问对象（Data Access Object，DAO）核心 Enterprise JavaBean 模式属于实体层。图 1 显示了服务实现的 n 层分层体系结构以及这些模式的应用位置。

回页首

性能、性能、还是性能……

在本系列的第 3 部分，我们将 WS 响应模板模式应用到了 Catalog 服务的 UML 模型。其中为 Catalog 服务创建了新的更为灵活的模型。随后，我们使用 UML-to-WSDL 和 UML-to-XSD 转换对新 Catalog 服务模型进行转换，以得到对应的存根和框架代码。随后由服务控制器实现 Catalog 服务，此控制器将访问遗留 Catalog 应用程序，以提供 Catalog 服务所需的 Catalog 数据。图 2 显示了事件的序列。

序列关系图表明，每次调用 Catalog 服务时（在特定 Catalog 中寻找 SKU），必须首先从遗留 Catalog 应用程序检索整个 Catalog，然后再发送到导航器。由于现有 Catalog 应用程序不能修改，而 Catalog 项目大部分都是只读的，因此这就非常适合采用请求端缓存模式。请求端缓存模式将在请求端缓存所请求的数据，以便保持特定的 Catalog 供将来查询使用。在更为详细地分析请求端缓存模式前，我们将先谈点别的，看看可以如何从实际工作中获得这个模式。此处的客户是虚构的，但模式所源于的场景是真实的。

回页首

请求端缓存模式的基于经验的开发

此模式是基于实践经验开发的一个例子，在这种情况下，应用程序/体系结构模式都源自对实际客户工作的总结。我们修改了客户名称，但问题和解决方案的技术细节是非常准确的。

假定有一个虚构的州政府机构 HIPPO，负责管理和处理医疗保健索赔和其他社会服务。HIPPO 包含大量有关索赔管理的业务流程，如“process new claim”。这其中的每个业务流程都包含数个任务，需要完成这些任务才能完成特定的业务流程。典型的 HIPPO 业务流程会长时间不间断执行，平均包含约 10 个业务任务。其中一些任务可以自动化，如检索索赔声明；有些需要人为干涉，如批准/拒绝索赔。HIPPO 通常每天处理约 3,000 项索赔。为了让 HIPPO 更高效地运作，他们决定转型为呼叫中心设计，以集中处理索赔。HIPPO 具有自动化这些业务流程的功能需求，另外还具有一系列关于性能、事务性和完整性等的非功能需求。

为了实现这些功能需求，HIPPO 使用 WebSphere® Business Integration (WBI) Modeler 对其业务流程进行建模。然后使用 WBI Modeler 生成业务流程执行语言（Business Process Execution Language，BPEL），以便在 WebSphere Process Server 内承载业务流程，且能实例化多个业务流程实例。每个流程任何时候都可以在系统内具有多个实例。每个流程实例都包含一系列人工任务，使用了 WebSphere Portal Server 来查询 WPS 和显示这些人工任务。可以随后由呼叫中心对这些任务进行管理，HIPPO 员工可以登录到系统，查看已分配给她的任务。随后可以按优先级、完成日期和其他任务元数据对这些任务进行排序。经理还可以登录到系统后向员工分配新任务，或查看特定员工的任务状态。

性能是 HIPPO 对门户应用程序的主要非功能需求。这就要求门户应用程序能够在特定时间内（例如两秒钟内）显示任务列表。不过，每次用户要求系统刷新（例如，按照结束日期对任务进行排序）时，门户应用程序必须向 WPS 发送新查询，以重新填充任务列表。随着活动流程实例数量的增加，系统的性能会大幅度下降。

进行了反复考虑后，所采用的解决方案是在门户端采用请求端缓存，以缓存人工任务信息。门户应用程序从 WPS 检索任务时，会将其缓存在本地。刷新任务列表时，门户应用程序将首先进行检查，以确定相关项目是否位于缓存中，如果不在，则查询 WPS。此解决方案满足了性能方面的非功能需求。

请求端缓存模式经常能够提供性能问题的有效解决方案，但架构师需要谨慎考虑一系列因素。这些因素包括要缓存的数据的非功能需求，如数据的易变性、缓存的延迟以及是否应该对缓存进行预先填充。在接下来的部分中，我们讨论为何要考虑将请求端缓存模式作为解决方案。现在让我们更详细地介绍此模式。

回页首

请求端缓存模式

请求端缓存模式对一个或多个客户机和一个或多个提供者之间的交互进行协调。协调过程包括保存提供者产生的数据项，并使用它们支持客户机的请求。协调的目的是为了提高数据访问的速度和/或减少数据访问的成本。这个非常通用的模式具有很多变体，用于满足不同的设计目标。模式应该能够帮助简化决策过程，并指导记录有关缓存和策略的决策。

类关系图

类关系图（图 3）显示了此模式的装饰（Gang of Four 设计模式）本质。其中的提供者是 ServiceImpl 类，该类实现了 IService 接口。此接口通常具有 getItem() 和 getItems() 之类的操作，其中 Item 代表某类实体。getItem() 操作获取主键来标识项目，而 getItemKeys() 通常接受能够使用 getItemKeys() 操作转换为一组主键的选择条件。IService 接口还能够具有一个 changeItem() 操作，按照其定义，此操作将导致对项目的内部结构的更改。此时的装饰是 CacheServiceImpl 类。CacheServiceImpl 实现 IService 接口，并通过为 getItem() 和 getItems() 提供缓存功能来包装 ServiceImpl。

序列关系图

图 4 中的序列关系图显示了使用 CacheServiceImpl 客户端代理调用 getItems() 的请求方。getItems() 实现将首先检查缓存，以确定是否能在其中找到相应的项目。如果未在缓存中找到相应项目，getItems() 将随后从提供者获取相应项目。最后会将这些项目存储在缓存中，以供将来使用。getItems() 方法使用 getItemKeys() 操作来获取唯一的主键集，并随后依次使用每个键来调用 getItem() 操作。

回页首

请求端缓存模式实现

现在可以基于模式规范创建多个请求端缓存模式实现。（请参见本系列的第 3 部分中的侧栏，以了解模式规范与模式实现间的差异。）通常，任何实现都将提供用于应用模式的一定级别的自动化功能。我们所讨论的实现将使用 Rational Software Architect 的模型驱动的开发环境。（有关使用此模式规范的基于 Aspect 的实现进行建模的更多信息，请参见侧栏。）对于本部分，我们将分析使用 RSA 模式引擎的请求端缓存模式实现。

此 RSA 模式引擎实现将使用需要进行加速的服务或接口的 UML 模型表示形式。使用此模式的方法遵循了特定的模型驱动的开发方法，后者可实例化服务或接口的 UML 模型元素的模式参数。模式参数绑定后，将自动创建缓存和支持缓存的服务代理等其他 UML 元素。通过对得到的模型调用 UML-to-Java 转换，将生成结果 Java 实现构件。这个实现还允许用户选择采用自定义（内存中）的用户定义缓存或 WebSphere Platform 动态缓存。如果用户选择后者，模式转换将自动生成动态缓存使用的配置文件。

请求端缓存模式的这个实现是使用 RSA 模式引擎创建的。通过使用 RSA 模式引擎创建模式，将得到一个 Eclipse 插件，能使用可重用资产规范（Reusable Asset Specification，RAS）将此插件打包为可重用资产。（有关可重用资产规范的更多信息，请参见参考资料；另请阅读本系列的第 1 部分中的相关部分，以了解有关模式和可重用资产的更多信息。）此打包操作所得到的是一个 RAS 资产。RAS 资产及其关联的元数据可以随后部署到 RAS 服务器（如 developerWorks RAS 存储库）。在下面的部分中，我们将说明如何使用 RAS 客户机从 developerWorks RAS 存储库访问此模式资产。此模式资产将导入到 RSA 中，而且能够扩展 RSA 功能，以允许用户将请求端缓存模式应用到模型。

回页首

应用请求端缓存模式

想看看如何应用请求端缓存模式吗？ 观看 下载 Adobe Flash Player。 了解有关动画演示的更多信息。

请求端缓存模式实现可以使用菜谱导入到 RSA 中。首先导航到菜谱中的“Apply patterns to a service implementation”部分，然后展开名为“Applying the requester-side caching pattern”的部分。在此步骤中找到相应的资产，并选择 Import（请参见图 5）。

这会将请求端缓存模式实现安装到 RSA 中。模式安装后，会出现在 Pattern Explorer 中，如图 6 中所示。

注意：本文是第 3 部分的后续文章。如果您要从干净的工作空间开始，请导入 WS 响应模板最终交换项目。请参见下载部分，其中提供了打包为项目交换文件的 RSA 项目。（要导入到 RSA，请选择 File>Import>Project Interchange。）

以下步骤说明了如何导航菜谱并将遗留 Catalog 模型导入到 RSA 中。请求端缓存模式会随后应用到此模型，并在 UML-to-Java 转换中生成对应的支持缓存的代码。

• 打开 SOA Catalog Entity Design Model。图 7 显示了 SOA Legacy Catalog Application Design Model 的内部结构。

• 导航到 com.ibm.retail.catalog 包，并在此处打开 UML 类关系图。图 9（图 8 中缺少的文本）显示了后端 Catalog 服务的 UML 类关系图。此模型显示了 Catalog 服务的接口和实现。此处有三个操作：
• getCatalog()：用于获取整个 Catalog。
• getCatalogs()：用于基于选择标准获取一系列 Catalog。
• getCatalogKey()：用于将选择条件转换为一组唯一键。

• 在建模透视图中，将请求端缓存模式拖动到打开的 UML 类关系图。图 10 显示了应用请求端缓存模式前的 Catalog 实体设计模型。

请求端缓存模式接受以下参数：

• Service：包含我们希望通过缓存加速的操作的接口/类（CatalogService 接口）。
• getItem：服务接口/类上用于在给定项目键的情况下获取单个项目的操作（getCatalog() 操作）。
• getItemKeys：服务接口/类上用于在给定一组条件的情况下获取键的操作（getCatalogKeys() 操作）。
• getItems：服务接口/类上用于在给定一组条件的情况下获取项目的操作（getCatalogs() 操作）。
• changeItemKey：ChangeItem 中与项目的键对应的参数（例如 setItem()）。
• Cache size：缓存的大小。
• Clustering：Boolean 值，为 True 时表明基础拓扑已集群化，False 表示基础拓扑未集群化。（在希望使用内存中缓存的情况下设置为 False，但如果希望利用 WebSphere 动态缓存功能，则设置为 True。）
• Timeout：必须将项目从缓存中逐出的时间值（以毫秒为单位）。

应用此模式后会得到一系列构件，如下所示：

• 会创建一个 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 文件（请参见“下载”部分）。

• Catalog 控制器现在可以使用 AcceleratedCatalogService 替代 CatalogService 来访问遗留 Catalog 应用程序。现在只需使用一行代码，Catalog 控制器就能够使用请求端缓存功能来缓存从遗留 Catalog 应用程序返回的 Catalog 了。

                

**
 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 的名称、说明和开始日期。

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

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

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

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

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

回页首

实现的结果

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

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

对 Catalog 控制器的根本更改是，从遗留 Catalog 实现更改到了缓存代理，如下所示：

                
  
   com.ibm.retail.entity.catalog.CatalogService catalogImpl = 
      new com.ibm.retail.entity.catalog.CatalogServiceImpl();
   catalog = catalogImpl.getCatalog(keystr);
   

将其更改为：

                     
   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 日志记录模式

使用 Aspect 进行建模 此处所示的基于模型的 AspectJ 功能是一个早期示例，说明 AspectJ 技术可如何在 UML 建模环境中管理和交付。从推出这个初始版本后，其功能已经得到了大幅度改进，开始吸引越来越多的高级开发人员和架构师将其用于为较大的开发团队指定和配置开发环境。请参见参考资料中给出的文章“Modeling with Aspects”，其中对 Aspects for MDD 的下一个版本作了介绍。 此框架中的 Aspect 将作为 Eclipse 插件编译和部署，这些插件负责将运行时组件作为已编译 JAR 文件包括进来。虽然对于简单的 Aspect（如前面讨论过的日志记录 Aspect），此方法要求进行的工作较多，而对于更大更复杂的方面（如第一次失败数据捕获 (First Failure Data Capture) Aspect），情况则要好得多（请参见参考资料）。不仅部署到大团队更容易，而且意外修改 Aspect 的可能性也很小。

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

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

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

设置 Aspect

想看看如何应用 Aspect 日志记录模式吗？ 观看 下载 Adobe Flash Player。 了解有关动画演示的更多信息。

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

通过导入 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 方法关联。

通过这样定义 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() 操作添加标注。

• 选择 AcceleratedCatalogService 类，并再次进行 UML-to-Java 转换。这次会创建一个额外的 AcceleratedCatalogServiceLogger aj 文件。以下是生成的 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 的名称、说明和开始日期。

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

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

图 24 显示了到控制台的消息的日志记录。

查看 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 服务调用的非侵入可跟踪性。

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

回页首

动画演示

如果您是首次遇到包含演示的 developerWorks 教程，则可能希望了解以下内容：

演示是一种可选方法，用于查看教程中描述的相同步骤。要查看动画演示，请单击“观看”链接。演示将在新的浏览器窗口中打开。每个演示都在屏幕底部包含一个导航条。通过使用导航条可暂停、退出、回退或快进演示的内容。演示的分辨率为 800 x 600 像素。如果您屏幕的最大分辨率等于或小于此值，则将必须滚动屏幕，以查看演示的某些区域。必须在您的浏览器中启用 JavaScript，而且必须安装 Macromedia Flash Player 6 或更高版本。

下载 Adobe Flash Player。

回页首

下载

	关于下载方法的信息

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 通过阅读规范了解有关 OMG 标准 Reusable Asset Specification, version 2.2 的更多信息。
  
  
• 阅读“Model Structure Guidelines for Rational Software Modeler and Rational Software Architect”（Bill Smith，developerWorks，2005 年 6 月），了解有关在 RSA/RSM 中进行建模的更多信息。
  
  
• 通过“用于软件服务的 UML 2.0 Profile”（Simon Johnston，developerWorks，2005 年 6 月）了解有关 IBM 的 Service Modeling Profile 的详细信息。
  
  
• 阅读“使用方面建模: 使用方面进行建模介绍 ”（Jim Conallen 和 Eoin Lane，developerWorks，2006 年 8 月）。
  
  
• 通过“Aspects for MDD: Rational Software Architect中的基于方面的追踪与首次失败数据捕获”（Helen Hawkins 和 Sian January，developerWorks，2006 年 7 月）了解关于新 Aspect 框架的信息。
  
  
• “Web 服务响应模板模式：规范”（Eoin Lane，developerWorks，2006 年 10 月） 分析 WSRT 模式规范及其提供的用于改进服务接口的解决方案。
  
  
• “The requester side caching pattern specification: An overview”（Harini Srinivasan、James Conallen 和 Eoin Lane，developerWorks，2005 年 10 月）对请求端缓存模式规范进行了详细说明。
  
  
• 阅读文章“Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process”（Jean-Louis Marechaux，developerWorks，2005 年 8 月），以了解关于 J2EE、RUP、RSA 的信息。
  
  
• 有关 SOA 的更多信息，请访问 developerWorks SOA and Web services 专区。
  
  
• 了解关于 developerWorks 技术事件和网络广播的最新消息。
  
  

• 下载 RUP Plug-In for SOA V1.0。
  
  
• 下载 Rational RequisitePro V7.0 的免费试用版。
  
  
• 了解有关 RUP for SOA Plug-In V1.0. 的信息。
  
  
• 下载 Rational Software Architect V6.0 的免费试用版。
  
  
• 使用 IBM 试用软件开发您的下一个项目，可直接从 developerWorks 下载这些试用软件。
  
  
• IBM alphaWorks 提供了 RAS 的一个参考实现，称为 Reusable Asset Specification Repository for Workgroups，可直接从 alphaWorks 下载。
  
  
• 此处提供了有关 IBM developerWorks 上的 Reuseable Asset (RAS) Repository 的更多信息。
  
  

• EIS 网站：了解 IBM 在 SOA 和企业集成领域的领先情况。
  
  
• 参与 developerWorks 博客，从而加入到 developerWorks 社区中来。

作者简介

		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）方面的专家。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首