Chapter 33. Data Interoperability

33.1. Protocol Interoperability

Red Hat JBoss Data Grid protocol interoperability allows data in the form of raw bytes to be read/write accessed by different protocols, such as REST, Memcached, and Hot Rod, that are written in various programming languages, such as C++ or Java.
By default, each protocol stores data in the most efficient format for that protocol, ensuring transformations are not required when retrieving entries. When this data is required to be accessed from multiple protocols, compatibility mode must be enabled on caches that are being shared.
Enabling Compatibility Mode

For instructions on how to enable compatibility mode refer to the Administration and Configuration Guide.

Report a bug

33.1.1. Use Cases and Requirements

The following table outlines typical use cases for data interoperability in Red Hat JBoss Data Grid.

Table 33.1. Compatibility Mode Use Cases

Use Case Client A (Reader or Writer) Client B (Write/Read Counterpart of Client A)
1 Memcached Hot Rod Java
2 REST Hot Rod Java
3 Memcached REST
4 Hot Rod Java Hot Rod C++
5 Hot Rod Java Hot Rod C#
6 Memcached Hot Rod C++
In the provided use cases, marshalling is entirely up to the user. JBoss Data Grid stores a byte[], while the user marshalls or unmarshalls this into meaningful data.
For example, in Use Case 1, interoperability is between a Memcached client (A), and a Hot Rod Java client (B). If Client A wishes to serialize an application-specific Object, such as a Person instance, it would use a String as a key.
The following steps apply to all use cases:

Client A Side

  1. A uses a third-party marshaller, such as Protobuf or Avro, to serialize the Person value into a byte[]. A UTF-8 encoded string must be used as the key (according to Memcached protocol requirements).
  2. A writes a key-value pair to the server (key as UTF-8 string, the value as byte arrays).

Client B Side

  1. B must read a Person for a specific key (String).
  2. B serializes the same UTF-8 key into the corresponding byte[].
  3. B invokes get(byte[])
  4. B obtains a byte[] representing the serialized object.
  5. B uses the same marshaller as A to unmarshall the byte[] into the corresponding Person object.

Note

  • In Use Case 4, the Protostream Marshaller, which is included with the Hot Rod Java client, is recommended. For the Hot Rod C++ client, the Protobuf Marshaller from Google (https://developers.google.com/protocol-buffers/docs/overview) is recommended.
  • In Use Case 5, the default Hot Rod marshaller can be used.
Report a bug

33.1.2. Protocol Interoperability Over REST

When data is stored via the REST interface the values are interpreted by Hot Rod or Memcached clients as a sequence of bytes. Meaning is given to this byte-sequence using the MIME type specified via the "Content-Type" HTTP header, but the content type information is only available to REST clients. No specific interoperability configuration is required for this to occur.
When retrieving data via REST, primitive types stored are read in their primitive format. If a UTF-8 String has been stored via Hot Rod or Memcached, it will be retrieved as String from REST. If custom objects have been serialized and stored via the remote cache, these can be retrieved as application/x-java-serialized-object, application/xml, or application/json. Any other byte arrays are treated as application/octet-stream.
Report a bug