38、资源描述与服务架构：WADL与大 Web 服务的深度剖析

资源描述与服务架构：WADL与大 Web 服务的深度剖析

1. WADL 对资源的描述

1.1 XSD 与参数标签

即使 XSD 能完整描述表示格式，我们仍可定义一些 param 标签来指出文档中特别重要的部分。

1.2 描述 APP 集合

之前的示例用应用表单描述了一组无限的相关资源，每个资源通过发送简单的 XML 文档响应 GET 请求。WADL 可描述任何响应统一接口的资源。若资源提供 XML 表示，我们能用 param 标签深入该表示，指出有趣的数据位和其他资源的链接位置。

1.3 WADL 与 APP 服务文档对比

WADL 文件和 Atom 发布协议的服务文档都是用于描述资源的 XML 词汇表。服务文档描述 APP 集合，而 WADL 文档可描述任何资源。

1.4 定义资源类型

下面定义了两种资源类型：Atom 集合和图像集合，它们类似于面向对象设计中的类。

<?xml version="1.0"?>
<!-- This is a description of two common types of resources that respond
     to the Atom Publishing Protocol. -->
<application xmlns="http://research.sun.com/wadl/2006/07"
             xmlns:app="http://purl.org/atom/app">
  <!-- An Atom collection accepts Atom entries via POST. -->
  <resource_type id="atom_collection">
    <method href="#getCollection" />
    <method href="#postNewAtomMember" />
  </resource_type>
  <!-- An image collection accepts image files via POST. -->
  <resource_type id="image_collection">
    <method href="#getCollection" />
    <method href="#postNewImageMember" />
  </resource_type>

这两种资源类型都支持 getCollection 方法，但 Atom 集合支持 postNewAtomMember 方法，而图像集合支持 postNewImageMember 方法。

1.5 定义方法

以下是三种可能的资源操作方法：

  <!-- Three possible operations on resources. -->
  <method name="GET" id="getCollection">
    <response>
      <representation href="#feed" />
    </response>
  </method>
  <method name="POST" id="postNewAtomMember">
    <request>
      <representation href="#entry" />
    </request>
  </method>
  <method name="POST" id="postNewImageMember">
    <request>
      <representation id="image"  mediaType="image/*" />
      <param name="Slug" style="header" />
    </request>
  </method>

• getCollection 是一个 GET 操作，期望以 Atom 提要作为其表示。
• postNewAtomMember 是一个 POST 操作，发送 Atom 条目作为其表示。
• postNewImageMember 也是一个 POST 操作，发送图像文件作为表示，并知道如何为 HTTP 头 Slug 指定值。

1.6 定义表示

最后定义了两种可能的 XML 表示：

  <!-- Two possible XML representations. -->
  <representation id="feed" mediaType="application/atom+xml"
          element="atom:feed" />
  <representation id="entry" mediaType="application/atom+xml"
          element="atom:entry" />
</application>

由于这些表示已在 Atom 的 XML 模式文档中描述，我们只需引用 XSD 文件，还可通过定义 param 元素注释 XSD，告知 WADL 客户端资源间的链接。

1.7 使用资源类型定义 APP 集合

将上述定义的文件发布到 Web 上，如 http://www.example.com/app-resource-types.wadl ，它就成为一个资源。我们可在服务中引用其 URI 来定义 APP 集合，如下所示：

<?xml version="1.0"?>
<!-- This is a description of three "collection" resources that respond
     to the Atom Publishing Protocol. -->
<application xmlns="http://research.sun.com/wadl/2006/07"
             xmlns:app="http://purl.org/atom/app">
  <resources base="http://www.example.com/">
    <resource path="RESTfulNews" 
     type="http://www.example.com/app-resource-types.wadl#atom_collection" />
    <resource path="samruby/photos" 
     type="http://www.example.com/app-resource-types.wadl#image_collection" />
    <resource path="leonardr/photos" 
     type="http://www.example.com/app-resource-types.wadl#image_collection"/>
  </resources>
</application>

1.8 超媒体的重要性

Atom 发布协议受欢迎是因为其通用接口。两个 APP 服务的主要差异在各自的服务文档中描述。通用 APP 客户端可读取这些文档并重新编程以作为多种不同服务的客户端。而 HTTP 的统一接口更通用，HTML 和 WADL 等超媒体格式可描述任何 Web 服务，其客户端比 APP 客户端更通用。超媒体是服务间交流差异的方式，将智能嵌入超媒体可减少程序员在代码中硬编码的内容，更重要的是，超媒体让我们能访问链接，这是仅次于 URI 的第二重要的 Web 技术。只有当 Web 服务以富含链接的超媒体形式提供表示时，REST 的潜力才能得到充分发挥。

1.9 WADL 是否有害

