本文介绍了一种利用 IBM Rational 统一过程（Rational Unified Process，RUP）框架，并结合模型驱动系统开发（Model Driven Systems Development，MDSD）来减少面向服务体系结构（Service Oriented Architecture，SOA）的组件开发中的风险的方法。本文还谈到了一些与 SOA 开发相关的缺陷。

 随着面向服务体系结构在软件开发中的重要性不断增加，越来越多的 IBM® Rational® 客户试图开发并利用面向服务的解决方案。但是构架和开发保证额外关注过程的 SOA 时存在挑战和风险。一个实例就是，构建可复用组件的困难是需要开发人员超越单个应用程序的需求去想象未来可能如何复用服务和当前的业务过程。同样地，当多个业务过程在利用服务时，对其高质量和健壮性能的需求就比传统应用程序大得多。违反安全性或法规遵循需求的服务可能会引入大量业务风险。

本文介绍了如何使用 IBM ® Rational® Unified Process（RUP®）框架，结合模型驱动系统开发（Model Driven Systems Development，MDSD）和统一建模语言（Unified Modeling Language，UML 2.0）或系统建模语言（Systems Modeling Language，SysML）的想法，这可能减少许多与 SOA 开发相关联的风险。特别地，我将介绍将 MDSD —— 与将复杂系统的需求向架构和设计转化相关的 RUP 的一部分 —— 应用于使用 SOA 范型的系统开发。我还将详述一些在使用 SOA 架构风格时应该避免的缺陷。

SOA 的承诺

不但在软件开发中，而且我们生活的许多领域中的复杂度和变化率都在增加。开发团队要在满足质量目标的同时更快速地交付更复杂的解决方案。软件开发团队需要变更他们的方法，因为传统方法不能跟上需求，并且的确已经在许多实例中失败。让我来叙述一些实例。

动机的叙述

大家还记得 9/11 事件后果的新闻文章中说的，美国情报机构没能收集相关的信息使其有效地互相通信？经常进行空中旅行的人都知道航空公司似乎从来都不能传达关于航班比计划起飞时间晚 15 分钟的信息（即使您在等待的飞机甚至已经离开了之前的飞机场！）。您记得 2002 年的汽车召回吗，因为去掉无线电会令汽车不能发动？Operation Desert Storm 中的情况如何呢，由于空军、陆军和海军没有通用的无线电通信能力，日常的电子军事命令不得不通过软盘传递到海军军舰上？您知道美国空军拥有超过 22,000 个指挥控制中心，并且每年还在增加吗？您听说过这样的卫星计划吗，三个不同的团队为其他卫星的位置跟踪创建了数据库？而且，一旦它们发现了彼此，将三个数据库合并仍旧被视为是非常昂贵的，因为每个都负责该计划中其他部分中的不同要素。

这些是如何发生的？我们如何管理业务、政府和军队环境中的这种指数级增长的复杂性？我们必须管理，而且在 IBM Rational 进行的研究正表明，存在我们可以使用的现代、模型驱动的系统开发技术，让我们即使在最大的系统开发计划中都能成功地管理这类的复杂性。

更好的方法

SOA 方法承诺帮助处理这些种类的问题。SOA 通过规定的协作支持各种服务的整合，并且能够构建抽取自企业许多领域的组合的应用程序来达到它们的目标。在上面引用的卫星位置数据库实例中，SOA 参与者本可以指派一个团队来为需要那些服务的企业中的每个人跨未知接口的使用生成所需的功能。

然而，SOA 早期的采纳者遇到了许多负面影响许多团队有效开发符合 SOA 风格的协作要素的互操作集合的能力的问题。这些问题是：

• 明确的不一致性，导致对组件应该如何互操作的模糊和误解
• 经常导致脆弱架构的功能分解
• 不同的和不一致的应用程序开发过程，因而减少了工程团队之间的效率和协作
• 对设计的低层次的关注，与之相对的是更加恰当的，利用了指导开发工作的高层次模式和约束的架构级的关注

模型驱动系统开发（Model Driven Systems Development，MDSD）为帮助企业开发团队符合 SOA 架构提供了理想的方法，它减少了影响团队生成有效且敏感的工程结果的能力的问题发生率。我所建议的 MDSD 的应用实际上是灵活的，也就是说，它支持对粗粒度和细粒度的 SOA 服务的同等容易的发现。当然，该方法着重于确定将企业 IT 基础架构作为灵活实体 —— 响应客户需求和服务质量需求 —— 进行维护所必需的可伸缩的协作模式。

MDSD 流程细化的概述

