On rereading this, I realized there were some improvements I could make. Here is a latest version. I've also tried to define persistence, though this will need some significant work.
Namespaces = wsrmpers, wsrmperspol TBD ============================================= Policy Extension for Persistence In this document the notion of persistence is defined as follows: A persistent RMS or RMD is one that stores enough sequence and/or message state to a stable storage model so that the system may fail and restart and continue processing the sequence as if no system failure had occured. The details of such persistent state are out-of-scope of this definition, except that the wire protocol behaviour (excluding timing considerations) of the system must be as if no system failure occurred. /wsrmp:RMAssertion/wsp:Policy/wsrmperspol:Persistent/ This policy assertion indicates that the endpoint supports a stable storage model and 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. /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. This mechanism may be used as a compact indication that support for stable storage is optional. The /wsrm:CreateSequence/wsrmpers:Persistent element may or may not be present when communicating with this endpoint. /wsrmp:RMAssertion/wsp:Policy/wsrmperspol:Persistent/@wsp:Ignorable="true" Per WS-Policy, this notation indicates "behavior that need not be engaged for successful interoperation with the entity", allowing the assertion to indicate to interested parties that a stable storage model is supported, but that the endpoint does not place any requirement on any RMS/RMD which is communicating with it to use the /wsrm:CreateSequence/wsrmpers:Persistent element. ============================================= 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. This element may be present even if the client did not request persistence. /wsrm:CreateSequence/wsrm:Offer/wsrmpers:Persistent This optional element, if present, indicates that the client-side RMD supports persisting the sequence state in stable storage for this offered sequence. The client-side RMD MUST persist the sequence state in stable storage if the response contains /wsrm:CreateSequenceResponse/wsrm:Accept/wsrmpers:Persistent. If the CreateSequence request contains the /wsrm:CreateSequence/wsrmpers:Persistent element but does not contain the /wsrm:CreateSequence/wsrm:Offer/wsrmpers:Persistent element, then the expected behaviour is that the outgoing sequence will use stable storage, but the Offered sequence will not use stable storage. This is a common pattern in messaging where outgoing messages require persistence but responses do not. However, the server-side RMS may use persistence storage in this model and may return /wsrm:CreateSequenceResponse/wsrm:Accept/wsrmpers:Persistent to indicate that it is doing so without error. /wsrm:CreateSequence/wsrm:Offer/wsrmpers:Persistent/@required This optional attribute, if present, indicates that the service-side 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 service-side 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/> 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 respond without 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. Paul On Fri, Dec 12, 2008 at 5:05 AM, Paul Fremantle <[email protected]> wrote: > Thanks for the feedback Sara. > >> 1. Are we still going for service level scope for this ie all the operations >> on a service? > My understanding is that the way this is written piggybacks off the > existing RMAssertion, which allows on a per message or per service > basis. I think the main point is that this makes sense in the scope of > any sequence, and should therefore match the semantics for sequences. > >> 2. You previously wanted to allow this to be turned on/off for request and >> responses to imitate the pattern in MQ or JMS to have a temporary >> reply to a persistent message. Is that still the plan? > > Yes I'd still like to make this possible to have a persistent out with > non-persistent responses, since that is a common pattern in messaging. > >> 3. Adding a policy assertion cannot guarantee the messages are written to >> disk. It means that this is the intention, but this is different to adding >> security headers to messages for example, which would be verifiable by the >> message. The client has to trust the server to do what it says and vice >> versa which is ok but we should be clear about this. but, to split some >> more hairs, are we abusing policy in some way by adding this kind of >> assertion that can't be verified? > > The assertion that the RMD only accepts messages that have the same > security token as the initial sender is similar. You can test it by > breaking it, but its really an assertion of the internal behaviour of > the system. Even more so, the delivery assurances are not testable > from the other end. So I don't think this goes beyond the usage of > policy we have already defined. > >> 4. How are we defining persistent? Paul you referred to XA spec which from >> a quick scan frequently assumes a database or file system as the storage but >> this was written in pre-historic times. Do we need to define what we mean >> by persistent, ie kinds (database or file system), recoverability quality >> (after server failure, time based). This becomes a rabbit warren to start >> down, but makes point 3 more important as if we can't define what we require >> when someone says they are persistent, then users of this can't be certain >> what they are getting when they add the xml to their message. This could >> then be seen as overhead on the message that adds limited value? > > I think it might be nice to define persistent in some "quality of > service terms". In other words this should support restart after > failure, and acknowledgements should positively indicate that the > message has been persisted. So rather than define the mechanics, it > would be better to define the behaviour: if the RMS is persistent, > then a Nack will *always* cause a resend of the missing message, even > if the client has restarted. If the RMD is persistent, the system will > *always* deliver any acknowledged message, even when there has been a > system restart. > > However, I don't want to go too far. I know the XA spec was written in > pre-historic times, but the main point I was making was that they > didn't feel the need to go into too much detail about the mechanisms. > >> >> I don't want to be a nay-sayer here .. I think persistent RM is valuable. I >> just want to make sure we aren't adding something because we can, rather >> than because we need to. > > +1 > >> >> thanks, >> Sara >> >> >> >> > > > > -- > 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 > -- 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]
