WebService扩展

1. 服务发布和查询

1.1 概念

SOAP、WSDL、XML Schema 已经可以完成点到点的调用，但点到点的调用不能完全发挥面向服务的特点

graph LR
    subgraph 点到点的调用不能完全发挥面向服务的特点
    A(SOAP);
    B(WSDL);
    C(XML Schema);
    D{点到点的调用};
    A & B & C --- D;
    end

所以引入第三方（即服务注册），UDDI 是在 Web Service 服务栈中间标准用来对于服务注册进行支撑的协议。

1.2 作用

  • UDDI 被用来提供发布和查找 Web Service 的元服务。它可以用来针对丰富的元信息进行查找

  • UDDI 采用 XML 格式，来存放注册 Web Service 的描述性息，主要提供以下信息：

  1. WHO ：业务的基本信息（谁提供服务）
  2. WHAT ：分类信息（服务完成哪些功能）
  3. WHERE ：注册信息（哪里完成服务的调用）
  4. HOW ：关于服务接口的注册引用及其它属性（采用什么方式访问）
  • UDDI 使用注册实体记录 Web Service 的发布信息，注册实体可分为三类：
  1. 百页 ：关于名称、地址、具体联系方式等信息
  2. 黄页 ：针对业务或服务进行分类的信息
  • 行业 ：NAICS
  • 产品/服务 ：UNSPSC
  • 位置 ：ISO 地理分类标准
  1. 绿页 ：服务中的技术性信息

1.3 UDDI 结构

  • UDDI 包含 5 个主要元素（都使用 XML Schema 来正式表达其数据结构）：
  1. businessEntity ：商业实体的信息及其提供的服务
  1. businessService ：商业实体所提供的服务
  1. bindingTemplates ：如何调用一个服务
  1. tModel（Technical Models）：特定概念和结构（主要是对于绿页的抽象）
  1. publisherAssertion ：表达商业关系
  • UDDI 工作流程

1.4 Web Service 发布和查询

  • Web Service 实现后（部署在通过网络能够访问的应用服务器），为了方便消费者使用，需要通过网络将服务发布在服务注册。

  • 服务注册需要为服务调用者提供用以发现服务提供者及其所提供的 Web Service 的相关信息（无需提供具体实现）：

  1. 服务名称
  2. 服务提供者名称
  3. 用来描述该服务的 WSDL 文件的 URL（作为服务合约的入口）
  4. 附加在白页信息以外的黄页信息
    【注】服务在发布时本质上只讨论当前 Web Service 完成的功能是什么、被设计用来解决什么问题、哪里可以调用到以及如何调用。
  • 服务消费者使用 UDDI 客户端来查询 UDDI 注册
    中的 Web Service 。

1.5 UDDI API

  • 对于分类、编目和管理 Web 服务，UDDI 注册库提供了一个标准方式，以便于能够发现和使用这些 Web 服务。
  1. 业务和提供者可以按标准方式使用 UDDI 来表示 Web 服务信息
  2. UDDI 使用 SOAP 作为它的传输层
  • UDDI API 是一个接口，可以接口封装在 SOAP 信封中的 XML 消息。
  1. 所有的 UDDI 交互都使用请求/相应模式
  2. 可以使用查询 API 来搜索和读取 UDDI 注册库中的数据，并可使用发布 API 来添加、更新和删除 UDDI 注册库中的数据

【UDDI 发布 API】

  • 通过发布接口，企业可以存储和更新包含在 UDDI 注册库中的信息
  • 发布 API 支持 4 类操作
  1. 授权：客户端可以获得相应的访问权限、获取授权令牌、终止会话和授权令牌
  • get_authtoken ：将客户端记录到注册
  • discard_authtoken ：终止会话，并从注册库中删除客户
  1. 保存：客户端可以在 UDDI 中添加或更新信息
  2. 获取：可以获取客户端所发布的数据结构的概要数据
  3. 删除：客户端可以在 UDDI 中删除信息

