了解一些基本SOA术语。本文是本系列的第2部分，Bertrand Portier将在其中定义一些术语（包括开发流程、模型和资产）并说明为何这些是SOA成功的基础。作者还将介绍此领域的一些主要标准。

　　引言

　　在任何领域中，语义都非常重要，而在面向服务的体系结构（Service-oriented architecture，SOA）中更是如此。由于SOA涉及多个团队和组织，因此就相关术语达成一致至关重要。本系列将带着您开始SOA之旅，为您定义基础术语和主要概念。您将了解SOA领域中所使用的各个词汇。对于每个术语，将说明其为何对SOA重要、其在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。

　　本系列的第1部分确定了业务焦点，并通过定义服务 和SOA等术语为后续部分打好了基础。本文将介绍成功SOA采用所必需的软件工程方法和流程，还说明交付SOA解决方案所需的构件（如模型和资产）。

　　开发流程和方法

　　成功的软件开发需要以下因素：

　　·需要得到理解和遵循的原则。
　　·进行了正式说明的基于经过验证的最佳实践的方法和技术。
　　·可以进行定制的流程。

　　方法内容

　　方法内容 描述需要生成什么内容、如何执行相关工作以及由谁执行。

　　方法内容构件包括：

　　·角色：定义技能和工作产品职责。软件架构师 就是角色的一个例子。

　　·工作产品：任务的结果，可以为交付内容，也可以不是交付内容。服务模型 就是工作产品的一个例子。

　　·任务：特定角色执行的步骤序列。任务使用输入工作产品来生成或修改输出工作产品。标识服务 就是任务的一个例子。

　　·指南：文档说明。术语表、模板、示例 和工具使用指导信息 都是指南。

　　流程

　　流程 用于将方法内容组织到开发周期中，并指定要完成的工作的顺序。要完成的工作的顺序独立于开发生命周期模型（如瀑布式或迭代）。可以将流程视为工作流或分解结构。通过流程，项目经理可以确定在项目的每个阶段需要哪些人员以及修改了哪些工作产品。如果熟悉Rational Unified Process (RUP)，则可以将RUP规程（如分析与设计实现）视为方法内容，而将RUP阶段（如细化和构造）视为流程元素。

　　务必将方法和流程这两个概念加以区分，并提供框架来支持分别对其进行修改。

　　Rational Method Composer

　　IBM Rational Method Composer(RMC)是基于Eclipse的方法与流程创作平台，用于集成、定制、代码化和发布流程。使用方便而且功能强大的RMC提供了一组流程，可以方便地加以使用或自定义，如Rational Unified Process(RUP)。负责维护流程的项目经理、项目管理者以及程序管理员通常会使用RMC，该工具可为本部分所描述的概念提供支持。

　　RMC中进行的工作的输出是作为HTML发布的流程（通常采用网站的形式）。希望遵循该流程的组织可以随后使用此流程站点。

　　软件流程工程元模型

　　本部分将讨论开发流程。软件流程工程元模型（Software Process Engineering Metamodel，SPEM）是正式描述软件开发流程的的标准规范。作为Object Management Group(OMG)标准，SPEM是独立于供应商、方法和框架的。1.1版于2005年1月正式发布，而包含重大更新的2.0版目前正在制订中。

　　Rational Unified Process

　　Rational Unified Process(RUP)基于全球数千项目所采用的最佳实践，是能够针对具体项目进行方便定制的软件开发流程。RUP包括有关优先级权衡、迭代开发、可视建模、软件质量和团队协作的主要原则。RUP定义规程（方法内容）和阶段（流程），如图1中所示。

　　图1. Rational Unified Process (RUP)
 
　　Rational Unified Process for Service-Oriented Modeling and Architecture

　　Rational Unified Process for Service-Oriented Modeling and Architecture(RUP Plug-In for SOMA)构建于RUP之上，可提供有关开发面向服务的解决方案的指导。2.4版（请参见参考资料）提供了组合之前RUP for SOA内容和IBM Global Business Services(GBS)SOMA方法的统一方法。RUP Plug-In for SOMA为软件架构师和设计人员提供了有关面向服务的体系结构的分析、体系结构和设计的具体指导信息。

　　提供了专用统一建模语言（Unified Modeling Language，UML）概要，用于建模领域特定的解决方案（包括SOA），并随之提供了紧密相关的专用流程。例如，有支持RUP Plug-In for SOMA的UML 2.0 profile for Software Services。

　　注意：将在本系列的后续文章中讨论与管理相关的流程。

　　IBM技术

　　如本系列的第1部分中所述，组件业务建模（Component Business Modeling，CBM）可帮助组织对策略、技术、操作和投资一致性形成大量新的认识。CBM支持对形成差别的业务组件进行标识，还支持对业务流程进行分析。

　　面向服务的建模与体系结构（Service-Oriented Modeling and Architecture，SOMA）提供了有关SOA解决方案的分析和设计的指导信息。SOMA支持对与业务保持一致的服务进行标识、规范化和执行（在设计层）。将在稍后详细讨论此主题。

　　模型、UML、资产与模式

