1. 服务发布和查询

1.1 概念

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

1
2
3
4
5
6
7
8
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)