Concepts and Architecture
The BigMemory .NET Client and Cross-Language Connector give you interoperability between your C# application and other platforms by providing access to BigMemory in-memory data. The client and connector may also be used in a single-language environment for fast, reliable access to BigMemory in-memory data.
Interoperable Access to In-Memory Data
BigMemory Cross-Language Clients provide 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# client, and vice versa. The BigMemory Clients also allow searching of the BigMemory data. There is no additional piece of infrastructure required.
A Java VM is set up on the same hardware that hosts the other platform's code. This VM 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 (.Net or 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 VM.
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 C++ 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:
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.
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 .NET or C++ clients should include a Java CacheSerializer.
Single-Language Environments
The BigMemory Cross-Language Clients can also be used for fast and reliable access to in-memory data that has been stored in BigMemory in the native format of your application. This type of installation can be used in homogenous .NET or C++ environments, where interoperability with data in other formats is not required.
Figure 4 below illustrates the flow of data through the Cross-Language Connector in a single-language environment.
Figure 4. Single-Language Data Flow
1. Data from a .NET client application can be stored in BigMemory using the BigMemory Client. A put from a BigMemory Client is serialized and then transported to the Cross-Language Connector and put into BigMemory.
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.
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, and if you want more than one CacheManager, you will need as many CL Connectors.
BigMemory Client for each platform (.NET or C++) - The BigMemory Client is specific to a platform (for example, C++, C#, 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 Java Virtual Machine. 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.
The choice of which serializer to use depends upon your environment. Some planning and consideration needs to go into the choice of a serializer, as there are pros and cons related to each. For more information, refer to
Cross-Language Serialization.
In single-language environments, PNF is not necessary, and native serialization is used to interact with the CL Connector. For data that will be stored in its native format, you can get started without writing any serialization code by using the provided native serializer class. For more information, refer to
Single-Language Serialization.
