了解体系结构在 SOA 中的重要性

您的软件开发团队决定采用面向服务的体系结构 (SOA)，并使得您的企业能够充分利用它的优点，包括增强的响应能力、IT 和业务活动更好的一致性、通过重用现有的资产和更简单的集成实现更低的整体 IT 成本。

当采用 SOA 方法的时候，体系结构甚至变得更加关键，毕竟 SOA 中的“A”表示的就是体系结构。尽管很久以来我们都鼓吹软件体系结构是成功地构建 IT 系统和应用程序的最重要的方面，但不幸的是，许多软件开发项目团队通常只是空谈有关体系结构的想法，而不是真正地去实践它。

研究体系结构的优点

让我们首先来分析软件体系结构之所以占有重要的地位，以及 SOA 使它变得更加重要的原因。

• 抽象：通过提供软件系统的抽象，体系结构可以创建简化的软件视图，以便在隐藏细节的同时能够很容易地描述和理解它。这个视图通常包括提供现有运行实现的抽象。
• 处理所有的关注事项：采用一致的方式、使用体系结构来处理所有经过验证的关注事项（无论是功能性需求、质量还是约束）。体系结构可以分离关注事项，并单独地对它们进行处理，同时确保它们不会相互冲突。
• 沟通：体系结构为不同的干系人（具有不同关注事项的干系人）提供了系统的不同透视图（也称为“视图”或者“上下文”），并允许所有的干系人沟通和理解系统的内容（使用他们的术语）。
• 一致性：采用体系结构的风格和原则（例如，在体系结构框架、参考体系结构或者体系结构模式中所包括的内容）将得到跨项目的一致性，从而改善 IT 系统的互操作性。
• 重用：体系结构从本质上支持重用，这是因为它为 IT 系统的各个构建块提供了相应的描述，以便在将来的组装中进行重用。另外，现有的资产，如现有的实现，一旦在您的体系结构规范中包含了它们，您就可以在新的解决方案中重用它们。
• 团队工作：体系结构的结构方面允许为不同的团队（可能是并行地工作，也可能在地理位置上是分开的）分配任务。例如，可以为不同的团队分配单独的组件。一旦在体系结构级别上进行了描述，那么就可以单独地对这些组件进行设计、实现和单元测试。
• 可说明性：体系结构包括设计（体系结构上的）决策的记录，这种记录可以清楚地说明决策是在何时、因为何种原因、由谁制定的，以及在制定时考虑了哪些备选方案。
• 规定：体系结构为特定部分的设计人员提供了明确的描述，说明系统的每个部分分别是什么，以及它们是如何工作的。另外，它还提供了清楚的规范以指导实现人员（开发人员）。

在本文以及本系列文章后续的部分中，将深入地研究这些概念。

根据 IBM® Rational® Unified Process (RUP) 给出的定义，单词系统 是指“为实现特定的目的而组织起来的相互连接的单元的集合”。无论我们在哪里使用“系统”这个词，您都可以使用“子系统”、“解决方案”、“应用程序”、“组合应用程序”或者“业务应用程序”来代替它。（有关 RUP 的更多信息，请参见参考资料。）

哪些人使用体系结构？

软件体系结构是软件架构师的职责，他们使用体系结构与干系人进行沟通，提供可说明性，并为不同的团队分配工作。

一个特定的体系结构可以提供不同的视图，每个视图都有其重点，并且每个视图用于处理相关的、特定的干系人可以理解的关注事项。服务协作视图是使用 SOA 的一个示例，该视图描述了一个环境中的服务与其他服务之间的行为。这个视图用于与设计人员（他们负责指定应该如何理解这个交互）和实现人员（他们负责指定应该如何实现这个交互）进行沟通。体系结构还用于与干系人进行沟通，无论这些干系人处于开发流程中的什么位置。例如，软件架构师使用体系结构概述向用户、管理人员、项目赞助商或者项目管理人员展示解决方案。

软件体系结构还可以作为决策制定的记录。例如，通过在结构和行为上制定体系结构上的决策，软件架构师可以处理系统的功能性和非功能性需求，通常使用特定的体系结构模式。体系结构描述包括所作出的选择背后的基本原理、设计的备选方法，以及在体系结构中如何处理各个需求的记录。软件架构师负责（有责任）处理所有的需求。同样，设计人员和实现人员都应该遵守体系结构，并处理分配给他们的体系结构中的某些部分。

最后，当软件架构师与项目管理人员紧密地协同工作时，将根据体系结构的结构为不同的团队分配相应的工作。例如，该结构可能是基于包或者组件的。然后可以通过购买软件包、外包给提供者，或者内部开发（由各个独立的团队完成）的方式来处理体系结构中特定部分的理解（设计）和实现（编码）工作。

