我们将结合一个参考示例来说明可以如何使此菜谱。此菜谱使用模型驱动的开发环境（RationalSoftwareArchitect就提供了此类环境）。菜谱还将使用RationalUnifiedProcess作为使用的方法，该方法是以用例为中心的方法，包含迭代开发和和可视模型。
我们首先对SOAImplementationandOptimizationofServicesRecipe和参考示例进行一下介绍，以便说明可以如何将菜谱应用到参考示例。该参考使用模型驱动的开发方法，并利用RationalSoftwareArchitect建模功能来开发用例模型、分析模型、设计模型和服务模型。
ImplementationandOptimizationofServicesRecipe
此菜谱有两个主要的指南：
·选择实现选项·将模式应用到服务实现
选择实现选项
顾名思义，该菜谱处理两种类型的服务：
图1是SOAImplementationandOptimizationofServicesRecipe的关系图，说明了架构师所要遵循的步骤，以评估用例的用户需求和实现与优化服务方面的功能与非功能需求。
图1.SOAImplementationandOptimizationofServicesRecipe略图此菜谱使用模型驱动的开发(MDD)方法，并允许建模人员或架构师将重点放在抽象层，以更好地设计解决方案的体系结构。
从其本质而言，菜谱将尽可能调用更为丰富的信息源，由于我们在使用MDD方法开发SOA解决方案，因此菜谱的第一个调用是链接到RationalUnifiedProcess，以便使用SOA。RationalUnifiedProcess提供软件开发流程指南，这些指南是通过对大量开发活动中使用的最佳实践进行提炼得到的。
菜谱表明，将首先分析用例，以确定需要构建哪些用例以及哪些可以利用现有的遗留服务或应用程序。
·对于现有应用程序，将分析非功能需求(NFR)，并基于这些NFR应用响应的模式。·对于需要构建的服务，将分析以前的服务实现，以实现体系结构一致性。
在这两种情况下，如果可用，将对服务模型和实体模型进行分析。在RationalSoftwareArchitect之类的MDD环境中，这些模型将是作为基本安装的一部分提供的RationalSoftwareArchitect模型，其用户体验方面将遵循RUP的风格。菜谱使用了与图2中所示类似的n层体系结构，可在其中将SOAIF模式应用到相应的层。
SOA模式
在讨论SOA模式的概况前，将n层体系结构视为以下所给出的情况。简单的三层体系结构将包括表示层、业务层和持久层。在SOA环境中，我们可以将业务层进一步划分为服务层、控制器层和实体/对象管理层。此分层情况如图2中所示。会话Faade、消息Faade和业务委托等核心EnterpriseJavaBean模式属于控制器层。
讨论模式时——以GangofFour的《DesignPatterns》为例——会涉及到人们感兴趣的两个不同元素。一个是描述模式的实际文本。这就是将在书上看到的内容，如有关适配器模式的章节。
另外，还有实现该模式的设计工具元素。例如，RationalSoftwareArchitect中就有实现GangofFour书中的不同设计模式的UML构件。因此，如果希望将适配器应用到设计中，将从选择面板选择对应的元素，并在工具中进行一些操作，以对设计进行转换，从而实使用该模式。
·WS响应模板模式（有关模式规范，请参阅参考资料）提供了对粗粒度服务的细粒度访问，并提供了服务定义的灵活性。·请求端缓存模式（有关模式规范，请参阅参考资料）提供了请求端缓存功能。·首选数据源模式是用于进行服务聚合的一种微流模式。·面向方面的模式将结合使用方面、AJDT和模型驱动的开发。
图2：n层体系结构这种业务层细化方式具有很多好处：
·将服务定义同业务逻辑（控制器）以及数据（实体）访问分离，可确保实体中不会透露任何业务逻辑。·在Web服务实现中，服务可以委托给控制器，以对有关方面进行恰当的分离。仅在进行消息拦截时会考虑服务，但将委托给控制器，以确定业务已完成。·控制器将访问其他服务或通过其创建、读取、更新和删除(CRUD)操作访问后端实体，从而实现服务业务逻辑。·现在可以在每个层实现相应的模式，从而满足服务功能需求和系统要求，并产生体系结构一致的应用程序和服务。
为了帮助架构师或开发人员更好地理解此菜谱，还将提供一个示例。
SOA参考示例
该示例演示各个SOA模式如何以可组合的方式一起工作，并说明这些模式如何与其他模式进行交互。此示例基于零售链进行松散耦合，重点是一个名为“LookupItem”的业务服务。LookupItem通常将用于需要在销售前在库存系统中查询商品的零售方案中。通常可将“Lookupitem”作为粗粒度业务服务的一个例子，我们希望从其中了解提供此业务服务所需的对应IT服务。
图3.Lookupitem业务服务业务流程分解可帮助更好地理解用于提供此业务服务的复杂流程。图4显示了此业务流程内的复杂情况。其中使用了两个其他服务，catalog和inventory服务。
·catalog服务用于查找正在寻找的商品的编号或SKU。·inventory服务使用此SKU来确定库存系统中是否存在此商品。该服务将首先查找本地库存系统。如果此查找失败，它将搜索数据仓库目录。该流程还可以随后搜索外部供应商等。图4中更为详细地对此进行了说明：
图4.Lookupitem业务流程分解业务流程分解会将业务服务与业务流程分离开。业务分析人员现在可以不必了解服务实现的复杂性，而直接考虑将作为某个总体服务流程的一部分的Lookupitem服务。业务流程分解还可帮助理解提供此流程及其服务所必需的IT服务。
用例
此用例模型作为可重用资产规范（ReusableAssetSpecification，RAS）资产存储在dWRAS存储库中，可以从该菜谱进行访问。图5显示了如何从此菜谱访问和导入用例模型。请确保将用例模型导入到之前创建的Retail项目。
图5.从菜谱导入用例模型资产用例模型可帮助架构师或开发人员理解需要构建的软件构件和服务。图6中所示的用例模型与图3中所示的业务流程模型非常相似。在此示例中，业务服务和IT服务之间存在非常紧密的映射，但并非总是如此。该用例模型从IT的角度对Lookupitem进行了说明。
图6.Lookupitem用例模型服务标识
在本例中，业务服务和IT服务之间存在一对一的映射关系。但并非总是这样。将IT服务和业务服务视为一体，认为二者一样，这是一种常见且非常危险的错误想法。SOA模式参考体系结构中包括两个IT服务。分别是：
·catalog服务，在产品目录中查找商品编号·inventory服务，根据库存系统查询这些商品的现货数量。
架构师将确定哪些用例可以使用之前已有的应用程序或服务实现，而哪些用例需要进行构造或扩展。在SOA模式参考示例中，有一个之前已有的catalog应用程序，该应用程序公开了一个Java接口。库存系统需要包含一系列对现有后端数据库（如本地商店数据库和中央仓库数据库）的调用。在服务定义的下一部分，将从UML和WSDL的角度对每个用例进行更为详细的复查。
·自顶向下方法：在IBM面向服务的建模方法（ServiceOrientedModelingApproach，SOMA）等自顶向下方法中，将通过使用业务分析对服务进行标识和优先排序。服务的细节通过业务流程模型进行确定。保险行业丰富的领域特定模型（如业务流程模型、业务对象模型）的一个例子就是IBMInsuranceApplicationArchitecture（请参阅侧栏）。服务的细节是从业务流程模型确定的。描述IT服务的WSDL是从在WebSphereBusinessIntegrationModeler等工具中创建的业务流程模型生成的。·自底向上方法：在自底向上方法中，服务是使用现有应用程序包及其接口的知识并结合用于创建组合服务的流程编排方法来定义的。这些服务的WSDL通常从类模型生成。
我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。