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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
