BT

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

by Floyd Marinescu on Mar 25, 2007 |
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. 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT