Re: [wsrm] Proposal to progress beyond 1.01J

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

  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
>