本系列文章将说明菜谱（recipes，本文中借用菜谱来喻意模板）、软件模式和模型等可重用资产可以如何帮助加快SOA解决方案的开发。SOA Implementation and Optimization of Services Recipe菜谱提供了规定性指南，用以确定如何使用模型驱动的开发方法来进行服务构造和利用其他可重用资产（如构造中的模式和模型）开发服务。我们将介绍通过一系列IBM SOA策略合作项目得到的四种新SOA应用程序模式。这些SOA模式代表了从这些SOA解决方案的开发过程获得的重大经验教训。该菜谱还对参考示例应用程序进行了利用，该参考示例应用程序演示了如何将这些新SOA模式部署到UML模式，从而满足服务的各个服务质量要求，如互操作性和可伸缩性。通过此菜谱可帮助产生符合代码开发最佳实践的体系结构一致的SOA应用程序。

　　引言

　　本文将对可重用资产、菜谱（recipes，本文中借用菜谱来喻意模板）和模式进行介绍。 资产是针对问题提供解决方案的构件集合。可重用资产规范（Reusable Asset Specification，RAS）

　　软件模式是特定上下文中的问题的可重复解决方案。Rational Software Architect采用了一种模型驱动的开发（model -driven development，MDD）方法来处理软件模式。MDD通常允许使用一组转换从一个抽象级别转换到另一个抽象级别。转换的一个例子就是从分析模型转换为设计模型，可能还随后从设计模型转换为代码。

　　多个Rational Software Architect模式和其他资产（如模型或需求）可能交织在一起，以形成粒度更大的解决方案。菜谱提供了流程指南、上下文和组成元素（即模式和资产）的描述。

　　菜谱、Rational Software Architect模式和转换以及其他资产均使用RAS进行打包，存储在资产或RAS存储库中。RAS存储库是开发资产存储库，提供了发现可用于特定解决方案的资产和元素的机制。我们将重点讨论SOA解决方案，但这个概念可以在很多地方使用。

　　模式菜谱提供了有关指定模式的使用、组织以及相互关系的文档。菜谱提供了有关使用模式及其实现所必需的资产的指南。菜谱可帮助将一个模式的输出与另一个模式的输入紧密地联系到一起。菜谱可以替代一个或多个模式。在上下文可能随着时间而改变的情况下，这非常有用。

　　SOA Implementation and Optimization Recipe是一个Rational Software Architect模式和转换集合以及有关提供SOA解决方案的指南。在该菜谱中讨论的模式将操作UML模型来生成和优化服务。Rational Software Architect模式是使用Rational Software Architect Pattern Engine实现的。每个Rational Software Architect模式和转换都作为Eclipse插件实现，均使用Rational Software Architect模式创作和转换API。

　　可重用资产简介

　　几年前，由软件行业领先企业组成的联盟——包括IBM、Rational Software（当时尚未被IBM收购）和Microsoft——开始讨论如何帮助组织对软件投资进行重新利用。当时，该联盟将资产定义为：可提供给定上下文中的问题的解决方案的构件集合。

　　资产也可以具有其他特征。资产可以具有允许用户通过设置各种参数对其进行自定义的可变点。可以采用这种方式处理的资产称为模板。目前，IBM Rational工具就是在考虑此定义的前提下实现的。

　　资产包括有关其使用的说明或规则，可尽可能减少开发人员发现、分析、使用和测试资产所需的时间。资产还要对开发和业务上下文进行描述，可以（也应该）在此上下文中使用此资产。

　　资产包含的构件类型取决于重用上下文。对于开发上下文，资产可以包含需求、模型、源代码和测试。构建服务的人员应将此类构件包含进去，以便其他开发人员有效地重用服务。

　　请注意，资产的定义与模式的定义非常相似。设计就是如此，因为模式和资产背后的基础概念都是上下文、问题和解决方案。不同之处在于细节不同。资产是比模式更为一般的概念。资产的可变点在构件级别，而模式则具有应用到整个模式（而不一定是特定构件）的参数和参与者（可变点类型）。

　　RAS简介

　　如何组织和结构化资产？我们需要知道哪些有关它的信息？可重用资产规范(RAS)提供了一个结构，可以圆满解决这些问题。此规范是一项Object Management Group(OMG)标准，于2005年开始采用。

　　存在很多类型的软件开发构件，可能以任何形式存在，反映出设计风格的变化。这个多样性可能增加发现、理解和重用其他作者的构件的成本。通过指定对这些构件进行组织、描述和打包的方法，RAS可跨诸多资产提供一致性和可预测性，从而大幅度减少资产管理和使用的成本。

　　为了说明标准化资产打包的价值，让我们了解一下标准化是如何为夜间运输公司提供帮助的。通过向客户提供标准信封和包装箱，并要求在运输标签上填写一致的信息，这些公司可籍此建立成熟的跟踪系统。此外，这些策略还有助于在整个业务范围内更好地进行各项规划和决策工作，既包括确定传输带宽度，也包含每个运输工具能承载多少包裹以及需要多少运输工具。

　　资产标准化可通过类似的方式提高效率，可在软件开发工具中实现高效率和自动化并提高使用这些工具的团队的工作效率。通过使用RAS，开发人员可以将每个资产打包为元数据包装，其中包含顶级属性，例如资产的名称、版本和描述（请参阅图1）。

