[REL-49]proposal for REL-49

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