Hi,
It makes sense to me to provide a few methods on
RuntimeComponentReference
and RuntimeComponentService to simplify the life of extension
developers.
Here's what I see from the usage pattern perspective.
1) For a reference, it's made available to the client either by
injection
(proxy) or ComponentContext (CallableReference or a proxy). Both the
java
and script implementation types support injections which requires the
creation of proxies. We have two things here:
a) Get the invoker for a given operation on the interface of the
reference.
b) Create a proxy for a reference based on the invokers for all the
operations on the interface of the reference
We can address a) by adding a method to the RuntimeComponentReference:
Invoker getInvoker(Binding binding, Operation operation);
The question: Is b) common to all implementation types hosted by the
java
runtime? Do we have the same ways to create proxies for injections?
If so, I suggest that we add a method like:
<T> T createProxy(Binding binding, Class<T> businessInterface);
But it seems to be duplicate with what we have in the ComponentContext
API,
we could use:
<T> T ComponentContext.getService(Class<T> businessInterface, String
referenceName);
2) For a service, the service binding provider is responsible to
dispatch
the inbound call to the promoted component. The incoming data varies on
the
binding protocols, for example, axis2 receives AXIOM which is
transformed
to
Object[] based on the interface contract of the promoted component
servie
and RMI binding receives java objects naturally. The binding provider
will
basically identify the operation and payload.
We could add a method to the RuntimeComponentService like:
Invoker getInvoker(Binding binding, Operation operation);
Then the service binding provider will wrap the payload into a
Message and
then call Invoker.invoke(Message).
For a service, there might be callbacks attached. We could provide a
method
like:
Invoker getCallbackInvoker(Binding binding, Operation operation).
I'll help add these methods if we agree. For less controversy, I can add
the
getInvoker() methods first.
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, May 09, 2007 8:54 AM
Subject: Re: Proxy's and invokers for RuntimeComponentService and
RuntimeComponentReference
> On 5/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> ant elder wrote:
>> > Looking at the binding and implementation extensions we have now
>> > there's
>> > still a bit of messy code in the way proxys and invokers for
>> > RuntimeComponentServices and RuntimeComponentReferences are
done. Eg,
>> > RMIBindingProvider.invokeTarget,
>> > Axis2ServiceBindingProvider.invokeTarget or
>> > ScriptImplementationProvider.createReferenceProxy. There's a lot of
>> > boilerplate code in those methods and also a lot of opportunity to
do
>> it
>> > wrong, eg wireList.get(0). Venkat and I were wondering if there's
>> > anything
>> > we could do to make this easier for extension writers?
>> >
>> > How about adding something like createProxy(Binding) and
>> > createInvoker(Binding) methods to RuntimeComponentService and
>> > RuntimeComponentReference?
>> >
>> > ...ant
>> >
>>
>> +1 for createInvoker() on RuntimeComponentReference. Or should it
be a
>> getInvoker() as I don't think we'll create a new one, right?
>>
>> I'm not sure about the createProxy()... a proxy seems interesting to
me
>> in a Java component, where the business logic expects a (proxy)
object
>> presenting the business interface. In a binding, I don't really
>> understand why we would use a Java proxy (which requires a Java
business
>> interface, expects individual arguments, and comes with some
overhead),
>> instead of just using Invoker.invoke(Message message).
>>
>> I'd suggest to leave Java Proxies to the Java component (or other
>> component implementation types where a Java proxy would really really
>> help). But in general, our invocation mechanism is
>> Invoker.invoke(Message message). If people think that invoke(Message
>> message) is not good, then let's switch everything to an
>> invoke(Object[]) :) but I'd like to avoid having 2 different
invocation
>> mechanisms all over the place, one is probably enough :)
>>
>> How about RuntimeComponentService.getInvoker()?
>>
>> --
>> Jean-Sebastien
>
>
> With our runtime written in Java I'm not sure how uncommon wanting a
proxy
> will be, the script implementation already needs one (
> ScriptImplementationProvider.createReferenceProxy), the json-rpc
binding
> will as well I suspect. But, what I really was complaining about
was all
> the
> messing about with the Tuscany internal things like WireList and
Chains
> etc,
> so if we have some sort of invoker method that does all that I guess
> you're
> right and we don't really need a proxy methods as well.
>
> So that will need to be something like :
>
> RuntimeComponentService.getInvoker(Binding, Operation) and
> RuntimeComponentReference.getInvoker(Binding, Operation) and they
could
> return an instance of our existing o.a.t.invocation.Invoker?
>
> ...ant
>
