You are viewing a plain text version of this content. The canonical link for it is here.

Posted to java-user@axis.apache.org by Gilbert Scheiblhofer <gi...@gmx.at> on 2007/03/12 22:57:42 UTC

Real Asynchronous WebServices with JMS

Hi,
there is a lot information about asynchronous WS-calls using 
asynchronous calls on client and transport level. I want to build 
asynchronous WS-calls using JMS as transport and I don't think that the 
current capabilities of axis2 are really asynchronous. The main problem 
is that with axis2 asynchrounous calls are done using callbacks, but 
whenever I use callbacks the client has to hold state for this call. So 
this is not really asynchronous, it is just a non-blocking API. What 
happens if the client shuts down before it could process the response?
Is there any (easy) way to do real asynchrounous calls using JMS and the 
JMSCorrelationId for the client to correlate the response to the 
request. I'm thinking of a solution where the axis-stub should 
instantiate the callback-object and additionally to the response 
provides the correlation information.

Thanks,
Gilbert

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

RE: Real Asynchronous WebServices with JMS

Posted by Gul Onural <on...@nortel.com>.

I have the same issue as Gilbert. We don't just want "unblocking" API,
but real async. API.
I took a quick look into Sandesha2 and I am trying to understand your
comments (reply to Gilbert) on Sandesha2.

You say the behavior we want can be achieved using Sandesha2. But I am
not sure I truly understand rest of your comments on Sandesha2. Can you
elaborate a bit more ? 

    " I believe that when you use Sandesha2 for reliable messaging you
get the behavior you want. 
      I agree that there ought to be a way of specifying a class or a
factory instead of an instance. 
      In that case it would be up to you to manage the correlation based
on looking inside the message. "

Thanks.

-----Original Message-----
From: Paul Fremantle [mailto:pzfreo@gmail.com]
Sent: Monday, March 12, 2007 7:06 PM
To: axis-user@ws.apache.org; axis-dev@ws.apache.org
Subject: Re: Real Asynchronous WebServices with JMS

Gilbert

We had a similar discussion to this about Sandesha2. I believe that when
you use Sandesha2 for reliable messaging you get the behaviour you want.
I agree that there ought to be a way of specifying a class or a factory
instead of an instance. In that case it would be up to you to manage the
correlation based on looking inside the message.

I guess at the moment you could implement what you desire by
implementing the response handling as a new service. Now you need to
start the JMS transport and Axis2 as a server at the client end
yourself, and find the EPR of the "response service". Set this as the
replyTo of the outgoing request and then make a one-way invocation
against the real service.

Does that make sense? Effectively you are modelling the service as two
one-ways at the client side.

Paul

On 3/12/07, Gilbert Scheiblhofer <gi...@gmx.at> wrote:
> Hi,
> there is a lot information about asynchronous WS-calls using 
> asynchronous calls on client and transport level. I want to build 
> asynchronous WS-calls using JMS as transport and I don't think that 
> the current capabilities of axis2 are really asynchronous. The main 
> problem is that with axis2 asynchrounous calls are done using 
> callbacks, but whenever I use callbacks the client has to hold state 
> for this call. So this is not really asynchronous, it is just a 
> non-blocking API. What happens if the client shuts down before it
could process the response?
> Is there any (easy) way to do real asynchrounous calls using JMS and 
> the JMSCorrelationId for the client to correlate the response to the 
> request. I'm thinking of a solution where the axis-stub should 
> instantiate the callback-object and additionally to the response 
> provides the correlation information.
>
> Thanks,
> Gilbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

RE: Real Asynchronous WebServices with JMS

Posted by Gul Onural <on...@nortel.com>.


I know the WS-RM is not particularly concerned with async. invocation of
web services, but
passing class instead of an instance would make Sandesha2 quite usable
for asynchrony purposes.

Any comments from Sandesha2 gurus ? I assume Chamikara is copied to
provide comments ?

Gul

-----Original Message-----
From: Paul Fremantle [mailto:pzfreo@gmail.com] 
Sent: Thursday, March 15, 2007 7:55 AM
To: axis-user@ws.apache.org
Cc: axis-dev@ws.apache.org; Chamikara Jayalath
Subject: Re: Real Asynchronous WebServices with JMS

