[REL-49]proposal for REL-49

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

 This proposal not only addresses the main issue as mentioned
in REL 49,
 but it also touches upon the client side config that was mentioned
in other
 issues.  I'd like to discuss this more at the F2F

 Salient points are:

• This should either be normative and optional (wrt to compliance) or should be made non-normative. Oracle prefers former.
• Has 2 different schema elements. <service-config> is defined for service side WSRM config to be used in the Service WSDL. <client-config> element is used for client side config to be used in vendor specific client property/config file.
• <service-config>
• Based  wsdl  extensibility elements concept.
• Per operation or per binding. Note that while wsdl 1.1 is ambiguous about extensible elements under portType/operation, BP does allow it.
• This extensible element can be either used in portType/operation or binding/operation. If it has to be shared by all bindings, then it could be used in the portType/operation [abstract part]. If this (wsrm usage) is per binding, then it can be defined only in the binding operation It can also be used at the binding level directly, if it is common for all the binding operations (note that extensibility elements are prohibited at the portType level though).
• This service element could be used inside any vendor specific policy elements or directly. If used directly, one could use the wsdl:required  (set to true) attribute, to enforce the config element..

  Once we finalize the schema, we could define them in the same schema
we are
  defining for the WSRM SOAP Headers and use the same namespace.

 Example of a <service-config> usage inside the operation 'foorBar'.

<portType name="fooPortType">
  <operation name="fooBar">

    <wsrm:service-config xmlns:wsrm="some URI" wsdl:required="true">
        <!-- Spec. version>
       <wsrm:version>1.0</wsrm:version>
        <!-- We can also have some kind of capability parameters

          <wsrm:batching-support>
                    {true|false}
          </wsrm:batching-support>

           <wsrm:piggyback-support>
                    {true|false}
           </wsrm:piggyback-support>
         -->

        <wsrm:guaranteed-delivery>
            <!-- List the reply patterns supported by this service.
                   Can have one or more such patterns -->
            <wsrm:reply-pattern>
                    Callback  <!—possible values are Response/Callback/Polling ->
            </wsrm:reply-pattern>
        </wsrm:guaranteed-delivery>

         <wsrm:duplicate-elimination>
                true
         </wsrm:duplicate-elimination>

          <wsrm:message-ordering>
                true
          </wsrm:message-oredering>
     </wsrm:service-config>
     <input message="fooMessageIn" />
     <input message="fooMessageOut>
   </operation>
</portType>
 

Client side config sample:

<wsrm:client-config xmlns:wsrm="some URI">
    <!-- No. of retries to send for non ack. messages  and return interval -->
     <wsrm:retry-config>
          <wsrm:retry-count>5</wsrm:retry-count>
          <wsrm:retry-interval>10</wsrm:retry-interval>  <!-- 10 secs
     </wsrm:retry-config>

     <!-- Can have only one such pattern. If the pattern is 'Callback',
            the reply-to attribute can also be used -->
     <wsrm:reply-pattern wsrm:reply-to="SomeURIToSendAcksAndFaults">
            Callback  <!—possible values are Response/Callback/Polling ->
      </wsrm:reply-pattern>

      <wsrm:group-config>
            <wsrm:group-expiry-time>dateTime</wsrm:group-expiry-time>
            <wsrm:group-max-idle-duration>dateTime</wsrm:group-max-idle-duration>
      </wsrm:group-config>
</wsrm:client-config>
 
 

 -Sunil