Amila There is a clear difference between:
1. Mercury recovering at the point it is engaged. This may not happen until the client tries to send a new message. (FINE) 2. Mercury requiring that the client sends a special message to recover. (NOT FINE) I'm also perfectly happy that in persistent recoverable scenarios the client has a way of "initializing" the Mercury engine. That is different from expecting the client to know that there has been a failure, and which sequences/service requests are in doubt and requiring the client to send special messages to those endpoints to restart. Can I suggest you start looking at this not from where Axis2 and Mercury are today, but from user requirements, developer friendliness, ease-of-use, usability and production management aspects? If the model we come up with cannot be satisfied by the current Axis2 architecture, then we can improve it. This whole discussion has spiralled into analyzing whether Sandesha2 is designed in a certain way rather than a positive, forward-looking discussion about how to make WSRM really effective for users. Paul On Wed, Jun 18, 2008 at 11:00 AM, Amila Suriarachchi <[EMAIL PROTECTED]> wrote: > > > On Wed, Jun 18, 2008 at 12:18 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote: >> >> Amila >> >> I don't see why the Mercury module cannot automatically check when it >> starts up if there are unfinished sequences. That is Chamikara's >> option 2. > > Here is the option two. > > 2. RM client should check for crashed sequences whenever it is invoked in > the client side, if it find any they should be resumed. > > As I understood he also has mentioned that the Application client should > send a message to RM. > > Here I am not sure whether he is talking about a message send to start > another sequence or a message to resume a the dead sequences. > When a service being invoked from the service client, different modules can > be engaged. According to this engagements there is a handler chain created > for each operation invocations. In mercury when sending a resume sequence it > is assumed that this handler chain is identical and the resume message > context has all the policies as in the earlier case. > > But I am not sure how the handler chain and polices determine when a message > comes to invoke a different operation. > > thanks, > Amila. >> >> >> Paul >> >> On Wed, Jun 18, 2008 at 5:47 AM, Amila Suriarachchi >> <[EMAIL PROTECTED]> wrote: >> > hi all, >> > >> > On Tue, Jun 17, 2008 at 8:35 PM, Chamikara Jayalath >> > <[EMAIL PROTECTED]> >> > wrote: >> >> >> >> 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. >> > >> > yes. I also has not mentioned you told such a thing. Here is what I have >> > said >> > >> > "Actually I had a chat with Chamikara regarding this and he told that >> > sandesha2 also can not >> > automatically restart." >> > >> > From your answer what I can get this that Sandesha2(currently) does not >> > support automatic recovery as Paul has mentioned. And that is what >> > exactly >> > you told me and I have mention here. >> > >> >> >> >> >> >> 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. >> > >> > As I understood what you are saying here is that An independent Agent >> > has to >> > invoke the RM instead of Application. Then what is the difference? What >> > you >> > are basically saying is that put that logic to an agent instead of >> > Application. >> > >> > >> > This is the use case I am thinking. Can you explain how it is achieved >> > with >> > this method. >> > 1. Application client start a sequence with 10 messages (want to send) >> > and >> > then hand over them to RM. The machine crashes after sending 5 messages. >> > Now >> > This sequence should be restarted to send the remaining 5 messages and >> > terminate the sequence >> > >> > 2. Application client start sequence with 100 messages (want to send) >> > and >> > then machine crashes when it has only handed over 25 messages and RM has >> > only send 10 messages. Now this sequence should be restarted so that >> > Application should be able to send 26 to 100 to RM and RM should >> > complete >> > the sequence. >> > >> > if you take the second scenario how Application client knows how much >> > messages it has hand over to RM if the application crashes at the >> > middle? >> > IMHO this is some thing to we have to think with the "end to end >> > argument". >> > Anyway application client has to play some role when handling >> > unreliability. >> > >> > thanks, >> > Amila. >> > >> >> >> >> >> >> 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. >> >> >> >> -- >> 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. -- 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]
