kelvin goodson wrote:
I've been having a bit of a look at one of new tests added to the
OASIS repo today to do with asynchronous service invocation.
<snip>
I think the latter warning is because none of the bindings implement
the asynchInvocation intent.
Yes, that's correct.
I'd like to try to begin to map out what other work might be necessary
to get the asynch service invocation support in place in the runtime.
Does anyone have any preconceived ideas about how this should look?
Can anybody help me break this up into bite size chunks?
I opened a new JIRA (Tuscany 3606
https://issues.apache.org/jira/browse/TUSCANY-3603) to track this and
any subtasks we might break this down into.
Kelvin.
I think that there are changes required in the following areas:
1) In the introspecting and in the comparison of <interface.java/> which references a Java interface
class that has the asynchronous server format.
Such an interface needs to be viewed in 2 ways, depending on what we're trying
to do:
a) mapped to the equivalent request/response interface for matching against other interfaces
(compatible, superset/subset etc)
b) treated in a special way by the invokers when we're trying to invoke one of the methods on the
interface
I think that a) needs to be done in the interface-java module
I suspect that b) must be handled in the code that sets up the invokers and in the invokers
themselves, such as implementation-java-runtime
2)Part of the invocation process involves handling the ResponseDispatch object that is passed to the
async service. This object must correctly reflect the response message type. It must also contain
or reference all the information that is needed to transmit the response message back via the binding.
This will be new stuff that belongs somewhere general such as core - core.invocation.impl may be the
right place.
3) The bindings need to be involved. You rightly say that we need to mark the bindings as
"providing" the asyncInvocation intent. However, this is not straightforward, since the bindings
will really have to do something different when invoking an async service - and this has an impact
on the whole chain between the client and the service too.
In essence, I think that things look like a service with a callback, but where the forward operation
is a OneWay and the callback operation is also a OneWay. For some bindings, this is not a big deal
- binding.jms basically works that way today. For other bindings, it is a bigger deal - binding.ws
for example will need a lot more work. Either way, the client side of the binding must create an
endpoint that the server side can use to transmit the response message.
How we do this I am not sure about at the moment. I can envisage us seeing "asyncInvocation" on the
reference and then immediately creating a callback endpoint just as if the reference had a
callback interface. One curiosity here is that the client may well have the purely synchronous
interface, although in my opinion it would be wise to use the client async interface.
Perhaps one way to handle this is that the created endpoint should have a completely generic
interface that is actually handled by the binding or "system" code which then connects back to the
actual interface used by the client.
I feel the need for some diagrams here, to help get the concept over better.
However, I've got the feeling that we may already have a lot of the mechanics that we need in the
codebase already and that by clever use of this code, we can implement the asyncInvocation function
without too much effort.
Yours, Mike.
