本系列文章探索菜谱、软件模式和模型等可重用资产，并说明它们可以如何促进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层分层体系结构以及这些模式的应用位置。

　　图1. 服务实现的n层分层体系结构
 
　　性能、性能、还是性能……

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

　　图2. getCatalog()WS响应模板序列关系图
 
　　序列关系图表明，每次调用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 &#101xecution Language，BPEL），以便在WebSphere Process Server内承载业务流程，且能实例化多个业务流程实例。每个流程任何时候都可以在系统内具有多个实例。每个流程实例都包含一系列人工任务，使用了WebSphere Portal Server来查询WPS和显示这些人工任务。可以随后由呼叫中心对这些任务进行管理，HIPPO员工可以登录到系统，查看已分配给她的任务。随后可以按优先级、完成日期和其他任务元数据对这些任务进行排序。经理还可以登录到系统后向员工分配新任务，或查看特定员工的任务状态。

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

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

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

　　请求端缓存模式

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

　　类关系图

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

　　序列关系图

　　图4. 请求端缓存模式序列关系图
 
　　图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功能，以允许用户将请求端缓存模式应用到模型。

　　应用请求端缓存模式

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

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

　　图6. 显示请求端缓存模式的Pattern Explorer
 
　　注意：本文是第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的内部结构。

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

　　图8. SOA Catalog Legacy Design Model概略图

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

　　图10. 应用请求端缓存模式前的SOA Catalog Legacy Design Model
 
　　请求端缓存模式接受以下参数：

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