Re: Policy or other extensions to indicate persistent messaging

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 <dug-r/[email protected]> wrote:
>
> I just have a hard time understanding how an RMD can require an RMS
> to have persistence.  Seems like that's under the RMS/client-app's
> control - not the server/RMD.  How does the RMD check this?
>
> thanks
> -Doug
> ______________________________________________________
> STSM  |  Web Services Architect  |  IBM Software Group
> (919) 254-6905  |  IBM T/L 444-6905  |  dug-r/[email protected]
>
>
> "Paul Fremantle" <[email protected]>
>
> 06/23/2008 05:39 PM
>
> To
> "David Illsley" <[email protected]>
> cc
> [email protected]
> Subject
> Re: Policy or other extensions to indicate persistent messaging
>
>
>
>
> David
>
> I agree with your scenarios. I do also have another angle on it, which
> is really orthogonal to the actual technical scenarios:
>
> The aspect I'm thinking of is to be able to counter people who say
> that RM does not "do" persistence, and I think to be able to get
> around the misinformation that has been around I think it will be
> important to have an *option* to enforce persistence.
>
> Paul
>
>
>
> On Mon, Jun 23, 2008 at 3:57 PM, David Illsley <[email protected]>
> wrote:
>> Doug,
>> There are 2 drivers of this for me, both of which became apparent
>> trying to explain RM to MQ centric people.
>>
>> 1. A desire on the client application developer's part to have a
>> reasonable expectation that a one-way message will be processed.
>>
>> 2. A desire on a server administrators part that the sequences it is
>> managing in a persistent way will be completed. It's probably a very
>> expensive operation to administratively deal with a hung sequence. A
>> server administrator might well wish to limit interaction to parties
>> which support persistence and which can therefore recover from
>> serious* failures and complete and close out sequences on their own
>> without human intervention.
>>
>> Paul, do you have other drivers for this?
>>
>> David
>>
>> * Clearly something less serious than an asteroid taking out the data
>> center hosting your servers.
>>
>> On Fri, Jun 20, 2008 at 6:22 PM, Doug Davis <dug-r/[email protected]> wrote:
>>>
>>> Is thispolicy/extension thing used just for advertisement or something
>>> else?
>>> Typically what an endpoint does internally is its own concern.  However,
>>> I
>>> can see
>>> choosing one RMD over another based on whether it has a higher degree of
>>> QoS/persistence.  But this almost sounds like you're suggesting that the
>>> RMD
>>> tell
>>> the RMS which kind of persistence it must have - which is odd to me.
>>>
>>> thanks
>>> -Doug
>>> ______________________________________________________
>>> STSM  |  Web Services Architect  |  IBM Software Group
>>> (919) 254-6905  |  IBM T/L 444-6905  |  dug-r/[email protected]
>>>
>>>
>>> "Paul Fremantle" <[email protected]>
>>>
>>> 06/20/2008 12:46 PM
>>>
>>> To
>>> "David Illsley" <[email protected]>
>>> cc
>>> [email protected]
>>> Subject
>>> Re: Policy or other extensions to indicate persistent messaging
>>>
>>>
>>>
>>>
>>> David
>>>
>>> Thanks for the reply.
>>>
>>> 1. I hope it won't be too difficult defining the details!!! But I'm
>>> always an optimist.
>>> 2. I agree, Open Standards != Open Source, and I presumed that it was
>>> better to try out some implementation thoughts before taking this to a
>>> standards process. However, if there is a feeling that this should be
>>> done in a standards body, we could move it there. My own feeling
>>> though is that WS-RX is in quiescent mode and so there will be inertia
>>> to be overcome to get an active discussion there.
>>> 3. Actually, you've asked the really tough question (how to define
>>> persistent storage), which is one of the main reasons the WSRX TC
>>> decided not to pursue this. However, I'm not convinced we need to. I
>>> think the prime example of this is the XA spec, which is the bedrock
>>> of transaction systems. If you look at the XA transaction spec, they
>>> simply talk about "stable storage" with no definition. And I'm not
>>> expecting this to be a legally binding policy (if such a thing
>>> exists).
>>>
>>> Paul
>>>
>>> On Fri, Jun 20, 2008 at 5:11 PM, David Illsley <[email protected]>
>>> wrote:
>>>> This does seem like something that could be useful, though I'd imagine
>>>> it'll be fraught with difficulties in defining the details.
>>>>
>>>> Clearly open standards!=open source, so if we come up with something,
>>>> finding a standards venue would be a good next step... but that's a
>>>> bit in the future.
>>>>
>>>> I think both parts of your proposal would be needed... a first
>>>> question if you will....
>>>>   Any idea on how we define 'persistent'? This must have been gone
>>>> over lots by other groups that I haven't been involved in.
>>>>
>>>> David
>>>>
>>>> On Mon, Jun 16, 2008 at 11:26 AM, Paul Fremantle <[email protected]>
>>>> wrote:
>>>>> One issue that the WSRX technical committee didn't address in the
>>>>> specification is the persistence of messages. Now, while there were
>>>>> possibly good arguments why that was the case, the reality is that
>>>>> many people want and expect WSRM to provide persistence, and certainly
>>>>> in the case of Sandesha it does. I have long thought that there should
>>>>> be an extension that can be used to signify whether persistence is
>>>>> available and whether it is to be used. This kind of thing is actually
>>>>> common in messaging systems and is available in other messaging specs
>>>>> such as AMQP.
>>>>>
>>>>> This isn't at all fully baked, but the sort of thing I am thinking of
>>>>> is:
>>>>>
>>>>> 1) A policy element to indicate whether this endpoint supports and/or
>>>>> requires persistence
>>>>> 2) An exchange that happens at create sequence time that indicates
>>>>> whether this sequence should/must be persistent
>>>>>
>>>>> Some questions:
>>>>> * What do people think about this? Is anyone *against* defining this?
>>>>> * If we define this, should we try to standardize it somewhere? Or
>>>>> just treat is as an optional extension.
>>>>> * Any comments on the approach - or suggestions for the actual XML?
>>>>>
>>>>> Regards,
>>>>> Paul
>>>>>
>>>>> --
>>>>> Paul Fremantle
>>>>> Co-Founder and CTO, WSO2
>>>>> Apache Synapse PMC Chair
>>>>> OASIS WS-RX TC Co-chair
>>>>>
>>>>> blog: http://pzf.fremantle.org
>>>>> [email protected]
>>>>>
>>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Paul Fremantle
>>> Co-Founder and CTO, WSO2
>>> Apache Synapse PMC Chair
>>> OASIS WS-RX TC Co-chair
>>>
>>> blog: http://pzf.fremantle.org
>>> [email protected]
>>>
>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> [email protected]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>