I was speaking to my recruiter/agent (ok, pimp. Whatever) the other day. A developer like me, but with a better work ethic and business nous. A rails/grails developer, he was back on J2EE and JSF, and enjoying it. Speaking to him reminded me of a lesson I learned a long time ago.
I was on a project a while ago, before the frameworks are as mature as they are now. The project was as much an excuse to skill up the in-house golden-haired boy, as much as anything. We contractors were along for the ride. The didn’t want an app server. Too heavyweight. But it turned out that having a layer to have people log in and to manage their permissions was important. So the young bloke wrote one. It was … what you’d expect. But it was lightweight. Didn’t need one of those damn app servers. Then it turned out that the app really needed a way to manage the problem of apps writing over records that were stale, so all the response/requests were passed with a bundle of what records were entangled in the session – the table names and their primary keys. Back and forth. Over a phone line. But it was lightweight, right?
I saw where it was going. When my time was up, I explained to the dude doing my debrief. Look, I said, this app passes primary keys of all entangles records back and forth with every request. It’s nuts. What is going to happen is that the young bloke will get the bright idea of keeping the list of primary keys for each session on the server, and just passing around an id for the session. That, I explained, is a transaction manager. All this trouble to avoid going with a dreadful heavyweight app server, and at the end of the day you have to write your own transaction manager.
The problem it that their app needed the services that a app server provides. ACID. Access control. There’s no getting around that. And any attempt to go “lightweight” is just going to result in an app thats just as heavyweight as an app server, but you have to spend hours of developer time writing and debugging the code.
These days I’m using spring, and I’m sure you can se where this is going.
We have two applications. A public-facing read-only app, and an editor restricted to certain people who log in remotely to update the data. The public app takes a couple of seconds to deploy. The editor takes half a minute. Why? Because the editor has over 9000 jar files in the war. Spring and struts.
You see, the editor runs on Tomcat. So lightweight! All you need is a WAR file. And the spring and struts jars. Oh, but it’s an editor, so we need an ORM model. No worries – add hibernate. Still lightweight! And the oracle driver jars, naturally. Oh, and spring security. And spring transaction management. And so on, and so forth. Takes a while to deploy. And you have to learn the ins and outs of all the spring and struts configuration files to make it go, write a spring security user service to talk to your tables where the users are. All the bits and pieces.
It occurred to me – you know, it would be way easier to put those library JARs on tomcat. That way, I could compile and deploy just the business logic. At which point, I went wait a moment!
That’s what an app server is. That’s the whole idea. It provides a managed environment for all that stuff that you are going to need whether you like it or not. But it’s so heavyweight! Tough luck – if you want multiple users writing to the same database, then it’s going to be heavyweight no matter what you do.
So what am I saying? Should our you-beaut taxonomic tree editor thingy sit on glassfish? I’ll tell you – I’m beginning to think it should.