使用可重用资产构建 SOA 应用程序，第 3 部分：WS 响应模板模式

本系列文章探索可重用资产、菜谱和软件模式，并说明它们可以如何促进 SOA 解决方案的开发。本文是其中的第 3 部分，将对 WS 响应模板模式实现进行说明。可以将 WS 响应模板模式应用到服务的 UML 模型，以创建更为灵活的服务。我们将以 SOA Implement and Optimize Services Recipe 以及随附的参考示例（本系列前两篇文章对其进行了说明）为背景讨论此模式。以后的文章将说明如何将 SOA 模式应用于参考示例，以满足非功能需求。
引言

在本系列前面的文章中，我们介绍了 SOA Implement and Optimize Services Recipe，并对参考示例进行了讨论，以说明可以如何应用此菜谱。该参考使用模型驱动的开发方法（Model-driven development,MDD），并利用 IBM Rational Software Architect 建模功能来开发用例模型、分析模型、设计模型和服务模型。本文说明如何修改现有服务；这是 SOA Implement and Optimize Services Recipe 中的一个重要步骤。

通常已经存在提供核心功能的遗留应用程序。要修改现有服务，必须将此应用程序作为服务提供，而且此服务必须遵循与原始应用程序需求不同的一系列非功能需求。

我们使用 SOA Implement and Optimize Services Recipe 和参考示例来说明软件模式能够如何满足这些新的非功能需求。通过使用软件模式来满足非功能需求，可帮助开发人员和架构师构建一个体系结构一致的服务，从而严格遵守软件开发最佳实践和原则。

修改现有服务

从我们在本系列第 2 部分所讨论的库存系统用例分析中了解到，一个现有的遗留 Catalog 应用程序提供用于访问 Catalog 信息的 Java 接口。现在我们必须将此遗留应用程序作为服务公开。在我们的菜谱中，这是一个过程示例，此过程包含重用现有服务或应用程序的四个步骤：
检查服务模型
检查服务的非功能需求
检查遗留应用程序分析/设计模型
基于非功能需求应用恰当的模式
SOA Implement and Optimize Services Recipe 为其中的每个步骤均提供了参考示例。
以 Rational Software Architect 资产的形式提供了 Catalog 服务及相关消息表示形式的服务模型，可导入到 Rational Software Architect UML 模型项目中。
对于库存系统用例的非功能需求，Rational RequisitePro 需求管理文件是以可重用资产规范（Reusable Asset Specification，RAS）资产的形式提供的。不过，此需求文件应该通过网络上的共享访问形式提供。图 3 显示了在打开参考示例的这个 Rational RequisitePro 需求管理文件后，Rational Software Architect 内的 Rational RequisitePro Requirement Explorer 的情况。
遗留 Catalog 的设计模型；此设计模型作为 RAS 资产提供，可导入到 Rational Software Architect UML 模型项目中。
检查服务模型

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

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

。。。。。。

点击此处查看全文