Proposal to progress beyond 1.01J

[Tom Rutt <tom@coastin.com>]

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