Chapter 2: J2EE projects: choices and risks

Developing a policy on specification versions

Decisive factors in determining a policy with respect to specification and language versions include:

• The nature of the application (does your particular application need the latest features)
• The length of the project (long projects may “wait” for newer releases)
• The nature of the organisation (mission critical)
• Portability between application servers

To minimize risk, steer clear of new, unproven technologies, even if they seem attractive. One safe policy is to target the versions of the J2SE and J2EE specifications that are supported by the mainstream application server vendors at project inception, although some projects may need to take future server release schudules into account.

Choosing an application server

In many cases, the application server will have been chosen before the project begins. For example, there may be an organization-wide policy, regarding application server choice. In this case, try to work with the chosen server. Don’t introduce another based on your or your team’s preferences, complicating the organization’s technology nix. If the chosen product is demonstrably inferior, and it’s still realistic to abondon it, lobby to have the choice changed.

When to choose an application server

Choose an application server and other important software products such as a database as early as you can. Attempting to defer a choice because “J2EE applications are portable” is a recipe for wasting time and money.

Regularly test the compliance of J2EE deployment units with the J2EE 1.3 Reference Implementation verifier tool. Integrate such verification into the application build process.

Defining the requirements: evaluation criteria

• Supported specifications (specification the server implements, Java version required by the server, etc). Sun runs two application server evaluation programs:
  • The Compatibility Test Suite, CTS
  • ECPerf
• Cost
  

  Cost should not be used as the measure of an application server’s worth. The true test is whether it meets the organization’s needs. Remember to consider total cost of ownership. Outlay on an application server should be only a small proportion of total cost.

• Vendor Relationship (Open Source or not?)
• Vendor Liability
• Development & deployment (Speed of server startup, hot deploy, sophisticated management tools, integration with (JMX) standards, error reporting facilities)
• Value-added features
• Quality of documentation
• Availability of skills
• User experience (look on Internet how users of a particular application server value this product)

Choice process

Useful (among others):

• Proof of concept of a vertical slice of your application!
• Hands-on experience of developers with a particular application server
• Spending money and resources on a complex solution that isn’t needed
• Consultation of independent J2EE expert

The “neat technology” trap

Avoid using technologies for their own sake. Every new technology added to a project makes it harder to maintain, unless alternative approaches are clearly inadequate. Adding new technologies is a strategic decision, and shouldn’t be taken lightly, to solve a particular prolem.

When to use alternative technologies to supplement J2EE

• When a different tool leads to dramatic simplification
• When it’s possible to leverage existing investment
• When it’s possible to leverage existing skill in the organization

Portability issues

Write Once, Run Anywhere (WORA)

What does portability mean

• Portability of applications between application server
• Portability of applications between server operating systems
• The ability to change important resources that J2EE applications rely on

A pragmatic approach to portability

• Write J2EE spec-compliant code
• Avoid platform specific solutions where possible
• Use loose coupling

Staging environments and release management

A typical web project might require three completely separate environments

• Development environment, allows necessary freedom for developers
• Test or staging environment, should as closely as possible mirror the production environment, as production environment critical tests are carried out
• Production environment, no direct access for developers, possibility of version release rollback

Release management ensures that the progress of an application release through the above described development cycle is reversible and repeatable.

Succesful J2EE projects depend not only on good application and application server software, but also on sound release mangement practices and suitable staging environments between developers’ local machines and live servers. It’s vital to invest sufficient time and involve all project personnel in developing a sound and workable strategy in these areas.

Building a team

Team structure

Who owns the architecture? Hierarchical or collective code ownership?

Regardless of who “owns” the system architecture, it’s vital that it’s clearly expressed and that the whole team buys into it. It seldom helps to impose a design on developers.

Vertical or horizontal responsibility

The vertical approach

The vertical appoach lets developers develope from EIS tier to UI tier.

The horizontal approach

The horizontal approach allocates developers to specific areas of expertise such as JSP or EJB. At least one senior should have a helicopter view. A possible division is:

• Markup developer
• Presentation developer
• Web-tier developer
• Business object developer
• Data access specialist
• DBA

Choosing development tools

Note that tools don’t equate to IDEs. Many lower-tech script-based tools are often highly effective in J2EE development.

• Visual modelling tools, mostly useful with entity EJBs, but with imposed hazard of developers not understanding the code that’s being generated
• IDEs, choose one that offers solid refactoring capabilities, such as Eclipse
• Build utilities, compiling source code, test code, creating deployment units (EARs, JARs, WARs), generating Java doc, running tests, working with version control system, deployment. Conclusion: USE ANT
  

  If you aren’t familiar with it, learn and use ANT. Continue to use your favorite IDE, but ensure that each project action can be accomplished through an Ant target. Spend a little time upfront to write Ant build files and reap the rewards later. See Ant in Anger:
  Using Apache Ant in a Production Development System for guidelines on using Ant effectively.

• Code generators: especially useful with entity EJBs, see Xdoclet and EJBGen
• Version control, advice: CVS

Identifying and mitigating risks

The following general principles are valuable in J2EE project risk management:

• Attack risks as early as possible
• Unsure that the design is flexible
• Allow contingency time in the project plan to handle unexpected problems
• Involve more developers when a problem becomes apparent
• Develop a good relationship with your application server vendor
• Learn to distinguish things that are your fault from things that aren’t (i.e. that are known bugs/lacks). That’s why every J2EE project needs at least one expert.
• Use the Internet

In the book follows a list of some significant risks encountered in J2EE projects, along with appropriate risk mitigation strategies.