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.

No more low-level code ? Hum...

[zeux]

it's no longer necessary to even think about writing low-level code (except as a technical exercise, or to express your inner geek :-)

Obviously, the guy that submitted this story doesn't know about handheld devices and embedded software. We are still writing A LOT of low-level code on this little planet. And it seems we will still need it for a couple decades.

Frameworks are certainly excellent for high level programming (my end of studies memoir is about them) but they are still way too slow, too bug-gy and too bulky for our little devices... And the thing is that we gonna have more and more little devices in the near future.

Also, your framework works on top of what ? Yes, low-level code...

Case Studies

[krulgar]

Case Studies (as in this case) always seem to come at the end of the book. If they were really analyzed they'd be earlier. Too often this is the author's response to the publisher's request for 80 more pages.

Re:No more low-level code ? Hum...

[wembley]

Except for the fact that this is about web frameworks, e.g. high-level code.

Re:No more low-level code ? Hum...

[captain_craptacular]

This book is a superb exploration of the current state of the web application development framework market.

Please please tell me you aren't writing web application frameworks to be served from your handheld devices.

Obviously, the guy that submitted this story doesn't know about handheld devices and embedded software.

The poster didn't imply that no-one will ever have to write low level code again. He said that you shouldn't have to in this specific context, which is web application frameworks. Of course there will be other areas where low level code is still quite neccesary, no-one said otherwise.

Re:No more low-level code ? Hum...

[Brians256]

Low-level code is not only for handheld devices and embedded software. Sometimes the existing framework just plain doesn't cut it.

It seems there is a huge blind spot concerning "the rest of the code". Not everyone is coding web pages and Java/.NET commerce systems! What about the applications like MS-Word, Mathcad, Compilers, or BitTorrent. OK, the last example is written in Perl which is not really a low-level language but it is certainly not a framework like .NET, but it COULD be written in a low-level language.

Or, how about stuff like what we do at http://www.cmicro.com for probing semiconductor wafers (hardware control/IO/mathematical analysis of signals, etc...). We use a standard PC to do things with a (unfortunately) Windows OS as a base, but we HAVE to do low-level code. The existing frameworks of .NET and MFC simply are not sophisticated enough to do the UI we need, and it does not allow access to hardware that we need. Re-inventing the wheel? I wish I didn't have to!

Dangit! Not everything is the Web!

Did you actually read the book?

[ViolentGreen]

If so I can't really tell. The review seems pretty empty and doesn't really contain any hard info that couldn't be found on amazon.com.

That being said. Java's frameworks tend to be very high quality and easy to work with in my experience.

Not just little devices

[Oestergaard]

Avoiding frameworks and middleware can be just as important on much larger systems.

Often these frameworks ("always" in the case of middleware) will add not just overhead (latency or burnt CPU cycles) to your system, it can add complexity. When given the choice of incorporating some already existing framework, or re-inventing the wheel, I often (but not always) choose to re-invent the wheel.

See, I will end up with a wheel that I know. A wheel that spins like it should, and doesn't spontaneously start brewing coffee, because someone thought that would be a great idea.

Some are religiously against re-inventing the wheel. But hey, the wheel is a well known technology, it is not necessarily very difficult to re-invent it. This amount of work, compared to the long-term implications of being dependent on something that you do not "own", make a little re-invention here and there well worth it.

Earlier on slashdot today you saw ATMs being hit by an RPC worm. Why is an ATM vulnerable to an RPC worm? Because it runs RPC. Why does it run RPC? Well, because nobody re-invented the little wheel it would have been to do a simple data transfer over a TCP connection. No, they chose either to use RPC, or to use a significant amount of middleware which did not allow them to disable RPC (otherwise, why would it have been enabled?).

If people feared re-invention a little less, and once in a while re-wrote that darn wheel instead of relying on frameworks and middleware that they cannot possibly hope to fully comprehend, you would not have ATMs being hit by RPC worms. Ximian Evolution would not take up hundreds of megabytes of memory. Web sites would not mysteriously hang if the MS ASPX interpreter got stuck. My PHP sites would not start giving load errors on every 5% of the hits after a bad call to a file load routine half a decade ago.

The world would be a better place.

Now go re-invent, please.

framework, insfrastructure and other buzz words

[GillBates0]

