[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [asap] wsrm issues
Currently the WSRM idea is to be a layer in an application's service stack, where the RMP is the endpoint itself and the reliable message components are to be used to add reliability to any message. I think people may be assuming that 1000 new messages mean 1000 new threads of control at an OS level (because of the way we sometimes think of web services and services as OS processes or threads?), rather than identifiable pieces of work in process. I didn't get any written feedback, just the scalability question on the conference call when I suggested reliable requests like the invoice requests were each service instances. (It seems to me ASAP's ListInstances gives us a way to query and return lists of completed instances (over an interval or for a group, perhaps) which would provide for the high throughput they want anyway ) I had previously posted the ASAP draft and I informally suggested that asynchronous requests could be sent as part of create-instance requests, but I think if we could provide some mockups of what the messages could look like using ASAP to implement the RM Polling ReplyPattern and describe what happens for an example it might help. Additionally it may help us identify areas for improvement in the ASAP precommittee draft. On Friday, October 3, 2003, at 06:13 AM, Jeffrey Ricker wrote: > Thanks for posting this for us, John. > > This is exactly the sort of thing that I hope ASAP can resolve. Here we > see WSRM trying to create an asynchronous pattern, just like we have > seen other protocols in OASIS do. > > I think "pattern" is a good term to describe ASAP. Developers and > protocol authors would employ the ASAP pattern to solve asynchronous > design challenges. (Hopefully they would use the namespace as well to > make things even easier.) > > How exactly does "service instance" scare people away? I am very eager > to understand this to remove any road blocks to adoption. > > Ricker > > > On Thu, 2003-10-02 at 17:35, John Fuller wrote: >> 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 >> >> *** >> >> ______________________________________________________________________ >> >> 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/asap/members/ >> leave_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]