I just have a hard time understanding how an RMD can require an RMS to have persistence. Seems like that's under the RMS/client-app's control - not the server/RMD. How does the RMD check this?
thanks -Doug ______________________________________________________ STSM | Web Services Architect | IBM Software Group (919) 254-6905 | IBM T/L 444-6905 | [EMAIL PROTECTED] "Paul Fremantle" <[EMAIL PROTECTED]> 06/23/2008 05:39 PM To "David Illsley" <[EMAIL PROTECTED]> cc [email protected] Subject Re: Policy or other extensions to indicate persistent messaging David I agree with your scenarios. I do also have another angle on it, which is really orthogonal to the actual technical scenarios: The aspect I'm thinking of is to be able to counter people who say that RM does not "do" persistence, and I think to be able to get around the misinformation that has been around I think it will be important to have an *option* to enforce persistence. Paul On Mon, Jun 23, 2008 at 3:57 PM, David Illsley <[EMAIL PROTECTED]> wrote: > 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] > > -- 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]
