-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Amila,
RM may be enabled globally using a custom axis2.xml outside the axis2 client. - -- 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) iD8DBQFIWmzQgNg6eWEDv1kRAlbFAKC6bSIwzwCfWJDjqx+Y/1oRXHR91gCgjCYS R7Yjo0JSGsQStE/i+EAask0= =320w -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
