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