-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 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) iD8DBQFIWl3mgNg6eWEDv1kRAoPoAJ9oOiQhZeSlnssc32Z3ZgOJCHurEwCfUfX3 g7iOjC58KcUAFZ16pDBln4A= =pyI1 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
