Previous    Next

Summary

In this chapter we've considered some of the most important choices to be made in J2EE development projects, other than the architectural decisions we considered in . We've looked at:

• How to choose an app server. One of the strengths of the J2EE platform is that it allows a choice of competing implementations of the J2EE specifications, each with different strengths and weaknesses. Choosing the appropriate app server will have an important influence on a project's outcome. We've looked at some of the major criteria in choosing an app server, stressing the importance of considering the specific requirements, rather than marketing hype. We've seen the importance of choosing an app server early in the project lifecycle, to avoid wasting resources getting up to speed with multiple servers. We've considered the issue of total cost of ownership, of which license costs are just a part.

• Managing the technology mix in an enterprise. While an unnecessary proliferation of different technologies will make maintenance more expensive forever, it's important to recognize that J2EE isn't the best solution to all problems in enterprise software development. We should be prepared to use other technologies to supplement J2EE technologies where they simplify implementation.
• Practical issues surrounding J2EE portability. We've seen how to ensure that we don't unintentionally violate the J2EE specifications, by regularly running the verification tool supplied with Sun's J2EE Reference Implementation, and how to ensure that app design remains portable even if we have good reason to use proprietary features of the target platform.
• Release management practices. We've seen the importance of having distinct Development, Test, and Production environments, and the importance of having a well-thought-of release management strategy.
• Issues in building and managing a team for a J2EE project. We've considered the implications of using a "Chief Architect," as opposed to a more democratic approach to architecture, and considered two common team structures: the "vertical" structure, which uses generalists to implement whole use cases, and the "horizontal" structure, which focuses developers on individual areas of expertise. We've considered a possible division of roles in the "horizontal" team structure.
• Development tools. We've briefly surveyed the types of tools available to J2EE developers. We've stressed the importance of the Ant build tool, which is now a de facto standard for Java development.
• Risk management. We've seen that successful risk management is based on identifying and attacking risks early in the project lifecycle. We've discussed some overall risk management strategies, and looked at several practical risks to J2EE projects, along with strategies to manage them.

As this is a practically focused tutorial, I haven't discussed choosing a development methodology, or deciding when one is required. However, this is another important choice. We've seen the importance of tackling risks early. I recommend using a methodology for J2EE development that emphasized this. Both the Rational Unified Process and Extreme Programming (XP) meet this requirement. Personally, I prefer "lightweight" or "agile" methodologies (see http://agilealliance.org/principles.html), although the degree of formality appropriate tends to increase the larger the project. I recommend the following resources as starting points for readers unfamiliar with these methodologies: The Unified Software Development Process from Oracle (), and http://www.extremeprogramming.org ("Extreme Programming: A Gentle Introduction").

In the next chapter we look at testing J2EE apps. Testing is an important concern throughout the software development lifecycle and is accorded particular importance in both these methodologies.

Previous    Next