You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by kelvin goodson <ke...@apache.org> on 2010/06/21 18:05:36 UTC
[discuss] asynch service invocation function
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.
As it stands, with no updates to the runtime, the new JCA_7003 test
falls over (unsurprisingly) with
SEVERE: [ASM50008] Component type reference not found for component
reference: Component = TEST_JCA_7003Component1 Reference = reference1
21-Jun-2010 16:11:34
org.apache.tuscany.sca.builder.impl.CompositePolicyBuilderImpl
[Composite: {http://docs.oasis-open.org/ns/opencsa/sca/200912},
Component: TEST_JCA_7003Component1, Service: Service1AsyncServer]
(IntentNotSatisfiedAtBuild)
WARNING: The intent
{http://docs.oasis-open.org/ns/opencsa/sca/200912}asyncInvocation
associated with policy subject (@19316843)Endpoint: URI =
TEST_JCA_7003Component1#service-binding(Service1AsyncServer/Service1AsyncServer)
has no matching policy set
I think the latter warning is because none of the bindings implement
the asynchInvocation intent.
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.
Re: [discuss] asynch service invocation function
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
I've added an initial implementation of ResponseDispatchImpl class into the
implementation-java-runtime module.
This is required for any invocation of an async server method, since it forms the final parameter of
any such method - it offers the route by which the service implementation returns the response
message from the method - or a Fault/Exception.
Yours, Mike.
Re: [discuss] asynch service invocation function
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Jun 23, 2010 at 10:23 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 2:12 PM, Mike Edwards
> <mi...@gmail.com> wrote:
>> Mike Edwards wrote:
>>>
>>> The next step is to fix up the interface mapping between the (client)
>>> synchronous version of the service interface and the (server) async version,
>>> so that these visibly different (Java) interfaces are treated as being
>>> compatible.
>>>
>>>
>>> Yours, Mike.
>>>
>> Folks,
>>
>> Today, we made changes to:
>>
>> JavaInterfaceImpl
>> JavaInterfaceFactoryImpl
>>
>> which enable a Java interface marked as "asyncInvocation" to be recognised
>> as an SCA async server interface and for methods following the async server
>> pattern
>> void xxxAsync( param1, param2..., DispatchResponse<ResponseMessage>)
>> to be recognized as async invocations.
>>
>> Such interfaces are stored in 2 forms
>>
>> a) the async form as introspected from the interface class
>> b) the equivalent mapped synchronous interface
>>
>> a) is used for the invokers
>> b) is used for other uses in particular for comparisons with other
>> interfaces in the structural hierarchy and in performing wiring
>>
>> This enables testcase JCA_7003 to run as far as the point where the invoker
>> on the service side is created.
>>
>> Updating the invoker is the next task.
>>
>>
>> Yours, Mike.
>>
>
> I had originally started that on JAXWSAsyncInterfaceProcessor
> following the same pattern that you are describing and I think it
> would be a better location for these code to reside.
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
I also note that there are files in core....
AsynchJDKInvocationHandler
AsynchResponse
Which I think Ant made a while back while initially looking at asynch
support. We need to look at those also, as well as the code Luciano
points to, and see what can be used.
I think we should avoid associating directly with JAXWS (e.g. in
naming our classes) for this asynch support as the feature is defined
by SCA rather than JAXWS. I.e. It's based on the JAXWS approach,
particularly on the client side, but doesn't follow it exactly.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [discuss] asynch service invocation function
Posted by Mike Edwards <mi...@gmail.com>.
Luciano Resende wrote:
> On Thu, Jun 24, 2010 at 3:18 PM, Mike Edwards
> <mi...@gmail.com> wrote:
>> Luciano Resende wrote:
>>> I had originally started that on JAXWSAsyncInterfaceProcessor
>>> following the same pattern that you are describing and I think it
>>> would be a better location for these code to reside.
>>>
>> Luciano,
>>
>> Could you tell us more about the work that is in
>> JAXWSAsyncInterfaceProcessor and why it would be a better place for the code
>> to be placed?
>>
>> Yours, Â Mike.
>>
>>
>>
>
> I started with all the introspection to filter the Async operations
> from the service interfaces based on all the rules specified on the
> SCA spec, and as it was based on JAX WS Client Async API, and we
> already had a JAX WS module handling JAX WS specific stuff, seemed to
> me as the best place to be.
>
> Having said that, my code wasn't in use, and we were doing a simple
> filter by name in various places.
>
Luciano,
OK, now I understand better - this is code for handling the JAX-WS Client side asynchronous interfaces.
So far, we've worked mainly on the SCA defined server-side asynchronous interfaces, which are not
the same thing. We may well want to use what you have done for the client side work.
One question that I have for you - the JAXWSAsyncInterfaceProcessor is placed in its own separate
module. Is there a need for this? Would it not be straightforward to include it as a separate
package within the interface-java module? I say this since there is no distinction in the SCDL for
these interfaces - they all are specified in <interface.java/> elements.
Since ANY client side interface could have these async methods, we have to check ALL Java interfaces
for their presence (tedious, but unlike the server side stuff, there is no simple "trigger" like the
presence of the @asyncInvocation annotation), so I don't see the JAXWS Async methods processing as
being anything other than "mainstream".
Yours, Mike.
Re: [discuss] asynch service invocation function
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Jun 24, 2010 at 3:18 PM, Mike Edwards
<mi...@gmail.com> wrote:
> Luciano Resende wrote:
>>
>> I had originally started that on JAXWSAsyncInterfaceProcessor
>> following the same pattern that you are describing and I think it
>> would be a better location for these code to reside.
>>
> Luciano,
>
> Could you tell us more about the work that is in
> JAXWSAsyncInterfaceProcessor and why it would be a better place for the code
> to be placed?
>
> Yours, Mike.
>
>
>
I started with all the introspection to filter the Async operations
from the service interfaces based on all the rules specified on the
SCA spec, and as it was based on JAX WS Client Async API, and we
already had a JAX WS module handling JAX WS specific stuff, seemed to
me as the best place to be.
Having said that, my code wasn't in use, and we were doing a simple
filter by name in various places.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: [discuss] asynch service invocation function
Posted by Mike Edwards <mi...@gmail.com>.
Luciano Resende wrote:
>
> I had originally started that on JAXWSAsyncInterfaceProcessor
> following the same pattern that you are describing and I think it
> would be a better location for these code to reside.
>
Luciano,
Could you tell us more about the work that is in JAXWSAsyncInterfaceProcessor and why it would be a
better place for the code to be placed?
Yours, Mike.
Re: [discuss] asynch service invocation function
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Jun 23, 2010 at 2:12 PM, Mike Edwards
<mi...@gmail.com> wrote:
> Mike Edwards wrote:
>>
>> The next step is to fix up the interface mapping between the (client)
>> synchronous version of the service interface and the (server) async version,
>> so that these visibly different (Java) interfaces are treated as being
>> compatible.
>>
>>
>> Yours, Mike.
>>
> Folks,
>
> Today, we made changes to:
>
> JavaInterfaceImpl
> JavaInterfaceFactoryImpl
>
> which enable a Java interface marked as "asyncInvocation" to be recognised
> as an SCA async server interface and for methods following the async server
> pattern
> void xxxAsync( param1, param2..., DispatchResponse<ResponseMessage>)
> to be recognized as async invocations.
>
> Such interfaces are stored in 2 forms
>
> a) the async form as introspected from the interface class
> b) the equivalent mapped synchronous interface
>
> a) is used for the invokers
> b) is used for other uses in particular for comparisons with other
> interfaces in the structural hierarchy and in performing wiring
>
> This enables testcase JCA_7003 to run as far as the point where the invoker
> on the service side is created.
>
> Updating the invoker is the next task.
>
>
> Yours, Mike.
>
I had originally started that on JAXWSAsyncInterfaceProcessor
following the same pattern that you are describing and I think it
would be a better location for these code to reside.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: [discuss] asynch service invocation function
Posted by Mike Edwards <mi...@gmail.com>.
Mike Edwards wrote:
>
> The next step is to fix up the interface mapping between the (client)
> synchronous version of the service interface and the (server) async
> version, so that these visibly different (Java) interfaces are treated
> as being compatible.
>
>
> Yours, Mike.
>
Folks,
Today, we made changes to:
JavaInterfaceImpl
JavaInterfaceFactoryImpl
which enable a Java interface marked as "asyncInvocation" to be recognised as an SCA async server
interface and for methods following the async server pattern
void xxxAsync( param1, param2..., DispatchResponse<ResponseMessage>)
to be recognized as async invocations.
Such interfaces are stored in 2 forms
a) the async form as introspected from the interface class
b) the equivalent mapped synchronous interface
a) is used for the invokers
b) is used for other uses in particular for comparisons with other interfaces in the structural
hierarchy and in performing wiring
This enables testcase JCA_7003 to run as far as the point where the invoker on the service side is
created.
Updating the invoker is the next task.
Yours, Mike.
Re: [discuss] asynch service invocation function
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jun 22, 2010 at 11:29 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 10:15 AM, Mike Edwards
> <mi...@gmail.com> wrote:
>
>
>> I've taken the first step on this one.
>>
>> binding.sca, binding.jms and binding.jms all now have
>> @mayProvide="sca:asyncInvocation" in their definitions.xml files.
>>
>
> Looking at keeping tuscany-binding-ws-runtime-jaxws-ri and
> binding-hazelcast-runtime in sync with that and I wonder where should
> those defintions.xml files go - in the runtime or model modules?
> Presently for JMS its in the model module but for WS and SCA its in
> the runtime module. If it can go in the model modules then i wont need
> to do anything for tuscany-binding-ws-runtime-jaxws-ri and
> binding-hazelcast-runtime.
>
> ...ant
>
It depends on whether we think the two binding implementations
will/may provide the same set of intents. They will at the moment but
I don't know what the answer is in the longer term. I don't think
there are any more imminent changes to the file (famous last words!).
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [discuss] asynch service invocation function
Posted by ant elder <an...@gmail.com>.
On Tue, Jun 22, 2010 at 10:15 AM, Mike Edwards
<mi...@gmail.com> wrote:
> I've taken the first step on this one.
>
> binding.sca, binding.jms and binding.jms all now have
> @mayProvide="sca:asyncInvocation" in their definitions.xml files.
>
Looking at keeping tuscany-binding-ws-runtime-jaxws-ri and
binding-hazelcast-runtime in sync with that and I wonder where should
those defintions.xml files go - in the runtime or model modules?
Presently for JMS its in the model module but for WS and SCA its in
the runtime module. If it can go in the model modules then i wont need
to do anything for tuscany-binding-ws-runtime-jaxws-ri and
binding-hazelcast-runtime.
...ant
Re: [discuss] asynch service invocation function
Posted by Mike Edwards <mi...@gmail.com>.
Mike Edwards wrote:
<snip>
>
> I think that there are changes required in the following areas:
>
...
> 3) The bindings need to be involved. You rightly say that we need to
> mark the bindings as "providing" the asyncInvocation intent.
...
>
> Yours, Mike.
>
OK,
I've taken the first step on this one.
binding.sca, binding.jms and binding.jms all now have @mayProvide="sca:asyncInvocation" in their
definitions.xml files.
This enables the EPR to EP mapping to get past the Intent/Policy mapping step when running
JCA_7003_TestCase.
I know that at the moment none of the bindings will actually do the async invocation correctly, but
the approach Kelvin & myself are taking on this is to use JCA_7003_TestCase as the driver for the
development of the changes necessary. The principle is to simply fix each problem encountered in
the execution of this testcase one by one until everything works. Some steps will be simple, other
ones will be complex, but this is "test driven development" ! ;-)
The next step is to fix up the interface mapping between the (client) synchronous version of the
service interface and the (server) async version, so that these visibly different (Java) interfaces
are treated as being compatible.
Yours, Mike.
Re: [discuss] asynch service invocation function
Posted by Simon Laws <si...@googlemail.com>.
Mike/Kelvin, generally sounds like you're approaching this in a
sensible way. Some comments in-line....
Simon
On Mon, Jun 21, 2010 at 11:22 PM, Mike Edwards
<mi...@gmail.com> wrote:
> 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
This will also have an impact on the endpoint/endpoint reference build
and activation phase depending on how we answer points 2 and 3 below.
>
> I think that a) needs to be done in the interface-java module
Sounds right
> 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
In the code at the moment core/CompositeActivatorImpl adds appropriate
providers to the component models. It's then the responsibility of the
Endpoints and EndpointReferences to create and manage their own
invocation chains. This includes creating the implementation invokers
from the implementation provider.
>
> 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.
And it depends on whether we decide to exploit a bindings natural
support for asynchronicity or whether to manage the asynchronicity
ourselves. It would be more consistent to do it at the Tuscany level
and we already have very similar support for callbacks so maybe it's
not such a great leap of faith.
>
> 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.
Our main ws binding is build on axis an that has native support for
interactions and the correlation required to make that work with
multiple transport channels. However in exploiting it we'd loose
control of the endpoint creation, e.g, integration into a webapp could
be tricky, so I agree that is seems sensible to consider this at the
Tuscany level first and see how it goes.
>
> 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.
We can't necessarily create the asyncInvocation at build time. We may
have a synch client talking to an asynch service and we may not be
able to match the two until runtime. We've just done some work to
solve this late endpoint creation problem for callbacks so we can
re-use some of that. Needless to say the important thing is that an
endpoint is created. One the code is in place the timing of creation
is not that important and doesn't actually impact the message exchange
pattern.
>
> 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.
+1 Some interaction diagrams would help.
>
> 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.
>
>
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [discuss] asynch service invocation function
Posted by Mike Edwards <mi...@gmail.com>.
Mike Edwards wrote:
> <snip>
.
>
> I'll commit this code soon, once I've confirmed that it does not harm
> existing modules and tests.
>
Done - initial code extensions and modificiations committed.
Testcase JCA_7003 now passes, which is the basic async service operation testcase.
Yours, Mike.
Re: [discuss] asynch service invocation function
Posted by Mike Edwards <mi...@gmail.com>.
Mike Edwards wrote:
<snip>
> I think that there are changes required in the following areas:
<snip>
> 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
<snip>
> 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.
>
Folks,
Today I concentrated on the service-side invocation sequence for async server operations.
This is based mostly around a new invoker:
JavaAsyncImplementationInvoker
...which is done as a subclass of JavaImplementationInvoker, all in java-implementation-runtime
The new invoker concentrates on creating the correct set of input parameters for the async method
and in particular adds in a ResponseDispatch object as the final parameter.
The invoker now makes the invocation and then calls the ResponseDispatch.get() method to retrieve
the response message, which can involve waiting for the service processing to complete.
With this implemented, I am now able to run the JCA_7003_TestCase successfully, which has a client
invoke an async service operation.
I'll commit this code soon, once I've confirmed that it does not harm existing modules and tests.
Now, this is only a first step, since clearly, we are still using synchronous versions of the
bindings. The next stage is to look at the bindings and to build response handling chains that can
be separated from the request chains and which can be invoked directly from the ResponseDispatch
object through a callback...
Yours, Mike.
Re: [discuss] asynch service invocation function
Posted by Mike Edwards <mi...@gmail.com>.
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.