　　元数据

　　元数据即关于数据的数据。例如，关于所录制的歌曲的元数据可能包括关于演唱者、专辑、作曲、长度或质量的信息，而数据则是音频记录本身。

　　根据上下文不同，相同的数据可能为实际数据，也可能为元数据。以前面讨论的开发方法和流程为例。在RMC中修改开发方法时，定义要类型化的内容（由元数据提供支持）。例如，可能会定义工作产品、任务和角色的新实例。在此级别，工作产品、任务和角色是元数据元素，元数据还定义这些类型（角色执行的任务）之间的关系。现在考虑设计人员定义有关方法的概念时的情况。假定他们在使用UML建模工作产品、角色和任务的概念。在此级别，工作产品、任务和角色是实际的数据，而UML是元数据。将稍后在RMC中将此数据作为元数据使用。这样看来，可以将UML视为元-元数据！

　　模型

　　RUP将模型定义为系统的抽象表示或模拟，可从特定的角度提供对系统的完整描述。模型经常用于更好地了解系统如何工作，或用于记录实际实现的设计决策。模型经常由多个不同类型的部分组成。这些部分作为模型元素进行归类。

　　模型的目标受众是能够理解这些模型的人群。例如，系统分析人员和设计人员创建和使用分析模型，数据库设计人员设计和查看数据模型。模型可以基于文本和/或图形。由于建模是在保持严密性和完整性的情况下减少复杂性（如在较高的抽象级别进行描述），因此最好使用丰富的图形设计符号，例如在RUM中描述为可视建模 的统一建模语言(UML)。模型位于特定的抽象级别，可以将其转换到更低的级别抽象。例如，分析模型通常会转换为设计模型。

　　在本系列的第1部分中，我们说明了协作SOA更为重要。例如，您的公司可能会将详细设计或实现外包给其他公司。进行建模时，请牢记要将建模结果提供给其他人使用。另外，您的SOA设计和开发平台也应该能够接受模型，并将其转换为其他模型。

　　自动化与转换

　　SOA设计与开发平台应该允许进行模型的半自动化转换，从而从高抽象级别转换到低抽象级别，最终转换为代码。例如，UML-to-Java转换能从UML类关系图生成Java代码。

　　基础框架还应该考虑可跟踪性，该功能实际上就是回溯到较高的抽象级别。例如，假定您希望了解需求中的变更对您的设计的影响。应该能够通过在进行设计决策来支持特定需求时添加的链接（轨迹），以确定在设计中对此需求进行了何种处理。然后，在影响分析期间，应该能够看到所有与该特定需求相关的设计决策（通过轨迹或链接），应该了解此需求中的更改对您的设计的影响。

　　元模型 是关于模型的模型。这是特定领域的模型，定义概念并提供用于创建该领域中的模型的构建元素。例如，可以将SPEM视为流程工程元模型。

　　Eclipse Modeling Framework

　　作为开源Eclipse项目，Eclipse Modeling Framework(EMF)包括了一个模型元模型（建模领域的元模型）。以下是EMF网站上提供的定义：

　　“EMF是用于基于结构化数据模型构建工具和其他应用程序的建模框架和代码生成工具。通过采用XML元数据交换（XML Metadata Interchange，XMI）格式描述的模型规范，EMF提供了工具和运行时支持，从而为模型生成一组Java类；这包括一组适配器类（支持查看模型和基于命令对模型进行编辑）和一个基本编辑器。

　　核心EMF框架包括用于描述模型的元模型(Ecore)，并为模型提供运行时支持，包括更改通知、采用缺省XMI序列化的保存支持以及用于对EMF对象进行常规操作的非常高效的反射应用程序编程接口（Application Programming Interface，API）。”

　　统一建模语言(UML)

　　“统一建模语言(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概要能很好地与开发流程一起使用。例如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构造型表示为类关系图（一种结构关系图）。

 

　　图2. UML类关系图
 
　　模型驱动的体系结构

　　模型驱动的体系结构（Model-Driven Architecture，MDA）为业务和技术提供独立的模型，能满足业务和技术不断更改的情况下的需要。以下是摘自OMG MDA用户指南的定义：

　　“OMG的MDA是一种在软件开发中使用模型的独立于供应商的方法。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生命周期中的协作”（请参见本系列的第1部分）。IBM BDD方法通过IBM Software Delivery Platform支持各种角色，如业务分析人员、IT架构师、J2EE开发人员或集成开发人员。

　　请参见参考资料中提供的IBM Systems Journal文章的链接，IBM思想领袖(thought leader)在其中深入地讨论了模型驱动的软件开发方法。

　　资产

　　资产和模式是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资产的主要部分。

　　图3. 核心RAS资产的主要部分
 
　　结束语

　　本文定义了有关软件工程流程和方法的术语。定义了用于构建SOA解决方案的软件构件，如模型、资产和模式等。另外还介绍了主要的标准，如SPEM、UML和RAS。

　　后续文章将定义与分析、设计、实现、运行时和管理相关的SOA术语。欢迎您继续阅读developerWorks上本系列的其他文章！