面向服务的体系结构概述

摘自 IBM 红皮书《Patterns: Service-Oriented Architecture and Web Services》(sg246303)第 2 章第 1 节

级别: 初级

Min Luo, Mark Endrei, Philippe Comte,Pal Krogdahl, Jenny Ang, Tony Newling
International Technical Support Organization, Raleigh Center
2004 年 6 月

    在这一节中，我们简要地描述了面向服务的体系结构的发展。然后，我们探究了面向组件的开发与面向服务的体系结构之间的关系，并且说明了如何将组件作为实现服务的基础设施。

第一部分：新方法的商业驱动力
虽然 IT 经理一直面临着削减成本和最大限度地利用现有技术的难题，但是与此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。

在所有这些压力之下，有两个基本的主题：异构和改变。现在，大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自多个厂商跨不同平台的产品简直就像一场噩梦。但是我们也不能单单使用一家厂商的产品，因为改变应用程序套件和支持基础设施是如此之难。

在当今 IT 经理面临的问题之中，改变是第二个主题。全球化和电子商务加快了改变的步伐。全球化带来了激烈的竞争，产品周期缩短了，每个公司都想赢得超过竞争对手的优势。在竞争产品和可以从 Internet 上获得的大量产品信息的推动下，客户要求更快速地进行改变。因而，在改进产品和服务方面展开的竞争进一步加剧了。

为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。企业必须快速地适应这种改变，否则就难以生存，更别提在这个动荡不安竞争激烈的环境中取得成功了，而 IT 基础设施必须支持企业提高适应能力。

因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态系统业务范例发展。重点是扩展供应链，支持客户和合作伙伴访问业务服务。第 19 页的图 2-1 展示了企业的这种发展。

图 2-1 企业的发展
图 2-1 企业的发展

我如何使我的 IT 环境更灵活且更快地响应不断改变的业务需求呢？ 我们如何使这些异构系统和应用程序尽可能无缝地进行通信呢？我们如何达到企业目标而不使企业走向破产的深渊呢？

IT 响应者/支持者是随着企业的这种发展而并行发展的，如图 2-2 所示。现在，许多 IT 经理和专业人员都同样相信，我们真的快找到了一种满意的答案——面向服务的体系结构。

图 2-2 体系结构的发展

图 2-2 体系结构的发展
Figure 2-2 The evolution of architecture

为了减少异构性、互操作性和不断改变的要求的问题，这样的体系结构应该提供平台来构建具有下列特征的应用程序服务：

    * 松散耦合
    * 位置透明
    * 协议独立

基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特定服务，因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能多的技术。特别地，来自不同实现技术（如 J2EE 或 .NET）的技术规范不应该影响 SOA 用户。如果已经存在一个服务实现，我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具有更好的服务质量。

第二部分：作为解决方案的面向服务体系结构
自从“软件危机”促进软件工程的开创以来，IT 界一直在努力寻求解决上述问题的方案。在过去几年里，下面简要概述的核心技术进展使我们走到了今天。我们将简要讨论这些核心技术，而我们重点关注的将是这些技术如何帮助解决 IT 问题。

面向对象的分析和设计
在“Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design”中，Larman 将面向对象的分析和设计的本质描述为“从对象（物体、概念或实体）的角度考虑问题域和逻辑解决方案”。在“Object-Oriented SoftwareEngineering: A Use Case Driven Approach”中，Jacobson 等将这些对象定义为“特点在于具有许多操作和状态（记忆这些操作的影响）的物体”。

在面向对象的分析中，这样的对象是用问题域来标识和描述的，而在面向对象的设计中，它们转变成逻辑软件对象，这些对象最终将用面向对象的编程语言进行实现。

通过面向对象的分析和设计，可以封装对象（或对象组）的某些方面，以简化复杂业务场景的分析。为了降低复杂性，也可以抽象对象的某些特征，这样就可以只捕获重要或本质的方面。

基于组件的设计并不是一种新技术。它是从对象范例中自然发展而来的。在面向对象的分析和设计的早期，细粒度的对象被标榜为提供“重用”的机制，但是这样的对象的粒度级别太低了，没有适当的标准可以用来使重用广泛应用于实践之中。在应用程序开发和系统集成中，粗粒度组件越来越成为重用的目标。这些粗粒度对象通过内聚一些更细粒度的对象来提供定义良好的功能。通过这种方式，还可以将打包的解决方案套件封装成这样的“组件”。

