面向对象的服务体系结构

1、引言

今天，Web 服务——特指用 Web 服务描述语言（Web Services Description Language，WSDL）描述的、通过 HTTP 发送的、处理 XML 编码的 SOAP 消息的分布式服务——正得到广泛的部署。Web 服务可用在各种各样的应用程序集成环境中：从简单的（特别是防火墙后面的）数据共享到大规模的 Internet 零售和货币交易。

Web 提供了软件组件之间的互操作性，这些软件组件可以在不同的企业之间进行通信，并且可以驻留在不同的基础架构中。这解决了顾客、软件开发人员和合作伙伴所面临一个最重要的问题。HTTP 和 SOAP 提供了通信和消息的互操作性。WSDL 提供了消息的描述，以支持开发工具之间的互操作性；它凭借交换接口定义的能力来完成通信互操作性。

一组基本的 Web 服务规范使顾客和软件厂商能够解决一些重要的问题。在这些规范成功的基础上，许多开发人员和公司准备解决 Web 服务方面更难的问题。Web 服务的巨大成功使开发人员想要从 Web 服务获得更多的能力。由于重要的工具和通信互操作已经成功了，所以开发人员现在期望增强互操作的功能。

除了基本的消息互操作性和接口交换之外，开发人员越来越需要更高级别的应用程序服务互操作。许多商业应用程序运行在这样一种环境中（“中间件”或“操作系统”），这种环境为一些功能（比如安全性和事务处理）提供支持。

IBM、Microsoft 和业界其他一些公司常常需要使 Web 更安全、更可靠且更好地支持事务处理。另外，我们在提供这些能力的同时，还需要保持现在 Web 服务中必不可少的简单性和互操作性。

2、面向服务的体系结构

Web 服务非常适于启用面向服务的体系结构（Service-Oriented Architecture，SOA），在使用 Web 服务构建解决方案时，解决方案由一些自治的服务组成，这些自治的服务通过 URL 进行标识，带有使用 WSDL 文档化的接口，处理定义明确的 XML 消息。SOA 是对实现解决方案的面向对象（ object-oriented，OO）、过程性和以数据为中心的方法的自然补充。实际上，在创建 SOA 系统时，一般使用这些技术中的一种或多种来构造单个服务。

面向服务的体系结构不同于面向对象和过程性系统的一个关键方面是：绑定（binding）。服务根据它们提供什么功能和他们如何提供这些功能来进行交互。而面向对象和过程性系统根据类性或名称把元素链接在一起。以下将更详细地对此进行讨论。

2、1通过 Schema 和合同而非类型描述服务

与以前的系统不同，Web 服务模型没有使用共享类型（需要通用的实现）的概念。相反，服务的交互是完全根据合同（用于消息处理行为的 WSDL/BPEL4WS）和 Schema（用于消息结构的 WSDL/XSD）。这使得服务能够描述它可以发送和/或接收的消息的结构以及对这些消息的顺序约束。结构和行为之间的分离以及对这些特征进行的显式和机器可验证的描述，可以简化异质环境中的集成。

此外，这种信息充分地描述了服务接口的特征，这样应用程序集成就不需要共享的执行环境来创建消息结构或行为。

面向服务的模型假定一个完全分布式的环境，在这种环境中，将 Schema 和/或合同中的改变传送到与服务交互的所有各方是非常困难的，如果不是不可能的话。面向服务意味着 Schema 和合同应该保持向后兼容，并且可以包含不完全为特定处理系统理解的信息。

由于这个原因，为用在面向服务的设计中而设计的合同和 Schema 能够比面向对象的接口更灵活。特别是，服务可使用像 XML 元素通配符（例如，xsd:any）、Schema 扩展和可选的 SOAP 头部来以不中断部署的应用程序的方式发展服务。这些特征对于 Web 服务的可组合形式非常关键的。

2、2 服务兼容性多于类型兼容性

过程性设计和面向对象设计一般把类型兼容与语义兼容等同起来。面向服务为决定兼容性提供了更加丰富的模型。结构兼容性是基于合同（WSDL 和 BPEL4WS（可选））和 Schema（XSD）的，并且可以进行验证。此外，WS-Policy 的出现使得可以对服务之间服务保证的兼容性进行附加的自动分析。这是根据 WS-Policy 语句形式的能力和需求显式断言完成的。

使用 WS-Policy，服务可以以机器可读的策略表达式（包含断言组合）的形式描述它们的服务保证能力和需求。这允许服务根据它们“如何”或“以什么样的质量”提供它们的合同来相互选择。

策略断言通过稳定的且全局惟一的名称进行标识，不管把策略断言应用到哪一种服务，这种名称的含义在时间和空间上都是一致的。策略断言也可以带有参数来限定断言的确切解释。

2、3 面向服务假定坏的事情可以并且必将发生

以前的一些用于分布式应用程序的方法显式地假定通用的类型空间、执行模型和过程/对象引用模型。其实，“记忆中”的编程模型都可称为分布式系统模型。

面向服务仅仅假定服务自动执行，而没有本地执行或通用的操作环境的观念。由于这个原因，SOA 显式地假定通信、可用性和类型错误都是共同的。

为了维护系统的完整性，面向服务的设计显式地依赖于各种技术来处理异步和部分失败模式。诸如异步消息传递、事务处理、可靠消息传递和冗余部署都是面向服务的系统中的标准。

此外，与以前的模型不同的是，面向服务假定传入消息不仅可以是结构不良的，而且它可以出于恶意或完全意想不到的目的进行传递。所以面向服务的系统通过把提供证据的责任放到所有的消息发送者身上来保护自己，它们需要应用程序证明已经授予发送者所需的权限。与服务自治的观念相一致，面向服务的体系结构一般依赖于行政管理的信任关系，从而避免了使用传统的 Web 应用程序中常见的通过服务验证的机制。

2、4 面向服务使得能够灵活地绑定服务

面向服务的体系结构（SOA）的核心概念之一就是灵活地帮定服务。更传统的过程性模型、组件模型和对象模型通过引用（指针）或名称绑定组件。SOA支持更动态地发现服务实例来提供请求者所期望的接口、语义和服务保证。

在过程性系统或面向对象的系统中，调用者一般根据它导出的类型或共享的名称空间来查找服务器。而在 SOA 系统中，调用者可以搜索注册中心（比如 UDDI）来查找服务。

1. 该文档是与调用者的需求兼容的消息。兼容性可以通过 WSDL 出现，也可以通过来自知名的 XML Schema 的匹配消息出现。  
2. 该文档支持调用者所需的服务保证。例如，调用者可能需要某种安全性或事务处理方法。

服务实现的松散绑定使选择行为的实现成为可能，这可以用于解决各种各样的需求问题。例如，可供选择的实现可能对应于供应链上可供选择的厂商，这些厂商使得服务能够更快地响应改变的市场条件。同样，从地理上讲，可供选择的实现可能是分布式数据中心，这些数据中心使得服务能够容许灾难的出现。