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: [email protected]; [email protected]
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

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to