[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: wsrm issues
Enclosed are excerpts from WS Reliability: the most recent schema, a suggestion I made concerning using ASAP to implement a polling reply pattern and a proposal from others in the group for a reliability namespace status request. My argument is basically that ASAP was designed to deal with the Aspect of determining the status of a service instance and could be used in place of adding special reliability headers for this purpose. Again, they expect 1000s of messages a second and want to piggyback acknowledgements. I worry the term "service instance" (while also used this way in the Grid Service community) may have scared people away imagining how it would be implemented. It seems to me ASAP's treatment of Keys and Context Data are opaque enough to handle it semantically. What are opinions here about the application of ASAP for this purpose? I don't want to misapply or stray from the intent of ASAP... *** WS-Reliability has gone through some changes since the precommittee document, a recent schema writeup is shown below
*** From: John Fuller <jfuller@wernervas.com> Date: Fri Sep 26, 2003 4:09:00 PM US/Central To: tom@coastin.com Cc: wsrm <wsrm@lists.oasis-open.org> Subject: Re: [wsrm] Poll Operation In the invoice message if they added an ASAP header for a create-instance-request (perhaps providing the observerkey uri) with no response requested (our one way scenario), it seems like an observer could find the status by the ASAP RequestId or alternately ContextData: both of which are opaque enough they could use RM header inforrmation or not. Admittedly reliability was originally to be out of scope for ASAP, but it is a case of a query for service instance status information... On Friday, September 26, 2003, at 03:39 PM, Tom Rutt wrote: > I have expressed concerns that the Poll operation should be expressed > as part of the WSRM protocol using a soap header element. Doug has > stated a preference to treat the poll operation > as a separate WSDL operation. > > I think the question boils down to what we consider as parts of the > contract for the web service instance that the client is accessing. > If one considers the entire description for a particular web service > instance (e.g., an Invoice delivery service with a oneway WSDL > operation) to include its ability to use WSRM defined > soap headers and protocol, and if the poll request message part will > never be piggybacked with an invoice message part, I can see Doug's > point. In this case, the adversised web > service instance includes the ability to receive the invoice oneway > operation, as well as to > be able to deal with the WSRM soap headers and act in accordance to > the protocol. So it does not matter if the service description > includes the poll info as a message part bound to the soap body, vs > binding it to the soap header. > > However, if the client wants to piggyback the poll request with another > reliable invoice request, the wsdl description might be complicated if > both are > defined as message parts (for the same wsdl operation) bound to the > body. If there is no need for this "Piggybacked poll" use case, then > that is another concern which is removed.. > > I was concerned about supporting use cases where someone would > consider the invoice oneway > operation as the definitive specification of the web service instance, > with WSRM protocol usage > negotiated in some other agreement, outside of the wsdl spec . If > this use case > is not in anybody's mind as an alternative, I guess my other concerns > do not apply, > > Tom Rutt > > -- ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 *** From: Sunil Kunisetty <Sunil.Kunisetty@oracle.com> Date: Tue Sep 16, 2003 1:51:15 PM US/Central To: wsrm@lists.oasis-open.org Subject: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern 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 ***
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]