What Is Resin?

Overview

During the early years of the Web, developers used a fairly small set of HTML document tags to manipulate the style and layout of each Web page. These static Web pages were usually stored on the same computer that was executing a Web server. When a user launched a Web browser on his or her local machine and pointed that browser to a Web server, a protocol-based exchange of information began. The page sent to the user was really just a text file with information and HTML tags embedded in it to present the information in a clear manner.

As time went on, it became clear that providing up-to-date and personalized information was going to be a developer's nightmare if using static pages was the only option. Keeping the static pages up-to-date was feasible, but personalizing that information manually was next to impossible. This meant that the pages had to be created on the fly in response to an action or request by the user. One early solution to this problem was called Common Gateway Interface (CGI). Figure 1.1 shows an example of how requests are made using CGI and a Web server.

Figure 1.1: CGI request flow.

Unfortunately, there were some problems with using CGI for dynamic Web page generation. First, the CGI protocol was designed to allow a Web server to communicate with an external program and not specifically for the generation of dynamic Web pages. The creation of the Web pages is actually a side effect of the CGI protocol. As shown in Figure 1.1, the protocol is written so that the Web server will create new process spaces in which the CGI application will execute. All information passed from the user's Web browser to the Web server is passed as environment variables to the waiting CGI application. All of these operations are expensive in terms of processor time as well as memory utilization.

The second problem is the fact that most CGI applications were written in Perl, with C and C++ coming in second. Depending on your programming capability, Perl could be a stumbling block to Web development.

After the success of CGI became apparent, an alternative implementation of CGI was created called FastCGI. Figure 1.2 shows the request flow in FastCGI.

Figure 1.2: FastCGI request flow.

The primary difference between CGI and FastCGI is the creation of persistent processes in which the CGI application executes. By using persistent processes, the Web server doesn't have to expend processor time and memory constantly creating and destroying processes. The success of FastCGI led to the development of other products, like mod_perl and PerlEx, to address performance and interface issues.

The overall success of CGI was dependent on the fact that most Web servers on the market supported its use. This included open-source servers, such as Apache; Internet Information Services (IIS) from Microsoft; and iPlanet from Netscape. However, at the same time these Web servers started experimenting with newer technologies like Active Server Pages (ASP) and Server-Side JavaScript (SSJS).

Both ASP and SSJS solutions to the problem of dynamic Web pages employ the concept of embedding code into the HTML page where dynamic content is needed. ASP, for example, uses JScript or VBScript. Figure 1.3 shows the process flow for ASP and SSJS.

Figure 1.3: ASP/SSJS process flow.

As Figure 1.3 shows, a user requests an ASP page from a Web server that supports ASP, usually IIS. The page is pulled into the Web server and processed.

The processing involves executing the ASP or SSJS code within the server and replacing the code with HTML tags and content. The resulting static page is sent to the browser.

One of my core beliefs is that all programming languages—both conventional and Internet based—should be compared with each other only when we're discussing a specific solution. Is Java better than Cobol? Well, for some applications clearly it is, but in some business situations, fancy GUIs and RMI just aren't needed. The same is true for things like ASP and servlets. Therefore, at this point, let's move to a discussion of JSP, servlets, and beans, which entered the scene after ASP and SSJS.

In the hierarchy of power, the JavaServer Pages (JSP) technology probably comes next. JSP pages are similar to both ASP and SSJS in that code is embedded in the HTML of a Web page. However, JSP isn't designed to be specific to one Web server. As long as a Web server can interpret the Java code embedded in the Web page, it will be able to handle JSP pages. Some of the real power in JSP comes from its ability to interact with JavaBeans. Beans are modular pieces of Java code designed to perform a specific job. Beans can be referenced from JSP pages and automatically instantiated on the server machine.

Finally, we have servlets. A servlet is an extension to a Web server written as a class that will be instantiated to provide additional functionality to the server. Figure 1.4 shows the process flow for a Web page that utilizes servlets.

Figure 1.4: Servlet processing.

When a Web page that includes calls to a servlet is requested by a browser, the HTML is processed by the Web server and the servlet calls are farmed to a servlet engine. The servlet engine will instantiate the servlet code, process the request, and return any results to the Web server. Servlets are powerful because they:

• Remain in memory after the first instantiation.

• Are portable to any platform that can execute Java.

• Have access to the full power of the Java language and its supporting classes.

You can use servlets for database access, distributed access using Remote Management Interface (RMI) or Common Object Request Broker Architecture (CORBA), and a host of other operations.

In the remainder of this chapter, we cover the Resin server product family and take a more in-depth look at the features provided by the servers.