axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <chamikar...@gmail.com>
Subject Re: Real Asynchronous WebServices with JMS
Date Thu, 15 Mar 2007 13:46:48 GMT
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
>
>

Mime
View raw message