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

["iwasa" <kiwasa@jp.fujitsu.com>]

I need a resolution for this discussion to finalize
editing a spec. (I think this was not agreed yet. Right?)

I think it is useful if it is included in a
spec as non-normative text/example in an appendix.
So we may be able to get feedback to the text also
for the future we need to define normative way to do so.

However if there are any concern to include this text
in the spec, the other way I could suggest is making it a separate
document and making it public on the TC web site as
technical note, use cases or something like that.

We can refer to the document, whenever people
need a non-normative way to describe these information for WSDL.
I can live with both. Which do we prefer?

Thanks,

Iwasa

----- Original Message ----- 
From: "Sunil Kunisetty" <Sunil.Kunisetty@oracle.com>
To: <wsrm@lists.oasis-open.org>
Sent: Wednesday, February 04, 2004 4:25 AM
Subject: Re: [wsrm] [REL-49]proposal for REL-49


>
>  Here is the Schema Type for the ServiceConfig element.
>
>
> <xsd:complexType name="ServiceConfigType">
>   <xsd:complexContent>
>    <xsd:extension base="tns:RmBaseType">
>     <xsd:sequence>
>      <xsd:element name="wsrm-guaranteed-delivery" minOccurs="0">
>       <xsd:complexType>
>        <xsd:complexContent>
>         <xsd:extension base="tns:wsrm-guaranteed-delivery-type">
>          <xsd:attribute name="usage" type="tns:UsageTypeValues"
use="optional"/>
>         </xsd:extension>
>        </xsd:complexContent>
>       </xsd:complexType>
>      </xsd:element>
>      <xsd:element name="wsrm-duplicate-elimination" minOccurs="0">
>       <xsd:complexType>
>        <xsd:complexContent>
>         <xsd:extension base="tns:EmptyType">
>          <xsd:attribute name="usage" type="tns:UsageTypeValues"/>
>         </xsd:extension>
>        </xsd:complexContent>
>       </xsd:complexType>
>      </xsd:element>
>      <xsd:element name="wsrm-message-order" minOccurs="0">
>       <xsd:complexType>
>        <xsd:complexContent>
>         <xsd:extension base="tns:EmptyType">
>          <xsd:attribute name="usage" type="tns:UsageTypeValues"
use="optional"/>
>         </xsd:extension>
>        </xsd:complexContent>
>       </xsd:complexType>
>      </xsd:element>
>     </xsd:sequence>
>    </xsd:extension>
>   </xsd:complexContent>
>  </xsd:complexType>
>  <xsd:complexType name="wsrm-guaranteed-delivery-type">
>   <xsd:complexContent>
>    <xsd:extension base="tns:EmptyType">
>     <xsd:sequence>
>      <xsd:element name="reply-patterns" type="tns:reply-patterns-type"/>
>     </xsd:sequence>
>    </xsd:extension>
>   </xsd:complexContent>
>  </xsd:complexType>
>  <xsd:complexType name="reply-patterns-type">
>   <xsd:complexContent>
>    <xsd:extension base="tns: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>
>  <xsd:simpleType name="UsageTypeValues">
>   <xsd:restriction base="xsd:string">
>    <xsd:enumeration value="optional"/>
>    <xsd:enumeration value="required"/>
>   </xsd:restriction>
>  </xsd:simpleType>
>  <xsd:complexType name="EmptyType">
>   <xsd:sequence/>
>  </xsd:complexType>
>
> Sunil Kunisetty wrote:
>
> >
> >  As per my AI from the last con. call, here are the new wordings
assuming that
> >  this  proposal is going to be non-normative
> >
> >  Tom & Jacques,
> >
> >  Feel free to pitch in and suggest any changes. I was very colloquial in
my wordings.
> >
>
  --------------------------------------------------------------------------
--------------------------------
> >  Annotating the Service WSDL with Reliable Messaging capabilities will
be
> >  very useful for the consumer of the Service as it can then leverage the
Reliable
> >  Messaging features correctly & effectively. While there is on going
work and
> >  research on how to specify such capabilities and policies, currently
there is no
> >  one widely accepted open standard which can be embraced right away.
While we
> >  can quickly cook up one such notation in this specification, it is felt
that such
> >  a notation should be defined in a different specification so that it
can be
> >  reused for all policy and capability declarations and not just Reliable
Messaging
> >  capabilities. Also, we don't want to overlay or compete when those
specifications
> >  becomes a widely accepted public standard. Hence, we would like to
propose
> >  a non normative solution to annotate the Service WSDL with Reliable
Messaging
> >  capabilities as an interim  solution.
> >
> >  The solution is based on defining a WS Reliable Messaging ServiceConfig
element.
> >  that can be used in the WSDL where ever element extensibility is
permitted such as
> >  at message,input,output,operation,binding,bindingOperation,port,service
levels.
> >
> >  The schema of the element is as follows:
> >
> >             <insert the schema here>
> >
> >   Vendors can define this element in their proprietary namespace or
define this
> >   element locally in the Service WSDL itself
> >
> >  The element consists of  3 optional sub-elements one each for the  3 RM
agreement
> >  items. All these sub-elements have an attribute by name " usage"
indicating the
> >  requirement of the corresponding  RM agreement item. It could take one
of the 2 possible
> >  values: required or optional. A required value indicates that
particular RM agreement
> >  MUST be used for that Web Service invocation. An optional value
indicates that
> >  the Consumer MAY elect to use that RM agreement  for this invocation.
> >
> >  Here is an example with the usage of this element.
> >
> >  <portType name="fooPortType">
> >   <operation name="fooBar">
> >     <tns:ServiceConfig >
> >         <wsrm-guaranteed-delivery usage="{required|optional}">
> >             <!-- List the reply patterns supported by this service.  -->
> >             <wsrm:reply-patterns
> >                    callback="{boolean}"
> >                    poll="{boolean}"
> >                    response="{boolean}"
> >              />
> >         </wsrm-guaranteed-delivery>
> >         <wsrm-duplicate-elimination usage="{required|optional}" />
> >         <wsrm-message-orderingusage="{required|optional}" />
> >      </tns:ServiceConfig>
> >      <input message="fooMessageIn" />
> >      <input message="fooMessageOut>
> >    </operation>
> > </portType>
> >
>
> --------------------------------------------------------------------------
------------------------------------
> >
> >
> >
> >  -Sunil
>