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
