英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料

WWW 2008 /期刊论文: Web工程 – Web服务部署 中国北京

标题: RESTful Web 服务对比 “Big” Web 服务: 做出正确的架构决策

作者：Cesare Pautasso Olaf Zimmermann Frank Leymann

摘要:

Web服务（WS）域中的最新技术趋势表明，消除WS- *标准的假定复杂性的解决方案可能正在出现：代表性状态转移（REST）的倡导者已经开始相信，他们的想法可以解释为什么使用“万维网” Web作品同样适用于解决企业应用程序集成问题并简化构建面向服务的体系结构所需的管道。在本文中，我们通过基于架构原理和决策的定量技术比较来客观化WS- *与REST的争论。我们表明，两种方法在必须做出的体系结构决策数量和可用替代方案数量上有所不同。选择自由与选择自由之间的这种差异解释了所感知的复杂性差异。但是，我们还表明，就最终开发和维护成本而言，某些决策的后果存在显着差异。我们的比较可以帮助技术决策者更客观地评估这两种集成方式和技术，并选择最适合其需求的一种：REST非常适合基本的临时集成方案，WS- *更灵活，并能解决高级服务质量问题企业计算中常见的需求。

分类和主题描述:

A.1 [一般文献]：介绍和调查；

C.2.2 [计算机通信网络]：网络协议；

D.2.11 [软件工程]：软件体系结构；

D.2.12 [软件工程]：互操作性；

H.1 [信息系统]：模型和原理

一般术语:

设计、标准化

关键词:

体系结构决策模型，HTTP，REST，面向资源的体系结构，面向服务的体系结构，SOAP，技术比较，Web服务，WSDL，WS- *与REST

版权由国际万维网会议委员会（IW3C2）拥有。 这些论文的分发仅限于课堂使用，其他人只能个人使用。

WWW 2008，2008年4月21日至25日，中国北京。

ACM 978-1-60558-085-2/08/04。

图1：将WS- * vs.REST决策置于应用程序集成样式的上下文中

1.介绍

可以使用许多不同的样式来集成企业应用程序（图1）。在依赖共享数据库，使用批处理文件传输，调用远程过程或通过消息总线交换异步消息之间进行选择是一项重大的体系结构决策，这会影响对底层中间件平台的需求以及集成系统的属性[20]。 “ Big” Web服务技术堆栈[1、45、47]（SOAP，WSDL，WS-Addressing，WS-ReliableMessaging，WSSecurity等）为远程过程调用（RPC）和消息传递集成样式提供了互操作性[ 41]。最近，提出了另一种解决方案来在Web上实现远程过程调用：所谓的RESTful Web服务[12]越来越受到关注，这不仅是因为它们在许多Web 2.0服务[32]的应用程序编程接口（API）中的使用,也因为发布和使用RESTful Web服务[40]的更加简单。

分布式系统设计中的关键体系结构决策（例如，集成样式和技术的选择）应基于技术论点以及每种替代方案提供的具体功能的公平比较。取而代之的是，WS- *与REST的争论不幸地演变成有偏见和宗教性的争论，这只会造成困惑和无法实现的期望[19]。

在本文中，我们采用定量方法来比较两者基于架构原理的集成样式技术和决定。比较是基于我们的行业项目和两种方法的教学经验。这样，相对WS- *和RESTful Web服务的复杂性（或简单性）可以根据以下内容衡量：1）必须做出的决策数量2）可用的备选方案（选项）的数量，以及3）所需的开发工作和所涉及的技术风险所指示的相对成本。正如我们将显示的那样，决策可能会相互影响，因此，例如，决定在较高级别上使用RESTful方法将在较低级别上限制异步消息中间件的选择选项。同样，在某些情况下，REST中缺少与某些决策（例如，交易保证或消息交换的可靠性）有关的选项，显然只能表明降低了复杂性，因为剩下的唯一选择就是实施定制解决方案，这会导致更高的开发和维护工作量和风险。

本文的组织如下。本文的组织如下。首先在第2部分和第3部分中，我们提供有关WS- *和RESTful Web服务的背景信息。 在第4节中，我们介绍了以决策为中心的比较方法。 然后，我们通过列出和比较采用WS- *和REST的几个重要原则（第5节），概念（第6节）和技术（第7节）决策来应用它。在第8节中，我们介绍相关工作，在第9节中，我们总结

