Projects

The following is a summary of some of the important guidelines for J2EE projects:

• Base design decisions on what works now, not a promise of brilliant functionality in the future
  Basing a project on a moving target of new server and specification releases is a recipe for failure. The nature of the J2EE specification process, which incorporates community input, but results in specifications being released before production-quality implementations of them, means that specified features are not always proven to work in the real world. This is another area in which J2EE development is about more than specifications.

• Don't read too much into trivial examples
  Most J2EE sample applications, such as Sun's Java Pet Store, are far from production quality, and simply ignore many common problems. So don't assume that all the approaches they use will be relevant to your real-world problems.

• Test your application thoroughly
  Design your application so that it is easily testable and test it at multiple levels. Build unit testing, functional testing, and performance testing into all phases of the development process. Consider writing tests before application code, and keep tests up to date.

• Document your application thoroughly, but keep documentation relevant to application code
  Always provide comprehensive Javadoc comments. Use graphical models and design documents as necessary. However, remember that fat formal documents are likely to be ignored by developers and seldom remain relevant throughout the software lifecycle.

• Adopt a methodology that tackles risk early
  J2EE applications have many moving parts, and must work with disparate resources: a lot can go wrong. Successful projects tackle risks as early as possible.

• Choose an application server early in your project, and develop expertise with it
  Learn about its capabilities and streamline the development, testing and release cycle using it. Although J2EE applications are usually portable between application servers, each application server is profoundly different to work with and has different strengths and weaknesses. Deferring a choice of application server will ensure a myriad of irritations, adding substantially to the effort involved in a project. Focus on your organization's needs, rather than marketing material, when choosing an application server.

• Automate the build and testing process early in the project lifecycle
  While IDEs provide valuable functionality, their functionality isn't scriptable. Use IDEs to enhance productivity, but ensure that there's a standard build script in place. Ant is now the de facto standard for building Java applications, and can be used to automate a host of other essential tasks such as unit testing, updating documentation, and deployment.

• Hire a core of experts in J2EE design from the beginning of the project
  J2EE is complex, and doesn't always work as it says on the can. Trying to save money using a team of inexperienced staff will cost more in the end. A core of experts can mentor less experienced developers as the project progresses, gradually building a deeper reserve of expertise.

• Write as little application code as possible
  In particular, avoid reinventing the wheel by understanding and leveraging the capabilities of your application server and using existing frameworks.

• Adopt consistent design and coding standards to ensure good practice
  Its vital that all developers on a project understand and commit to common standards. This helps to ensure good practice, enhances maintainability, and helps to minimize duplication of effort.

Above all, it's vital to take a flexible and pragmatic approach to J2EE design. Ultimately, applications are measured by how well they meet their business requirements and how cost-effectively they are implemented and maintained.

Hopefully, after reading this book you will feel more confident about taking design decisions and making implementation choices in J2EE projects. Good luck!