内容


初识 WS-I 基本概要 1.0

本概要的功能

Comments

2002 年 10 月 17 日,WS-I,即 Web 服务互操作性组织(Web Services Interoperability Organization)发布了它的 WS-I 基本概要 1.0 规范的第一个公开的工作组草案(Working Group Draft)。这个草案的发布象征着 WS-I 和基本概要工作组(Basic Profile Working Group)重要的里程碑,后者是最初为提供有关 WS-I 基本概要版本 1.0 的可交付包而特设的三个 WS-I 技术工作组之一。这个草案文档虽然尚未完成,但它的确代表着 WS-I 基本概要工作组的各成员已达成了共识。预计该文档还会进一步修改,以纳入针对该概要所施加的约束和要求的更多示例和更多详细的基本原理。

关于 WS-I


Web 服务互操作性组织是一个开放的业界努力,它是为提高跨平台、跨应用程序和跨编程语言的 Web 服务互操作性而专门设立的。这个组织把各种 Web 服务社区的领军人物聚拢起来响应客户的需求,他们在这里为开发可互操作的 Web 服务提供指导、推荐的实践以及支持资源。

WS-I 可交付包


所发布的这个草案是 WS-I 正在制定的与基本概要有关的一组相关材料中最先发布的。当完成时,可交付包连同 WS-I 基本概要将包含如下内容:

  • 用例和使用情形:用例和使用情形(分别)捕获 Web 服务使用的业务要求和技术要求。这些要求反映了支持 Web 服务解决方案的实际要求的种类,并提供了一个框架来演示 WS-I 概要中所描述的大纲。
  • 概要:概要由一组已命名的、有版本号的 Web 服务规范以及一组实现与互操作性大纲(这些大纲推荐了如何使用这些规范来开发可互操作的 Web 服务)组成。
  • 样本应用程序:样本应用程序演示了应用程序的实现,这些应用程序是按照 Web 服务使用情形和用例构建的,并且遵循一组给定的概要。相同的样本程序在多平台、多语言和多开发工具上的实现演示了实际运转中的互操作性,并为 Web 服务从业人员提供了方便实用的资源。
  • 测试工具:测试工具用于监视并分析与 Web 服务的交互,以确定所交换的消息是否遵循 WS-I 概要大纲。

WS-I 流程以定义用例开始,用例描述了如何应用 Web 服务来满足实际的业务需要。然后这些用例被分解为支持用例和设计模式的各个方面的使用情形。使用情形描述了在收集到的用例的上下文中利用 Web 服务的方法。这项工作帮助演示如何单独使用 Web 服务规范、如何协同使用 Web 服务规范或者同时使用两种方法。

用例分析为要定义的概要的需求提供了基础。每一个概要都基于一组特定的 Web 服务规范,每个规范都处于特定的版本和修订版级别。概要通过实现和互操作性大纲提供了这些规范和标准的更精确的用法,在许多情况下,这些大纲被捕获为一组测试断言,这组测试断言可用来验证给定的 Web 服务实现是遵循概要的。

