In this chapter:
As we described in Part I, the KanDoIT company wants to provide an enhanced service for its customers. The aim is to provide new pages in the KanDoIT web site that allow clients to check their accounts online, using a browser. The web pages presented to customers must comply with existing corporate style guidelines and be easy to maintain without any need to change application code. The solution will connect to the existing business logic component, access customer data and return a dynamically generated web page without the user ever knowing that CICS is performing the data processing behind the scenes.
This Part builds on Part III, and essentially covers the implemention of a CORBA client in a web server environment. The sample application presented here to meet these requirements is quite simple in its design and it does not address the complex issues of security.
For the web component we describe how to create the HTML pages by which customers can make requests, how to write a Java servlet to handle requests and retrieve data from CICS using CORBA, and how to create dynamically generated web pages using Java Server Pages (JSP) and JavaBeans. The design is typical for a web application, in that it follows the three-tier model, or perhaps more accurately, the n-tier model.
In this model, the user interface, the business logic, and the backend data management processes are separated by platform. Figure 8-1 shows the overall design.
The Java component, which wrappers the COBOL program on CICS, is described in Chapter 7.
For the KanDoIT users, customers with web access, the web component needs to provide:
An input form into which customers can enter their account number and password
An output screen to display the customer’s account details
This is the presentation layer for the component; the customer submits the input form and views the account details on their web browser. The design of the presentation layer is described in more detail in the next section, Designing the Web Interface.
Between the user submitting a request with their input parameters, and receiving output (of their account details) in their browser, there must be some processing to generate a response. The input parameters must be checked for validity, and then passed on to the CICS application to retrieve the appropriate customer data from its database. Then, using that data, a new web page is generated and returned to the user.
A web server (a server connected to the Internet, dedicated to serving web pages) is typically used to deliver static web pages in response to users requesting HTML documents via HTTP from their web browsers. However, the web server could also return the output of a program, which in this case we want to be the data returned by the CICS application. In our example, the web server provides the following services:
Listens for an HTTP request for account details, issued by the user’s web browser.
Invokes a program to connect to and request data from the CICS application.
Formats the data returned from the CICS application into HTML.
Returns the HTML document to the user’s web browser.
The design of the data processing logic is described in more detail in Designing the Web Server Components later in this chapter.