Off the top of my head, the RMD could advertise the requirement using WS-Policy and enforce it by requiring an RMS includes a specific extensibility element in the CreateSequence message... David
On Tue, Jun 24, 2008 at 12:32 AM, Doug Davis <[EMAIL PROTECTED]> wrote: > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
