理解面向服务的体系结构

理解面向服务的体系结构

发布日期 : 2005-10-17 | 更新日期 : 2005-10-17

David Sprott 和 Lawrence Wilkes

CBDI Forum

本文简明地解释了面向服务的体系结构，它是什么，以及它对体系结构，CIOs，项目管理，业务分析员和上层开发人员的影响。

本页内容

介绍
原则和定义
SOA基础
处理事务
体系结构
服务体系结构
SOA平台
企业SOA
摘要

介绍

目前看来大多数软件的功能最终将作为服务来交付和使用。当然，它们可以实现为紧密耦合的系统，但从门户、 设备以及其它终端使用的观点看，它们将使用一种面向服务的接口。 我们已经注意到有人提出体系架构师和设计者应该谨慎避免将所有功能都作为服务。我们认为 这是不正确和不适当的。如果有了成熟的Web服务协议和技术，再考查是否将所有功能实现为Web服务是否有效，这可能会 更加有效，但这并不会减弱从服务的角度来设计所有功能的需求。服务是发布的主要构造成分，应该在每一重要的接口中使用。 面向服务的体系结构可以让我们按照相关的服务来管理使用（发送、接收、使用，等等）服务。这将对我们如何管理软件生命周期 产生重大影响－－从需求规格说明开始就作为服务，服务的设计，服务的获取和外包，以及服务的评估等等。

随着时间推移，功能被说明、发布或使用的抽象级别会逐渐越来越高。我们已经经历了从模块化、对象，到现在的服务的发展过程。 然而，在许多方面，SOA的命名还是令人遗憾的。当然，SOA也和体系结构相关，不可能将讨论限制在体系结构方面，因为一些事物，如业务 设计和发送过程也是重要的考虑因素。一个更有用的命名方法可能是面向服务（Service Orientation）或SO。实际上这与面向对象（OO） 和基于组件的开发（CBD）有许多相似之处：

• 类似于对象和组件，服务代表了自然的建造单元块，它可以让我们按更熟悉的方式来组织功能。

• 类似于对象和组件，服务是一个功能建造单元块，它可以

  • 组合信息和行为。

  • 隐藏内部的工作，以防外部入侵。

  • 为其它部分提供一个相对简单的接口。

• 对象使用了抽象数据类型和数据抽象，服务可以通过方面或上下文环境提供类似级别的适应性。

• 对象和组件可以按照类或继承行为的服务层次 来组织，服务可以单独发布和使用，或者按层次或协作方式来使用。

对于许多组织来说，研究面向服务的体系结构的起点是对Web 服务的考虑。然而Web服务不是内在的面向服务的。 一种Web服务只是提供一种符合Web服务协议的功能。在本文中，我们将要标识一个结构良好的服务所具有的特征，并为系统架构师和设计者提供关于如何交付面向服务的应用程序的指导。

返回页首

原则和定义

环视业界，SOA作为术语或者缩略词正广泛地被使用，但这一术语在使用上还不很精确。例如， World Wide Web Consortium （W3C）将SOA定义为一套可以被调用的组件，用户可以发布并发现其接口描述。 在其它地方我们也可以看到相似的定义：从体系结构的技术实现来看，它是非常有技术远景的。这有些奇怪，因为体系结构这一术语一般地用于描述一种风格或一套实践—例如，设计和构造事物的风格，如乔治亚州的建筑物，新艺术主义装饰品，或Sir Edwin Lutyens 和Gertrude Jekyll 设计的花园。

CBDI认为面向服务的体系结构需要一种更加广泛的定义。为了得到这一定义，让我们先从一些现有的定义入手，并对W3C提供的定义与CBDI推荐的定义进行比较。 我们首先看一下基本服务概念的定义。

Service 服务

• 能执行一项任务的一个组件。一个WSDL服务：一个端点（end points）的集合（W3C）。

• 一种使用WSDL描述的功能（CBDI）。

一个服务定义

• 根据一个经过协商的合同（暗示或明确表示的），用户的需求被满足的一种方式，包括服务协议、提供的功能等等（CBDI）。

服务执行

• 一个功能运行的实例过程（CBDI）。

Web 服务

一个软件系统，设计为支持能通过网络互操作的机器对机器的交互，它有一个用机器能够处理的格式描述的接口（特别是WSDL）。 其它的体系可以使用SOAP消息按照Web 服务描述的方式与之交互，典型地是使用HTTP进行传输，并用XML序列化和其它Web相关的标准联接（W3C）。

• 一个功能的程序接口，符合WSnn协议（CBDI）。

