第三部分：近距离审视面向服务的体系结构

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

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

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

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

功能性方面包括：

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

服务质量方面包括：

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

SOA 协作

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

图 2-7 面向服务的体系结构中的协作

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

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

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

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

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

• 服务：可以通过已发布接口使用服务，并且允许服务使用者调用服务。
• 服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和/或服务质量 (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 面向服务的体系结构的不同实现

SOA 范围中的服务

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

服务与组件

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

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

图 2-9 定购单组件模型

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

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

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