(in rder to close Issue WSRF77) RE: [wsrf] an attemt to simplify, clarify and combine into one WSDL binding

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

Just to remind the TC that this proposal was not to add another issue :), but rather to close Issue WSRF77.

Comments?

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 

 

---

From: Sedukhin, Igor S
Sent: Wednesday, November 17, 2004 4:17 PM
To: wsrf@lists.oasis-open.org
Subject: [wsrf] an attemt to simplify, clarify and combine into one WSDL binding

3.3 WSDL 1.1 Embodiment

 

This embodiment is one in which WSDL 1.1 is used [WSDL11]. The form of a WS-Resource reference is a WSDL definitions element which contains exactly one WSDL service child element which, in turn, contains one or more WSDL port child elements each bound to the same portType element.

 

Rules of WSDL 1.1 [WSDL11] and any extensions thereof which appear in the reference MUST be followed in order to properly form messages containing resource identifiers and target them at the WS-Resource.

 

For example, policy attached to the WSDL definitions may indicate that X.509 certificate must appear in the WS-Security header. The certificate must be obtained by the requestor from the execution context or otherwise. Terefore, messages targeted at the WS-Resource will contain headers with required certificates which may be used as the resource identifiers by an implementation to distingish the resource targeted by the message.

 

Note that a form of a reference to a WS-Resource in this embodiment of WS-RAP does not necessarily contain a value of the resource identifier, however it 1) identifies what the resource identifier is (e.g. the fact that it is an X.509 certificate in the requestor’s context), and 2) specifies where in the message the value of the resource identifier has to appear (e.g. a <soap:header> WSDL SOAP binding extension element). The actual value of the resource identifier depends on the application specifics and the context in which the requestor runs. Therefore, it is possible to have one WS-Resource reference which when interpreted in each requestor/caller context will result in messages targeted to different resources. This is an application-context dependant form of a reference. See example in $3.3.1.

 

A simpler case of this embodiment which does specify the value of the resource identifier is the one where the resource identifier value is encoded in the contents of a WSDL port element of the WS-Resource reference. In case of SOAP binding, within the soap:address element. In this case, the address encoded within the WSDL port element contains both the address of the Web service endpoint and the resource identifier. See example in $3.3.2.

 

3.3.1 Header element example

The following is an example of a valid reference to a WS-Resource in this embodiment: 

<wsdl:definitions … xmlns:tns=”…” xmlns:my=”…”>

  <wsdl:message name=”custom”>

    <wsdl:part name=”hdr” element=”my:ResourceIdentifier”/>

  </wsdl:message>

  <wsdl:binding name=”SOAP” … >

    <wsdl:operation … >

      <wsdl:input>

        <soap:header message=”tns:custom” part=”hdr” use=”literal”/>

        <soap:body … > … </soap:body>

      </wsdl:input>

    </wsdl:operation>

  </wsdl:binding>

  <wsdl:service name=”svc”>

    <wsdl:port name=”SOAPHTTP” binding=”tns:SOAP”>

      <soap:address=”http://my.server.org/soap/http/listener”/>

    </wsdl:port>

  </wsdl:service>

</wsdl:definitions>

In this example, the requestor would need to understand how to form the contents of the my:ResourceIdentifier element before sending a SOAP message to the http://my.server.org/soap/http/listener address. The QName of this header element identifies the application semantics of the element. For example, semantics could be that the elemeent must contin a value of a primary key into a specific database table. Precisely how to form the contents of the header element is dictated by its application semantics, and it has to be known and implemented by the requestor. This specification does not make any assumptions as to what such application semantics could be. However, applications that understand the semantics of my:ResourceIdentifier element will be able to use this reference sucessfully.

 

3.3.2 Address example

The following is an example of a valid reference to a WS-Resource in this embodiment:

<wsdl:definitions … >

  <wsdl:service name=”svc”>

    <wsdl:port … >

      <soap:address=”http://www.example.com/R1”/>

    </wsdl:port>

  </wsdl:service>

</wsdl:definitions>

In this example, messages sent to http://www.example.com/R1 are, actually, sent to the endpoint of the Web service which provides access to the resource in this example identified by the string “R1”. Note that even though resource identifier does not appear within the SOAP envelope contained in messages sent when using this reference, it MUST appear in as part of the HTTP message (in the form of the URL).

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749