Summary: The possibility for organizations whose projects include a combination of Java, .NET and C++ platforms to communicate and access each other easily and efficiently while also maintaining the benefits of the GigaSpaces scale-out application server.
Overview
GigaSpaces introduces interoperability – the possibility for organizations whose projects include a combination of Java, .NET and C++ platforms to communicate and access each other easily and efficiently, while also maintaining the benefits of the GigaSpaces scale-out application server:
Transparency: using your native API in the space transparently with minimum changes to existing assets. Objects are stored in the space in the same manner regardless of the platform they are written from. For example, an object can be written to the space from a Java feeder, processed using a C++ Processing Unit, and a .NET client can receive the notification.
Performance: communication between platforms is performed through the space directly, without the need for adapters or XML translation.
SOA: all applications communicate using the space, allowing each of them to exist as as a loosely-coupled service.
To work with GigaSpaces interoperability, classes from the different platforms should meet the following criteria:
The classes should have the same fully qualified name (i.e. including package/namespace).
The classes should have the same hierarchy (i.e. same base/superclass structure).
The classes should have the same properties with the same names and matching types.
There are two methodologies for developing interoperable solutions:
Writing the class code in each relevant platform by yourself (See the Writing Interoperable Class tab below)
Writing an XML file that describes the Entry, and use the code generation tool in the C++ component to generate classes for all platforms (see the Code Generator tab below)
There are pros and cons for each alternative. Here are some points to help you decide which methodology is best for you:
If you need a C++ version of the class, you have to write the gs.xml file to generate the C++ code.
If you're getting started with interoperability, you can use the code generator as a learning tool to review interoperable classes in all platforms.
The code generation tool does not support some of the advanced features in .NET. If you have a need for these features, it is recommended to use the generator to get started, and manually edit the generated code. In this case you need to be careful when changing the class, since regenerating the code might override your manual changes.
Writing Interoperable Classes
Summary: This page is focused on designing interoperable classes manually, and some related advanced features.
The .NET-Java example demonstrates many .NET-Java interoperability features. For more details, see GigaSpaces Starter Examples; .NET; DotNetJava ***
Designing Interoperable Classes
C#
Java
Using GigaSpaces.Core.Metadata;
namespace MyCompany.MyProject.Entities
{
[SpaceClass(AliasName="com.mycompany.myproject.entities.Person")]
public class Person
{
private string _name;
[SpaceProperty(AliasName="name")]
public string Name
{
get { returnthis._name; }
set { this._name = value; }
}
}
}
package com.mycompany.myproject.entities;
public class Person
{
privateString name;
publicString getName()
{
returnthis.name;
}
public void setName(String name)
{
this.name = name;
}
}
Guidelines and Restrictions
The following guidelines and restrictions should be followed in order to enable platform interoperability:
The full class name (including package\namespace) in all platforms should be identical. Since java packages use a different naming convention than .Net namespaces, it is recommended to use the [XAP66:SpaceClass(AliasName="")] feature to map a .Net class to the respective java class.
The properties/fields stored in the space in all platforms should be identical. In Java, only properties are serialized into the space. In .NET, both fields and properties are serialized, so you can mix and match them. Since java properties start with a lowercase letter, whereas .Net properties usually start with an uppercase letter, it is recommended to use the [XAP66:SpaceProperty(AliasName="")] feature to map a property/field name from .Net to java.
Only the types listed in the table below are supported. If one of your fields uses a different type, you can use the class only in a homogeneous environment. Arrays of these types are supported as well. You can also use .NET enumerations, which are treated as their underlying .NET type. Java enums are not supported. If your class contains a field whose type is not in the table, you can use SpaceExclude to exclude it from the space. Some of the types have different charactaristics in .NET and Java (signed\unsigned, nullable\not nullable, precision, etc.) This can lead to runtime exceptions (e.g. trying to store null in a .NET structure) or unexpected results (e.g. copying values between signed and unsigned fields).
Supported Types for Matching and Interoperability
The following types are supported by the space for matching and interoperability:
In .Net a byte is unsigned, whereas in java a byte is signed.
These types can be either nullable or not nullable in .Net, whereas in java they are always nullable.
In .Net a DateTime is measured in ticks (=100 nanoseconds) since 1/1/0001, whereas in java a Date is a measured in milliseconds since 1/1/1970.
The types Decimal (.Net) and BigDecimal (java) have different precision and range (see .Net and java documentation for more details). In addition, be aware that serialization/deserialization of these types is relatively slow, compared to other numeric types. As a rule of thumb these types should not be used, unless the other numeric types presicion/range is not satisfactory.
Arrays and Collections support
The following collections are mapped for interoperability:
In java, the Properties type allows the user to store keys and values which are not strings.
***Link required
Code Generator
The *gs.xml file and the gsxml2cpp utility allow you to use your C++ classes in the space without a need for mapping or special knowledge regarding other APIs. This file is in charge of generating the C++ class serialization code, allowing you to use your C++ classes in the space. It can also be used to generate the C++ class header file and POJO Java file.
To define your classes in the space using the .gs.xml file, perform the following steps:
Write a *gs.xml file, defining its XML elements as desired.
Run the gsxml2cpp command – this command generates the serializer code, which includes the classes defined in your gs.xml file.
Compile the serializer code – this is done using the gsxml2cpp command cpp output parameter. For an example of how to do this, refer to the C++ Hello World Example.
Compiling the serializer code generates a DLL file in the format of: serialize.dll. Copy the DLL file to the <GigaSpaces Root>\lib\serviceGrid\native directory.
You can now use your C++ classes inside the space.
For an explanation of the different gs.xml elements, refer to the CPP API Mapping File section.
To find out about the supported C++ types, refer to the Supported Types section.
For an explanation of the gsxml2cpp command and how to use it, refer to the gsxml2cpp Utility section.