Concepts and Architecture
Concepts and Architecture
The BigMemory C++ Client and Cross-Language Connector enable interoperability between your C++ application and other platforms by providing access to BigMemory in-memory data.
BigMemory Cross-Language Clients supply access to data from multiple platforms. Supported platforms can interoperate using the same data. For example, a Java application can read data added by a C++ or .NET client, and vice versa. The BigMemory Clients also allow searching of the BigMemory data. There is no additional piece of infrastructure required.
A Java Virtual Machine (JVM) is set up on the same hardware that hosts the other platform's code. This JVM will host the Cross-Language Connector and the BigMemory instance. The Cross-Language Connector runs as a JVM process that talks to the BigMemory instance and opens the communication channel between other processes and BigMemory. The Cross-Language Connector runs as any other Terracotta client (L1) from the cluster perspective, but it allows other processes to connect to it using a well-defined protocol and API.
The BigMemory C++ Client connects and accesses data stored in BigMemory. The BigMemory Client is a library which is installed on the target platform in the appropriate path. Within the target application, the API is used to talk to the JVM.
Figure 1 below illustrates a topology where multiple clients share one Cross-Language Connector. The BigMemory Client is added to the application, and then the Cross-Language Connector provides access to the BigMemory in-memory data.
Figure 1. Cross-Language Topology, Example 1
Figure 2 below illustrates a topology with multiple Cross-Language Connectors. Hosting the CL Connector on the same machine as your application may have the advantage of keeping your data closer and reducing latency. Each CL Connector requires its own CacheManager, so this topology may be a good approach for keeping discrete data sets available to different applications.
Figure 2. Cross-Language Topology, Example 2
Factors to consider when designing your topology include: your data access patterns, how data is shared among your applications, the amount of memory you have, and the amount of data that you want keep in memory.
Figure 3 below illustrates the flow of data through the Cross-Language Connector.
Figure 3. BigMemory Cross-Language Clients' Data Flow
1. Data from a C++ or .NET client application can be stored in BigMemory using the BigMemory Client. A put from a BigMemory Client is converted into platform-neutral format (PNF). It is then transported to the Cross-Language Connector and put into BigMemory, either directly or after serialization, depending upon the use case.
2. Data can be retrieved from BigMemory by the same client or by a different client. A get from the client retrieves the serialized object from BigMemory and deserializes it, making the Domain Object available to the client.
3. You may also have a Java client, which can store and access BigMemory data in either of these ways:
a. If the BigMemory data is primarily in platform-neutral format (PNF), use the Ehcache API through a CacheSerializer that lazily serializes/deserializes the data for use with your Java application.
b. If the BigMemory data is primarily in Java format, use the Ehcache API directly from Java. (F) In this case, the Cross-Language Connector for C++ or .NET clients should include a Java CacheSerializer.
Components
Cross-Language Connector - The CL Connector is configured with the cross-lang-config.xml file, and it accesses BigMemory data that is contained in caches that have been defined in the ehcache.xml file. Each CL Connector needs its own CacheManager, so if you want more than one CacheManager, you will need as many CL Connectors.
BigMemory Client for each platform - The BigMemory Client is specific to a platform (for example, C++, .NET, etc.). It will convert data from the platform into platform-neutral format and send it to the CL Connector.
Deployment
BigMemory Cross-Language support is provided as a client-server model. One server potentially connects to a Terracotta Server Array (TSA) but could also be a standalone "caching server." Typically, in order to minimize latency, the server would run on the same hardware as the client(s). You can have one or more clients' processes then connecting to that server.
The two main CL Connector deployments are:
As a standalone server process that runs in its own dedicated JVM. A standalone CL Connector is started and stopped using the batch or shell scripts provided in the kit.
As an embedded server process within the CacheManager used by an existing Ehcache application. An embedded CL Connector is configured by making simple changes to the
ehcache.xml file, and then it is started and stopped via your application.
Platform-neutral Format and Serialization
The platform-neutral format (PNF) is a Thrift-based, opaque, binary format that is used for wire transport between platforms. PNF objects can be trivially stored by BigMemory and the Terracotta Server Array. PNF data has the following characteristics:
Consists of well-defined primitive types (string, integer, float, date, byte[], etc.)
Keys are mapped to some type of primitive
Values are comprised of two parts:
Binary byte array, opaque to Ehcache
Map of String::
<primitive type> used for indexing/search
Data that will be shared across languages needs to be serialized. Cross-Language CacheSerializers are implementations which take a platform domain object and transform it into a platform-neutral format, and also perform the operation in reverse, from PNF back to the original format. In a mixed platform deployment, CacheSerializers need to be written for each platform, in the platform language.
For more information, see
C++ Client Serialization.
