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