一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系结构，就可以将支持企业的应用程序划分成一组粒度越来越大的组件。可以将组件看作是打包、管理和公开服务的机制。它们可以共同使用一组技术：实现企业级用况的大粒度企业组件可以通过更新的面向对象的软件开发与遗留系统相结合来实现

面向服务的设计
在“Component-Based Development for Enterprise Systems”中，Allen 涉及了服务的概念，“它是将组件描述成提供相关服务的物理黑盒封装的可执行代码单元。它的服务只能通过一致的已发布接口（它包括交互标准）进行访问。组件必须能够连接到其他组件（通过通信接口）以构成一个更大的组”。服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。第 22 页的图 2-3 展示了重要的面向服务术语：

    * 服务：逻辑实体，由一个或多个已发布接口定义的契约。
    * 服务提供者：实现服务规范软件实体。
    * 服务使用者（或请求者）：调用服务提供者的软件实体。传统上，它称为“客户端”。服务使用者可以是终端用户应用程序或另一个服务。
    * 服务定位器：一种特殊类型的服务提供者，它作为一个注册中心，允许查找服务提供者接口和服务位置。
    * 服务代理：一种特殊类型的服务提供者，它可以将服务请求传送到一个或多个其他的服务提供者。

图 2-3 面向服务的术语

图 2-3 面向服务的术语

基于接口的设计
在组件和服务开发中，都需要进行接口设计，这样软件实体就可以实现和公开其定义的关键部分。因此，在基于组件和面向服务的系统中，“接口”的概念对于成功的设计非常关键。下面是一些与接口有关的重要定义：

    * 接口：定义一组公共方法签名，它按照逻辑分组但是没有提供实现。接口定义服务的请求者和提供者之间的契约。接口的任何实现都必须提供所有的方法。
    * 已发布接口：一种可唯一识别和可访问的接口，客户端可以通过注册中心来发现它。
    * 公共接口：一种可访问的接口，可供客户端使用，但是它没有发布，因而需要关于客户端部分的静态知识。
    * 双接口：通常是成对开发的接口，这样，一个接口就依赖于另一个接口；例如，客户端必须实现一个接口来调用请求者，因为该客户端接口提供了某些回调机制。

第 23 页的图 2-4 定义了客户关系管理 (CRM) 服务的 UML 定义，它表示为一个 UML 组件，实现接口 AccountManagement、ContactManagement 和 SystemsManagement。在这些接口中只有头两个接口是已发布接口，不过，后者是公共接口。注意，SystemsManagement 接口和 ManagementService 接口构成了双接口。CRMservice 可以实现许多这样的接口，但是它以多种方式行为的能力取决于客户端在行为的实现方面是否允许有大的灵活性。甚至有可能给特定类型的客户端提供不同或附加的服务。在一些运行时环境中，这样的功能也用于在单个组件或服务上支持相同接口的不同版本。

图 2-4 已实现的服务

图 2-4 已实现的服务

分层应用程序体系结构
如前所述，面向对象的技术和语言是实现组件的极好方式。虽然组件是实现服务的最好方法，但是您必须理解的一点是，好的基于组件的应用程序未必就构成好的面向服务的应用程序。一旦理解了服务在应用程序体系结构中所起的作用，组件开发人员就很有可能会利用现有的组件。进行这种转变的关键是认识到面向服务的方法意味着附加的应用程序体系结构层。第 24 页中的图 2-5 演示了如何将技术层应用于程序体系结构以提供粒度更粗的实现（它更靠近应用程序的使用者）。为称呼系统的这一部分而创造的术语是“应用程序边界”，它反映了服务是公开系统的外部视图的极好方法的事实（通过内部重用并结合使用传统组件设计）。

图 2-5 应用程序实现层：服务、组件、对象

图 2-5 应用程序实现层：服务、组件、对象

