[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] clarification on Respond primitive
Tom Rutt wrote: > Upon further refllection I think the protocol can be simplified > greatly by disallowin callback and poll > reply pattern with wsdl request/response operation type. This would > require a no in that box of 5.2 Why? What's wrong with having Callback and Poll reply pattern for RM-Reply for WSDL R-R MEP? I understand that they may not be that useful as *response* is construed as an implicit Ack., but I dont't see any fundamental problems with them. > > With this restriction, the respond primiitive will only be invoked on > the Receving RMP for the response reply > pattern. > > This will simplify the protocol and the explanation greatly. > > Tom Rutt > > Tom Rutt wrote: > >> >> >> Doug Bunting wrote: >> >>> 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. >> >> >> >> I think this cannot be done with the response reply pattern as >> defined. I could go along with you on >> generalizing the callback and poll with callback reply patterns, >> however. >> >>> >>> 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 agree we should get rid of as many non essential assumptions as >> possible. But the response reply pattern >> works with the restrictions that are currently on it. Lets not make >> it more in this version. >> >>> >>> 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. >> >> >> >> I think we need to define our "primitive" operations to allow >> multiple implementation styles. >> >>> >>> 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." >> >> >> >> I read this as required only to get rm reply indications back, not >> application data from a wsdl request /response operation. >> >>> >>> "All that is expected of the transport layer is that it will not >>> deliver a corrupted message to the reliability layer." >>> >> We have extra assuptions in the messaging model for underlying >> request response. These are required for >> response reply pattern, but are overconstraing for the callback and >> poll with callback patterns. >> >>> 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." >> >> >> >> This is what should be done with callback and poll reply patterns. >> The rm reply does not depend >> on waiting for the producer to return a response. This "waiting" >> behaviour is only required for the response reply pattern >> >>> >>> 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. >> >> >> >> That matrix entry is allowed in 5.2 table. There is no reason to >> disallow it, as long as we can agree that >> the rm reply goes on a separate callback request, while the response >> goes on the underlying protocol response to the underlying request >> carrying the RM Request. >> >> TomRutt >> >>> >>> 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. >>> >>> >>> >>> >>> >>> To unsubscribe from this mailing list (and be removed from the >>> roster of the OASIS TC), go to >>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. >>> >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]