有人担心 WADL 会像 WSDL 对 SOAP 那样，将普通 HTTP Web 服务与 RPC 风格绑定。但实际上 WADL 抽象掉了 HTTP 请求和响应的细节，但没有添加新的抽象。REST 不依赖于 HTTP，WADL 文档描述的是响应统一接口的资源，使用 WADL 的程序创建对应资源的对象并通过体现统一接口的方法调用访问它们，这仍是 REST。不过，一些一键式代码生成器可能会生成只暴露单个“资源”的 WADL 文件，这是一个值得关注的问题。但幸运的是，WADL 的发展背景与 WSDL 不同，它在人们意识到 REST 优势时被引入，并被宣传为在隐藏细节的同时保持 RESTful 接口的方式。

2. 资源导向架构与大 Web 服务对比

2.1 大 Web 服务简介

大 Web 服务主要指 SOAP、WSDL 和 WS - * 栈等技术，它们形成了一种与 Web 工作方式不同的 Web 服务范式。

2.2 大 Web 服务的问题

• 不暴露资源 ：Web 基于资源，而大 Web 服务不暴露资源。
• 缺乏 URI 和链接 ：Web 基于 URI 和链接，典型的大 Web 服务只暴露一个 URI 且没有链接。
• 很少使用 HTTP 特性 ：Web 基于 HTTP，大 Web 服务几乎不使用 HTTP 的特性。
  这些问题导致大 Web 服务无法获得资源导向 Web 服务的优势，如不可寻址、不可缓存、连接性差，不遵循统一接口，且在为各种客户端提供服务时往往存在互操作性问题。

2.3 大 Web 服务试图解决的问题

以旅行预订服务为例，预订旅行可能需要预订航班、酒店和租车，这些任务相互关联，且每个任务都需要与外部机构协调以获得最佳交易。资源导向方法虽能建模此类复杂应用，但某些资源可能价值不大。大 Web 服务主要试图解决面向流程、中介分布式服务的设计问题，这类应用在商业和政府应用中更为普遍。

2.4 SOAP 基础

SOAP 是众多 WS - * 规范的基础。将任何没有 DOCTYPE 或处理指令的 XML 文档用两个小 XML 元素包装，就得到一个有效的 SOAP 文档。例如：

<hello-world xmns="http://example.com"/>

包装后的 SOAP 文档如下：

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
   <hello-world xmns="http://example.com"/>
 </soap:Body>
</soap:Envelope>

SOAP 信封的字符编码必须与所包含的文档相同。

2.5 SOAP 示例

以下是提交给 Google 的 SOAP 搜索服务的 SOAP 信封示例：

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <gs:doGoogleSearch xmlns:gs="urn:GoogleSearch">
      <key>00000000000000000000000000000000</key>
      <q>REST book</q>
      <start>0</start>
      <maxResults>10</maxResults>
      <filter>true</filter>
      <restrict/>
      <safeSearch>false</safeSearch>
      <lr/>
      <ie>latin1</ie>
      <oe>latin1</oe>
    </gs:doGoogleSearch>
   </soap:Body>
</soap:Envelope>

该文档描述了对远程过程 gs:doGoogleSearch 的调用。

2.6 SOAP 编码方式

早期的 RPC/literal 或 Section 5 编码方式在后来的规范版本中被弃用，主要被 document/literal 和 wrapped document/literal 编码方式取代。

2.7 SOAP 头元素

SOAP 除了 Body 元素外还有 Header 元素，任何可放入 Body 元素的命名空间文档（无 DOCTYPE 或处理指令）都可放入 Header 。 Header 可包含任意数量的元素，且元素通常较小。SOAP 头元素通常包含关于 Body 中数据的信息，如安全和路由信息，类似于 HTTP 头。SOAP 为头实体定义了 actor 和 mustUnderstand 两个属性，用于标识目标和对中间节点或最终目的地施加限制。

2.8 SOAP 的其他特点

SOAP 请求和响应格式相同，类似于 HTTP，还有单独的 SOAP Fault 格式用于表示错误条件。目前，SOAP 文档中只能包含 XML 文档，虽有一些尝试定义附加二进制数据的机制，但尚未有明确的解决方案。SOAP 的一个所谓优点是传输独立性，即其头信息在消息内部，不依赖于传输协议，但在实践中该特性很少使用。

2.9 大 Web 服务的发展历程

大 Web 服务的愿景随时间演变，为全面分析，我们按时间顺序进行：
- 最初的“发布、查找和绑定”愿景 ：早期大 Web 服务的设想。
- “安全、可靠的事务” ：后续发展阶段关注的重点。
- 近期发展 ：如企业服务器总线、业务流程执行语言和面向服务的架构等。

3. 大 Web 服务各阶段详细分析

3.1 最初的“发布、查找和绑定”愿景

在大 Web 服务发展初期，“发布、查找和绑定”是核心愿景。其流程如下：
1. 发布 ：服务提供者将服务的相关信息发布到服务注册中心，这些信息包括服务的功能、接口、访问方式等。
2. 查找 ：服务消费者在服务注册中心查找符合自己需求的服务。
3. 绑定 ：服务消费者找到合适的服务后，与服务提供者建立连接并使用该服务。