研究 SOA 中抽象的角色

在“哪些人使用体系结构？”部分中，您了解了体系结构之所以很重要，是因为它有助于对将来（或者当前）系统进行抽象。在这个部分中，我们定义了“抽象级别”，并介绍了对 SOA 来说最关键的抽象级别。

抽象级别提供了什么呢？

抽象提供了简化的软件视图（在隐藏无关细节的同时，可以在视图中进行完整描述和理解），允许您仅仅显示与给定的上下文相关的信息。抽象允许在具有不同目的和技能的人之间进行交流，使用他们能够理解的术语，并降低底层的复杂性。

您或许曾多次听说过这样的短语“更高/更低的抽象级别”或者“抽象层”。抽象级别的目的是为了降低复杂性。抽象级别越高，细节信息越少；级别越低，细节信息越多。

与抽象级别类似的是黑箱视图（不显示实现细节的较高级别）和白箱视图（显示事物工作方式的内部视图）。例如，概念分析模型的抽象级别比详细设计模型的抽象级别更高，因为它忽略了设计组件和元素（它们显示如何实现体系结构）方面的细节。当您降低抽象级别的时候，表现相同的事物则需要使用更多的元素。

很重要的一点是，特定的抽象级别与特定的人员组相关（例如，设计级别是面向设计人员的，而实现级别则是面向开发人员的）。

重要的 SOA 抽象级别

请注意，SOA 抽象级别并不仅仅包含下面四种抽象级别。通过列出 SOA 上下文中的重要抽象级别，这个部分描述了抽象的含义，以及它如何与 SOA 相关联。另外请注意，它着眼于 SOA 开发项目（例如，从业务流程建模到编码实现），而不是生产应用程序的部署或者管理。

在 SOA 环境中，并没有给出抽象级别的正式列表。然而，在设计面向服务的解决方案的时候，需要考虑到下面列出的抽象级别（按从高到低进行排序）：

• 业务。对于业务人员（如业务策划师或者分析师）来说，这个抽象级别是很有意义的。业务体系结构的轮廓将在这个级别中形成。业务体系结构的组成要素包括组织图表、业务目标、重要的性能指标（KPI）、业务流程及其活动，在 SOA 环境中还包括概念业务服务。组件业务建模 (CBM) 就属于这个抽象级别，在第 2 部分中将详细地描述这方面内容。
• 分析。Rational Unified Process 将分析和设计作为单个规程进行考虑，并且在通常情况下，分析元素将会发展成为设计元素。然而，我们希望对它们进行区分，因为在 IT 满足业务需求的情况下，可以将分析考虑为一种抽象级别。它是最概念化的 IT 级别，并且对于 SOA 所承诺的提供业务价值来说，它是极其重要的。对于 SOA，重要的分析级活动称为服务标识，它可以根据需要产生一组标识的概念服务，并与业务保持一致，从而形成更详细的设计工作的输入。
• 设计。设计是定义体系结构的核心组成要素，并且在更详细的级别上，设计文档是关于如何实现体系结构的。本系列文章的目标主要就是针对这个级别。就 SOA 来说，设计元素是面向服务、服务接口或者服务交互的。设计具有一个重要的特征，它应该追溯到更高抽象级别的元素（例如，业务流程或者用例），包括需求。这样可以确保存在一条用于说明设计如何处理相关需求的记录，还允许进行更改影响分析。请注意，设计并不是体系结构的实现，而是关于体系结构是什么，以及应该如何实现体系结构（在从分析进行导出时）或者代码抽象（在对实现进行抽象时）的设计。（请注意，这两种设计视图应该保持一致。）
• 实现。实现是抽象的代码级别。正如接下来关于模型驱动开发的部分中所描述的，可以利用各种开发工具和框架，从较高抽象级别的模型（特别是从设计模型）生成大量的实现。这样做可以支持更高质量的代码，以及改进的开发人员工作效率（将他们从繁重的工作中解放出来，重点关注于业务逻辑）。

体系结构的重要性和需求

RUP 对软件架构师的解释如下：“软件架构师从整体上负责实现主要的技术决策，这些决策使用软件体系结构进行表示。这通常包括标识和说明系统在体系结构上的重要方面，包括系统需求、设计、实现和部署视图。”需求和体系结构是非常重要的两个方面，它们跨越了多个抽象级别，而不是局限于某一个特定的抽象级别。例如，可以在较高的抽象级别上用业务术语来描述一项需求，但是另一项需求则可能需要进行非常详细的技术描述。