Gil, Gul

This only happens with the persistent implementation of Sandesha.

So - I think you are making a really good point here, and I think we
need to add another approach to the callback model.

Currently the callback only takes an instance. Now, one approach is that
we could try to serialize that instance class. However, I think thats
not necessarily a scalable model.

I would rather that for the truly async case we pass in a class instead
of an instance.

Then the question is whether to leave it up to the user to store their
own state, or whether to help them. If we help them, I would rather
explicitly pass a java.io.Serializable or even better an XML document
and then inject it into the callback class. I think this ends up with a
more solid model than just trying to serialize the existing callback.

e.g.

ServiceClient.sendReceiveNonBlocking(OMElement payload, Class
callbackClass, Serializable state);

then when the response comes back we do..

Callback callback = (Callback)callbackClass.newInstance();
if (callback instanceof Injectable) {
    callback.setState(state);
}
callback.onComplete(result)



Paul







On 3/15/07, Paul Fremantle <pz...@gmail.com> wrote:
> Gul
>
> A while back we had a discussion about what happens if the system 
> crashes and sandesha then delivers the message after a restart. At 
> that point it was stated that when Sandesha is involved, it news up 
> instances instead of using saved callbacks.
>
> I will check with the Sandesha gurus.
>
> Paul
>
> On 3/14/07, Gul Onural <on...@nortel.com> wrote:
> >
> > I have the same issue as Gilbert. We don't just want "unblocking" 
> > API, but real async. API.
> > I took a quick look into Sandesha2 and I am trying to understand 
> > your comments (reply to Gilbert) on Sandesha2.
> >
> > You say the behavior we want can be achieved using Sandesha2. But I 
> > am not sure I truly understand rest of your comments on Sandesha2. 
> > Can you elaborate a bit more ?
> >
> >
> >     " I believe that when you use Sandesha2 for reliable messaging 
> > you get the behavior you want.
> >       I agree that there ought to be a way of specifying a class or 
> > a factory instead of an instance.
> >       In that case it would be up to you to manage the correlation 
> > based on looking inside the message. "
> >
> > Thanks.
> >
> >
> >
> > -----Original Message-----
> > From: Paul Fremantle [mailto:pzfreo@gmail.com]
> > Sent: Monday, March 12, 2007 7:06 PM
> > To: axis-user@ws.apache.org; axis-dev@ws.apache.org
> > Subject: Re: Real Asynchronous WebServices with JMS
> >
> > Gilbert
> >
> > We had a similar discussion to this about Sandesha2. I believe that 
> > when you use Sandesha2 for reliable messaging you get the behaviour
you want.
> > I agree that there ought to be a way of specifying a class or a 
> > factory instead of an instance. In that case it would be up to you 
> > to manage the correlation based on looking inside the message.
> >
> > I guess at the moment you could implement what you desire by 
> > implementing the response handling as a new service. Now you need to

> > start the JMS transport and Axis2 as a server at the client end 
> > yourself, and find the EPR of the "response service". Set this as 
> > the replyTo of the outgoing request and then make a one-way 
> > invocation against the real service.
> >
> > Does that make sense? Effectively you are modelling the service as 
> > two one-ways at the client side.
> >
> > Paul
> >
> > On 3/12/07, Gilbert Scheiblhofer <gi...@gmx.at>
wrote:
> > > Hi,
> > > there is a lot information about asynchronous WS-calls using 
> > > asynchronous calls on client and transport level. I want to build 
> > > asynchronous WS-calls using JMS as transport and I don't think 
> > > that the current capabilities of axis2 are really asynchronous. 
> > > The main problem is that with axis2 asynchrounous calls are done 
> > > using callbacks, but whenever I use callbacks the client has to 
> > > hold state for this call. So this is not really asynchronous, it 
> > > is just a non-blocking API. What happens if the client shuts down 
> > > before it
> > could process the response?
> > > Is there any (easy) way to do real asynchrounous calls using JMS 
> > > and the JMSCorrelationId for the client to correlate the response 
> > > to the request. I'm thinking of a solution where the axis-stub 
> > > should instantiate the callback-object and additionally to the 
> > > response provides the correlation information.
> > >
> > > Thanks,
> > > Gilbert
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>


