Java Frameworks and Components
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 ConsiderAfter 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?
SummaryA tour de force! With only one quibble, this is the definitive work on Web application frameworks.
Table Of Contents1. 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.
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.
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.
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.
With all of the high-quality frameworks available today, it's no longer necessary to even think about writing low-level code.
And all this time i've been writing all my bytecode with a hex editor, like a sucker.
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.
We are talking about Java here. I could just use web-start. It's quite nice.
.Net or Perl or etc. ?
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
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.
Karma Clown
Good question.
;-)
... Go Credit Unions! :-)
I am the author and I appologise for forgetting to put a little something about me in the review. My excuse is that I'm too humble, but who knows if you'll buy that?
I am a Java developer with Lands' End. In fact, I was the first Java developer that LE hired, and I've been with the company five years now. I have worked with Java since version 1.0 and was also responsible for the first Java program written at my previous employer (CUNA Mutual Group
I have a slight relationship with the publishing houses, in so far as they send me books. I have no connection to the authors. I get to keep the book, but there is no payment for these reviews. I am highly opinionated, so if I say that I like a book, then that's the straight dope. Check out my personal website if you want proof of my willingness to express opinions (http://www.simonpeter.com/)
Hope this helps, and I'll put in a bio next time.
Simon
simonpeter.org | simonpeter.com | techbook.info