Rapid J2EE Development 146
Rapid J2EE Development: An Adaptive Foundation for Enterprise Applications | |
author | Alan Monnox |
pages | 395 |
publisher | Prentice Hall PTR |
rating | 8 |
reviewer | Pankaj Kumar |
ISBN | 0131472208 |
summary | A telescopic view of tools, techniques and processes for boosting Java software development productivity |
"Using a Hole-Hawg for the job of a homeowners drill can have deleterious effect on productivity by causing serious harm to the health of the inexperienced operator." Just identifying a tool for a task is not enough. You should also be able to match the demands of the task to the characteristics of the tool and your ability to handle the tool. The good news is that this book passes even this stringent test, suggesting very practical and hands-on approach for choosing the tool with right characteristics for the specific demands of the task.
The ever-growing body of literature on development best practices, the burgeoning ranks of supporting tools and the accompanying debates on their relative merits can easily overwhelm most practitioners. Worst, a large chunk of the developer community may never spend the time and effort and miss the opportunity to take advantage of them altogether. Rapid J2EE Development offers an easy path to such Java developers by bringing together a number development techniques, best practices and description of supporting open source tools in a single book.
Whether you are a confused Java developer, overwhelmed project leader or plain lost manager, this book has something for you. Wondering about how to design complicated class hierarchies to encapsulate the ever-changing business rules? Worry not, follow the advice of Chapter 10, "Working to Rule" and use Jess, an open-source Expert System Shell. Don't have the time or motivation to download and play with it? No problem. The coverage includes not only an overview and discussion on when and where to use it but also presents a sample session and illustrative code snippets.
If you're confused with all the hype around AOP (Aspect Oriented Programming) and uncertain about where to start, start with the chapter "Aspect Oriented Programming," which introduces the notion of crosscutting concerns in any large software project, presents the AOP terminology to nail down these concerns and associated actions, and covers AspectJ and AspectWerkz to apply AOP to your projects. The brief description of these tools may not answer each and every question, but the example- and code-driven approach will certainly make you feel a lot more comfortable and motivate to explore further.
Not able to decide whether to use XP (Extreme Programming) or RUP (Rational Unified Process) for your next project involving four different development teams in three different continents interacting with as many customer groups? The Chapter "Embracing Adaptive Methods" outlines an approach to making such methodology decisions, though it is not very obvious from the chapter title. (Of course, you will have to read the sections that talk about when XP works best and when the rigors of RUP start paying off to make your decision.) And although there is not much discussion around mixing elements of development methodologies or adapting them in the middle of an ongoing project, the author's account of a real case study does exactly this.
These are just a few examples. Other topics covered include use of UML for modeling, code generators, Model-Driven Architectures, Java-based scripting languages, Object Relational mapping, build and test automation, and use of the right IDE plug-ins for J2EE projects. Among the development tools, all the usual suspects are there: Apache Ant, Eclipse, Jython, JUnit, HttpUnit, JMeter. In fact, I also found description of tools that were somewhat new to me: MyEclipse, AndroMDA, Middlegen and few others.
I found the book to be highly readable, insightful and loaded with the right kind of details. For example, the information on debugging with Eclipse explains how to configure a J2EE program for remote debugging, and how to debug a Web application using JSPs, something that is quite hard to do without the right tools and the right methods. Even the UML primer, with its well-chosen examples, is a good refresher.
It is easy to get superficial when covering a lot of ground: a common pitfall for authors of books on new technologies is that they themselves get caught up in the hype and lose perspective, but Alan somehow manages to keep the extraneous stuff out and deliver what a hands-on professional looks for. He tempers his zeal with practical realities and conveys the same to the reader with anecdotes and discussions with colorful stories such as the Cargo Cult Software trap and Christmas Puppy Syndrome.
The book manages to introduce a number of the very best open source Java tools available to boost productivity in a very natural manner and with the appropriate context, and it succeeds in giving a "feel" for the tool by presenting hands-on sessions. Most other such efforts that I am aware of usually end up being a drab list of tools with descriptions taken from home pages.
Given the number of topics and tools covered, it would be unrealistic to expect in-depth coverage of everything. What this book does is to create the right context, introduce the appropriate topics, and generate sufficient motivation to explore further. Fair enough. In fact, I believe this is the best approach for any book in this "Google era" -- the book should tell what you should look for and let Google do the rest.
So, is there anything not to be liked about the book? Well, I was a little disappointed to not find my favorite BeanShell among various Java scripting alternatives. Another thing I noticed is that the coverage of system manageability issues, especially in a book with J2EE in its title, was quite conspicuous by its absence. Also, some of the points, especially those around use of best practices and development techniques, could be made more emphatically with help of focused and concrete anecdotes.
Of course, no book can cover everything, especially on topics that are open-ended by nature. Overall, I think it does justice to the subject matter and is worth reading by anyone even remotely connected to the business of creating, maintaining or operating Java/J2EE software.
You can purchase Rapid J2EE 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.
Methodology Schmethodolgy (Score:5, Insightful)
Why why why why why to books on rapid enterprise development cover methodologies rife with process and reading-knowledge experts?
Once upon a time we did something called "rapid prototyping". It worked for most enterprise apps where clients and analysts didn't know their a-holes from their L-bows. Then we were told that "iterative software development is programming by trial and error
Then there is a total rebellion by the artists and untrained IT masses, who instead of blaming middle managers with NO expertise architecting, designing, requirement gathering, that instigate zillions of Death Marches - we get peer programming - that pushes back-seat-driver development coupled with accountability (decrease in hours playing Solitaire.)
Somehow more unrest leads to test driven development where you don't try specify every little detail but have a big picture and manage risk (Agile).
Guess what. We're right back to iterative development! But now we got all kinds of fancy labels to attach and heroes to worship.
Common sense and been-there-done-that became Design Patterns.
CR became Programming by Contract.
And all this while the big companies we work for are hell bent on outsourcing us all because "You IT/IS types consistently screwed up projects for years... so we'll give it to someone who knows better [in 3rd world country of choice.]"
The point of my rant?
The best rapid development process is done by experienced people, not by process.
Process doesn't write programs. People write programs.
The most important J2EE Bean of all (Score:1, Insightful)
Re:J2EE has got it all wrong. (Score:4, Insightful)
Re:Pardon my ignorance.... (Score:4, Insightful)
Why is there a chapter on UML? (Score:5, Insightful)
Re:What's that humming? (Score:2, Insightful)
This is one thing I don't understand. People believe that J2EE is the be all end all solution for everything and it's not. If you have a basic site that requires minimal dynamicism then J2EE is not always the right solution - I would purely recommend PHP. If you are using messaging, require flexible reusability, modularity for a distributed system then I would recommend J2EE.
A simple e-commerce website needs no more than say 3 base services: database connectivity, security, email. J2EE offers you those 3 plus a persistence layer (EJB), Messaging (JMS), Object oreinted code, separation of functionality (web containers, ejb containers, third party containers) and extensibility. Yes you need to design a J2EE application a PHP web application can be whipped up with as little design required as possible.
I would agree with you there. Alot of people believe just because they can write a Hello World App in Java then they can program J2EE. Also J2EE is vast people don't expect you know the full system inside out unless you have been working in the industry for at least 5-10 years.
Understanding SQL is good but I would never fully place all functionality into stored procedures unless the database system is required to remove load off the Java app server. If there is legacy SQL procedures in place for say password encryption or data integrity then fine it sits in the DB. If it requires going through thousands of tables then sure let the database do it. It's all about finding balance without affecting portability of code.
Java is constantly evolving and yes there is more than one way to acheive the same result. It's all about how much time you have and what resources are available.
For example we recently had 5 months to put together a document delivery solution which applied DRM to PDF documents. One of our contractors was all into the "design it my way" solution which affected the project heavily. He tried to design his own user security system (Authentication and Authorisation ). He spent nearly 4 weeks working on it and left without even finishing his work! With tight time constraints there is no time to redesign the wheel, make use of whats out there! Our original path was to design the system using EJB's for the persistence layer but it took too long to design and learn so we switched to Hibernate.
Working with J2EE is all about knowing what resources are out there you can use and keeping up to date. Yes knowing the basics is always required if not core but Java opens up your options and when used correctly is an excellent language for RAD. Modelling a project and generating your Java code, table DDL's and any ancillary schemas makes the project move much more quickly and you will always have your model to refer back to which is much easier to follow than trying to wade through all that code.