The Future is here (and it's spelled Terracotta)

Yesterday I attended Elevate @ Avega (see below for more information) and listened to Jonas Bonér when he presented Terracotta. I knew this product is cool, but not this cool!! I felt blown away when walking home after the seminar.
Why do I feel this way then? Well, I feel that the impact of this product (and similar ones) will be immense on how we develop systems in the Java sphere.
I can foresee 2 big topics that will emerge during the coming year and I will explain these in detail below:

• Stateful Programming
• Data Modeling

Stateful Programming
This has been considered a bad way of building systems. The culprit, according to me, is the infamous stateful EJB introduced by Sun in 1999. Using stateful EJBs in a system was equal to building an application that simply did not scale! Therefore almost all Java developers have shied away from this type of EJB.

"We are now seeing interest in moving towards a more stateful model."
- Rod Johnson, founder of Interface 21 (and creator of the Spring Framework)

There are several reasons for using a stateful model. One is that it's simply a more natural way of programming and thinking about how your program works. Take the example of a shopping cart. It is not interesting to persist the content of the cart into a database before the check out is performed and the transaction is committed. But are forced to resolve to persisting if we are not to keep it in the HTTP session. And then we need to make sure that the HTTP session is replicated between web servers (to get 100% availability).

Now on we can use Terracotta to solve this problem for us. Let Terracotta replicate the state between the servers and we can program a stateful approach without any specific API calls or anything like that. Terracotta handles clustering in an non-intrusive way similar to how Spring handles dependencies.

Speaking of Spring and Terracotta. I feel that these two are a perfect match and I will certainly investigate more within this topic. What "design patterns" should be used to achieve the best performance from Terracotta, i.e. what should be cached? Interesting topic, eh? :-)

Data Modeling
What does data modeling have to do with Terracotta? Have I gone absolutely bezerk? Nope. I'm no doctor, but I don't think I am crazy... You see with the advent of Terracotta we can decide what to put in a database and what to keep out of it. I will try to explain this more below.

Terracotta has its own persistence storage (on disk). It keeps track of the state of data, so if a JVM in a Terracotta "domain" crashes there is no data loss. When the JVM comes back up again it will ask the Terracotta server for the "missing" data and, like some magic, the data is back in your application. The fact that the Terracotta server persists can be used when designing applications. In the "old days" (3 weeks ago) the systems designers simply took for granted that all data in the application had to be persisted in a database. This is not the case anymore. Instead, when designing a new system, a data analysis should be conducted and based on the outcome of this we should decide what data to store where. Some data must reside in a database e.g. for data warehousing purposes, where as other data might as well be kept in the Terracotta persistence storage. It is still retrievable only that you have to use a Java application to retrieve it. (Or at least an application that is compiled into Java byte code - read JRuby :-)).

How cool isn't this?? :-)
At least I'm excited.
What about you?
Download Terracotta and start playing around with it.

L8r