What Does Our Solution Provide?

This solution provides high scalability, because as the load increases, the number of
Cluster Workers can be increased; also, these Cluster Workers can be distributed across
different machines. There can be multiple instances of the JavaSpace Service running on
different machines, forming groups, and the Cluster Servers can decide to write to any of
them, thus keeping the network traffic that is generated manageable.

The Cluster Servers and Workers use the Jini service discovery mechanism to find these JavaSpaces service implementations, so their locations do not need to be hard-coded. Thus, the solution is dynamically configurable. Use of the Jini leasing model allows additional resources to be added without bringing down the whole system. Similarly, existing resources can be taken down gracefully by not renewing the jini licenses and taking them out after the existing licenses expire.

Since the distribution of requests to the different servers in the cluster is by pull rather than by push, there is no question of requests getting directed to servers that have gone down, thus providing request-level fail-over.

In this solution, the session information is placed in the JavaSpaces and retrieved later using the Session ID provided by the HTTP client when needed. Thus, it provides session-level fail-over because even if the server that originally created the session
dies, some other server in the cluster can carry on with the session. Since we're using the Jini leasing model, we can set a time after which the session entries in the JavaSpaces expire to the session timeout interval; this takes care of purging expired session data.

Since the distribution of load is based on pull, there is automatic load balancing, as the servers with more free resources are going to pull more work.

This design shifts the responsibilities of maintaining the session data to the
JavaSpaces, and since there are different implementations of the JavaSpaces services that
can provide persistence and also transactional capabilities, it becomes easier to provide
persistent sessions if needed.

Currently, we are using the space as a bag to hold the requests, but it is possible (with
minor modification) to make it behave as a channel, as described in the article
"Build and use distributed data structures in your JavaSpaces". Similarly, it is possible to implement a filtering service that will filter these requests; it is also possible to implement a service to prioritize these requests thus providing QoS capabilities.

Limitations of Our Solution

There can be more than one Cluster Server, and it makes no difference to how it all works, but HTTP clients typically use a URL to access Web resources, and the clients need to perceive the cluster as a single machine with one IP address (for server affinity), thus requiring a single Cluster Server. Thus, this can be single point of failure, but this
limitation can be overcome by using a hardware load balancer (even then, the load balancer
itself is a single point of failure), in which case this solution can be used as the Web
server proxy (as described in articles on J2EE Clustering by Abraham Kang), or by using other techniques to let more than one machine serve
a single domain name. Another technique is described in the article "ONE-IP: Techniques for Hosting a Service on a Cluster of Machines".

Conclusions

This solution provides high scalability, high availability, and good load balancing
capabilities that are comparable with any other software solution. It needs low
maintenance because of the dynamic self-configuration capabilities, and has good promise
for implementing QoS capabilities.