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 <[EMAIL PROTECTED]> wrote: > Hi Paul, > > Please see my comments below. > > Thanks, > Jaliya > ----- Original Message ----- From: "Paul Fremantle" <[EMAIL PROTECTED]> > To: "Jaliya Ekanayake" <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> >>> To: "Danushka Menikkumbura" <[EMAIL PROTECTED]> >>> Cc: <[email protected]> >>> 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 >>>> <[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] >>>> >>> >>> >> >> >> >> -- >> 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 > > -- 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]
