You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Paul Fremantle <pz...@gmail.com> on 2008/07/24 10:57:42 UTC
Re: Policy or other extensions to indicate persistent messaging
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 <da...@gmail.com> 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 <du...@us.ibm.com> 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 | dug@us.ibm.com
>>
>>
>> "Paul Fremantle" <pz...@gmail.com>
>>
>> 06/23/2008 05:39 PM
>>
>> To
>> "David Illsley" <da...@gmail.com>
>> cc
>> sandesha-dev@ws.apache.org
>> 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 <da...@gmail.com>
>> 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 <du...@us.ibm.com> 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 | dug@us.ibm.com
>>>>
>>>>
>>>> "Paul Fremantle" <pz...@gmail.com>
>>>>
>>>> 06/20/2008 12:46 PM
>>>>
>>>> To
>>>> "David Illsley" <da...@gmail.com>
>>>> cc
>>>> sandesha-dev@ws.apache.org
>>>> 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 <da...@gmail.com>
>>>> 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 <pz...@gmail.com>
>>>>> 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
>>>>>> paul@wso2.com
>>>>>>
>>>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Paul Fremantle
>>>> Co-Founder and CTO, WSO2
>>>> Apache Synapse PMC Chair
>>>> OASIS WS-RX TC Co-chair
>>>>
>>>> blog: http://pzf.fremantle.org
>>>> paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Policy or other extensions to indicate persistent messaging
Posted by Paul Fremantle <pz...@gmail.com>.
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 <pz...@gmail.com> 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
> paul@wso2.com
>
> "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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Policy or other extensions to indicate persistent messaging
Posted by Paul Fremantle <pz...@gmail.com>.
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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Policy or other extensions to indicate persistent messaging
Posted by Sara Mitchell <sa...@googlemail.com>.
>
> Hi Paul,
>
Glad to see this back .. been thinking of it recently. There were a few
things that came up on the old thread that are still a bit open ended imho
:o)
1. Are we still going for service level scope for this ie all the operations
on a service?
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?
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?
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 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.
thanks,
Sara
Re: Policy or other extensions to indicate persistent messaging
Posted by Paul Fremantle <pz...@gmail.com>.
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 <da...@gmail.com> 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 <pz...@gmail.com> 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: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Policy or other extensions to indicate persistent messaging
Posted by David Illsley <da...@gmail.com>.
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 <pz...@gmail.com> 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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org