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] about Request-Response MEP


Thank you for your detailed consideration of the issue and for your 
suggested resolution.

On 09-Jun-04 00:11, Jacques Durand wrote:

 > Following-up on Doug's remark about our lack of handling reliability of
 > Request-Response MEP (WSDL).
 > After careful thoughts on this and more discussion with Hamid, it
 > appears we cannot dodge the issue
 > even if we decide to support only partially the reliability of such MEPs
 > (as we do):
 > See below analysis and proposal.
 > Jacques

 > - A proper extension to the Messaging Model would be to add a "Respond"
 > operation
 > for passing a response payload from Consumer to Receiving RMP,
 > correlating in some
 > way with a previous "Deliver" invocation.

On the Producer / Sending RMP side, is a similar operation required or 
would the existing Notify operation include any delivered payload(s)?


 > Proposal:
 > Solution 1: we could just restrict our spec to the one-way operation
 > only. It would
 > be restrictive, though as we hint at in the FAQ, the value of RM as
 > defined here
 > is less for req-resp than for a One-Way.

I agree this is not the best solution.

On the rather pedantic side, I believe you mean the "request / response MEP 
with no OUT content" sub-sub-option Tom described on the call yesterday. 
Our existing text disallows use of the Response RM-Reply pattern with a 
WSDL one-way operation because one-way apparently applies at every level 
(SOAP processor, RMP, producer and consumer).  Put another way, we have 
interpreted WSDL descriptions to constrain both the producer to consumer 
and RMP-to-RMP interactions; such an interpretation limits our options.

 > Solution 2: we extend the model. That is not as high impact as it seems.

 > - no other change is needed. The definition of the main RM features,
 > which currently ignore the response payload, stay the same. No schema
 > change.

I suspect we need to look at the non-normative text around the deliver 
operation in particular.  At the moment, an implementation could place an 
incoming message into a queue and issue an underlying protocol response 
immediately.  When using the Response RM-Reply pattern, we probably need to 
delay such a response until the consumer has had a "chance" to invoke the 
Respond operation.  This may trickle into message ordering and the exact 
semantic meaning of an acknowledgement (again) but only when using this 
reply pattern.


 > I will draft the editorial details for (2), if no further comments.

thanx very much,

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