We can discuss frameworks probably till we die but somehow some frameworks reach the status of being a ‘defacto’ standard. And somehow this standard keeps changing more frequently than a formule-one driver can drive its laps on the Monaco circuit. That’s life, take it, leave it or be stubborn. And the last approach has driven me lately into a nice, convenient but not so ‘defacto’ stack of libraries/frameworks to develop webapplications. Warning, what will come is not enterprise, not widely used nor supported but just an experiment that proved me there are alternatives. Do not try this at work, your fellow web engineers might kill you for being obstinate. But here’s the recipy for small quick but nicely designed web-apps:

Let’s start at the bottom. The data. The famous persistence layer. All we normally use are relation databases, tables, maybe views stored in Oracle, MySQL or whatever (HSQL, Derby) RDBMS. Throw it away! The reasoning is simple, we’re living in an OO world with an OO language dealing with Objects not dealing with non OO data and heavily depending on mappings from the old world to the new world. No Hibernate, no Toplink, no Ibatis but just a a plain simple OO database. DB4O is our bottom. And yep, our bottom is going to be hit by more than one religious clan (indeed no need for EJB3, no need for DBA’s and no need for industry marketed standards, instead we simply fill in the needs to store and retrieve objects, not data).

Let’s move up to so called business logic. Nowadays business logic is living in a container. I’m from Rotterdam and the concept of containers is well known in this area. And I agree with it. Containers are great. Throw your logic inside a four by four by two meters dimensioned room and there you go. But do we need endless XML descriptors? Do we need declaretive assemblage? Not realy, I just want to program the content of my Container. So no Spring, no SEAM this time. Just a plain simple IOC container I can fill with my needs. Pico was born before Spring (and after the well forgotten Avalon framework), has a five minute introduction to explain the concepts and still works perfect.

Now, move up to the top. The presentation layer. The area where the framework war finds its real trenches. Struts has lost the war two years ago (can post a seperate blog on this issue, wont do that). There is Wicket, there is Spring-MVC and Spring Web Flow, there is JSF, somewhere there is Tapestry and of course the full pile of homegrown JSP, velocity, or whatever template based presentation frameworks. Oops, forgot to mention Cocoon in case you’ve driven into (or gets driven by) XML. And, last for not least we have to deal with the concept of rich clients (still think OpenLazlo is a fairly good option to create bling bling applicatons). AJAX is on the move and all previously mentioned frameworks are doing the best they can to support this technology. But why not use an ‘AJAX-native’ framework? Echo2 is using AJAX and supports the ‘Swing’ way of developing rich internet applications. A perfect match in the search for an alternative stack.

So, No RDMS and ORM but DB4O, no Spring or SEAM but Pico and Echo2 on top of it. Why not? Well, I can bring up plenty of reasons not to go for this stack. DB4o and Echo2 do not have real friendly licenses. Pico is coming from codehaus and not from apache. It’s a pain to cluster this stack, Echo2 eats up your HTTPSession (just like Wicket by the way) and DB4O is not Oracle. And finally it’s not standard so developers are facing a steep learning curve and first must go through a bunch of unforseen pitfalls to use it efficiently.

But, after playing for a while with this stack, I have to say its working. It’s working pretty damn good. It’s doing its job: It’s simple, It’s wel designed (pattern wise), and it boost up your performance (development wise). So why not give it a try? The last few days I’ve been experimenting with the DB4O-Pico-Echo2 stack. And to show you this stack has perspective, in the upcoming weeks (months ….) I’ll try to share some code snippets to make it clear.

By the way, before ending up in another war of flames, this post does not try to attack enterprise development using whatever framework. My previous post about SEAM still stands up! There is room for enterprise frameworks but all I would like to express is there is room for more simple approaches also! And all I like to show is that a simple approach might lead to unexpected results. The fact those results are far away from the ideas behind unreable JSR’s or other ’standards’ is no argument for not learning from it. At the end there’s a chief architect who decides and who we’ll follow. But maybe (desperate cry from a man falling of the cliffs), the same chief architect realizes he’s not doing enterprise but just small business.

So, maybe only to see what I’m talking, follow some of the tutorials that can be found on the net (db4o, pico, echo2), download the packages (db4o, pico, echo2) and give it a try to decide for yourself if this technology is applicable or not.