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

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 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