The web server’s job is to listen for requests for account details, validate input parameters, connect to CICS, pass on the request to the CICS application, format the returned data into HTML and return a web page to the user’s browser. All of these tasks can be handled by a special type of program running in the web server environment called a servlet.
In Chapter 9, we can divide the specific tasks further among three distinct components:
A Java servlet to process the request and connect to CICS
A JavaBean to temporarily hold information about the customer
Java Server Pages (JSP) to automatically format the returned data into HTML
Let’s look at these web server components in more detail.
The Common Gateway Interface (CGI) was one of the first practical techniques for creating dynamic content. With CGI, a web server can forward HTTP requests to an external program. The output of this program is then returned to the client browser. CGI is more-or-less platform-independent and is very popular. However, CGI has many drawbacks that affect web application performance and it is particularly resource-intensive. There are several proprietary solutions that work only on certain web servers, such as server extension APIs, Active Server Pages, and server-side JavaScript. These are by no means perfect solutions, as they can be difficult to develop, increase the risk of crashing the web server, or they work in very specific environments.
A servlet is a Java program (class) that runs on a web server. It can be loaded dynamically to expand the function of a server. Servlets are commonly used in web servers to replace CGI scripts. A servlet is similar to a proprietary server extension, except it runs inside a Java Virtual Machine (JVM) on the server, so it is safe and portable.
Unlike CGI, which uses multiple processes to handle separate programs and/or separate requests, servlets are all handled by separate threads within the web server process. This means servlets are efficient and scalable. Another advantage is portability: Java runs anywhere there is a JVM and all major web servers support servlets. Because servlets are written in Java, they give you access to all the benefits that the Java language provides, namely networking and URL access, multithreading, image manipulation, data compression, database connectivity, remote method invocation (RMI), CORBA connectivity, and object serialization, among others.
Servlets inherit the strong type safety of the Java language and, because Java doesn’t use pointers, servlets are generally safe from memory management problems. Servlets handle errors safely using exception processing, which won’t crash the server.
Servlet code is clean, object-oriented, modular, and quite simple. Servlets can take advantage of a huge library of third-party Java classes and JavaBean components, including new Enterprise JavaBeans.
For the purposes of our example web application, the servlet we will develop performs the following functions:
Checks that the account number and password parameters entered by the user are in a valid format.
Instantiates a JavaBean to store the parameters and the details that are received from CICS.
Invokes a method on a remote Java Account object running in CICS, using IIOP.
Returns the appropriate Java Server Page (JSP) to the browser.
The servlet is automatically invoked whenever a request for this specific servlet is received from a web browser. The request is initiated when a customer submits the View Account page by clicking on the Request button.
A JavaBean, often referred to simply as a bean, is a reusable Java component built using Sun’s JavaBeans technology. In our sample application, our JavaBean is called AccountBean. The purpose of AccountBean is to store the details of the customer account returned from the call to the Account object in CICS. So, for example, it contains first name, last name, telephone number, account balance, and so on. This information is then used by the JSP to build the HTML that is returned to the user’s web browser.
Java Server Pages (JSP files) technology is a convenient way to generate dynamic page content. JSP files allow the application server to dynamically add content to your HTML pages before they are sent to a requesting browser. The dynamic content can come from any available databases and file systems to provide web visitors with timely and accurate data.
The JSP files created by the WebSphere Studio wizards contain the following HTML tags and JSP tags defined by the JSP specification. This allows us to retrieve data directly from JavaBeans:
- A JSP <BEAN> tag
To access a JavaBean when the page is processed
- JSP <INSERT> tags
To embed variables in the page
- HTML tags
To format the variable data
- JSP <REPEAT> tags
To repeat a block of HTML tagging that contains <INSERT> tags and the HTML formatting tags
When the Application Server processes the JSP file, it:
Instantiates the JavaBean
Puts the resulting data into the output page (replacing the special tags)
Returns it as an HTML file
You can customize the JSP file, adding your own text and images using JavaScript, HTML, or JSP tagging. These tags and script are included in the HTML file created by the application server and returned to the requesting browser.
For our sample, we make use of the account details stored in our AccountBean JavaBean. As an example, if we want to include the account number property in the HTML output we would include a tag similar to this in the account details JSP file:
<INSERT BEAN="KanDoItServlet" PROPERTY="accountnum"></INSERT>
For more information, see Creating the Java Server Page File in Chapter 9.
There are many ways the web component could have been designed. So why have we done it this way? There are several compelling reasons:
By using a servlet rather than an applet, we are ensuring that any customer with web access can use the component, regardless of what web browser they are using.
Servlets produce better performance than CGI programs performing a similar function.
Because the servlet and JSPs run on the web server we can upgrade or even completely change function and presentation of data without any dependency on user’s client software.
Using CORBA (see below) we can communicate directly with our account object running in the CICS server over a TCP/IP network.
CORBA is both cross-platform and cross-language—we’ve implemented our CORBA client in Java so we can invoke it directly within our servlet.
The servlet could have included code to perform HTML conversion, but it would then be doing two jobs: processing and presentation. If you later wished to change the way in which data was presented in the web browser, you would have to change the servlet and recompile it. By using JSP to generate the HTML, and inserting placeholders for any dynamic data, the presentation logic is kept apart from the processing logic and it is easier to maintain and update.