这个愿景旨在实现服务的自动化发现和使用，提高服务的可复用性和互操作性。但在实际应用中，存在一些问题，例如服务注册中心的维护成本高、服务信息的准确性和完整性难以保证等。

3.2 “安全、可靠的事务”阶段

随着大 Web 服务的发展，安全和可靠性成为重要关注点。在这个阶段，主要解决以下问题：
- 安全问题 ：通过各种安全机制，如身份验证、授权、数据加密等，确保服务的安全性。例如，使用 SSL/TLS 协议对数据传输进行加密，防止数据在传输过程中被窃取或篡改。
- 可靠事务 ：实现可靠的事务处理，保证服务调用的原子性、一致性、隔离性和持久性（ACID）。例如，使用两阶段提交协议来确保分布式事务的一致性。

以下是一个简单的表格，对比不同安全机制的特点：
| 安全机制 | 优点 | 缺点 |
| ---- | ---- | ---- |
| 身份验证 | 确保用户或服务的身份真实性 | 可能存在密码泄露风险 |
| 授权 | 控制用户或服务的访问权限 | 权限管理复杂 |
| 数据加密 | 保护数据的机密性 | 增加系统开销 |

3.3 近期发展

大 Web 服务的近期发展主要集中在企业服务器总线、业务流程执行语言和面向服务的架构等方面。
- 企业服务器总线（ESB） ：是一种中间件，用于集成不同的应用程序和服务。它提供了消息传递、服务路由、数据转换等功能，使得不同的服务可以方便地进行交互。
- 业务流程执行语言（BPEL） ：用于描述和执行复杂的业务流程。通过 BPEL，可以将多个服务组合成一个完整的业务流程，实现业务的自动化。
- 面向服务的架构（SOA） ：是一种设计理念，强调将应用程序拆分成多个独立的服务，这些服务可以通过网络进行交互。SOA 提高了系统的灵活性和可扩展性。

下面是一个 mermaid 流程图，展示了面向服务的架构中服务之间的交互：

graph LR
    A[客户端] -->|请求服务| B[服务注册中心]
    B -->|返回服务信息| A
    A -->|调用服务| C[服务提供者 1]
    A -->|调用服务| D[服务提供者 2]
    C -->|返回结果| A
    D -->|返回结果| A

4. 资源导向架构与大 Web 服务的综合对比

4.1 技术特点对比

对比项	资源导向架构	大 Web 服务
资源暴露	充分暴露资源，每个资源有唯一的 URI	不暴露资源或只暴露一个 URI
链接性	富含链接，便于资源之间的关联和导航	几乎没有链接
HTTP 特性利用	充分利用 HTTP 的各种特性，如 GET、POST、PUT、DELETE 等	很少使用 HTTP 特性
统一接口	遵循统一接口，如 RESTful 接口	不遵循统一接口
互操作性	具有良好的互操作性，易于不同系统之间的集成	在为各种客户端提供服务时存在互操作性问题

4.2 应用场景对比

• 资源导向架构 ：适用于需要高度可寻址、可缓存和良好连接性的场景，如 Web 应用、移动应用等。例如，一个电商网站的商品信息、用户信息等资源可以通过资源导向架构进行管理和访问。
• 大 Web 服务 ：适用于面向流程、中介分布式服务的场景，如企业级应用、政府应用等。例如，一个企业的供应链管理系统，涉及到多个部门和外部合作伙伴的服务调用，大 Web 服务可以更好地协调这些服务。

4.3 发展趋势对比

• 资源导向架构 ：随着 Web 技术的发展，资源导向架构越来越受到关注，尤其是 RESTful 架构的广泛应用。它强调简单性、可扩展性和灵活性，符合现代 Web 应用的发展趋势。
• 大 Web 服务 ：虽然大 Web 服务在企业级应用中仍然有一定的市场，但由于其复杂性和互操作性问题，发展速度相对较慢。未来，大 Web 服务可能会与资源导向架构相互融合，取长补短。

5. 总结与建议

5.1 总结

资源导向架构和大 Web 服务是两种不同的 Web 服务范式，各有优缺点。资源导向架构基于 Web 的本质，充分利用 HTTP 特性，具有良好的可寻址性、可缓存性和链接性；而大 Web 服务则更侧重于面向流程的分布式服务，试图解决复杂业务场景下的问题。

5.2 建议

• 对于开发者 ：
  • 如果开发的是面向公众的 Web 应用，建议优先考虑资源导向架构，如 RESTful 架构，以提高系统的性能和可维护性。
  • 如果开发的是企业级应用，涉及到复杂的业务流程和多个系统的集成，可以考虑结合大 Web 服务和资源导向架构的优点，根据具体需求选择合适的技术。
• 对于企业 ：
  • 在选择 Web 服务技术时，要综合考虑业务需求、技术团队的能力、系统的可扩展性和维护成本等因素。
  • 加强对技术发展趋势的关注，及时引入新的技术和理念，提高企业的竞争力。

通过对资源导向架构和大 Web 服务的深入分析，我们可以更好地理解它们的特点和适用场景，从而在实际应用中做出更合理的选择。