服务规定服务的生命周期作为可再利用的概念。由这些定义看出,和CBDI相比，W3C采用了较狭义的方法来定义服务和相关的概念。CBDI并没有将所有的服务看作组件，也不完全认为服务将执行一项任务。 此外CBDI推荐将类型、定义和实现作为单独的内容。然而实际上在SOA的定义中，CBDI与W3C相互补充。

面向服务的体系结构 :

• 一套可以被调用的组件，可以发布和发现它们的接口描述（W3C）。

CBDI 基于两种考虑而拒绝这一定义：第一，组件（或实现）经常不是成套的；第二， W3C对体系结构的定义只考虑了那些被实现和部署的组件，而没有从建造体系结构的科学、技巧或实践来考虑。 Cbdi推荐的SOA的常用定义为：

策略、实践、框架,它们按与服务消费者相关的粒度将应用程序功能作为服务集提供给用户使用。可以调用、发布、和发现服务，并使用一种单一的基于标准的接口形式从具体的实现中抽象出来。 （CBDI）

CBDI将SOA定义为一种使用了特定的策略、实践和框架的结构，按照特定的规范来交付服务。典型的例子包括特定的粒度，独立于实现，符合标准。 这些定义强调了用web服务接口可以提供的服务形式。但是更高质量的要求，如可重用性和独立性于实现，只能够通过在设计和建造过程中使用一些技术来实现，这些增加的目标已经超出了使用web服务所支持的基本的交互性。

返回页首

SOA基础

很容易得出结论，转移到面向服务（ Service Orientation ）实际上是随着 web 服务开始的 — 大约三年多前。然而， Web 服务仅仅是漫长道路的开始一步。 服务的概念是组件思想不可分割的一部分，显然，分布式体系结构是早期的面向服务的体系结构的尝试。认清 web 服务是更广泛的 SOA 蓝图的一部分是很重要的。 Web 服务是符合 WSnn 协议的功能的编程接口。这样 Web 服务为我们提供了一定的体系结构的特点，尤其是平台独立性，松散耦合，自描述和服务发现功能。由于接口的形式化，它们可以支持服务提供者和消费者之间的形式化的分离。

服务是一个重要概念。 Web 服务是一套协议，通过这些协议可以按技术独立的标准形式来发布和发现服务。

虽然Web服务越来越多地用于SOA，但事实上Web服务并不是SOA的固有组件。SOA 在这一方面潜在性更加广泛，而不仅仅是定义服务实现、以及从提供者和消费者的角度来定位服务质量。CBD 和组件技术之间有相同之处，例如，从技术角度看，COM和包装了地址组件的UML组件，但是CBD或是基于组件的软件工程（CBSE）是规则，通过这些规则可以确保正在建造的组件能和业务保持一致。 但从那技术角度看，CBD，甚至基于组件的软件工程（CBSE）是保证建造的组件与业务相一致的规则。同样地，Web服务仅仅是实现而已。 SOA 是方法，而不仅仅是一个UML组件包装图的服务对等物。

CBDI最近的报告中阐明了许多SOA的这些特征，和两个DotCom公司发布的Web服务比较，他们使用Web服务替换通常的基于浏览器的访问，可以让用户将提供的功能组合到他们自己的应用程序。在一个例子，Web服务很明显地成为有意义的业务服务—如支持服务消费者逵价格、生成列表、或向购物车中增加物品。

相反,另一个组织的服务是相当不同的。它实现了一个通用目的的API，只是简单地通过Web服务来提供创建、读取、更新和删除（CRUD）数据库的访问。 虽然这一实现根本没有一点错误，但它要求用户理解基础的模型，并遵守业务规则，以保护数据的完整性。WSDL不描述业务或实体内容。 这是一个不使用SOA的Web服务的例子。

从技术的角度看，SOA不仅仅是一个服务体系结构，也包括策略、实践和框架，通过这些可以保证服务被正确提供和消费。

所以我们需要一个框架来理解什么构成了一个好的服务。正如我们在以前的例子中看到的，如果我们改变了使用水平，我们需要某种面向服务的原则（Principles of Service of Service Orientation ）来设置策略、测试基准等等。

这里，我们可以辨别两个明显的集合：

• 接口相关的原则—技术中性、标准化和可消费性。

• 设计原则—更多的涉及取得优质的服务，满足实际的业务需求，使得服务易于使用，内在的可适应性，以及易于管理。

