In-Depth

Integrating Screen-Based Apps with the Web

• 08/01/1999

With widespread recognition of the value that Web technology can provide to almost every organization, there is a tremendous pull on expanding the use of this technology. In particular, the expansion of static HTML sites to include transaction processing and live data queries can provide exceptional value and cost savings. Call it electronic commerce if you like; the fact is that the Web offers a truly universal network and universal terminal (the browser) that can and will reshape your organization’s information technology and its use.

This article focuses on the integration of existing screen-based host applications to provide the fastest, lowest cost approach to integrating key transactions as the building blocks of transaction-oriented, dynamic Web applications. Since the 3270 (mainframe) and 5250 (AS/400) are two terminal protocols that lend themselves well to this approach, they are assumed as the terminal types used for host access.

Many who leveraged screen-based applications in client/server projects are familiar with this approach, unaffectionately termed "screen scraping." A simple analysis shows that there are costs to this approach: increased host CPU time spent delivering screen maps that are in many cases unnecessary, as well as ongoing maintenance synchronization issues. Yet, even in the long run, breaking up 10-year-old COBOL applications into back-end/front-end components so that you can save a few cycles of less and less expensive hardware starts to look like an exercise in futility.

So we have higher benefits, similar costs and the same outcome: screen integration. The goals for screen integration include:

• Identify new and existing relationships you are supporting.

• Determine security and access requirements.

• Provide a pass-through emulation capability (screen-to-HTML).

• Implement multiple levels of user interface re-engineering.

• Compatibility with existing Web application development environments.

What is this, a database? No. We aren’t talking about database tables here; we’re talking about organizational relationships. This is somewhat new; in the past, systems designs were based on a relatively static set of roles and relationships between the users of the applications and the systems being built. Implementing Web applications changes all this, because we are setting up what is potentially a broadcast set of applications that can touch anyone we give the authority for access.

So, a priority in defining your integration goals is to identify the key relationships you will be supporting. Broad categories include Internet, extranet and intranet. These are really just boxes invented to describe relationships to the unknown public (Internet), known affiliates (extranet) and in-house personnel (intranet). These are nice generalizations, but they tend to oversimplify.

As you discover the opportunities in extending the functionality in your host applications using Web technology, you will find that each relationship with your organization, whether inside or out, will have different application needs. These needs are best met with a spectrum of application access focused through the ubiquitous, universal terminal that is the Web browser.

This is something new – anyone with a Web browser can access your Web applications! But only if you let them. Security is certainly a difficult topic to generalize: Each organization has its own policies regarding who can access certain classes of information (and who can enter or update information).

For intranet applications, you may be replacing emulators or even terminals that have, up until now, utilized a fixed logical unit, which is then included in the security profile. In this kind of situation, you will need to either relax your security policies away from a fixed physical device orientation, or implement the same policy using TCP/IP and your host access gateway.

It is possible in a browser environment to physically identify a workstation using the physical IP address. To use this as a consistent device identity requires care in the use of DHCP servers, and requires that your connection to your mainframe is using an SNA connection, TN3270E (extended) or for an AS/400, a version of TN5250 that supports device identification.

You can broaden both the user identification process and encryption across the Internet using a wide variety of technologies, which fall under the umbrella term "virtual private network." A VPN implementation is particularly useful in extending access to those in your organization in a secure manner outside your premises.

For extranet and Internet relationships, you will need to hash-out new security policies in order to achieve business goals. Some classes of information require no user identification or authorization. For example, a public court system that is by law required to make court schedules available to anyone has no issue with providing access to this information anonymously over the Internet. Meanwhile, for a manufacturer who wishes to enable customers to place orders and review order status, there is a higher level of security required.

For Internet and extranet applications, you need to determine for each relationship whether you will be identifying each user at the mainframe security level, or using an additional layer and group user IDs (or no authorization at all, as in the courthouse example).

If you are registering each user in your mainframe security system, then everything pretty much works as it does today. A simple alternative is to maintain a side database of "PIN" numbers, which are used along with a customer number to login – this way there is a simple 4- or 5-digit number that provides what could be considered a "lightweight" security authorization.

When implementing a lightweight authorization scheme, the actual logons to the mainframe or AS/400 use a group user profile. Note also that your host access gateway for the Web applications can act as an additional security filter that can restrict access to certain screens and block-out access to sensitive fields.

If you are going to implement a Web-based application set that provides support for a new or existing relationship, a key capability is pass-through emulation. In practice, this consists of protocol conversion between 3270 or 5250 native datastreams and HTML forms.

The need for screen-to-HTML protocol conversion is based on maintaining a consistent user interface. For many user sets, not all of the functions involved in systems interaction will be provided through new HTML pages delivered through new application functionality. Many functions, particularly less used or simplistic ones, should be delivered using the existing screen-based application "as-is." It is inappropriate and in poor style to have a separate emulator window from the browser that the user has been working in. That is why using standard HTML to provide the emulation is critical to proper Web-based host access integration.

To make this possible, there are a number of technical challenges that vendors of screen-to-HTML protocol conversion have had to overcome. These include unsolicited screen updates, direct function key support and screen layout control (particularly in columnar layouts). With today’s browsers, which include style sheet support, not only can high fidelity emulation be delivered using HTML, but it also looks and works better for many users than standard emulators.

When evaluating a pass-through capability, the generated HTML user interface should be "open" and flexible, allowing you full control over the look and feel of the generated HTML pages. This is key to maintaining a consistent style and look with the pages that support the user’s relationship with you using conventional Web delivery.

For example, a salesperson who is provided an extensive intranet application consisting of all sales collateral, rules of doing business and an interactive order entry system may also need access to a broad set of queries. When the user accesses these queries, he or she is actually directly accessing some simple screen-based applications. Since the generated HTML uses the same style sheets and/or colors and fonts as the base intranet application, the user is not "thrown-off" by a pop-up green screen in a box by itself.

