David Would the following meet your model?
Namespaces = wsrmpers, wsrmperspol TBD ============================================= Policy Extension for Persistence /wsrmp:RMAssertion/wsp:Policy/wsrmperspol:Persistent/ This policy assertion indicates that the endpoint supports a stable storage model for persisting sequence state. This policy assertion is independent of the CreateSequence/CSResponse extensions listed below. /wsrmp:RMAssertion/wsp:Policy/wsrmperspol:Persistent/@wsp:Optional="true" Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that persistence MAY be used. /wsrmp:RMAssertion/wsp:Policy/wsrmperspol:Persistent/wsp:Policy/wsrmperspol:Required This policy assertion indicates that the endpoint requires that any RMS/RMD communicating with it MUST support stable storage for the sequence state and in addition MUST use the /wsrm:CreateSequence/wsrmpers:Persistent element to indicate that it is using persistent storage. ============================================= Extension to the CreateSequence/CreateSequenceResponse: /wsrm:CreateSequence/wsrmpers:Persistent This optional element, if present, indicates that the RMS is using stable storage to persist the sequence state. If understood by the RMD, the RMD MUST respond with a /wsrm:CreateSequenceResponse/wsrmpers:Persistent element (see below) /wsrm:CreateSequence/wsrmpers:Persistent/@required This optional attribute, if present, must have a value of "true", "1", "false", or "0". If true, the RMD MUST either use stable storage for storing the sequence state OR refuse to create the sequence. If not present, the default behaviour is "false" - the RMD can successfully create the sequence whether or not the server is persistent. /wsrm:CreateSequenceResponse/wsrmpers:Persistent This optional element, if present, is used to indicate whether or not the sequence is using stable storage to persist the sequence state. /wsrm:CreateSequence/wsrm:Offer/wsrmpers:Persistent/@required This optional attribute, if present, indicates that the RMS MUST use stable storage for sequence state for this offered sequence. If the server supports this extension, it MUST either include the Accept/Persistent element in the response (and use persistence) OR not accept the offered sequence. /wsrm:CreateSequenceResponse/wsrm:Accept/wsrmpers:Persistent This optional element, if present, indicates that the RMS is using stable storage to persist the sequence state for the offered sequence. Explanation: Here are the potential cases: 1) The server is persistent but does not require it from the client 2) The server is persistent and requires if from the client 3) The client is persistent but does not require it from the server 4) The client is persistent and requires if from the server 1) The server may advertise its persistence using <wsrmperspol:Persistent wsp:Optional="true"/> In addition, the server can understand <Persistent> elements in the CreateSequence and respond in the CSR. The server, since it understands this model, must indicate if it is using persistence using the CSR extension. If the client knows that the server supports this extension (e.g. by noticing the policy tag) then it can deduce that the sequence is NOT persistent from the ABSENCE of a <Persistent/> element in the response. If the client does not support this extension, then it ignores the extended elements in the response (according to the spec). 2) The server may advertise this behaviour with: <wsrmperspol:Persistent><wsrmperspol:Required></wsrmperspol:Persistent> In addition, the server will refuse to create any sequences that do not have the <Persistent> element in the CreateSequence and Offer. Clients that are not aware of this extension will find the reason in the CreateSequenceRefused fault detail. 3) The client can include the <Persistent> element in the CreateSequence and/or Offer. If the server does not support the extension or chooses not to use persistence on this sequence, then the server will not respond with a CreateSequenceResponse/Persistent element. 4) The client SHOULD include the <Persistent @required="true"> If the server supports the extension, then it MUST either respond CreateSequenceResponse/Persistent OR refuse the sequence (if it cannot use persistence on this sequence for some reason). If there is no CreateSequenceResponse/Persistent tag then the client SHOULD terminate the sequence. I think the biggest question to answer is whether persistence is something you can support on an operation or message basis, or on say just requests. I am for simplicity, so in general I think this should set at the level of a service (all the operations on a service). However, I do think it makes sense to say that a request is persistent without the response necessarily being persistent. The reason for this is that this is a very common pattern in MQ or JMS to have a temporary reply to a persistent message. However, while I think this is supported in the RM extensions, it isn't yet captured in the policy extensions. Paul On Tue, Jun 24, 2008 at 9:33 AM, David Illsley <[EMAIL PROTECTED]> wrote: > 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] > > -- 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]
