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 <[email protected]> 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
