Ok, the bing picture in my mind is at the assembly level as follows:
At the client side:
- component uses reference with a bi-directional interface,
which implies the component implements the callback interface
- component invokes reference
- component receives callback invocation
At the service side:
- component is referenced by service with the bi-directional interface,
which implies the component gets a handle on a callback object
- component receives forward invocation
- component invokes callback object
A slightly lower level depends on the binding used by the client side
reference and service side service. For the case at hand I am assuming
a ws/Axis2 binding. The details of how soap/http requests are handled
depend on how Axis2 handles operationClient.execute(false) on the
client, and how AbstractMessageReceiver.receive is invoked. One
detail under our control is how we handle this latter receive request
and the callback from the service component. My plan was to use a
similar approach as AbstractInOutAsyncMessageReceiver except that
that the invocation of the component and the send off of the callback
get separated into a similar message receiver and a target invoker, as
sketched out below. That is, an Axis2ServiceInOutAsyncMessageReceiver
would or could invoke the business logic on a separate thread to return
control asap to the axis engine that called receive.
Wrt wsa:ReplyTo, it seems to me that SCA bi-directional interfaces and
callbacks play a role of invocation pattern more so than of message
exchange pattern. In my mind, wsa:ReplyTo has more to do with the mep
in use, and so the use of a bi-directional interface is independent of what
form was:ReplyTo has. This should also afford more freedom wrt the
specific setup of the Tuscany runtime that hosts components that use
bi-directional interfaces. I.e., regardless of whether the particular
Tuscany host is able to define a separate listener, a component that uses
a bi-directional interface should be able to be deployed just the same.
I suppose this also helps me duck the question of where in the
runtime is the value of the wsa:ReplyTo header is actually set ... ;-)
----- Original Message -----
From: "ant elder" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 01, 2006 7:00 AM
Subject: Re: Async callbacks over ws binding w/Axis2, was Re: Inner
composite patch
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)?
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?
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?)
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:
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: <[email protected]>
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]
