3.1　面向服务简介

在我们的日常生活中，服务随处可见且就像已存在的文明历史一样源远流长。所有执行特定任务以支持他人的动作都属于提供一项服务。任意团体共同执行一项任务以支持一项更重大的任务也是交付一项服务的演绎（见图3-1）。

同样，执行与其目的或业务相关联任务的组织也在提供服务。只要所提供的任务或功能定义合理并且可以与其他相关联的任务相对隔离，则可以被明确地归类为服务（见图3-2）。

有些基线要求单个的服务提供商组成团体、共同协作以便提供更大的服务。例如，图3-2显示了一组员工，每个组员都为ABC交付提供服务。即使每个个体都提供一个特定服务，而为了企业的有效运作，其工作人员也需要具备基本的、共同的特点，如可用性、可靠性和使用相同语言沟通的能力。具备了这些因素，这些个体就能够组成一个富有成效的工作团队。建立此类贯穿业务自动化解决方案基线的需求是面向服务的关键目标。

3.1.1　业务自动化中的服务

一般来说，服务是一款软件程序，其通过发布API（服务契约的一部分）实现其功能的可用性。图3-3显示了用于描述服务的符号（不提供有关其服务契约的任何详情）。

不同的实现技术可以用于编程和构建服务。本书涵盖的两个常见的实现介质是基于SOAP的Web服务（或仅Web服务）和RESTful服务（或仅REST服务）。图3-4显示了本书中用于表示服务契约的标准符号。

注意

Web服务契约通常由WSDL定义和一个或多个XML Schema定义组成。作为REST服务实现的服务通过统一契约访问，例如由HTTP和Web媒介类型提供的协议。第8章和第9章讲述了有关Web服务和REST服务契约的相关示例。

服务契约可以进一步由人类可读文档组合而成，例如描述附加服务质量保证、行为和限制的服务水平协议（SLA）。一些SLA相关的需求也可以用机读格式表示。

3.1.2　服务是能力的集合

在讨论服务时，重要的是要记住单个服务可以提供一个提供能力集合的API。它们因为该服务的上下文功能关系而被组合在一起。例如，图3-5中所示服务的上下文功能是“货运”。该特定服务提供与货运处理相关联的能力集。

因此，服务本质上是相关能力的容器。它由一组旨在执行这些功能的逻辑体和表明其功能可用于公共调用的服务契约组成。当介绍本书中的服务功能时，我们会特别关注被定义为服务契约API部分的那些服务功能。

服务消费者是当软件程序访问和调用服务时的运行时角色，或者更具体地说，当它向服务契约中表示的服务能力发送消息时由软件程序采用的运行时角色。在接收到请求时，服务开始执行调用能力所包含的逻辑，执行后可能会向服务消费者返回相应的响应消息也可能不会返回。服务消费者可以是能够通过其API调用服务的任何软件程序。一个服务本身也可能扮演另一个服务的消费者。

不可知逻辑和非不可知逻辑

术语“不可知”源于希腊语，意思是“没有认知”。

因此，足够通用、不针对（不具备该知识）特定父任务的逻辑被归类为不可知逻辑。因为针对单一目的任务的知识被故意省略，所以不可知逻辑被认为是多用途的。相反，针对（包含该知识）单一目的任务的逻辑被标记为非不可知逻辑。

另一种概念化不可知和非不可知逻辑的方法侧重点在逻辑可以重用的程度。由于不可知逻辑具备多种用途，我们期望它在不同的上下文中可以重用，以便作为单个软件程序（或服务）的逻辑可以有助于自动处理多个业务过程。非不可知逻辑不受这些预期类型的约束。它被专门设计为单一用途软件程序（或服务），因此具有不同的特性和需求。非不可知逻辑仍然可以重用，但只在其父业务流程的作用域内，该作用域保持了针对更大的、单一目的任务的上下文。

3.1.3　面向服务是一种设计范式

设计范式是设计解决方案逻辑的一种方法。在构建分布式解决方案逻辑时，设计方法通过一种称为“关注点分离”的软件工程理论而实现。简而言之，这个理论说明，将更大的问题分解成一组较小的问题或关注点时，这个问题就能得到更有效地解决。这让我们产生了将解决方案逻辑划分为多个功能的想法，每个功能都旨在解决单一的关注点。相关功能可以分组为解决方案逻辑单元。

分布式解决方案逻辑存在不同的设计范式。面向服务体现在：面向服务执行关注点分离的方式以及它如何塑造具有特定特性和支持特定目标状态解决方案逻辑的单个单元。

从根本上说，面向服务将合适的解决方案逻辑单元整合为企业资源，其可以被设计为解决即时问题，同时对更大的问题保持不可知。这就为我们提供了不断的机会来重新利用那些单元内的功能并解决其他问题。

将面向服务应用到有一定意义的程度，即能够产出可以安全归类为“面向服务”的解决方案逻辑和能够作为“服务”的单元。（第5章详细探讨了如何以面向服务分离关注点。）

