Basic Concepts Behind the WebFacing Tool

Before you use the WebFacing Tool, I want to explore some of the basic WebFacing concepts. In a nutshell , the tool converts a 5250 user interface application to a Web application. The following sections look at the components of a Web application.

Concept of a Web Application

A Web application is ideally split into three distinct parts :

1. The user interface

2. The controller logic

3. The business model

For a Web application the user interface displays in a browser and is described in HTML tag language. In many cases, additional Java script logic executes in the browser, to enhance the user interface, since the basic HTML tag language can produce only a very rudimentary user interface.

The controller logic for the Web application is written in Java and runs on an application server. The controller logic determines which user interface components (Web pages) to display and what business logic to run depending on requests and input from the end user on the browser.

The business logic can run on any server platform and can be implemented in any programming language. In an iSeries shop the platform normally is an iSeries server and the programming language is RPG or COBOL,

Figure 1.2 shows a typical three- tier Web application environment.

Figure 1.2: Graphical representation of a three-tiered Web application

The WebFacing Tool converts the green-screen user interface to a Web user interface. With this conversion, the original green-screen application runs as a Web application. The controller logic normally implemented in a servlet, which essentially decides which page is shown next , still resides in the original application. Therefore, the application is not a "true" Web application even though it behaves like one. Actually, the WebFacing run time is a servlet that acts as intermediary between the application and the user interface.

WebFacing Conversion

To change the green-screen user interface of a host application into a Web application, the WebFacing Tool has to convert the DDS user interface description to an HTML user interface description. The browser then understands how to display the HTML tags and the data included from the application. Part of the WebFacing conversion process is the selection of the DDS source members that make up the application's user interface.

To reflect the dynamic nature of the 5250 user interface, the Web user interface description must be capable of supporting changes at run time. For example, output fields have to be able to add data at run time. Plain HTML does not support dynamic content, but JavaServer Pages do. JSP files consist of HTML tags that define the static content, and Java code for the dynamic pieces of the user interface. When a JSP file is requested , the Java code in the JSP file runs on the server, resulting in dynamic content of the page. The file is then sent as pure HTML to the browser and rendered as a Web page.

The WebFacing Tool needs another piece of information to be able to work in the Web environment. How is your application invoked in the 5250 environment? The command that invokes the application must be specified. The WebFacing Tool creates an index.html page that contains a link. Selecting this link from the index page will invoke routines in the WebFacing server and start the application on the iSeries host.

As you will see later on, you need to specify only a few things before you convert your application with the WebFacing Tool.

During conversion, the WebFacing Tool accesses the specified DDS source and creates the corresponding JSP files, and several other files, from your DDS source members. It places these files onto your workstation. Since the WebFacing Tool is a plug-in to the WebSphere Studio workbench, the information is stored in the workbench workspace. To specify the WebFacing work environment, you create a WebFacing project in the workbench before you start the conversion.

WebFacing Run Time

Now that I have explained what you have to do to convert your 5250 user interface, I will explain more about the WebFacing run-time environment.

The goal of WebFacing is to provide a more attractive user interface for an existing application without impacting its logic. Ideally, you should not need to touch the logic of your RPG, COBOL, CL, C, or C++ programs. Let's look at how the programs work today with their text-based user interface.

In your iSeries programs you use a workstation file to indicate that you want to display data in a user interface. The workstation files contain record formats, which describe the data buffer layout of your user interface. Essentially, all dynamic content of your user interface is described through the record formats, and at run time the data inside the record format is passed from the program to the user interface and vice versa. The data buffer definition in the record formats is the interface between your program logic and the user interface. In your programs, you communicate with the workstation file by writing the buffers when you display a screen and reading the buffers when you receive input from the user interface.

The requests to the workstation file are handled by the iSeries workstation manager, which takes the data in the buffer and surrounds it with 5250 control characters . It does this according to the DDS user interface description you provided for the record format and that is stored in a display file. The complete 5250 data stream with user interface definitions and data is sent to the 5250 terminal, which renders the 5250 data stream and displays the user interface parts with the data.

Figure 1.3 shows this process.

Figure 1.3: Interactive model

For a WebFaced application, this picture changes. The device that renders the user interface is a browser. The browser is sending requests to a Web server instead of a 5250 terminal that is directly connected to a workstation controller on an iSeries server.

The program itself still communicates with a workstation file, but the iSeries workstation manager itself is enhanced for the WebFacing environment. This change in the iSeries workstation manager has to be installed with a PTF. Please visit the WebFacing Web page for the latest PTF numbers for your specific iSeries OS/400 release.

The workstation manager enhancement enables it to sense whether an application is connected to a 5250 device or to the WebFacing server. If the application is invoked via the WebFacing server, the workstation manager does not create the 5250 data stream around the data it receives from the programs. Instead, it passes this data directly to the WebFacing server. The WebFacing server hands the data over to the WebFacing run time, which is implemented as a servlet and runs on the IBM WebSphere application server.

The WebFacing run time receives the workstation file data from the program in a data buffer. The WebFacing runtime also receives information on which record format to display. From this information, the run time invokes the corresponding JSP, created during the WebFacing conversion process. The JSP takes the data from the data buffer and inserts it into the user interface description from the conversion. The resulting HTML data stream, which now includes the data as well as the user interface description, is sent to the browser. The browser then renders the data stream and displays the data as a Web page.

Figure 1.4 shows the changed iSeries workstation environment for WebFaced applications.

Figure 1.4: WebFacing model

Figure 1.5 shows the individual steps in the flow of a WebFaced application invocation.

Figure 1.5: How it all works

1. The end user requests the index.html page created by the WebFacing conversion.

2. The end user clicks on the generated HTML link on the page to invoke the application he or she wants to run.

3. The request is send to the Web server and invokes the WebFacing run time. (The WebFacing run time is published to the server as part of the WebFacing project.)

4. The WebFacing run time connects to the specified iSeries host, and the WebFacing server receives the request. (I describe later how to start the server on the iSeries server.)

5. A job is created, and the command to invoke the application is run in that job.

6. The application writes a record format to the workstation file, and workstation manager handles this request.

7. The workstation manager passes the record format to the WebFacing server.

8. The WebFacing server sends the record format to the WebFacing run time.

9. The WebFacing run time invokes the JSP corresponding to the record format. The data from the program is included in the JSP.

10. The HTML stream including data is sent to the browser.

11. The browser renders the data stream and displays the Web page.

With this short introduction to the WebFacing development and run-time environment, you are ready to tackle basic WebFacing tasks . Before you try the exercises, however, I will explain how to install the sample Order Entry application on the iSeries host. You will use this sample application during most of the WebFacing exercises. After the iSeries application installation, I explain how to install the WebFacing Tool. Because the WebFacing Tool is not a stand-alone tool, I will tell you how to install Development Studio Client on your workstation. If you have already installed Development Studio Client, you can skip that section.