[[using_client_server]]
= Using the Client-Server Mode

There are situations when accessing {brandname} in a client-server mode that might make more sense than embedding it within your application. For example, this may apply when trying to access {brandname} from a non-JVM environment.

Since {brandname} is written in Java, if someone had a C\+\+ application that wanted to access it, it could not do it in using the p2p way.
On the other hand, the client-server would be perfectly suited here assuming that a language neutral protocol was used and the corresponding client and server implementations were available.

image::server_modules_2.png[align="center", title="Non-JVM access"]

In other situations, {brandname} users want to have an elastic application tier where you start/stop business processing servers very regularly. Now, if users deployed {brandname} configured with distribution or state transfer, startup time could be greatly influenced by the shuffling around of data that happens in these situations. So in the following diagram, assuming {brandname} was deployed in p2p mode, the app in the second server could not access {brandname} until state transfer had completed.

image::server_modules_3.png[align="center", title="Elasticity issue with P2P"]

This effectively means that bringing up new application-tier servers is impacted by things like state transfer because applications cannot access {brandname} until these processes have finished. If the state being shifted around is large, this could take some time. This is undesirable in an elastic environment where you want quick application-tier server turnaround and predictable startup times. Problems like this can be solved by accessing {brandname} in a client-server mode because starting a new application-tier server is just a matter of starting a lightweight client that can connect to the backing data grid server. No need for rehashing or state transfer to occur and as a result server startup times can be more predictable which is very important for modern cloud-based deployments where elasticity in your application tier is important.

image::AchievingElasticity.png[align="center", title="Achieving elasticity"]

It is common to find multiple applications needing access to data storage. Theoretically, you could deploy an {brandname} instance per each of those applications, but this could be wasteful and difficult to maintain. Consider databases; you do not deploy a database alongside each of your applications. Alternatively, you could deploy {brandname} in client-server mode keeping a pool of {brandname} data grid nodes acting as a shared storage tier for your applications.

image::server_modules_4.png[align="center", title="Shared data storage"]

Deploying {brandname} in this way also allows you to manage each tier independently. For example, you can upgrade r application or app server without bringing down your {brandname} data grid nodes.
