Java Frameworks and Components

Simon P. Chappell writes "Life is busy enough without writing your own infrastructure code. With all of the high-quality frameworks available today, it's no longer necessary to even think about writing low-level code (except as a technical exercise, or to express your inner geek :-) Our problem today, is to review and select the best available framework for our needs. This is a non-trivial task, but help is at hand with Java Frameworks and Components by Michael Nash." Read on for the rest of Chappell's review. Java Frameworks and Components: Accelerate Your Web Application Development author Michael Nash pages 477 (14 page index) publisher Cambridge University Press rating 9 reviewer Simon P. Chappell ISBN 0521520592 summary A tour de force! With only one quibble, this is the definitive work on Web Application Frameworks. Overview This book is a superb exploration of the current state of the web application development framework market. Both commercial and open-source/free frameworks are examined in detail.

The book works through a logical progression, starting with a discussion of what a framework is (and, of course, what it isn't) before moving on to an examination of the benefits that they bring to development efforts. The meat of the book is in the next couple of chapters where a framework (no pun intended) is explored to select and compare frameworks. A list of current frameworks is given, each being described, with strengths and weaknesses highlighted.

The trailing chapters cover aspects of development that are affected by the use of frameworks, including the obvious ones like IDE support and methodologies.

What's To Like The aspect that most impressed me was the depth of research that has obviously gone into this book. I think most of us know that frameworks are good, and a reasonable number of us could list several reasons why they are good, but I suspect that very few of us could generate such a comprehensive and cogent rationale for using a framework.

The information density in this book is quite high. Normally, I read technical books quite quickly, but this one took a while, because every good point prompted much thought and consideration. This was impressive to me after seeing so many books coming to the market that have simplification as their rationale for existence. The selection of an appropriate framework for web application development is not a simple task and this book takes it very seriously.

While non-free frameworks might be a non-issue for some of the Slashdot crowd, those of us working in corporate I.S. have to be very aware of the differences and our local management's attitudes concerning it. The book does come out strongly in favour of open-source and free software, but does not let this bind the discussion in any way. Commercial and free software are judged equally and fairly throughout.

Pragmatic is a much over-used word these days, but I would describe this book as pragmatic. The advice given concerning framework selection, urged people to consider many factors, including existing frameworks used in-house, the type of project, the degree of accordance between the services provided by the framework and the requirements for the system being written. I have seen many a framework selected because it was buzzword compliant, so this advice was a refreshing change.

What's To Consider

After enjoying the book, to reach the case studies and be disappointed was, well, disappointing. The case studies seemed rushed and lacking in substance. The idea of comparing and contrasting the four leading frameworks to solve the same problem was a good one, but somehow it didn't quite come off. The Struts case study got to me the most: I have conniptions everytime I see business logic in actions! Perhaps the case studies could be dropped in a future edition?

Summary

A tour de force! With only one quibble, this is the definitive work on Web application frameworks.

Table Of Contents

1. Components and Application Frameworks
2. Components: The Future of Web-Application Development
3. Application Frameworks: What Do They Provide and What Are the Benefits?
4. Choosing an Application Framework
5. A Catalog of Application Frameworks
6. Comparing Frameworks
7. Open Source and Components/Frameworks
8. Development Methodologies and Design Patterns
9. Integrated Development Environments
10. Strategies for Using Frameworks: Best Practices
11. Conclusions: The Future of Frameworks and Components
Appendix. Case Studies

You can purchase Java Frameworks and Components: Accelerate Your Web Application Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

aren't?

[dance2die]

Arent' there as many frameworks as there are coffee types in Starbucks? I wonder which java framework i woudl like to choose.. IT's a daunting task for me already to pick a right flavor @ coffee shop... :)

WTF is "infrastructure code"?

[heironymouscoward]

(Raises hand)

I think I understand the term, but does that mean it's a given that any application is built around a "framework"?

All well-constructed software is sliced into coherently-discrete layers that are solved as individual problems, but I believe the "framework" concept is largely a commercial concept designed by certain vendors to enable them to sell large, complex toolkits.

Are we not in danger of taking this commercial model and turning it into dogma, in which your application shall be built around a framework and the only choice is "which one?"

Who are you?

[Sean80]

I've said it once, and I'll say it again. Who are you, reviewer? Are you connected to the author or the publisher? Do you have any financial interest in this review?

