Open Terracotta

Open source and the low cost of hardware capable of advanced features - such as main boards with integrated RAID controllers, multi core processors, faster and larger RAM modules (features that few years ago were offered only on high level systems), are now offering the chance to get impressive fault tolerance and clustering features on non-dedicated systems; lots of applications like web services could gain great benefit from this kind of features, and even new approaches to normal office applications became possible: with the reliability and performance of a high end system, it is possible to implement departmental web implementations of word processors or spreadsheet with a low enough cost to compete with the licensing cost of traditional office suites. Up to now I've been thinking of cluster able software as a clustering engine (an API) used in a custom designed application: something like an application with transactions or similar constructs used to keep consistency through the various nodes of the cluster. Up to now.
Yesterday, Jonas Boner from Terracotta Inc., presented in occasion of the Turin JUG meeting, gen. 2007, Open Terracotta. Please, have a look at it! terracotta.org.
One important thing Jonas was saying is that Open Terracotta is proposing a model of clustering/replication of enterprise Web 2.0 applications based on two layers: the usual database, which is responsible to maintain clustering/replication for the persistence layer - that is the data you usually store in the DB, and Terracotta, which is aimed to maintain consistency through cluster nodes for the Session Data – that is the data about the user logged in.
I think this kind of approach is the most effective, and fits perfectly in a Web 2.0 application. But what about other contests? First of all it's important to focus on the reasons that are leading to a clustering choice: it is a matter of scaling capability, fault tolerance, or both? It's very important to understand that in the case fault tolerance becomes a concern, a “software only” solution could not be sufficient, exposing for example the network layer as a SPOF; in this contest, software becomes part of the system (and not the system itself), so the whole system must be designed as a fault tolerant composition of software AND hardware. Assumed this, I still see in Terracotta a great and easy (for the developer) way to write software focusing on the business domain instead of having to deal with the technical detail of managing replication consistency.

Java was the first language I used with an integrated concurrency model (synchronized keyword, wait() and notify(), the new concurrent package): I thought this was such a leap forward for programmers, but yesterday we discussed the “what if” scenario in which Terracotta's heap consistency clustering approach is plugged inside the open source JVM; this could lead to new great applications! Imagine how easy could be to implement a chat system, or in general any kind of application (client based or web based) using shared informations. But personally I think that Sun doesn't want to plug into the free VM features that it's willing to sell to its customers!