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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> [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]
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"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
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
