| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
In the Internet world, the need to deliver dynamically generated content in a maintainable fashion is extremely important. This content may be personalized to an individual. Great care must be taken when designing the user experience of an application because it will distinguish one application from another and potentially make or break a company.
The sample application is an example of a Web application that delivers dynamically generated content. The underlying data that is used to generate the content for the sample application can be changed without modifying the sample application code. This would allow the administrator of the application to add new products or services which would immediately be available in the application. The sample application was designed to be general enough to not be tied to any product or service. With little effort, the sample application could be tailored to offer different products or services.
In this section we will discuss the technologies used to design a personalized Web application in which the logic that drives the application is separate from the content. We will begin by examining the conventional technology used to generate dynamic content, namely Common Gateway Interface (CGI) scripts. Following the discussion of CGI we will review the features of Java servlets and JavaServer Pages technology.
While the Internet was originally designed to provide static content, the need to present dynamic content, customized to a user's needs, has quickly come to drive the development of Web technology. The earliest response to this need was the Common Gateway Interface (CGI). This interface allows Web servers to call scripts to obtain data from (or send data to) databases, documents, and other programs, and present that data to viewers via the Web. However, CGI technology has a number of limitations.
One limitation is that the code within a CGI script that accesses resources, such as a file system or database, must be specific to the server's platform. Therefore most CGI applications will not run on another server platform without modification. This limits their utility in a distributed environments where Web applications may need to run on multiple platforms.
Second, because a new process must be created each time a CGI script is invoked, CGI scripts are often resource intensive and slow and thus tend not to scale well. Increasing the amount of hardware will allow a CGI application to scale to a point. However, the extent to which the application will scale is limited to the hardware and the operating system.
Finally, CGI applications are difficult to maintain because they combine content and display logic in one code base. As a consequence, two types of expertise are needed to maintain and update CGI scripts.
Many Web server vendors have enhanced CGI for their specific products and have developed better ways of handling CGI-like functions by providing extensions to their products. These have enabled the development of sophisticated Web applications based on CGI. However, the root problems still exist: CGI applications are platform-specific, do not scale well, and are difficult to maintain.
The J2EE platform supports two technologies, servlets and JavaServer Pages, that provide alternate solutions that overcome these problems.
Java servlets are a means of extending the functionality of a Web server. Servlets can be viewed as applets that run on the server. Servlets are a portable platform- and Web server-independent means of delivering dynamic content. A browser-based application that calls servlets need not support the Java programming language because a servlet's output can be HTML, XML, or any other content type.
Servlets are written in the Java programming language. This allows servlets to be supported on any platform that has a Java virtual machine and a Web server that supports servlets. Servlets can be used on different platforms without recompiling. They can use generic APIs such as JDBC to communicate directly with existing enterprise resources. This simplifies application development, allowing Web applications to be developed more rapidly.
Servlets are extensible because they are based on the Java programming language. This allows developers to extend the functionalities of a Web application just as they would a Java application. A good example of this would be a controller servlet that is extended to be a secure controller. All of the functionalities of the original controller would be provided along with new security features.
Servlets perform better than CGI scripts. A servlet can be loaded into memory once and then called as many times as needed and scale well without requiring additional hardware. Once a servlet is loaded into memory it can run on a single lightweight thread while CGI scripts must be loaded in a different process for every request. Another benefit of servlets is that, unlike a CGI script, a servlet can maintain and/or pool connections to databases or other necessary Java objects which saves time in processing requests.
Servlets eliminate much of the complexity of getting parameters from an HTTP request; components have direct access to parameters because they are presented as objects. With CGI-based applications, parameters posted from a form are converted to environment properties which must then read into a program.
One of their greatest benefits is that servlets provide uniform APIs for maintaining session data throughout a Web application and for interacting with the user requests. Session data can be used to overcome the limitations of Web applications due to the stateless nature of HTTP.
JavaServer Pages (JSP) technology was designed to provide a declarative, presentation-centric method of developing servlets. Along with all the benefits servlets offer, JSP technology offers the ability to rapidly develop servlets where content and display logic are separated, and to reuse code through a component-based architecture.
Both servlets and JSP pages describe how to process a request (from an HTTP client) to create a response. While servlets are expressed in the Java programming language, JSP pages are text-based documents that include a combination of HTML and JSP tags, Java code, and other information. Although both servlets and JSP pages can be used to solve identical problems, each is intended to accomplish specific tasks. Servlet technology was developed as a mechanism to accept requests from browsers, retrieve enterprise data from application tier or databases, perform application logic on the data (especially in the case where the servlet accessed the database directly), and format that data for presentation in the browser (usually in HTML). A servlet uses print statements to post HTML data, both hard-coded tags and dynamic content based on the enterprise data retrieved from the back-end tiers, back to the user's browser.
Embedding HTML in print statements causes two problems. First, when HTML is embedded in the print statements of a servlet, Web designers cannot preview the look and feel of an HTML page until runtime. Second, when data or its display format changes, locating the appropriate sections of code in the servlet is very difficult. In addition, when presentation logic and content are intermixed, changes in the content require that a servlet be recompiled and reloaded into the Web server.
JSP pages provide a mechanism to specify the mapping from a JavaBeans component to the HTML (or XML) presentation format. Since JSP pages are text-based, a Web designer uses graphical development tools to create and view their content. The same tools can be used to specify where data from the EJB or enterprise information system tiers is displayed. JSP pages use the Java programming language for scripting complex formatting, such as the creation of dynamically-sized tables for master-detail forms. Some JSP editing tools may provide advanced features so that a Web designer can specify the formatting of complex data without using Java code. Alternatively, Java programmers can provide their Web designers with a set of JavaBeans components and/or custom tags that handle complex dynamic formatting of HTML, so that the Web designers do not need to understand how to code in the Java programming language in order to create a complex JSP page.
When a Web designer changes a JSP page, the page is automatically recompiled and reloaded into the Web server. In addition, all the JSP pages in a Web application can be compiled prior to deploying the application for greater efficiency.
Thus JSP technology allows content developers and Web application designers to clearly define what is application logic and what is content. Content providers don't need to know Java technology to update or maintain content. Instead they can design interfaces using the JavaBeans components and custom tags provided by the Web application developer. Web application developers need not be experts in user interface design to build Web applications. At the same time, a Web application development and content can easily be performed by a single person.
Like servlets, JSP technology is an efficient means of providing dynamic content in a portable platform- or application-independent means. JSP technology also supports a reusable component model through the inclusion of JavaBeans technology and custom tag extensions. Note that the JavaBeans components used by JSP pages are not the same AWT or JFC JavaBeans components. These JavaBeans components simply expose properties using get and set methods. custom tags can be viewed as intelligent JavaBeans components with the exception that the actions can better interact with the JSP page (see Section 4.4.2).
In summary, JSP technology provides an easy way to develop servlet-based dynamic content, with the additional benefit of separating content and display logic. In a properly designed JSP page, content and application logic can be independently updated by developers with specific expertise in each area.
Currently CGI scripts are widely used to provide dynamic content. Technologies such as servlets and the JSP technology that are scalable and easy to write and maintain should be used instead of CGI scripts. This is driven by the need to provide dynamic content in a platform-independent, scalable way.