当我们利用 SOA 架构风格重铸企业 IT 环境时所面临的首要问题之一是企业而不是软件。业务目标通过许多参与者的协作完成，包括人员（让我们称他们为角色）、信息和许多种类的硬件和软件。

MDSD 的一个特点是灵活特性，因此让我们来应用该思想。我们可以认为企业是一类系统吗？Blanchard 和 Fabrycky 将系统定义为：

一组相交互、相关，或相互依赖的形成复杂整体的要素。系统提供企业所使用的一组服务来执行业务目的（使命）。系统组件包含硬件、软件、数据和角色。 ¹

我认为上述充分地描述了典型的业务企业。企业是一种系统，并且我们可以用类似方式进行分析。我将从此起始点，分析构成企业的组件系统。

了解系统环境

利用 MDSD 进行系统分析 —— 企业或相反 —— 开始要通过确定一组与系统协作的 UML/SysML 参与者/角色，并且将系统的业务目标商定并确定为一组 UML/SysML 用例，获得对系统环境的准确了解。图 1 显示了零售系统的环境图。

图 1：零售系统的环境图

根据环境图中表示的参与者和角色，我们可以为同一个系统生成用例图，如图 2 所示。

图 2：与图 1 中显示的相同的零售系统用例图

黑盒操作

下一个步骤是通过为系统参与的每个用例编制一组场景来进行用例分析。如果我们要增强现有的系统或企业，那么我们应该知道这些场景是什么。在此阶段，我们需要小心地避免深入到正在对其用例进行分析的系统中，要停留在“黑盒”级别。编制系统的参与者要求系统什么，以及系统要求与其协作的各种参与者什么。在复杂的系统中，会有许多这样的场景。我们一般会利用 UML/SysML 序列图描述每个场景，如图 3 所示。

图 3：黑盒序列图

当我们在各种序列图中找到对系统的操作时，如果我们利用典型的 UML 或 SysML 建模应用程序来执行此分析，那么该工具将记录那些操作，并且允许我们在其他序列图中复用它们。像这样的分析是主要的人所采取的方法，但是会存在一些模糊和重复，因此了解、精练，并消除操作集中的重复的重构步骤是重要的。结果可能看起来如图 4。

图 4：描绘对系统类/模块的操作的环境图

联合的流程细化

MDSD 的下一个步骤是对上面讨论的每一个操作执行联合的流程细化。联合的流程细化对 MDSD 的恰当使用是至关重要的。这也是一种革新，因为，它允许从许多重要的观点同时推出初始系统的分解（尽管首先考虑个别观点是重要的）。

我称这些观点为viewpoints（观点），依照该术语在 IEEE 1471 中的定义 ² 。每个观点涉及独立的工程关注集。举例来说，逻辑的观点用于描述功能、可扩展性、可维护性、耦合、内聚性和其他相关的关注点的完整性。部署观点用于描述系统的物理特征和资源是否满足功能的需要，以及是否胜任服务质量目标的满足。根据需求可以对其他观点进行定义和使用。

在联合的流程细化中，每个系统操作都作为原子请求，并且经受分析，在分析过程中，将使系统中的要素协作满足该请求。这种协作表现为对系统中这些要素的消息或操作调用的有序集合。虽然系统可能不必要是纯粹的软件，但是良好的面向对象软件设计的基本宗旨在确定应该为此目的而协作的一组良好的要素时是极其有用的。换句话说，如果系统已经存在，并且分析是针对增强的目的的，那么可以让一组现有的要素进行协作，其中一些可能需要修改或开发来满足现有系统不能达到的新目标。该结果被称为逻辑白盒场景，如图 5 所示。

图 5：逻辑的白盒场景的序列图
点击放大

流程细化到多个观点

联合的流程细化步骤的下一个部分清楚地说明了为什么称为“流程细化”。对于我们为其创建逻辑白盒场景的操作来说，我们因此拥有消息的有序集合。我们对此集合执行额外的分析，来从中确定应该寄存，或接收，每个操作调用的系统中的资源要素。每一个这样的资源要素都是产地的实例。我们以这种方式找到的产地共同地表现出考虑到系统的服务质量需求和分配需求而制定的设计决策，如图 6 所示。

图 6：零售系统的分配白盒场景的序列图
点击放大

通过考虑额外的观点来继续对这种特定场景的联合流程细化，因为它适当地衡量出观点所表现的关注。利用同样的有序消息集可以开发描述与每个观点相关的要素之间协作的白盒序列图。举例来说，图 7 显示出组织观点可能的样子。每个观点都需要处理同样的场景，但拥有被评估的不同关注。

图 7：白盒场景序列图实例