第三部分：近距离审视面向服务的体系结构
面向服务的体系结构提供了一种方法，通过这种方法，可以构建分布式系统来将应用程序功能作为服务提供给终端用户应用程序或其他服务。其组成元素可以分成功能元素和服务质量元素。第 25 页的图 2-6 展示了体系结构堆栈以及在一个面向服务的体系结构可能观察到的元素。

注意：面向服务的体系结构堆栈可能是一个容易引起争议的问题，因为各方面的支持者已经提出了几种不同的堆栈。我们的堆栈不是作为服务堆栈提出的。我们之所以在此提出它，是因为我们想要搭建一个有用的框架，在本书的剩余章节中，我们将通过这个框架来组织对 SOA 的讨论。

图 2-6 面向服务的体系结构的元素

图 2-6 面向服务的体系结构的元素

体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面，而右边的一半集中于体系结构的服务质量方面。这些元素详细描述如下：

功能性方面包括：

    * 传输是一种机制，用于将来自服务使用者的服务请求传送给服务提供者，并且将来自服务提供者的响应传送给服务使用者。
    * 服务通信协议是一种经过协商的机制，通过这种机制，服务提供者和服务使用者可以就将要请求的内容和将要返回的内容进行沟通。
    * 服务描述是一种经过协商的模式，用于描述服务是什么、应该如何调用服务以及成功地调用服务需要什么数据。
    * 服务描述实际可供使用的服务。
    * 业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用，以满足业务要求。注意，可以将业务流程本身看作是服务，这样就产生了业务流程可以由不同粒度的服务组成的观念。
    * 服务注册中心是一个服务和数据描述的存储库，服务提供者可以通过服务注册中心发布它们的服务，而服务使用者可以通过服务注册中心发现或查找可用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。

服务质量方面包括：

    * 策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我们在功能和服务质量两个区中都有策略功能。
    * 安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权和访问控制。
    * 传输是属性集，可以应用于一组服务，以提供一致的结果。例如，如果要使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个完成。
    * 管理是属性集，可以应用于管理提供的服务或使用的服务。

SOA 协作
图 2-7 展示了面向服务的体系结构中的协作。这些协作遵循“查找、绑定和调用”范例，其中，服务使用者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹配的服务。如果服务存在，注册中心就给使用者提供接口契约和服务的端点地址。下图展示了面向服务的体系结构中协作支持“查找、绑定和调用”范例的实体。

图 2-7 面向服务的体系结构中的协作
Figure 2-7 Collaborations in a service-oriented architecture

面向服务的体系结构中的角色包括：

    * 服务使用者：服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。
    * 服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。
    * 服务注册中心：服务注册中心是服务发现的支持者。它包含一个可用服务的存储库，并允许感兴趣的服务使用者查找服务提供者接口。

面向服务的体系结构中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的某一种（或多种）。面向服务的体系结构中的操作包括：

    * 发布：为了使服务可访问，需要发布服务描述以使服务使用者可以发现和调用它。
    * 发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。
    * 绑定和调用：在检索完服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。

面向服务的体系结构中的构件包括：

    * 服务：可以通过已发布接口使用服务，并且允许服务使用者调用服务。
    * 服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和/或服务质量 (QoS) 级别。

除了动态服务发现和服务接口契约的定义之外，面向服务的体系结构还具有以下特征：

    * 服务是自包含和模块化的。
    * 服务支持互操作性。
    * 服务是松散耦合的。
    * 服务是位置透明的。
    * 服务是由组件组成的组合模块。

这些特征也是满足电子商务按需操作环境的要求的主要特征，如第 301 页“e-business on demand and Service-oriented architecture”所定义的。

最后，我们需要说明的是，面向服务的体系结构并不是一个新的概念。如图 2-8 所示，面向服务的体系结构所涉及的技术至少包括 CORBA、DCOM 和 J2EE。面向服务的体系结构的早期采用者还曾成功地基于消息传递系统（如 IBM WebSphere MQ）创建过他们自己的面向服务企业体系结构。最近，SOA 的活动舞台已经扩展到包括 World Wide Web (WWW) 和 Web 服务。

图 2-8 面向服务的体系结构的不同实现

图 2-8 面向服务的体系结构的不同实现