结论。

2. SOAP和WS- * STACK

在异构中间件技术堆栈之间提供无缝的互操作性，并促进服务使用者（请求者，客户端）和服务提供者之间的松散耦合，是面向服务的体系结构（SOA）概念和Web服务技术的主要设计目标。

2.1 概念与技术

从概念上讲，服务是通过网络可访问端点[16]提供的软件组件。服务使用者和提供者使用消息以自包含文档的形式交换调用请求和响应信息，这些文档很少对接收方的技术能力做出假设。特别是，没有远程对象引用的概念，它要求对象代理来管理分布式内存地址空间[43]。 在技术级别上，SOAP是一种XML语言，用于定义消息体系结构和消息格式，因此提供了基本的处理协议。SOAP文档定义了一个称为信封的顶级XML元素，其中包含一个标头和一个正文。 SOAP标头是用于消息层基础结构信息的可扩展容器，可用于路由目的（例如，寻址）和服务质量（QoS）配置（例如，事务，安全性，可靠性）。 正文包含消息的有效负载。 XML模式用于描述SOAP消息的结构，以便两个端点处的SOAP引擎可以编组和解组消息的内容并将其路由到适当的实现。

Web服务描述语言（WSDL）是一种XML语言，用于通过语法定义接口。WSDL端口类型包含多个抽象操作，这些抽象操作与某些传入和传出消息相关联。 WSDL绑定将抽象操作集与具体的传输协议和序列化格式链接在一起。在撰写本文时，唯一的标准化绑定使用基于HTTP的SOAP [21]。 供应商已经定义了几个附加的协议，以支持消息传递协议以及专有的旧系统接口。 服务端点可以在传输级别上进行寻址，即使用SOAP / HTTP绑定端点的通用资源标识符（URI），也可以通过WS-Addressing在消息传递级别上进行寻址[44]。

默认情况下，没有状态的概念。WS-Resource Framework [28]涵盖了与有状态Web服务的交互，该框架处理Web服务接口背后的有状态资源的管理。 WS- *技术栈还涵盖了确保高级中间件系统互操作性所需的许多其他QoS功能[45]。考虑到该方法的模块化和可组合性，这导致了相当多的WS- *规范集。

2.2优势

尽管它们看起来很复杂，SOAP消息格式和WSDL接口定义语言作为能够在异构中间件系统之间交付互操作性的网关技术得到了广泛采用。

WS-*的一个优点是协议的透明性和独立性。使用SOAP，相同格式的相同消息可以跨各种中间件系统传输，这些系统可能依赖于HTTP，但也依赖于许多其他传输。传输协议可能会随之更改。被声明为SOAP头，可以使加密和可靠传输等QoS方面独立于路径上使用的传输(“端到端QoS”)。

使用WSDL来描述服务接口有助于从底层通信协议和序列化细节以及服务实现平台(操作系统和编程语言)中抽象。WSDL契约提供了相应请求和响应消息的语法和结构的可由机器处理的描述，并为服务定义了灵活的演化路径。随着业务和技术需求的变化，可以将相同的抽象服务接口绑定到不同的传输协议和消息传递端点。特别是，WSDL可以基于同步和异步交互模式为系统建模服务接口。在为现有的遗留系统构建网关时，这种灵活性变得非常重要，因为遗留系统可能并不总是使用对web友好的协议。

此外，成熟的SOAP引擎和WSDL工具[2,11]有效地向应用程序编程人员和集成人员隐藏了感知到的复杂性。根据我们个人的项目经验[54]，如果所选的运行时和工具符合WS-I基本概要[47]，那么就不需要研究规范来开发可互操作的服务。可以从WSDL契约自动生成测试客户端。

2.3 缺点

矛盾的是，当前WS-*工具所提供的强大功能(使将现有软件组件转换为Web服务变得如此容易)也可能被滥用。因此，避免跨抽象级别的泄漏是很重要的。例如，当服务实现的本地数据类型和语言结构出现在其接口中时，可能会出现互操作性问题。这一弱点可以通过陈述和实施某些设计和编码指导方针来缓解，比如契约优先开发。

