In this article, we will explore the role and strategy of WebFacing Tool, IBM’s latest application development tool for iSeries and AS/400 programmers. A follow-up article will offer a more technical, hands-on tutorial introduction to the actual use of IBM’s WebFacing Tool.

WebFacing and the Application Development Strategy

On May 25, 2001, when V5R1 was made generally available, the world of application development for the iSeries platform changed forever. If you missed it, there is now only one product, WebSphere Development Studio (WDS), for application development (for both V5R1 and V4R5). It contains all priced compilers (RPG, COBOL, C, and C++), all green-screen tools (Application Development ToolSet/400), and unlimited licenses to a package of client tools known as WebSphere Development Tools (WDT) for iSeries. For software subscription customers, this new product is a free upgrade from any of the constituent products. For the rest, or for new boxes, it is a delta to the historical price of ADTS plus RPG. Either way, the key is this: You can’t not get it. WDS is the new base for all application development work on the iSeries—and if you are not yet at V4R5 or V5R1, well, it’s time to get on with it!

Even though the compiler changes in V5R1 are extensive and exciting, it is the client tools that are catching people’s interest.

These tools are a packaging of the key Windows-based tools for iSeries development, for everything from traditional green-screen to modern e-business applications. The tools include the following:

• CODE/400—This is the modern-day follow-on to SEU, SDA, RLU, PDM, and the system debugger.

• VisualAge for RPG—This tool is used for writing Windows client/server GUI applications easily with RPG.

• VisualAge for Java, Professional Edition, with Enterprise Toolkit for iSeries—This tool is for writing all manner of Java code, except for Enterprise JavaBeans, which require an upgrade to the Enterprise Edition of VisualAge for Java.

• WebSphere Studio, Professional Edition, with iSeries Extensions—This tool is needed for authoring new Web browser user interfaces that run inside WebSphere Application Server.

• WebFacing Tool—This tool is the new kid on the block and the focus of this article.

With this set of products, you now have everything you need to write modern applications with a modern user interface. Whether you ease into them or dive headlong is your call.

IBM’s essential strategy is to modernize your application development tools, your applications, and most importantly, your application user interfaces. IBM wants more Web browser-based applications running in WebSphere Application Server. These tools are part of that strategy.

To create a Web browser user interface, IBM gives you WebSphere Studio, with some exciting iSeries extensions for easily generating all the WebSphere plumbing between your user interface and your modular batch RPG or COBOL business logic. This is a fantastic option if your green-screen logic is divorced from your business logic and your business logic is easily accessible using discreet APIs. Many of you are not there, but we encourage you to consider this your long-term goal.

In the meantime, if you have a large interactive application that is not easily rearchitected with a divorce between the display file I/O and the business logic, IBM offers WebFacing. This is what we call the “one-two punch.” IBM gives you great tools for new applications and another quick-fix tool to help you deal with existing applications. The idea is that this will buy you time with your customers, users, or executives while work begins on the next generation of your application. What if you like WebFacing enough to just stay with it? Well, that is your call, too!

What Is WebFacing?

We are often asked how WebFacing compares with 5250 intercept products that convert a 5250 data stream to something else on the fly. Many assume that this is what WebFacing does. It is not. There is no 5250 data stream translation involved with a WebFaced application. There is no 5250 data stream, in fact.

WebFacing is a different approach to the problem of re-facing an application. WebFacing is a developer’s tool; it is a combination of a development-time, display-file source conversion and a runtime intercept deep in the operating system. You convert your user interface source, and with the runtime intercept, your existing application code runs as is, still thinking that it is driving the original display files when, in fact, it is driving the Web user interface, created by the conversion tool at development time. Before dissecting the benefits (and dis-advantages) of this approach, we’ll dig a little deeper into the process.

First, we’ll review briefly what happens today when you interact with a display file from a high-level program. The write operations send a buffer of data to the workstation data manager, which merges that data with the record format in the display file to produce a 5250 data stream. The read operations cause the workstation data manager to return to your program all user input data, in the form of an input buffer, and event information, in the form of a feedback buffer. The read operation causes your code to block until the user presses Enter or a function key. A noteworthy feature is that the program starts the user- interface interaction by writing that first screen. In a sense, the program drives the user interface.

In a WebSphere application, you have a different architecture but with some similarities. First, the user starts the interaction by calling up a Web page, so it is the user interface that drives the program, not the other way around. A Web page is defined as a JavaServer Page (JSP) file, which is simply an HTML file with embedded JSP tags. The

