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


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

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

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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]