有趣的是一些已经建立起成熟的组件体系结构的组织一定程度上也提到了第二个集合。然而根据经验，我们确定大多数组织已经发现这个级别的规则难以满足。 虽然在一些核心应用程序中为了广泛的共享和重用而创建了高品质的组件，但更一般的是按照短期的投资回收率，一直很难察觉到组件带来的投资费用。

然而将同样的原则用于服务时，需要更多地考虑需求，尤其对于那些不是为这一目的而设计的IT系统来说,业务和IT管理人员需要经历更加陡峭的学习曲线才能更好的理解IT系统的成本和收益。这里，我们必须清楚并不是所有的服务都需要这些特点：虽然当有多个消费者使用服务时这一点很重要（尤其是例如当需要SOA时的情况），需求规格说明要通用化，需要从实现中抽象出服务（如早期的dotcom案例研究），消费者应用程序的开发人员应该不必知道底层的模型和规则。 客户端应用程序的任务规格说明必须有精密的形式化的定义，也必须按照粒度的相关水平来提供服务，要具有灵活性，并易于装配到业务处理过程中。

表 1 显示了良好的服务设计的原则， Web 服务或者 SOA 都支持这些特点。

表 1 　 Web 服务和 SOA

Web 服务支持的	技术中心的	终端平台独立
-	标准化	基于标准的协议
-	可消费性	支持自动发现和使用
SOA 支持	可重用	服务的使用，并非通过复制代码/实现进行重复使用。
-	抽象的	将服务从实现中抽象出来
-	发布	精确的，发布服务接口的功能规格说明，并非实现
-	形式化	服务提供者和消费者的终端位置上任务的形式化合同。
-	相关的	按用户可识别的粒度提供的功能，并作为一个有意义的服务

如果遵守表1中概括的原则，我们会得到一些有趣的好处：

• 在业务和IT实现之间有真正的同步。多年来业务人员并不真正理解IT体系结构。 使用良好设计的服务，我们可以从根本上改善业务间的通信，不必进行对齐，也不必认真地考虑业务和IP过程的会聚。

• 一个结构良好的服务可以提供给我们业务使用相关的管理单元。将服务提供强制分离让我们可以理解一个服务的生命周期费用，以及它是如何在业务中使用的。

• 当将服务从实现中抽象出来时，其交付和合作模型可以有多种选择方案。在可预见的将来的任意时候，没有人会期待核心企业应用程序将会单纯地通过从多个来源装配服务得到。 然而可以完全现实地认为某些服务将会从外部来源中取得，因为这是更适当地获取它们的方法。如何，认证服务，第三方商品服务也是一个好例子，它可以交付一个高级服务，　这是由于其专业性，以及使用一个受信任的外部代理来改善认证的优点决定的。

返回页首

处理事务

如前所述，CBDI建议好的SOA是有关结构、策略、实践和框架的所有事物。这使得使处理事物成为一个实质的考虑因素。

虽然一些组织使用组件也能取得服务的优点，但只有相对很少的组织在处理中严格做到提供与消费分离。这一点在服务中很早地就实现了，因为其接口协议的形式化，但我们需要承认这种分离需要管理。 例如，可以很容易地分离服务和消费者的构建处理过程，但如果消费者处理由开发服务的同一团队开发，则可以容易地按照反映底层实现的方式来测试服务。

在 SOA 中，确保要为提供者和消费者至少实现两种不同的并且单独的处理过程，这一点很关键。

然而，目前用户对无缝端到端业务处理过程的需求，这是使用Web服务的一个关键驱动因素，意味着在提供者和消费者组织之间经常会有清晰的分离，具有潜在的多对多关系，虽然其中每一方参与者都有不同的目的，但都需要使用相同的服务。我们推荐开发组织使用这样的开发方式，即使当提供和消费的处理过程在一起时也这样做，可以确保他们在正确地设计可以容纳未来需求的服务。

对于消费者，必须组织处理过程，使得只有服务接口起作用，并且不依赖于服务实现的知识。如果能做到这一点，灵活性所带来的益处自然会增加，因为服务设计者不能对消费者行为做任何假设。 不论消费者如何使用服务，服务设计者必须在消费者可以使用服务的范围内提供形式化的说明和合同。消费者开发人员只需要知道服务在哪里，服务的功能，以及如何使用服务。 接口实际上是的唯一一件对消费者重要的事情，它定义了服务如何进行交互。

相似的,虽然提供者有非常不同的一套关注点，要求开发和交付的服务可以在完全分离的处理过程中使用服务消费者。提供者注意的焦点因此再一次落在接口上—即描述和合同。