然后 WS-I 为样本应用程序开发规范并实现这些样本应用程序。这些支持实现用多种编程语言进行开发(如 C#(C sharp)和 Java 编程语言)并被部署到多个平台上,包括 Java 2 平台,企业版(Java 2 Platform,Enterprise Edition(J2EE))和 .NET。这一步通过开发针对概要旨在处理的用例和使用情形的解决方案说明了概要互操作性。

最后,为了要关闭这个循环,WS-I 正在开发一些测试工具,以供 Web 服务从业人员使用,这些人员包括那些开发样本应用程序的 WS-I 工作组成员。这些工具用来验证由监视的 Web 服务所观察到的交互遵循该组大纲和定义互操作性概要的测试断言。

WS-I 基本概要 1.0


WS-I 基本概要规范定义了 Web 服务实例要遵循的内容。这个概要由以下一组非专有的 Web 服务规范组构成:

  • SOAP 1.1
  • WSDL 1.1
  • UDDI 2.0
  • XML 1.0(第二版)
  • XML 模式第 1 部分:结构(XML Schema Part 1: Structures)
  • XML 模式第 2 部分:数据类型(XML Schema Part 2: Datatypes)
  • RFC2246:传输层安全性协议版本 1.0(The Transport Layer Security Protocol Version 1.0)
  • RFC2459:因特网 X.509 公钥基础架构证书与 CRL 概要(Internet X.509 Public Key Infrastructure Certificate and CRL Profile)
  • RFC2616:超文本传输协议 1.1(HyperText Transfer Protocol 1.1)
  • RFC2818:TLS 上的 HTTP(HTTP over TLS)
  • RFC296:HTTP 状态管理机制(HTTP State Management Mechanism)
  • 安全套接字层协议版本 3.0(The Secure Sockets Layer Protocol Version 3.0)

概要给旨在提高互操作性的那些基本规范提供了约束和清晰说明。在概要不起作用的地方,基本规范就是合乎规范的。如果概要规定了需求或约束,它便会取代底层的基本规范。由概要施加的一些约束旨在限制、或要求可选的行为和功能,从而减少潜在的互操作性问题。提供有些约束和要求是为了清晰说明基本规范中的语言,这些语言可能是经常发生曲解的根源,这曲解也是导致互操作性问题的常见根源。

以下突出说明了由这个概要所施加的主要限制:

  • 不得使用 SOAP 编码
  • 需要使用针对 SOAP 的 HTTP 绑定
  • 对于 SOAP 故障(SOAP Fault)消息,需要使用 HTTP 500 状态响应
  • 需要使用 HTTP POST 方法
  • 需要使用 WSDL1.1 来描述 Web 服务的接口
  • 需要使用 WSDL SOAP 绑定的 rpc/literal 形式或 document/literal 形式
  • 不得使用请求-响应(solicit-response)操作和通知(notification)样式的操作
  • 需要合用 HTTP 和 WSDL SOAP 绑定扩展作为所需的传输
  • 需要使用对代表 Web 服务的 UDDI tModelI 元素的 WSDL1.1 描述

哪些与开发人员有关?


WS-I 基本概要 1.0 规范是个相当复杂的文档。您可能会问:“我开发 Web 服务是为了谋生,这个规范与我的工作有什么关系?我需要阅读并理解所有这些材料吗?”

本规范中的大多数内容针对的是从事 SOAP 处理器、WSDL 解析器、代码产生器及类似工具的特定于供应商的实现的平台基础架构和工具开发人员。这个规范体现了基本概要工作组各成员所达成的共识。由于工作组成员包括代表平台供应商和/或工具供应商的人(比如说我),所以您有理由把这个文档看作是那些工具和平台供应商的协同努力成果,这些供应商这样做是为了确保它们各自的产品将产生或托管可互操作的 Web 服务实例。这意味着在您可能需要熟悉该概要规范的所有内容时,有某些部分将是您在实现 Web 服务时需要着力注意的。

我们将研究该概要规范的每一个独立部分并讨论它与 Web 服务从业人员的关系。

WS-I 基本概要规范的第 4 部分讲述 SOAP 和 SOAP 的 HTTP 绑定的使用。因此,是那些编写 SOAP 处理器实现的开发人员而不是 Web 服务开发人员将对这部分最感兴趣。

第 5 部分是有关规范使用 WSDL 的,因此,Web 服务从业人员(特别是那些亲手编制他们的 WSDL 描述的人员)应对这部分很有兴趣。我们将在下面探讨这一部分中一些令人特别感兴趣的方面。

第 6 部分是关于使用 UDDI 的 Web 服务发现。这部分也应是 Web 服务从业人员的兴趣所在。这一部分描述了在 UDDI 注册中心注册和分类 Web 服务的规范方法。

第 7 部分讲述使用 HTTP/S 的 Web 服务的安全性,这部分也应是那些所开发的 Web 服务有安全性要求的 Web 服务从业人员所感兴趣。

编写符合 WS-I 的 WSDL


正如前面所讨论的那样,WS-I 基本概要 1.0 规范的第 5 部分讲述了规范地使用 WSDL 来描述 Web 服务。对于 Web 服务开发人员,在这个概要规范的各个部分中,第 5 部分可能他们最感兴趣的也是最重要的。它从解决与 WSDL 文档的结构和组合有关的问题开始。

第一个解决的问题是正确使用 wsdl:import 功能。wsdl:import 功能旨在以与使用 xsd:import 相同的方式用来从外部名称空间(例如,一个与正在导入的 WSDL 文档的 targetNamespace 属性值不同的名称空间。)导入定义。此外,WS-I 基本概要还把 <wsdl:import> 功能限制为只用来从另一个 WSDL 文档导入 WSDL 定义组件。这意味着您无法使用 <wsdl:import> 功能从 XSD 文件导入模式定义。

清单 1 - 3 显示了一些示例,这些示例演示了 <wsdl:import> 功能的不正确用法和正确用法。

清单 1:wsdl:import 的不正确使用

<definitions name="StockQuote"  
  targetNamespace="http://example.com/stockquote/wsdl"
    xmlns:sq="http://example.com/stockquote/sqTypes/" 
                ...
      xmlns="http://schemas.xmlsoap.org/wsdl/">   
      <import namespace="http://example.com/stockquote/sqTypes/"
               location="http://example.com/stockquote/sqTypes.xsd"/>            
               
      <message name="GetLastTradePriceInput">        
              <part name="body" element="sq:TradePriceRequest"/>    
      </message>
                     ...
</definitions>

清单 2:wsdl:import 的正确使用

<definitions name="StockQuote"    
  targetNamespace="http://example.com/stockquote/wsdl"   
  xmlns:sq="http://example.com/stockquote/sqTypes/"             
   ...   
  xmlns="http://schemas.xmlsoap.org/wsdl/">      
  <types>     
   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">      
    <xsd:import namespace="http://example.com/stockquote/sqTypes/"          
     schemaLocation="http://example.com/stockquote/sqTypes.xsd"/>     
    </xsd:schema>   
  </types>   
  <message name="GetLastTradePriceInput">      
   <part name="body" element="sq:TradePriceRequest"/>   
  </message>               
    ...
</definitions>

清单 3:wsdl:import 的另一个正确使用

<definitions name="StockQuote"     
 targetNamespace="http://example.com/stockquote/service/"   
 xmlns:sq="http://example.com/stockquote/sqDefs/"   
 xmlns:tns="http://example.com/stockquote/service/"   
 xmlns="http://schemas.xmlsoap.org/wsdl/">      
 
 <import namespace="http://example.com/stockquote/sqDefs/"        
  location="http://example.com/stockquote/stockquote.wsdl"/>  
  
 <service name="StockQuoteService">      
  <port name="StockQuotePort" binding="sq:StockQuoteSoap">           
   ....      
  </port>  
 </service>
</definitions>

正如我们在第一个示例中所看到的那样,wsdl:import 语句被不正确地用来从 XSD 文件导入模式定义:

http://example.com/stockquote/sqTypes.xsd

清单 23演示了 wsdl:import 和 xsd:import 功能的正确用法。

这个概要还对以什么顺序使用顶级 WSDL 元素进行了约束。具体说来,它要求 wsdl:import 元素(如果使用了这个元素的话)出现在所有其他顶级 WSDL 元素之前。然后是 <wsdl:types> 元素紧随其后,接着是 <wsdl:message> 元素、 <wsdl:portType> 元素、 <wsdl:binding> 元素和 <wsdl:service> 元素,后面这些元素可以根据需要出现任意次,并且出现顺序不限。

这个约束与规范中的许多其他约束相似,是以 W3C 工作组的决定为基础的,这些决定定义了针对 SOAP 和 WSDL 的各 Web 服务规范的下一个版本。基本概要工作组采用了某些由 W3C 工作组做出的决定,其原因是它们想以符合 W3C 工作组方向的方式解决已被标识出来的互操作性问题,W3C 工作组制定了 SOAP 和 WSDL 规范版本 1.2 的草案。这种办法旨在当这些规范达到了 W3C 推荐这一状态并且被纳入到随后的 WS-I 概要后,能有利于更平滑地过渡到这些规范的下一版本中。

清单 4是一个有正确顺序的 WSDL 文档。

清单 4:WS-I 基本概要 1.0 的格式良好的 WSDL

<definitions name="StockQuote"   
  targetNamespace="http://example.com/stockquote/service/"   
  xmlns:tns="http://example.com/stockquote/service/"   
  xmlns:sqt="http://example.com/stockquote/sqTypes/"   
  xmlns:sqd="http://example.com/stockquote/sqDefs/"   
  xmlns="http://schemas.xmlsoap.org/wsdl/">     
  
  <import namespace="http://example.com/stockquote/sqDefs/"           
   location="http://example.com/stockquote/stockquote.wsdl"/>     
   
  <types>    
   <schema targetNamespace="http://example.com/stockquote/sqTypes/"         
    xmlns="http://www.w3.org/2000/10/XMLSchema">           
     .......    
   </schema>   
  </types>              
  
  <message name="GetLastTradePriceInput">      
   <part name="body" element="sqt:TradePriceRequest"/>   
  </message>               
    ...   
    
  <service name="StockQuoteService">      
   <port name="StockQuotePort" binding="tns:StockQuoteSoap">           
    ....      
   </port>   
  </service>
</definitions>

拒绝 SOAP 编码


正如我们前面所讨论过的那样,WS-I 基本概要拒绝使用 SOAP 编码,其原因很大程度上在于 SOAP 编码已经被证明常常会导致互操作性问题。因此,WS-I 基本概要要求使用 WSDL SOAP 绑定的 RPC/literalDocument/literal形式。这个规范提供了大量的细节(这些细节描述了 SOAP 绑定扩展元素的正确使用)以确保对 SOAP 绑定的 RPC/literalDocument/literal 形式进行了一致的和可互操作的描述,从而确保用于生成代码的 WSDL 工具对于生成和/或消费的 SOAP 消息是可互操作的。

在这第一个公共草案中,规范的第 5.8 部分目前还没有附带示例,预计下一个修订版将会有许多示例,从而强化所施加的约束,让开发人员很容易就可理解这些约束。此外,生成的 WSDL 作为样本应用程序的一部分,将随基本概要一起交付,它也为开发人员提供一组具体的示例,这些示例演示了针对 RPC/literalDocument/literalSOAP 绑定描述的 SOAP 绑定 WSDL 扩展的正确用法。

当然,WS-I 想让它的测试工具(在可以得到这些工具时)能被开发人员用来测试他们的 WSDL 文档遵循该概要,而不是需要他们手工检查他们的 WSDL 是否符合 WS-I 基本概要规范的约束叙述和/或示例。

情形、样本应用程序和测试工具


并非只是 WS-I 基本概要工作组在其目标方向上取得了很大的进步。另外两个工作组以 WS-I 基本概要 1.0 规范早期的草案为基础,一直在开发它们自己的可交付包方面进行着艰苦的努力。情形和样本应用程序工作组(Scenarios and Sample Applications working group)已经设计并正积极开发将演示 WS-I 基本概要的各种功能的样本应用程序。

测试工具工作组(Testing Tools Working Group)在设计和开发他们的参考工具方面取得了重大进展,并且正在将在 WS-I 基本概要草案中定义的约束和要求转化成测试断言,这些断言将配置测试工具,Web 服务从业人员可以用这些工具来测试他们的 Web 服务实例和 WSDL 描述遵循概要。

期待在不久的将来见到这些工作组各自向公众发布的以供评议的成果。

展望 WS-I 基本概要 1.0


当然,WS-I 基本概要 1.0 仅仅是初露端倪。WS-I 计划开始致力于针对 Web 服务规范的许多概要的工作,以进一步充实协议栈。将来可能出现的概要包括安全性、编排和可靠的消息传递等等类似内容。当概要依托的各种规范成熟并稳定时,关于这些未来概要的工作就将要着手开展。WS-I 的目标是可以从这些基本概要创建复合的概要,从而能够组合各种功能(如基本通信(正如在基本概要中发现的一样)、安全性和可靠的消息传递)来满足业务要求。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=21629
ArticleTitle=初识 WS-I 基本概要 1.0
publish-date=10012002