You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2007/05/09 15:01:29 UTC
Proxy's and invokers for RuntimeComponentService and RuntimeComponentReference
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
Re: Proxy's and invokers for RuntimeComponentService and RuntimeComponentReference
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 5/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> ant elder wrote:
>> > Sounds good to me.
>> >
>> > ...ant
>> >
>> > On 5/9/07, Raymond Feng <en...@gmail.com> 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" <an...@gmail.com>
>> >> To: <tuscany-dev@ws.apache.org >
>> >> 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 < jsdelfino@apache.org> 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?
>
>
> In the Java environment isn't there always going to be things that
> expect to
> work on something like a proxy object with the correct interface? The
> json-rpc-java library we use only works if the object instance Tuscany
> registers with json-rpc-java has methods for all the operations on the
> service. That seems like it could be fairly common.
>
> But, I think it would be fine for Tuscany not to have a createProxy
> method
> and for extensions to just create their own if required using the service
> interface and invoker...but the problem is that that requires a Java
> interface. Is this a symptom of problem we have with the current
> support for
> different IDLs? Do we need a something like we have for the databindings
> where we can transform IDLs into whatever IDL is required by the
> extensions?
> There's various places in the current code where it casts Interface to
> JavaInterface and calls getJavaClass on it, and as pointed out above
> thats
> not always going to work.
>
> Maybe each IDL impl needs a way to get an instance of its Interface type
> from a generic Interface, something like:
>
> o.a.t.s.interfacedef.java.JavaInterface getInterface(
> o.a.t.s.interfacedef.Interface i)
>
> which under the covers could either just return the passed in
> interface if
> its already a JavaInterface otherwise does something like use ASM to
> dynamically create the matching interface class. The
> o.a.t.s.interfacedef.WSDLInterface could do similar so we can always
> get a
> WSDL doc when required.
>
> ...ant
>
Ant,
Here's what I'm concerned about with this approach:
1. Have extensions start to use a Java dynamic proxy for convenience
2. Have code starting to use Java reflection to talk to these proxies
3. Since all of this requires a business Java interface, use some ASM
machinery to generate Java business interfaces dynamically
Doing (1) + (2) is pretty inefficient and I think can probably be
simplified in most cases (more below with the concrete JSONRPC use case).
(3) will not always be possible. Some languages like Ruby don't have the
concept of an interface, so I'm not sure how we'll generate a Java
interface for a Ruby script for example. Also as soon as a business
service passes complex data, I guess we'll have to generate Java
databindings for that data on the fly. This starts to look really
complicated to me.
I think we should look at the concrete use cases for these Java proxies
and see how they are used. Starting with the JSONRPC binding, here's an
invocation stack:
Thread [pool-1-thread-3] (Suspended (breakpoint at line 97 in
JavaTargetInvoker))
JavaTargetInvoker.invokeTarget(Object, ConversationSequence,
WorkContext) line: 97
JavaTargetInvoker(TargetInvokerExtension).invoke(Message) line: 44
TargetInvokerInvoker.invoke(Message) line: 46
JDKInvocationHandler(AbstractInvocationHandler).invoke(InvocationChain,
Object[], Object, LinkedList<URI>, WorkContext) line: 76
JDKInvocationHandler.invoke(Object, Method, Object[]) line: 111
$Proxy0.echo(String) line: not available
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 585
JSONRPCBridge.call(Object[], JSONObject) line: 1122
JSONRPCEntryPointServlet.service(HttpServletRequest,
HttpServletResponse) line: 127
JSONRPCEntryPointServlet(HttpServlet).service(ServletRequest,
ServletResponse) line: 820
ServletHolder.handle(ServletRequest, ServletResponse) line: 491
ServletHandler.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 367
SessionHandler.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 181
ContextHandler.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 689
Server(HandlerWrapper).handle(String, HttpServletRequest,
HttpServletResponse, int) line: 139
Server.handle(HttpConnection) line: 285
HttpConnection.handleRequest() line: 457
HttpConnection$RequestHandler.content(Buffer) line: 765
HttpParser.parseNext() line: 627
HttpParser.parseAvailable() line: 209
HttpConnection.handle() line: 357
SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run()
line: 329
Jsr237Work<T>.run() line: 61
ThreadPoolWorkManager$DecoratingWork.run() line: 206
ThreadPoolExecutor$Worker.runTask(Runnable) line: 650
ThreadPoolExecutor$Worker.run() line: 675
Thread.run() line: 595
Here we see the JSONRPCBridge use reflection to call a dynamic proxy
directly. This is an illustration of my concern with these proxies. It
seems to me that we can make this much simpler, and maybe extend
JSONRPCBridge or use the other JSON APIs directly to avoid all that
reflection + proxying, and dispatch the invocation to our Invoker directly.
This line:
JSONRPCBridge.call(Object[], JSONObject) line: 1122
takes the Object[] that we could pass directly to our Invoker, as well
as the name of the invoked method in the given JSONObject.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proxy's and invokers for RuntimeComponentService and RuntimeComponentReference
Posted by ant elder <an...@gmail.com>.
On 5/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > Sounds good to me.
> >
> > ...ant
> >
> > On 5/9/07, Raymond Feng <en...@gmail.com> 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" <an...@gmail.com>
> >> To: <tuscany-dev@ws.apache.org >
> >> 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 < jsdelfino@apache.org> 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?
In the Java environment isn't there always going to be things that expect to
work on something like a proxy object with the correct interface? The
json-rpc-java library we use only works if the object instance Tuscany
registers with json-rpc-java has methods for all the operations on the
service. That seems like it could be fairly common.
But, I think it would be fine for Tuscany not to have a createProxy method
and for extensions to just create their own if required using the service
interface and invoker...but the problem is that that requires a Java
interface. Is this a symptom of problem we have with the current support for
different IDLs? Do we need a something like we have for the databindings
where we can transform IDLs into whatever IDL is required by the extensions?
There's various places in the current code where it casts Interface to
JavaInterface and calls getJavaClass on it, and as pointed out above thats
not always going to work.
Maybe each IDL impl needs a way to get an instance of its Interface type
from a generic Interface, something like:
o.a.t.s.interfacedef.java.JavaInterface getInterface(
o.a.t.s.interfacedef.Interface i)
which under the covers could either just return the passed in interface if
its already a JavaInterface otherwise does something like use ASM to
dynamically create the matching interface class. The
o.a.t.s.interfacedef.WSDLInterface could do similar so we can always get a
WSDL doc when required.
...ant
Re: Proxy's and invokers for RuntimeComponentService and RuntimeComponentReference
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> Sounds good to me.
>
> ...ant
>
> On 5/9/07, Raymond Feng <en...@gmail.com> 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" <an...@gmail.com>
>> To: <tu...@ws.apache.org>
>> 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 <js...@apache.org> 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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proxy's and invokers for RuntimeComponentService and RuntimeComponentReference
Posted by ant elder <an...@gmail.com>.
Sounds good to me.
...ant
On 5/9/07, Raymond Feng <en...@gmail.com> 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" <an...@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Proxy's and invokers for RuntimeComponentService and RuntimeComponentReference
Posted by Raymond Feng <en...@gmail.com>.
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" <an...@gmail.com>
To: <tu...@ws.apache.org>
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Proxy's and invokers for RuntimeComponentService and RuntimeComponentReference
Posted by ant elder <an...@gmail.com>.
On 5/9/07, Jean-Sebastien Delfino <js...@apache.org> 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
Re: Proxy's and invokers for RuntimeComponentService and RuntimeComponentReference
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org