Many developers would have you believe that somewhere along the way, enterprise Java slowly evolved into something that could no longer be done simply. Instead, it was the problems that became less simple. As the problems became more difficult so did the solutions. Servlets arrived, but it was ugly writing html code out in Java code, so we added JSP. Writing Java code in our JSP was ugly, so we remembered MVC. We got tired of writing our own MVC, so we adopted MVC frameworks, and evolved them to meet all the needs of all of the users out there. At the root of it all, though, peel back all of this, and you can still write a servlet if you like. If you want to write a transactional, scalable, remoteable component you can do that by hand. Or you can use an EJB.
Bruce Tate writes an analogy comparing J2EE to riding a mountain bike. In his analogy, he suggests that we are climbing an uphill trail of overly complex technology, and that it’s time to choose a simpler, easier trail. I suggest, rather, that the applications we’re building are the trail, and that our choice of technology is the choice of what gear to use in attacking that trail. When climbing a steep hill, low gears are necessary so we don’t fall over. Trying to use that same gear on a flat or downhill slope will leave you exhausted. Much like a developer would feel if they used entity beans behind stateless session beans behind a session facade called remotely from an MVC web tier, perhaps even JSF, simply to accomplish a 10 screen CRUD application (and don’t forget JMS for logging).
He does make the point, “Most applications are simple, and we don’t need to go through artificial steps to complicate them.” This is absolutely true, and is far more important that the popular suggestion that Java will collapse under its own weight. In riding a mountain bike, even on the long journey of your career, you may not use every gear, but it’s good to know that if you needed it, it’s there. Some speeds on the J2EE bike are still needed, some will eventually be removed. The EJB expert group recognizes that perhaps EJB make you pedal too hard for most projects, hence we have EJB3 coming as a potentially simpler way.
We don’t need a new bike. We need fewer vendors pushing overkill solutions, fewer managers forcing their teams into first gear just in case they need to climb a big hill, and more practical developers looking to build the right system instead of building resume fodder. We need to choose the right technology for the projects, and that’s an old idea, not a new one.
4 thoughts on “Who Deprecated My Servlets?”
In all the time I’ve been reading Jroller blogs, I’ve never seen a statement as sane as this one.
Interesting… except that Spring and other lightweight containers can give you 90% of what EJB give you (actually, it’s 100% of what you need from EJB in 95% of the cases) with about 20% of the overhead. I think this is a good tradeoff, and doesn’t fit into your gear analogy nearly as well as it fits into Bruce’s analogy.
Also, don’t get me wrong, I’m not opposed to new ways of doing things, new frameworks, etc. EJB3, JDO, Hibernate, Spring, etc. are examples of the J2EE industry refactoring itself. Naturally, new technology will replace old, as we (hopefully) learn from our past mistakes.
As much as Spring and other lightweight frameworks make doing the same things simpler, all we’re really saying is that the solution to our problems with frameworks is itself a framework. Though IoC/Dependency Injection streamlines much of what we’re accustomed to doing in frameworks, eventually the lightweight containers will find other ways to be heavyweight and crufty, and be discarded in favor of something new.
Seems like there is movement to a simpler approach to things 😛
When things come to a certain level of complexity, there is a reversal trend towards simplicity…
Comments are closed.