只有消息部分才能包含附件

　　请注意，在清单 1 中，绑定将一个 MIME 类型与一个消息部分进行了关联。这意味着所有附件必须是部分;例如，您不能将附件定义为 complexType 元素。这样的方法限制性很强，使附件的可用性降到了最低。

　　附件与 document/literal 包装模式

　　第三个问题是附件不符合行业当前对 WSDL 的 document/literal 包装模式的习惯用法。有些人认为附件完全不适合 document/literal 包装模式。我并不这样认为，但是无论我怎样想，目前尚没有任何规范尝试过让附件适应 document/literal 包装模式。

　　问题在于，在 document/literal 包装模式中，一条消息中只有一个部分，而部分必须引用一个 wrapper 元素。附件部分如何适应这个模型呢?它并不能适应。只有放宽对消息中可包含内容的规定，它才能够 适应，但是目前没有任何人尝试过正式地放宽此规定。

　　WS-I 的解决方案

　　WS-I 通过创建 XML 附件类型解决了所有这些问题。wsi:swaRef 在 WSDL“接口”中可见。wsi:swaRef 的位置并不局限于消息部分中，也可以为 complexType 元素。作为 XML 类型，wsi:swaRef 能很好地适应 document/literal 包装模式(此模式要求参数是 complexType 元素)。清单 2 是清单 1 的修改版本，其中使用 wsi:swaRefs 代替了标准的附件。请注意，我们还将清单 2 的 WSDL 转换为 document/literal 包装的 WSDL 了。

　　清单 2. 使用 WS-I 的 wsi:swaRef 附件类型的 WSDL

<definitions
   
   
    targetNamespace=”urn:attachment.tip”
    >
  <types>
    <schema
        targetNamespace=”urn:attachment.tip”
       
       
        >
      <import
          namespace=”http://ws-i.org/profiles/basic/1.1/xsd”
          schemaLocation=”http://ws-i.org/profiles/basic/1.1/xsd”/>
      <element name=”sendImage”>
        <complexType>
          <sequence>
            <element name=”image” type=”wsi:swaRef”/>
          </sequence>
        </complexType>
      </element>
      <element name=”sendImageResponse”>
        <complexType>
          <sequence/>
        </complexType>
      </element>
      <element name=”sendOctet”>
        <complexType>
          <sequence>
            <element name=”octet” type=”wsi:swaRef”/>
          </sequence>
        </complexType>
      </element>
      <element name=”sendOctetResponse”>
        <complexType>
          <sequence/>
        </complexType>
      </element>
    </schema>
  </types>
  <message name=”imageMsg”>
    <part name=”parameters” element=”tns:sendImage”/>
  </message>
  <message name=”imageResponseMsg”>
    <part name=”return” element=”tns:sendImageResponse”/>
  </message>
  <message name=”octetMsg”>
    <part name=”parameters” element=”tns:sendOctet”/>
  </message>
  <message name=”octetResponseMsg”>
    <part name=”return” element=”tns:sendOctetResponse”/>
  </message>

  <portType name=”AttachmentTip”>
    <operation name=”sendImage”>
      <input message=”tns:imageMsg”/>
      <output message=”tns:imageResponseMsg”/>
    </operation>
    <operation name=”sendOctet”>
      <input message=”tns:octetMsg”/>
      <output message=”tns:octetResponseMsg”/>
    </operation>
  </portType>

  <binding name=”AttachmentBinding” type=”tns:AttachmentTip”>
    <soap:binding style=”document”
                  transport=”http://schemas.xmlsoap.org/soap/http”/>
    <operation name=”sendImage”>
      <soap:operation soapAction=””/>
      <input>
        <soap:body use=”literal”/>
      </input>
      <output>
        <soap:body use=”literal”/>
      </output>
    </operation>
    <operation name=”sendOctet”>
      <soap:operation soapAction=””/>
      <input>
        <soap:body use=”literal”/>
      </input>
      <output>
        <soap:body use=”literal”/>
      </output>
    </operation>
  </binding>

  <service name=”AttachmentService”>
    <port name=”AttachmentTip” binding=”tns:AttachmentBinding”>
      <soap:address
          location=”http://localhost:9080/attachment/services/AttachmentTip”/>
    </port>
  </service>

</definitions>
 
　　从清单 2 可以看到，定义 wsi:swaRef 非常简单。其行为方式与其他基本 XML 类型相似。但在我看来，它过于简单了。与标准附件不同的是，并不知道附件的 MIME 类型。您只知道有一个附件。如果 WS-I 定义 wsi:swaRef 具有特定属性(例如，提供 MIME 类型的属性)，将会更有用;但是 WS-I 并不负责定义规范，而只是对相关内容进行阐明，因此在并不定义任何新内容时，会尽可能使其保持最小。