Here's a short pop quiz: Have you ever built an application in J2EE and taken it through the entire product life cycle? Or, for that matter, any distributed computing application? If the answer is "Yes," then answer this one: Have you handled all the facets of the application on your own - as a one-man team? If you answered "Yes" to both questions, my response is: I don't believe you. You can do one or the other, but not both, if we're talking about a real-world application, that is.

J2EE offers a platform for developing applications whose components or subsystems can be distributed across the different tiers of the computing network. The obvious advantage is the decoupling of the programming logic that leads to reusable and scalable solutions. The other main advantage is that development projects can structure their teams so that each member is assigned to develop the subsystem that utilizes his or her particular skillset. The operative word here is team. J2EE projects are team-oriented projects.

Of course, J2EE development can mean different things to different folks. There's a plethora of configuration options for application components and a variety of APIs that can be applied to their development. Sun's Java Blueprints outline the different ways to skin the n-tier. It all depends on the business requirements of your application, the technologies available at your company (or the ones that your corporation is willing to invest in), and the external systems you will have to integrate with.

It's true that a J2EE application can be built by a one-man team. For instance, if you're building the Pet Store application, the airline reservation application, or the typical bank account two-phase-commit example, you can do it yourself. Or if your application consists of a few business flows built on simple business logic and textbook data schemas, one or two developers with similar skillsets will suffice.

However, the colloquial interpretation of a J2EE application is one that uses the J2EE object model - EJB. Typically, EJBs apply to large-scale business applications, and an EJB-based project requires a mix of skillsets. In fact, the J2EE application server vendors have cornered the market on the J2EE frameworks and component containers. The Java IDEs offer the code development environment. The data and business modeling tools enable design and analysis. The vendors offer a mix of options for developing J2EE applications, all based on the J2EE Blueprints.

To effectively utilize the tools in the market, you need to first define an appropriate team for your application. The skillsets you'll need can be broadly classified into the following areas:

• Front-end graphics
• JSP/servlet/HTML/Web development
• EJB/middle-tier Java components
• Database and application server administration

The following is an example of an EJB-based project. If your application requires development using Web services, JMS, JCA, or other Java platform APIs, you'll have to define your team accordingly. While it's possible to "overload" developers to work across the different areas, in a complex application the pragmatic approach is to assign developers to specific areas and migrate them to other areas when needed.

Fortunately, there are resources in the market that will aid you in defining the appropriate architecture. The J2EE vendors have mature offerings that help you develop reusable components, as well as environments that enable you to migrate components across the tiers. Several online and print resources for applying good design patterns and best practices are available too.