Home
This project contains the APIs required to interact with the Terracotta server.
It is the root of the dependency graph between Terracotta-OSS projects, in that it only has dependencies external to any of these projects.
2 implementations of this API exist:
The API is broken down into 4 fundamental components:
-
Connection API
-
The way that clients connect to the implementation, given a URI, and then interact with this connection
-
-
Entity API
-
The way that server-side application code interacts with the implementation, as a framework
-
-
Service API
-
The way that additional pieces of functionality can be plugged-in to an implementation, extending its capabilities, for the use of entities which make up application logic
-
-
Standard Cluster Services
-
A set of service interfaces either exposed by the implementation or will be used by the implementation if provided by external code
-
The below diagram shows where various high-level components exist within the server, what they rest upon, and how they are provided (blue is provided by the implementation - core or passthrough, red is provided by the user to implement their application, and purple is where the official API boundaries exist).
This shows that entities exist on top of everything else and configuration exists at the bottom but that services interact in various different ways. Some are provided by the user, providing their config and also core logic and interfaces. Others are the standard cluster services provided by the implementation (such as ClientCommunicator). The third class of services is the standard cluster services which are expected by the implementation, and may be optionally provided by the user in order to enable some specific functionality/feature (such as IPlatformPersistence).
Conversely, the client is a far simpler design, where the user code dominates the picture. Here, only the connection layer is provided by the implementation, and the connection API exists directly between these components.
The page describing the Philosophy of the Design further describes how the API attempts to address these needs.