最后，为此场景写一个联合的实现表（Joint Realization Table，JRT），在表的每列中显示对于每个观点的协作要素。表中的行与场景中的步骤相关。重要的是要注意，在该表中，指定了 SOA 环境中称为 quality of service requirements（服务质量需求）的非功能需求。总体上，我们指定场景中的服务质量需求，并且将这些作为输入。

在 JRT 指定的协作过程中，这意味着引出对协作中每个操作的服务质量的需求。而，这意味着对那些操作调用（消息）分配给的要素的服务质量的需求，也就是产地的实例。举例来说，注意对产地的给定操作调用可能在许多场景中多次出现。这是每个产地必须满足的总的服务质量需求。表 1 例举了一个 JRT 实例。

联合实现的静态组织

这总结了与 MDSD 联合流程细化的行为方面相关的步骤，但还存在额外的架构分析步骤。应该准备一组 UML/SysML 接口来逻辑地组织各种由在每个观点中协作的要素所实现的操作集。这些如图 8 所示。

图 8：零售实例的联合实现静态结构（接口实现）图

SOA 概念与 MDSD 的关系

现在我将说明上面讨论的 MDSD 概念与 SOA 如何相关联。如果二者之间存在良好的关系，那么我们应该能够利用 MDSD 帮助生成符合面向服务体系结构风格的高质量且有效的系统。

定义和分析

让我们开始对短语“面向服务体系结构”本身进行一些分析。我们可以找到许多对其的定义。我喜欢 Dr. Hao He 说的这个定义：

SOA 是一种架构风格，它的目标是实现相互交互的软件代理之间的松散耦合。 ³

这是个良好的开端。在上面对 MDSD 的讨论中，我注意到其中一个观点 —— 确实，由于完整功能的需要而第一个要考虑的 —— 是逻辑观点。但是逻辑观点中也有许多其他相关的关注点，包括可扩展性、可维护性，好的内聚性和松散耦合。很明显这些概念是相似的。

对 SOA 更精确的定义 —— 结合了 IBM 红皮书中的定义和 ⁴ 其他来源 ⁵ —— 使 SOA 更清楚：

SOA 是架构风格，是协作的称为服务的代理的集合，它的目标是通过例如松散耦合、位置透明，和协议独立性的思想来管理复杂性并达到架构的弹性和健壮性。

单词“服务”在没有谨慎定义的情况下在使用着，因此我们接下来应该对其进行定义。文献中对于服务有各种各样的定义。尽管一些参考文献中可以找到功能定义，但是在其定义中，例如“代理”或“实体”的概念的使用表明，服务确实是由管理它们自己的状态的对象实现的，并且可以根据与面向对象程序设计相关的通用命名法来分类。

Hao He 提出了此定义：

服务是拥有一个描述的实体，并且服务消费者可以通过已发布的接口来调用它。

服务一般由粗粒度的，暴露的，作为单个实例存在，并通过松散耦合、基于消息的通信模型与应用程序和其他服务交互的软件 entity（实体）[我的强调]实现的。

最后，UML 规范列举了必须赋予服务的具体属性 ⁶ ：

• 服务的接口是平台独立的。
• 可以动态地查找并调用服务。
• 服务是自包含的。也就是说，服务维护其自身的状态。

因此，我提出了服务的这个定义：

服务是形式化描述的，自包含的实体，按约定被绑定来实现指定的接口集，并且服务的操作可以作为一个集合被动态的查找到，并且按照需求用消息来调用服务。

根据 Philippe Kruchten ⁷ 的说法，对服务的恰当的 UML/SysML 构建是端口（Port）。UML 端口是非常符合这个定义的。

SOA 通过服务供应者来提供服务的实现。服务供应者无疑地拥有执行服务的资源，因此，根据定义，它是一个产地。产地是更一般的概念，但我们可以认为所有的服务提供者都是产地。

服务规范

在服务的描述中的按约定的绑定是什么？在 UML/SysML 中，一组实现的操作的描述称为 interface（接口）。在 SOA 中，这个概念指的是 service specification（服务规范）。然而，除了所实现的操作规范之外，服务规范还包括服务质量需求的规范。因此服务规范是一类接口，但它加入了服务质量信息。我们可以利用接口和一组约束来为服务规范建模。

不再对这点进行过多的讨论，在我们继续精炼这些概念时，我们发现了值得注意的相似之处。表 2 向 MDSD 和 SOA 之间的映射中添加了一些概念。

对于那些熟悉 MDSD 历史的读者来说，在该表中，我们舍弃了历史上 Rational Unified Process for Systems Engineering （RUP-SE®）的“服务”定义。我们使用在这里独自出现的词来指 SOA 所谓的服务。

结束语

