Pavel, I've moved proposals from this thread to the IEP [1] and described changes to protocol, please have a look.
[1] : https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation пн, 18 мая 2020 г. в 15:09, Pavel Tupitsyn <ptupit...@apache.org>: > 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 <plehanov.a...@gmail.com> > 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 > > >
