-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Amila,
In the basic use case, the client calls echoString() and when RM mar gets that, from that point on, RM is in charge and will make sure that message that it is now responsible for is sent. What you are stating is *yet* another use case, where the client wants to *track* which ones got thru and which ones did not, there is no harm in making this available with a suitable API with some kind of notifications. Yes, the client can decide whether to start from the beginning or from where they left off. Both variations should be allowed programatically. Here the application client drops down to the low level API, gets its hands dirty :) thanks, dims Amila Suriarachchi wrote: | On Thu, Jun 19, 2008 at 8:51 PM, Chamikara Jayalath <[EMAIL PROTECTED]> | wrote: | |> Hi Amila, |> |> On Thu, Jun 19, 2008 at 11:10 AM, Amila Suriarachchi < |> [EMAIL PROTECTED]> wrote: |> |>> |>> On Thu, Jun 19, 2008 at 8:18 PM, Davanum Srinivas <[EMAIL PROTECTED]> |>> wrote: |>> | 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!). |>>> |>>> fine use case :) |>>> Lets say your client send 10 messages. And say when it crash it has send 6 |>>> messages. |>>> |>>> Here since EPR and internal key is same RM can assume it is try to resume |>>> a non terminated sequence. |>>> |>>> 1. So if RM Source continue the sequence from there it will end up with |>>> sending 15 messages. which is wrong in this case. then the number of |>>> messages depends on the crashed time messages. |>>> |>>> 2. So if RM Source understand that it resumes and drop the first five |>>> messages (as jaliya has mentioned ) it will end up with sending the 10 |>>> messages. Which is correct according to this. |>>> |>> |>> May be I understood you wrong. |>> |>> Are you saying that application have to rediliver earlier messages after a |>> crash recovery. Application has to deliver each message to RM client only |>> once. So in both these scenarios application should only deliver the last |>> four messages after the crash recovery. It should be up to RM to manage |>> failures. |>> | |> I think you have not understand the question Dims asked. |> There is a client which send 10 messages. and it crash when it has send 5 |> messages. Then Someone run the *same client* once again. Now it send 10 |> messages since client has written like this. | |> The scenario we are talking is that What should happen when the client |> starting at the second time. | |> There are two options |> 1. Client should run a recovery process |> Here client should get to know that it has only send 5 messages. Here |> think how client possibly know this. only way is to check the number of |> messages RM has received. Then send only five messages. | |> 2. Client send all the messages | | | | | |>> |>> Chamikara |>> |>> |>> |>>> |>>> Here client send the messages again with the same configuration. if this |>>> happens it is not a problem of restarting. The only thing we have to think |>>> is either we consider 1 behaviour or 2. |>>> |>>> |>>> thanks, |>>> Amila. |>>> |>>> |>>> | 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. | | | |> | | | |> | | | | | | | | | | |> | | | |> | |>>> |>> |>> |>> -- |>> Amila Suriarachchi, |>> WSO2 Inc. |> |> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIW0QHgNg6eWEDv1kRAkjgAKC+V1zwCnLFghl5GGaV5HaReTzJ6gCgs+v8 iTRxKbbjulwcS1TPgmQH3Co= =fnsf -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
