使用可重用资产构建 SOA 应用程序，第 2 部分: SOA 菜谱参考示例

领测软件测试网

本系列探索可重用资产、菜谱（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 应用程序的开发中提供规定性指南的架构师和开发人员。

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

1. 选择实现选项
2. 将模式应用到服务实现

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

选择实现选项

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

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

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

图 1. SOA Implementation and Optimization of Services Recipe 略图
soa-reuse2/Recipe4.gif" width="545" twffan="done"/>

此菜谱使用模型驱动的开发 (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 层体系结构

这种业务层细化方式具有很多好处：

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

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

回页首

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 服务。分别是：

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

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

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

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

catalog 服务

此 inventory 服务模型包含 catalog 服务和 inventory lookup 服务，作为 RAS 资产存储在 dW RAS 存储库中，可以从菜谱对其进行访问。通过菜谱浏览到以下所示的位置，并将 Ref Example Asset：SOA Inventory Service model 导入到前面创建的 Rational Software Architect 项目 Retail 中。可以从菜谱访问 catalog 服务，如下图中所示：

图 7. SOA Inventory Design Model RAS 资产

catalog 服务将在产品目录中查找商品编号——产品的库存编号（Stock Keeping Unit，SKU）。在模型驱动的开发中，服务是应用了 UML 2.0 Profile for Software Services 的 UML 模型类模型。UML 2.0 Profile for Software Services 提供了用于描述服务的模型的公共语言。

UML 2.0 Profile for Software Services 提供了一种描述服务的公共语言（覆盖了整个开发周期的一系列活动），还可为不同的干系人提供不同的视图。UML Profile for Software Services 是 UML 2.0 的概要，对服务建模、SOA 和面向服务的解决方案进行了考虑。该概要已在 IBM Rational Sofware Architect 中实现，并成功地用于对复杂客户场景进行建模，同时可以帮助人们了解开发面向服务的解决方案时的注意事项（请参阅参考资料）。

IBM Insurance Application Architecture IBM Insurance Application Architecture 是一组全面的信息、流程和集成模型集，代表了保险行业的系统开发最佳实践。它是一个信息体系结构蓝图，包含了详细的保险业务内容，可应用到整个企业，也可按具体的项目进行应用。它允许保险公司为信息系统创建详细的规范和跨企业的体系结构。这些模型代表了 300 多年的经验积累，包含了来自很多领先的金融机构的信息（请参阅参考资料）。

我们现在有了一个用于详细地表示如何实际实现服务的模型。通过使用此类模型，可以对应用程序和体系结构模式进行应用，以满足性能、可伸缩性等相关的非功能需求。catalog 服务示例使用了 WS 响应目标模式（请参阅参考资料）和安全模式等模式。可以从 catalog 服务模型应用从 UML 到 WSDL 的转换和从 UML 到 XSD 的转换，以创建服务的 WSDL 和 XSD 表示形式，从而提供两种不同但相互补充的方法来在不同的抽象级别可视化服务。这些转换不在本文的讨论范围之内，将在下一篇关于 WS 响应目标模式的文章中进行讨论。

• catalog 服务 UML 模型：catalog 服务（参见下文）
• catalog 服务规范 (WSDL)：catalog 服务 WSDL

catalog 服务模型

图 8 显示了 catalog 服务模型。该模型包含两个操作：

• getCatalog() 操作接受一个主键作为参数，并返回 Catalog
• getCatalogs() 操作接受一个主键数组为参数，并返回 Catalogs 数组

图 8. Catalog 服务 UML 模型

catalog 数据模型

图 9 显示了 catalog 消息模型。此模型中包含以下非常明了的事实：

• 每个 Catalog 消息包含多个 CatalogItem 消息
• 每个 CatalogItem 消息包含多个 FeatureValue 消息
• 每个 FeatureValue 消息包含一个 Feature 消息

图 9. Catalog 消息 UML 模型

inventory 服务

inventory 服务提供两个操作。首先是一个查询，确定库存中是否包含足够的商品，以满足订单所需的数量。在零售行业，仓库中的现有商品数量称为现货量（Quantity on Hand，QoH）。第二个操作记录库存水平的变化，此变化是由于商品售出或新进货物引起的：这称为库存动向。此服务也能在两个不同的抽象级别进行可视化，与上面的 catalog 服务类似。

• inventory 服务 UML 模型：inventory 服务
• inventory 服务规范 (WSDL)：

inventory 服务模型

图 10 显示了 inventory 服务模型。根据上面的服务描述，该模型包含两个操作：

• getQoH() 操作接受一个 QoHRequest 作为参数，并返回 QoHResponse
• inventoryMovement() 操作接受一个 Integer 作为参数，并返回 Boolean

图 10. inventory 服务 UML 模型

inventory 数据模型

inventory 数据模型允许指定用于指定库存源的位置的请求。这个源可以为商店或地区仓库等。

图 11. inventory 数据 UML 模型

回页首

标识遗留应用程序

遗留 catalog 应用程序设计模型

参考示例遗留 catalog 应用程序设计模型可以从 SOA Implementation and Optimization of Service Recipe 进行访问，其访问方式与前面导入到 Rational Software Architect 中的 SOA inventory 服务模型和 SOA inventory 用例类似。

图 12. 访问遗留 catalog 应用程序设计模型

图 13 显示了遗留 catalog 应用程序的 UML 类关系图。此应用程序是一个 Java™ 组件，公开了一个 Java 接口。getCatalog() 和 getCatalogs() 操作是非常粗粒度的操作，因为将分别返回整个目录和目录列表。

图 13. 遗留 catalog 应用程序的 UML 类关系图

回页首

结束语

在本系列的第一篇文章中，我们介绍了如何将 Rational Software Architect 作为 RAS 客户机来以菜谱的形式检索可重用资产。本文对此方法进行了扩展，以演示如何使用这些菜谱产生服务，以及可以如何使用模式来构建这些服务，以满足特定的非功能需求。

可以通过采用自顶向下业务分析方法（构建新服务时）或自底向上方法（将 SOA 用于遗留系统转换时）来标识服务。

为了演示如何在服务构造期间应用模式，我们使用了一个参考服务示例（可作为 RAS 资产下载）：此参考示例以 SOA Implementation and Optimization of Services Recipe 为基础，提供了使用此菜谱的详细指南。

本系列的下一篇文章将说明如何将 WS 响应模板模式应用于 Catalog 服务模型（请参阅参考资料），以得到一个更为灵活的客户机友好接口。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/