I Am Legend - XAP 6.5 POCO C++ SBA Framework

Posted 23 January 2008 @ 10:07 am by Shay Hassidim

I'm not the Legend… the XAP 6.5 POCO C++ SBA Framework is the Legend :-)

I was watching few days ago this amazing "I Am Legend" Movie - http://www.imdb.com/title/tt0480249/ on my Large Sony BRAVIA at my place in the freezing shiny Manhattan. See a nice trailer here: http://www.imdb.com/title/tt0480249/trailers-me60407838

When watching Will Smith, alone by himself, on the Manhattan South Street Seaport, asking people to join him, I felt pretty much the same regarding the news about our CPP and .Net SBA framework coming with XAP 6.5. No one really knows what is going under the hood with this amazing framework.

It is about time to share with you our new POCO C++ SBA framework. Aside from the superstar team created this fine framework, no one have the details about this framework. I hope that after reading this post, you will share my enthusiasm and try it yourselves.

So… let me give you some overview. This post will focus mainly on the new POCO C++ API. In my upcoming posts I will cover also .Net aspects of the new .Net SBA framework (and there are plenty of these for you the .Net guys) as well as provide more details about the items listed below

First, As Always - Some History…

The new C++ POCO API is the 3rd generation of the GigaSpaces C++ API. The first version of this API introduced a while back (around 3 years ago) and used by C++ engineers that had to learn some of our internal proprietary API (The ExternalEntry) to interact with the space. This API was based on the excellent libraries from CodeMesh (http://www.codemesh.com). The main problem with this approach is that it was non intuitive and Java centric. The C++ engineers had to use Java semantics when writing their C++ applications. More than that - there was no ability to easily and dynamically scale the C++ business logic or deploy it across the GigaSpaces Grid containers.

In essence, GigaSpaces .Net API had the same history with similar issues.

The new C++ API has been designed to address the following:

So what is this POCO?

The POCO is a wordplay on the famous POJO acronym and it stands for Plain Old C++ Object.
It is essentially a C++ class that includes attributes and business logic , where its instances (their data) can be manipulated by the space. With such C++ objects, data can be stored within the space, updated, removed or trigger notifications. Same as Java POJO's and .Net PONOs. There is no need to re-write your domain classes or to build marshaling/de-marshaling code (remember this with our old C++ API…) in order their data will be space data.

In general, you simply introduce your C++ class to the space via standard XML (that can be created manually or automatically in some cases) and call the relevant API explicitly or have your business logic to be called implicitly (… what this means , we will see later… ).

Space Meta Class Data

On top of the C++ class itself which include the attribute names their types additional meta information is required for the Space Class. This information can include the indexed fields , FIFO mode, versioned mode, replicatable mode etc.

In order to introduce this additional Meta data to the space, the C++ engineer should provides a simple XML based config file  (the gs.xml). This file is parsed at pre-compile time (not in runtime as the PONO and POJO) and allows a code generator facility to create a piece of code that serves as the "glue" between the C++ runtime and the space runtime (aka the marshaling code).

The code generator includes many cool options - we will cover these in future posts.

Here is a simple example of the gs.xml content:

 <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE gigaspaces-mapping SYSTEM "../../../config/cpp.dtd">
<gigaspaces-mapping>
  <class name="Message" persist="false" replicate="false" fifo="false" >
    <property name="id" type="int" null-value="-999" index="true"/>
    <routing  name="id"/>
    <property name="uid" type="string" null-value="" index="false"/>
    <id name="uid" auto-generate="true" />
    <property name="content" type="string" null-value="" index="false"/>
  </class>
</gigaspaces-mapping>

Hibernate users - does this looks familiar?

.Net PONO and Java POJO users - does this looks familiar?

Yep - you got it: You have the same meta data decoration file across all languages. The same gs.xml can be used to introduce your language independent class to the Space.

Here is the C++ h file that will be generated or should be used with the above gs.xml:

class Message: public IEntry

{
public:
    Message() {
        content = "";
        id = -999;
        uid = "";
    }
                std::string    content;
                int               id;
                std::string    uid;
                virtual const char* GetSpaceClassName() const
                {
                   return "Message";
                  }
};
typedef boost::shared_ptr<Message>    Message_ptr;

Here is the C++ code using the above class:

SpaceProxyPtr space ( finder.find("jini://*/*/mySpace") );

Message_ptr msg( new Message() );
msg->id = 1;
msg->content = "Hello World";
space->write(msg, NULL_TX, 5000000);
Message messageTemplate;
Message_ptr result (space->take(&messageTemplate, NULL_TX, 0 ));

That's it! This is really the explicit API. In future we will introduce the implicit event driven based API…

The SpaceProxyPtr includes all the familiar Space operation such as write , read , take , update for single and batch operations , SQL Query , Event Notifications, Transactions etc.

As you can see the example above using the boost::shared_ptr. If you are not familiar with "boost", see: http://www.boost.org/

Can I use existing C++ classes with the Space?

Yes. You will need to perform minor changes to your existing C++ classes (such as inhering from the IEntry base class) , but you will be able also to implement your own serialization and data transport protocol to gain total control on the byte stream content sent through the wire when the client interacts with the space process. More about this in future posts.

Interoperability - or how I can share data across Java . .Net and C++ applications?

The most complex part with the interoperability magic is the ability to digest every Class structure with every development language to have one common denominator to will be understood by the space runtime. There are several ways to achieve this, e.g. using XML to store the data and convert it to native language objects. We found this option irrelevant for the real time SBA application our users are building. They need fast data conversion and transportation service that will be able to handle objects from all supported languages on all platforms and to do that in optimized and efficient manner - i.e. micro sec latency. This was the target.  Well, I'm happy to say that such a technology exists. It is called Portable Binary Serialization (PBS).

This highly sophisticated PBS mechanism, can, in very efficient manner, scan , compact and serialize complex objects from different languages and bring them into a format that is known to all supported runtimes: .Net , C++ and Java.

With the PBS approach a POCO Class that is a graph object, i.e. holds references to other objects or arrays of objects - can be stored in the space in a way that a Java application using a matching POJO could read the data and materialize the data into a pure Java object. Same with .Net.

Dynamic Scalability - Not only for Spaces!

The main problem with Grid based application and such heterogynous complex environments is the inability to forecast how many machines needed to store the data or run the business logic. Without a smart container for the data and business logic that can handle the application objects (and not only network processes) there is very little to do in terms of the ability to scale your application efficiently. You need a nervous system with sensors to instruct data and business logic instances to be started , shutdown or move to another machine to scale dynamically. In a sense - you have 2 dimensions to scale: In-Proc and Out-of-Proc. In-Proc means multiple threads of your business logic running within the same process. Out-of-Proc means start new instances of your business logic across multiple Grid nodes (on the same machine or different machines). In both cases you need the ability to increase/decrease the amount of business logic instances in runtime based on some SLA of dynamic external business logic.

The space introduced this ability for Java based business logic long time ago (scaling your application by adding more containers on the fly to increase the space cluster capacity). The Java based in/out of Proc scalability was supported via the Jini Service Beans and expanded also to Spring Beans. This is one of the main capabilities of the OpenSpaces framework (that is not only for Java users! - more to come in future posts…). The new POCO framework allows you to do the same with C++ business logic. More on this item will be delivered in a different post. Stay tuned!

Deployment - Stand Alone and Grid Based

The deployment of POCO SBA application involves the standard C++ runtime libraries, the gs.xml files, and the GigaSpaces runtime libraries (C++ , Java and JDK libraries).

These can be packaged using a simple installer to simplify the deployment routine. You may place the runtime libraries on a shared folder to eliminate the need to distribute the files to every machine running an application that access the space.

The other option would be to encapsulate the business logic as Processing-Unit to be managed, deployed and executed across the Grid nodes by the SLA driven container. This will allow you to control the different C++ business logic instances to access remote spaces or collocated spaces (i.e. C++ business logic running within the same memory address as the space to avoid remote calls). Same as Java applications. Similar capability already available as OpenSpaces project for .Net applications. See http://www.openspaces.org/display/DNPU/Dot+Net+Processing+Unit

Configuration

Beyond the gs.xml file creation and the serializer library compilation (you need to compile the generated code - can be as custom build event as part of your visual studio project) there is very little to do in order to run your C++ application and start working with the space.

You can run the C++ application in remote mode - i,e, access a clustered space running across the Grid or start the space instance within your C++ process. Same as .Net and Java application can do.

Performance

This is really the sweet spot of the POCO library…. It is Blazing FAST!

The remote operations and especially the batch operations have been tuned to interact with the space in a very efficient manner. We assume many of the C++ applications will use the POCO API to push data into the space to be processed by collocated Java and C++ business logic. These could be Wombat or Tibco based C++ feeders, that will get rapid market data changes and push these into the space via the POCO API.

Although the performance of C++ business logic accessing an embedded space (running within its process memory address) is still slower than its Java twin, it will provide sub millisecond latency response.

Compatibility

The POCO API is compatible with all other GigaSpaces components and tools.

Packaging

The POCO package includes the following components:

Libraries

The POCO API using the great ACE and BOOST platform independent libraries:

These provides you the C++ engineer out of the box powerful Smart pointers , threading , singletons , collections and many more capabilities provided for all platforms.

POCO Internal Architecture

The POCO libraries are constructed in several layers.

More on this sophisticated and elegant architecture would be provided in future posts.

Summary

We hope the above glimpse into the new POCO API was useful.

As Will Smith says in the "I Am Legend" movie: You are not alone.  We are here to help you with any question you have.

You can now easily scale your C++ application in simple manner, same as the Java engineers using the Java based SBA framework.

Give it a spin - Download GigaSpaces XAP 6.5 early access release today!

http://www.gigaspaces.com/wiki/display/OLH/Welcome+to+GigaSpaces

http://www.gigaspaces.com/wiki/display/RN/GigaSpaces+6.5+Early+Access

http://www.gigaspaces.com/wiki/display/OLH/Writing+Your+First+CPP+Application

Shay

Posted in .Net, C++, GigaSpaces, space-based architecture | Trackback | del.icio.us | Digg it | Top Of Page
Read more...

2 Responses to “I Am Legend - XAP 6.5 POCO C++ SBA Framework”

  1. Bahata Mukhopadhyay Says:
    February 6th, 2008 at 4:37 am

    I find the documents provided in Gigaspace too short / cryptic for the new users like me to solve their problems. I am desperate to get replies to my quetions . Can I have a chat with somebody from Giga to help me out?

  2. Shay Hassidim Says:
    February 6th, 2008 at 9:35 pm

    The GigaSpaces doc includes more than 2000 pages. So we can’t call these short…
    The award winning tutorial includes step by step instructions how to build GigaSpaces based applications.
    See:
    http://www.gigaspaces.com/wiki/display/GS6/Welcome+to+GigaSpaces+Quick+Start+Guide

    The new POCO API docs are enhanced these days – see latest docs:
    http://www.gigaspaces.com/wiki/display/OLH/POCO+Benchmark+Framework
    http://www.gigaspaces.com/wiki/display/OLH/Openspaces+CPP+Processing+Unit
    http://www.gigaspaces.com/wiki/display/OLH/Writing+Your+First+CPP+Application

    You can always call us and schedule a conf call. Simply send email to info@gigaspaces.com

    Shay

Leave a Reply