本系列探索可重用资产、菜谱（recipes，本文中借用菜谱来喻意模板）和软件模式可以如何促进SOA解决方案的开发。本文是本系列的第二篇文章，将描述可以在其中应用菜谱的参考示例。以后的文章将说明如何将SOA模式应用于此类示例，以满足非功能需求。

　　引言

　　本系列的第一篇文章“可重用资产、菜谱和模式”介绍了菜谱是一种提供规定性指南的方法，以便使用模式和分层体系结构创建SOA实现。其中介绍的菜谱称为SOA Implementation and Optimization of Services Recipe。在本文中，我们将对此菜谱进行详细的分析，并讨论其引用的其他可重用资产。应该注意，此菜谱并不完整；我们仅使用其来进行演示。

　　在前一篇文章中，我们建立了IBM Rational Software Architect客户机来连接到IBM Rational developerWorks RAS存储库，并导入了SOA Implementation and Optimization of Services Recipe。这个特殊的模式菜谱使用SOA模式实现和优化服务。其主要受众是致力于提供SOA应用程序开发方面的规定性指南的架构师和开发人员。

　　我们将结合一个参考示例来说明可以如何使此菜谱。此菜谱使用模型驱动的开发环境（Rational Software Architect 就提供了此类环境）。菜谱还将使用Rational Unified Process作为使用的方法，该方法是以用例为中心的方法，包含迭代开发和和可视模型。

　　我们首先对SOA Implementation and Optimization of Services Recipe和参考示例进行一下介绍，以便说明可以如何将菜谱应用到参考示例。该参考使用模型驱动的开发方法，并利用Rational Software Architect建模功能来开发用例模型、分析模型、设计模型和服务模型。

　　Implementation and Optimization of Services Recipe

　　在前一篇文章中，我们将SOA Implementation and Optimization of Services Recipe导入到了Rational Software Architect中。这个特殊的菜谱处理如何应用和使用一系列SOA模式。系统的非功能需求（如性能可伸缩性、互操作性）可以用于确定要使用哪个模式。这些非功能需求提供了恰当使用的指南。此菜谱主要针对要在SOA应用程序的开发中提供规定性指南的架构师和开发人员。

　　此菜谱有两个主要的指南：

　　·选择实现选项
　　·将模式应用到服务实现

　　在本文中，我们将详细分析如何选择实现选项。这将为本系列的后续文章奠定基础，以便将各个模式应用到服务实现中。

　　选择实现选项

　　顾名思义，该菜谱处理两种类型的服务：

　　·全新服务：服务定义通常为已知（或许是通过某种业务服务分析活动得到的）。该菜谱还鼓励架构师或开发人员查找以前具有相似非功能需求的服务的实现。这样可确保当前实现将与以前实现的最佳实践保持体系结构一致性。
　　·与已经存在的遗留应用程序或服务相关的服务。通常，这是遗留服务或应用程序，不受开发人员或架构师的看法影响。这代表了当前存在的大量遗留应用程序和服务，需要将其作为较大的SOA工作中的一部分加以利用。现在必须满足服务的非功能需求，而这通常会涉及可伸缩性和性能问题。

　　图1是SOA Implementation and Optimization of Services Recipe的关系图，说明了架构师所要遵循的步骤，以评估用例的用户需求和实现与优化服务方面的功能与非功能需求。

　　图1. SOA Implementation and Optimization of Services Recipe略图
 
　　此菜谱使用模型驱动的开发(MDD)方法，并允许建模人员或架构师将重点放在抽象层，以更好地设计解决方案的体系结构。

　　从其本质而言，菜谱将尽可能调用更为丰富的信息源，由于我们在使用MDD方法开发SOA解决方案，因此菜谱的第一个调用是链接到Rational Unified Process，以便使用SOA。Rational Unified Process提供软件开发流程指南，这些指南是通过对大量开发活动中使用的最佳实践进行提炼得到的。

　　菜谱表明，将首先分析用例，以确定需要构建哪些用例以及哪些可以利用现有的遗留服务或应用程序。

　　·对于现有应用程序，将分析非功能需求(NFR)，并基于这些NFR应用响应的模式。
　　·对于需要构建的服务，将分析以前的服务实现，以实现体系结构一致性。

　　在这两种情况下，如果可用，将对服务模型和实体模型进行分析。在Rational Software Architect之类的MDD环境中，这些模型将是作为基本安装的一部分提供的Rational Software Architect模型，其用户体验方面将遵循RUP的风格。菜谱使用了与图2中所示类似的n层体系结构，可在其中将SOA IF模式应用到相应的层。

　　SOA模式

　　在讨论SOA模式的概况前，将n层体系结构视为以下所给出的情况。简单的三层体系结构将包括表示层、业务层和持久层。在SOA环境中，我们可以将业务层进一步划分为服务层、控制器层和实体/对象管理层。此分层情况如图2中所示。会话Fa?ade、消息Fa?ade和业务委托等核心Enterprise JavaBean模式属于控制器层。

　　菜谱所使用的SOA模式与业务层相关。所有这些模式都源自战略性IBM SOA工作。其中的每种模式都使用Rational Software Architect模式引擎作为模式规范和模式实现开发。有关更多信息，请参阅参考资料部分。

　　讨论模式时——以Gang of Four的《Design Patterns》为例——会涉及到人们感兴趣的两个不同元素。一个是描述模式的实际文本。这就是将在书上看到的内容，如有关适配器模式的章节。

　　另外，还有实现该模式的设计工具元素。例如，Rational Software Architect中就有实现Gang of Four书中的不同设计模式的UML构件。因此，如果希望将适配器应用到设计中，将从选择面板选择对应的元素，并在工具中进行一些操作，以对设计进行转换，从而实使用该模式。

