站内搜索: 请输入搜索关键词

当前页面: 开发资料首页 → J2EE 专题 → 手工创建的 SOAP 消息中命名空间的处理

手工创建的 SOAP 消息中命名空间的处理

摘要: 深入理解 WSDL 如何映射到 SOAP。在一般环境下，无须考虑 SOAP 消息中的命名空间。然而，在某些情况下，就必须要考虑这个问题。您可能需要手工创建 SOAP 消息，并在没有其它工具辅助下处理命名空间的问题。本文将专门针对这些情况来解决相关问题。
学习如何将 WSDL 映射到 SOAP
Russell Butek
Web 服务顾问, IBM
2005 年 5 月 03 日


引言
在典型的 Web 服务场景中，通常使用工具技术来处理命名空间的所有细微差别。但是有些时候，特别是在使用 SAAJ（SOAP with Attachments API for Java）为特定的 Web 服务构造 SOAP 消息时，您必须自己处理命名空间问题。在没有任何工具辅助的情况下构造消息――或是部分消息时――可以使用该技巧。

虽然命名空间看似复杂，但您真正只需要掌握的是以下一份简短的规则清单：

如果 WSDL 样式为 RPC，那么可在 WSDL 绑定的 wsdlsoap:body 元素中查看命名空间。
如果 wsdlsoap:body 有命名空间属性（且 Web 服务互操作性组织（WS-I）的 Basic Profile（参见参考资料部分）需要该属性用于 RPC 样式），那么这就是 SOAP 消息中操作元素的命名空间。
如果 wsdlsoap:body 没有命名空间，那么该操作元素不符合要求。
对于数据元素而言：
如果元素通过根元素（不是根类型）定义，那么它的命名空间就是根元素的命名空间；
如果元素不是通过根定义的，那么该元素不符合要求（对于该规则的说明请参见以下 elementFormDefault 部分的讨论。）
这些都是简单的规则，但如同大多数规则一样，需要对其进行少许说明。本文的其余部分将展示使用这些规则的各类实例。

有两种常用类型的 Web 服务描述语言（WSDL）文件： RPC/literal 和 document/literal 封装。当然还有其它的类型，但在本文中只包含这两种。（各类 WSDL 的详细内容参见文章“我应该使用哪种样式的 WSDL？”――参见参考资料。）

RPC/literal WSDL
清单 1 中的 RPC/literal WSDL 有三个操作：op1、op2 和 op3。注意 WSDL 文件中用粗体强调的不同命名空间。

清单 1. RPC/literal WSDL
<?xml version="1.0" encoding="UTF-8"?>
    targetNamespace="http://apiNamespace.com"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:tns="http://apiNamespace.com"
    xmlns:data="http://dataNamespace.com"
    xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/">
  
            targetNamespace="http://refNamespace.com"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:tns="http://refNamespace.com">
      
    
            targetNamespace="http://dataNamespace.com"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ref="http://refNamespace.com"
        xmlns:tns="http://dataNamespace.com"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      
      
        
          
          
        
      
            "true" type="tns:Data"/>
      
        
          
        
      
    
  
  
    
  
  
    
  
  
    
  
  
    
  
  
    
    
  
  
    
  
  
    
      <input message="tns:op1Request"/>
      
    
    
      <input message="tns:op2Request"/>
      
    
    
      <input message="tns:op3Request"/>
      
    
  
  
        "http://schemas.xmlsoap.org/soap/http"/>
    
      
      <input>
                "http://apiNamespace.com" use="literal"/>
      </input>
      
                "http://apiNamespace.com" use="literal"/>
      
    
    
      
      <input>
                "http://op2Namespace.com" use="literal"/>
      </input>
      
                "http://op2Namespace.com" use="literal"/>
      
    
    
      
      <input>
        
      </input>
      
        
      
    
  
  
        "Sample">
            "http://localhost:9080/RPCNamespaces/services/Sample"/>



WS-I 遵从性
WS-I（参见参考资料）为 WSDL 定义遵从性标准。从两个方面来讲，op3 不遵从 RPC/literal WSDL：它并不在绑定的 wsdlsoap:body 中定义命名空间；它的消息部分引用了元素，而不是类型。在此提出是为了展示可以用 WS-I 的 Basic Profile 解决的一些命名空间问题。


查看用于每个操作的绑定的 wsdlsoap:body 元素中的命名空间。op1 和 op2 是规则 1.1 的实例（参见以下有关 SOAP 消息的内容）。op3 是规则 1.2 的实例。op1 展示了使用 targetNamespace 的常规实例――在这种情况下是“http://apiNamespace.com”――作为该操作的命名空间，但是这仅仅是通常情况。op2 使用的命名空间将不会在 WSDL 中的其他任何地方被使用。op3 无需定义任何命名空间。

清单 2、3 和 4 分别展示了 op1、op2 和 op3 的 SOAP 消息。注意消息中用粗体强调的命名空间。

清单 2. op1 的 RPC/literal 请求/响应 SOAP 消息
"http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
         1
         2
      
    
  


