Building GigaSpaces Apps in Minutes with Giga Systems Builder

If you're into MDA, there are some great news for you. One of our partners, New Technology/enterprise (NT/e) has created a very impressive tool to build and deploy end-to-end GigaSpaces applications in minutes. The tool is called GigaSystemsBuilder (GSB).
GSB is an Eclipse plugin which makes it quick and easy for Java developers to model, code and deploy GigaSpaces applications.
Since it's based on well known and battle-proven patterns on top of the GigaSpaces XAP platform, it reduces learning time and on-going development effort, and also increases the likelihood of successful projects.
It covers the entire application life cycle, and enables you to model, code, build, run and even deploy the application on the cloud (using our cloud framework) in a few clicks from within your IDE.
The tool is free for development and deployment, and comes with optional paid support package from NT/e.
A good place to start exploring this tool is this 10-minute screen cast.

Enjoy,
Uri

UI & Manageability Improvements in XAP 7.0

As GigaSpaces XAP 7.0 release is getting closer, it's time to overview some of the important new features and enhancements of this version. In this post I will focus on the manageability aspects of this release. I'll review the general concepts behind the management interfaces, namely the GUI and the new Administration API, and will also touch on these two interfaces.
I will dedicate separate posts to each of them in future to keep things in a digestible size.

One of the main issues with previous releases was that the tooling behind the product provided a lot of information about the GigaSpaces runtime, but the data was not fully organized according the product's domain model, and the tools did not expose all of the capabilities that you would have expected. In this release we have gone a great to deal to make sure the management interfaces are comprehensive, coherent, easy to use and accurately reflect to product's domain model.

The GigaSpaces Domain Model
GigaSpaces is very simple to understand if you look at things hierarchically, starting from the physical infrastructure and ending at the application level.

The physical infrastructure level: At the bottom level, you have the physical infrastructure, which includes the physical (or virtual, if you're running on the cloud) hosts. Information about this level includes CPU, memory and network utilization, and naturally machine level properties such as operating system, processor architecture, etc.

The process/JVM level: The next level is the JVM level, which hosts three main components:

• The GigaSpaces container (GSC) - this is a lightweight container, which hosts deployed application instances (e.g. a data grid instance, a Spring application or a web application instance). It's in fact a meta container, which exposes SLA and manageability capabilities on top of other lightweight containers such as Spring or Jetty.
  
• The GigaSpaces manager (GSM) - this is the actual deployment manager. You deploy your application to the GSM, which takes care of provisioning application instances to the running GSCs and mobilizing the deployed application binaries to these GSCs. It is also responsible for monitoring the state of the deployed applications and using the GSCs to enforce the SLA requirements, e.g. take action if a certain application instance fails
  
• The GigaSpaces agent (GSA) - New in 7.0. Think of it as a daemon or a background service which simply start and stops the other services (GSM, GSC) and receives remote commands from the management interface (GUI or admin API)

Information about this layer includes JVM systems properties, JVM stats (available heap size, number threads, GC stats, etc.) and information specific to the above components, such as the applications managed by a specific GSM or the application instances running on a certain GSC. This layer can also be actively managed, e.g. start, stop and restart components.

The processing unit (application) level: The next level is the processing unit level. A processing unit is, simply put, the deployment and packaging unit. A certain application can be composed of one or more processing units. A processing unit can take multiple forms, but in general we distinguish between 3 types of processing units:

• Data only, which only contains a data grid
  
• Business logic only, which contains application code which may or may not access a data grid, but does not host the actual data grid instance
  
• Data and business logic, which contains both the data grid and business logic, which in most cases interacts with the embedded data grid in memory to achieve the lowest possible latency the highest level of scalability

Once deployed, the processing unit has one or more instances, e.g. a data only processing unit with 5 space partitions would have 5 instances. If we define a backup to each of the partitions then it would have 10 instances. Typically, the processing unit is configured via Spring, with custom GigaSpaces namespace bindings to reflect the SLA associated with it and the GigaSpaces components it may contain. Furthermore, in version 6.6, we have also implemented processing units which are plain JEE web applications, Mule applications or even .Net applications. This can be thought of as a mere extension to the basic processing unit model (after all, all of the above also run business logic and may or may not contain a space).
Information about this layer includes the processing unit's name, type, number of instances, its contents, e.g. space instances, web application instances, exposed remote service and so on.
It also includes runtime statistics like the throughput of space operations, web requests per second if it's a JEE web app, and many more runtime characteristics.
Operations that can be taken on this layer include deployment, undeployment, relocation from one GSC to another, restart of a certain instance, increment/decrement the number of instances, etc.

The following diagram depicts the above (click to enlarge):

The management interfaces
Let's start with the admin API. This is a completely new API, which gives you full control over the entire lifecycle of the GigaSpaces runtime components.

Using this API, you can start and stop any GigaSpaces component (literally, at the JVM process level!) or even your own custom components, deploy and undeploy your processing units, and monitor almost any aspect you can think of using either polling or event based notifications.

Monitorable entities are all the ones mentioned above, namely the physical hosts (CPU, memory, network utilization), JVMs (number of threads, available heap memory, object count, etc.), deployed processing units (transactions committed, space data, JEE requests stats) or even the underlying network layer.

The main benefit of this API, besides it's cleanliness and completeness, is that opens a variety of options to extend the core product functionality, e.g. implement sophisticated cluster-side bootstrapping, easily integrate with any 3rd party monitoring tools, implement automatic scaling for your web application (as shown in my latest webinar) and much more. But that's something I'll cover in detail in a separate post.

As for the GUI, it also caters for all of the above, but allows to view everything graphically (and as they say, a picture is worth a thousand words). We used the excellent Balsamiq Mockup tool to quickly create sketches of the way we want to see things, and from there the job went fairly smoothly. The user interface is now divided into 3 main tabs:

• Hosts: which gives a physical view of things, but also shows the entire component hierarchy described above
• Applications: which focuses on the logical side of things, namely deployed processing unit and the components they contain
• Space browser: a pure data-grid only view to enable you to focus on data grid aspects
  

Naturally, besides viewing things you are also able to operate on the cluster and do all the above mentioned operations using the UI (.e.g. restart a certain JVM, relocate a running processing unit instance from on host to another, or even increase the number of processing unit instances).
The following image shows how we went from mockup to real implementation (in this case showing the "Hosts" view):



I encourage you to give it a try and let us know what you think. Naturally this milestone 8 and not the final release so there are a few more tweaks and improvements we will add, but this can give you the general sense of things.

Cheers,
Uri