服务，作为面向服务解决方案的一部分，以具有明显设计特征的独立物理软件程序而存在。每个服务均分配了代表自己典型功能的上下文，并且由与该上下文相关的一组能力组成。服务组合是服务的协同聚合。如3.3节中所述，服务组合（见图3-6）与传统应用程序相比，其功能范围通常与父业务流程的自动化相关联。

服务目录是描述企业内或企业内有意义部分边界中，相互依赖的服务的独立标准化和管理化的集合。图3-7创建了本书中用于表示服务目录的标准符号。

IT企业可以包含或甚至可以由单个服务目录组成。或者，企业环境也可以包含多个服务目录。当组织有多个服务目录时，此术语进一步定位为域服务目录。

在面向服务应用中，服务目录对于建立本地服务间的高度互操作性是至关重要的。这支撑着有效服务组合的重复创建（见图3-8）。

以下是对迄今为止阐述的面向服务元素的简要回顾：

·面向服务的解决方案逻辑通过服务和根据面向服务设计的服务组合来实现。

·服务组合由一系列组装起来以提供特定业务自动化任务或流程所需功能的服务组成。

·因为面向服务将许多服务形成企业资源，所以一个服务也许会被多个消费者程序调用，每个消费者程序可以涉及不同服务组合中的相同服务。

·标准化服务集合能够形成在自己的物理部署环境内独立管理的服务目录的基础。

·通过从服务目录中的现有不可知服务池中创建服务组合可以使多个业务流程实现自动化。

正如在第4章中将探讨的，面向服务架构是一种为支持服务、服务组合和服务目录而进行了优化的技术架构形式。

3.1.4　面向服务的设计原则

前面几节在非常高的层次上描述了面向服务范式。但这个范式如何应用呢？它主要应用于服务级别（见图3-9），通过使用以下8个设计原则：

· 标准化服务契约 ——同一服务目录中的服务符合相同的契约设计标准。

服务通过服务契约表达其目的和能力。这可能是最基本的原则，因为它基本上规定了以标准化方式分割和发布面向服务解决方案逻辑的需要。它还特别强调服务契约设计，以确保服务表现功能方式和定义数据类型方式保持相对一致。

· 服务松耦合 ——服务契约降低消费者耦合需求，并且它们自身与它所在的周围环境解耦。

耦合指的是两个事物之间依赖性的度量。这个原则在服务边界内部和外部建立特定的关系类型，并且持续强调削弱（“松散化”）服务契约、实现服务契约和服务消费者之间的依赖性。服务松耦合促进服务逻辑的独立设计和演进，同时保证基本的互操作性。

· 服务抽象 ——服务契约只包含基本信息，以及那些仅限于服务契约中发布的信息。

抽象涉及面向服务的许多方面。从根本上讲，这一原则强调需要尽可能多地隐藏服务的内部细节。这样做直接实现了前述的松耦合关系。服务抽象在服务组合的定位和设计中也起着重要作用。

· 服务可重用性 ——服务包含并显示不可知的逻辑，可以定位为可重用的企业资源。

每当构建一个服务时，我们会寻找方法使其潜在能力得到最佳发挥而非仅仅针对一个目的。面向服务极大地强调了重用，因此它成为设计过程的核心部分，并且也是关键服务模型的基础（参见第5章）。

· 服务自治 ——服务对其内部的运行时执行环境进行高度的把控。

为了使服务能够持续可靠地发挥其功能，其内部的解决方案逻辑需要对其环境和资源进行最大程度的把控。服务自治能够支持在现实生产环境中有效地实现其他设计原则。

· 服务无状态 ——服务通过必要时推迟状态信息的管理来最小化资源消耗。

过度的状态信息管理可能会损害服务的可用性以及其行为的可预测性。因此，服务被理想化地设计为仅在需要时维持状态。与服务自治一样，这是另一个更少关注契约、更多地关注内部逻辑的设计的原则。

· 服务可发现性 ——服务补充了交互元数据，通过它们可以有效地发现和诠释服务。

对于定位为具有可重复投资回报率（ROI）的IT资产的服务，当需要重用时，我们需要很容易地识别和理解这些服务。因此，服务设计需要考虑服务契约和能力的“通信质量”，而不管诸如服务注册表的发现机制是否是环境的直接部分。

· 服务可组合性 ——服务是有效的组合参与者，无须考虑组合物的大小和复杂性。

随着面向服务解决方案复杂性的增加，潜在服务组合配置的复杂性也随之增长。有效组合服务的能力是实现面向服务计算的一些基本目标的关键要求。复杂的服务组合对服务设计提出了要求。服务有望作为有效的组合成员参与，无论它们是否需要立即加入组合。

SOA模式

面向服务原则与SOA模式密切相关。请注意附录C中每个模式配置文件表如何包含专用于显示相关设计原则的字段。 Hydvd2BoZHtDCsiUMw0BXmiDJTmpSXK63VsDigFgxRls4KOeSpKRAtyEN4Yna2Ou