"http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
        10
        20




在上文中已经提及，清单 2 中的 SOAP 消息遵从规则 1.1。op1 的命名空间为“http://apiNamespace.com”。这些消息同样遵从规则 2.2。所有参数数据都不通过根元素定义，仅仅是根类型――数据――以及它的子元素。既然没有使用根元素，那么这些元素都是不合要求的。

清单 3. op2 的 RPC/literal 请求/响应 SOAP 消息
                        "http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
        3
        4
      
    
  


"http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
        300
        400




op1 和 op2 消息中的唯一真正差别（比较清单 2 和 清单 3）是：op2 的消息说明了可以使用任意选择的命名空间；无需使用 WSDL 定义的 targetNamespace。

清单 4. op3 的 RPC/literal 请求/响应 SOAP 消息
                        "http://schemas.xmlsoap.org/soap/envelope/">
  
    
            "http://dataNamespace.com">
        5
        6
      
      
                "http://refNamespace.com">7
      
    
  


"http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
        7




op3 和其它两个操作区别很大。首先，没有定义命名空间，因此根据规则 1.2， 和 标签都是不合要求的。（注意：请记住 op3 不遵从 WS-I――参见 WS-I 遵从性部分）。

第二，名为 in1 的部分是根元素而不是根类型。由于它是元素部分，因此它的名称被元素名称 DataElem 取代。由于使用了元素名称，则根据规则 2.1，必须使用元素的命名空间“http://dataNamespace.com”。

最后，规则 2.1 再次为 in2 的类型元素而调用。in2 引用了根元素：RefDataElem。该元素用其它命名空间定义：“http://refNamespace.com”。

document/literal 封装的 WSDL

清单 5 中的 WSDL 和清单 1 中的 WSDL 是等价的。它是 document/literal 封装而不是 RPC/literal。为这个 WSDL 而生成的 Java API 和为 RPC/literal WSDL 生成的 Java API 是相同，但它们的 SOAP 消息可能还是有些差别。命名空间再次用粗体标出。

清单 5. document/literal 封装的 WSDL
<?xml version="1.0" encoding="UTF-8"?>
    targetNamespace="http://apiNamespace.com"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:tns="http://apiNamespace.com"
    xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/">
  
            targetNamespace="http://refNamespace.com"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:tns="http://refNamespace.com">
      
    
            targetNamespace="http://dataNamespace.com"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ref="http://refNamespace.com"
        xmlns:tns="http://dataNamespace.com"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      
      
        
          
          
        
      
      
      
        
          
        
      
    
            targetNamespace="http://apiNamespace.com"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:data="http://dataNamespace.com"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      
      
        
          
            
          
        
      
      
        
          
            
          
        
      
      
        
          
            
          
        
      
      
        
          
            
          
        
      
      
        
          
            
            
          
        
      
      
        
          
            
          
        
      
    
  
  
    
  
  
    
  
  
    
  
  
    
  
  
    
  
  
    
  
  
    
      <input message="tns:op1Request"/>
      
    
    
      <input message="tns:op2Request"/>
      
    
    
      <input message="tns:op3Request"/>
      
    
  
  
        "http://schemas.xmlsoap.org/soap/http"/>
    
      
      <input>
                "http://apiNamespace.com" use="literal"/>
      </input>
      
                "http://apiNamespace.com" use="literal"/>
      
    
    
      
      <input>
                "http://op2Namespace.com" use="literal"/>
      </input>
      
                "http://op2Namespace.com" use="literal"/>
      
    
    
      
      <input>
        
      </input>
      
        
      
    
  
  
    
            "http://localhost:9080/Wrapped/services/Sample"/>



对于 op1 而言，用于 document/literal 封装服务的 SOAP 消息和用于 RPC/literal 服务的 SOAP 消息是相同的。（参见 清单 2）。这是最常见的一类 document/literal 封装操作。请注意此时遵从的是规则 2.1 而不是规则 1.1；命名空间是从元素而不是从 wsdl:soapbody 获得。请注意 WSDL 中的约定，封装元素和 WSDL 自身一样，都是用相同的命名空间定义：“http://apiNamespace.com”。它们可以用任意的命名空间定义，根据该约定，document/literal 封装的消息和 RPC/literal 消息是相同的。

op2 的 document/literal 封装的 SOAP 消息如清单 6 所示。

清单 6.op2 的 Document/literal 封装的请求/响应 SOAP 消息

                        "http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
        3
        4
      
    
  


"http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
        300
        400



WS-I 遵从性
WS-I 要求 document/literal 绑定不应在其 wsdl:soapbody 中拥有命名空间属性。所以 op1 和 op2 都不符合要求。我在 IBM&reg; WebSphere&reg; Studio Application Developer 中运行该 WSDL，IBM&reg; WebSphere&reg; Studio Application Developer 接受不合要求的 WSDL，但可通过忽略任何 wsdl:soapbody 命名空间来强制符合 WS-I。