SOA 范围中的服务
在面向服务的体系结构中，映射到业务功能的服务是在业务流程分析的过程中确定的。服务可以是细粒度的，也可以是粗粒度的，这取决于业务流程。每个服务都有定义良好的接口，通过该接口就可以发现、发布和调用服务。企业可以选择将自己的服务向外发布到业务合作伙伴，也可以选择在组织内部发布服务。服务还可以由其他服务组合而成。

服务与组件
服务是粗粒度的处理单元，它使用和产生由值传送的对象集。它与编程语言术语中的对象不同。相反，它可能更接近于业务事务（如 CICS 或 IMS 事务）的概念而不是远程 CORBA 对象的概念。

服务是由一些组件组成的，这些组件一起工作，共同提供服务所请求的业务功能。因此，相比之下，组件比服务的粒度更细。另外，虽然服务映射到业务功能，但是组件通常映射到业务实体和操作它们的业务规则。作为一个示例，让我们看一看 WS-I 供应链管理（WS-I Supply Chain Management）样本的定购单（PurchaseOrder）组件模型，如图 2-9 所示。

图 2-9 定购单组件模型

图 2-9 定购单组件模型

在基于组件的设计中，可以创建组件来严格匹配业务实体（如顾客（Customer）、定购单（Purchase Order）、定购项（Order Item）），并且封装匹配这些实体所期望的行为的行为。

例如，定购单（Purchase Order）组件提供获取关于已定购的产品列表和定购的总额的信息的功能；定购项（Order Item）组件提供获取关于已定购的产品的数量和价格的信息的功能。每个组件的实现都封装在接口的后面。因此，定购单（Purchase Order）组件的用户不知道定购单（Purchase Order）表的模式、计算税金的算法、以及定单总额中的回扣和/或折扣。

在面向服务的设计中，不能基于业务实体设计服务。相反，每个服务都是管理一组业务实体中的操作的完整单元。例如，顾客服务将响应来自任何其他系统或需要访问顾客信息的服务的请求。顾客服务可以处理更新顾客信息的请求；添加、更新、删除投资组合；以及查询顾客的定单历史。顾客服务拥有所有与它管理的顾客有关的数据，并且能够代表调用方进行其他服务查询，以提供统一的顾客服务视图。这意味着服务是一个管理器对象，它创建和管理它的一组组件。

第四部分：面向服务的体系结构所带来的好处
如前所述，企业正在处理两个问题：迅速地改变的能力和降低成本的要求。为了保持竞争力，企业必须快速地适应内部因素（如兼并和重组）或外部因素（如竞争能力和顾客要求）。需要经济而灵活的 IT 基础设施来支持企业。

我们可以认识到，采用面向服务的体系结构将给我们带来几方面的好处，有助于我们在今天这个动荡的商业环境中取得成功：

利用现有的资产。
SOA 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在 IT 方面的投资，方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值，而不必重新从头开始构建。

更易于集成和管理复杂性。
在面向服务的体系结构中，集成点是规范而不是实现。这提供了实现透明性，并将基础设施和实现发生的改变所带来的影响降到最低限度。通过提供针对基于完全不同的系统构建的现有资源和资产的服务规范，集成变得更加易于管理，因为复杂性是隔离的。当更多的企业一起协作提供价值链时，这会变得更加重要。

更快的响应和上市速度。
从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的组织提供了独特的优势。通过利用现有的组件和服务，可以减少完成软件开发生命周期（包括收集需求、进行设计、开发和测试）所需的时间。这使得可以快速地开发新的业务服务，并允许组织迅速地对改变做出响应和减少上市准备时间。

减少成本和增加重用。
通过以松散耦合的方式公开的业务服务，企业可以根据业务要求更轻松地使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增加。

说到做到
通过 SOA，企业可以未雨绸缪，为未来做好充分的准备。SOA 业务流程是由一系列业务服务组成的，可以更轻松地创建、修改和管理它来满足不同时期的需要。

SOA 提供了灵活性和响应能力，这对于企业的生存和发展来说是至关重要的。但是面向服务的体系结构决不是灵丹妙药，而迁移到 SOA 也并非一件可以轻而易举就完成的事情。请别指望一个晚上就将整个企业系统迁移到面向服务的体系结构，我们推荐的方法是，在业务要求出现或露出苗头时迁移企业功能的适当部分。