Proposed write-up for WSRF app notes

["Vambenepe, William N" <vbp@hp.com>]

Hi all,

During the last conf call, I took an action item to write up a proposed
addition to the App Notes to explain a way to offer Web services that
compose portTypes other than the copy/paste approach currently described
in the App Notes. This email contains my proposal. This proposal also
implies some rewording in 3.1 of the App Notes to make 3.1 overall
independent of the approach taken and list two approaches (so, remove
the concept of most-derived interface from the introduction section of
3.1): the copy/paste one as represented by 3.1.1.1 to 3.1.1.3 and the
service-level composition as presented below. Note that the editors
should probably extract the resourceProp document aggregation
instructions out of the copy/paste method of portType aggregation as the
resource properties document aggregation is actually shared between the
copy/paste and the service-level methods of portType aggregation. Also,
this would require modifying the last paragraph of section 1.1.1 of
WS-RP to talk about services that implement more than one portType
rather than using cut/paste for manual aggregation.




Service-level aggregation

WSDL 1.1 defines a service element as a sequence of ports. A service
that implements multiple portTypes can be represented in WSDL by a
service element containing ports implementing the portTypes implemented
by the service. This section defines how to do so in an interoperable
way. It is important to note that this mechanism (just like the
copy/paste mechanism also describe in this document) is only available
if all the operations in all the portTypes implemented by a given
service use a different element QName for their input message.

Here is an example of a WSDL document created using this approach. This
example corresponds to the case where the described service implements
both a portType of local name A and targetnamespace http://foo.com and a
portType of localname B and targetnamespace http://bar.com.

<definition targetnamespace="http://myNS.com/";
   xmlns:tns="http://myNS.com/";
   xmlns:foo="http://foo.com";
   xmlns:bar="http://bar.com";
 
xmlns:wsrp="http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-ResourceProp
erties-1.2-draft-06.wsdl">

   <import namespace="http://foo.com"/>
   <import namespace="http://bar.com"/>
   <import
namespace="http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-ResourcePrope
rties-1.2-draft-06.wsdl"/>

   <binding name="bindingA" type="foo:A">
      ...
   </binding>

   <binding name="bindingB" type="bar:B">
      ...
   </binding>

   <binding name="bindingWSRP" type="wsrp:GetResourcePropertyDocument">
      ...
   </binding>

   <service name="myService">

      <port name="PortA" binding="tns:bindingA">
         <soap:address location="http://myServer/myEndpoint"/>
      </port>
      <port name="PortB" binding="tns:bindingB">
         <soap:address location="http://myServer/myEndpoint"/>
      </port>
      <port name="PortWSRP" binding="tns:bindingWSRP">
         <soap:address location="http://myServer/myEndpoint"/>
      </port>
   </service>

</definition>

Here are the best practices defined to allow the service-level
aggregation of interfaces. These best practices are recommended whenever
a service element contains a port implementing a WSRF-defined portType
(in this example the "wsrp:GetResourcePropertyDocument" portType):

- The fact that several ports are part of the same service element means
that they provide access to the same WS-Resource.

- All the resource properties defined by any of the portTypes
implemented by the ports in the service are resource properties of the
WS-Resource. The aggregate resource properties document is created using
the rules for resource properties documents specified in the copy/paste
aggregation method.

- In the case where resource properties are defined but no operation is
defined by the associated portType, this is simply represented by a
binding for an empty portType and a port for this service. As described
by WS-ResourceProperties, the resource properties document defined by
this portType is provided by the portType.

- The best practice to create an EPR that addresses such a Web service
is to make use of the optional "wsa:ServiceName" element to provide the
QName of the service element but not to use the optional PortName
attribe of the ServiceName element.

Regards,

William