Associating callback methods, was Re: NoClassDefFoundError, apparently in Axis2

[Ignacio Silva-Lepe <is...@verizon.net>]

Yeah, actually, for components that are directly wired this is not really a 
problem. But for a component that is invoked remotely via a binding, this is 
a problem for the current architecture. In particular, without a more or 
less explicit association of callback methods, it does not seem to be 
possible to statically setup target invokers on the invocation chains for 
the outbound wire on a bound reference, e.g., Axis2Reference.

We will probably depend on dynamic information to be conveyed by a response 
message, and then use this info to complete the wiring and connection setup.

For instance, with Axis2 we'll need to carry an indicator of what callback 
method was invoked, with the Tuscany infrastructure needing to unpack this 
info to perform the association. Notice that a correlation id does not 
suffice as it only indicates an association between the response and request 
messages

This can have interop ramifications if we want to allow a component with an 
Axis2-bound reference to invoke an arbitrary implementation of the 
corresponding web service. And this is just considering Axis2, other 
bindings are bound to have similar issues (pun not intended ... maybe ;-)

----- Original Message ----- 
From: "scabooz" <sc...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Saturday, September 30, 2006 10:54 AM
Subject: Re: NoClassDefFoundError, apparently in Axis2


> FWIW, This is an area of the specs that are under discussion, and this
> exact point has been raised.  The following assumes that conversational
> support is out of scope of this thread of discussion.  However, it does
> have effect on the use cases in the end.
>
> The intention in the current specs is that there is no relationship 
> between
> i1 and c1 operations.  The spec is open enough to allow the consumer
> to invoke i1 operations independently from the service provider invoking
> c1 operations.  I think this is a 4th case that you haven't even listed 
> yet.
> Therefore, if the designer of the service wants to build in a relationship
> between i1 operations and c1 operations, they are free to do that, but
> the SCA runtime is not aware of it.  Such a relationship would be
> documented in an appropriate out of band mechanism. An example
> of such a relationship is the idea that a callback invocation carries a
> response from a previous i1 invocation by the consumer. It's only the
> business logic in the callback service that knows this. I think this is 
> your
> case3.
>
>
> Dave Booz
>
> ----- Original Message ----- 
> From: "Ignacio Silva-Lepe" <is...@verizon.net>
> To: <tu...@ws.apache.org>
> Sent: Saturday, September 30, 2006 10:07 AM
> Subject: Re: NoClassDefFoundError, apparently in Axis2
>
>
>> Some more thoughts on this.
>>
>> The specs (assembly and C&I) do not seem to be very explicit about what 
>> should happen with an interface that is annotated as @Callback and that 
>> defines more than one method. But notice that if this is the case then 
>> the next question pertains to a previous question, which is what happens 
>> when the callback interface (the one in the annotation, not the annotated 
>> one) has more than one method.
>>
>> Let i1 be an intrerface annotated with @Callback(c1), where c1 is the 
>> callback interface. The simplest case is when both i1 and c1 have only 
>> one method. If i1 has > 1 methods there are two cases: c1 has only one 
>> method, and c1 has > 1 methods. The first case is the case at hand. 
>> Notice that one last case is where i1 has one method and c1 has > 1, but 
>> that really is a special case of the second case.
>>
>> The second case is the one we had asked about before, how do we associate 
>> methods in c1 with methods in i1. Again, the specs are not explicit about 
>> this. In general, this association may require knowledge about the 
>> implementation of i1. That is, i1Impl will get an injected instance of c1 
>> which then it will use in its method(s) to make callback invocations. 
>> Which c1 method is invoked in i1 is arbitrary and we may have to resort 
>> to non-trivial introspection to figure it out. Btw, nontice that this 
>> case also includes the first case.
>>
>> So it seems we have a choice of how to interpret the specs.
>> 1- The simplest choice is to assume i1 and c1 both have only one method.
>> 2- We can assume that c1 has only one method (case at hand) and 
>> introspect each method in i1 to figure out which is intended as async 
>> with callback and which is not. In addition, here we also have a choice 
>> of whether to treat non-callback methods as sync or async.
>> 3- We can try go for the general case.
>>
>> My vote is to go with choice 1, which is what I have been assuming so 
>> far, at least for the coming release. And if we don't feel comfortable 
>> with this choice long term, then we can try for choice 2 or maybe even 
>> choice 3, if we can make sense of it.
>> It would also be useful to try to go back to the spec collaboration to 
>> try to calrify the intent.
>>
>> Thoughts?



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org