WebFacing

Many ISVs have started migrating their RPG/iSeries applications into the web-based architecture.  The first step involved in this transition is always the conversion of the presentation layer of existing applications from RPG/System i (IBM iSeries/AS400) into a web-based interface while maintaining the core business logic and DB I/O in RPG.  This document gives an overview of the classic iSeries programming model, discusses the various options available for web-enabling the current iSeries/RPG applications and focuses on WebFacing – one of the technology approaches for web-enabling iSeries applications.

In the classic iSeries program model, the application performs READs and Writes to the terminal workstation.  The workstation data manager merges the application data with the display file and generates a 5250 data stream that is sent to the display.  The following figure shows the data flow in an RPG application in the iSeries programming model using RPG:

 

In this model, there is typically one model object and multiple views on that object.  Presentation logic typically goes in the view and business logic goes in the model. 

The following are some of the available options for converting green-screens into a web-based architecture:

 

Host Access Transformation

There are several third-party solutions available that dynamically convert the green-screens into a web-based UI during runtime.  These solutions are based on a screen-scraping architecture which interfaces directly with the 5250 data stream.  HATS and Host-On-Demand APIs from IBM are some of the sample solutions:

Pros:

• No changes required to RPG applications
• Easy to deploy

Cons:

• Licensing costs involved in implementing the solution
• Less flexibility in customizing the UI
• Not very scalable as each client requires a 5250 data stream

 

CGI Web Development Toolkit

CGIDev2 is a web development toolkit for iSeries that facilitates the development of web-based programs using RPG or COBOL.  The gateway interface is implemented using an RPG ILE service program that contains all of the procedures required to read input from a browser, generate and send the appropriate response back to the browser.

Pros:

• Avoids 5250 data streams and reduces the load on the system
• Better design in separating HTML templates from RPG/CGI
• Open Source

Cons:

• Doesn’t always scale well
• HTTP server and web application must be in the same tier and locks you into using iSeries as your webserver and backend.
• Requires good knowledge of RPG for extending it into the CGI framework

 

WebFacing

WebFacing is an IBM’s WebSphere based solution which provides a java-based connector framework for interfacing with iSeries programs.  WebFacing helps iSeries programmers to web-enable RPG applications using java.  WebFacing converts RPG display files to JSPs and JavaBeans, which in turn access the core business logic residing in RPG/System i.  This conversion allows host application to act as a web application.

Pros:

• Minimal changes to underlying RPG applications
• Better architecture using MVC design pattern with Struts framework
• Conversion done at development time making runtime faster
• Runtime is part of OS/400 and the tools are fully integrated with WebSphere Development Studio
• Highly Scalable

Cons:

• Requires DDS source files for RPG applications. If there are no DDS source files, it requires advanced edition with HATS support.
• Cannot change the screen to screen navigation.

 

Comparing the benefits and drawbacks of these solutions, an IBM WebSphere based solution using WebFacing tools provides a cost effective approach for converting the presentation layer of the current system into a web-based architecture. 

WebFacing is an IBM’s WebSphere based solution which provides a java-based connector framework for interfacing with iSeries programs.  WebFacing helps iSeries programmers to web-enable RPG applications using java.  The development toolkit allows conversion of RPG display source files to Web UI easily.  The application is converted during development time and thus increases the efficiency during runtime.  The following figure shows a typical e-business program model using MVC framework:

 

 

The e-business program model used in WebFacing architecture follows the Model-View-Controller paradigm, organizing the application into three separate components:

• Model: the application model with corresponding data representation and business logic
• View: data presentation, providing views for user input
• Controller: to dispatch requests and control data flow

 

The controller handles the interactions between the view and the model. When the model changes it updates the view, when the user does something with the view the controller informs the model.

Using the WebFacing toolkit that comes with IBM WebSphere Development Studio, the application is first converted to create JSPs and Java Beans for each record format. When the program performs a READ on a record format, control as well as the application data is sent to the controller.  Because the job was started by the WebFacing server, the controller knows this is a WebFacing request and passes the data and control to the WebFacing server which runs on the iSeries.  Control returns to the WebFacing runtime servlet that runs in WebSphere Application Server. The WebFacing servlet locates the appropriate JSPs and Java beans. The WebFacing servlet tells WebSphere Application Server to return the JSP back to the browser. The JSP is compiled and the resultant HTML is returned to the browser.  Note that no 5250 datastream is generated in this flow.  The following figure depicts these data flows in a WebFaced application: 

 

 

WebFacing is part of the WebSphere Development Studio for iSeries.  The studio includes all the compilers and tools to support WebFacing and includes the development environments Code/400 and VisualAge for RPG.

WebFacing tools help to quickly convert existing RPG applications into web UI with minimal changes required to the underlying applications.  It introduces very less additional costs to the application stack price and requires no user enablement licenses.  The architecture also eliminates the interactive (OLTP) workload and improves the efficiency of the web application during run time.