Re: [ws-rx] Minimalist GetMessage proposal

[Paul Fremantle <paul@wso2.com>]

Chris
> We've been over this many times. Any RMS should be free to make its 
> own determination as to when
> IT requests creation of a Sequence. The RMS at the server side of an 
> RMD that can only be accessed via
> the anonymous endpoint is/should be no exception. 
Firstly, the RM spec doesn't state this anywhere. In the submitted spec 
there is no way for a server to request creation of a sequence with an 
anonymous client. If you are going to justify this you need to back it 
up with a use case, scenario, charter words, usage of the submitted spec 
or spec lines. To state it as ig it were a given when it plainly isn't 
even acheivable today in this scenario is not convincing.

Nothing in my proposal forbids an RMS using any mechanism it can to 
create a sequence with an RMD. However, unless the RMD is in some way 
contactable then it is simply logic that states it cannot be contacted.
My proposal is that the way a client makes a server aware of itself is 
through an Offer. Unless the server has some "knowledge of" a client 
(such as an address, a sequence id, or in your case an EPRId) it cannot 
create a sequence, no matter what. You have chosen to create a new 
identifier (EPRId) and therefore a context which needs to be managed and 
so extend the RM spec in a whole new direction. As I posted in response 
to Doug's note, I think the EPRId is poorly specified, with no 
lifecycle, no defined faults, and plainly adding a whole new set of 
state that has to be managed by an RM agent. 

It would be valuable for you to enumerate usecases and real scenarios 
which are motivating the statements you are making, because so far the 
motivation has been theoretical (freedom for RMSs) rather than practical 
(I need to create a sequence because....). I still haven't seen a 
thoroughly plausible scenario for unreliable-in/reliable-out which is 
one of the reasons I took out the optimisation (section 4.2) from my 
earlier proposal.

Paul

Christopher B Ferris wrote:
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> "Marc Goodner" <mgoodner@microsoft.com> wrote on 05/03/2006 11:51:51 PM:
>
> > 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
> >

-- 

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