应用程序结构：概念视图-2服务

 

本页内容

	服务模型
	服务设计概念
	服务是投资
	服务小结

服务是现代企业应用程序体系结构的构造块。

软件服务是应用程序逻辑的离散单元，它们提供了基于消息的、适合通过网络访问的接口。 基于服务的体系结构允许使用非常灵活的部署策略；服务模型允许应用程序利用网络上的计算资源，而不要求所有的数据和逻辑都驻留在单独的计算机上。此方法支持许多方案；以下是几个示例：

•	在多个客户端系统之间共享状态。许多客户端应用程序通过服务远程访问数据，从而与共享的上下文协作。 此方案对于组织内和跨组织边界均很有用。
•	将应用程序扩展到单独的系统以外。服务可使群集和网格计算的概念支持非常复杂的应用程序，或者可使在单独的计算机上操作非常大的数据集。
•	简化应用程序逻辑的部署。逻辑只需在需要时远程进行访问，而无需在可能需要它的所有计算机上进行安装。
•	优化专用系统上的处理。数据存储和视频呈现是由硬件提供的可能最佳的应用程序逻辑的示例，这些硬件是针对这些特殊的目的而设计或调整的。

上面的方案使软件设计朝着建模并以服务形式提供逻辑的趋势发展。即使本地运行软件也可以被设计为服务，这样，它们就可以根据需要或者在系统要求随着时间的推移而改变时，分发到不同的配置上。

随着网络变得更快、更便宜和更可靠，服务体系结构已经发生了演变。目前，从服务抽象中派生出三个主要模式：

•	远程过程调用(RPC) 基础体系结构使用基于消息的服务来模拟本地方法调用。
•	分布式对象系统（类似于 RPC）使用消息来模拟本地对象操作（包括方法调用和数据成员访问）。
•	以文档为中心的服务使用消息来执行由协议限制的会话，通常以独立于平台的文本形式传递命令和数据。 Internet 的基础体系结构依赖这些服务实现互操作性；这些服务包括域名系统 (DNS)、使用简单邮件传输协议 (SMTP) 实现的邮件系统、使用超文本传输协议 (HTTP) 实现的应用程序以及可扩展标记语言 (XML) Web 服务。

尽管所有这些模式都将继续在应用程序体系结构中起重要作用，但是 XML Web 服务尤其提供了几个关键的优点。 XML Web 服务提供独立于平台的方法，用来公开和使用应用程序逻辑，产生更好的互操作性、功能要求和操作要求的分离以及对软件单元的单独管理。通过特意强调服务的线格式（以 XML 形式表示操作状态），XML Web 服务避免了对平台的依赖性，从而不再限制其他分布式体系结构的互操作性。

本文描述了一个依赖可互操作的服务来提供高价值的业务逻辑和状态管理的应用程序体系结构。如果不考虑所使用的具体技术，应假定本文中的服务概念包括下列特性：

•	独立于平台。为了允许跨不同的系统进行集成，服务必须使用独立于平台的数据表示方法，并支持以独立于平台的方法来访问应用程序逻辑。 例如，XML 架构规范就是用于数据表示的独立于平台型系统的示例。 完全按照服务所收发的消息定义服务，而不是将服务建模为一组功能调用，有助于实现应用程序逻辑访问的独立于平台的特性。
•	基于标准。 服务依赖标准来获得互操作性。线协议、消息架构和安全凭据的表示形式是所必需的标准的几个示例。
•	将服务文档与元数据的处理分开。成功的服务提供依赖丰富而又可靠的基础体系结构来提供各种功能，如可靠的消息传送、安全管理、日志记录和审核。 这样的基础体系结构依赖对有关所请求操作的元数据（如路由信息和响应的可缓存性）的访问。这些信息必须基于标准，并从消息正文中携带的特定于应用程序的状态中提取。 简单对象访问协议 (SOAP) 是通过将元数据放到头元素中并将应用程序数据放到正文元素中来实现上述目的。

基于这些原则构建服务可允许服务在其他类似服务的动态网络中进行相互操作。 图 1 基于对数据或/和元数据的共识来阐释不同服务之间的消息路由。

图 1. 服务和消息

服务模型

通常，服务既提供业务逻辑，也提供与要解决的问题相关的状态管理。在设计服务时，目标是有效地封装与现实世界中的过程相关的逻辑和数据，对要包括在内的内容和要作为独立服务实现的内容作出明智的选择。