另一种观点是考虑提供者和消费者之间合作的本质。乍一看　办法的看一看到这个将回想自然的那合作之间提供者和消费者。乍一看你可能会认为提供者和消费量所拥有的实现和规定之间有清晰的区别。 然而如果我们从合作的角度看待这些顶层的处理过程，我们将看到非常不同的情景。

我们拥有的是很多处理区域（依赖于服务的本质），提供者和消费者之间有深层的合作。潜在地，我们需要对软件交付处理进行重要的重建。 虽然在基于服务的处理过程中有两个主要的参与方，我们的结论是我们需要管理三个主要的处理区域。在经过分解后，我们认为以下是主要的顶层处理过程。

• 交付服务实现的处理过程。

  • 传统的开发

  • 编程

  • 使用工具使Web服务自动化的过程

• 服务的提供—将服务的生命周期作为一个可重用的产出品来看待。

  • 面向商业的

  • 内部及外部的视图

  • 服务级管理

• 消费处理过程。

  • 业务处理驱动

  • 服务的消费者可以是内部的也可是外部的

  • 解决方案从服务中装配，并非代码中

  • 越来越多图形化的,声明性的开发方法

  • 能被业务分析员或知识处理人员接受

采取这种观点的益处是，处理的协作方面都主要包括在服务提供的处理区域中。服务提供的处理区域非常重要，这是因为协议的本质对于处理需求具有非常重要的影响。 或许有两种主要的模式可用于设计消费者/提供者协作：

• 协商 — 消费者和提供者一起对服务达成协议　当开发新的服务时，消费者和提供者有机会对服务的内容以及如何工作达成协议。业界有很多参与方的业务会彼此相关，服务也为众多提供者所共同使用。业界需要标准化这些服务是必不可少的。 例子包括:

  • 早期的适配器

  • 新的服务

  • 密切的伙伴

  • 工业发起的标准

  • 内部使用

• 示例—这就是它，采取或者放弃。协作场景中的一方可能只是简单地规定需要使用的服务。 有时这种服务已经存在，用户仅需要选择是否使用它。 例子包括:

  • 支配方

  • 提供者优先——使用这项服务，否则我们不做业务

  • 消费者优先——提供这项服务，否则我们不做业务

  • 业界发起的——符合标准

  • 现有的系统/接口

返回页首

体系结构

我们考查的这个处理过程视图是考虑所需要的体系结构的类型和兴趣范围，责任和完整性这些问题的先决条件。对于SOA，在图1中显示了三种重要的体系结构观点。

• 应用程序体系结构。这是一种面向业务的解决方案，消费服务来自于一个或多个提供者，并将它们集成到业务处理过程中。

• 服务体系结构。这为实现和消费应用程序之间提供了一个桥梁，创建了服务集的一个逻辑视图，我们可以使用这些服务，通过通用的接口和管理体系结构来调用它们。

• 组件体系结构。它描述了支持实现的应用程序、业务对象和它们的实现的多种环境。

图 ⒈ 三种体系结构视图

从消费者或提供者的观点来看待这些体系结构。这种体系结构的关键在于服务的消费者不应该关心服务的实现细节，只关心服务提供的功能。 体系结构的实现可能会随不同的提供者而有所变化，但它们仍提供相同的服务。相似的，提供者也不应该关心使用服务的应用程序。 新的不可预见的应用程序也将会重用相同的服务。

消费者关注的是他们的应用程序的体系结构,使用的服务,而并非组件体系结构的细节。他们对具有共同利益的通用业务对象的特定级别的细节感兴趣，如提供者和消费者需要共享一个订单的共同视图。 但是消费者不需要知道订单组件和数据库的实现细节。

相似的,提供者关注的是组件体系结构，服务体系结构，而并非应用程序体系结构。此外，他们二者需要了解某些基础应用程序的信息，例如能设置任意的顺序规则、前置和后置条件。但提供者不会对消费应用程序的每一细节感兴趣。

返回页首

服务体系结构

SOA的核心是需要能够将服务作为一阶可交付对象来管理。这就是我们经常强调的，服务的关键在于提供者和消费者之间的通信。 0>因此我们需要的服务体系结构要保证服务不会退化为接口的状态，相反他们有自己的标识，可以单独或按集合来管理。

CBDI开发的业务服务总线Business Service Bus （BSB） 概念的正好满足这一要求。BSB 是一种某一特定业务领域的可用服务的逻辑视图，例如人力资源或后后勤管理。 它能帮助我们解答如下问题:

• 我们需要什么样的服务?

• 我们能使用哪些服务?

• 哪些服务能进同时操作? (共用的语意,业务规则)

• 有何种替代服务可以使用?

• 服务与服务版本间的相关性是什么？

