Page History

...

Users of these traditional client-server products (referred to as "server products" here) are shielded from server-side implementation choices such as product implementation language, so long as suitable client libraries are available. This is a key choke-point in such architectures. By narrowing client-server communication through a (assumed small, stable) network protocol—many different client technology stacks can be supported, and much freedom to evolve the server implementation is gained.

...

As a low-latency, consistent in-memory caching product, Geode must (almost by definition) provide at least a "fat client" library. In order to provide low-latency, consistent caching, changes must be propagated synchronously, and data must be made available in-process (in the user application process). Clients cannot, in general, wait for a network round-trip for data reads. This implies that in the client-server mode, Geode must have a sophisticated fat client library. Geode, in fact provides two such fat client libraries: a Java one and a "native client". Each of these fat client libraries provides a language-level or link-level interface for client programs to communicate via IP networking, to a server (cluster). The These fat client libraries provide sophisticated in-process data management.

A decade-and-a-half Two decades ago, the software on which Geode is based, started life as a shared object memory. There Multiple processes running on the same computer shared coordinated access to objects through shared memory. In that era there was no client-server mode at all. There was only peer-to-peer. In that world the software's raison d'être was to provide efficient, low-latency, consistent data replication between processes. All processes were assumed to be Java virtual machines, and in fact, all processes were assumed to run software written entirely in Javashared object access to processes running on a single computer. Eventually a "caching interface" was added to that system. Some time later the (C-based) shared memory logic was eliminated entirely and a new network-based distributed caching infrastructure took its place. Some of the most significant users of the software on which Geode is based, have still run business-critical high-scale applications that rely entirely on this use of the software to support peer-to-peer (cache) data management.

Geode exposes a vast peer-to-peer Java API (e.g. `org.apache.geode.cache.CacheFactory` and friends) that users rely on. While the project has striven to clearly divide the public peer-to-peer API from the internal one (various `..internal..` packages), the existing public API may be too large and too ill-specified to provide the isolation necessary to reasonably consider alternative implementations of that (public, peer-to-peer) interface. This porous peer-to-peer API covers a networking vocabulary of around 360 different peer-to-peer message types.

The Geode client-server Java API (e.g. `org.apache.geode.cache.client.ClientCacheFactory`) is implemented underneath by around 70 network message, or "Op", types. By itself, this client-server interface could possibly serve as an architectural choke-point, were it not for the size, and porosity of the existing peer-to-peer interface.

Decision

Geode is a Java toolkit—not (merely) a server product. While Geode supports a client-server topology, and therefore supports clients written in various programming languages, it also supports a peer-to-peer topology.

This peer-to-peer support is a primary product focus. No effort will be made to end support for this peer-to-peer interface. No effort will be made to abstract a peer-to-peer interface away from the current implementation. Peers are Java programs.

Consequences

Geode exposes a vast peer-to-peer Java API that users rely on. The Geode project benefits from no single, cohesive, well-defined client-server choke-point in the architecture.

...