OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.
-----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:

 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" >
            <!-- List the reply patterns supported by this service.  -->
        <wsrm-message-ordering />
     <input message="fooMessageIn" />
     <input message="fooMessageOut>
 Schema for such an element would be:
 <xsd:element name="ServiceConfig" type="wsrm:ServiceConfigType" />
 <!-- ServiceConfig WSDL Extensible Element Type -->
 <xsd:complexType name="ServiceConfigType">
   <xsd:extension base="wsrm:RmBaseType">
     <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:complexType name="wsrm-guaranteed-delivery-type">
   <xsd:extension base="wsrm:EmptyType">
     <xsd:element name="reply-patterns" type="wsrm:reply-patterns-type"  />
 <xsd:complexType name="reply-patterns-type">
   <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"/>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]