Using CGI for dynamic Web pages

One way to provide dynamic Web pages is through the Common Gateway Interface (CGI), which is part of the HTTP protocol. CGI is a standard way for a Web server to pass a Web user's HTTP request to an application. CGI generates the output and passes it back to HTTP Server, which sends it back to the user in an HTTP response (Figure 1).

CGI is not limited to returning only HTML pages; the application can also create plain text documents, XML documents, pictures, PDF documents, and so on. The mime type must reflect the content of the HTTP response.

CGI has one major disadvantage, which is that each HTTP request requires a separate address space. This causes a lack of efficiency when there are many requests at a time.

To avoid this problem, FastCGI was created. Basically, the HTTP Server FastCGI plug-in is a program that manages multiple CGI requests in a single address space, which saves many program instructions for each request. More information about HTTP Server plug-ins is provided in Using the plug-in interface.

Figure 1. How the CGI works

Using the plug-in interface

Another way of providing dynamic content is by using the plug-in interface of HTTP Server, which allows one of several products to interface with HTTP Server. Here, for example, are some ways in which HTTP Server can pass control to WebSphere®;

• WebSphere plug-in, same address space

  Figure 2 shows a simple configuration in which no J2EE server is needed. This servlet can connect to CICS® or IMS™, or to DB2® through JDBC. However, coding business logic inside servlets is not recommended. For more information about the architectural characteristics that are associated with Web-based DB2 applications, see http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.intro/db2z_architectureofwebapplications.htm

Figure 2. Accessing servlets using the WebSphere plug-in

• Web container inside HTTP Server, separate EJB container

  Figure 3 shows a more usable configuration in which the servlets run in a different address space than the EJBs, so the EJBs are invoked from remote calls. The EJBs then get information from other servers.

Figure 3. Accessing EJBs from a WebSphere plug-in

• Separate J2EE server with both Web container and EJB container

  In addition to running your servlets locally within the WebSphere plug-in, you can also use the WebSphere plug-in to run servlets remotely in a Web container, as shown in Figure 4. This allows you to localize your servlets and EJBs to the same z/OS address space, so that no remote EJB calls are required.

Figure 4. Accessing servlets in a Web container using the WebSphere plug-in

If you are using WebSphere Application Server, HTTP Server might not be needed, yet there are several ways in which HTTP Server can interact with WebSphere Application Server.