[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Groups - COntribution-JD-WS-Reliability-2004-06-21.pdfuploaded
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. - 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. 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). 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). 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. 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. 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). -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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]