# Java clients **URL:** \ **Category:** Elasticsearch\ **Created:** [February 20, 2010, 7:27am UTC](https://discuss.elastic.co/t/java-clients/2823 "2010-02-20T07:27:28Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Lukas\_Vlcek1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lukas_vlcek1/32/819_2.png) [@Lukas\_Vlcek1](https://discuss.elastic.co/u/Lukas_Vlcek1)\ **Post date:** [February 20, 2010, 7:27am UTC](https://discuss.elastic.co/t/java-clients/2823/1 "2010-02-20T07:27:28Z")
I found there are three implementations of o.es.c.Client interface. I would like to understand what is the difference. Please take a look at the below findings and let me know if there is any miss-understanding, So far I've learned that: ServerClient - this is tied to a particular server instance and there is always only one client for one server. I guess it should never be instantiated (though it has public constructor) but it is the server which is responsible to create and close this instance. TransportClient - it can connect to one or more servers using port number. JavaDoc says it is not part of the cloud, which I think means that the purpose of this class is to connect to server(s) via net whereas the ServerClient talks to server directly (kind of embedded mode). InternalTransportClient - used internally by TransportClient only. So there is no practical use case for this implementation (other then it is used by ES API internally, thus it could be removed in the future and developer should never code against this object). So when talking to cloud via net I will always be dealing with TransportClinet as it can talk to many servers, contrary ServerClinet can talk to one server only and moreover the ServerClient lives within server scope. Does it also mean that TransportClient forwards requests to particular ServerClients when talking to servers? Regards, Lukas ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [February 20, 2010, 10:04am UTC](https://discuss.elastic.co/t/java-clients/2823/2 "2010-02-20T10:04:29Z")
Hi, The Java API is still something that I am working on in order to finalize but I it is great that you brought it up. Currently, there are two main implementation of the Client interface, the ServerClient, and the TransportClient. You are correct regarding the ServerClient, you should not create a new instance of it yourself, but instead, use the Server#client() method to get it. The ServerClient is just an API to use when starting an embedded Server (be it a data node or not). The Server instance starts a node, and that node will be part of the cluster (it will get cluster events, and so on). Using the API, you still work against the whole cluster, meaning that if you index something, and it needs to get to another node to be indexed, then there will be automatic routing. The benefit of using the ServerClient (or starting a Server in your "client" Java application) is the fact that you always do only one hop. For example, the index operation will perform the routing and "hit" the correct node with the data. The TransportClient is a dumb down Transport based client, where you add addresses and it will connect to the nodes, discover through them the rest of the nodes, and do dummy load balancing for each operation. This means that when you index something, the transport client will peak node at random, perform the index operation on it, and _that_ node will do the hashing and proper routing to the correct node. You would probably always want to use ServerClient if you can, because of the performance benefits (usually with node.data set to false, so it won't hold any index information). But then it means that the client will be part of the cluster. The question if you can do it or not is up to the Discovery module that you choose to use (which, currently, is just JGroups). If you have a client behind a firewall, then its more tricky to configure JGroups, so you might as well use the TransportClient for simplicity. Another point about JGroups is the fact that the client (even though it is not a data node) might become the master of the cluster, which you might not want. -shay.banon On Sat, Feb 20, 2010 at 9:27 AM, Lukas Vlcek [lukas.vlcek@gmail.com](mailto:lukas.vlcek@gmail.com) wrote: > I found there are three implementations of o.es.c.Client interface. I > would like to understand what is the difference. Please take a look at > the below findings and let me know if there is any miss-understanding, > So far I've learned that: > > ServerClient - this is tied to a particular server instance and there > is always only one client for one server. I guess it should never be > instantiated (though it has public constructor) but it is the server > which is responsible to create and close this instance. > > TransportClient - it can connect to one or more servers using port > number. JavaDoc says it is not part of the cloud, which I think means > that the purpose of this class is to connect to server(s) via net > whereas the ServerClient talks to server directly (kind of embedded > mode). > > InternalTransportClient - used internally by TransportClient only. So > there is no practical use case for this implementation (other then it > is used by ES API internally, thus it could be removed in the future > and developer should never code against this object). > > So when talking to cloud via net I will always be dealing with > TransportClinet as it can talk to many servers, contrary ServerClinet > can talk to one server only and moreover the ServerClient lives within > server scope. Does it also mean that TransportClient forwards requests > to particular ServerClients when talking to servers? > > Regards, > Lukas ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:25am UTC](https://discuss.elastic.co/t/java-clients/2823/3 "2017-07-06T04:25:38Z")