Fwd: Async callbacks over ws binding w/Axis2, was Re: Inner composite patch

[Jim Marino]

This hasn't shown up on this list...sending again

Begin forwarded message:

From: Jim Marino <[EMAIL PROTECTED]>
Date: September 1, 2006 9:59:04 AM PDT
To: tuscany-dev@ws.apache.org

Subject: Re: Async callbacks over ws binding w/Axis2, was Re: Inner composite patch

On Sep 1, 2006, at 4:00 AM, ant elder wrote:

I've not thought much about async yet in Tuscany so could you give a more "big picture" view of what is being done (or just point me to OSOA white

papers or sections in the spec if they talk about it)?

Please see the specs (assembly and Java) for details on the programming model for callbacks and conversations.

For example for services with a WS binding are you talking about something

like:

soap/http request arrives
request queued in Tuscany runtime
http 202 response sent
...
tuscany processes queued request
soap/http response sent

And I guess references with a WS binding will support remote services
working the same way?

Whats needed to be done in the SCDL to get that to happen, how do

callbackInterfaces relate to this, or whether or not the incoming requests

use a non-anonymous WSA replyTo?

For references with a WS binding what will control whether or not we send out a non-anonymous WSA replyTo? And can that happen independent of whether

or not the component invoking the reference uses a callbackInterface?

I'll let Ignacio reply to the specifics on flowing across Axis using WS-Addressing since he has thought about this more but two higher level things are relevant. One is that the wiring infrastructure should delegate to the binding for propagation of correlation information (e.g. there are ways to do this with JMS implementations or various remoting protocols such as T3). This will mean we need to have a correlation service in core for invocation "sequences" that cross *remote* boundaries (optimizations may be done for sequences that remain in shared memory). Indigo/WCF as an approach for propagating correlation through WS-splat so we may want to look at that for ideas and as a way to achieve interop.

Is there going to be a single Tuscany HTTP service that listens for service requests and reference responses, or will there be separate listeners for the reference responses? (and how will this fit in with the existing Tuscany

ServletHost facility?)

My initial reaction would be to leave that up to the binding to decide. It can have one transport listener that picks things up and passes them back through the reference or it may have multiple (e.g. maybe in JMS someone decides to send response back over a different queue).

Sorry for all the questions but I'm interested in this from being involved in Synapse which is trying to do similar things. As an fyi, in Synapse we've just added a non-blocking http transport for Axis2 based on asyncweb which

we may be able do something with in Tuscany. See:

Maybe we could have an async transport service similar to what Synapse has (care to take that on)? Also, Jetty 6 has support for NBIO.

Jim

http://svn.apache.org/viewvc/incubator/synapse/trunk/java/modules/ nhttp/

  ...ant

On 8/31/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:

Sure, np.

The basic idea is to use (1) the wiring and connection infrastructure that is there (or shortly to be there once the patch is applied) for composite references and services, and (2) the non-blocking execute with callback

facilities of Axis2's operation client.

Axis2Reference would need to be modified to use a variation of

Axis2TargetInvoker that calls operationClient.execute(false) and that sets

up a callback target invoker as the callback registered with

operationClient. This could work as a subclass of Axis2TargetInvoker,

probably in a similar way as AsyncJavaTargetInvoker is a subclass of
PojoTargetInvoker (minus the new thread creation bit, that becomes
unnecessary).

Axis2Service is a bit trickier, mainly because the Axis2 api is not quite there for our needs. At first glance, it would seem like we could create

an
Axis2ServiceInOutAsyncMessageReceiver that extends Axis2's

AbstractInOutAsyncMessageReceiver. But this latter class assumes that the business logic returns the result synchronously, i.e., when its call to invokeBusinessLogic is done it assumes that the result has been left in newmsgCtxt, and then it turns around and invokes the callback with the result or fault. We need to be able to separate this function so that the async invocation of the target component does happen in an independent Axis2ServiceInOutAsyncMessageReceiver, but the callback invocation happens in an Axis2ServiceCallbackTargetInvoker that is created by Axis2Service

and

that is set on the Axis2Service's outbound wire by the connector. A key

item
is the in-message context provided to

Axis2ServiceInOutAsyncMessageReceiver's receive and that is needed in Axis2ServiceCallbackTargetInvoker to create the out-message context. We

may
end up using a workContext techinque similar to that used by

AsyncJavaTargetInvoker in the local case. It may be possible to factor out

the databinding function that is common with
Axis2ServiceInOutSyncMessageReceiver.

Needless to say, this is a first pass at putting this together, so
comments
are welcome.

----- Original Message -----
From: "ant elder" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, August 31, 2006 9:58 AM
Subject: Re: Inner composite patch, was Re: Optiional Autowire


> On 8/31/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:
>
> <snip/>
>

> I am getting a good picture of what needs to be done for async callbacks >> over ws binding w/axis2 and I can keep looking at this in my current

>> sandbox
>> until you are done, so it's not like I am stuck.
>
>

> Could you post an email about what and how you're looking at doing async

> and

> Axis2? There's a few of us who've worked on this binding in the past

who'd

> be interested, I didn't even know you were looking at this until it was

> mentioned on IRC yesterday (unless I missed some previous email).
>
>   ...ant
>

-------------------------------------------------------------------- -

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]