Re: [wsrm] Proposal to progress beyond 1.01J

[Tom Rutt <tom@coastin.com>]

1.01 H was my action item to back out the non agreed changes from 1.01

1.01J was Jacques action item to introduce a respond primitive.

I agre that it is probable better to reach consensus on a direction 
before another draft.

However, people should feel free to propose changes to help make their 
points clear.

Sunil Kunisetty wrote:

>
>  While I couldn't follow all the mails as it has been very hectic for 
> me last few mails,
>  I just can't understand  the mails I read  and I really don't 
> understand what the issue is.
>  There are so many drafts and  I don't really understand what we are 
> solving here.
>
>  I think we should STOP updaing the drafts until we finalize the 
> technical issues if
>  any. Could someone summarize the real technical issue?
>
>  As far  sending cached responses for DE, it is totally impractical 
> and a strong NO-NO
>  from Oracle.
>
>  -Sunil
>
> Tom Rutt wrote:
>
>> Proposal for more accurate WS-Reliability Model:
>>
>> Add a definition for the Respond abstract operation, as proposed by 
>> Jacques in 1.01J.
>>
>> Include the response conveyance as a potential part of the Notify 
>> operation, as proposed by Jacques.
>>
>> To maintain the design requirement that the RMP does not have to be 
>> aware of the WSDL for the payload, make invocation of the Respond 
>> operation optional for the
>> Callback and Poll reply patterns.  For these patterns, the Receiving RMP
>> could just ignore the Respond invocation if it occurs
>> , since it is totally in control of initiating the
>> response with these two reply patterns.  If a response is conveyed by 
>> the Respond operation it would be
>> put in the underlying response to the reliable message request, but 
>> the Sending RMP would not have to
>> deal with it, since it will get its reply thru a callback or a poll.
>> For the callback and poll pattern the Receiving RMP response 
>> initiation would be independent of whether the
>> respond primitive is invoked or not.
>>
>> However, if the response reply pattern is requested, there needs to 
>> be an added requirement that the Respond operation is invoked by the 
>> Consumer on the Receiving RMP.  That would be the trigger for the 
>> Receiving RMP to add its soap header block with the reply to the soap 
>> response.
>>
>>
>> For Duplicate elimination case, the Receiving RMP should be allowed 
>> to return a cached copy of the original Respond contents.  This is 
>> desirable behaviour.   If the Sending RMP had successfully received 
>> the first response and conveyed it to the producer, it could ignore 
>> the second response, or do other things dependent on the local 
>> implementation of the Notify primitive.
>>
>> If the response to the duplicate invocation is not available to the 
>> Receving RMP, then it can return an empty soap body with its ack 
>> reply for the duplicate.
>> In the typical case, by the time the Sending RMP receives the second 
>> ack, it will have already delivered the response to its producer 
>> using the Notify operation.  The receving RMP in this case can just
>> ignore the ack response to the duplicate invoke, not caring that the 
>> body is empty.
>>
>> The only case which would be troublesome is when the original 
>> response was lost, say to a transport connection failure.  The 
>> sending RMP would see the second empty body ack as the response for 
>> the original invocation and would deal with it in a manner specific 
>> to the implementation of the Notify operation on the sending sysem.
>>
>>
>>
>> This is a minimal fix which meets the needs of the specification, in 
>> my opinion.
>>
>> Comments please.
>>
>> Tom Rutt
>>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133