Doug, There are 2 drivers of this for me, both of which became apparent trying to explain RM to MQ centric people.
1. A desire on the client application developer's part to have a reasonable expectation that a one-way message will be processed. 2. A desire on a server administrators part that the sequences it is managing in a persistent way will be completed. It's probably a very expensive operation to administratively deal with a hung sequence. A server administrator might well wish to limit interaction to parties which support persistence and which can therefore recover from serious* failures and complete and close out sequences on their own without human intervention. Paul, do you have other drivers for this? David * Clearly something less serious than an asteroid taking out the data center hosting your servers. On Fri, Jun 20, 2008 at 6:22 PM, Doug Davis <[EMAIL PROTECTED]> wrote: > > Is thispolicy/extension thing used just for advertisement or something else? > Typically what an endpoint does internally is its own concern. However, I > can see > choosing one RMD over another based on whether it has a higher degree of > QoS/persistence. But this almost sounds like you're suggesting that the RMD > tell > the RMS which kind of persistence it must have - which is odd to me. > > thanks > -Doug > ______________________________________________________ > STSM | Web Services Architect | IBM Software Group > (919) 254-6905 | IBM T/L 444-6905 | [EMAIL PROTECTED] > > > "Paul Fremantle" <[EMAIL PROTECTED]> > > 06/20/2008 12:46 PM > > To > "David Illsley" <[EMAIL PROTECTED]> > cc > [email protected] > Subject > Re: Policy or other extensions to indicate persistent messaging > > > > > David > > Thanks for the reply. > > 1. I hope it won't be too difficult defining the details!!! But I'm > always an optimist. > 2. I agree, Open Standards != Open Source, and I presumed that it was > better to try out some implementation thoughts before taking this to a > standards process. However, if there is a feeling that this should be > done in a standards body, we could move it there. My own feeling > though is that WS-RX is in quiescent mode and so there will be inertia > to be overcome to get an active discussion there. > 3. Actually, you've asked the really tough question (how to define > persistent storage), which is one of the main reasons the WSRX TC > decided not to pursue this. However, I'm not convinced we need to. I > think the prime example of this is the XA spec, which is the bedrock > of transaction systems. If you look at the XA transaction spec, they > simply talk about "stable storage" with no definition. And I'm not > expecting this to be a legally binding policy (if such a thing > exists). > > Paul > > On Fri, Jun 20, 2008 at 5:11 PM, David Illsley <[EMAIL PROTECTED]> > wrote: >> This does seem like something that could be useful, though I'd imagine >> it'll be fraught with difficulties in defining the details. >> >> Clearly open standards!=open source, so if we come up with something, >> finding a standards venue would be a good next step... but that's a >> bit in the future. >> >> I think both parts of your proposal would be needed... a first >> question if you will.... >> Any idea on how we define 'persistent'? This must have been gone >> over lots by other groups that I haven't been involved in. >> >> David >> >> On Mon, Jun 16, 2008 at 11:26 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote: >>> One issue that the WSRX technical committee didn't address in the >>> specification is the persistence of messages. Now, while there were >>> possibly good arguments why that was the case, the reality is that >>> many people want and expect WSRM to provide persistence, and certainly >>> in the case of Sandesha it does. I have long thought that there should >>> be an extension that can be used to signify whether persistence is >>> available and whether it is to be used. This kind of thing is actually >>> common in messaging systems and is available in other messaging specs >>> such as AMQP. >>> >>> This isn't at all fully baked, but the sort of thing I am thinking of is: >>> >>> 1) A policy element to indicate whether this endpoint supports and/or >>> requires persistence >>> 2) An exchange that happens at create sequence time that indicates >>> whether this sequence should/must be persistent >>> >>> Some questions: >>> * What do people think about this? Is anyone *against* defining this? >>> * If we define this, should we try to standardize it somewhere? Or >>> just treat is as an optional extension. >>> * Any comments on the approach - or suggestions for the actual XML? >>> >>> Regards, >>> Paul >>> >>> -- >>> Paul Fremantle >>> Co-Founder and CTO, WSO2 >>> Apache Synapse PMC Chair >>> OASIS WS-RX TC Co-chair >>> >>> blog: http://pzf.fremantle.org >>> [EMAIL PROTECTED] >>> >>> "Oxygenating the Web Service Platform", www.wso2.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Paul Fremantle > Co-Founder and CTO, WSO2 > Apache Synapse PMC Chair > OASIS WS-RX TC Co-chair > > blog: http://pzf.fremantle.org > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