　　第一个我们称为“模式规范”。第二个我们称为“模式实现”。本系列的后续文章将更为详细地讨论这些模式。

　　将考虑以下四种模式；将会在本系列的后续文章中更为详细地对这些模式进行分析：

　　·WS响应模板模式（有关模式规范，请参阅参考资料）提供了对粗粒度服务的细粒度访问，并提供了服务定义的灵活性。
　　·请求端缓存模式（有关模式规范，请参阅参考资料）提供了请求端缓存功能。
　　·首选数据源模式是用于进行服务聚合的一种微流模式。
　　·面向方面的模式将结合使用方面、AJDT和模型驱动的开发。

　　图2：n层体系结构
 
　　这种业务层细化方式具有很多好处：

　　·将服务定义同业务逻辑（控制器）以及数据（实体）访问分离，可确保实体中不会透露任何业务逻辑。
　　·在Web服务实现中，服务可以委托给控制器，以对有关方面进行恰当的分离。仅在进行消息拦截时会考虑服务，但将委托给控制器，以确定业务已完成。
　　·控制器将访问其他服务或通过其创建、读取、更新和删除(CRUD)操作访问后端实体，从而实现服务业务逻辑。
　　·现在可以在每个层实现相应的模式，从而满足服务功能需求和系统要求，并产生体系结构一致的应用程序和服务。

　　为了帮助架构师或开发人员更好地理解此菜谱，还将提供一个示例。

　　SOA参考示例

　　在SOA Implementation and Optimization of Services Recipe中集成了一个示例，以便进行演示。在此部分，我们将逐步了解该菜谱如何访问用于构造参考示例的资产。为此，我们首先需要在Rational Software Architect中建立一个项目，以便承载这些资产。通常，这些资产将为用例、服务、分析和设计模型。要在Rational Software Architect中创建简单的项目，可以使用以下命令序列：File> Project>Simple>project call the project “Retail”。

　　该示例演示各个SOA模式如何以可组合的方式一起工作，并说明这些模式如何与其他模式进行交互。此示例基于零售链进行松散耦合，重点是一个名为“Lookup Item”的业务服务。Lookup Item通常将用于需要在销售前在库存系统中查询商品的零售方案中。通常可将“Lookup item”作为粗粒度业务服务的一个例子，我们希望从其中了解提供此业务服务所需的对应IT服务。

　　图3. Lookup item业务服务
 
　　业务流程分解可帮助更好地理解用于提供此业务服务的复杂流程。图4显示了此业务流程内的复杂情况。其中使用了两个其他服务，catalog和inventory服务。

　　·catalog服务用于查找正在寻找的商品的编号或SKU。
　　·inventory服务使用此SKU来确定库存系统中是否存在此商品。该服务将首先查找本地库存系统。如果此查找失败，它将搜索数据仓库目录。该流程还可以随后搜索外部供应商等。图4中更为详细地对此进行了说明：

　　图4. Lookup item业务流程分解
 
　　业务流程分解会将业务服务与业务流程分离开。业务分析人员现在可以不必了解服务实现的复杂性，而直接考虑将作为某个总体服务流程的一部分的Lookup item服务。业务流程分解还可帮助理解提供此流程及其服务所必需的IT服务。

　　用例

　　此用例模型作为可重用资产规范（Reusable Asset Specification，RAS）资产存储在dW RAS存储库中，可以从该菜谱进行访问。图5显示了如何从此菜谱访问和导入用例模型。请确保将用例模型导入到之前创建的Retail项目。

　　图5. 从菜谱导入用例模型资产
 
　　用例模型可帮助架构师或开发人员理解需要构建的软件构件和服务。图6中所示的用例模型与图3中所示的业务流程模型非常相似。在此示例中，业务服务和IT服务之间存在非常紧密的映射，但并非总是如此。该用例模型从IT的角度对Lookup item进行了说明。

　　图6. Lookup item用例模型
 
　　服务标识

　　在本例中，业务服务和IT服务之间存在一对一的映射关系。但并非总是这样。将IT服务和业务服务视为一体，认为二者一样，这是一种常见且非常危险的错误想法。SOA模式参考体系结构中包括两个IT服务。分别是：

　　·catalog服务，在产品目录中查找商品编号
　　·inventory服务，根据库存系统查询这些商品的现货数量。

　　架构师将确定哪些用例可以使用之前已有的应用程序或服务实现，而哪些用例需要进行构造或扩展。在SOA模式参考示例中，有一个之前已有的catalog应用程序，该应用程序公开了一个Java接口。库存系统需要包含一系列对现有后端数据库（如本地商店数据库和中央仓库数据库）的调用。在服务定义的下一部分，将从UML和WSDL的角度对每个用例进行更为详细的复查。

　　可以采用两种方法得到服务模型。这并不是二者任选其一，有时候某个方法相比之下更为合适。下面让我们更为详细地了解一下其中的相关信息：

　　·自顶向下方法：在IBM面向服务的建模方法（Service Oriented Modeling Approach，SOMA）等自顶向下方法中，将通过使用业务分析对服务进行标识和优先排序。服务的细节通过业务流程模型进行确定。保险行业丰富的领域特定模型（如业务流程模型、业务对象模型）的一个例子就是IBM Insurance Application Architecture（请参阅侧栏）。服务的细节是从业务流程模型确定的。描述IT服务的WSDL是从在WebSphere? Business Integration Modeler等工具中创建的业务流程模型生成的。
　　·自底向上方法：在自底向上方法中，服务是使用现有应用程序包及其接口的知识并结合用于创建组合服务的流程编排方法来定义的。这些服务的WSDL通常从类模型生成。