因为服务在设计上是通过网络调用的，所以它们应当总是粗粒度的。 即，服务应当封装应用程序逻辑的实质部分，并提供因网络请求滞后而带来的损失价值。 同样，服务应当呈现粗粒度的接口： 服务应当呈现更少的接口，以允许单个请求执行整个查询或更新，而不是呈现许多接口并让每个接口都操作较少的状态。

因此，服务和传统组件之间的主要区别在于调用语义。 尽管对象通常是在调用时实例化并且具有粒度相对较细的方法，但是服务通常长期运行并操作较大的消息。 值得注意的是，服务调用并不意味着为了处理消息而实例化对象，比较合理和常见的是以令牌形式处理消息，或者在进行整个处理之前处理消息的特定部分（如安全凭据）。

服务一定要对其所管理的状态严加保护，谨慎地授予读取和写入访问权限，并针对完整性规则验证更新。 服务是其所管理状态的“要塞”，并且在有关如何操作该状态方面是绝对的权威。 也可以说服务对外部访问者保持“健康不信任”的态度。

状态操作由业务规则来管理。业务规则是与状态相关的相对稳定的算法（如从商品清单汇总出发票的方法），一般是作为应用程序逻辑来实现的。

服务由策略来管理。与业务规则相比，策略的稳定性较差，并且可能是区域性的或针对特定客户的。 例如，某些享受优惠的客户可能获得对商品和服务的折扣。 一个非常不同的示例就是要求使用 SSL 来访问服务的策略。 策略通常是在运行时由查询表驱动（尽管需要应用程序逻辑查找和应用策略）。

因此，服务的更完整的定义可以是：“服务是能在网络上运行的软件单元，它通过消息来实现逻辑、管理状态和通信，并且由策略来管理。”

此定义中包含的每个概念都会在本文档集的后面深入探索。 消息处理详细说明了消息和消息处理；策略讨论策略；状态探索由服务管理的几种状态类型；处理查看基于服务的结构中的分布式过程管理。

本主题的其余部分介绍与服务设计和追求基于服务的结构所带来的技术好处相关的高级概念。

返回页首

服务设计概念

服务是非常复杂的。 完善的服务设计要求软件架构师既了解组织内的数据建模和业务过程，又了解行业部门之间的数据建模和业务处理。 必须仔细设定消息架构的因素以重复使用公用元素，并精确表示与正在建模的过程相关的状态和逻辑。 跨部门和组织边界工作的服务必须解决信任、身份验证和授权等问题。 跨公用网络工作的服务必须解决该环境的不可靠性和恶意攻击等问题。 服务必须设计得具有伸缩性，并且能在需要很少维护的情况下可靠地运行。

尽管提供有关如何解决这些复杂问题的详细指南已超出了本文的范围，但提供服务设计中的几个基本问题也是非常有用的。 本文档集中随后的主题将进一步讨论如何考虑服务设计。

功能要求和操作要求的分离

为了以一致的方式应用策略（以及开发和维护成本的管理），可以开发一个能够由许多针对不同的功能要求而提供的服务共享的可操作基础结构。 最好对于组织中的所有服务实现一次操作支持功能。

如前面所述，处理元数据的服务文档的分离原则支持这种分离要求。 基础结构服务用于处理消息的“头”并满足操作要求；服务特定的逻辑将处理消息的头并满足功能要求。

图 2 阐释在基于服务的结构中的业务逻辑和操作要求的分离。

图 2. 功能要求和操作要求的分离

粒度

为了补偿网络请求中固有的滞后时间，最好将服务设计为在每次与服务使用者交互时都执行相对较多的工作。

服务的常见模型是使用“查询、更新、添加和删除”方法来操作大量文档。 例如，应当在单个请求中更新产品说明，并提供文档更新前后的视图。 这与典型的对象模型方法（将针对每个已发生更改的属性调用不同的访问器方法）形成对比。

另一个模式是支持请求和响应元素的数组。 例如，电视列表服务应当在单个请求中接受一系列频道，并用单个响应消息为所有已请求的频道返回适当标记的列表。

服务代理

服务代理是一种服务，它有助于您使用其他服务。 服务代理通常由目标服务的提供商提供，它在靠近使用服务的应用程序的位置以拓扑方式运行。 它既帮助准备服务请求，又帮助解释来自服务的响应。 服务代理通常可提供下列好处：

