[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
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. I am curious why the StatusResponse contains a Status that seems to include error conditions. What rules decide whether a situation should result in a Fault versus a Status? The current proposal leans toward Status handling without explanation. 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? If multiple StatusRequest elements are contained in one message, must all related StatusResponse elements be included in a single message as well? 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. 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]