The diagram below shows this process in outline; the individual parts of the diagram will be explained in turn later in the chapter.

When Sun introduced Java ServerPages, some were quick to claim that Servlets had been replaced as the preferred request handling mechanism in web-enabled enterprise architectures. Although JSP is a key component of the Java 2 Platform Enterprise Edition (J2EE) specification, serving as the preferred request handler and response mechanism, we must investigate further to understand its relationship with Servlets. For all the latest information on J2EE, including documentation relating to some of the issues discussed in this chapter, please refer to http://java.sun.com/j2ee.

Other sections of this book explain the implementation details of JSP source translation and compilation into a Servlet. Understanding that JSP is built on top of the Servlet API, and utilizes Servlet semantics, raises some interesting questions. Should we no longer develop standalone Servlets in our web-enabled systems? Is there some way to combine Servlets and JSPs? If so, where do we place our Java code? Are there any other components involved in the request processing, such as JavaBeans? If so, where do they fit into the architecture and what type of role do they fulfill?

It is important to understand that, although JSP technology will be a powerful successor to basic Servlets, they have an evolutionary relationship and can be used in a cooperative and complementary manner.

Given this premise, we will investigate how these two technologies, each a Java Standard Extension, can be used co-operatively along with other components, such as JavaBeans, to create Java-based web-enabled systems. We will examine architectural issues as they relate to JSP and Servlets and discuss some effective designs while looking at the tradeoffs of each. Before jumping directly into a discussion of specific architectures, though, we will briefly examine the need to develop a variety of architectures.