需求，无论是功能性的（所需的性能）还是非功能性的（质量和约束），都对体系结构有着直接的影响。架构师需要对它们进行全面地指定和理解，并且应该在收集和分析它们时，对其进行验证。例如，需要通过确认来确保某个业务目标（在业务体系结构中）的所有需求都是可跟踪的，确保不存在冲突的需求，确保所有的需求都是“可实现的”。有时候，人们所讨论的是体系结构上重要的需求；架构师还应该记住，SOA 解决方案（与可重用资产）及其需求将会随着时间的推移而发生变化。这意味着，他或者她需要特别注意可维护性和可伸缩性。请注意，对于 SOA 项目来说，典型的情况是，最初由建模业务流程发现功能性需求（位于业务抽象级别）；然后，RUP 推荐通过各种用例来形式化这些需求（位于分析抽象级别）。

大多数与需求或者体系结构相关的工作都发生在项目的特定阶段，下面的部分将对此进行描述。

抽象级别之间的关系

现在，我们已经标识了重要的抽象级别，让我们更深入地研究它们之间的关系。

如果您查看这些抽象级别，那么您将会发现，在这些级别中都指定了相同的“决策”种类：也就是，关于如何从局部的角度来组织软件、这些局部看起来是什么样子、它们如何组合起来，以及它们如何运转的细节。这些决策递归嵌套，并在较低的抽象级别中不断地添加细节。另外，如前所述，在较高的抽象级别中所指定的决策将约束那些在较低的抽象级别中所指定的决策。

“体系结构上的重要决策”指出某个在详细体系结构级别上很重要的决策。抽象的设计级别包含所有最重要的决策（关于软件结构、打包、接口，以及在实现级别中约束所有较低级别决策的连接）。最重要的是，我们指的是使用某种结构（在很长一段时间内保持有效的）提供整体体系结构的那些决策。例如，我们可以选定一些体系结构部分（组件），以及一些最不容易随时间的推移而更改的接口。不必要的体系结构的更改可能是，仅仅因为持久性机制发生了更改而更改某个接口。应该将这类更改的影响限制于实现中的更改（从而将其限制于抽象的实现级别）。

正如您所看到的，体系结构概括了关于软件（和硬件）的最重要的决策，并且将它们限制于能够经受住时间考验的决策。决定哪些内容是或者不是体系结构中的一部分，看上去有明确的界线，但是这种分离是很重要的，它允许我们管理软件模型的复杂性。它还可以生成这些区别（这是经验丰富的软件架构师的最重要的技能之一）。

面向服务的体系结构构建块：SOA 解决方案堆栈

通过抽象重要概念和分离关注的事项，软件体系结构可以降低复杂性。对于面向服务的领域，SOA 解决方案堆栈提供了 9 个层次（分离关注的事项），以及它们的逻辑体系结构构建块（抽象），这些构建块可以用于在较高的抽象级别上表现面向服务的体系结构。

要获得关于 SOA 解决方案堆栈的更详细的信息，请阅读文章“Design an SOA solution using a reference architecture”*（请参见参考资料部分）。本文的目的在于，说明可以将 SOA 解决方案的关注事项分离为五个功能层和四个非功能层。这五个功能层分别是：

• 操作层。包括运行于 IT 操作环境的应用程序组合中所有自定义的或者打包的应用程序资产，并支持各种业务活动
• 服务组件层。包含软件组件，这些组件为某项服务提供了实现、认识、或者操作
• 服务层。由所有的服务组成，包括在 SOA 内部定义的、与业务保持一致的一组（一个或者多个）IT 功能的抽象规范
• 业务流程层。定义在服务层中公开的服务的组合和编排
• 使用者（或者表示）层。提供向最终用户交付 IT 功能和数据以满足特定的使用偏好所需的功能

请注意，提供者更加关注底层功能层，然而，服务使用者则更多地关注于顶层功能层。

四个非功能层分别是：

• 集成层。提供服务请求从服务请求者到正确的服务提供者的中介、路由和传输的功能
• QoS 层。为 SOA 提供实现非功能性需求 (NFR) 所需的功能
• 信息体系结构和业务智能层。确保包含与数据体系结构和信息体系结构相关的重要注意事项
• 管理层。涵盖 SOA 中业务操作生命周期管理的所有方面

UML 2 Profile for Software Services

Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA) 提供了 RUP 过程和方法中所包含的 SOA 指导。（有关更多信息，请参见参考资料部分。）在 RUP SOMA 中，面向服务的体系结构表现在服务模型工作产品中。与服务模型紧密相关的是 Unified Modeling Language (UML) 2.0 Profile for Software Services，它定义了一种公共语言，用以在较高的抽象级别上描述面向服务的体系结构。可以将这个概要看作定义 SOA 解决方案堆栈的构建块。所有的服务模型工作产品构件（包含匹配的服务概要原型），对于体系结构来说都是非常重要的，包括：

