-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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!). 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. | | |> | | |> | | | | | | | |> | |> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIWnHRgNg6eWEDv1kRAmI+AKD79gmMK1b+AqsW1ZCx1x2HOPX7dwCgm9rS 7xUpql5Nj/qPwbnHkTTIb7I= =vTLX -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
