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: <[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]
