POJO Mojo

Spent the last month of 2005 traveling. I was in London to speak with Rod Johnson--learned a lot. I was in Miami for the Spring Experience. I was in Belgium for Javapolis. I felt it a great honor to hang out with Jonas Bonér and help him get Terracotta's message out there. In Miami we demonstrated our new product, Terracotta for Spring. At Javapolis, we had two 15 minute sessions where we did tech-heavy demonstrations as well.

After spending the last several years running the JRockit JVM business at BEA and the last year working closely with Terracotta's customers and partners, it has become totally clear that there are two big galactic forces in Java today - namely: scale-out and complexity - and these two forces are actually conflicting with each other and reinforcing the difficulties facing Java developers and application operators in the market today. Layered on top of this is the need for the managed runtime (the JVM) to handle more of the operational responsibilities in Java applications today (see my previous post on Developer vs. Runtime Responsibilities). Let me explain myself a bit more clearly:

Several people have commented to me, and have posted links to my latest blog posting effectively twisting my words around to make the point that Spring was not designed for scalability. Nothing could be further from the truth.

Colin's blog posting says it better than I can - and yes, he is right, I "deserve a spanking" and should know better.

We at Terracotta believe strongly that the Spring framework vastly simplifies the task of creating enterprise applications by, among other things, adhering to some basic principles such as application code should not have any unnecessary dependencies on the underlying infrastructure, and that many infrastructure related tasks can and should be taken care of transparently at runtime. The point I was trying to make (somewhat awkwardly) in my post was that scalability (ie. sharing of state and behavior between nodes in a cluster) should follow those same principles. This is not the full definition of scalability, of course - a completely stateless application can scale very nicely without the need to share in-memory state or behavior between nodes. But, in the cases where state and/or behavior needs to be shared or coordinated between nodes, a Spring application can scale very nicely in conjunction with any number of other products, such as WebLogic Server, Tangosol's Coherence, or our product, Terracotta. In my post, I was drawing a contrast between scalability and simplicity, and in this context, the combination of Spring and Terracotta makes the most sense to us - it achieves the desired scalability (sharing of state/context/behavior) without making the application more complex by requiring dependencies on the underlying infrastructure. Terracotta, like Spring, is transparent and API-free - thus the very natural partnership between Spring and Terracotta.

I hope this clarifies our position somewhat - comments welcome!

Ari will be speaking at the East Bay Java SIG tonight on "Injecting enterprise quality of services into applications transparently at runtime." Here is the abstact:

The modern enterprise development community has come to accept that many operational aspects of enterprise systems should not be explicitly handled by developer code. A decade ago, mundane tasks such as garbage collection and thread management were handled manually by developers; the code for these operational services mingled with developers' business logic and became an unending source of bugs. With recent advances in virtual machine technology, however, a general consensus has emerged that such responsibilities are best left to the underlying runtime environment.

We believe that a similar transformation is now underway with other operational services such as distributed caching. VM technologies have matured to the point where they can now take responsibility for state replication in much the same way they have already taken responsibility for memory management.

This presentation will describe how enterprise qualities of service can be provided as natural extensions of the Java Virtual Machine. We will show that by mapping natural Java language semantics into a distributed environment, business logic can be isolated from so-called "infrastructure logic" such as replication and caching.

Join us for a lively discussion!

Most solutions that claim to enable scale out for Java applications are really nothing more than in-memory databases - forcing the OO developer to think in relational terms. What is needed is a pure OO model to enable scale-out.

Seems to me that relational theory is of tremendous value (reasonably established by the multi-billion-dollar-per-year industry based on it). OO-theory is of tremendous value as well. They are somewhat orthogonal and needn't be compared. So why then do Java (an OO environment) clustering vendors ask me to use relational theory when working in an OO environment? Because it is easier for me or is it actually just easier for them?

First I should justify my assertion that clustered hashmaps are in-memory databases. If a product follows these few tenets, it should be considered a database:

1. SELECT / get() as a mechanism for looking up data
2. UPDATE / put() as a mechanism for making changes to that data
3. primary key construct for accessing and cross-referencing unique instances of data.
4. a query language to select and/or update groups of or unique data safely.

Is such a product solving problems for Java developers in the most natural, expedient way? And is such a product destined to become a [in-memory] database? If it walks like a duck and quacks like a duck...then its a duck, right?

I believe the Java development community needs to stand together and assert ourselves as wanting to maintain the object oriented / POJO programming paradigm as much as possible. Bob's recent post on Galactic forces explains our belief in more detail, but suffice it to say Spring, Hibernate (and EJB3), are on to something--a return to the simpler ways of single-JVM Java.
Read on if you are interested in my assessment on the performance [dis]advantages of clustered hashmaps / in-memory databases...