Gemstone, Tangosol Offering Native .NET Clients to Distributed Data Caches

Posted by Floyd Marinescu on Mar 25, 2007 11:54 PM

Community

.NET

Topics

Java plus .NET Integration,

Grid Computing,

Clustering & Caching

Tags

GemFire,

Coherence

Gemstone last month released an interoperability update to their Gemfire distributed data cache/grid offering with native C++ and .NET cache clients.  Tangosol last week also released Coherence for .NET, which provides a native C# client implementation to access data in Coherences' data grid.  Both companies as well as GigaSpaces have Java-based distributed cache solutions and in 2006 announced .NET support via implementing their own object serialization formats + .NET wrapper clients over their Java cache-clients.  The most frequent use case for these tools are .NET client front-ends with Java backends (typical in the finance industry),  where .NET code can share  objects in a cache with a Java-based infrastructure.

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. 

• Older >