clarification on Respond primitive

[Tom Rutt <tom@coastin.com>]

I would like to clarify my understanding of the respond primitive.

Its only use if for the case where the request is carried on an 
underlying transport request response
exchange, and the consumer wants to provide response information to be 
carried on that underlying
protocol response.

If the callback reply pattern is requested for a wsdl two way operation 
(this is allowed in the table in 5.2)
the respond primitive would only affect the underlying protocol response 
to the reliable message request.  The
reply info is sent on a separate  callback invocation, initiated by the 
Receving RMP,  to convey the reply in a soap
header. 

There is no requirement to be able to send response payload with the 
callback or poll reply pattern.

If we want to make the protocol more robust, we can allow the callback 
request or the asynch poll
request and poll calback reply to map to oneway underlying transport.  
However, the response reply pattern
has only been designed to cover the underlying protocol being request 
response.

If other people have been thinking differently, now is the time to 
explain their interpretation so we can
reach agreement on how to fix the problem

I am viewing it as fixing the documentation of what we already have.

Some of Doug's proposals seem to be extending the protocol way beyond my 
understanding of
its behaviour.

Tom Rutt


PS Piggybacking another reliable message request on a callback is 
allowed, but the consumer is not involved in this, since it is  a 
combinded sending/receiving rmp which would  be able to do this 
(multiplex a submit from its own producer on a callback reply for a 
message received as a Receiver.

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