At least try to provide a disclaimer. Otherwise, an excellent review of a technical book published on probably the largest technical web site on the internet. Smells like fish, tastes like fish to me.

My 2c.

Why not write your own Framework?

[Guru1]

Simply put, our group wrote our own struts type framework. This was around 4 years ago when struts wasn't quite as hyped, and we wanted something that did exactly what we wanted, without extra baggage or cost. Four members in our group, it took us around a week to write the basic components.

Other groups (sitting a few feet away from us), have gone through a couple framework tools, ending up with struts.

I really don't see a difference in either approach. So many times writing your own tools is frowned upon, but when you're talking about small scale projects, why not? Do you really need every feature of struts to display a fairly simple website? A few forms, polls, etc.. why install such a massive package?

For my home machine, I wanted a couple forms, a photo album, and fairly simple navigation. I wrote it in a night. It would have taken me just as long to download the tools, install them, and set them up.

I think the problem is that it's a very "in thing" to use the latest tools. The technology lead for the other team was pushing for one open source solution before, then was pushing for struts, now is pushing for some other "cool" tool. I would rather focus on writing for what is needed, rather than for what is a cool solution.

Re:Why not write your own Framework?

[Anonymous Coward]

In general it is a best practice within all of engineering to reuse what is already there. It takes time to design, develop, test, and maintain a custom framework. It may start out as simple but over time the chances are that it will grow. As it grows the upkeep will grow. By using a framework that is already highly regarded by the industry you save yourself all of those costs as well as benefit from using a proven technology. I am not talking about bleeding edge frameworks that are not standardized like JSF or Portlets but standardized technologies like struts.

DISCLAIMER:
There is little doubt in my mind that JSF and Portlets will become major players in the framework arena but for now they are the equivalent of beta software.

Re:Why not write your own Framework?

[enjo13]

While you qualify this 'especially for small projects', I feel that all projects (big or small) benefit from standard underpinnings when they are available. One of the absolute BIGGEST reasons to standardize on a open and free framework like Struts is a business buzzword known as 'knowledge management.'

It is MUCH easier to find a programmer familiar with Struts than it is to find one familiar with your framework. When you leave the company, move onto other projects, or (god/allah/diety of your choice forbid) are hit by a bus your proprietary framework now must be maintained by someone else. If you had used a standard framework to do the same thing, then you can easily go out and find a programmer who can more easily step in and fill that role.

There are, of course, lots of other benefits. When your framework has a bug, it requires your time to find and fix it. One open, free frameworks it's often fixed before you even know about it. When you have lots of developers working together on a mission critical piece (the framework), then your application benefits with only a small effort from you. The whole is MUCH greater than the sum of it's parts in this case.

The only caveat to this is knowing when a tool TRULY meets your needs. I'm a PalmOS C++ programmer (a rare beast:) ) and while there are a couple of nice C++ frameworks out there, neither begins to address the level of abstraction that I desired. I could have used them, but would have spent more time fighting the framework than I would from enjoying it's benefits. So I rolled my own. If there was a framework that truly met the needs of my application, I would have used it in a heartbeat. It sounds like the problem for your 'other groups' isn't the frameworks, but their inability to accurately understand how the framework fits into their product.

Rolling my own...

[Anonymous Coward]

Am I the only one who thinks that sometimes its simpler, not to mention more fun, to write my own low-level/framework code? Before you flame me, I DO understand the value of using a framework (reuse, time, integration, other developers, blahdiblah). When you write your own framework, you get to be Da Man.

Useless

[blamanj]

Excuse me, but what frameworks are compared and covered?

Are we talking GUI frameworks, JSP Engines, Web application frameworks, what?

This "review" told me nothing.

Standard frameworks not always the answer...

[Anonymous Coward]

Because you've got to spend a lot of time learning them. We looked at a bunch of frameworks (Avalon, Klim, and some others) and felt the amount of time needed to learn the framework was about the time it would take us to implement our own (we didn't need many features, just component loading and common db and log access).

So we rolled our own. Since java has interfaces, built in rpc, threading, and db-independant DB accesss, and most IDEs support some refactoring, it was pretty easy. Except for that classloader stuff. Ugh.

You probably disagree. Flame away!

-- ac at work

Re:Why not write your own Framework?-OSS Perils.

[cjustus]

I see where this is leading... Just to nip it in the bud...

I'm not saying the OSS are bad... I'm saying that when a system allows for a user to make changes, and I choose to take advantage of that (as an end user), that I am leaving the path of upgrades, and commiting to sticking with that version for the foresee-able future...

