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


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:  

View Document Details:

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]