You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ignacio Silva-Lepe <is...@verizon.net> on 2006/08/31 19:47:54 UTC
Async callbacks over ws binding w/Axis2, was Re: Inner composite patch
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" <an...@gmail.com>
To: <tu...@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 <is...@verizon.net> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Async callbacks over ws binding w/Axis2, was Re: Inner composite patch
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 31, 2006, at 10:47 AM, Ignacio Silva-Lepe 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.
I'm reviewing the patch now...It would also be interesting to get
some of the Celtix (Jervis, Dan?) people to comment on how this could
be done with that binding as well.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Fwd: Async callbacks over ws binding w/Axis2, was Re: Inner composite patch
Posted by Jim Marino <jm...@bea.com>.
This hasn't shown up on this list...sending again
Begin forwarded message:
> From: Jim Marino <jm...@myromatours.com>
> 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 <is...@verizon.net> 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" <an...@gmail.com>
>>> To: <tu...@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 <is...@verizon.net> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Async callbacks over ws binding w/Axis2, was Re: Inner composite patch
Posted by Jim Marino <jm...@myromatours.com>.
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 <is...@verizon.net> 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" <an...@gmail.com>
>> To: <tu...@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 <is...@verizon.net> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Async callbacks over ws binding w/Axis2, was Re: Inner composite patch
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
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" <an...@gmail.com>
To: <tu...@ws.apache.org>
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 <is...@verizon.net> 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" <an...@gmail.com>
>> To: <tu...@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 <is...@verizon.net> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Async callbacks over ws binding w/Axis2, was Re: Inner composite patch
Posted by ant elder <an...@gmail.com>.
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 <is...@verizon.net> 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" <an...@gmail.com>
> To: <tu...@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 <is...@verizon.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>