Gemstone in February was the first to release native C++ and .NET clients, eliminating the need to deploy a JVM within .NET apps or use wrappers when sharing data between C++ and Java. InfoQ spoke to Gemstone in early March about their solution. On their wire format, Gemstone replied:
GemFire uses a binary format for representing object graphs. This is similar to the Java Object serialization protocol where the object state along with class ID information is encoded onto the stream. Class ID (generated or specified by the application) information is the primary means by which different languages interprets the bytes during deserialization. It provides implicit mapping between Java, C++ and .NET objects and enforces a consistent programming model across languages. The serializaiton framework is capable of handling complex object graphs. In addition to supporting the basic types, the serializaiton framework has added native support for byte arrays and XML documents.Gemfire supports Java, C++, and any .NET language natively. In order for them to share objects, they must implement the same object model in any of the languages requiring access to those objects. Gemstone described the approach most of their customers used to achieve this:
1. Create a class in .NET, C++ or Java (the originating language is not important).
2. Create a matching class in the target languages.
3. Register the class on the client (Java, C++ or .NET)
4. Register the class on each server.
The end result is a common serialization structure understood and agreed upon by all constituents. Describing the customer use cases for Java and .NET interop, Gemstone explained:
On Wall Street, we're seeing significant demand for C++ and Java clients deployed within the grid, all requiring access to the enterprise data fabric. Outside of grid, we have numerous clients on Wall Street that are building applications that access the EDF. As the customers are using .NET as their GUI development of choice, a .NET client is a natural fit.GigaSpaces also explained their interop solution in a past InfoQ interview and their intention to support .NET natively in early 2007.