HTML tags define the constant part of the page, while, at runtime, during an output operation, the JSP tags are used to extract the runtime data out of a JavaBean. Note that this is a simple JavaBean, not an Enterprise JavaBean. A JSP is called from a servlet, which is a small Java program that manages the flow of the JSPs. The servlet will put the data into the JavaBean and pass it to the JSP. Your user typically calls your servlet first, which then calls the initial JSP, resulting in the first page. All input fields in a JSP are captured in standard HTML forms, which contain various input widgets, such as entry fields and radio buttons. Each form is associated with a server-side program, such as a servlet, that is called when the user presses the Submit button. Each form has one Submit button, which is therefore very similar to the Enter key. In addition, a form can have other buttons that can be coded to call the servlet, similar to the function keys in a display file. When a servlet is called from a form, it reads the input entered into the form by the user and uses it to populate a JavaBean. The servlet then calls business logic to do the requested task, passing in the user data. The business logic returns new data, which is put into that same Bean. The servlet decides which JSP to show next and calls it, passing in the JavaBean for the runtime data. This is the basic flow of a simple Web application, and this is the architecture that WebFacing generates for you, for the Web user interface graft onto your interactive application.

Now we can discuss in more detail how WebFacing maps the old world onto the new world. The WebFacing Tool is a Windows-based integrated development environment (IDE) for creating WebFacing projects. This IDE contains a wizard for identifying the input information, such as the display file DDS source members, and a project action for converting or reconverting that DDS source into a Web user interface. The conversion generates the following for each record format:

• Two JavaServer Pages—One page contains the user interface format and one contains purely JavaScript routines to be passed to the Web browser for light editing and dynamic display formatting.

• Three JavaBeans—One JavaBean is for the input and output fields, another is for the device file feedback information (such as function key pressed and cursor row/column position), and the last is for the view information, such as indicator settings.

• One Cascading Style Sheet—This is for all the files converted in this project. By changing this style sheet, you can affect all the JSPs in your application.

• One index.html file—This file acts as the front door to your application. Users typically start with it, and it has a link that starts your application by calling the WebFacing servlet.

You then use another action in the IDE to publish these output files to WebSphere Application Server along with the WebFacing servlet. This publishing can target WebSphere Application Server on iSeries or, indeed, any WebSphere Application Server. For example, you many choose to test with WebSphere Application Server on Windows first, or with the WebSphere Application Server that comes built into VisualAge for Java (for testing and debugging).

The WebFacing runtime is a piece of code running on the iSeries. It is the heart of the magic. The servlet communicates with it through Sockets calls, and the runtime, in turn, communicates with the WorkStation Data Manager. To see what happens when you run your WebFaced application, relate the numbered items in Figure 1 with those in the following list:

1. The user presses the generated link to start the application.
a. If the user has not signed on yet, a sign-on prompt will be displayed.

2. The WebFacing servlet gets control and calls the WebFacing runtime.

3. The WebFacing runtime spawns a thread for this user, then starts an AS/400 job. It either uses a hard-coded user ID and password or tells the WebFacing servlet to prompt the user for these. (This is a decision you made at conversion time.)

4. The runtime tells WorkStation Data Manager that you are in WebFacing mode.

5. The runtime calls your application (using the CL command and parameters you specified at conversion time), which starts running.

6. Your application does a number of write operations to the display file, followed by a read operation.

7. The WorkStation Data Manager, knowing that you are in WebFacing mode, simply passes the application data directly to the WebFacing runtime.

8. WebFacing runtime passes the application data to the WebFacing servlet, which is waiting on a Socket.

9. The WebFacing servlet puts the application data into the generated JavaBean for this record format.
a. The WebFacing servlet then passes the two JavaBeans to the generated JavaServer page for this record format.

10. The JSPs associated with the RPG program’s write operation are merged, then executed, to format the application data with HTML.

11. The user sees this as his next page. At this point, the RPG program is still blocked, waiting for the read operation to be completed.

12. The user enters data and presses Submit or a push button representing a function key.

13. The WebFacing servlet gets control again, reads the user input data, and passes it and the feedback information to the WebFacing runtime.

14. The runtime passes the data and feedback information to the WorkStation Data Manager, which uses that information to respond to the RPG program as usual.

This continues until your application exits. The WebFacing servlet then recognizes the exit and cancels the WebSphere session. Of course, there are all those little details that have to be dealt with, like library lists, break messages, user time-outs, and the browser Back button. We have done the worrying for you, including the biggest worry of all: subfiles!