Another technical requirement for a pass-through capability is that it should easily integrate with any extended transactions currently being supported through the same screen-based application system. Typically, this is achieved through an easily accessed opaque session key. The session key can be maintained for the host session providing the pass through at a variety of locations in the application delivery tiers.

A simple technique is to provide the coordination of this integration at the browser itself, using HTML frames and JavaScript or VBScript. Once the session is established, the session key can be saved in a variable in the top-level frame, making it available to any function driven by a menu or link on any pages.

With this scenario, the pass-through emulation page is displayed in the primary frame, while a "menu" or navigation frame provides functional links on the left. When a user selects a new function that is driven off a completely different set of code (but shares the same screen session currently displayed as a pass-through page), the link selected calls a function in the top level frame. This function combines the link’s function ID with the stored session key to provide a transaction request which will "break-out" of the emulation mode into a programmed, re-engineered mode.

A full spectrum of screen re-engineering describes the ability to integrate everything from pass-through screens right up to what is essentially a new application flow, look and feel. The fully re-engineered application uses the existing screens as primitive executives for reading and posting transaction data; the resulting application looks very little like the backing screens, and the sequence of user interaction has little resemblance to the host-based transaction flow or navigation.

The HTML delivery mechanism combined with a pass-through (protocol conversion) capability as described in the prior section provides a unique opportunity that simply didn’t exist in client/server applications. This is the capability of "light" re-engineering. Light re-engineering existed in client/server GUI environments, but at a high cost. While it might have resulted in a GUI screen that "looked a lot like" the originating screen, the GUI screen still required a full programming effort to convert from the backing screen to the event-driven GUI environment.

How is HTML different in delivering lightly re-engineered screens? It is different because in the right screen-to-HTML delivery environment, the "upgrade" to the screen can consist of simple, easily implemented static HTML text and tags surrounding the "live" screen data. Any variety of techniques can be used to implement a lightly re-engineered HTML-delivered screen.

How the level of re-engineering scales up from "light" on through "heavy" is a matter of gray areas. Generally, moderate re-engineering involves the maintenance of state information for the user as navigation from one business function is performed. The user’s activities closely map to the flow of the host screen applications, but the pages that the user views do not look very much like the backing screens.

One can also measure the level of re-engineering by the amount of work involved, which, based on the desired goals, will be different depending on the toolset used. It is hard to say that an application is "heavily re-engineered" if it takes a single developer an afternoon to implement the enhancements above the base pass-through emulation.

A key to understanding that your host access integration can support full re-engineering is how well it supports popular Web development environments. That is because the "truly" re-engineered applications are those that are in fact not based on the screens at all; they are based on a new application design implemented by a department using a Web application development and deployment environment. In this scenario, the screen applications provide none of the flow, navigation, look or feel of the application; they simply perform the "heavy lifting" of the application while the interaction with the user and presentation of information is delivered by the Web application.

Compatibility with existing Web development environments will be essential for success when integrating existing screen-based applications. The existing Web developers in your organization hold the keys to a rapid, compatible integration of business transactions with the Web sites they have already built and will continue to build.

An interesting aspect of the Web has been the ongoing clash between departments/marketing and traditional IS departments. One is fast-moving, almost ignorant of normal development approaches and discipline. The other, somewhat ignorant (admit it!) of how HTML and JavaScript create such quick success. Meanwhile, as Web applications expand in functionality and usefulness, they encroach upon and begin to rely on the traditional IT (read: mainframe) resources.

Whether or not this is true in your organization, one key point is that there are a number of development and deployment environments that have established themselves, and there is probably at least one of these already in use in your organization.

By providing support to your departmental developers with the implementation of a compatible host access toolset, you can accelerate their delivery of reliable and accurate applications while maintaining control over how your screen-based applications are utilized.

There are four primary approaches for integration with an existing Web development tool:

Integrate at the Browser Using Frames. This is a simple approach that will work no matter what Web application server you have. A top-level HTML frame at the browser contains management JavaScript in the form of control variables and functions. It requires that your host access gateway have the flexibility to enable the generation of HTML that contains JavaScript and which include the ability to provide a "session key" used to provide state management between the user’s browser session and the host gateway session.

In this architecture, the Web gateway and the Web application server "share" the browser and interchange information using JavaScript (or VBScript for an all-IE client base).

Native Components. Examples of native components include custom DLL-based components designed to work with the specific Web application server. Examples include a custom CFX tag for Cold Fusion (Allaire) or an Active Server Component for Active Server Pages (Microsoft). These are two popular and low-priced Web delivery environments; there are plenty of others, each may or may not offer a native component feature.

Distributed Object Architectures. Distributed object architectures tie your Web application server with your Web gateway using either CORBA or Microsoft’s COM architecture. This provides the same sort of integration as native components, but with additional features provided by the distributed object environments.

Host Access Gateway as XML Server. XML provides an additional metadata layer in what is essentially an identical environment to the browser-Web server environment. With XML, a transaction request is made over the same protocol that is the backbone of the Web: HTTP. The reply can contain any arbitrary organization of field data, including hierarchical organizations of multiple tables.

This approach to integration has many advantages for multi-platform environments as it involves a minimum of operating system or hardware dependencies. For example, an NT-based host access gateway easily provides complex transaction capability to a UNIX-based Web application server without any compatibility or configuration complexity.

For this approach to work, the host access software must be able to act as an XML server, and the Web application server must be able to act as an XML client.

About the Author: Bill Thorne is ScreenSurfer Group Vice President for Intelligent Environments (Burlington, Mass.).