从 op2 的 document/literal 封装的消息可以更明显的看出，您遵循的是规则 2.1 而不是规则 1.1。此时完全忽略了绑定的 wsdl:soapbody 中的命名空间。

最后，对比 RPC/literal op3 的 SOAP 消息（清单 4）和 document/literal 封装的 op3 SOAP 消息（清单 7）。和 op2 一样，唯一的差别是 op3 的命名空间。 RPC 版本没有命名空间，但是 document 版本有命名空间；按照规则 2.1，如同其它所有的 document 消息一样，它从元素的命名空间来获取命名空间。

清单 7. op3 的 Document/literal 封装的请求/响应 SOAP 消息

                        "http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
        5
        6
      
      
                "http://refNamespace.com">7
      
    
  


"http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
                "http://refNamespace.com">7



关于缺省命名空间
您可以使用缺省命名空间来取消对前缀的需求。例如，如清单 8 所示，e 和 f 都在缺省命名空间中，此时定义命名空间为 urn:default；e 在缺省命名空间中的原因是因为缺省命名空间定义在 e 上，且 f 在其中的原因是因为 f 是 e 的子元素。

清单 8. 缺省命名空间使用实例



以下是一些建议：在实例数据中不要使用缺省命名空间。

如果使用缺省命名空间，在从上下文中取出某些内容时，例如――那么此时根本不知道该元素是否符合要求，或者该元素是否已通过某父元素定义为符合要求。
如果想使子元素符合要求，则必须引入空命名空间。例如，在清单 9 中，e 在 urn:default 命名空间中，且 f 通过看起来有些奇怪的方式，被定义为不合要求。

清单 9. 缺省命名空间中不合要求名称的实例



elementFormDefault="qualified"
可对命名空间产生影响的模式属性是 elementFormDefault。该属性的缺省设置是“unqualified”，到目前为止您已经看到的，子元素是不合要求的。但是如果您将 elementFormDefault="qualified" 添加到 document/literal 封装的 WSDL 中的所有模式中，那么消息中所有的元素将通过其父元素的命名空间而被定义为符合要求。例如，清单 10 包含了 op3 操作的 document/literal 封装的消息，该消息来自清单 5 中的 WSDL，此时 elementFormDefault 是符合要求的。通常，您不希望使用 elementFormDefault="qualified" 属性，因为它会使消息变得臃肿。但是在一年甚至更久以前，在各厂商之间存在着互操作性问题，通过设置该属性有时可以解决这些问题。

清单 10.使用 elementFormDefault="qualified" 的 op1 Document/literal 封装请求/响应 SOAP 消息
                        "http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
                "http://dataNamespace.com">1
                "http://dataNamespace.com">2
      
    
  


"http://schemas.xmlsoap.org/soap/envelope/">
  
    
      
                "http://dataNamespace.com">10
                "http://dataNamespace.com">20



结束语
在一般环境下，无须考虑 SOAP 消息中的命名空间。然而，在某些情况下，例如，必须手工创建 SOAP 消息，就必须予以考虑。此时，您必须对 WSDL 如何映射到 SOAP 有深入的了解。如果按照本文中的规则操作，您就可以用合适的命名空间手写 SOAP 消息，并且不会出现问题。

参考资料

您可以参阅本文在 developerWorks 全球站点上的 英文原文。


查阅 W3C 的 SOAP with Attachments 规范。


阅读文章“我应该使用哪种样式的 WSDL？”（developerWorks，2003 年 10 月），了解 document/literal 封装的相关知识。


查阅 WSDL 规范 Web 服务描述语言 (WSDL) 1.1。


了解更多关于 IBM 和 WS-I 的内容。


查阅 XML Schema Primer。


浏览 Web Services Interoperability（WS-I） 组织的 Web 页面。


Java API for XML-Based RPC (JAX-RPC) Downloads & Specifications 提供 JAX-RPC 1.1 规范的链接。


访问 Developer Bookstore 以获取技术书籍的详细清单，其中有大量有关 Web 服务的文章。


通过参与 developerWorks blogs 加入 developerWorks 社团。


IBM developerWorks 组在全世界范围内有大量的技术简报，您可以免费查阅。


需要更多资料？developerWorks 的 SOA 和 Web 服务专区有大量信息丰富的文章，以及关于开发 Web 服务应用程序的初级、中级和高级教程。


关于作者
Russell Butek 是一名 IBM Web 服务顾问。他是 IBM WebSphere Web 服务引擎的开发人员之一，也是 JAX-RPC Java Specification Request（JSR）专家组的成员。Russell Butek 的工作涉及 Apache 的 AXIS SOAP 引擎的实现，使 AXIS 1.0 符合 JAX-RPC。之前，他曾是一名 IBM CORBA ORB 的开发人员，也是许多 OMG 任务组的 IBM 代表，其中包括在可移植式拦截器任务组中担任要职。


↑返回目录
前一篇: JDO、EJB/CMP、Hibernate和Amber的比较
后一篇: 使用 Web Service Appender for Log4j 管理日志纪录