[dais-wg] DAIS mapping and WSRF embodiments

[Simon Laws]

I've been thinking about the WS Resource document [1] embodiments and 
their impact on the mapping of the DAIS interfaces. Five embodiments are 
described;

1 ? WS Addressing using reference properties embodiment
2 ? WS Addressing without using reference properties embodiment
3 ? WSDL 1.1 service element embodiment
4 ? WSDL 1.1 binding element embodiment
5 ? WS Message Delivery embodiment

The focus of these embodiments is on how the information required to 
discriminate a resource is relayed from the service consumer to the 
service itself. The underlying assumption of WSRF is that resource 
discrimination information is separate from the application message being 
transferred. 

This assumption is evident in the messages defined by WS Resource 
Properties as they don't explicitly include resource discrimination 
information. For example, GetResourceProperty includes just the name of 
the resource property being retrieved; the resource discriminator is 
expected to flow in accordance with one of the embodiments. 

The DAIS mappings document [2] discusses different approaches that the 
DAIS working group could take in mapping its interfaces to WSDL. One of 
these approaches is WSRF. The other significant approach promotes the 
inclusion of resource discriminator information within application 
messages. 

We are in a position where we must decide whether to include resource 
discriminator information within DAIS defined messages or not. Or else 
define two sets of messages that satisfy the two mapping approaches. The 
definition of two sets of messages is not an attractive option. 

Currently the DAIS specifications present a mapping to WSDL which takes 
the WSRF approach. Following the GGF12 session we had on this subject I 
have been pondering if the WSRF embodiments provide a mechanism for 
satisfying both approaches. 

Using WS Resource Properties as an example the WSDL says (this may be 
little out of date)... 

... 
<xsd:element name="GetResourceProperty" type="xsd:QName" /> 

<xsd:element name="GetResourcePropertyResponse" > 
   <xsd:complexType> 
      <xsd:sequence> 
         <xsd:any minOccurs="0" maxOccurs="unbounded" /> 
      </xsd:sequence> 
   </xsd:complexType> 
</xsd:element> 
... 
<wsdl:message name="GetResourcePropertyRequest"> 
   <wsdl:part name="GetResourcePropertyRequest" 
element="wsrp:GetResourceProperty" /> 
</wsdl:message> 

<wsdl:message name="GetResourcePropertyResponse"> 
   <wsdl:part name="GetResourcePropertyResponse" 
element="wsrp:GetResourcePropertyResponse" /> 
</wsdl:message> 
... 
<wsdl:portType name="GetResourceProperty"> 
    <wsdl:operation name="GetResourceProperty"> 
       <wsdl:input name="GetResourcePropertyRequest" 
                             message="wsrpw:GetResourcePropertyRequest" /> 

       <wsdl:output name="GetResourcePropertyResponse" 
                             message="wsrpw:GetResourcePropertyResponse" 
/> 
       ?
     </wsdl:operation> 
</wsdl:portType> 

As already discussed these messages do not define how the resource, for 
which properties are being requested, is identified. Embodiment 1 [1] 
relies on the WS Addressing specification and says that the information 
required to discriminate the resource will be included in the reference 
property of an EPR that references the service and resource in question. 

Embodiments 3 and 4 rely only on existing WSDL 1.1 features. In particular 
embodiment 4, WSDL 1.1 binding element embodiment, uses the binding 
element to associate resource discriminator information with the message 
header. For example, the information required is specified as an extra 
message 

<wsdl:message name="CustomHeader"> 
        <wsdl:part name="ResourceIdentifier" element="dais:ResourceId"/> 
</wsdl:message> 

The following binding associates the new message with the existing message 
header

<wsdl:binding name="DaisEmbodiment4Binding" type=
"dais:DatabaseDataService"> 
            <wsdlsoap:binding style="document" transport="
http://schemas.xmlsoap.org/soap/http"/> 
            <wsdl:operation name="GetResourceProperty"> 
              <wsdlsoap:operation soapAction=""/> 
              <wsdl:input name="GetResourcePropertyRequestRequest"> 
                <wsdlsoap:header message="dais:CustomHeader" part=
"ResourceId" use="literal"/>               
                <wsdlsoap:body use="literal"/> 
              </wsdl:input> 
              <wsdl:output name="GetResourcePropertyResponse"> 
                <wsdlsoap:body use="literal"/> 
              </wsdl:output> 
                ... 
            </wsdl:operation> 
</wsdl:binding> 

How tooling interprets this may vary but it indicates that it is the 
responsibility of the client (either the application or infrastructure 
code) of the service to introduce the specified resource discriminator 
information into the header of the message. 

This example can be extended to include a DAIS specified message.

<wsdl:operation name="SQLExecute"> 
        <wsdl:input name="SQLExecuteRequest" message=
"wsdair:SQLExecuteRequestMessage" /> 
        <wsdl:output name="SQLExecuteResponse" message=
"wsdair:SQLExecuteResponseMessage" /> 
</wsdl:operation> 
.. 
 
<wsdl:binding name="DaisEmbodiment4Binding" type=
"dais:DatabaseDataService"> 
            <wsdlsoap:binding style="document" transport="
http://schemas.xmlsoap.org/soap/http"/> 
            <wsdl:operation name="GetResourceProperty"> 
              <wsdlsoap:operation soapAction=""/> 
              <wsdl:input name="GetResourcePropertyRequestRequest"> 
                <wsdlsoap:header message="dais:CustomHeader" part=
"ResourceId" use="literal"/>               
                <wsdlsoap:body use="literal"/> 
              </wsdl:input> 
              <wsdl:output name="GetResourcePropertyResponse"> 
                <wsdlsoap:body use="literal"/> 
              </wsdl:output> 
                ... 
            </wsdl:operation> 
            <wsdl:operation name="SQLExecute"> 
              <wsdlsoap:operation soapAction=""/> 
              <wsdl:input name="SQLExecuteRequest"> 
                <wsdlsoap:header message="dais:CustomHeader" part=
"ResourceId" use="literal"/>               
                <wsdlsoap:body use="literal"/> 
              </wsdl:input> 
              <wsdl:output name="SQLExecuteResponse"> 
                <wsdlsoap:body use="literal"/> 
              </wsdl:output> 
            </wsdl:operation> 
</wsdl:binding> 

This approach allows the DAIS working group to build one set of messages 
without regard for the resource discriminator and then introduce the 
resource discriminator at bind time. I can also support other embodiments, 
for example, "3.1 WS Addressing Using Reference Properties" without 
changing the messages that we have designed in DAIS. 

Thoughts?

Simon Laws
IBM Hursley - Emerging Technology Services

[1]  Web Services Resource 1.2 - 
http://www.oasis-open.org/committees/download.php/9547/wsrf-WS-Resource-1.2-draft-01.doc

[2] Scenarios for mapping DAIS concepts - 
http://forge.gridforum.org/projects/dais-wg/document/Scenarios_for_Mapping_DAIS_Concepts/en/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20041123/0f94a863/attachment.html