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/06/16 12:26:14 UTC
Policy or other extensions to indicate persistent messaging
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
Re: Policy or other extensions to indicate persistent messaging
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Paul,
On Mon, Jun 16, 2008 at 8:12 AM, Paul Fremantle <pz...@gmail.com> wrote:
> Danushka
>
> I'm not clear I understand your point.
>
> Firstly, I was just using AMQP as an example - I didn't mean that we
> wanted to be exactly the same as AMQP or do anything with AMQP.
+1
I don't think Sandesha persistence should be bound to AMQP or any other
transport mechanism. On the other hand sandesha2 exposes an interface
(StoargeManager) which can be implemented using any transport mechanism.
>
> So firstly, in general, I don't believe that Sandesha2 can modify the
> persistence on a sequence by sequence basis - either it is on for a
> service or off. However, logically the sequence *is* the level at
> which persistence can be defined. So these are the options I see:
>
> * The server has persistence set permanently on for a service. It does
> not demand persistence from the client. It publishes a policy saying
> persistence is optional for the client. It accepts any sequence
> creation, and persistently stores messages. If the client "asks for
> persistence" during the create sequence, then it says "yes I'm
> persistent in reply" (by some yet to be determined mechanisms). This
> is how we operate today, except with the addition of the policy and
> the optional information passing during create sequence.
>
> * The server has persistence set permanently on for a service. It
> demands persistence from the client. Therefore it publishes a policy
> saying that client's must be persistent. During the CreateSequence
> exchange, it can refuse any client that doesn't agree (by some
> yet-to-be-defined mechanism) to be persistent. This would be a new
> capability.
>
> * The server has some clever ability to turn persistence on or off
> per-sequence based on the create sequence. In this model, the server
> picks up the preference from the client. So the same service might
> have some persistent and some non-persistent sequences. Maybe this is
> overkill and beyond the basic requirements. I'm not clear. However,
> this seems to be a model that other systems allow. Of course, a server
> could respond that it doesn't support this capability.
I think first approach is the best.
I think persistence should be a setting on the server. It is a feature of
the service and it is something that should be decided by the server admin
considering factors such as performance.
Secondly I don't think a server should reject a client simply because that
client does not have persistence. If a client does not have persistence that
client should know its limitations and should know that it cannot expect a
correct message exchange with client side failures.
Thanks,
Chamikara
>
>
> Ideally, all of this would be designed to allow backwards
> compatibility. So even in the cases where the server refuses a
> sequence because it requires persistence and the client doesn't
> support this extension, the failure is explained in the error and the
> administrator can see why.
>
> Paul
>
> On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura
> <da...@wso2.com> wrote:
> >
> >>>> 1) A policy element to indicate whether this endpoint supports and/or
> >>>> requires persistence
> >>>>
> >>>>
> >>>
> >>> (b) Even if we go for transport level persistence, the endpoint does
> not
> >>> have a say in it, because in AMQP we can have either queue level
> >>> persistence
> >>> (i.e. transport receiver level abstraction) or message level
> persistence
> >>> (i.e. message sender level abstraction).
> >>>
> >
> > Hi Paul,
> > But still this is not doable with AMQP.
> >
> > Danushka
> >
> >
>
>
>
> --
> 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>.
So as far as I'm concerned AMQP and RM are mutually exclusive
alternatives. If you want SOAP/AMQP then that gives a slightly
different model of reliability than WSRM.
I can't imagine using both.
Paul
On Mon, Jun 16, 2008 at 3:01 PM, Danushka Menikkumbura
<da...@wso2.com> wrote:
>
>> Danushka
>>
>> I'm not clear I understand your point.
>>
>> Firstly, I was just using AMQP as an example - I didn't mean that we
>> wanted to be exactly the same as AMQP or do anything with AMQP.
>>
>>
>
> Hi Paul,
> Of course I was under the impression that you are talking of something
> **exactly** similar to AMQP. Because I was thinking of ways to get AMQP for
> RM some time back as it has support for some of the key RM concepts like
> Transactions, Persistence and stuff like that.
>
> Danushka
>
>
> ---------------------------------------------------------------------
> 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 Danushka Menikkumbura <da...@wso2.com>.
> Danushka
>
> I'm not clear I understand your point.
>
> Firstly, I was just using AMQP as an example - I didn't mean that we
> wanted to be exactly the same as AMQP or do anything with AMQP.
>
>
Hi Paul,
Of course I was under the impression that you are talking of
something **exactly** similar to AMQP. Because I was thinking of ways to
get AMQP for RM some time back as it has support for some of the key RM
concepts like Transactions, Persistence and stuff like that.
Danushka
---------------------------------------------------------------------
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 Amila Suriarachchi <am...@gmail.com>.
+1 to add a policy to declare whether a service supports Persistence or not.
IMO if RM provides persistence then it should happen in both client and
server side.
But at the client side Application layer has to do some part as well.
In Mercury if a client dies when sending a sequence it can be restarted by
sending a message by setting a property called MercuryResumeSequence to
true.
But in this case Application client have to check how many messages it had
send to RM either by keeping a track of messages or by examining the Mercury
data base store.
thanks,
Amila.
On Tue, Jun 17, 2008 at 6:50 AM, Jaliya Ekanayake <jn...@gmail.com>
wrote:
> Hi Paul,
>
> I agree with the two scenarios you mentioned.
> So, if the majority of the use cases for RM are of the above type with long
> running communications, then we should stick to the persisted reliability in
> every usecase.
> Otherwise, I think we'd better keep the client side free from the mandatory
> database integration.
>
> Thanks,
> Jaliya
>
>
> ----- Original Message ----- From: "Paul Fremantle" <pz...@gmail.com>
> To: "Jaliya Ekanayake" <ja...@apache.org>
> Cc: <sa...@ws.apache.org>
> Sent: Monday, June 16, 2008 1:05 PM
>
> Subject: Re: Policy or other extensions to indicate persistent messaging
>
>
> Jaliya
>>
>> I agree that it is the responsibility of the client. But I'm worried
>> about two scenarios.
>>
>> 1) The client crashes and restarts - the server has missing messages
>> and without them it cannot deliver the later messages that it has.
>> 2) The client crashes and restarts - the server has responses stored,
>> ready to send, but the client has lost the sequence state and cannot
>> accept the stored messages.
>>
>> I still think that there is a requirement to ENSURE that a particular
>> communication is completely reliable.
>>
>> Paul
>>
>> On Mon, Jun 16, 2008 at 5:54 PM, Jaliya Ekanayake <jn...@gmail.com>
>> wrote:
>>
>>> Hi Paul,
>>>
>>> Please see my comments below.
>>>
>>> Thanks,
>>> Jaliya
>>> ----- Original Message ----- From: "Paul Fremantle" <pz...@gmail.com>
>>> To: "Jaliya Ekanayake" <ja...@apache.org>
>>> Sent: Monday, June 16, 2008 11:40 AM
>>> Subject: Re: Policy or other extensions to indicate persistent messaging
>>>
>>>
>>> Jaliya
>>>>
>>>> My idea is that the persistence is a feature that the admin can turn on
>>>>> or
>>>>> off per service.
>>>>>
>>>>
>>>> So I agree that it is a good feature to turn it on and off per
>>>> service, and that we support today. So for this model, what I am
>>>> proposing adding is the ability for the server to advertize that it
>>>> supports that.
>>>>
>>>> If it is to be per sequence, I think it will over
>>>>> complicate the handshakes.
>>>>>
>>>>
>>>> It will *complicate* the handshakes :) I agree. I think to say it
>>>> over-complicates the handshake is a subjective idea.
>>>>
>>>> I agree.
>>>
>>> Also, Sandesha should not impose restrictions to the clients based on
>>>>> their
>>>>> persistence settings.
>>>>>
>>>>
>>>> I don't agree. WSRM imposes plenty of restrictions on the client and
>>>> server. It is perfectly possible for a server to refuse to communicate
>>>> with a client that does not support RM. With WSRM 1.1 It is possible
>>>> for clients to demand that the server creates an association between
>>>> the sequence and a security session.
>>>>
>>>> If the server supports persistence but the client doesn't, then there
>>>> is no overall guarantee of reliability. So I believe that it ought to
>>>> be *possible* for a server to send CreateSequenceRefused if it
>>>> *requires* persistence and the client cannot provide it. Of course
>>>> that should be configured by the server. Similarly the client should
>>>> be able to demand (like a mustUnderstand) that the server provides a
>>>> persistent capability.
>>>>
>>>> Why do I want this? Almost every customer I talk to says that WSRM
>>>> without persistence is basically pointless.
>>>>
>>>
>>> I totally agree with this. Without persistance, I can almost trust TCP
>>> for
>>> the reliability. (not for the multi-transport multi-hop cases)
>>> So we need persistance for *real* use cases.
>>>
>>> The blogging from people
>>>
>>>>
>>>> who believe that WSRM should not support persistence has - in my view
>>>> - been very harmful to the adoption of the spec. Now the normal
>>>> argument is that "you can support persistence if you need it". But
>>>> frankly, that is a weak argument, because in a real distributed SOA
>>>> you cannot (at the moment) know if there is persistence involved,
>>>> except maybe by phoning up the sysadmin at the other end. So if you
>>>> require proper persistent reliability then you need a way of agreeing
>>>> between both parties that it exists. Now WSRM has the perfect model
>>>> for this negotiation - the CreateSequence/CSResponse. This ability to
>>>> negotiate details is perfect for this, and I don't see any problem
>>>> extending it to support this.
>>>>
>>>>
>>> I agree that the Client should be able to request persistence from a
>>> Service, but I still don' t understand why we need the server to reject a
>>> client if it does not support persistence.
>>> Here is a scenario.
>>>
>>> Say we have two companies A and B that perform some communications over
>>> snail mail.
>>> All the mails received by the company B first go through its mail
>>> processing
>>> system (MPS) which keeps information on all the mails received, and also
>>> keeps a copy of them.
>>> All the mails sent by the company B also go through the same MPS.
>>>
>>> Company A is not that sophisticated in its operations. They don't simply
>>> have a system as above.
>>>
>>> Now consider the communications that could happen.
>>>
>>> 1. A sends a mail to B
>>> If this reach B, things are fine.
>>> If this does not reach B then it is a problem of A. A should keep a copy
>>> so
>>> that it can send it again.
>>>
>>>
>>> 2. B sends a mail to A as a response to A's request
>>> If this reach A and processed by A things are fine
>>> If this reach A but not processed by A, then B can send it again. (up to
>>> some number of times)
>>> If this does not reach A, B can still send it again.
>>>
>>> 3. B needs to send a mail to A requesting something. (Now A is the
>>> service
>>> provider)
>>> In this case B can request that A provides the necessary reliability to
>>> its
>>> requests.
>>> If A does not support it, B should not proceed.
>>>
>>> Therefore, IMO the client does not need to have a real persistence to use
>>> a
>>> service offered with persisted reliability, but it can request this
>>> feature
>>> from the service.
>>>
>>> Let me know your thoughts. probably I have missed some use case.
>>>
>>> Thanks,
>>> Jaliya
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Say, the server supports persistance. In that case, any request sent by
>>> the
>>> client is guranteed to be served.
>>>
>>>
>>>
>>>
>>>
>>> Paul
>>>>
>>>> , but we can advertise that we have persistence for this
>>>>
>>>>>
>>>>> service.
>>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Jaliya
>>>>>
>>>>> ----- Original Message ----- From: "Paul Fremantle" <pz...@gmail.com>
>>>>> To: "Danushka Menikkumbura" <da...@wso2.com>
>>>>> Cc: <sa...@ws.apache.org>
>>>>> Sent: Monday, June 16, 2008 8:12 AM
>>>>> Subject: Re: Policy or other extensions to indicate persistent
>>>>> messaging
>>>>>
>>>>>
>>>>> Danushka
>>>>>>
>>>>>> I'm not clear I understand your point.
>>>>>>
>>>>>> Firstly, I was just using AMQP as an example - I didn't mean that we
>>>>>> wanted to be exactly the same as AMQP or do anything with AMQP.
>>>>>>
>>>>>> So firstly, in general, I don't believe that Sandesha2 can modify the
>>>>>> persistence on a sequence by sequence basis - either it is on for a
>>>>>> service or off. However, logically the sequence *is* the level at
>>>>>> which persistence can be defined. So these are the options I see:
>>>>>>
>>>>>> * The server has persistence set permanently on for a service. It does
>>>>>> not demand persistence from the client. It publishes a policy saying
>>>>>> persistence is optional for the client. It accepts any sequence
>>>>>> creation, and persistently stores messages. If the client "asks for
>>>>>> persistence" during the create sequence, then it says "yes I'm
>>>>>> persistent in reply" (by some yet to be determined mechanisms). This
>>>>>> is how we operate today, except with the addition of the policy and
>>>>>> the optional information passing during create sequence.
>>>>>>
>>>>>> * The server has persistence set permanently on for a service. It
>>>>>> demands persistence from the client. Therefore it publishes a policy
>>>>>> saying that client's must be persistent. During the CreateSequence
>>>>>> exchange, it can refuse any client that doesn't agree (by some
>>>>>> yet-to-be-defined mechanism) to be persistent. This would be a new
>>>>>> capability.
>>>>>>
>>>>>> * The server has some clever ability to turn persistence on or off
>>>>>> per-sequence based on the create sequence. In this model, the server
>>>>>> picks up the preference from the client. So the same service might
>>>>>> have some persistent and some non-persistent sequences. Maybe this is
>>>>>> overkill and beyond the basic requirements. I'm not clear. However,
>>>>>> this seems to be a model that other systems allow. Of course, a server
>>>>>> could respond that it doesn't support this capability.
>>>>>>
>>>>>> Ideally, all of this would be designed to allow backwards
>>>>>> compatibility. So even in the cases where the server refuses a
>>>>>> sequence because it requires persistence and the client doesn't
>>>>>> support this extension, the failure is explained in the error and the
>>>>>> administrator can see why.
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura
>>>>>> <da...@wso2.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> 1) A policy element to indicate whether this endpoint supports
>>>>>>>>>> and/or
>>>>>>>>>> requires persistence
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> (b) Even if we go for transport level persistence, the endpoint
>>>>>>>>> does
>>>>>>>>> not
>>>>>>>>> have a say in it, because in AMQP we can have either queue level
>>>>>>>>> persistence
>>>>>>>>> (i.e. transport receiver level abstraction) or message level
>>>>>>>>> persistence
>>>>>>>>> (i.e. message sender level abstraction).
>>>>>>>>>
>>>>>>>>>
>>>>>>> Hi Paul,
>>>>>>> But still this is not doable with AMQP.
>>>>>>>
>>>>>>> Danushka
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Policy or other extensions to indicate persistent messaging
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
I agree with the two scenarios you mentioned.
So, if the majority of the use cases for RM are of the above type with long
running communications, then we should stick to the persisted reliability in
every usecase.
Otherwise, I think we'd better keep the client side free from the mandatory
database integration.
Thanks,
Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: "Jaliya Ekanayake" <ja...@apache.org>
Cc: <sa...@ws.apache.org>
Sent: Monday, June 16, 2008 1:05 PM
Subject: Re: Policy or other extensions to indicate persistent messaging
> Jaliya
>
> I agree that it is the responsibility of the client. But I'm worried
> about two scenarios.
>
> 1) The client crashes and restarts - the server has missing messages
> and without them it cannot deliver the later messages that it has.
> 2) The client crashes and restarts - the server has responses stored,
> ready to send, but the client has lost the sequence state and cannot
> accept the stored messages.
>
> I still think that there is a requirement to ENSURE that a particular
> communication is completely reliable.
>
> Paul
>
> On Mon, Jun 16, 2008 at 5:54 PM, Jaliya Ekanayake <jn...@gmail.com>
> wrote:
>> Hi Paul,
>>
>> Please see my comments below.
>>
>> Thanks,
>> Jaliya
>> ----- Original Message ----- From: "Paul Fremantle" <pz...@gmail.com>
>> To: "Jaliya Ekanayake" <ja...@apache.org>
>> Sent: Monday, June 16, 2008 11:40 AM
>> Subject: Re: Policy or other extensions to indicate persistent messaging
>>
>>
>>> Jaliya
>>>
>>>> My idea is that the persistence is a feature that the admin can turn on
>>>> or
>>>> off per service.
>>>
>>> So I agree that it is a good feature to turn it on and off per
>>> service, and that we support today. So for this model, what I am
>>> proposing adding is the ability for the server to advertize that it
>>> supports that.
>>>
>>>> If it is to be per sequence, I think it will over
>>>> complicate the handshakes.
>>>
>>> It will *complicate* the handshakes :) I agree. I think to say it
>>> over-complicates the handshake is a subjective idea.
>>>
>> I agree.
>>
>>>> Also, Sandesha should not impose restrictions to the clients based on
>>>> their
>>>> persistence settings.
>>>
>>> I don't agree. WSRM imposes plenty of restrictions on the client and
>>> server. It is perfectly possible for a server to refuse to communicate
>>> with a client that does not support RM. With WSRM 1.1 It is possible
>>> for clients to demand that the server creates an association between
>>> the sequence and a security session.
>>>
>>> If the server supports persistence but the client doesn't, then there
>>> is no overall guarantee of reliability. So I believe that it ought to
>>> be *possible* for a server to send CreateSequenceRefused if it
>>> *requires* persistence and the client cannot provide it. Of course
>>> that should be configured by the server. Similarly the client should
>>> be able to demand (like a mustUnderstand) that the server provides a
>>> persistent capability.
>>>
>>> Why do I want this? Almost every customer I talk to says that WSRM
>>> without persistence is basically pointless.
>>
>> I totally agree with this. Without persistance, I can almost trust TCP
>> for
>> the reliability. (not for the multi-transport multi-hop cases)
>> So we need persistance for *real* use cases.
>>
>> The blogging from people
>>>
>>> who believe that WSRM should not support persistence has - in my view
>>> - been very harmful to the adoption of the spec. Now the normal
>>> argument is that "you can support persistence if you need it". But
>>> frankly, that is a weak argument, because in a real distributed SOA
>>> you cannot (at the moment) know if there is persistence involved,
>>> except maybe by phoning up the sysadmin at the other end. So if you
>>> require proper persistent reliability then you need a way of agreeing
>>> between both parties that it exists. Now WSRM has the perfect model
>>> for this negotiation - the CreateSequence/CSResponse. This ability to
>>> negotiate details is perfect for this, and I don't see any problem
>>> extending it to support this.
>>>
>>
>> I agree that the Client should be able to request persistence from a
>> Service, but I still don' t understand why we need the server to reject a
>> client if it does not support persistence.
>> Here is a scenario.
>>
>> Say we have two companies A and B that perform some communications over
>> snail mail.
>> All the mails received by the company B first go through its mail
>> processing
>> system (MPS) which keeps information on all the mails received, and also
>> keeps a copy of them.
>> All the mails sent by the company B also go through the same MPS.
>>
>> Company A is not that sophisticated in its operations. They don't simply
>> have a system as above.
>>
>> Now consider the communications that could happen.
>>
>> 1. A sends a mail to B
>> If this reach B, things are fine.
>> If this does not reach B then it is a problem of A. A should keep a copy
>> so
>> that it can send it again.
>>
>>
>> 2. B sends a mail to A as a response to A's request
>> If this reach A and processed by A things are fine
>> If this reach A but not processed by A, then B can send it again. (up to
>> some number of times)
>> If this does not reach A, B can still send it again.
>>
>> 3. B needs to send a mail to A requesting something. (Now A is the
>> service
>> provider)
>> In this case B can request that A provides the necessary reliability to
>> its
>> requests.
>> If A does not support it, B should not proceed.
>>
>> Therefore, IMO the client does not need to have a real persistence to use
>> a
>> service offered with persisted reliability, but it can request this
>> feature
>> from the service.
>>
>> Let me know your thoughts. probably I have missed some use case.
>>
>> Thanks,
>> Jaliya
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Say, the server supports persistance. In that case, any request sent by
>> the
>> client is guranteed to be served.
>>
>>
>>
>>
>>
>>> Paul
>>>
>>> , but we can advertise that we have persistence for this
>>>>
>>>> service.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Jaliya
>>>>
>>>> ----- Original Message ----- From: "Paul Fremantle" <pz...@gmail.com>
>>>> To: "Danushka Menikkumbura" <da...@wso2.com>
>>>> Cc: <sa...@ws.apache.org>
>>>> Sent: Monday, June 16, 2008 8:12 AM
>>>> Subject: Re: Policy or other extensions to indicate persistent
>>>> messaging
>>>>
>>>>
>>>>> Danushka
>>>>>
>>>>> I'm not clear I understand your point.
>>>>>
>>>>> Firstly, I was just using AMQP as an example - I didn't mean that we
>>>>> wanted to be exactly the same as AMQP or do anything with AMQP.
>>>>>
>>>>> So firstly, in general, I don't believe that Sandesha2 can modify the
>>>>> persistence on a sequence by sequence basis - either it is on for a
>>>>> service or off. However, logically the sequence *is* the level at
>>>>> which persistence can be defined. So these are the options I see:
>>>>>
>>>>> * The server has persistence set permanently on for a service. It does
>>>>> not demand persistence from the client. It publishes a policy saying
>>>>> persistence is optional for the client. It accepts any sequence
>>>>> creation, and persistently stores messages. If the client "asks for
>>>>> persistence" during the create sequence, then it says "yes I'm
>>>>> persistent in reply" (by some yet to be determined mechanisms). This
>>>>> is how we operate today, except with the addition of the policy and
>>>>> the optional information passing during create sequence.
>>>>>
>>>>> * The server has persistence set permanently on for a service. It
>>>>> demands persistence from the client. Therefore it publishes a policy
>>>>> saying that client's must be persistent. During the CreateSequence
>>>>> exchange, it can refuse any client that doesn't agree (by some
>>>>> yet-to-be-defined mechanism) to be persistent. This would be a new
>>>>> capability.
>>>>>
>>>>> * The server has some clever ability to turn persistence on or off
>>>>> per-sequence based on the create sequence. In this model, the server
>>>>> picks up the preference from the client. So the same service might
>>>>> have some persistent and some non-persistent sequences. Maybe this is
>>>>> overkill and beyond the basic requirements. I'm not clear. However,
>>>>> this seems to be a model that other systems allow. Of course, a server
>>>>> could respond that it doesn't support this capability.
>>>>>
>>>>> Ideally, all of this would be designed to allow backwards
>>>>> compatibility. So even in the cases where the server refuses a
>>>>> sequence because it requires persistence and the client doesn't
>>>>> support this extension, the failure is explained in the error and the
>>>>> administrator can see why.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura
>>>>> <da...@wso2.com> wrote:
>>>>>>
>>>>>>>>> 1) A policy element to indicate whether this endpoint supports
>>>>>>>>> and/or
>>>>>>>>> requires persistence
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> (b) Even if we go for transport level persistence, the endpoint
>>>>>>>> does
>>>>>>>> not
>>>>>>>> have a say in it, because in AMQP we can have either queue level
>>>>>>>> persistence
>>>>>>>> (i.e. transport receiver level abstraction) or message level
>>>>>>>> persistence
>>>>>>>> (i.e. message sender level abstraction).
>>>>>>>>
>>>>>>
>>>>>> Hi Paul,
>>>>>> But still this is not doable with AMQP.
>>>>>>
>>>>>> Danushka
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>
---------------------------------------------------------------------
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>.
Jaliya
I agree that it is the responsibility of the client. But I'm worried
about two scenarios.
1) The client crashes and restarts - the server has missing messages
and without them it cannot deliver the later messages that it has.
2) The client crashes and restarts - the server has responses stored,
ready to send, but the client has lost the sequence state and cannot
accept the stored messages.
I still think that there is a requirement to ENSURE that a particular
communication is completely reliable.
Paul
On Mon, Jun 16, 2008 at 5:54 PM, Jaliya Ekanayake <jn...@gmail.com> wrote:
> Hi Paul,
>
> Please see my comments below.
>
> Thanks,
> Jaliya
> ----- Original Message ----- From: "Paul Fremantle" <pz...@gmail.com>
> To: "Jaliya Ekanayake" <ja...@apache.org>
> Sent: Monday, June 16, 2008 11:40 AM
> Subject: Re: Policy or other extensions to indicate persistent messaging
>
>
>> Jaliya
>>
>>> My idea is that the persistence is a feature that the admin can turn on
>>> or
>>> off per service.
>>
>> So I agree that it is a good feature to turn it on and off per
>> service, and that we support today. So for this model, what I am
>> proposing adding is the ability for the server to advertize that it
>> supports that.
>>
>>> If it is to be per sequence, I think it will over
>>> complicate the handshakes.
>>
>> It will *complicate* the handshakes :) I agree. I think to say it
>> over-complicates the handshake is a subjective idea.
>>
> I agree.
>
>>> Also, Sandesha should not impose restrictions to the clients based on
>>> their
>>> persistence settings.
>>
>> I don't agree. WSRM imposes plenty of restrictions on the client and
>> server. It is perfectly possible for a server to refuse to communicate
>> with a client that does not support RM. With WSRM 1.1 It is possible
>> for clients to demand that the server creates an association between
>> the sequence and a security session.
>>
>> If the server supports persistence but the client doesn't, then there
>> is no overall guarantee of reliability. So I believe that it ought to
>> be *possible* for a server to send CreateSequenceRefused if it
>> *requires* persistence and the client cannot provide it. Of course
>> that should be configured by the server. Similarly the client should
>> be able to demand (like a mustUnderstand) that the server provides a
>> persistent capability.
>>
>> Why do I want this? Almost every customer I talk to says that WSRM
>> without persistence is basically pointless.
>
> I totally agree with this. Without persistance, I can almost trust TCP for
> the reliability. (not for the multi-transport multi-hop cases)
> So we need persistance for *real* use cases.
>
> The blogging from people
>>
>> who believe that WSRM should not support persistence has - in my view
>> - been very harmful to the adoption of the spec. Now the normal
>> argument is that "you can support persistence if you need it". But
>> frankly, that is a weak argument, because in a real distributed SOA
>> you cannot (at the moment) know if there is persistence involved,
>> except maybe by phoning up the sysadmin at the other end. So if you
>> require proper persistent reliability then you need a way of agreeing
>> between both parties that it exists. Now WSRM has the perfect model
>> for this negotiation - the CreateSequence/CSResponse. This ability to
>> negotiate details is perfect for this, and I don't see any problem
>> extending it to support this.
>>
>
> I agree that the Client should be able to request persistence from a
> Service, but I still don' t understand why we need the server to reject a
> client if it does not support persistence.
> Here is a scenario.
>
> Say we have two companies A and B that perform some communications over
> snail mail.
> All the mails received by the company B first go through its mail processing
> system (MPS) which keeps information on all the mails received, and also
> keeps a copy of them.
> All the mails sent by the company B also go through the same MPS.
>
> Company A is not that sophisticated in its operations. They don't simply
> have a system as above.
>
> Now consider the communications that could happen.
>
> 1. A sends a mail to B
> If this reach B, things are fine.
> If this does not reach B then it is a problem of A. A should keep a copy so
> that it can send it again.
>
>
> 2. B sends a mail to A as a response to A's request
> If this reach A and processed by A things are fine
> If this reach A but not processed by A, then B can send it again. (up to
> some number of times)
> If this does not reach A, B can still send it again.
>
> 3. B needs to send a mail to A requesting something. (Now A is the service
> provider)
> In this case B can request that A provides the necessary reliability to its
> requests.
> If A does not support it, B should not proceed.
>
> Therefore, IMO the client does not need to have a real persistence to use a
> service offered with persisted reliability, but it can request this feature
> from the service.
>
> Let me know your thoughts. probably I have missed some use case.
>
> Thanks,
> Jaliya
>
>
>
>
>
>
>
>
>
>
>
> Say, the server supports persistance. In that case, any request sent by the
> client is guranteed to be served.
>
>
>
>
>
>> Paul
>>
>> , but we can advertise that we have persistence for this
>>>
>>> service.
>>
>>
>>>
>>> Thanks,
>>> Jaliya
>>>
>>> ----- Original Message ----- From: "Paul Fremantle" <pz...@gmail.com>
>>> To: "Danushka Menikkumbura" <da...@wso2.com>
>>> Cc: <sa...@ws.apache.org>
>>> Sent: Monday, June 16, 2008 8:12 AM
>>> Subject: Re: Policy or other extensions to indicate persistent messaging
>>>
>>>
>>>> Danushka
>>>>
>>>> I'm not clear I understand your point.
>>>>
>>>> Firstly, I was just using AMQP as an example - I didn't mean that we
>>>> wanted to be exactly the same as AMQP or do anything with AMQP.
>>>>
>>>> So firstly, in general, I don't believe that Sandesha2 can modify the
>>>> persistence on a sequence by sequence basis - either it is on for a
>>>> service or off. However, logically the sequence *is* the level at
>>>> which persistence can be defined. So these are the options I see:
>>>>
>>>> * The server has persistence set permanently on for a service. It does
>>>> not demand persistence from the client. It publishes a policy saying
>>>> persistence is optional for the client. It accepts any sequence
>>>> creation, and persistently stores messages. If the client "asks for
>>>> persistence" during the create sequence, then it says "yes I'm
>>>> persistent in reply" (by some yet to be determined mechanisms). This
>>>> is how we operate today, except with the addition of the policy and
>>>> the optional information passing during create sequence.
>>>>
>>>> * The server has persistence set permanently on for a service. It
>>>> demands persistence from the client. Therefore it publishes a policy
>>>> saying that client's must be persistent. During the CreateSequence
>>>> exchange, it can refuse any client that doesn't agree (by some
>>>> yet-to-be-defined mechanism) to be persistent. This would be a new
>>>> capability.
>>>>
>>>> * The server has some clever ability to turn persistence on or off
>>>> per-sequence based on the create sequence. In this model, the server
>>>> picks up the preference from the client. So the same service might
>>>> have some persistent and some non-persistent sequences. Maybe this is
>>>> overkill and beyond the basic requirements. I'm not clear. However,
>>>> this seems to be a model that other systems allow. Of course, a server
>>>> could respond that it doesn't support this capability.
>>>>
>>>> Ideally, all of this would be designed to allow backwards
>>>> compatibility. So even in the cases where the server refuses a
>>>> sequence because it requires persistence and the client doesn't
>>>> support this extension, the failure is explained in the error and the
>>>> administrator can see why.
>>>>
>>>> Paul
>>>>
>>>> On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura
>>>> <da...@wso2.com> wrote:
>>>>>
>>>>>>>> 1) A policy element to indicate whether this endpoint supports
>>>>>>>> and/or
>>>>>>>> requires persistence
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> (b) Even if we go for transport level persistence, the endpoint does
>>>>>>> not
>>>>>>> have a say in it, because in AMQP we can have either queue level
>>>>>>> persistence
>>>>>>> (i.e. transport receiver level abstraction) or message level
>>>>>>> persistence
>>>>>>> (i.e. message sender level abstraction).
>>>>>>>
>>>>>
>>>>> Hi Paul,
>>>>> But still this is not doable with AMQP.
>>>>>
>>>>> Danushka
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>
>>
>>
>> --
>> 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 Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
Please see my comments below.
Thanks,
Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: "Jaliya Ekanayake" <ja...@apache.org>
Sent: Monday, June 16, 2008 11:40 AM
Subject: Re: Policy or other extensions to indicate persistent messaging
> Jaliya
>
>> My idea is that the persistence is a feature that the admin can turn on
>> or
>> off per service.
>
> So I agree that it is a good feature to turn it on and off per
> service, and that we support today. So for this model, what I am
> proposing adding is the ability for the server to advertize that it
> supports that.
>
>> If it is to be per sequence, I think it will over
>> complicate the handshakes.
>
> It will *complicate* the handshakes :) I agree. I think to say it
> over-complicates the handshake is a subjective idea.
>
I agree.
>> Also, Sandesha should not impose restrictions to the clients based on
>> their
>> persistence settings.
>
> I don't agree. WSRM imposes plenty of restrictions on the client and
> server. It is perfectly possible for a server to refuse to communicate
> with a client that does not support RM. With WSRM 1.1 It is possible
> for clients to demand that the server creates an association between
> the sequence and a security session.
>
> If the server supports persistence but the client doesn't, then there
> is no overall guarantee of reliability. So I believe that it ought to
> be *possible* for a server to send CreateSequenceRefused if it
> *requires* persistence and the client cannot provide it. Of course
> that should be configured by the server. Similarly the client should
> be able to demand (like a mustUnderstand) that the server provides a
> persistent capability.
>
> Why do I want this? Almost every customer I talk to says that WSRM
> without persistence is basically pointless.
I totally agree with this. Without persistance, I can almost trust TCP for
the reliability. (not for the multi-transport multi-hop cases)
So we need persistance for *real* use cases.
The blogging from people
> who believe that WSRM should not support persistence has - in my view
> - been very harmful to the adoption of the spec. Now the normal
> argument is that "you can support persistence if you need it". But
> frankly, that is a weak argument, because in a real distributed SOA
> you cannot (at the moment) know if there is persistence involved,
> except maybe by phoning up the sysadmin at the other end. So if you
> require proper persistent reliability then you need a way of agreeing
> between both parties that it exists. Now WSRM has the perfect model
> for this negotiation - the CreateSequence/CSResponse. This ability to
> negotiate details is perfect for this, and I don't see any problem
> extending it to support this.
>
I agree that the Client should be able to request persistence from a
Service, but I still don' t understand why we need the server to reject a
client if it does not support persistence.
Here is a scenario.
Say we have two companies A and B that perform some communications over
snail mail.
All the mails received by the company B first go through its mail processing
system (MPS) which keeps information on all the mails received, and also
keeps a copy of them.
All the mails sent by the company B also go through the same MPS.
Company A is not that sophisticated in its operations. They don't simply
have a system as above.
Now consider the communications that could happen.
1. A sends a mail to B
If this reach B, things are fine.
If this does not reach B then it is a problem of A. A should keep a copy so
that it can send it again.
2. B sends a mail to A as a response to A's request
If this reach A and processed by A things are fine
If this reach A but not processed by A, then B can send it again. (up to
some number of times)
If this does not reach A, B can still send it again.
3. B needs to send a mail to A requesting something. (Now A is the service
provider)
In this case B can request that A provides the necessary reliability to its
requests.
If A does not support it, B should not proceed.
Therefore, IMO the client does not need to have a real persistence to use a
service offered with persisted reliability, but it can request this feature
from the service.
Let me know your thoughts. probably I have missed some use case.
Thanks,
Jaliya
Say, the server supports persistance. In that case, any request sent by the
client is guranteed to be served.
> Paul
>
> , but we can advertise that we have persistence for this
>> service.
>
>
>>
>> Thanks,
>> Jaliya
>>
>> ----- Original Message ----- From: "Paul Fremantle" <pz...@gmail.com>
>> To: "Danushka Menikkumbura" <da...@wso2.com>
>> Cc: <sa...@ws.apache.org>
>> Sent: Monday, June 16, 2008 8:12 AM
>> Subject: Re: Policy or other extensions to indicate persistent messaging
>>
>>
>>> Danushka
>>>
>>> I'm not clear I understand your point.
>>>
>>> Firstly, I was just using AMQP as an example - I didn't mean that we
>>> wanted to be exactly the same as AMQP or do anything with AMQP.
>>>
>>> So firstly, in general, I don't believe that Sandesha2 can modify the
>>> persistence on a sequence by sequence basis - either it is on for a
>>> service or off. However, logically the sequence *is* the level at
>>> which persistence can be defined. So these are the options I see:
>>>
>>> * The server has persistence set permanently on for a service. It does
>>> not demand persistence from the client. It publishes a policy saying
>>> persistence is optional for the client. It accepts any sequence
>>> creation, and persistently stores messages. If the client "asks for
>>> persistence" during the create sequence, then it says "yes I'm
>>> persistent in reply" (by some yet to be determined mechanisms). This
>>> is how we operate today, except with the addition of the policy and
>>> the optional information passing during create sequence.
>>>
>>> * The server has persistence set permanently on for a service. It
>>> demands persistence from the client. Therefore it publishes a policy
>>> saying that client's must be persistent. During the CreateSequence
>>> exchange, it can refuse any client that doesn't agree (by some
>>> yet-to-be-defined mechanism) to be persistent. This would be a new
>>> capability.
>>>
>>> * The server has some clever ability to turn persistence on or off
>>> per-sequence based on the create sequence. In this model, the server
>>> picks up the preference from the client. So the same service might
>>> have some persistent and some non-persistent sequences. Maybe this is
>>> overkill and beyond the basic requirements. I'm not clear. However,
>>> this seems to be a model that other systems allow. Of course, a server
>>> could respond that it doesn't support this capability.
>>>
>>> Ideally, all of this would be designed to allow backwards
>>> compatibility. So even in the cases where the server refuses a
>>> sequence because it requires persistence and the client doesn't
>>> support this extension, the failure is explained in the error and the
>>> administrator can see why.
>>>
>>> Paul
>>>
>>> On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura
>>> <da...@wso2.com> wrote:
>>>>
>>>>>>> 1) A policy element to indicate whether this endpoint supports
>>>>>>> and/or
>>>>>>> requires persistence
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> (b) Even if we go for transport level persistence, the endpoint does
>>>>>> not
>>>>>> have a say in it, because in AMQP we can have either queue level
>>>>>> persistence
>>>>>> (i.e. transport receiver level abstraction) or message level
>>>>>> persistence
>>>>>> (i.e. message sender level abstraction).
>>>>>>
>>>>
>>>> Hi Paul,
>>>> But still this is not doable with AMQP.
>>>>
>>>> Danushka
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>
>
>
> --
> 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 Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
My idea is that the persistence is a feature that the admin can turn on or
off per service. If it is to be per sequence, I think it will over
complicate the handshakes.
Also, Sandesha should not impose restrictions to the clients based on their
persistence settings, but we can advertise that we have persistence for this
service.
Thanks,
Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: "Danushka Menikkumbura" <da...@wso2.com>
Cc: <sa...@ws.apache.org>
Sent: Monday, June 16, 2008 8:12 AM
Subject: Re: Policy or other extensions to indicate persistent messaging
> Danushka
>
> I'm not clear I understand your point.
>
> Firstly, I was just using AMQP as an example - I didn't mean that we
> wanted to be exactly the same as AMQP or do anything with AMQP.
>
> So firstly, in general, I don't believe that Sandesha2 can modify the
> persistence on a sequence by sequence basis - either it is on for a
> service or off. However, logically the sequence *is* the level at
> which persistence can be defined. So these are the options I see:
>
> * The server has persistence set permanently on for a service. It does
> not demand persistence from the client. It publishes a policy saying
> persistence is optional for the client. It accepts any sequence
> creation, and persistently stores messages. If the client "asks for
> persistence" during the create sequence, then it says "yes I'm
> persistent in reply" (by some yet to be determined mechanisms). This
> is how we operate today, except with the addition of the policy and
> the optional information passing during create sequence.
>
> * The server has persistence set permanently on for a service. It
> demands persistence from the client. Therefore it publishes a policy
> saying that client's must be persistent. During the CreateSequence
> exchange, it can refuse any client that doesn't agree (by some
> yet-to-be-defined mechanism) to be persistent. This would be a new
> capability.
>
> * The server has some clever ability to turn persistence on or off
> per-sequence based on the create sequence. In this model, the server
> picks up the preference from the client. So the same service might
> have some persistent and some non-persistent sequences. Maybe this is
> overkill and beyond the basic requirements. I'm not clear. However,
> this seems to be a model that other systems allow. Of course, a server
> could respond that it doesn't support this capability.
>
> Ideally, all of this would be designed to allow backwards
> compatibility. So even in the cases where the server refuses a
> sequence because it requires persistence and the client doesn't
> support this extension, the failure is explained in the error and the
> administrator can see why.
>
> Paul
>
> On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura
> <da...@wso2.com> wrote:
>>
>>>>> 1) A policy element to indicate whether this endpoint supports and/or
>>>>> requires persistence
>>>>>
>>>>>
>>>>
>>>> (b) Even if we go for transport level persistence, the endpoint does
>>>> not
>>>> have a say in it, because in AMQP we can have either queue level
>>>> persistence
>>>> (i.e. transport receiver level abstraction) or message level
>>>> persistence
>>>> (i.e. message sender level abstraction).
>>>>
>>
>> Hi Paul,
>> But still this is not doable with AMQP.
>>
>> Danushka
>>
>>
>
>
>
> --
> 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
Re: Policy or other extensions to indicate persistent messaging
Posted by Paul Fremantle <pz...@gmail.com>.
Danushka
I'm not clear I understand your point.
Firstly, I was just using AMQP as an example - I didn't mean that we
wanted to be exactly the same as AMQP or do anything with AMQP.
So firstly, in general, I don't believe that Sandesha2 can modify the
persistence on a sequence by sequence basis - either it is on for a
service or off. However, logically the sequence *is* the level at
which persistence can be defined. So these are the options I see:
* The server has persistence set permanently on for a service. It does
not demand persistence from the client. It publishes a policy saying
persistence is optional for the client. It accepts any sequence
creation, and persistently stores messages. If the client "asks for
persistence" during the create sequence, then it says "yes I'm
persistent in reply" (by some yet to be determined mechanisms). This
is how we operate today, except with the addition of the policy and
the optional information passing during create sequence.
* The server has persistence set permanently on for a service. It
demands persistence from the client. Therefore it publishes a policy
saying that client's must be persistent. During the CreateSequence
exchange, it can refuse any client that doesn't agree (by some
yet-to-be-defined mechanism) to be persistent. This would be a new
capability.
* The server has some clever ability to turn persistence on or off
per-sequence based on the create sequence. In this model, the server
picks up the preference from the client. So the same service might
have some persistent and some non-persistent sequences. Maybe this is
overkill and beyond the basic requirements. I'm not clear. However,
this seems to be a model that other systems allow. Of course, a server
could respond that it doesn't support this capability.
Ideally, all of this would be designed to allow backwards
compatibility. So even in the cases where the server refuses a
sequence because it requires persistence and the client doesn't
support this extension, the failure is explained in the error and the
administrator can see why.
Paul
On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura
<da...@wso2.com> wrote:
>
>>>> 1) A policy element to indicate whether this endpoint supports and/or
>>>> requires persistence
>>>>
>>>>
>>>
>>> (b) Even if we go for transport level persistence, the endpoint does not
>>> have a say in it, because in AMQP we can have either queue level
>>> persistence
>>> (i.e. transport receiver level abstraction) or message level persistence
>>> (i.e. message sender level abstraction).
>>>
>
> Hi Paul,
> But still this is not doable with AMQP.
>
> Danushka
>
>
--
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 Danushka Menikkumbura <da...@wso2.com>.
>>> 1) A policy element to indicate whether this endpoint supports and/or
>>> requires persistence
>>>
>>>
>> (b) Even if we go for transport level persistence, the endpoint does not
>> have a say in it, because in AMQP we can have either queue level persistence
>> (i.e. transport receiver level abstraction) or message level persistence
>> (i.e. message sender level abstraction).
>>
Hi Paul,
But still this is not doable with AMQP.
Danushka
---------------------------------------------------------------------
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>.
Danushka
I don't agree that Sandesha is at the application level. The WSRM
delivery assurances are explicitly NOT at the application level. The
acknowledgement that goes back to the sender is an acknowledgement
that the WSRM agent has received the message NOT that the application
has received the message. Therefore WSRM persistence is about
transport level persistence.
Paul
On Mon, Jun 16, 2008 at 12:03 PM, Danushka Menikkumbura
<da...@wso2.com> wrote:
> Hi Paul,
> I have a couple of questions.
>
> (a) If we go for something like AMQP, which is at the transport level, we do
> not have to couple persistence with Sandesha, which is at the application
> level. That means we can make the messages persistent at the transport level
> itself.
>>
>> 1) A policy element to indicate whether this endpoint supports and/or
>> requires persistence
>>
>
> (b) Even if we go for transport level persistence, the endpoint does not
> have a say in it, because in AMQP we can have either queue level persistence
> (i.e. transport receiver level abstraction) or message level persistence
> (i.e. message sender level abstraction).
>>
>> 2) An exchange that happens at create sequence time that indicates
>> whether this sequence should/must be persistent
>>
>>
>
> Closely relates to my question (a).
>
> Regards,
>
> Danushka
>
>
>
--
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 Danushka Menikkumbura <da...@wso2.com>.
Hi Paul,
I have a couple of questions.
(a) If we go for something like AMQP, which is at the transport level,
we do not have to couple persistence with Sandesha, which is at the
application level. That means we can make the messages persistent at the
transport level itself.
> 1) A policy element to indicate whether this endpoint supports and/or
> requires persistence
>
(b) Even if we go for transport level persistence, the endpoint does not
have a say in it, because in AMQP we can have either queue level
persistence (i.e. transport receiver level abstraction) or message level
persistence (i.e. message sender level abstraction).
> 2) An exchange that happens at create sequence time that indicates
> whether this sequence should/must be persistent
>
>
Closely relates to my question (a).
Regards,
Danushka
---------------------------------------------------------------------
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
Re: Policy or other extensions to indicate persistent messaging
Posted by Paul Fremantle <pz...@gmail.com>.
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 David Illsley <da...@gmail.com>.
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
Re: Policy or other extensions to indicate persistent messaging
Posted by Doug Davis <du...@us.ibm.com>.
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
Re: Policy or other extensions to indicate persistent messaging
Posted by Paul Fremantle <pz...@gmail.com>.
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
Re: Policy or other extensions to indicate persistent messaging
Posted by David Illsley <da...@gmail.com>.
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
Re: Policy or other extensions to indicate persistent messaging
Posted by Doug Davis <du...@us.ibm.com>.
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
Re: Policy or other extensions to indicate persistent messaging
Posted by Paul Fremantle <pz...@gmail.com>.
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
Re: Policy or other extensions to indicate persistent messaging
Posted by David Illsley <da...@gmail.com>.
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