--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

Fwd: Real Asynchronous WebServices with JMS

Posted by Chamikara Jayalath <ch...@gmail.com>.

[Hadn't copied to the dev list]

---------- Forwarded message ----------
From: Chamikara Jayalath <ch...@gmail.com>
Date: Mar 15, 2007 7:16 PM
Subject: Re: Real Asynchronous WebServices with JMS
To: Gul Onural <on...@nortel.com>
Cc: axis-user@ws.apache.org

Hi All,

I also believe that passing a class than the instance will be a better
approach here. Letting the user pass the object kind of conveys that we will
be preserving the state, which we actually will not be doing.

We still couldn't commit the persistent implementation of the Sandesha2
StorageManager to Apache due to it's dependency on Hibernate. Apache legal
team informed us that we have to wait till some legal issues are solved.
Till then the code is available at [1].

Also +1 for Paul's suggestion to let the user pass an Serializable object
(or an XML) to be managed by the persistence layer.

Chamikara

[1] http://wso2.org/repos/wso2/trunk/commons/sandesha2-persistence/


On 3/15/07, Gul Onural <onural@nortel.com > wrote:
>
>
> I know the WS-RM is not particularly concerned with async. invocation of
> web services, but passing class instead of an instance would make
> Sandesha2 quite usable for asynchrony purposes.
>
> Any comments from Sandesha2 gurus ? I assume Chamikara is copied to
> provide comments ?
>
> Gul
>
> -----Original Message-----
> From: Paul Fremantle [mailto:pzfreo@gmail.com]
> Sent: Thursday, March 15, 2007 7:55 AM
> To: axis-user@ws.apache.org
> Cc: axis-dev@ws.apache.org; Chamikara Jayalath
> Subject: Re: Real Asynchronous WebServices with JMS
>
> Gil, Gul
>
> This only happens with the persistent implementation of Sandesha.
>
> So - I think you are making a really good point here, and I think we
> need to add another approach to the callback model.
>
> Currently the callback only takes an instance. Now, one approach is that
> we could try to serialize that instance class. However, I think thats
> not necessarily a scalable model.
>
> I would rather that for the truly async case we pass in a class instead
> of an instance.
>
> Then the question is whether to leave it up to the user to store their
> own state, or whether to help them. If we help them, I would rather
> explicitly pass a java.io.Serializable or even better an XML document
> and then inject it into the callback class. I think this ends up with a
> more solid model than just trying to serialize the existing callback.
>
> e.g.
>
> ServiceClient.sendReceiveNonBlocking(OMElement payload, Class
> callbackClass, Serializable state);
>
> then when the response comes back we do..
>
> Callback callback = (Callback)callbackClass.newInstance();
> if (callback instanceof Injectable) {
>     callback.setState(state);
> }
> callback.onComplete(result)
>
>
>
> Paul
>
>
>
>
>
>
>
> On 3/15/07, Paul Fremantle < pzfreo@gmail.com> wrote:
> > Gul
> >
> > A while back we had a discussion about what happens if the system
> > crashes and sandesha then delivers the message after a restart. At
> > that point it was stated that when Sandesha is involved, it news up
> > instances instead of using saved callbacks.
> >
> > I will check with the Sandesha gurus.
> >
> > Paul
> >
> > On 3/14/07, Gul Onural <onural@nortel.com > wrote:
> > >
> > > I have the same issue as Gilbert. We don't just want "unblocking"
> > > API, but real async. API.
> > > I took a quick look into Sandesha2 and I am trying to understand
> > > your comments (reply to Gilbert) on Sandesha2.
> > >
> > > You say the behavior we want can be achieved using Sandesha2. But I
> > > am not sure I truly understand rest of your comments on Sandesha2.
> > > Can you elaborate a bit more ?
> > >
> > >
> > >     " I believe that when you use Sandesha2 for reliable messaging
> > > you get the behavior you want.
> > >       I agree that there ought to be a way of specifying a class or
> > > a factory instead of an instance.
> > >       In that case it would be up to you to manage the correlation
> > > based on looking inside the message. "
> > >
> > > Thanks.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Paul Fremantle [mailto:pzfreo@gmail.com]
> > > Sent: Monday, March 12, 2007 7:06 PM
> > > To: axis-user@ws.apache.org; axis-dev@ws.apache.org
> > > Subject: Re: Real Asynchronous WebServices with JMS
> > >
> > > Gilbert
> > >
> > > We had a similar discussion to this about Sandesha2. I believe that
> > > when you use Sandesha2 for reliable messaging you get the behaviour
> you want.
> > > I agree that there ought to be a way of specifying a class or a
> > > factory instead of an instance. In that case it would be up to you
> > > to manage the correlation based on looking inside the message.
> > >
> > > I guess at the moment you could implement what you desire by
> > > implementing the response handling as a new service. Now you need to
>
> > > start the JMS transport and Axis2 as a server at the client end
> > > yourself, and find the EPR of the "response service". Set this as
> > > the replyTo of the outgoing request and then make a one-way
> > > invocation against the real service.
> > >
> > > Does that make sense? Effectively you are modelling the service as
> > > two one-ways at the client side.
> > >
> > > Paul
> > >
> > > On 3/12/07, Gilbert Scheiblhofer < gilbert.scheiblhofer@gmx.at>
> wrote:
> > > > Hi,
> > > > there is a lot information about asynchronous WS-calls using
> > > > asynchronous calls on client and transport level. I want to build
> > > > asynchronous WS-calls using JMS as transport and I don't think
> > > > that the current capabilities of axis2 are really asynchronous.
> > > > The main problem is that with axis2 asynchrounous calls are done
> > > > using callbacks, but whenever I use callbacks the client has to
> > > > hold state for this call. So this is not really asynchronous, it
> > > > is just a non-blocking API. What happens if the client shuts down
> > > > before it
> > > could process the response?
> > > > Is there any (easy) way to do real asynchrounous calls using JMS
> > > > and the JMSCorrelationId for the client to correlate the response
> > > > to the request. I'm thinking of a solution where the axis-stub
> > > > should instantiate the callback-object and additionally to the
> > > > response provides the correlation information.
> > > >
> > > > Thanks,
> > > > Gilbert
> > > >
> > > > ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

Re: Real Asynchronous WebServices with JMS

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi All,

I also believe that passing a class than the instance will be a better
approach here. Letting the user pass the object kind of conveys that we will
be preserving the state, which we actually will not be doing.

We still couldn't commit the persistent implementation of the Sandesha2
StorageManager to Apache due to it's dependency on Hibernate. Apache legal
team informed us that we have to wait till some legal issues are solved.
Till then the code is available at [1].

Also +1 for Paul's suggestion to let the user pass an Serializable object
(or an XML) to be managed by the persistence layer.

Chamikara

[1] http://wso2.org/repos/wso2/trunk/commons/sandesha2-persistence/


On 3/15/07, Gul Onural <on...@nortel.com> wrote:
>
>
> I know the WS-RM is not particularly concerned with async. invocation of
> web services, but passing class instead of an instance would make
> Sandesha2 quite usable for asynchrony purposes.
>
> Any comments from Sandesha2 gurus ? I assume Chamikara is copied to
> provide comments ?
>
> Gul
>
> -----Original Message-----
> From: Paul Fremantle [mailto:pzfreo@gmail.com]
> Sent: Thursday, March 15, 2007 7:55 AM
> To: axis-user@ws.apache.org
> Cc: axis-dev@ws.apache.org; Chamikara Jayalath
> Subject: Re: Real Asynchronous WebServices with JMS
>
> Gil, Gul
>
> This only happens with the persistent implementation of Sandesha.
>
> So - I think you are making a really good point here, and I think we
> need to add another approach to the callback model.
>
> Currently the callback only takes an instance. Now, one approach is that
> we could try to serialize that instance class. However, I think thats
> not necessarily a scalable model.
>
> I would rather that for the truly async case we pass in a class instead
> of an instance.
>
> Then the question is whether to leave it up to the user to store their
> own state, or whether to help them. If we help them, I would rather
> explicitly pass a java.io.Serializable or even better an XML document
> and then inject it into the callback class. I think this ends up with a
> more solid model than just trying to serialize the existing callback.
>
> e.g.
>
> ServiceClient.sendReceiveNonBlocking(OMElement payload, Class
> callbackClass, Serializable state);
>
> then when the response comes back we do..
>
> Callback callback = (Callback)callbackClass.newInstance();
> if (callback instanceof Injectable) {
>     callback.setState(state);
> }
> callback.onComplete(result)
>
>
>
> Paul
>
>
>
>
>
>
>
> On 3/15/07, Paul Fremantle <pz...@gmail.com> wrote:
> > Gul
> >
> > A while back we had a discussion about what happens if the system
> > crashes and sandesha then delivers the message after a restart. At
> > that point it was stated that when Sandesha is involved, it news up
> > instances instead of using saved callbacks.
> >
> > I will check with the Sandesha gurus.
> >
> > Paul
> >
> > On 3/14/07, Gul Onural <on...@nortel.com> wrote:
> > >
> > > I have the same issue as Gilbert. We don't just want "unblocking"
> > > API, but real async. API.
> > > I took a quick look into Sandesha2 and I am trying to understand
> > > your comments (reply to Gilbert) on Sandesha2.
> > >
> > > You say the behavior we want can be achieved using Sandesha2. But I
> > > am not sure I truly understand rest of your comments on Sandesha2.
> > > Can you elaborate a bit more ?
> > >
> > >
> > >     " I believe that when you use Sandesha2 for reliable messaging
> > > you get the behavior you want.
> > >       I agree that there ought to be a way of specifying a class or
> > > a factory instead of an instance.
> > >       In that case it would be up to you to manage the correlation
> > > based on looking inside the message. "
> > >
> > > Thanks.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Paul Fremantle [mailto:pzfreo@gmail.com]
> > > Sent: Monday, March 12, 2007 7:06 PM
> > > To: axis-user@ws.apache.org; axis-dev@ws.apache.org
> > > Subject: Re: Real Asynchronous WebServices with JMS
> > >
> > > Gilbert
> > >
> > > We had a similar discussion to this about Sandesha2. I believe that
> > > when you use Sandesha2 for reliable messaging you get the behaviour
> you want.
> > > I agree that there ought to be a way of specifying a class or a
> > > factory instead of an instance. In that case it would be up to you
> > > to manage the correlation based on looking inside the message.
> > >
> > > I guess at the moment you could implement what you desire by
> > > implementing the response handling as a new service. Now you need to
>
> > > start the JMS transport and Axis2 as a server at the client end
> > > yourself, and find the EPR of the "response service". Set this as
> > > the replyTo of the outgoing request and then make a one-way
> > > invocation against the real service.
> > >
> > > Does that make sense? Effectively you are modelling the service as
> > > two one-ways at the client side.
> > >
> > > Paul
> > >
> > > On 3/12/07, Gilbert Scheiblhofer <gi...@gmx.at>
> wrote:
> > > > Hi,
> > > > there is a lot information about asynchronous WS-calls using
> > > > asynchronous calls on client and transport level. I want to build
> > > > asynchronous WS-calls using JMS as transport and I don't think
> > > > that the current capabilities of axis2 are really asynchronous.
> > > > The main problem is that with axis2 asynchrounous calls are done
> > > > using callbacks, but whenever I use callbacks the client has to
> > > > hold state for this call. So this is not really asynchronous, it
> > > > is just a non-blocking API. What happens if the client shuts down
> > > > before it
> > > could process the response?
> > > > Is there any (easy) way to do real asynchrounous calls using JMS
> > > > and the JMSCorrelationId for the client to correlate the response
> > > > to the request. I'm thinking of a solution where the axis-stub
> > > > should instantiate the callback-object and additionally to the
> > > > response provides the correlation information.
> > > >
> > > > Thanks,
> > > > Gilbert
> > > >
> > > > ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>