Sorry for the VERY long response time on this one. I just was being harangued by someone today for the fact WSRM doesn't have a persistence model!
Here is my updated draft based on the comments on this list and off-list (Thanks Doug, David) 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 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 and the /wsrm:CreateSequence/wsrmpers:Persistent element is optional. /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/@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 Tue, Jul 29, 2008 at 9:13 PM, David Illsley <[EMAIL PROTECTED]> wrote: > Sorry for the delayed response. This is certainly along the lines I > was imagining, and I have a few comments. > > On Thu, Jul 24, 2008 at 9:57 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote: >> 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. >> > The above doesn't really fit with the general WS-Policy model. An > assertion should state a requirement, and use the standard mechanisms > to make the requirement optional. I think can be restated as: > > /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 and the > /wsrm:CreateSequence/wsrmpers:Persistent element is optional. > > /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. > > (though it's still not right) > >> ============================================= >> 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). > > Yep, this isn't an easy question, but I think the existing WS-RM > Policy 1.1 doc probably helps. You've defined the new assertion as a > nested assertion of the RMAssertion, which itself is only applicable > at the Endpoint and Message subjects, so allowing these new assertions > in those places seems sensible and to match your thoughts. > >> However, I do think it makes sense to say that a request is persistent >> without the response necessarily being persistent. The rason 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. > > I *think* this would be supported with a persistent policy attached to a > wsdl:binding/wsdl:operation/wsdl:input > and a non-persistent RM policy attached to the corresponding > wsdl:binding/wsdl:operation/wsdl:output > though I'm unclear whether real-world WS-RM implementations support > this level of configuration with the current assertions. (i.e. RM on > the request and not the response). > > I'll keep thinking about this, > David > > --------------------------------------------------------------------- > 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]