•	易于集成。 使用所提供的代理与远程服务联系可以简化开发过程。 例如，服务代理可以提供语言绑定，这使服务调用看上去如同本地方法调用一样。
•	错误处理。 对于使用服务的应用程序的开发人员来说，最棘手的任务就是对错误条件做出正确的响应。 服务代理可被设计为了解服务可能产生的错误，这会大大简化集成工作。
•	数据处理。 服务代理可被设计为以适当的智能方式缓存服务中的数据， 这可大大缩短服务的响应时间、降低服务负荷并允许应用程序在断开连接（脱机）状态下工作。 有关如何管理类似数据的更详细的讨论，请参阅状态文档中有关快照和参考状态的讨论。
•	请求验证。 服务代理可以检查服务请求的输入文档，以便在提交之前确认其正确性，并允许捕获明显的错误，而不会产生滞后时间和往返时的服务器负载。 这并不取消服务在收到时验证所有请求的需要；服务既无法确信请求是由代理准备的，又无法信任在组织不能控制的“可攻击”环境中运行的服务代理。
•	智能路由。 一些服务可以基于请求的内容，使用代理来将请求发送到特定的服务实例。 基于内容的路由将在消息处理中详述。

并非所有的服务都需要服务代理，而且并非所有的使用者都需要服务代理的帮助，既便有可用的服务代理也是如此。图 3 阐释服务代理如何由一些服务使用但不由其他服务使用。

这些视图由一组需求来驱动，反过来又会生成设计、开发、配置和运作过程及系统的输入。

图 3. 服务代理

一些服务代理可以与多个服务进行通信；例如，经纪人可以从多个保险公司请求报价，以便进行比较。

可使用开发工具从 Web 服务描述语言工具 (WSDL) 文档自动生成代理类；这些类是简单服务代理的示例。

服务代理与服务的使用者有关，并且通常与服务的使用者紧密绑定。

处理不可靠性

由于计算机和网络可能发生故障，所以远程服务的可靠性将不如在本地运行的软件可靠性高。 公用网络的可靠性不如局域网高。 请求滞后（即向服务发送请求和接收响应之间的时间）是不可预见的。

强健的消息处理基础结构可以减少但不能消除消息传送的不可靠性问题；这会在消息处理中较为详细地阐述。 操作和组织方面的补救措施（例如，冗余服务和服务等级协议）对于降低服务无法访问或性能较差的可能性也非常有用。

但是，在任何使用或公开网络服务的应用程序中，必须针对服务的可靠性进行某些考虑。 最重要的一般原理是支持异步消息处理。 异步消息处理将发送请求和接收响应分成两个交互操作，这可能会由相当长的时间间隔来分开。 最可靠的消息处理基础结构依赖客户端和服务异步收发的能力；复杂过程通常涉及到较长的滞后时间，即使在所有的网络和服务都按照规范正常运行时也是如此；一般原则是，当应用程序要求允许使用异步交互时，就针对这些交互进行设计。

异常处理

针对失败进行设计。 在应用程序软件中，错误是不可避免的。 基于服务的结构引进了一组可导致事情出现问题的新方法。

仔细地定义服务异常，可允许以编程方式处理许多错误。 客户端和服务都还必须准备从中间服务（例如，可靠的消息处理基础结构）那里接收异常。 异步消息处理会使异常处理变复杂，这是由于在失败时过程状态可能需要保持可用。

在交互式应用程序中，可以将无法由应用程序逻辑解决的错误展示给用户。 服务和非交互式应用程序需要使用一些功能来将严重的错误提交至操作人员。

返回页首

服务是投资

与编写独立的应用程序相比，设计、开发、部署、管理和维护可靠服务等过程需要较高的前期成本。 服务模型在结构方面的好处必须体现此投资的价值。 实质上，基于服务的结构必须长期体现成本效益这一好处。

广而言之，服务通过针对集成而设计来提供好处。 在大型组织中的客户、合作伙伴、供应商和部门之间，设计完善的服务可用于集成业务应用程序（例如，记帐系统）和软件系统。 最重要的是，服务在设计上与仍未开发的系统协作。

在基于组件的传统系统中，每个组件都需要知道有关其他组件的许多信息，以便与它们进行联系。 因此，很难在不影响系统其他部分的情况下将一个组件更换为另一个组件。 如果尝试使用的组件采用不同的通信协议、用不同的语言编写或者需要定期更新，这可能会产生问题。

使用消息，可以指定和约定要在服务之间使用的线（通信）格式。 与使用通过函数调用来实现的组件相比，这为您提供下列好处：

•	允许交互操作用不同技术实现的服务，从而允许用不同技术编写的服务互相通信。
•	允许您将使用一种技术编写的服务替换为使用另一种技术编写的服务。
•	允许您在每次引入新服务时选择技术。

