JavaServer Pages inherit the concepts of Applications, ServletContexts, Sessions, Requests, and Responses from the Java Servlets API and offer the same portability, performance, and scalability as servlets.
Java servlets overcome many of the deficiencies of CGI, ISAPI, and NSAPI. Although the CGI-BIN interface itself is not platform-specific, code has to be recompiled for different platforms, and performance is poor for large-scale applications because each new CGI request requires a new server process. Similar platform-specific interfaces such as ISAPI and NSAPI improve performance, but at the cost of even less portability.
Because Java servlets are written in Java, they are completely platform- and server-independent. They provide superior performance and scalability because they can be compiled, loaded into memory, and reused by multiple clients while running in a single thread, and they can take advantage of connection caching or pooling.
Java servlets are described in more detail in Chapter 22, “Creating Java Servlets”.
Java servlets and JSPs are based on the same API, and either can be used to fill some roles in a Web application. But while Java servlets are Java code with embedded HTML, JSPs are HTML (or XML) pages with embedded Java code. This difference provides additional advantages.
Servlets need to be recompiled and deployed whenever there is a change to the page presentation, so they are best used where such changes are not required. Use servlets to generate binary data—such as image files—dynamically, and to perform complex processing with no presentation component.
The JavaServer Pages API provides tags that make it easy for a Web-page developer to add dynamic content to a Web page without writing Java code. The application logic in the page can be separated from page format and design. This separation supports multitiered development. An application developer can build EJBs, JavaBeans, and custom tag libraries. The page author needs only know how to call these components and what arguments to pass.
In a typical architecture for multitier applications, a Web server communicates with a client via HTTP, with a transaction server hosting components that handle database transactions. JSPs make it easier to partition and maintain an application on multiple servers. The JSP runs on the Web server and can be updated whenever the page designer needs to change elements of the presentation. The components called by the JSP run on the transaction server, or on a cluster of transaction servers, and can be updated whenever the business logic needs to change.
You can also separate request handling from presentation using JSPs as front components and presentation components. A front component receives a request from the client, creates, updates, or accesses server components, then forwards the request to a presentation component. A presentation component incorporates fixed template data and returns the response to the client. Both types of JSP typically use custom actions to access the server-side data.
