[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern
Doug, Doug Bunting wrote: > Sunil, > > I believe John had a good point that, while it may not change the > suggested text, is certainly an important part of your proposal. If we > were to accept this proposal and require it in all implementations (not > something that is entirely clear in this proposal), we may be changing > the persistence requirements. How does this proposal change the "existing" persistence requirements? As far as I recollect, it supports the existing ones without any new requirements. Atleast my intent was not to jeopardize any existing ones or add new ones. > > > I am curious why the StatusResponse contains a Status that seems to > include error conditions. What rules decide whether a situation should Are you referring to InvalidGroupId & InvalidSequenceNo? If so, they are not the cause of the original msg., but rather the Status request msg. itself. If a receiving RMP receives a Status request for a msg with a GroupId that was not never sent or was invalid, it will then send an InvalidGroupId 'status' response corresponding to the 'status' request and not the original request. > > result in a Fault versus a Status? The current proposal leans toward > Status handling without explanation. I didn't understand the above. > > Other issues arise due to the bundling suggested below. When one > StatusRequest is invalid (should result in a Fault) but the bundled > business Request (or additional StatusRequest) does not, what happens? This is a generic problem in the sense that we will have the same problem if we want to piggy-back Acks on other Requests & Responses. We ran into similar cases when Jacques is trying to propose a solution for Response Ack. pattern, > > If multiple StatusRequest elements are contained in one message, must > all related StatusResponse elements be included in a single message as well? We could go either way, but for protocol simplicity we should say yes. > > > The existing patterns are focused on RMP-level signals and this proposal > puts handling the status requests at that level. This leads to > potential handling delays if too many requests are bundled together. In > turn, this proposal leads to additional cases in which the patterns > cannot hold. We should then come with recommendation and exclusion cases. -Sunil > > > Many systems will impose security restrictions in the area of these > requests. Some will refuse to respond positively to any request; others > will ignore requests not coming from the originator of the referenced > message. These and other common situations should be described below. > > Finally a new (separable) issue, both this suggested Status text and the > existing description of faultcode values defined in our specification > are rather lax about qnames. Restrictions such as requiring a value to > be a qname should be clear in the text, not just indicated in the schema > (not a problem below). Any possible value examples and descriptions > should use a fully qualified name. > > thanx, > doug > > On 16-Sep-03 12:51, Sunil Kunisetty wrote: > > > > > John Fuller wrote: > > > > > >>While I suppose it would add a diagnostic benefit, it sort of directly > >>addresses the RMP > >>as opposed to the RMP just knowing how to manage messages and hand them > >>off. > > > > > > The above issue while is important is out-of-scope of this particular requirement/proposal. > > "Message management" was/should-be handled in the persistence/DE/RM sections. > > > > > >>How long would you have to archive message information to know > >>when expired groups were purged? Or does it not assume transient > >>services > >>that persist, but a daemon that would only respond with knowledge since > >>its startup? > >> > >>On Tuesday, September 16, 2003, at 01:51 PM, Sunil Kunisetty wrote: > >> > >> > >>> All - > >>> > >>> I had an AI @ the last F2F for coming up with a proposal for POLL > >>>pattern. > >>> > >>> Mark/Doug: > >>> > >>> Could you create a Spec. Issue for Requirement Issues 3.6 & 3.7? > >>> > >>> <ProposalBegin/> > >>> > >>> I'd like to propose to have 2 new Headers: > >>> > >>> StatusRequest > >>> StatusResponse > >>> > >>> StatusRequest will be the Header used by the Sender to send a > >>>poll/status > >>> inquiry to the Receiver. It will have 2 sub-elements. A mandatory > >>>GroupId > >>> and an optional SequenceNo. The types for these are the same as the > >>>ones > >>> in MessageHeader element. > >>> > >>> StatusRequest > >>> - GroupId - Mid URI type - Mandatory > >>> - SequenceNo - UnsignedLong - Optional > >>> > >>> StatusRequest can be sent without a MessageHeader and hence can be > >>> piggy-backed on another Request or can be batched with other status > >>>requests. > >>> > >>> StatusResponse Header will be used by a Receiver to send the status > >>>back > >>> to Sender. It will have the following sub-elements: > >>> - RefToGroupId - mid URI type - Mandatory > >>> - RefToSequenceNo - unsigned long - Optional > >>> - Status - QNAME - Mandatory > >>> > >>> Possible Status Values are: > >>> - InvalidGroupId - When the GroupId is invalid or > >>>un-recognized > >>> - InvalidSequenceNo - When the SequenceNo is invalid or > >>>un-recognized > >>> - MsgExpired - When the message was expired (based on > >>>ExpiryTime) > >>> - MsgReceived - When the message was received and ack-ed by > >>>the RMP/ > >>> > >>> Since all our Header elements are extensible, Implementations can > >>>extend with a > >>> new element called 'sub-status' and send more implementation > >>>specific details > >>> if desired. But I prefer that Spec. level requirements for Status be > >>>simple. > >>> > >>> Multiple StatusResponse(s) can be batched or can be piggy-backed on > >>>Response. > >>> > >>> We should be able to share the above Status values with Fault Codes. > >>>Note both > >>> are QNAME types and hence shareable. > >>> > >>> Error due to StatusRequest processing will result in a Fault with > >>>error code > >>> InvalidStatusRequest. > >>> > >>> <ProposalEnd/> > >>> > >>> Comments ??? > >>> > >>> -Sunil > >>> > >>> > >>>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. > > > > > > > > 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. > > > > -- > SunNetwork 2003 Conference and Pavilion > "An unparalleled event in network computing! Make the net work for you!" > > WHEN: September 16-18, 2003 > WHERE: Moscone Center, San Francisco > > For more information or to register for the conference, please visit: > http://www.sun.com/sunnetwork
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]