Tuesday, June 14, 2005

Move over LAMP, HILTS is here

While the corporate world is slowly gaining awareness of the LAMP stack and the more clued-on Open Source world is beginning to explore some new alternatives, a far better stack of Open Source technologies has quietly emerged.

I call it HILTS, which stands for Hibernate-Ingres-Linux-Tomcat-Spring. As a platform for running enterprise applications, I believe it represents the best that you can get for love or money.

We won't waste time arguing the strengths of Linux. Linux is the operating system of the future on every hardware platform imaginable, and when the Microsoft dazzle wears off in the near future, the rest of the world will see that too. Linux should absolutely be your OS platform of choice.

Ingres is quite simply the best Open Source database out there, bar none - better than Firebird (Interbase), better than PostgreSQL, better than MaxDB (formerly SAP DB). Notice that I don't consider MySQL worth mentioning as a competitor. Ingres has true enterprise-class features comparable to Oracle or Sybase, and the documentation that comes with it is awesome. It runs on several major OS platforms, unlike MS-SQLServer. If you want my opinion, move all your data to Ingres. That's the future. [Disclosure: I developed applications using commercial versions of Ingres a decade ago, and some bias may result from the long exposure.]

Tomcat is the quiet achiever of the Java server family. It's everywhere. Every development shop runs Tomcat somewhere, and many even run it in production. Virtually every J2EE IDE bundles Tomcat. Heck, JBoss bundles Tomcat. There was a time when I thought of Servlet/JSP engines as the Genie of the Ring when compared to EJB-capable app servers, which were the Genie of the Lamp. No longer. The existence of powerful frameworks like Spring, which I'll come to in a moment, means that enterprise-class applications can run quite comfortably on Tomcat. Tomcat should be your app server platform of choice.

I'll admit I've had mixed feelings about Hibernate. On the one hand, there's no doubt that it's a cool, capable O-R mapping product, excellent at what it does. On the other, it doesn't implement a standard API like JDO, which to my standards-craving mind, is heretical. Hibernate has often made me ponder the philosophical question of whether an Open Source product can ever be considered proprietary. [Update: There is now a persistence standard, the Java Persistence API. Hibernate will implement JPA, just like TopLink and OpenJPA (formerly Kodo). Interchangeability of implementations, however theoretical, satisfies me :-).]

Ideology aside, there is a technical limitation with Hibernate. Perhaps it isn't a true limitation, because it only becomes apparent when you try to use it for purposes beyond what it was designed for. Hibernate is great at implementing the persistence behaviour of POJOs (load/store), but it knows nothing about managing that behaviour. In other words, it can persist objects perfectly, but has no idea when to do it. It needs another component to say when.

That's the beef I have with people who talk about Hibernate by itself as a replacement for Entity Beans. Simpler and cleaner Hibernate may be, but EJBs have the notion of container callbacks driven by transaction boundaries, so they know when to initiate persistence as well as how to do it. Hibernate needs to be explicitly told to do so by a Session Bean, which means that the application developer must now take responsibility for something that an EJB container did as a matter of course. It's a step backwards from EJB to Hibernate.

Ah, but not when the Spring framework holds everything together! Spring is transaction-aware, and Spring can now drive Hibernate the way the EJB container used Session Beans' transaction boundaries to drive the persistence of Entity Beans.

Spring 1.2 now also introduces Message-Driven POJOs, and with the use of Quartz, provides a much nicer timer mechanism.

I believe that with Spring 1.2, the world now has a credible alternative to EJB technology. Spring should therefore be every developer's application framework of choice.

So there you go - the entire server-side stack for your next application! HILTS will do everything you need. "Everything" implies the application of the 90-10 rule, of course. There will still be the 10% for which you may need another solution, but HILTS will comfortably handle the other 90%.

[I was toying with the idea of calling this e-HILTS, just to tell you that you'll probably use Eclipse on the client side as your development tool of choice, but it sounds too dot-comish to be serious.]

HILTS is good. Stick it to .NET, guys! :-)

No comments: