ant elder wrote:
> Sounds good to me.
>
> ...ant
>
> On 5/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> 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
>> >
>>
I'm still having trouble understand the requirement to use Java proxies
to develop extensions, given that:
- there is not necessarily a business Java interface specified on a
reference or service
- a Java proxy can only be created if we have the business Java
interface
So isn't any use of a Java proxy going to break as soon as there is no
business Java interface?
In other words, can I expose as a JSON-RPC service or invoke from a
script a component that does not expose a Java business interface? I
think that the answer should be yes :)
The other trouble I have with the Proxy approach is seeing a generic
piece of runtime (like the JSON-RPC binding or scripting implementation
provider) first go through a specific generated (or dynamically created)
proxy which will in turn dispatch to a generic
java.lang.reflect.InvocationHandler... Couldn't we dispatch directly to
the generic InvocationHandler? or even better directly to our Invoker
which is pretty close to an InvocationHandler?
