You want to develop a new business application based on your particular business problem. You get a software team to pull together the right mix of technologies to build the required software components. You choose an architect to capture your business requirements and to define the right mix of software and hardware to deploy the appropriate solution. You put together a development team to implement the business processes of your application in the form of software components that magically do everything. Now all you have to do is sell the solution. Right?

Wrong. Nothing is ever that easy, especially in software development. One of the toughest challenges when designing a software application is to define the deployment architecture that ultimately hosts the application's components. Unfortunately, in an application development cycle it's typical to postpone this until the software components are near completion. For successful businesses, it's imperative that the software architecture be well defined ahead of time. Otherwise, changing the developed components to adapt to the runtime architecture is a very costly proposition in both time and money.

The Java platform was designed to support distributed applications from the get-go, although the pieces to effectively do so came later. When Sun divided Java into three editions, it was clear that the platform had come full circle, with J2EE as the architecture for developing business applications across the different tiers. During the past two years, the vendors have solidified their offerings for building applications based on Java's distributed technologies and encompassed by J2EE. However, your software architect has a plethora of choices for developing the end application. How well your architect accomplishes this is based on his or her experience in identifying the appropriate technologies from the wide gamut offered by J2EE. This, in turn, is based on the ability of your software architect to identify the deployment architecture needed to finally host the application.

The current release of the platform offers several options on how to structure the tiers of your application. Specifically, the maturation of the EJB component model, the support around XML and messaging, the introduction of the JCA architecture, and the value-added support offered by the leading application server vendors provide a very stable environment for defining the deployment architecture at an early stage. In addition, the mismatch between the requirements definition and analysis tools such as UML and software design environments has decreased tremendously. Most of the leading application servers and IDE environments are moving toward offering consolidated environments that allow requirements capture and analysis and software development using the same suite of tools. One of the technologies that makes this possible is XML, since it provides a uniform mechanism for exchanging data between environments.

However, getting the right set of tools doesn't complete the job; they have to be applied properly. Good architectural design for an n-tier application requires the ability to select and eliminate the features offered by the platform and supporting environments to maintain the needs of a specific application. Several application development efforts are based on the examples that are bundled with development tools or offered by the platform.

A case in point in the J2EE world is Sun's Pet Store example. While this is supported by most of the leading vendors, it's too trivial for designing a real-world application. Ultimately, you'll have to tailor the technologies to your specific business requirements. This involves answering hard questions like: Should you develop your application on a three-tier architecture using only the Web component layer as opposed to the EJB layer provided by J2EE? When should you use direct JDBC instead of container-managed database access? Are there cases that warrant the use of a two-tier model? Can you base your application on a pure asynchronous messaging layer instead of an EJB-based middle-tier?

The answer to all these questions is: yes, but not always. Fortunately, several J2EE design patterns that embody the experience of millions of J2EE developers are available for making the correct design choices.