Async Invocation and binding.sca

[Simon Laws <si...@googlemail.com>]

I'm just starting to look at JCA_7003 through 6 so wanted to kick off
a thread about how to get async invocation working over the default
binding (it only operates over binding.ws at the moment). I've started
with 7003 which happens to be the interesting case of a synch
reference and an asynch service.

What I'm first trying to work out is how the async callback Endpoint
is intended to be generated.

The code to do this kind of thing is in the
AsynchJDKInvocationHandler. This is injected by the JDKProxyFactory if
it detects an async reference. So it won't be injected in this case as
only the service is async. If it were injected if would, in this case,
look to see if the target is asynch. However is does this before the
bind has resolved the target so an issue there as well. I hacked both
of these locally and am looking at the next issue.

We do have the option of course to special case the local default
binding so that the callback reference is not required but It would be
useful to understand the full flow before optimizing.

Any insight appreciated.

Regards

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Async Invocation and binding.sca

[Simon Laws <si...@googlemail.com>]

On Wed, Aug 25, 2010 at 4:43 PM, ant elder <an...@gmail.com> wrote:
> On Wed, Aug 25, 2010 at 4:36 PM, Simon Laws <si...@googlemail.com> wrote:
>
>
>> - Check that we can use binding.ws under binding.sca successfully in
>> async mode.
>
> By that are you implying that the only binding.sca we'll have that
> works is when using the ws based version of the sca binding?
>
>   ...ant
>

No, I'm implying that that's the one I want to fix first because I
understand it.

The async function is not really binding dependent as it stands, it
only requires bindings to pass certain headers in the messages that
are sent. Fixing others should not be too onerous. Optimizing this to
exploit naturally asynchronous bindings is another question, e.g. JMS
should fit pretty well.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Async Invocation and binding.sca

[ant elder <an...@gmail.com>]

On Wed, Aug 25, 2010 at 4:36 PM, Simon Laws <si...@googlemail.com> wrote:


> - Check that we can use binding.ws under binding.sca successfully in
> async mode.

By that are you implying that the only binding.sca we'll have that
works is when using the ws based version of the sca binding?

   ...ant

Re: Async Invocation and binding.sca

[Simon Laws <si...@googlemail.com>]

Hi Mike

I just checked in (r989157) the changes to-date in this area. Comments in-line

Simon
>>
> Simon,
>
> Let me deal with the question of when a client reference should follow the
> asynchronous service pattern - ie when the client should treat the server as
> if there is going to be a long delay between making a request and getting
> the response back.
>
> First, there is the case where the client reference or its binding is marked
> with "asyncInvocation" intent.  In this case, the binding should react as if
> the service is asynchronous.
>
> Second there is the case where there is NO asyncInvocation intent on the
> reference, but there is a wire to a service to which "asyncInvocation" is
> applied (either directly or from the interface of the service
> implementation).  This second case can only occur when there is no explicit
> binding on the reference - and in this case the binding is being "inherited"
> from the service which is the target of the wire.
>
> In BOTH of these cases, the reference binding should be treated as if
> "asyncInvocation" is applied to the reference - and the result is that the
> binding must behave as if the request message transmission is completely
> separate from the response message - ie things are treat as if there were
> two one-way operations, one in the forward direction and one in the reverse
> direction.
>
> I note that the current client code does not do this checking at the moment
> - some extra up-front work is required to test for the presence of the
> asyncInvocation intent in the relevant locations.

I believe that, now that the AsyncJDKInvocationHandler is always used
(see below), both EPR and EP intents are checked when deciding if the
async or synch pattern should be used.

>
>
> On the client reference side, the reference itself can have one of two forms
> - either the standard "synchronous" form of a Java interface (simple
> request/response operarations) or the JAXWS async form of a Java interface
> (3 forms for each operation - sync, polling, callback).  The client can use
> either, whether the service is synchronous or asynchronous.  It is clearly
> unwise to choose the synchronous forms of a method in the case where the
> service is async, but I don't think that it is SCA's job to police that.

I agree, and this implies that we need to be ready to do async
invocation regardless of how the reference is marked. We don't know
until EPR/EP bind time what the binding will be so we need to add the
AsyncJDKInvocationHandler at proxy creation time. The async/sync
pattern determination is them done a run time.

>
> It is pragmatic perhaps to choose to use the "async" client code that is
> currently in the codebase, whether the client is using the sync or the async
> forms of the Java interface.  The async code can in principle cope with
> either sync or async services - it may need some optimisation, but I think
> that it should work very much as it is.  This is a change from the current
> code, but I think it is the right way forward for getting all the behaviour
> that we need.

+1. This is the foundation of the code I just committed. This is a
"doing the right thing before doing it right" approach. There are
several improvements/optimizations we could/should make. For example,

