[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrf] Proposed write-up for WSRF app notes
William and I have discussed WSRF-103 and would like to jointly propose the
following.
The proposed write-up for WSRF app notes for WSRF 103 included below in
this email was attempting to address the loss of information when portTypes
are aggregated together. As an alternative to having separate ports in the
service element we could
use the wsa:Action attribute on the wsdl11:input, output and fault child
elements of the wsdl11:operation element. This additional metadata in the
wsdl could be used to specify the additional information that is lost when
operations from multiple portTypes are copied into a 'most derived
portType'. To be precise I propose that we document in the app notes in
the 'interface aggregation' section the following:
...the style of WSDL 1.1 interface extension should be carried out in the
following fashion:
Define the new portType.
Copy all of the operation child elements from the portType being
extended, and paste them as child elements of the new portType
For each operation child element being copied:
If the wsa:Action attribute does not appear in the child input or
output element then
define the wsa:Action for the child input or output element as:
[target namespace]/[port type name]/[input|output name]
If the wsa:Action attribute does not appear in the child fault
elements then
define the wsa:Action for the child fault elements as:
[target namespace]/[port type name]/[operation
name]Fault:[fault name]
where
The [target namespace] is /definition/@targetNamespace of the
portType from which the operation was copied.
The [port type name] is the /definition/porttype/@name of the
portType from which the operation was copied.
The [input | output] is the name of the element as defined in WSDL
1.1 Section 2.4.5.
The [fault name] is the
/definition/porttype/operation/fault/@name.
The rest of the steps for copy and paste......
Additionally each of the abstract operations defined in the suite of
WSRF specifications
contains the following normative statement restricting the SOAPAction
URI.
If a SOAPAction URI is included in the transport portion of the Add
message, it MUST contain the URI
http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-xxxxxx-xx.wsdl/<portType>/<input
name>.
These statements should be changed to normatively define wsa:Action to
align with the above appnotes.
The wsa:Action MUST contain the URI
http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-xxxxxx-xx.wsdl/<portType>/<input
name>.
Regards,
Tom Maguire and William Vambenepe
"Vambenepe, William N" <vbp@hp.com> wrote on 03/30/2005 08:20:29 PM:
> 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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]