服务以独立实体形式运行，每个服务在系统中都承担不同的责任，而且每个服务都指定其各自的内部行为。 它们不与其他服务共享状态（例如，数据库内容），因此您在更改系统的内部实现时，无需更改与其通信的其他服务。 因为服务不互相依赖，所以它们可用于连接在技术上不同的系统，以便使用可能已存在于组织内或组织外的功能。 这可能包括使用 Internet 上的可用服务，您无需知道有关这些服务内部工作方式的任何信息即可使用它们。

不同服务的控制和管理也是相互独立的。 可以在组织内的一台计算机上安装一个服务，并独立于与该服务通信的其他服务来管理该服务。 这意味着您可以将服务移到另一台计算机，而不会对其他服务的操作造成负面影响，从而简化应用程序的管理。 将上述想法深推一步，则意味着您可以在组织内的多台计算机上运行服务的其他实例，从而提供扩展应用程序的机会。

上面的多数分析都可以归结为“服务提升松散耦合”。 耦合表示多件事情链接在一起，它们之间存在依赖关系，并且它们在发生更改后会产生一定的后果。 软件可以具有许多依赖关系： 它依赖运行它的操作系统、线程和进程模型、其他服务和其他服务接口。 良好的服务设计会隐藏这些依赖关系。

耦合的紧密程度是可调整的因素，而且您必须权衡哪些因素是对您至关重要的，以便决定以怎样的紧密程度耦合服务。

耦合使系统的更改成本变得非常昂贵。 例如，如果您有两个紧密耦合的组件，则在更改其中的一个组件时，还需要在另一个组件中实现某些更改。 如果将上述想法扩展到涉及许多组件的应用程序，则成本会更高。 如果这些组件中包括外部的预包装组件，则成本会再次升高。 如果这些组件跨越组织边界，则还应当考虑协商更改所带来的成本。 因此，在设计服务时应当牢记松散耦合。

完善的设计都会进行较好的取舍。 有时，使用松散耦合所带来的好处不抵所涉及到的额外工作。 实际上，为了操作方面的原因，有时将需要一起部署和管理多个服务。 例如，可以创建一个基于给定的地址验证邮政编码的服务。 因为这是与地址服务一起使用的，所以以下操作非常有意义：将这两个服务放在一起，使它们成为一个可部署的单元，然后将二者的组合作为松散耦合服务的一部分呈现给外部世界。

图 4 阐释系统中的耦合选项。

图 4. 耦合选项

在选择是否创建组件或服务时需要做出一定的取舍，每个选择都有一定的利弊。 从管理的角度看，组件的耦合程度较高，意味着就必须以一个单元形式管理多个组件，因此不易将一个组件从一个系统移到另一个系统；从技术角度看，组件的耦合程度较高，意味着很难将使用不同技术编写的组件绑定到一起。 服务的耦合程度较低，这会带来前面讨论的好处（例如，可以单独控制和管理不同的服务）。

尽管基于服务的结构具有上述好处，但是它并非适合所有的应用程序。 软件架构师必须考虑应用程序的周期，将功能要求和操作要求映射到适当的技术，并选择最适合的结构模式。 但是，对于大多数长久的企业应用程序来说，服务模型所带来的好处将有可能证明初始投资的价值。

返回页首

服务小结

网络方面的革新和投资已经为软件创造了解决新类别业务方案的机会。 这些包括企业间交互以及连接企业应用程序的复杂过程。

但是，传统的应用程序开发方法不太适合在异类系统的混合网络之间集成。 如果尝试使用 RPC 和远程对象结构，会导致易损坏的解决方案，这样的解决方案经常要求对组织的操作步骤进行入侵式更改。 对类似系统进行修改被证明是代价高昂的，并要求合作伙伴组织之间进行较高级别的协调。

服务模型在设计上比较适合构建集成解决方案。 按照本文描述的那样来使用服务，可以提供下列好处：

•	独立的管理。 这意味着在移动或复制服务时不会对系统产生负面影响。 复制服务可允许您进行扩展。
•	使用者和提供商之间的技术独立性。 互操作性得到改善，从而允许不同的系统方便地通信和共享信息。
•	功能要求和操作要求的分离。 服务的操作方面由基础结构来处理，核心的业务功能包含在服务中。 这使功能要求和操作要求彼此无关，这意味着不同的用户（甚至不同的部门）可以使用不同的部分。
•	基于标准。 服务立足于使用基于标准的技术（例如，SOAP、HTTP 和 XML）。 这意味着用户不被限制于仅使用一个供应商的产品。

基于服务的结构为在设计上要进行集成和更改的软件提供模型。

转到原英文页面