RE: [wsrm] [REL-49]proposal for REL-49

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Sunil:

 

A few comments, which I don't see critical, but even if we keep the annotation

as you propose, we need to explicitly state which of the following semantics it has:

 

- It should be possible to express that only input messages are concerned by the RM features

even when attaching a service config annotation at service / port / op level, (i.e. without having to

"override" at message level, in order to exclude the output message.)

E.g. scope="input", (future versions will handle: scope="output", scope="input-ouput")

 

- The annotation you propose is not always about capability: in some cases the RM features *must* be used

by the client. In other words, the annotation may have different meaning

for each side. Consider the following cases, each gives the annotation a different meaning:

 

1. server capability (this is your service config I think): WS supports this RM feature if client asks for using it. 

Attribute: clientuse="possible".

 

2. client requirement: client must use the feature, because the WS implementation assumes it does

for a proper WS behavior (e.g. ordering required, when using repeatedly a monitoring operation)

Attribute:  clientuse="required".

 

3. server requirement: E.g. WS1 is a deployed pay-per-use WS, which will respond to users via requests

issued to users. The user then has to implement a "response" WSDL, describing a service WS2 that

supports these requests. So we may want to specify in the WSDL 2 that the WS implementation or

deployment  MUST support the RM feature, because the client (here the deployed WS1) will use it.

Attribute: serveruse="required" (or clientuse="possible"?)

 

Beyond this, it becomes user-specific (e.g. according to an SLA) and would require more advanced

policies or agreements attached to user ID.

 

Jacques

-----Original Message-----
From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
Sent: Tuesday, January 20, 2004 2:57 PM
To: wsrm@lists.oasis-open.org
Subject: Re: [wsrm] [REL-49]proposal for REL-49

 
 Here is my AI from the last F2F  to simply the proposal for REL-49.

 Salient points are:

• A non-normative proposal for annotating Service WSDL with WSRM capabilities
• Based on WSDL  extensibility element concept.
• Defines only one extensible schema element (ServiceConfig)
• This element could be used at any of the following WSDL levels:
  • message/input/output/operation/binding/bindingOperation/port/service
• This service element could be used inside any vendor specific policy elements or directly.

 Example of a <ServiceConfig> usage inside the operation 'foorBar'.

<portType name="fooPortType">
  <operation name="fooBar">
    <wsrm:ServiceConfig xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" >
 
        <wsrm-guaranteed-delivery>
            <!-- List the reply patterns supported by this service.  -->
            <wsrm:reply-patterns
                   callback="{boolean}"
                   poll="{boolean}"
                   response="{boolean}"
             />
        </wsrm-guaranteed-delivery>
        <wsrm-duplicate-elimination/>
        <wsrm-message-ordering />
     </wsrm:ServiceConfig>
     <input message="fooMessageIn" />
     <input message="fooMessageOut>
   </operation>
</portType>
 
 Schema for such an element would be:
 <xsd:element name="ServiceConfig" type="wsrm:ServiceConfigType" />
 <!-- ServiceConfig WSDL Extensible Element Type -->
 <xsd:complexType name="ServiceConfigType">
  <xsd:complexContent>
   <xsd:extension base="wsrm:RmBaseType">
    <xsd:sequence>
     <xsd:element name="wsrm-guaranteed-delivery"  type="wsrm:wsrm-guaranteed-delivery-type" minOccurs="0"/>
     <xsd:element name="wsrm-duplicate-elimination" type="wsrm:EmptyType" minOccurs="0"/>
     <xsd:element name="wsrm-message-order" type="wsrm:EmptyType" minOccurs="0"/>
    </xsd:sequence>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>
 <xsd:complexType name="wsrm-guaranteed-delivery-type">
  <xsd:complexContent>
   <xsd:extension base="wsrm:EmptyType">
    <xsd:sequence>
     <xsd:element name="reply-patterns" type="wsrm:reply-patterns-type"  />
    </xsd:sequence>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>
 <xsd:complexType name="reply-patterns-type">
  <xsd:complexContent>
   <xsd:extension base="wsrm:EmptyType">
    <xsd:attribute name="callback" type="xsd:boolean" use="optional"/>
    <xsd:attribute name="poll" type="xsd:boolean" use="optional"/>
    <xsd:attribute name="response"  type="xsd:boolean" use="optional"/>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

 
 -Sunil