The seamy side of JBoss
Went to a fascinating Gavin King
talk about Seam, JBoss’ new application framework. “One framework to rule them all” is the ongoing joke… Basically, think Ruby on Rails, with a EJB3 foundation, proper relationship handling, and some nifty gui tools.
It looks very clever, but I came away with a few big concerns:
- The aggressive conflicts with Spring seem to continue – which is very sad. Spring as a mindset competes with ejb3 (and therefore jboss) – this is fair enough, competition is good for open source projects – but it shouldn’t result in angry fighting like this. It just comes across as petty and arrogant. Scott Ambler lists “Humility” as a key value for a software designer(part of his Agile Modeling principles) – and humility seemed pretty absent this morning. Arrogant derision about other people’s software being a “steaming heap” is hardly a good argument for your own software, or your ability to work with other developers.
- It takes more than “Trust JBoss” to get me to trust a container vendor that the EJB container will somehow magically make stateful server-side objects work, this time. We have been bitten by this before, many many times – EJB2, EJB1, Corba, yada yada yada. Spring has so much mindset because it is light weight – what it does is clean, obvious, and you are in control – it doesn’t magically provide you with extra behind-the-scenes services, instead it gives you wiring to set up your key layers, and leaves the rest up to you. Maybe JBoss will magically work where all previous J2EE containers didn’t – but I’d want a better argument than “IBM couldn’t do it, but our container will magically provide scalable stateful session beans that just work. Trust us.”
- At least based on this morning’s demo, another key lesson of Spring has been missed – loose coupling. Direct access of EJBs from JSP pages? I’m with the audience member who protested loudly – sure, it makes a good demo, but it’s hardly an architecture anyone should be encouraging, except for the most trivial of applications.
- And last but not least, vendor tie-in. Sure JBoss are an open-source oriented company (like IBM?
) but they still are a commercial vendor – and I saw no suggestion that Seam would be available for anyone who didn’t also lock themselves in with JBoss. Another mistake people are learning not to repeat – vendor lock-in is to be avoided, especially when choosing brand new technologies.
Who knows, maybe Seam will take off and be widely adopted – but I’m going to keep looking elsewhere for the Ruby on Rails killer. If RoR had come from a vendor, and only worked on that vendor’s server, it would have been still-born.
Hmm – I really need two blogs, one for technical and one for personal – sorry if this is all opaque, more about my exciting personal life when I find more time 