-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cool!. As i was telling Glen, let's mark this use case scenario as complete and would be supported with no client changes and proper default behavior and move on to the next one :)
thanks, - -- dims Jaliya Ekanayake wrote: | Hi Dims, | | ----- Original Message ----- From: "Davanum Srinivas" <[EMAIL PROTECTED]> | To: "Jaliya Ekanayake" <[EMAIL PROTECTED]> | Cc: "Amila Suriarachchi" <[EMAIL PROTECTED]>; "Chamikara | Jayalath" <[EMAIL PROTECTED]>; "Paul Fremantle" <[EMAIL PROTECTED]>; | <[email protected]> | Sent: Thursday, June 19, 2008 11:35 AM | Subject: Re: [Mercury] Mercury restarting (was persistence policy) | | |> Think of it from the POV of a end user. Don't think of how you are |> gonna implement it :) | | Yes, this is what we should do. | |> |> Basically say a Twitter Application Client sending strings to the |> Twitter server. So we have a wsdl with a echoString and an Async |> Transport. works great! now they want to throw in RM in a totally |> transparent manner. All the messges for which echoString were |> *already* called need to reach the server and all the strings that |> need to reach the client should reach the client. If the client had |> stuff for which he has not yet called echoString, that's his/her |> problem. |> | | This is not a problem for the current implementations. This scenario | should works wihotut the user intervention. | The question is "if the user needs to continue sending a related set of | messages in a fixed RM sequance or not" | | If RM implementation decides when to start a sequance and when to | terminte a sequance then the above scenario will work. | |> thanks, |> dims |> |> |> On Thu, Jun 19, 2008 at 11:07 AM, Jaliya Ekanayake |> <[EMAIL PROTECTED]> wrote: |>> Hi Dims, |>> |>> Please see my commets below. |>> |>> |>> ----- Original Message ----- From: "Davanum Srinivas" |>> <[EMAIL PROTECTED]> |>> To: "Amila Suriarachchi" <[EMAIL PROTECTED]> |>> Cc: "Jaliya Ekanayake" <[EMAIL PROTECTED]>; "Chamikara Jayalath" |>> <[EMAIL PROTECTED]>; "Paul Fremantle" <[EMAIL PROTECTED]>; |>> <[email protected]> |>> Sent: Thursday, June 19, 2008 10:48 AM |>> Subject: Re: [Mercury] Mercury restarting (was persistence policy) |>> |>> | Let me start again: | | 1) Axis2 end User runs wsdl2java and writes a client using the | generated | code Say against WCF service | 2) Once #1 works, he switches on RM on the server and adds a RM mar | and a | custom axis2.xml on the client | | That's it. If the client fails and he/she brings it back up, everything | should be back to normal. The End user should | not have to do anything (no clicking, no specifying a new starting | sequence #, no change to his client, nothing!). |>>> |>>> Can you explain a bit more of this? |>>> |>>> The client will work without any user intervention as if it is |>>> started new. |>>> But what is interesting is, can the client resume from its crashed |>>> state and |>>> still continue on the same RM sequence without passing any |>>> information from |>>> the application to the RM implementation. |>>> |>>> Thanks, |>>> Jaliya |>>> |>>> |>>> | | thanks, | dims | | Amila Suriarachchi wrote: | | On Thu, Jun 19, 2008 at 7:57 PM, Davanum Srinivas <[EMAIL PROTECTED]> | wrote: | | | | Amila, | | | | RM may be enabled globally using a custom axis2.xml outside the axis2 | | client. | | | | | |> it does not matter whether it engaged in the service level or global | level. | |> You mean if someone updates the RM mar file while as sequence | executed? | |> Sorry I am still not getting you correctly. Could you please | explain a | bit? | | | |> Amila. | | | | | | -- dims | | | | Amila Suriarachchi wrote: | | | On Thu, Jun 19, 2008 at 6:53 PM, Davanum Srinivas | <[EMAIL PROTECTED]> | | wrote: | | | | | | Amila, | | | | | | At the risk of stating the obvious use case scenario. If someone | runs | | | wsdl2java and writes a client, they should be able | | | able to just drop in a new mar and RM should work transparently | with | *NO* | | | changes to the client. | | | | | | | | |> Sorry I didn't get your point. You mean without engaging that | module | at | | the | | |> client? | | |> What I am saying is that RM do not have to worry about the other | engaged | | |> modules. At the recovery time client has to set them properly. | | | | | | | | | | | | Yes, even if the client | | | crashes and is later restarted again. | | | | | | thanks, | | | dims | | | | | | | | | Amila Suriarachchi wrote: | | | | On Wed, Jun 18, 2008 at 7:00 PM, Jaliya Ekanayake < | | [EMAIL PROTECTED] | | | | wrote: | | | | | | | |> Hi Amila, | | | |> | | | |> I think the discussion is mixing up the application recovery and | the | | | |> persistance requirements of RM. | | | |> We need to separate the two cases. | | | |> | | | |> In your example, how the application client determines | whether it | has | | | |> crashed or not is a separate problem to RM. | | | |> | | | | Agreed. | | | | | | | |> From RM point of view, this is what should happen. | | | |> | | | |> The application client should be given a simple API to let RM | know | | that | | | |> this is the same sequance that it needs to continue before | crashing. | | | |> Something like "resumeSequance(seqID)" | | | |> | | | | | | | | yes. In Mercury it uses to address and internal key to uniquely | | identify | | | a | | | | RM sequence. I think sandesha2 also do the same. | | | | | | | |> We need this information from the application client simply | because | RM | | | does | | | |> not have a way to differentiate the different invocations of the | | | application | | | |> client. | | | |> | | | |> In RM database, we only need to record the messages and the | propety | to | | | know | | | |> whether the sequance is completed or not. | | | |> | | | | yes. What about the acknowledged messages. I think we need to | keep | all | | | the | | | | details to restart the sequence. In Mercury terms to populate the | last | | | | state. | | | | | | | | | | | |> When the application client recovers, it can simply call | | | |> "resumeSequance(seqID) and probably start sending the messages | again | | | from | | | |> the begining. | | | |> | | | | However, in the RM database our records shows that we have | successfully | | | sent | | | |> up to 25h message. So RM will continue only after 26th message. | | | |> | | | | | | | | you mean if it is a resumed sequence RM has to drop messages upto | the | | | number | | | | it has gone? | | | | I think the better option is to give some API to Client app to | get | the | | | | number of messages has send. if crashed sequence has send 99 | messages | | | then | | | | this is a huge duplicate. | | | | | | | | thanks, | | | | Amila. | | | | | | | |> Thanks, | | | |> Jaliya | | | |> | | | |> | | | |> | | | |> ----- Original Message ----- | | | |> *From:* Amila Suriarachchi <[EMAIL PROTECTED]> | | | |> *To:* Jaliya Ekanayake <[EMAIL PROTECTED]> | | | |> *Cc:* Chamikara Jayalath <[EMAIL PROTECTED]> ; Paul | Fremantle< | | | [EMAIL PROTECTED]>; | | | |> [email protected] | | | |> *Sent:* Wednesday, June 18, 2008 1:41 AM | | | |> *Subject:* Re: [Mercury] Mercury restarting (was persistence | policy) | | | |> | | | |> Here is what I thought when writing the persistence. | | | |> | | | |> Lets take this scenario, | | | |> | | | |> There is an application client which process transaction logs | and | send | | | |> messages to server. From another application it gets log | files to a | | | folder | | | |> called *input* folder and then this application moves this | file to | | | |> *processing* folder and start reading log entries and send | messages. | | | After | | | |> finish it move the file to *finish* folder. | | | |> Then say this Application client crashes when it processing the | file. | | | When | | | |> at the start up the application can understand it has crashed by | | looking | | | at | | | |> the files in the *processing* folder. | | | |> Then it has to determine how many messages it has send. This | can be | | done | | | by | | | |> checking the RM persistence database. Then it can restart the | sequence | | | and | | | |> start sending messages from the stop point. | | | |> The main point here is that this application should have a | recovery | | | process | | | |> and it should be able to understand something has gone wrong. | (in | this | | | case | | | |> looking at the files in the *processing* folder). | | | |> | | | |> This logic can only be written in the Application level recovery | | | process. | | | |> That also can be written in a demon but I don't see any | advantage. | | | |> | | | |> thanks, | | | |> Amila. | | | |> | | | |> | | | |> | | | |> On Wed, Jun 18, 2008 at 10:26 AM, Amila Suriarachchi < | | | |> [EMAIL PROTECTED]> wrote: | | | |> | | | |>> | | | |>> On Tue, Jun 17, 2008 at 9:53 PM, Jaliya Ekanayake < | | | [EMAIL PROTECTED]> | | | |>> wrote: | | | |>> | | | |>>> Don't know if somebody has done this earlier, but as | Chamikara | | | |>>> mentioned, we can have a daemon process in the client side | which | | acts | | | as | | | |>>> the: | | | |>>> | | | |>>> 1. Endpoint for the dual channel communications originating | from | | that | | | |>>> machine. | | | |>>> 2. manager for the reliable communications. | | | |>>> | | | |>>> The communications between the RMHandler (not the client | | application) | | | and | | | |>>> the daemon process should happen via a persistence storage | | mechanism. | | | |>>> | | | |>> isn't this mean the user has to write this logic in the | deamon. So | I | | | think | | | |>> writing this straight away in the Application client would | make it | | | easier. | | | |>> | | | |>>> The daemon will keep trying to send the messages, and if | something | | | |>>> fail, once in a while bug the user with a pop up window :) | | | |>>> | | | |>> Then anyway application client has to handle this isn't it? | This | | means | | | |>> some recovery part should goes to application client. | | | |>> | | | |>> thanks, | | | |>> Amila. | | | |>> | | | |>>> Thanks, | | | |>>> Jaliya | | | |>>> | | | |>>> | | | |>>> ----- Original Message ----- | | | |>>> *From:* Chamikara Jayalath <[EMAIL PROTECTED]> | | | |>>> *To:* Amila Suriarachchi <[EMAIL PROTECTED]> | | | |>>> *Cc:* Paul Fremantle <[EMAIL PROTECTED]> ; | | [email protected] | | | |>>> *Sent:* Tuesday, June 17, 2008 11:05 AM | | | |>>> *Subject:* Re: [Mercury] Mercury restarting (was persistence | policy) | | | |>>> | | | |>>> Amila, Paul, | | | |>>> | | | |>>> I don't think I said that application client should have any | logic | | to | | | |>>> manage recovery. I simply said that one of following two | has to | be | | | done to | | | |>>> manage recovery in the client side. | | | |>>> | | | |>>> 1. There should be a permanent RM agent running in the client | side, | | | which | | | |>>> manages recovery. | | | |>>> 2. RM client should check for crashed sequences whenever it is | | invoked | | | in | | | |>>> the client side, if it find any they should be resumed. | | | |>>> | | | |>>> In both cases work should be done by the RM client | transparently, | | not | | | by | | | |>>> the application client. | | | |>>> | | | |>>> Chamikara | | | |>>> | | | |>>> | | | |>>> On Tue, Jun 17, 2008 at 10:42 AM, Amila Suriarachchi < | | | |>>> [EMAIL PROTECTED]> wrote: | | | |>>> | | | |>>>> | | | |>>>> On Tue, Jun 17, 2008 at 7:09 PM, Paul Fremantle | <[EMAIL PROTECTED] | | | |>>>> wrote: | | | |>>>> | | | |>>>>> Amila | | | |>>>>> | | | |>>>>> The Mercury design is wrong. | | | |>>>>> | | | |>>>>> The application client should not be responsible for | understanding | | | if | | | |>>>>> the system needs to restart. There isn't a single successful | | | messaging | | | |>>>>> or transaction system in the world that requires the | application | | to | | | |>>>>> incorporate logic to handle recovery. Sandesha2 manages | automatic | | | |>>>>> recovery and so should Mercury. | | | |>>>> | | | |>>>> Here the question is that when a client dies. (i.e. system | crashed) | | | how | | | |>>>> it automatically restart? | | | |>>>> Actually I had a chat with Chamikara regarding this and he | told | | that | | | |>>>> sandesha2 also can not | | | |>>>> automatically restart. | | | |>>>> Chamikara could you please comment on this? | | | |>>>> | | | |>>>> thanks, | | | |>>>> Amila. | | | |>>>> | | | |>>>>> | | | |>>>>> Paul | | | |>>>>> | | | |>>>>> On Tue, Jun 17, 2008 at 2:36 PM, Amila Suriarachchi | | | |>>>>> <[EMAIL PROTECTED]> wrote: | | | |>>>>>> +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 < | | | |>>>>> [EMAIL PROTECTED]> | | | |>>>>>> 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" < | | | |>>>>> [EMAIL PROTECTED]> | | | |>>>>>>> To: "Jaliya Ekanayake" <[EMAIL PROTECTED]> | | | |>>>>>>> Cc: <[email protected]> | | | |>>>>>>> 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 < | | | |>>>>> [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] | | | |>>>>>>>> | | | |>>>>>>> | | | |>>>>>>> | | | |>>>>> | | | | --------------------------------------------------------------------- | | | |>>>>>>> To unsubscribe, e-mail: | [EMAIL PROTECTED] | | | |>>>>>>> For additional commands, e-mail: | | [EMAIL PROTECTED] | | | |>>>>>>> | | | |>>>>>> | | | |>>>>>> | | | |>>>>>> -- | | | |>>>>>> Amila Suriarachchi, | | | |>>>>>> WSO2 Inc. | | | |>>>>> | | | |>>>>> | | | |>>>>> -- | | | |>>>>> 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 | | | |>>>>> | | | |>>>> | | | |>>>> | | | |>>>> -- | | | |>>>> Amila Suriarachchi, | | | |>>>> WSO2 Inc. | | | |>>> | | | |>>> | | | |>> | | | |>> -- | | | |>> Amila Suriarachchi, | | | |>> WSO2 Inc. | | | |> | | | |> | | | |> | | | |> -- | | | |> Amila Suriarachchi, | | | |> WSO2 Inc. | | | |> | | | |> | | | | | | | | | | |> | | | |> | |>>> - --------------------------------------------------------------------- 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] |>> |>> |> |> |> |> -- |> Davanum Srinivas :: http://davanum.wordpress.com |> |> --------------------------------------------------------------------- |> To unsubscribe, e-mail: [EMAIL PROTECTED] |> For additional commands, e-mail: [EMAIL PROTECTED] |> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIWoLWgNg6eWEDv1kRAsyfAKDbX6yD953RViK8acPeaE8iioft8ACdEuTp WJg2fuKFtI0pgG1PYdomKYA= =MUFR -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