If I go an modify low-level (non-module) linux source code, in a particular distribution of Linux, do not submit by code changes back, then if I want to upgrade to the latest and greatest kernel, it's going to be non-trivial... Check out the struts site... Great, stable, framework... I use it, but find I need to make changes to 1.1 ... Now 2.0 is on the roadmap, and when it comes out, migration will be non-trivial for those that take advantage of internal code, modify the internals, etc... and migration may still be non-trivial even if I haven't made changes...

My point is that choosing to use a public framework, you must consider the path that the code is moving in... In the case of an apache project, it's going to be well-managed, well-defined, and as an open source solution, will be available for all to discuss / contribute...

turbine

[Leonig Mig]

has anyone tried turbine? i'm just getting the hang of it, as it seems like a more coherent and quicker way of getting going than struts? i quite like it now, wondering if anyone had any reservations who has had an experience with it.

thanks.

Application frameworks vs webapp frameworks

[smagoun]

There are plenty of webapp frameworks out there, but are they really the right way to write an app? Picking a technology (like servlets) and then writing an application based on that technology - or based on a framework that wraps that tech - is fundamentally broken for many apps.*

The problem is that technologies change over time. Tech-oriented frameworks make writing the app easier in the short run, but they don't consider the long-term life of the app. Applications that are tightly coupled to any given tech become a liability as that tech ages, and quite often migration to a new tech involves a ground-up rewrite of the application. Instead of tying the app to a framework like Struts or a tech like EJB, write the app to stand on its own, using interfaces to the various techs it needs. Particular technologies like Struts (for a web UI) or EJB (for persistence) can be swapped in + out of the application as necessary without changing the function of the application itself.

There are a number of benefits to a technology-agnostic approach like this. The technology implementations can be upgraded: find out that EJB is a dud? Switch to Hibernate! Perhaps more interestingly, the technology implementations can be supplemented: Have a web UI, but need to ship a desktop application too? Plug in the desktop app tech implementation and presto! You now have both a web UI and a Swing/SWT/etc UI for the same app. Testing becomes far easier too, because you have clearly defined boundaries between the different components of the app (so it's easy to figure out which part isn't behaving).

There are drawbacks, of course. To work as advertised you need to invest a fair amount of architecture to get such a system off the ground. Someone has to write the tech implementations, as well - an SWT UI for your app won't just fall out of the sky when you want it.

Everyone has their pet project. Mine is Sandboss, an approach to enterprise application development that's application-centric, not technology centric. It concentrates on the app itself - you don't wind up with a "Struts application" or an "EJB app". Instead you wind up with an application that can use Struts and EJB, but can also work with Hibernate and WebWork. It's not for everyone - it requires a fair amount of committment to the methodology - but it works well in practice. The time savings are pretty incredible, and the components really are reusable.

*There are many places where a front end for a database is all you need. Of course, once the requirements for that project start to grow you'll wish you had something more powerful.

Re:Application frameworks vs webapp frameworks

[mjglobal]

What your describing sounds a bit like a project I'm involved with, Keel, a "meta-framework" for lack of a better term. Application-logic oriented, framework independant, switchable implementations (we just added an implementation to use Hibernate for one choice as persistence, for example). Quickly looking at the sandbox.org site, it sounds like there might be a lot of synergy between the two. Feel free to drop me an email directly if you want to kick that thought around a bit... Mike

Re:Which frameworks are covered

[blamanj]

Thanks, it would have been nice to see that list in the review.

I'm curious though, why you lump everything together under the word 'framework.' To me, framework implies a particular programming model that must be maintained. So JUnit is indeed a framework, though it doesn't at all compare directly with Struts, a framework with a completely different purpose. When I looked at the table of contents, I expected to see some sort of classification scheme.

And things like Xerces I wouldn't class as a framework at all, more an API.

Re:Which frameworks are covered

[mjglobal]

You're quite right that "framework" is a broad (and sometimes misused) term. I go into that in some detail in the book, and the frameworks reviewed are divided up by category to make it clearer (e.g. whole-application frameworks, persistence frameworks, presentation/UI framworks, etc)

I thought Xerces was just a tool/API as well at first, but with bit of digging I found it actually is more of a framework, with pluggable implementations, a component structure, several different APIs, etc. That's why I thought it made an interesting example on the "border" of what a framework is.

Mike