On 5/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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?
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