MDSD 为 SOA 架构的开发提供了可靠的方法，该方法生成了架构上具有弹性的架构，其服务质量需求已经向功能需求一样得到健全地分析。因此，其固有的可伸缩性将优于经受其他分析方法的系统。我将 MDSD 的详细描述留给了其他作者（参见 5、15、16，和 17 项），并且鼓励读者参考那些文章和其他工作。

MDSD 将环境作为参与者，并将任务作为描述价值结果的用例。从此信息中，我们找到系统必须实现的黑盒操作集，并且对于每个操作，我们找到了实现它们的场景，每个场景包含许多观点中的要素，这些要素相互协作来实现恰当的服务规范中指定那些黑盒操作要具有的功能。当找到地点时，我们分析每个地点的属性来确定其是否应该成为服务供应者。对于那些应该成为的，MDSD 方法已经为它们开发了服务规范，以及用 SysML 接口写的该规范的功能方面和服务质量的方面，他们源于联合的实现表，还附加上了约束。

这可能听起来太简单了，而下一个步骤是以同样的方式来分析每一个刚刚发现的服务供应者。毕竟，每个供应者都是一个系统，而 MDSD，如上所提到的，在这点上是灵活的。当我们发现服务供应者足够简单到可以立刻构建时，我们可以利用适当的技术实现它们。如果该技术包括面向 Web 的软件，那么实现机制有可能是应用服务器，例如 IBM Websphere® Application Server 或来自其他供应商的同等产品。

参考文献

1. “Intelligence 'Failures' and the Blame Game”，War Watch，Orson Scott Card。
2. “Computer Woes Continue to Plague Airlines”，USA Today online，Harry Weber AP。
3. “Air Force Command Structure -- Federation of American Scientists”，fas.org。
4. Systems Engineering and Analysis（第 3 版），B.S. Blanchard 和 W.J. Fabrycky，Prentice Hall，1998 年。
5. “Model-driven systems development”，IBM Systems Journal Vol. 45，No. 3，2006 年，Balmelli、Brown、Cantor，Mott。
6. “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”，IEEE Std 1471-2000， Institute for Electrical and Electronic Engineers（2004 年）。
7. “Patterns: Service-Oriented Architecture and Web Services”，IBM 红皮书，Endrel 等人，2004 年 4 月。
8. “What is Service-Oriented Architecture?”，Hao He，2003 年 9 月。
9. “Service-oriented architecture (SOA) definition”，Barry & Associates，2004 年，或访问：http://www.service-architecture.com/
10. “Service-Oriented Architecture Explained”，Sayed Hashimi，2003 年 8 月。
11. 统一建模语言：高层结构，Version 2.0，Final Adopted Specification，ptc/03-08-02，2003 年 8 月，Object Management Group。www.omg.org，www.uml.org
12. OMG 系统建模语言 (OMG SysML) Final Adopted Specification，Version 1.0，ptc/06-05-04，2006 年 5 月，Object Management Group： www.omg.org，www.omgsysml.org
13. “面向服务解决方案建模”，Simon Johnston，The Rational Edge，2005 年 9。
14. Rational 统一过程：介绍，第三版，Philippe Kruchten，Addison-Wesley，2003 年。
15. “The Rational Unified Process for Systems Engineering, Part I: Introducing RUP SE 2.0（PDF）”，Murray Cantor，The Rational Edge，2003 年 8 月。
16. “The Rational Unified Process for Systems Engineering, Part II: System Architecture（PDF）”，Murray Cantor，The Rational Edge，2003 年 9 月。
17. “The Rational Unified Process for Systems Engineering, Part III: Requirements Analysis and Design（PDF）”，Murray Cantor，The Rational Edge，2003 年 10 月。

注释

¹ Systems Engineering and Analysis（第 3 版），B.S. Blanchard 和 W.J. Fabrycky，Prentice Hall，1998 年。

² IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”，IEEE Std 1471-2000， Institute for Electrical and Electronic Engineers（2004 年）。

³“What is Service-Oriented Architecture?”，Hao He，2003 年 9 月。

⁴“Patterns: Service-Oriented Architecture and Web Services”，IBM 红皮书， Endrel 等人，2004 年 4 月。

⁵“One I recommend is Service-Oriented Architecture Explained”，Sayed Hashimi，2003 年 8 月。

⁶统一建模语言：高层结构，Version 2.0，Final Adopted Specification，ptc/03-08-02，2003 年 8 月，Object Management Group：www.omg.org，www.uml.org

⁷ Rational 统一过程：介绍，第三版，Philippe Kruchten，Addison-Wesley，2003 年。

参考资料

• 参与论坛讨论。
• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。