Somehow, whenever I see a book (or review thereof) with a lot of words like infrastructure, framework,case study, component, in-house,my buzz-word radar goes up. I have given up reading many a book lately, just because I hate the wordiness that goes in to describing the concepts/theory.

And lately, I have started looking at Java as a corporate-hep buzzword too, not to mention .NET, and a hoarde of other ones.

Whatever happened to the concise, well-written, to the point books of a few years ago. Kernigan/Ritchie's C book comes to mind, though it was a C Reference Manual.

Hard to keep track

[Timesprout]

Its almost impossible to keep track of all the frameworks that have sprung up around Java. It seems hardly a day goes by by without someone announcing either a new framework to address issues the rest of us were not aware existed or a new release of release of one of the plethora in existence.

I find myself in a rather ironic position now. A few years ago I was a strong proponent of frameworks. I saw no reason why essentially the same code should be rehashed slightly differently when a framework could be made of the core material and the rest customised as required. Now I have to press the pause button when a framework is put forward to determine if it suits our requirements or is complete overkill for what we need or forces us into an excessively complex architecture to facilitate it.

While still in favour of frameworks I believe you can have too much of a good thing. I think many frameworks available today ignore the "frame" part of the concept and actually try and fill in all the code for you.

Not just little devices-Dark Ages.

[Anonymous Coward]

Now just think of how far engineering would have advanced if had taken the same path? Don't build using standard girders, and fastners. Re-invent your own kind of girders and fastners.

Computer Science will never mature as a discipline as long as is NIH is so prevalent. It's not a cool, but then building anything has "not cool" elements.

Re:Not just little devices-Dark Ages.

[Waffle Iron]

Now just think of how far engineering would have advanced if had taken the same path? Don't build using standard girders, and fastners. Re-invent your own kind of girders and fastners.

A standard fastener like a bolt has probably less than a dozen parameters to worry about. Things like length, thread pitch, diameter, head shape, alloy strength, etc.

If instead, each standard bolt was like a software component and had an API with thousands of parameters to worry about, you can bet that the architects would consider having simpler custom designed bolts machined for each project that match the unique requirements of that job.

Yeah Frameworks are Great

[Greyfox]

Until you have to do something that the framework assumes you weren't going to do. Something like... adding a netscape-specific form tag element to your struts form to prevent the Netscape password manager from popping up. Then you can fight your way through 5 levels of management buerocracy in order to implement a new tag library just to keep your QA people and your users from getting confused. In other words, what should be a simple one-line change in a text file becomes essentially impossible.

I'll say it again: Web Apps Suck. Since this statement confused some people last time I said it, allow me to clarify. For a blog-type-system like Slashdot, webapps are cool. For a simple log-in to your bank and check your account balance, web apps are cool. In fact, right up until you find yourself implementing kludgy work-arounds to get around limitations in HTML, web-apps are cool. The minute you have to resort to Javascript, 1-pixel spacer GIFs or back-end session management databases to get around the fact that your user could be talking to any machine on your cluster, web-apps are no longer cool.

If your web-app is so complex as to need a framework, your web-app probably sucks. It is probably a bloated, complex, nearly unmanagable piece of code that would have been a lot better off implemented as a stand-alone Java program or a lower-level language portable back-end attached to a UI written in either Java or one of the portable UI libraries that are available. But no, your manager wanted to avoid all that because (pick one) 1) everyone's talking about webapps and he went "ooo" and started drooling or 2) You thought it'd look good on your resume so you suggested generating all your applications from XML files using Java and struts.

I expect to see a backlash soon as more people run up against the limitations and unique problems associated with the crappy HTML protocol. The workarounds will become more and more atrocious until eventually the whole thing implodes. I can't imagine it taking more than 4 or 5 years for this to take place.

Re:No more low-level code?

[Krach42]

Some poor guy in India.

Re:Yeah Frameworks are Great

[nate1138]

Kay, couple of nits to pick here. First off, I think you meant HTTP protocol, not HTML. HTTP is perfect for what it was designed for. That is shuttling documents back and forth to between clients and a server. It is very simple to understand and implement.

Second, what's wrong with Javascript? It is very useful in a web app. Field validation, UI enhancement, etc.

Third, I think you are ignoring all of the benefits of deploying a web app VS a standalone application. Such as support (much simpler IMHO). It also helps to negate the massive variations in computer hardware/OS that is out there. If I deploy as a web app, and I am careful about coding standards, that app works the same for a Mac, Windows, or Linux system. Lastly, there is nothing to install. Many users freak out whenever they have to install anything at all on their system.

