Re: [wsrm] clarification on Respond primitive

[Doug Bunting <Doug.Bunting@Sun.COM>]

Tom,

This argument is starting to go in circles both in many private emails and 
on the list.  We are having terminology problems in many areas and are 
discussing proposals that significantly miss the mark from the perspective 
of our requirements and customer expectations.

We have many interaction levels our terminology often cross.  At the lowest 
level, the wire protocol involves one way and request-response transfer 
protocol utilizations (SMTP or HTTP for example).  Next, we observe the 
effects of the SOAP / WSDL binding descriptions, which I term the 
underlying protocol.  These bindings may add a request-response capability 
to transfer protocols that do not support this directly.  Next, we have the 
RM-Reply patterns which are specifically describing how the RM-Reply itself 
gets back to the sending RMP and may involve multiple underlying protocol 
exchanges.  At the top, we have the producer / consumer interface which may 
abstract away all of the extra RMP-specific exchanges and much of the 
detail below that level (when RM-Replies are transfered, entire underlying 
protocol or transfer protocol exchanges and many other details).  I assume 
when we talk about WSDL without additional qualifiers, we are talking about 
the top-level producer / consumer interaction.

I want to be clear that our specification should be entirely concerned with 
the top-level producer / consumer interaction, the RM-Replies pattern and 
the generic capabilities the underlying transport provides.  I doubt we 
need to know more about the underlying transport then whether it supports 
request-response interactions directly (in which case the Response and 
synchronous Poll RM-Reply patterns become straightforward in our protocol). 
  With the exception of the HTTP Binding chapter (which might be better 
termed our use of the existing SOAP over HTTP binding), the specification 
should ignore transfer protocols completely.

The specification as it exists today (1.01 for example) is not that far 
from supporting this level of abstraction.  It is however dragged down with 
a number of statements such as the "non-essential assumption" (whatever 
that means) that the underlying protocol universally support 
request-response operation.

I also assume we use the acronym "RMP" as described in our requirements 
document and abstract model:

"R1.1 The implementation of the specification must fit into a layered 
architecture where WS-Reliability is a communication layer between the 
application and the SOAP layer."

The RMP is explicitly *not* a handler sitting within some other generic 
SOAP processor.  It subsumes such features.  The specification as it stands 
today supports implementation choices that may or may not involve using a 
generic SOAP processor and handlers to create an RMP.

Back to your proposal below.

If I am reading your proposal correctly, you are talking about conveying 
consumer information (response payloads, the result of the Respond 
operation) in the immediate underlying protocol response to whatever 
reliable message arrives.  This starts from a somewhat non-sensible "design 
requirement"[1] which is impossible to meet if the RMP is solely 
responsible for the bits on the wire.  It ends up meaning the consumer 
cannot reliably return any information and the producer cannot sit behind a 
firewall.  We are not meeting at least two of our requirements:

"R3.7 The Specification must support the Polling RM-Reply Pattern for WSDL 
1.1 Request-Reply operations."

"All that is expected of the transport layer is that it will not deliver a 
corrupted message to the reliability layer."

I would also suggest returning to my discussion of proposal C in the 
original "more on payload(s) inclusion and MEPs than our Request-Response 
MEP discussion covers" email.  In that email, I pointed out:

"The use cases for this option seem  a bit far fetched
since the RMP information would be expected to be available faster than any
consumer Respond invocation; we would expect  the RMP to be able to respond
faster  than the  consuming system  /  user /  application /  ...  The  new
Respond operation would provide consumer payload(s) returned as part of the
initial message exchange."

I would go so far as to say it is just wrong to send the Respond results in 
the immediate underlying protocol response unless we are using the Response 
RM-Reply pattern.  These payloads must be transferred together with the RMP 
publications.

thanx,
	doug

[1] Mentioned in your previous "Proposal to progress beyond 1.01J" email. 
The RMP cannot be unaware of the top-level WSDL when it is solely 
responsible for both the bits on the wire and its interface to the producer 
or consumer.  The RMP might not need to understand anything about the 
payloads described in the WSDL but certainly needs to be aware of a need to 
wait for information from the consumer and probably a bit more.

On 10-Jun-04 17:08, Tom Rutt wrote:

> 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.