Hi Alex, Thanks for starting this thread. I've created the IEP some time ago but then got distracted by other things.
My thoughts: *1. Create service proxy on each invoke request* Single client operation is a lot simpler to implement on both sides (client and server), so I would prefer this way. The only concern here is performance. My plan was to benchmark and then decide. *2. Method resolution* Taking Python and other dynamically typed languages into account, current PlatformService implementation seems to be the best fit. If we decide to add an optional signature, we should not make it Java-specific: use binary type IDs (that are already part of the protocol) to specify parameter types. On Mon, May 18, 2020 at 2:27 PM Alex Plehanov <[email protected]> wrote: > Hello Igniters, > > I have plans to implement service invocation in thin clients. I've already > implemented a PoC for java thin client and want to discuss some details. > Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net thin > client [2]. > > To invoke the service method by java thick client we can get service proxy > by: > IgniteServices.serviceProxy(String name, Class<? super T> svcItf, boolean > sticky, long timeout) > and then invoke the method on this proxy. > > Also, we already have service invocation functionality for .Net thick > client (see PlatformServices class). For .Net thick client there are two > types of operation related to service invocation: create a proxy and invoke > a method (this approach is identical to java thick client). > > But I think we can't use two operations for thin clients. If we create a > proxy by a separate operation we should store this resource somewhere on > server-side and we should also have an ability to close this resource when > it's not needed anymore. So there is an additional operation on client-side > needed to close the proxy explicitly. This is more complex from users point > of view than the current approach for java thick client, so I think it's > better to use only one operation for thin clients: OP_SERVICE_INVOKE and > create a service proxy on each method invocation. In this case, each > request should have at least these parameters: service name, interface > name, timeout, nodes set, method name, and args (sticky flag is useless > since we always will create a new proxy for each request). > > There is one more problem: methods of some interface can be overloaded. In > .Net thick client implementation there is a method used to find an > appropriate service method to invoke by method name and args values: > PlatformServices.ServiceProxyHolder#getMethod. Since we use here only args > values (don't have full information about args types) sometimes we can get > an error for overloaded methods. For example, if you have an interface > like: > > public interface TestServiceInterface { > public String testMethod(String val); > public String testMethod(Object val); > } > > And invoke service like: > > Object arg = null; > svc.testMethod(arg); > > Java will resolve the correct method to call on client-side, but using only > arg value (null) it's impossible to get exactly one method on the > server-side (PlatformServices.ServiceProxyHolder#getMethod will throw an > error in this case: Ambiguous proxy method 'testMethod') > > To solve this problem we can pass full method signature (method name with > parameters types) instead of just method name. Or we can additionally pass > argument types to find exactly one method by Class.getMethod(String name, > Class<?>... parameterTypes). Also, we can support two approaches at the > same time: just the method name to simplify the implementation of non-java > thin clients, and full method signature to deal with overloaded methods. > > So, > What do you think about single operation for service invocation (create > service proxy on each invoke request)? > What do you think about ways to resolve the method? > > [1] : > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation > [2] : https://issues.apache.org/jira/browse/IGNITE-12754 >
