Summary "Expert one-on-one J2EE design and development"

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.

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.

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

Staging environments and release management

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.

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.