　　图1：RAS元数据结构
 
　　如图1中所示，RAS资产具有一个有助于搜索和浏览的classification部分；此部分可以包含简单的名称/值对描述符和上下文声明（如具体的领域、开发或部署上下文）。

　　图1中所示的solution部分是资产的重要部分，描述提供解决方案的构件集合。

　　usage部分提供有关使用可变点应用和自定义资产的指南。可能可以通过使用脚本和向导实现某些使用信息的自动化，这些脚本和向导与其他构件一起存储在solution部分中。

　　related assets部分定义资产与其他资产的关系，可帮助创建资产集合或系列，以形成粒度更大的解决方案。
　
　　为了支持组织中各种程度的重用、正式化和流程成熟度，很多RAS资产部分都是可选的。RAS还可以通过配置文件进行扩展和自定义。OMG当前提供了三个配置文件：Default配置文件、Default Component配置文件和Default Web Service配置文件

　　Default配置文件用于打包任意类型的软件资产，而其他两个配置文件分别用于与组件和Web服务一起使用。
　
　　模式简介

　　术语“模式”的定义非常多。如果不加留心，虽然的确应用了模式，也可能不会注意到使用了模式。这是模式一个好的特征，同时也是危险的特征。一方面，仍然可能不会注意到模式，而仅会看到所应用模式的好处。另一方面，没有认识到应用模式的原因和目的，模式的基本原理本身、相关知识以及好处可能会被忽略，最终会被遗忘而不加利用。总之，抽象既可能是我们的朋友，也可能成为敌人。

　　定义

　　但首先，什么是模式？此处，我们将借用一些思想先驱已在此领域获得的工作成果：

　　James Coplien将模式定义为“可解决在特定上下文中的问题的重复出现的结构配置，构成美学或文化价值的某个整体或系统的完整性。”（Organizational Patterns，第4页，Pearson Prentice Hall）

　　christopher Alexander写道：“每个模式描述在我们的环境中一再重复出现的问题，然后描述该问题的解决方案的核心内容。”（Alexander，1979）他还写道：“每个模式都是一个三段式规则，表述特定上下文、问题以及解决方案之间的关系。”（Alexander，1979，第274页）

　　Booch写道：“模式可提供某些上下文中的常见问题的良好解决方案。”（The Unified Modeling Language User Guide，第370页，Addison Wesley）

　　尽管大多数人都认可这个定义，但在本文中，我们将选择最常见的定义版本：

　　模式是对给定上下文中重复出现的问题的解决方案。

　　什么是模型驱动的开发？

　　模型驱动的开发基本上是用于指定和实现解决方案的软件相关抽象。可以在整个软件开发生命周期的各个地方使用模型。而且，在生命周期的任何位置，模型都是以特定的抽象级别加以表述的。

　　例如，业务流程模型描述任务、条件、资源、成本和时间安排。由于模型经过了优化，因此可能描述特定于IT系统或服务的资源的本性。这种类型的优化可能减少抽象级别。

　　另一个例子是用例模型，用于列出参与者。由于模型经过了优化，因此可能会描述用例实现的本性，对用于实现用例的组件和服务进行标识。同样，这种类型的优化可能减少抽象级别。

　　抽象也可能向另一个方向发展，通过增加抽象级别，从而减少模型中的细节级别。

　　凭借着某种眼力，我有时候会问“有没有别人发现模型的价值？”模型已经投入使用了相当长时间了。根据Hermann Schichl在《Modeling Languages in Mathematical Optimization》中的说法，“‘建模’一词来自拉丁词modellus。它描述人类复制现实的一种典型方法。人类学家认为，构建抽象模型的能力是让智人(Homo sapiens)具有竞争优势的一个重要特征……”（History of modeling，第25页）

　　随着时间的推移，Schichl进一步指出：“到公元前2000年，至少有三种文明（巴比伦、埃及、印度）具有一定的数学知识，并使用数学模型。”（History of modeling，第 25 页）

　　Schichl认为，早期使用的图形模型之一是在天文学领域。在这个领域，托勒密于公元150年创建使用圆圈和中心点创建了太阳系的一个模型。显然，此模型一直沿用到1619年，然后出现了一个更好的模型，该模型的基础理论今天仍然在使用。（History of modeling，第26页）

　　模型可提供进行沟通的手段，设计合理时，可提供能在相当长时间内使用的恰当抽象。有多少模型能够使用近1500年，更不用说应用程序的一个或两个版本了？

　　为特定上下文选择恰当抽象非常关键。

　　模式规范和模式实现

　　考虑模式方面的工具提供情况，我们将模式规范和模式实现的概念分离开来。模式规范是描述模式的文本；您将在书中或网页等上看到它。

　　模式可以采用多种形式之一实现；因此，对于每个模式规范，都可能会存在多个模式实现。模式可以实现为UML模型、组件或服务。

　　图2：模式规范和模式实现关系
 
　　我们此处描述的模式是使用UML模型实现的，可使用一些转换技术对这些模型进行优化。这要求使用模式引擎或机制来完成此任务。