You have some valid points about the difficulty of deploying such an app, and the workarounds that are necessary, but in the end, I think it is worth it.

Re:Yeah Frameworks are Great

[Greyfox]

Yeah I meant HTTP, my bad.

JavaScript would be great if you could count on it being implemented correctly on every browser. That goes for a lot of browser features. Browsers were never intended for the UI work they're not being used for. If I have to implement a heaping helping of UI code in JavaScript, why not just go back to C and do it using a protocol where I can actually maintain the state of my application from moment to moment?

I am not ignoring all the benefits of deploying a web app Vs. a standalone application. I've done both. Both require careful planning to implement correctly. Both can be guaranteed not to work the same or correctly on every user's machine. Both will require the same level of support questions and both will require you to tell some users that their platform is not supported. Or do you intend to go around supporting those Netscape 4.79 (or Lynx) users forever? Most people who actually deploy web apps are going in that direction now -- my bank's web app refuses to run except on IE 6 or AOL's version of Netscape (Though it works perfetly in Galeon if I tell Galeon to lie about what it is.)

In the end, all I see webapps saving you is having to install some code on the end user's system, and I personally have never run across a user who had a problem doing that. In fact, most of the users I run across have installed so much crapware on their systems that the poor machines run at 1/3rd the speed they're capable of and are more obnoxious than television commercials whenever you try to do anything on the web. If anything, users are too eager to install stuff on their system.

In my opinion, kludging HTTP to deal with an increasingly complex set of things it wasn't designed to do is not worth it.

Re:Yeah Frameworks are Great

[j3110]

We are talking about Java here. I could just use web-start. It's quite nice.

I spent 1 month looking at all the enterprise level technologies out there (You know... anything with distributed transactions, RMI of some sort, and security infrastructure). I spent 3 months learning J2EE. I spent 3 months looking at different frameworks. I eventually decided to go Web-Start. I really really wished there were books that compare the technologies out there based on performance, popularity (increases the number of jobs you can work at and the number of employees you can pick from), and time to completion (ease of use). Java almost has too much choice.

Here are some questions that should make my point.

How do you want to access your data?
JDBC, JDO, Hibernate, CMP, or some weird object-database?

What reporting package do you want to use?
Custom (using iText, FOP, or just plain AWT to the printer?)
JasperReports
JFreeReports
or one of the plethora of commercial packages?

What kind of client do you want?
HTTP, Web-Start, Standalone, or SOAP to Mozilla or .Net or Perl or etc. ?

If you go HTTP, what web framework do you want to use?
JSP/Servlets directly, Struts, WebWork, or some conjured up Velocity template?

If you go Web-Start or Standalon, what GUI TK do you want to use?
SWT, Swing, Thinlet, Luxor, Swixml, AWT (for 1.1 compatibility), etc.

Do you want MiddleWare? What kind?
Session Beans, Message Beans, Message queue's and some custom apps... with or without SOAP? Would you like a nice XML-RPC to go with that? Maybe you want something a bit more network centered like Jini? Maybe you have to work with some old CORBA software.

Oh, BTW, what operating system do you want to run it on? (Linux, Mac, BSD, Unix) What application server? (JBoss, Jonas, Pramati, WebSphere, WebLogic, SunONE, JRun, Resin) What database server? (MySQL, PostgreSQL, Oracle, DB2, McKoi, Hypersonic, Firebird, MS SQL) What JVM? (SUN, IBM, JRocket) Do you need charting for your reports? (JFreeCharts, bah... just search google for java charting)

My head hurts now, and I want to cry. When someone ends the madness, please wake me up and tell me what year it is, and which packages I should use, because if I look at them all, by the time I'm done, I'll have to start all over.

Re:Rolling my own...

[Garg]

Yep, you get to be Da Man, all right.

You get to be Da Man who gets called at 3am when one little thing you forgot brings the whole shebang down. You get to be Da Man who gets to enhance it for every little niggling request from your fellow coders. You get to be Da Man who has fingers pointed at him first, then find out later somebody's app didn't follow your rules. You get to be Da Man who meticulously documents it, so they know those rules.

You get to be Da Man who can't take vacation or call in sick.

I gave up my desire to be Da Man some time ago.

Garg