Another wizard is part of the WebFacing Tool IDE (see Figure 2). This wizard helps you create your own style, or change the look and feel, for your Web pages. The converted screen is in the center of the page, but you are free to put what you want in each edge—making it easy to add corporate logos, for example. Use the wizard to customize the colors and fonts of the application area and to position the function key buttons. The wizard makes it reasonably easy to generate new styles, but to get you going, the WebFacing Tool comes with a number of predefined styles to choose from. Enterprising Business Partners might want to consider marketing additional styles as well.

Why Use WebFacing?

The advantages to WebFacing over the traditional approach of converting the 5250 data stream on the fly are twofold. First, the conversion is done at development time, so you are free to change the output that is generated. The JSPs and JavaBeans are industry standards, and there are several tools for editing them, including WebSphere Studio, which ships with WebSphere Development Tools for AS/400. The key is that you make all your changes at development time on source code, as opposed to writing runtime macros. The second advantage is that there is no 5250 data stream created simply for the purpose of subsequently translating it to something else again at runtime. This provides an opportunity for better performance.

Editing output sounds great, but be cautious. Once you change what WebFacing generates, it will be your responsibility to merge your changes back in after a subsequent regeneration. (WebFacing backs up your changed file first.) Future releases will offer merge tools, but, in the meantime, you are on your own. To minimize the need for this, you can tailor the output before the conversion. The CODE Designer tool is the SDA follow-on inside CODE/400. If you use it for your display file DDS source, you will find that there is a properties dialog for fields where you can specify properties that pertain only to the conversion code. For example, you can elect to hide a file from the generated Web page, even though it will still show up in the green-screen. You can also insert any HTML you like into your green-screen, such as a little image beside each menu item. Again, this does not affect the green-screen, as WebFacing stores these properties as DDS comments. You can even have a field be rendered as an image, where the name of the image file is deduced from the value of the field at runtime. For many, this capability, along with the style support, will be sufficient to get a good-looking Web page that the boss will like. However, remember that if it is not sufficient, you have all the generated code at your disposal, and you are free to do what you want with it. At the extreme, you may even decide to alter your RPG code to optimize the screen flow for the Web. To help you do this, IBM offers an API, to query whether you are running on the Web or as a green- screen. Doing this type of surgery today is a bit tricky, though. IBM will make it much easier in future releases.

A final advantage to WebFacing, is that it is cost-effective. The tool is part of WDT, which eventually everyone will have. The AS/400 runtime is an OS/400 PTF.

Why Not Use WebFacing?

To use WebFacing, you must WebFace the entire application. You cannot switch between Web and green-screen randomly. Not all screens can be converted yet. For example, we don’t handle User Interface Manager yet, hence operating system screens. In fact, the GA product for V5R1 does not handle all DDS keywords yet. IBM prioritized them, based on scanning the source of 120 Business Partner applications, so there should be enough coverage for what you use (the conversion report will tell you). If not, IBM’s Web site will offer frequent updates to the tool and the conversion throughout the release cycle; watch it carefully. (The following URL will get you there by way of links: www.ibm.com/software/ad/wdt400.)

WebFaced applications run only on OS/400 V4R5 or higher, and they require that both HTTP Server and WebSphere Application Server, Standard Edition, Version 3.5.2 or higher, be installed, configured, and running.

Something for Everyone

WebFacing is a new option for you to convert your green-screen applications into Web- enabled applications quickly, easily, and cheaply, and with a number of options for refining the resulting output. We think that, for many, it will be just perfect—in fact, that is the response we are hearing. For others, it will take a little more evolution before it fits their bill. Still others will choose to simply install and turn on a 5250 intercept product to easily

Web-enable every screen of every application (assuming they like the output). Yet others are digging in and aggressively rewriting and redesigning their applications as native Web applications. This is all good. The only wrong thing to do is nothing! As a side note, we should point out that WebFaced applications still count as interactive applications and therefore still require the interactive feature. In a future article, we will go through the tools and show you a little more of the mechanics of actually doing a WebFacing conversion.

Index.html

Sign-on

Prompt

Application Pages
WebSphere Application

Server WebFacing Job User Job

1

Feedback JavaBean Data JavaBean

13

WebFacing Runtime WorkStation Data Manager

13

2

8

3

4

WebFacing

Servlet

13

14

5

1a

12

11

9

7

9

6

9a

Figure 1: The WebFacing Tool allows Web-browsing users to access legacy applications through a combination of JSP and servlets.

*PGM

View JavaBean

JSP JavaScript

JSP

UI

10

10

CSS

Figure 2: A WebFacing Tool wizard lets you customize the look and feel of your DDS screen.