【UDDI 查询 API】

  • UDDI 查询 API 有两类使用模式
  1. 浏览
  • 开发者可以使用浏览模式（发现 API 调用）来获取满足比较宽泛的查询标准的接入点、服务或者技术特性
  • 浏览模式中可是使用 find_business、find_relatedBusiness、find_service、find_binding 和 find_tModel 操作
  1. 下钻
  • 使用下钻模式（获取 API 调用）来获取更具体地信息
  • 下钻模式中，可以使用 get_businessDetail、get_BusinessDetailExt、get_serviceDetail、get_bindingDetail 和 get_tModelDetail 操作

2. WS-* 协议

2.1 概念

WS-* 协议是指除了核心标准外地扩展 Web Service 协议。不同公司和不同组织都在不断地提供对 Web Service 的扩展，大致可分类为以下几种：

2.2 具体分类

2.3 复合服务

  • 为什么需要复合服务：复用、灵活
  1. 有些服务是垂直的，有些服务是水平的。为保证复用性，某些垂直服务被设计为由水平服务构造而来
  2. 如果活动由服务实现，那么由活动构成的（商业）流程由复合服务实现
  • 如何实现复合服务
  1. 在传统编程环境中，调用子服务，再把编程单元封装成服务以供调用
  2. 采用标准协议的 XML 脚本描述服务组合方式（BPEL）

2.4 BPEL

2.5 Web Service 消息分发

  • 问题
  1. 为了正确处理，消息接收者必须具备识别所需要调用的 Web Service 的能力
  1. 由于在 WSDL 中没有定义，服务提供者在开发服务时，需要自己来区分消息的不同类型
  • 在单个地址上部署单个服务时，采用 XSD，为不同的服务能力的不同消息说明不同的 QNames
  • 在单个地址上部署多个服务时，必须在全局考虑所有服务中的消息类型
  1. 如服务提供者不能达成上述目标，尤其在使用通配类型（#any，#none）时，必须提供消息分发机制
  1. 在带状态的 Web Service 中，也需要消息分发机制，来识别同一个服务的不同实例
  • 解决
    引入 WS-Addressing 协议标准。

2.6 无状态和有状态的 Web Service

  • 无状态 Web Service
  1. 不获取和维护状态
  2. 无上下文
  3. 可扩展性好，容错性好
  4. 轻量级
  • 有状态 Web Service
  1. 为不同消费者服务，且提供个人化服务
  2. 持有状态
  3. 支持需要协作的复杂服务
  4. 需要更多编码和额外的处理资源
  5. 重量级

2.7 Web Service 资源框架（WSRF）

  • 包含四组用来通过 Web Service 接口访问内部状态的接口
  1. WS-ResourceProperties
  2. WS-ResourceLifetime
  3. WS-BaseFault
  4. WS-ServiceGroup

  • 支持资源属性的动态创建

  • 支持资源的销毁

  1. 立刻销毁
  2. 基于时间的计划销毁

2.8 协作过程

虽然在链路与链路中间通过授权机制和 HTTPS等等加密网络传输协议，确保在传输途中不会被篡改、不会被泄密，但由于整个 Web Service 是基于 XML，XML 是基于文本的，文本是基于明文的，导致中间节点也可以看到并且去篡改消息。

2.9 WS-Security

  • WS-Security Policy ：所有安全性协议都基于该框架
  • WS-Authorization ：在协议中解决验证问题
  • WS-Trust ：在该协议中解决信任问题
  • WS-SecureConversation ：在该协议中解决会话问题
  • WS-Privacy ：在该协议中解决隐私问题
  • WS-Federation ：在该协议中解决信任领域问题

2.10 WS-Coordination

  • WS-Coordination 用来发起、支持、完成多方参与、多消息的 Web Service 协作的通用机制
  • 定义了协作服务和协作上下文
  • 是协作 Web Service 交互的框架

其中主要包括 WS-Coordination 和 WS-Transaction 两大部分：

  • WS-Coordination
  • WS-Transaction
  1. WS-Atomic Transaction（WSAT）
  1. WS-Business Activity（WSBA）