Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@ws.apache.org
Received-SPF: pass (herse.apache.org: domain of ONURAL@nortel.com designates
 47.129.242.56 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Real Asynchronous WebServices with JMS
Date: Wed, 14 Mar 2007 17:41:14 -0400
Message-ID: 
 <87AC5F88F03E6249AEA68D40BD3E00BE0E90A2C8@zcarhxm2.corp.nortel.com>
In-reply-to: <88f5d710703121606k6c0e0620s6f0baab9d7532b84@mail.gmail.com>
Thread-Topic: Real Asynchronous WebServices with JMS
Thread-Index: Acdk+x5MBK7VanO2TRiItvHd8ycsBQBhW9Rg
References: <45F5CCD6.9060305@gmx.at>
 <88f5d710703121606k6c0e0620s6f0baab9d7532b84@mail.gmail.com>
From: "Gul Onural" <onural@nortel.com>
To: <axis-user@ws.apache.org>, <axis-dev@ws.apache.org>


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 ?=20

=20
    " I believe that when you use Sandesha2 for reliable messaging you
get the behavior you want.=20
      I agree that there ought to be a way of specifying a class or a
factory instead of an instance.=20
      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]=20
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=20
> asynchronous calls on client and transport level. I want to build=20
> asynchronous WS-calls using JMS as transport and I don't think that=20
> the current capabilities of axis2 are really asynchronous. The main=20
> problem is that with axis2 asynchrounous calls are done using=20
> callbacks, but whenever I use callbacks the client has to hold state=20
> for this call. So this is not really asynchronous, it is just a=20
> 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=20
> the JMSCorrelationId for the client to correlate the response to the=20
> request. I'm thinking of a solution where the axis-stub should=20
> instantiate the callback-object and additionally to the response=20
> 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