Re: [wsrm] Proposal to progress beyond 1.01J

[Tom Rutt <tom@coastin.com>]

I need to clarify a couple things.

When I say, "the RMP can ignore the Respond operation" I meant only with 
respect to
its logic for when to send its reply.  Depending on implementation, the 
Receiving RMP may
have to convey the response information to the underlying response to 
the request.   It would be
acting as a pass thru layer for the callback and poll reply pattern.

The key point here is that the consumer knows when it needs to invoke 
the respond operation , it knows the contract (e.g, wsdl request 
response operation) and will invoke it in conditions it needs to.

With the response reply pattern, the producer always must invoke the 
respond for every deliver it gets.

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