考虑到WS-*标准栈的可表达性，早期的实现一直受到互操作性问题的困扰。除了后来WS-I澄清的错误解释之外，这些错误解释还可以部分归咎于XML和现有(面向对象)编程语言之间的阻抗不匹配。例如，连接上的XML和相应的内存数据结构之间的转换一直存在问题，这是性能低下的[15]的主要原因。以Java为例，为了生成一个稳定的Web服务编组层[25]，需要进行几次尝试(Apache SOAP到JAXRPC 1.0和1.1到JAX-WS和JAX-B)。此外，XML模式是一种非常丰富的语言，因此很难确定正确的结构来以所有SOAP/WSDL实现完全支持的方式表达数据模型。通过分析可以避免这个问题，识别XML模式类型的子集，例如序列，对于大多数集成场景来说，这已经足够好了，并且可以互操作。

3. REST

代表性状态转移（REST）最初是作为一种体系结构样式引入的，用于构建大规模分布式超媒体系统。这种体系结构风格是一个相当抽象的实体，其原理已被用来解释HTTP 1.0协议的出色可伸缩性，并且也限制了其后续版本HTTP 1.1的设计。因此，术语REST非常经常与HTTP结合使用。

在本节中，我们将围绕用于定义“ RESTful” Web服务的当前解释概述REST的主要特征。有关更多信息，请向读者介绍[12，14，33]。

3.1技术原理

REST架构风格基于四个原则：

通过URI进行资源识别。RESTful Web服务公开了一组资源，这些资源标识了与其客户端进行交互的目标。资源由URI [5]标识，URI提供了用于资源和服务发现的全局寻址空间。

统一的界面。使用固定的一组四个创建，读取，更新和删除操作来操纵资源：PUT，GET，POST和DELETE。PUT创建一个新资源，然后可以使用DELETE将其删除。GET以某种表示形式检索资源的当前状态。 POST将新状态传输到资源上。

自描述消息。资源与它们的表示分离，从而可以以多种格式（例如HTML，XML，纯文本，PDF，JPEG等）访问其内容。有关资源的元数据可用并用于控制缓存，检测传输错误，协商适当的表示格式以及执行身份验证或访问控制。

通过超链接的状态交互。与资源的每次交互都是无状态的，即请求消息是独立的。 有状态的交互基于显式状态转移的概念。存在几种交换状态的技术，例如URI重写，Cookie和隐藏的表单字段。 可以将状态嵌入响应消息中，以指向交互的有效将来状态。

3.2优势

RESTful Web服务被认为很简单，因为REST利用了现有的众所周知的W3C / IETF标准（HTTP，XML，URI，MIME），并且必要的基础设施已经普及。HTTP客户端和服务器可用于所有主要的编程语言和操作系统/硬件平台，并且默认的HTTP端口80在大多数防火墙配置中通常默认情况下保持打开状态。

这样的轻量级基础结构可以用最少的工具构建服务，因此获取成本不高，因此采用的障碍很小。由于开发人员可以从普通的Web浏览器开始测试此类服务，而无需开发定制的客户端软件，因此为RESTful服务构建客户端所需的工作量很小。 部署RESTful Web服务与构建动态网站非常相似。

此外，借助URI和超链接，REST已经证明，无需基于强制注册到（集中式）存储库的方法，就可以发现Web资源。

在操作方面，由于REST内置了对缓存，集群和负载平衡的支持，因此已知如何扩展无状态RESTful Web服务以服务于大量客户端。由于可以选择轻量级消息格式，例如JavaScript Object Notation（JSON [10]），或者甚至对于非常简单的数据类型，甚至可以选择纯文本，REST也提供了更多余地来优化Web服务的性能。

3.3 缺点

关于构建RESTful Web服务的公认最佳实践存在一些困惑。Hi-REST建议已非正式建立，但并非总是被所谓的Lo-REST实现完全遵循：Hi-REST，主张使用所有4个动词（GET，POST，PUT，DELETE;建议使用（所谓的）“不错的” URI；并建议使用原始旧XML（POX）格式，用于格式化消息的内容。另一方面，Lo-REST专注于最小公分母。因此，仅使用2个动词（对于幂等请求使用GET，对其他所有请求使用POST）。这是由于以下事实：代理和防火墙可能并不总是允许使用任何其他动词的HTTP连接。同样，POST和GET是XHTML form5的method属性中可以

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[236025]，资料为PDF文档或Word文档，PDF文档可免费转换为Word