Hi Paul,
On Mon, Jun 16, 2008 at 8:12 AM, Paul Fremantle <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
