Let’s talk Grids – Datasynapse

At Lab49 we have been called upon to provide know-how on various Grid offerings such as Platform, GridServer, Digipede and so on as well as ‘Datagrid’ systems such as Tangosol Coherence and Gigaspaces. I’ll blog about these and other similar tools. I thought I’d kick off with a brief introduction to the DataSynapse Gridserver API’s, briefly what they do etc. Mainly because there isn’t alot out here about Datasynapse.

GridServer APIs what are they for?

DataSynapse looks like it’s already an evolutionary product, it is written in Java and has a set of API’s that are designed to run either client or server side. Some are designed as replacements for others. It is worth reading the developer guide but following is a list of the API’s which languages can be used to manipulate it

1. Tasklet – available in Java and C++ this is been superseded by the Services API however it is a richer API (though not available to as many client languages) as it includes the Job and Propagator API which is used for message passing (it will look functionally familiar if you come from an MPI or even PVM background).

2. PDriver – stands for Parametric Driver – allows for scripts to be executed on the grid.

3. Services – as mentioned this is a replacement for the Tasklet API. It is available client side – Java, .Net (1.1 only currently), C++ and web services. Server side – Java, .Net (1.1) , C++ and COM.

4. Admin – The grid can be set up to snapshot data to it’s own database at a configurable interval (it comes supplied with HSQLDB – but can be configured to work with just about any DB that has a JDBC driver; example configs. Exist for MySQL, Oracle, DB2, SQLServer), all this data can be accessed through the Admin API this enables information to be obtained for Services, Engines, Brokers and drivers.

5. Cache – designed to facilitate data locality for executing services, some people plug in other distributed caches as the native doesn’t support transactions – more later.

6. Discriminators – Not an API as such but worth a distinct mention, discriminators allow a demographic control i.e. where your service runs, this can be useful if you have a heterogeneous grid where some services need to call out to platform specific services such as a pricing library which is only available as a windows DLL which can be pre-deployed to a windows machine that will act as a grid node, the service will then locate to this (these) node(s) to satisfy calls of this type. This is simply done through setting properties in the service.

I’ll talk more about getting some code going client and server as well as how to code for a grid