SOA术语：开发流程、模型和资产
元数据即关于数据的数据。例如，关于所录制的歌曲的元数据可能包括关于演唱者、专辑、作曲、长度或质量的信息，而数据则是音频记录本身。
根据上下文不同，相同的数据可能为实际数据，也可能为元数据。以前面讨论的开发方法和流程为例。在 RMC 中修改开发方法时，定义要类型化的内容（由元数据提供支持）。例如，可能会定义工作产品、任务和角色的新实例。在此级别，工作产品、任务和角色是元数据元素，元数据还定义这些类型（角色执行的任务）之间的关系。现在考虑设计人员定义有关方法的概念时的情况。假定他们在使用 UML 建模工作产品、角色和任务的概念。在此级别，工作产品、任务和角色是实际的数据，而 UML 是元数据。将稍后在 RMC 中将此数据作为元数据使用。这样看来，可以将 UML 视为元-元数据！
RUP 将模型定义为系统的抽象表示或模拟，可从特定的角度提供对系统的完整描述。模型经常用于更好地了解系统如何工作，或用于记录实际实现的设计决策。模型经常由多个不同类型的部分组成。这些部分作为模型元素进行归类。
模型的目标受众是能够理解这些模型的人群。例如，系统分析人员和设计人员创建和使用分析模型，数据库设计人员设计和查看数据模型。模型可以基于文本和/或图形。由于建模是在保持严密性和完整性的情况下减少复杂性（如在较高的抽象级别进行描述），因此最好使用丰富的图形设计符号，例如在 RUM 中描述为可视建模 的统一建模语言 (UML)。模型位于特定的抽象级别，可以将其转换到更低的级别抽象。例如，分析模型通常会转换为设计模型。
在本系列的第一部分中，我们说明了协作 SOA 更为重要。例如，您的公司可能会将详细设计或实现外包给其他公司。进行建模时，请牢记要将建模结果提供给其他人使用。另外，您的 SOA 设计和开发平台也应该能够接受模型，并将其转换为其他模型。
SOA 设计与开发平台应该允许进行模型的半自动化转换，从而从高抽象级别转换到低抽象级别，最终转换为代码。例如，UML-to-Java™ 转换能从 UML 类关系图生成 Java 代码。
基础框架还应该考虑可跟踪性，该功能实际上就是回溯到较高的抽象级别。例如，假定您希望了解需求中的变更对您的设计的影响。应该能够通过在进行设计决策来支持特定需求时添加的链接（轨迹），以确定在设计中对此需求进行了何种处理。然后，在影响分析期间，应该能够看到所有与该特定需求相关的设计决策（通过轨迹或链接），应该了解此需求中的更改对您的设计的影响。
元模型 是关于模型的模型。这是特定领域的模型，定义概念并提供用于创建该领域中的模型的构建元素。例如，可以将 SPEM 视为流程工程元模型。
作为开源 Eclipse 项目，Eclipse Modeling Framework (EMF) 包括了一个模型元模型（建模领域的元模型）。以下是 EMF 网站上提供的定义：“EMF 是用于基于结构化数据模型构建工具和其他应用程序的建模框架和代码生成工具。通过采用 XML 元数据交换（XML Metadata Interchange，XMI）格式描述的模型规范，EMF 提供了工具和运行时支持，从而为模型生成一组 Java 类；这包括一组适配器类（支持查看模型和基于命令对模型进行编辑）和一个基本编辑器。
核心 EMF 框架包括用于描述模型的元模型 (Ecore)，并为模型提供运行时支持，包括更改通知、采用缺省 XMI 序列化的保存支持以及用于对 EMF 对象进行常规操作的非常高效的反射应用程序编程接口（Application Programming Interface，API）。”
“统一建模语言 (UML) 是行业标准语言，用于指定、可视化、构造和记录软件系统的构件。它简化了软件设计的复杂流程，为构造创建“蓝图”。”来源：Object Management Group (OMG)
UML 的好处在于其具有广泛的行业支持。该规范最初于 1997 年提交给 OMG，拥有很多供应商的设计与开发环境的全面支持，如 IBM Rational Software Modeler (RSM) 或 IBM Rational Software Architect (RSA)。
作为 OMG 标准，该规范的当前正式版本为 2.1.1。其中定义了 13 组概念 和归入两个类别的关系图类型：
- 结构；类、对象、组件、组合结构、包、部署
- 行为：用例、活动、状态机、序列、通信、计时、交互概述
UML 是一种通用建模语言，其主要优势之一是能够使用 UML 概要针对领域特定的建模工作进行扩展。
UML 概要为独立于领域的 UML 提供了简单的扩展机制。概要支持定义领域特定的实体和规则。UML 概要能很好地与开发流程一起使用。例如UML Profile for Business Modeling 支持 Rational Unified Process (RUP) for Business Modeling Plug-In。
概要主要由构造型组成。构造型定义哪个 UML 类（元类）与其关联、该类上的属性以及有关构造型元素如何与其他元素关联的约束。例如，在 UML 2.0 Profile for Software Services 中，Service Specification 构造型扩展 Interface UML 元类。它定义名为 published 的属性来指示服务规范是否已发布到服务注册中心。最后，其约束之一是，所有 Service Specification 操作都应该标记为 public。
UML 2.0 Profile for Software Services
UML 2.0 Profile for Software Services 是“允许对服务、面向服务的体系结构 (SOA) 和面向服务的解决方案进行建模的 UML 概要。该概要（有时候称为服务概要）已经在 IBM Rational Software Architect (RSA) 中实现，已成功在制定复杂客户场景的模型方面得到了应用，可用于帮助传递有关与开发面向服务的解决方案相关的注意事项。”
该概要定义 Message、Service Specification 或 Service 之类的构造型。它还为这些概念提供可方便区分的图形符号。图 2 显示了 UML 关系图的一个示例：保险领域的消息设计模型（在 IBM Rational Software Architect 中）。它将使用服务概要中的 Message 构造型表示为类关系图（一种结构关系图）。
模型驱动的体系结构（Model-Driven Architecture，MDA）为业务和技术提供独立的模型，能满足业务和技术不断更改的情况下的需要。以下是摘自 OMG MDA 用户指南的定义：
“OMG 的 MDA 是一种在软件开发中使用模型的独立于供应商的方法。MDA 提供了相应的方法，支持提供用于以下方面的工具：
- 指定独立于为其提供支持的平台的系统
- 指定平台
- 为系统选择特定的平台
- 将系统规范转换为针对特定平台的规范
MDA 的核心是系统（现有或以后的系统）、平台（提供 J2EE 或 Web 服务等功能）和视角（关注特定概念的抽象概念）之类的概念。
MDA 定义以下模型：
- 计算独立模型（Computation-Independent Model，CIM）：用于定义功能的需求的领域模型。
- 平台独立模型（Platform-Independent Model，PIM）：独立于可以采用其进行构建的技术的业务功能和行为模型。
- 平台特定模型（Platform-Specific Model，PSM）：将 PIM 的规范与特定类型的平台的使用方式进行组合。
MDA 定义了转换，以将系统的模型转换为同一个系统的另一个模型（如从 PIM 到 PSM）。将一个模型转换为另一个模型的方法使用映射进行说明。
MDA 的主要目标之一是允许提供设计及为其提供支持的开发工具。
本部分目前所介绍的内容（即模型和转换）形成了模型驱动的开发（Model-Driven Development，MDD）的基础，该方法有时候也称为模型驱动的软件开发（Model-Driven Software Development，MDSD），是采用 MDA 作为说明标准的软件工程方法。模型驱动的开发 (MDD) 是基于模型和转换的软件开发方法。MDD 支持采用半自动化方式生成代码，可使用一组模型到模型转换以及模型到代码转换从高级业务分析模型生成代码。此功能以一组模型的定义、模型实例的完整性和转换中使用的不同模型间的元素的映射作为后盾。另外，MDD 支持对变更的影响进行分析。
IBM Rational Software Delivery Platform (SDP) 支持使用 MDD（或其他方法，如业务驱动的开发）方法进行端到端企业解决方案的团队开发。"业务驱动的开发（Business-Driven Development，BDD）是一种基于角色的集成软件开发方法，能使业务和 IT 保持一致，可大幅度提高业务的性能。“BDD 也使用模型，关注的是业务和 IT 模型在整个 SOA 生命周期中的协作”。IBM BDD 方法通过 IBM Software Delivery Platform 支持各种角色，如业务分析人员、IT 架构师、J2EE 开发人员或集成开发人员。
资产和模式是 SOA 成功的关键，因为这二者为进行重用提供支持。事实上，采用基于资产的业务模型的企业可获得巨大的增长能力。此类企业不再像传统的基于人力的业务模型中那样受到其员工的效率或数量的限制。恰当使用资产可以对软件投资带来巨大的变化。不过，采用此模型的任何人都会告诉您，这并不简单，需要恰当的治理和基础设施支持。
对 SOA 而言，创造性可能会对效率造成影响。让架构师、设计人员和开发人员完全从头进行每个新项目是我们所不希望的。类似的需求应该能够得到一致的体系结构和设计。资产和模式允许恰当的创造性，使您能够在可能的情况下重用经过验证的解决方案，然后将您的时间和精力集中在需要全新开发的内容上，如特定于该项目的业务逻辑等。
资产是提供上下文中问题的解决方案的构件集合。在此上下文中，构件可以为任意内容，如需求、设计模型、实现代码或测试用例等。可以将构件视为文件系统上的文件。对其成功至关重要的是，资产包括有关如何使用、自定义和扩展资产的说明。
模式是对给定上下文中重复出现的问题的解决方案。模式是一种特定类型的可重用资产。可以对模式的规范（问题、上下文、各个因素和解决方案的说明）与实现（如 Java Bean）加以区分。单个模式规范可以有很多个实现。
根据其应用到的开发过程的阶段不同，模式可归入不同的类别。例如，IBM 电子商务模式将模式分为以下几类：业务、集成、组合、应用程序和运行时。Gang of Four (GoF) 设计模式也非常有名。
使用模式时，可以确保所提供或代码化的解决方案是正确、有用的，而且经过了验证。不过，和任意可重用资产一样，只有在给出了说明何时、为何以及如何使用模式的上下文和方法时，才可以加以采用。存在很多模式，而上下文是开始使用的必要条件。例如，电子商务的模式以流程的形式提供（基于技能和环境），可帮助您标识处理您的业务问题的相关模式。
最后，模式的目标之一是提供一致性，以便最终能因为在设计中使用了模式而基于相同的一组需求得到相同的体系结构。
可重用资产规范（Reusable Asset Specification，RAS）于 2005 年开始采用，是用于描述可重用软件资产的结构、内容和说明的 OMG 标准。RAS 的目标是提供有关如何以一致的标准方式打包资产的非常好的实践。按照规范中的定义，RAS 资产的核心特征包括：
- 分类：资产相关的上下文。
- 解决方案：资产中包含的构件。
- 用法：有关安装、使用和自定义资产的规则。
- 相关资产：此资产如何与其他资产相关。
构件的类型可以由其文件名后缀决定，如 .xml、.txt、.doc 或 .java；也可以由其用途决定，如用例模型或分析模型。由于软件资产 是较为宽泛的术语，RAS 还提供了用于描述特定资产类型的概要。此概念与 UML 概要相同。可以使用 UML 概要来扩展独立于领域的 UML。类似地，可以采用领域特定（如 Web 服务）的 RAS 概要来扩展独立于领域的 RAS。
RAS 资产的文件扩展名为 .ras，打包为 .zip 文件，这意味着其中包含一个清单，可以使用 WinZip 将其打开。图 3 摘自 RAS 规范，说明了核心 RAS 资产的主要部分。