• 服务规范。为服务定义组合一组相关操作的接口；操作及其参数类型或者消息，对于体系结构来说，也是非常重要的。
• 服务使用者。一个或者多个服务的使用者。
• 服务提供者。提供一组服务的软件要素（通常是一个组件）。
• 服务。由服务提供者提供，一项服务可以标识提供的服务规范（在组合服务情况下，可以标识一个或者多个所需的服务规范）。
• 服务协作。用以建模一组服务之间的交互，以实现某种行为（通常最初通过用例在需求级别进行指定）。
• 服务分区。系统（结构）的逻辑或者物理边界，分区通常与特定的质量（策略）相关联。分区还允许并行作业的分配（例如，通过将设计的特定部分分配给一个团队，而将设计的另一部分分配给另一个团队）。服务分区可以提供一种有用的机制，以建模单独的面向服务的 (IT) 系统。

要获得关于服务模型元素，以及与创建它们相关的技术详细信息，请参见参考资料。

研究软件开发流程中体系结构的角色

体系结构是软件架构师的职责，正如我们所描述的，它跨越了多个抽象级别。那么，体系结构活动在什么时候发生呢？

图 3 显示了 RUP、它的规程、阶段和迭代。

在这张图中并没有显示体系结构，那么它在什么时候发生呢？软件架构师在什么时候执行他的大多数任务呢？四个 RUP 阶段分别是：

• 初始。在项目生命周期目标的所有干系人之间实现并发
• 细化。为系统的体系结构建立基准，并为下一个阶段中的批量设计和实现工作提供可靠的基础
• 构造。根据基准体系结构，完成系统的开发
• 过渡。确保软件做好交付给用户的准备

构建良好的软件体系结构活动将完成下面的工作：

• 以初始阶段作为开始，软件架构师在该阶段评估风险并执行初始分析
• 在细化阶段期间达到高峰期，软件架构师在该阶段指定大多数设计，并帮助分配构造工作
• 通常在构造阶段完成，软件架构师在该阶段确保代码遵循设计方案

正如您所看到的，在项目的细化阶段中执行大多数体系结构工作。

总结

在本文中，您了解了如何使用抽象为复杂的设计实现更加清楚、更加容易的表达，从而加速整体开发过程。您研究了在设计 SOA 解决方案和构件（可以用于建模服务体系结构）时的一些相关抽象级别。最后，您分析了体系结构和架构师的角色在软件开发流程中所处的位置。

共享本文…… 请 Digg 这个故事 发布到 del.icio.u Slashdot 一下!

致谢

作者希望感谢他们的架构师同事，特别感谢 Franco Potepan 和 John Catlin，他们对本文进行了审阅。

参考资料

• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
  
  
• 请参见 Wikipedia 关于软件体系结构的条目。
  
  
• 阅读卡内基梅隆大学软件工程研究所关于软件体系结构的文章。
  
  
• 通过 developerWorks 中的 SOA 术语概述 系列文章了解有关 SOA 的词汇表。
  
  
• 找出更多关于 The Open Group Architecture Framework (TOGAF) 的信息。
  
  
• 阅读文章“Model-Driven Software Development”（IBM Systems Journal，第 45 卷，第 3 期）。
  
  
• 阅读“用于软件服务的 UML 2.0 Profile”（developerWork，2005 年 4 月）。
  
  
• IBM 红皮书®： Building SOA Solutions with the Rational SDP 。
  
  
• 阅读 The Rational Unified Process:An introduction (Third Edition) ，作者 Philippe Kruchten（Addison-Wesley Professional，2003 年 12 月）。
  
  
• 阅读“Design an SOA solution using a reference architecture”（developerWork，2007 年 3 月）。
  
  
• 浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。
  
  
• 充分利用 developerWorks Live 的优点！技术事件和网络广播。
  
  
• 在 developerWorks 的 Architecture 架构专区中，获取用以提高您在体系结构方面的技能的各种资源。
  
  
• 查看 IBM OnDemand 演示，以了解有关 IBM 各种软件产品和技术的更详细的信息。
  
  
• 了解最新的 developerWorks Live！技术讲座。
  
  

• Plugin:RUP for Compliance Management Plug-in V1.0。
  
  
• The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)。
  
  
• 下载 IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

• 参与论坛讨论。
  
  
• 使用 developerWorks Blog 社会网络的强大功能，并加入到 developerWorks 社区。