Class Versioning in Runtime Data Sharing with Distributed Cache

Today many organizations use .NET and Java technologies to develop different high traffic applications. At the same time, these applications not only have a need to share data with each other but also want to support runtime sharing of different version of the same class for backward compatibility and cost reduction.

The most common way mostly used to support runtime sharing of different class versions between .NET and Java application is through XML serialization. But, as you know XML serialization is an extremely slow and resource hungry process. It involves XML validation, parsing, transformations which really hampers your application performance and uses extra resources in term of memory and CPU.

The other approach widely used to support sharing of different class versions between .NET and Java is through database but the problem with this approach is that it is slow and also does not scale very well with the growing transactional load. And, your database quickly becomes a scalability bottleneck because you can linearly scale your application tier by adding more application servers, you cannot do the same at the database tier.

Download NCache free trial - Extremely fast and scalable in-memory distributed cache

Well, this is where a distributed cache like NCache comes in really handy. NCache provides you a binary-level object transformation between different versions not only of same technology but also between .NET and Java. You can map different versions through an XML configuration file and NCache understands how to transform from one version to another.

NCache class version sharing framework implements interoperable binary serialization custom protocol that generates byte stream based on specified mapping in such a format that any new and old versions of the same class can easily de-serialize it regardless of its development language; which can be .NET or Java.

Here is an example of NCache config.ncconf with class version mapping:

<cache-config name="InteropCache" inproc="False" config-id="0" last-modified="" type="local-cache" auto-start="False">
 ...
      <type id="1001" handle="Employee" portable="True">
        <attribute-list>
          <attribute name="Name" type="Java.lang.String" order="1"/>
          <attribute name="SSN" type="Java.lang.String" order="2"/>
          <attribute name="Age" type="int" order="3"/>
          <attribute name="Address" type="Java.lang.String" order="4"/>
          <attribute name="Name" type="System.String" order="5"/>
          <attribute name="Age" type="System.Int32" order="6"/>
          <attribute name="Address" type="System.String" order="7"/>
        </attribute-list>
        <class name="com.samples.objectmodel.v1.Employee:1.0" handle-id="1"
   assembly="com.jar" type="Java">
          <attribute name="Name" type="Java.lang.String" order="5"/>
          <attribute name="SSN" type="Java.lang.String" order="2"/>
        </class>
        <class name="com.samples.objectmodel.v2.Employee:2.0" handle-id="2"
   assembly="com.jar" type="Java">
          <attribute name="Name" type="Java.lang.String" order="5"/>
          <attribute name="Age" type="int" order="6"/>
          <attribute name="Address" type="Java.lang.String" order="7"/>
        </class>
        <class name="Samples.ObjectModel.v2.Employee:2.0.0.0" handle-id="3"
   assembly="ObjectModelv2, Version=2.0.0.0, Culture=neutral,
   PublicKeyToken=null" type="net">
          <attribute name="Name" type="System.String" order="5"/>
          <attribute name="Age" type="System.Int32" order="6"/>
          <attribute name="Address" type="System.String" order="7"/>
        </class>
        <class name="Samples.ObjectModel.v1.Employee:1.0.0.0" handle-id="4"
               assembly="ObjectModelv1, Version=1.0.0.0, Culture=neutral,
               PublicKeyToken=null" type="net">
          <attribute name="Name" type="System.String" order="5"/>
          <attribute name="Age" type="System.Int32" order="6"/>
        </class>
      </type>
    </data-sharing>
    ...
  </cache-config>

So, how does NCache do it? Well, in the ncache.config file that you see above, you’ll notice that the Employee class has a set of attributes defined first. These are version independent attributes and appear in all versions of .NET and Java classes. This is actually a superset of all attributes that appear in different versions. Below that, you specify version-specific attributes and map them to version-independent attributes above.

Now, let’s say that you saved .NET Employee version 1.0.0.0. Now, when another application tries to fetch the same Employee but it wants to see it as Java version 1.0 or 2.0. NCache knows which attributes of .NET version 1.0.0.0 to fill with data and which ones to leave blank and vice versa.

There are many other scenarios that NCache handles seamlessly for you. Please read the online product documentation for more detail on this.

Finally, the best part is that you don’t have to write any serialization and deserialization code or make any code changes to your application in order to use this NCache feature. NCache has implemented a runtime code generation mechanism, which generates the in-memory serialization and deserialization code of your interoperable classes at runtime, and uses the compiled form so it is super-fast.

In summary, using NCache you can now share different class versions between your .NET and Java applications without even modifying your application code.

Download NCache Trial | NCache Details

This entry was posted in Distributed Cache and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


eight − 5 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>