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.
