TheServerSide – my old stomping grounds, you know – posted “GigaSpaces XAP 8: Like Playing With a Long Lever and a Strong Fulcrum” this Monday (January 31, 2011.) Cameron pointed out the standard superlatives found in every press release, but he managed to bring up some interesting things while missing some pretty crucial points.
Look: I hate press releases. Every now and then I’ll get asked for my opinion on press releases, and I run out of red ink on them, only to be told “we need all this noise or else it doesn’t look press-releasey.” I try, but it’s true: what I write isn’t a lot like press releases.
XAP 8.0, technical aspects
First, what XAP is: XAP stands for “eXtreme Application Platform.” It’s a cloud platform, data grid, messaging platform, and scalability solution wrapped up in a single package. One could think of it as an analog to a Java EE application server, except it’s not limited to serving Java (it handles .Net and C++ modules as well) and it’s not limited to a primarily request/response model. It’s built for scalability and ease of use, by developers as well as production control.
There are two primary focuses for XAP 8.0: productivity enhancements and operational readiness enhancements.
Productivity enhancements in XAP 8.0 focus on two branches, which we call “Continuous Scaling” and “Same Data, Any API.”
Continuous Scaling refers to our elastic service manager (ESM) and enhancements around it. The ESM allows you to programmatically declare what your deployment topology should look like. How many primary nodes in your cluster? How many backups? What kind of memory should be available? How much CPU should be available? — You get the idea.
You can deploy an application, suggesting that the application should have at least four primary nodes, each with one backup; the cluster should have 10GB of RAM available to it, and no CPU should sustain above 60% usage for an extended period of time. If these constraints are violated, the system is able to spin up (or down) instances in the cluster until the service levels are met.
This means that your application sizes itself appropriately for the load it’s enduring. If you’ve overallocated instances, XAP can spin down nodes to save you money; if you’re handling a lot of load, XAP can spin up extra instances to make sure you’re not introducing delays.
Same Data, Any API refers to our data grid and messaging platform, and how easy it is to put data in and retrieve it. We added two new APIs to the Java product: JPA (the standard ORM for Java EE) and a schemaless API (the Document API).
In addition, we’ve enhanced our query model so you can construct some truly mind-bending queries (referring to nested data across embedded objects, including having this data indexed). It’s almost as flexible as XPath; the main omissions here are axis queries, which most people don’t use anyway. (Axes are more useful in presentation, not location, in my experience.)
Lastly, we’ve focused a lot of effort in making sure that data is available in every API. If you store an entity via JPA, you can query it (and retrieve it) through the Document API, or the native API. Likewise, if you store a Document, you can retrieve it or query for it with JPA.
Same data, any API. Where developers are used to being constrained to one API to access data (or occasionally two, if they mix JDBC and JPA and like to live dangerously), XAP explicitly allows developers to use whatever API is appropriate for whatever use they may have: JDBC, JPA, document, native, JPA.
Most developers won’t care about the operational readiness improvements, but they’re critical for modern deployments.
One aspect of operational readiness has already been mentioned: the elastic service manager. That’s not all, of course, even though if it was the only improvement it’d be important news.
For one thing, we’ve decided to include runtime compatibility across versions now. You can update a client to a new version of our API, without having to upgrade the entire system in one fell swoop – which means you can do rolling updates not only of your application, but of the application platform itself.
In addition, we’ve updated our replication system, to make it faster and optimize it for multi-core systems, by far the most common physical platform on which cloud-based applications are deployed.
We’ve also provided capabilities for geographically disparate clouds. You can now host multiple data centers, and represent them as a single deployment platform across a WAN or the internet, if you so choose.
Lastly (for my purposes here, at least) we’ve improved our split-brain handling, which addresses what happens when a network failure between primary nodes occurs. This is referred to as “split-brain” because both primaries are parts of a single application, yet with a network failure, they’re unable to interoperate. We’ve added features here to enable an application to survive such network failures much more safely and quickly.
So there’s the five-thousand foot overview of what XAP 8.0′s release means. I think it’s some fantastic stuff; the document API, complex object query features, and JPA are the most interesting to me as a Java programmer, but the runtime support for production control should make it far easier for production shops to use XAP confidently and safely.
XAP 8.0′s release is huge for GigaSpaces; our additional features represent a huge leap forward in capabilities and a lot of work for us, as well – work that can pay off in spades for our users.