OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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]