The latest version of IBM's WebFacing technology, which is now part of Rational Host Access Transformation Services (HATS), has a new feature called the WebFacing Application Bridge (for HATS licensing information, see "Repackaging and Licensing Updates for WebFacing 7.1" below). We quickly review the capabilities of WebFacing before introducing this new feature and describing a method for using it to request a service from a web service.

The WebFacing tool lets you create web front ends for existing 5250 applications. These applications, written using DDS to define their screens, need not be modified as you web-enable them. The WebFacing tool reads the screen specifications up front to create corresponding web page fragments. It then creates a web application that launches the original application from a browser. The WebFacing infrastructure does not require that a 5250 data stream be generated by the application's screens. Instead, the application data is intercepted and fed into the web page fragments as the original application runs, and the page fragments are assembled for display. In addition, the host application does not consume 5250 cycles when running under WebFacing (see "Running on i5/OS Integrated Web Application Server," below).

Application Bridge

The Application Bridge enables WebFacing applications to connect and exchange data with other web applications. You can exploit the technology in several ways. For example, you can connect reengineered parts of your application with the rest of the interactive application as you transition to a modern application architecture by creating your own web interface to the refactored business logic now encapsulated in batch programs, or by connecting your WebFacing applications to Enterprise Generation Language (EGL) applications. Here, we describe a simple way to use the Application Bridge in a WebFacing application to request a service from a web service, hence enhancing the WebFacing application's capability.

Let's examine a real-life scenario. Employees at your bookstore, which is part of a chain of bookstores, use an in-house i5/OS application that looks up books available in the store. You have used WebFacing to web-enable this application and give it a graphical user interface, but to further modernize the application and leverage other web capabilities at your fingertips, you would like to add a new web function that lets employees search the application to find the nearest chain store that has a copy of a book that is out of stock in your store.

The logic for this complex search function need not be added to the i5/OS application. Instead, the web-enabled application will connect to a web service that can do the necessary lookup and return the store data to the application.

A new DDS record is used to exchange data between your WebFacing application and a new web application that invokes the web service. This record is called the "linkage record" because it serves as the interface between WebFacing and the web application and carries data you want to exchange between the two. The Application Bridge Web Setting tags the DDS record as a linkage record. (WebFacing provides Web Settings as one of the customization options to let you specify how your application renders and functions when accessed from a web browser.)

Since the data in the linkage record is not intended for display, all the fields must be defined as hidden (usage H). In addition, the Application Bridge Web Setting lets you specify the web address (or URL) that your WebFacing application should forward to. At runtime, when the host application on the System i writes this record of data, it triggers WebFacing runtime to forward data and control to the web application using the URL provided on the Application Bridge Web Setting. The receiving web application does the necessary processing and returns control to WebFacing with data updates. WebFacing then returns the data to the host application.

Back to our scenario . . . the WebFacing application provides the book's International Standard Book Number (ISBN) and your store's location zip code to the web application. The web application returns the ID of the nearest store that has a copy of the book. The linkage record therefore contains three fields: ISBN, location zip code, and store ID. In our example, the web application context root is SampleWebApp, and the entry point is a servlet named RetrieveStoreID. So, the URL to this web application is /SampleWebApp/RetrieveStoreID, which is saved as a special Web Setting annotation in the linkage record and used by WebFacing to pass data and control to the web application. The WebFacing application URL is /SampleWFApp/webfacing/WebFacing.do. The web application will use this information to return the data and control back to WebFacing.

The following steps detail how to set up and use the Application Bridge between the WebFacing application and the new web application.

Step 1: Create a new DDS linkage record. First, create a new DDS linkage record that contains the ISBN, zip code, and store ID. Figure 1 shows the Application Bridge Web Setting specified for this record and the target application URL being /SampleWebApp/RetrieveStoreID.

Step 2: Update the host application to write and read the linkage record. Next, update the host application to write this linkage record. At runtime, when the record is written, WebFacing will transfer data in the linkage record and control to the web application using the Java EE (formerly known as J2EE) forward method. The write operation in the host application should be followed by a read of this record so the host application can receive the updated data.

Step 3: Consume linkage data in the web application. When the web application receives control, it detects that the request was forwarded from WebFacing because, prior to forwarding, WebFacing adds a request attribute "forwarded" with the value "WF" in the request object. The web application can access the linkage data sent from WebFacing via a request attribute called "LinkageData". The linkage data is saved in a Java HashMap with the DDS field name as the key and its value as the value for the associated key. Field values contain Unicode string data. Figure 2 shows how to retrieve the linkage data sent from WebFacing.

Step 4: Return data and control to WebFacing. After the web application processes the data and resolves the store ID for the nearest chain store that has a copy of the book, the web application updates the "STOREID" field in the HashMap and sends the HashMap back to WebFacing via the "LinkageData" request attribute. Before forwarding the request to WebFacing, the web application adds the request attribute "forwarded" in the request object. The value for this attribute is "EGL" for a request forwarded from an EGL web application or "CUSTOM" for a request forwarded from other web applications. Figure 3 shows how the linkage data is updated and returned to the WebFacing application.

Step 5: Update the WebFacing application to display the new information. Upon receiving the linkage data, WebFacing returns the data to the host application, which processes the store ID and returns the store's location. You can update your WebFacing applications to display this new information.

Moving Forward

This is just a taste of what the Application Bridge offers. Feel free to explore it and extend your existing applications to take advantage of the latest web technologies. Watch for future articles on the WebFacing Application Bridge. For detailed information about this feature, check out the documentation in the product and online (publib.boulder.ibm.com/infocenter/hatshelp/v71/index.jsp). To try out a hands-on tutorial, visit Rational Host Access Transformation Services on the IBM Education Assistant website (ibm.com/software/info/education/assistant).

Jiayun Zhu is a staff software engineer at the IBM Toronto Laboratory. She is the technical lead for IBM's WebFacing tool, which she has worked on since 2000.

Satish Gungabeesoon is the architect for System i application tools in IBM's Rational software division and the inventor and architect behind IBM's WebFacing technology. He has a degree in electronic engineering from the University of Wales and works at the IBM Toronto Laboratory. Satish has held technical leadership and management positions for WebFacing technology development and is a speaker at conferences.

Repackaging and Licensing Updates for WebFacing 7.1

Before V7.1, WebFacing was part of WebSphere Development Studio client (WDSc). In V7.1, as a result of repackaging, WebFacing is available as an optionally installable feature of Rational Host Access Transformation Services (HATS). Also, you need a HATS V7.1 license instead of the WebFacing Deployment Tool for WebSphere Development Studio with HATS technology (WDHT) V7.0 license to enable the runtime environment for WebFacing V7.1.

— J.Z. and S.G.

Running on i5/OS Integrated Web Application Server

You can deploy WebFacing applications on the i5/OS integrated web application server when you have limited i5/OS system resources that cannot optimally run WebSphere Application Server (WAS). However, this configuration does not support the high availability and failover features that WebFacing provides when it is deployed to WAS Network Deployment.

— J.Z. and S.G.