[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] clarification on Respond primitive
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]