EJB or not JB? That is the question (sort of) …

I recently read a post on LinkedIn on the WAFUG group by Andrew Hedges:

Frameworks or libraries?

"Frameworks are larger abstractions than libraries. Abstractions leak, cost performance and take up mental resources." ... http://tr.im/20fm

Is the whole framework craze overkill for most projects? At what point does it make sense to use a framework over libraries that just do what you minimally need? Is it better to start with a large, leaky abstraction or only impose it if/when the project gets big enough to need it?

The answer to this for me is "it depends", and it's what keeps architects up at night. Frameworks are usually attempts to encapsulate some best practice or design patterns in a way that will help the developer achieve some gain in productivity, scalability or reliability.

During the dotBomb era, I worked for a small boutique consulting company designing web sites for a lot of startups. All of them were convinced they would be the next big thing, and most of them had extremely aggressive targets for scalability.

Because of this, we spent quite a bit of time with various frameworks trying to understand the balance between the complexity introduced and the scalability that the framework would give us. At the time, Sun was busy pushing the EJB framework, which was a study in how to over-engineer software. The big benefit promised by EJB was that you could theoretically scale your application to infinity and beyond. The downside was that it basically took a huge team of rocket scientists to get off the ground (this was not the nice simple POJO based EJB of today).

What we found was that in most cases, we could get the same sort of scalability for our clients out of simple Model 2 JSP based applications (MVC approach) by taking care to design the application from the database forward. By using the database for what it is really good at (caching, storing and reading data), building DAOs to interact with the database, and factoring the business logic out of the JSP's, we were able to build a reliable MVC framework that we used with many clients. The framework was very similar to Struts, which didn't yet exist, and which we started using once Struts2 was released.

Turns out that the amount of traffic that you have to experience to require the overhead of a complex framework like EJBs is not realistic for any but a handful of web sites.

Fundamentally as an architect, it's my job to figure out what the real problem is, to solve that in a way that will answer the business need (immediately),  and to build it in a way that will allow for some level of deviation from today's needs (future scalability and flexibility). So for almost every case that we came across, there was too much complexity and overhead in the EJB framework to make adoption a valid choice back then. Not only did an EJB design require significantly more developer work than the alternatives (making it more costly and harder to change), the initial application wouldn't perform as well (since it was burdened with all the code that was required to make it scale seamlessly).

All of that said, EJB is also a great study in how a framework can be improved. With the current value proposition of EJB3, the objections that were so clear before have gone away: it no longer takes a rocket scientist to engineer EJBs, and in fact any complexity is fairly well hidden from the developer. Most of the overhead of the framework has been moved into the run-time, so it scales much more appropriately.

As an architect, my decision becomes much easier to include a framework like EJBs when it both saves development time, and gives me a clean and simple path to change. There's always a balancing act between the time to market, and anticipated change in the application too. I worked on some applications that used MS Access or Domino to get off the ground quickly because when used as a framework those applications are great RAD tools. You can prototype and get to the 95% level of usability for an application very quickly, and for many apps this is better than good enough.

The problem with these (as with almost any framework) is when you get to the point you need to do something that the framework wasn't designed for. You built a killer app in Access, and now you want to roll it out to the entire company. Well, even though Access claims to work for multiple users, turns out it is a pain, and uses some very archaic methods for things like sharing the database. And even if you reengineer it to store your data in an enterprise DB, it still has the problem of needing to be deployed somewhere or being shared (which again runs you into the locking and corruption problems).

Every problem requires thought and some knowledge of the limitations of the tools in your tool box. By understanding the business problem, and coming to a reasonable understanding of what sorts of changes you can anticipate (including unanticipated ones), you can choose the right level of complexity to solve the problem for today and tomorrow.