Perusing javablogs, I discovered that a friend from college, Rich Unger, has a journal on java.net and recently mused on the proliferation of J2EE frameworks. I decided this was as good an opportunity as any to geek out in my blog, given that I’ve been neglecting it of late.
Despite the fact that he lists things like “Hibernate” (an Object/Relational mapping tool), “Velocity” (a text templating language agnostic to J2ee or web frameworks), “SiteMesh” (a Servlet filter for decorating pages with common layout components like headers and sidebars), and “EJB” (component-based framework for creating distributed enterprise Java apps), I believe Rich’s real astonishment is at the number of Java web frameworks available to webapp developers. Indeed, this can’t really be argued against; Java web frameworks are legion. New ones pop up all the time, each created seemingly to meet the whims of another development style. As a wise man once said, that’s the beauty of standards: there’s so many to choose from.
I think, though, it’s a common mistake (especially among webapp development newcomers) to confuse web frameworks with application frameworks. I would guess there aren’t many experienced J2EE developers who didn’t, at one time or another, work on a project that failed to make this distinction. A web framework, if done well, only provides a solution for one tier of a typical J2EE application: the UI. This is also the reason, as Rich puts it, that “the folks at Spring seem to take it for granted that Tapestry is something best relegated to the UI layer.” They do that because that’s what Tapestry and other such web frameworks are built to solve: organizing code and content in the UI tier of a J2EE application. Once you start using a web framework for more than that, though, you’re really asking for headaches. Placing business logic and persistence code directly into your Struts actions or JSP pages, for example, invites a host of problems into your application.
That’s why frameworks like Spring are so compelling. Spring is an application framework. In fact, while it is incredibly well suited for J2EE development, it works beautifully in environments that wouldn’t normally be considered under the J2EE umbrella, such as in the Spring Rich Client Project.
Part of Spring’s charm is that it (typically) doesn’t attempt to reinvent the wheel. It provides a clean and consistent interface (both through its API and its IoC configuration model) for many, if not all, of the technologies you would use in a typical J2EE application. Spring’s effectiveness in this regard can’t be understated. Rich complained about a proliferation of web frameworks, but have you seen a list of the “core” set of J2EE technologies? They include, but are not limited to, JTA, JMS, JDBC, JMX, EJB, JavaMail, JSP , and servlets. Note that only those last two are specific to the web tier. Yet all of these technologies have different APIs, different exception hierarchies, different configuration mechanisms, different programming models. The beauty of Spring is that it provides a unified front for these technologies, allowing for easier coding, testing, and configuration.
This is why there’s no contradiction when coupling Struts and Spring. While Spring does provide an MVC library for implementing the view tier of a web application, it doesn’t mandate its use, and provides direct support for a number of other view technologies, including the ever-popular Struts. Thus, Struts is not a direct competitor of Spring, just Spring’s MVC layer.
I could discuss this at length, but I’ve already exceeded the point where anyone would find this post worth reading. For more information about what goes into writing J2EE applications, I really recommend Rod Johnson’s books “Expert One-on-One J2EE Design and Development” and “Expert One-on-One J2EE Development without EJB“. While the second one is certainly Spring-friendly, the first was written prior to Spring, and is the tome that inspired the development of Spring in the first place. It provides a really powerful overview into the technologies and architectures available when creating J2EE applications.
Read Full Post »
