Re: [wsrm] Groups - COntribution-JD-WS-Reliability-2004-06-21.pdfuploaded

[Tom Rutt <tom@coastin.com>]

Sunil Kunisetty wrote:

> Jacques,
>
> I’m very un-comfortable with the new wordings.
>
> A Meta Point: The spec. is getting very “verbose” and complicated. If 
> I myself have to read couple of times to
> understand the gist, understand the plight of the naïve reader.
>
> I do understand that the spec. has to talk about the model. But to me 
> that has to be simple and crisp and not
> overly complicated. An overly complicated model implies implementation 
> restrictions. Also, while I understand
> that RMP is not an independent entity and piggy backs on a SOAP 
> processor, we should discuss about RMP
> model in particular and not SOAP Processing model in general.
>
> Emphasize should be more on the protocol behavior and the headers as 
> these have an affect on the
> interoperability.
>
> To me a model description should be as simple as:
> - Supports RM capability for request messages only
> - Works with both request-response and one-way transports.
> - For cases where RM-Reply has to be piggy backed on the response 
> (such as the Response pattern case),
> the RMP should wait until the Consumer responds.

To do this the spec needs the Respond primitive as an abstract action by 
the Consumer to the Responding RMP

> - Explain the patterns abstractly etc.
>
> I think we should only emphasize on the Submit and Deliver operations 
> and avoid defining Notify and Respond.
> The way the current Notify is defined, it implies that a RMP 
> implementation should support some kind of
> notification/callback mechanism to the Producer. This is what I meant 
> earlier when I said over emphasizing on
> the model could imply implementation restrictions.

The implementation of the primitives is not subject to standardization, 
there are many ways the response or fault
can be conveyed to the producer, by the sending RMP.

>
> Some specific concerns about the Respond abstract operation:
>
> 1) We need to mention that Respond is not always there if the 
> operation is an one way message or the
> message is dispatched asynchronously (using some Queues).

I agree that respond should only be invoked by the consumer when 
response payload needs to be conveyed.

> 2) Even for synchronous request-response, we don’t have to wait for 
> the Response from the Consumer in
> cases such as Callback where in Response and RM-Reply are sent on 
> different channels and we don’t have
> to wait for the Response to send the RM-Reply (which we send when we 
> make available the message to the
> Consumer).

This version of the protocol has only an http post binding as normative, 
which does not support sending a response payload.

Future versions could add this feature, but it is not there now. Thus I 
do not see any problem in 2) above.

> 3) And I’m very confused about the whole Correlation of the operations 
> section (lines 266-275). Essentially it
> implies (asynchronous) correlation of requests and response. This is a 
> big NO_NO from us. Note that
> there could be cases where a request-response operation could be bound 
> 2 different one-way bindings and
> in that case correlating a Delivery and Respond would require some 
> kind of correlation mechanisms as
> defined in WS-MessageDelivery or so. This spec. cannot stipulate 
> search restrictions.

The Receiving rmp has to know that a response payload is to be 
associated with the request. However this if conveyed,
when it know that a response is required, it (with response reply 
pattern) must wait and correlate the response payload with
the rm reply info for the particular request. This was already in the 
protocol for the http post soap binding..

>
> Some more specific comments:
> 1) Figure 1 should have dotted lines for Respond, Return Rm-Reply and 
> Notify.
> 2) I still believe that the previous definition of Reply patterns are 
> much better than the current ones. The
> current ones talk about SOAP MEPs which is not good.
> 3) Usage of word SOAP MEP is confusing as SOAP 1.1 doesn’t talk about 
> MEP.

we should define the use of the term and reference soap 1.2 for this.

> 4) Section 4.5 still talks about sending both SOAP and RM Fault, which 
> is wrong and needs to be corrected
> (I do understand that your exercise is not intended to fix this but 
> even the latest 1.03 draft has the same
> problem).

This has been agreed for a long time. This was agreed a long time ago. 
The text in 4.5 is now considered stable.

The rm fault, which results in no response payload being avilable return 
for a response reply pattern, MUST be
returned with a soap fault (the lack of response does not obey the wsdl 
contract for that operation).

If someone wants to question this, they must raise an issue, knowing 
that we already voted on making it the way it is.

>
> -Sunil
>
> jdurand@us.fujitsu.com wrote:
>
>>The document COntribution-JD-WS-Reliability-2004-06-21.pdf has been submitted by Jacques Durand (jdurand@us.fujitsu.com) to the OASIS Web Services Reliable Messaging TC document repository.
>>
>>Document Description:
>>latest proposal in extending the WS-R message model, by adding Respond operation, and removing limitation to "request-response" underlying protocol.
>>
>>Download Document:  
>>http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7454/COntribution-JD-WS-Reliability-2004-06-21.pdf
>>
>>View Document Details:
>>http://www.oasis-open.org/apps/org/workgroup/wsrm/document.php?document_id=7454
>>
>>
>>PLEASE NOTE:  If the above links do not work for you, your email application
>>may be breaking the link into two pieces.  You may be able to copy and paste
>>the entire link address into the address field of your web browser.
>>
>>
>>
>>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.
>>
>>  
>>
>
> 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