不是让开发人员去发现单独的服务，并将其放入上下文中，相反， Business Service Bus 是开发人员的起点，指导他们按照领域中一套一致的规则来开发。

BSB的目的是能根据bus 级别，而不是为单独的服务来制定通用的规格说明、策略等。例如，一个bus 上的服务将完全遵循相同的语义标准，服从相同的安全策略，全部指向相同的领域全局模型。 它简化了一些通用的、低级的业务基础服务的实现，这些服务可以聚集到同一bus的其它高级业务服务中（例如，它们都可以使用相同的产品代码验证服务）。 每一业务领域都开发一个词汇表和一个代表处理过程和对象的业务模型。

服务体系结构的关键问题在于：“发布到业务服务Bus 中的服务范围是什么？”一个简单的回答是：“某种业务级别的抽象”。 然而这种回答太空泛，解释很多—最好是一些启发式的，以确保服务是最小公分母，能达到业务标准，面向消费者，达成协议的，对业务处理具有意义。关键的一点就是，有一个聚集和合作的过程，并且其发生应该独立于实现组件，如图2所示。通过分隔实现，可以取得一定水平的灵活性，可以调整已经提供的服务而不用修改底层组件。 原则上,需要用抽象级别来保证服务位于与消费者相关或相适于某一级别。这些级别可能是以下的一个或多个：

• 业务服务

• 面向消费者的服务

• 由提供者和消费者两者协商的服务

• 将低级的基于实现的服务组合某些对业务有意义的事物中

• 粗粒度的

• 适用于外部使用的

• 兼容以前的连接设计

图 ⒉ 抽象的级别

返回页首

SOA平台

实现分离的关键在于定义一个虚拟平台，它等价于许多相关的真实平台。虚拟平台的目标是尽可能完整的分离服务和实现，允许建造在各种实现平台之上的组件提供不依赖于实现的服务。

虚拟的SOA平台由一个包含开发和实现平台的计划蓝图组成。这一蓝图为应用程序的开发和实现提供指导，确保发布的服务能遵循相同的构建原则，这些原则与服务的管理和消费者视图相关。

当许多不同的应用程序能共享相同的结构，结构的各部分具有相同的关系时，我们就会具有一种称之公共体系结构的结构。这种结构可能会以多种方式实现：它或许是一个公共的技术环境，一套策略、框架或者是实践。 一个虚拟平台的示例平台组件包括：

• 主机环境

• 消费者环境

• 中间件

• 集成和装配环境

• 开发环境

• 资产管理

• 发布&发现

• Service 服务级别管理

• 安全性基础结构

• 监视&度量

• 诊断&错误处理

• 消费者/预订者管理

• Web服务协议

• 身份管理

• 认证

• 部署&版本化管理

返回页首

企业SOA

对于SOA来说，最适宜的实现体系结构是基于组件的体系结构。很多人都熟悉处理和实体组件的概念，也了解组件体系结构的固有的稳定性和灵活性，它在业务实体和组件实现之间提供了一个一对一的映射。 企业SOA(ESOA)同时带来了两个主线程—Web 服务和CBD （或者CBSE）。结果是，一个企业SOA既可应用于外部可用的Web 服务，也可以应用于专为内部使用而建造或指定的核心业务组件服务。 更深入地探讨ESOA已超出了本文的范围。有关企业SOA更多的主题有一份5部分的报告“CBDI Report Series”。

返回页首

摘要

SOA的目标是实现世界范围内的协作服务网络，可以在Service Bus发布和调用这些服务。采用SOA是实现业务灵活性和Web服务承诺的IT灵活性的本质要求。 这些优点不仅只是从技术角度和采用Web服务协议才会体现出来，它们也需要创建面向服务的环境，这一环境要基于本文提到的以下关键原则：

• 服务是一个重要的概念。Web服务是一套协议，可以通过这些协议按照技术中性的标准形式来发布、发现和使用服务。

• 从技术的角度看，SOA不仅仅是一个服务体系结构，也包括策略、实践和框架，通过这些可以保证服务被正确提供和消费。

• 在SOA中，确保要为提供者和消费者至少实现两种不同的并且分离的处理过程，这一点很关键。

• 不是让开发人员去发现单独的服务，并将其放入上下文中，相反，Business Service Bus 是开发人员的起点，指导他们按照领域中聚合的一套规则来开发。

此外，CBDII除了提供有关移植到Web服务和SOA所需要的规划和管理，它们也提供了Web Services Roadmap ，一套可以在 http://roadmap.cbdiforum.com/　免费使用的资源