[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Detailed proposal to allow Batching of Acks and RM faultsusingResponse Reply pattern.
Sunil Kunisetty wrote: > Agree with the new wordings. > > A unrelated question (wrt to this topic), but related to RM Faults and SOAP Faults > is, if we are using RM Faults for RM stuff and not SOAP faults, what is the replacement > for faultcode/faultstring (for 1.1 case and Code/Reason for 1.2 case) in the RM Faults. > > My earlier proposal for Faults said send Client/Server (Sender/Receiver for 1.2) codes > depending the RM fault. We had 2 different categories of RM Faults which we clearly > distinguished. An issue we never solved with the old approach was when batching faults, > if we have to send some Client and some Server faults, what should be the faultCode > inside the SOAP Fault. > > This is not an issue if we are not using SOAP Faults. > > That is another reason to not map rm faults directly to soap faults. The only exception is the new issue, on what the web service can return if it demands reliability, but the sender does not inclucde the proper reliabiliy header info. However, this should be a Soap fault, since it being issued from a receiver back to a non rm aware sender. > What to do with the RM Faults case? Shall we say it's upto the client to distinguish it > based on the type of fault as specified in the specification. > > What does it matter, the fault descriptions are fairly clear. > And what about the fault string? > > This can be an extension attribute to the NonSequenceReply and RangeReplies elements. If we want to make it standard, we can simply add another optional attribute for faultDetail, with xsd:string type. > -Sunil > >Tom Rutt wrote: > > > >>Tom Rutt wrote: >> >> >> >>>Lines 1019 thru 1024 currently state the following: >>> >>>“ >>>- *Response *: An Acknowledgment message (or Fault message) MUST be >>>sent back >>>directly in the response to the Reliable Message. This pattern is not >>>applicable for one-way application level MEP. The acknowledgment >>>message that can be sent back in the response is for the message in the >>>request only. Acknowledgment message for the former request >>>MUST NOT be sent back. >>>“ >>> >>>To allow the receiving RMP to return acks or falts for former >>>requests, the last two sentences are too strong: >>> >>> >>Discussions have led to a concensus that the spec should be silent on >>sending extra information in the response for the response reply pattern. >> >>The proposal to resolve rel 108 and rel 115 includes restrictions on a >>response element pertaining to response reply pattern. These are >>the more approprate way to state the requirment, without disallowing >>extensions to provide more information. >> >>Delete the last two sentences: >>" >>The acknowledgment message that can be sent back in the response is for >>the message in the >>request only. Acknowledgment message for the former request MUST NOT be >>sent back. >>" >> >> >> >>-- >>---------------------------------------------------- >>Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com >>Tel: +1 732 801 5744 Fax: +1 732 774 5133 >> >>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@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]