[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Minimalist GetMessage proposal
I agree this proposal is a lot tighter in scope. I'm not to convinced of the need to poll for a CS so that doesn't trouble me very much. Your suggestion for the addition of Offer is an interesting idea. I'm not sure how much it really optimizes things when the client instead of polling for an inbound CS could simply start with an outbound CS with an Offer for an inbound sequence. The outbound sequence would be independent of the inbound one so it could be terminated before the inbound one if it was not needed. Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 Blog: http://spaces.msn.com/mrgoodner/ -----Original Message----- From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: Wednesday, May 03, 2006 7:24 PM To: Paul Fremantle; wsrx Subject: RE: [ws-rx] Minimalist GetMessage proposal I must say the proposal is much improved and scoped. It of course works only with offered sequences - I am still trying to convince myself that not being able to poll for CS is not a (serious) issue. A wild idea: the unreliable-in/reliable-out case could be handled better by allowing an wsrm:Offer on the GetMessage... Jacques -----Original Message----- From: Paul Fremantle [mailto:paul@wso2.com] Sent: Wednesday, May 03, 2006 12:05 PM To: wsrx Subject: [ws-rx] Minimalist GetMessage proposal Based on some of the discussions it seemed to me that it could be valuable to produce a completely "minimalist" GetMessage proposal. This is a new proposal that is based on the previous WSO2 proposal. The proposal removes the MessageID selector in the GetMessage - relying on simply getting whatever message the server sends back next. Also it removes the section 4.2. Effectively section 4.2 is an optimisation: for example to support unreliable-in/reliable-out a client could do a createsequence+offer and never use the outgoing sequence. In this case there is an overhead, which 4.2 aimed to remove, but this simplifies the proposal by focussing on the bare minimum required to support the most common use cases, but still allowing the other use case with a slight overhead. I've also included a sample message flow which I hope helps understand the proposal and show the general usage. Paul -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://feeds.feedburner.com/bloglines/pzf paul@wso2.com "Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]