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.
October 4th, 2005 at 11:37 am
Nice to see that there are developers that see through the hype of frameworks. If we all take a serious look at our own projects, nobody can convince me that we are all implementing the next Amazon.com or Ebay. So why not use these frameworks en build a nice stack. Way to go… Quick and easy that is something we have to be all aware off.
October 27th, 2005 at 4:10 pm
Thanks for your post! May I just ask why you consider db4o not to have a friendly license? db4o is available under a dual license, exactly like MySQL: You have the choice between the *free* GPL version and a very affordable (10x lower cost than incumbent OODBMS) commercial license, if you don’t like to follow the obligations of the GPL. Is that more unfriendly than Oracle where you have no free licence and pay 80x more than MySQL?
Cheers,
Christof
October 27th, 2005 at 4:11 pm
Christof, indeed it is the GPL. As soon as one of the libraries / frameworks / components / whatever that is included in a piece of home brewed software is using GPL, it is impossible to release your home brew under a less restrictive license. So let’s say I’m re-inventing the blogger software wheel again using db4o and I want to give my invention to the world, for free, for the sake of the nation or just for fun, I have to release it as GPL. Why not go for a free-BSD style licence?
But you are right, when using db4o as a replacement for your way to pricy oracle, the licensing model is pretty neat
October 27th, 2005 at 9:58 pm
By the way, Postgres (http://www.postgresql.org/) is released under BSD licensing terms. Ever tried it? Seems a good replacement for MySQL in case you run into licensing problems. Not for db4o of course since it is still a relational, meaning O/R mapping demanding, database.
November 2nd, 2005 at 7:48 pm
Okke,
you are right, that the GPL is pretty restrictive. That’s why db4objects offers a very affordable commercial license to complement this. This so-called dual-licensing model works well for a couple of open source DBMS vendors, including MySQL and Berkeley DB.
If db4o was to go BSD, we would need to find other revenue streams, such as Postgres does with services, to be able to invest as heavily as we do into the technology and the ecosystem around it.
The downside of a service-based revenue model is that you have no incentive to make your software easy-to-use, because you want to sell services.
db4objects has chosen a different path: We decided not to sell services and make the software as easy to use as possible, to make the live of OO developers much easier. But in return we ask for some financial contributions - only from those that ship their product not under the GPL (i.e., usually commercially) and not until they actually ship (not when you evaluate, develop or use it inhouse).
Does that sound like a fair compromise?
Have a great day!
Christof