Chapter 8. From the Outside Looking In

In addition to the standard native client access to the cluster, Hazelcast also provides a few generic interfaces itself so that our application be powered by a technology stack that isn't necessarily Java-based, and we can still take advantage of some its capabilities:

• Memcache compatible access to the default map

• RESTful access to map and queue collections

What about the rest of us?

One limitation of Hazelcast is that due to being a Java-based technology it is mostly focused on supporting applications build around that stack. While we do have a degree of flexibility, in that, other JVM byte-code based languages (such as Groovy or Scala) can utilize the standard Java client driver, but that still does leave a rather large hole for other technology choices. Luckily and very thoughtfully, the cluster nodes do offer limited access to some of our data storage collections in a more compatible way using two popular standards.

Memcache

If we were building a script-based application (say in Python or PHP), and required a data caching service, probably one of the first systems we would consider would be memcache. Both incredibly fast and remarkably simple, but it is this simplicity that does come with some drawbacks. Currently to provide resilience or replication, we have to either handle it on the client side or overlay another system on top of the default memcache to provide transparent scaling or data sharing. But either way, we are exposing some consistency risks, especially in the case of node failure or fallover.

However, one of its greatest strengths is the extent of its client libraries, with no fewer than 10 different technology stacks catered for. Drawing upon these benefits

Hazelcast has sought to provide a compatible alternative, in exposing a memcache API service from each of the Hazelcast cluster nodes. As each of the nodes exposes access to the whole cluster, we can talk to any node about any key held...

Going RESTful

An alternative to memcache would be the even more generic RESTful API. Without wanting to go into too much detail, REST is a popular convention of providing HTTP access to data via resources; these are set up to provide path-like access to collections, objects, and properties. Hazelcast additionally provides a simple HTTP service built-in to each of the nodes to enable access to our standard map and queue collections via HTTP.

The structure of the API is pretty simple:

http://127.0.0.1:5701/hazelcast/rest/maps/mapName/key

http://127.0.0.1:5701/hazelcast/rest/queues/queueName

Where mapName or queueName is as configured within our application, we can then use the standard REST convention of using the HTTP method to describe the type of operation we wish to perform.

In the case of maps, we send in all cases the appropriate key as required; but using a POST method to create or update an entry, specifying an appropriate MIME type as needed.

$ curl -v -X POST -H "Content-Type: text...

Summary

We have seen that Hazelcast isn't a closed technology, while it draws from its own Java-centric background, and is best placed to support applications based on that stack; it does allow more generic access to the cluster's data. Inspired by other standards and conventions already present in the wider community, Hazelcast has avoided completely reinventing the wheel and has found an ideal mix to complement its own offering but also allow existing applications to migrate across easily.

In the next chapter we shall look at taking our application into the cloud and the differences when deploying on a public cloud infrastructure.