- Sort out the use of WS_MESSAGE_ID
- Check that we can use binding.ws under binding.sca successfully in
async mode.
- Look to defer to bindings that naturally support async operation. To
do this we need to review how our invocation chains work. Currently
they combine request and response processing. We'd have to split this
up

Re: Async Invocation and binding.sca

[Mike Edwards <mi...@gmail.com>]

Simon Laws wrote:
> I've made enough local changes to get 7003, 7004 and 7005 working and
> this is what I found.
> 
> The spec doesn't seem to mandate that the reference interface should
> be marked with asyncInvocation even if the service is. Even when the
> reference interface is marked in such a way the client could choose to
> use the synchronous form of the operation. There is code in the
> AsnchJDKInvocation handler to handle this case so I enabled it for
> this situation by doing the following
> 
> - In JDKProxyFactory I enabled the AsyncJDKInvocationHandler in all situations.
> - I called EPR.getInvocationChains before the
> AsyncJDKInvocationHandler tests whether the service is async to ensure
> that the endpoint in question is resolved
> - I changed the binding.sca invoker to send the callback endpoint if
> one is available to send
> - I changed the ResponseDispatchImp to pick up MESSAGE_ID as well as
> WS_MESSAGE_ID. The WS stuff seems to have bled into the general
> runtime.
> 
> I'll attach the specific changes as a JIRA patch shortly when I've had
> a look at why 7006 isn't working.
> 
> The is exploiting the general async pattern, that Mike implemented, in
> the local default binding scenario. I expect this could be optimized
> but it's useful that it's using a common pattern with the ws binding.
> When binding.sca is running in remote mode with binding.ws underneath
> it this should make getting asynch to work easier.
> 
> 
> Simon
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
> 
Simon,

Let me deal with the question of when a client reference should follow the asynchronous service 
pattern - ie when the client should treat the server as if there is going to be a long delay between 
making a request and getting the response back.

First, there is the case where the client reference or its binding is marked with "asyncInvocation" 
intent.  In this case, the binding should react as if the service is asynchronous.

Second there is the case where there is NO asyncInvocation intent on the reference, but there is a 
wire to a service to which "asyncInvocation" is applied (either directly or from the interface of 
the service implementation).  This second case can only occur when there is no explicit binding on 
the reference - and in this case the binding is being "inherited" from the service which is the 
target of the wire.

In BOTH of these cases, the reference binding should be treated as if "asyncInvocation" is applied 
to the reference - and the result is that the binding must behave as if the request message 
transmission is completely separate from the response message - ie things are treat as if there were 
two one-way operations, one in the forward direction and one in the reverse direction.

I note that the current client code does not do this checking at the moment - some extra up-front 
work is required to test for the presence of the asyncInvocation intent in the relevant locations.


On the client reference side, the reference itself can have one of two forms - either the standard 
"synchronous" form of a Java interface (simple request/response operarations) or the JAXWS async 
form of a Java interface (3 forms for each operation - sync, polling, callback).  The client can use 
either, whether the service is synchronous or asynchronous.  It is clearly unwise to choose the 
synchronous forms of a method in the case where the service is async, but I don't think that it is 
SCA's job to police that.

It is pragmatic perhaps to choose to use the "async" client code that is currently in the codebase, 
whether the client is using the sync or the async forms of the Java interface.  The async code can 
in principle cope with either sync or async services - it may need some optimisation, but I think 
that it should work very much as it is.  This is a change from the current code, but I think it is 
the right way forward for getting all the behaviour that we need.


I hope that this helps clarify things.


Yours,  Mike.

Re: Async Invocation and binding.sca

[Simon Laws <si...@googlemail.com>]

I've made enough local changes to get 7003, 7004 and 7005 working and
this is what I found.

The spec doesn't seem to mandate that the reference interface should
be marked with asyncInvocation even if the service is. Even when the
reference interface is marked in such a way the client could choose to
use the synchronous form of the operation. There is code in the
AsnchJDKInvocation handler to handle this case so I enabled it for
this situation by doing the following

- In JDKProxyFactory I enabled the AsyncJDKInvocationHandler in all situations.
- I called EPR.getInvocationChains before the
AsyncJDKInvocationHandler tests whether the service is async to ensure
that the endpoint in question is resolved
- I changed the binding.sca invoker to send the callback endpoint if
one is available to send
- I changed the ResponseDispatchImp to pick up MESSAGE_ID as well as
WS_MESSAGE_ID. The WS stuff seems to have bled into the general
runtime.

I'll attach the specific changes as a JIRA patch shortly when I've had
a look at why 7006 isn't working.

The is exploiting the general async pattern, that Mike implemented, in
the local default binding scenario. I expect this could be optimized
but it's useful that it's using a common pattern with the ws binding.
When binding.sca is running in remote mode with binding.ws underneath
it this should make getting asynch to work easier.


Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com