The Coherence Ecosystem

Skip to end of metadata
Go to start of metadata

Breakdown of Coherence editions

The Coherence ecosystem is divided into two subsections: Coherence client editions and Coherence server editions. There are two different client editions:

And there are three different server editions:

  • Standard Edition
  • Enterprise Edition
  • Grid Edition

Each has a different (graduated) list of features which can be found on the Coherence Features by Edition page.

Coherence client and server connections

The figure below illustrates which client editions can connect to which server editions. It illustrates two important points:

  • Coherence Data Client can connect to any of the Coherence Server Editions.
  • Coherence Real Time Client can only connect to Coherence Grid Edition.

Architecture and Coherence modules involved in connecting client and server editions

There are two Coherence modules involved in connecting Coherence client and server editions:

  • Coherence Extend*TCP - which is the protocol (built on TCP/IP) that is used between the Coherence client and server processes.
  • Coherence Extend*TCP Proxy - which is the module that sits within a Coherence server edition process that manages the Coherence Extend*TCP connections coming in from the clients.

First, let's start by showing how a single Coherence client process connects to a single Coherence server

Cross Platform Client Support
Coherence currently ships with native clients for both Java and [.NET (C#)] and native [C++]. This allows different platforms to access, modify, query, (and so on), data between programming languages by connecting to the Coherence Data Grid.

The following figure illustrates how a request is passed from a Coherence client process to internal data storage:

  1. A Coherence client process uses Extend*TCP to initiate and maintain a connection to the Coherence (server-side) Data Grid.
  2. Extend*TCP connects to the Coherence Server JVM process, specifically the Extend*Proxy service that is running within the process space.
  3. The Extend*Proxy service routes the client requests to the internal data storage.

Now let's take a look at how this would look in a more "real world" (that is, scaled-out) environment. The components involved remain the same as in the above environment.

The following figure illustrates how requests are passed from the client processes to internal data storage where there are multiple Coherence server JVM processes:

  1. The Coherence client processes use Extend*TCP to initiate and maintain a connection to the Coherence (server-side) Data Grid.
  2. Extend*TCP connects to a single Coherence server JVM process, specifically the Extend*Proxy service that is running within the process space. In the event of failure the client process will connect to another Coherence server JVM process that is running the Extend*Proxy service.
  3. The Extend*Proxy service then routes the client requests to the correct Coherence server JVM process (that is, the process or processes that hold the data relevant to the client request) represented by the "internal data storage" in the diagram.

Labels:
architecture architecture Delete
clients clients Delete
server server Delete
editions editions Delete
core-concept core-concept Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.