In today's business climate, building your entire IT infrastructure from scratch is not always viable. IT must provide true business value and justify expenses. With reduced budgets, it makes financial sense to continue to leverage existing applications by integrating them into the current on-demand IT world.

If your business relies on "green-screen" applications, IBM WebSphere Host Access Transformation Services (HATS) is a tool that can help you gain new value from those established applications.

With HATS, you can rapidly transform the end user experience of your terminal applications without modifying those applications. Using HATS' rules-based transformation technology, the screens of your applications can be rendered in the browser "on the fly" with intuitive user interfaces. For example, function keys can be rendered as links or buttons. You can further improve the appearance, usability, and flow of your applications by creating screen customizations and macros. Since HATS is a Web application, the only client needed is a browser; there is no software download.

HATS can also be used to transform and expand the connectivity of your terminal applications by extending the proven business logic as Web Services. These services can be deployed as reusable components in a larger application integration or Service Oriented Architecture (SOA) implementation.

This article describes what HATS is and explains how it can be used to broaden the reach of your existing applications.

What Is HATS?

HATS consists of two components: the development toolkit and the runtime.

HATS toolkit provides a set of wizards and editors that guide you through creating and modifying HATS projects. HATS toolkit is integrated with the Eclipse-based IBM Rational Software Development Platform (Rational SDP). This combination enables you to do all development (HATS, Java, Team, Web, Portal, etc.) and testing in one development environment before deploying to the server.

HATS applications are packaged in standard J2EE formats. For deployment directly to IBM WebSphere Application Server, the HATS application is packaged as a J2EE Enterprise archive (.ear) file; for deployment to IBM WebSphere Portal Server, the HATS application is packaged as a Web archive (.war) file.

HATS runtime is a set of servlets and classes that are automatically packaged with the HATS application. HATS runtime does the following:

• Manages connections to the Telnet servers for the terminal applications that you are transforming
• Keeps track of end users and their interactions with one or more HATS applications
• Provides a transformation servlet (HATS entry servlet) that processes requests from end users and dynamically transforms terminal data to HTML based on the request, the screen received from the terminal application, and the customizations defined by the developer
• Provides an Administrative Console servlet that enables connection management and problem determination for one or more HATS applications

The runtime leverages IBM WebSphere Application Server (WAS) as its deployment platform.

Figure 1: Develop, test, and deploy a HATS application. (Click images to enlarge.)

For more information on HATS prerequisites and supported HATS toolkit and runtime environments, see WebSphere HATS Detailed System Requirements.

Extending the Application

HATS offers you two basic transformation scenarios for expanding the use of your terminal applications. These scenarios are not mutually exclusive. You could implement either one, move from one to the other, or combine them based on business needs. These are the scenarios:

1. Transform the user experience by exposing existing terminal applications to new end users.
2. Transform the connectivity by providing programmatic access to terminal applications.

HATS application development, deployment, administration, and usage call for different roles and skills:

• HATS developer--The developer creates and edits the HATS application using the HATS toolkit and the Rational SDP. Required skills include an understanding of the terminal application and HTML. For advanced customization, the developer might require JSP, JavaScript, Java, portlet, and J2EE development skills. HATS is extensible and has a rich function set, so there are many possible tasks and integration opportunities, including these:

1. Developing a HATS application with very little customization

2. Integrating a HATS application with another J2EE application or an Enterprise Information System (EIS)

3. Using HATS APIs to create custom components and widgets

4. Using HATS and portlet APIs to customize a HATS portlet

5. Creating business objects based on HATS macros and integrating them into a J2EE application.

• WebSphere administrator--This is the person who deploys the HATS application. This person must be familiar with using the WebSphere administrative console or scripting to deploy, start, stop, and manage J2EE applications. The skill level is dependent upon the WebSphere configuration, and might be operating system specific.
• HATS administrator--The administrator monitors HATS connections, examines logs, and collects traces. HATS problem determination skills are required.
• HATS end users--The end user accesses the HATS application through a browser. For the "transform the connectivity" scenario, the end user might access HATS services using a .NET or Java application client.

Transform the User Experience

The main value of this scenario is the rapid return on investment. You can quickly improve the user interface of your existing applications and achieve integration with other business information with minimal development cost. The result is an easy-to-use Web interface to the application, which can reduce training cost, simplify the application, and/or make the application accessible to new users outside your organization.

This scenario also illustrates how HATS fits with the "develop iteratively" and "continuously ensure quality" principles of the business-driven development process. Within a few hours, you can create a HATS application that does basic transformation of the existing application, show it to your end users, and get feedback on how it can be improved further. You might be satisfied with minor customization, or you might want to continue developing and testing iterations until the appearance and flow of the HATS application is very different from the application you are transforming.

Basic Transformation
To create a HATS project, the developer specifies the Telnet server for the application to be transformed and the connection type (5250, 3270e, or 3270). This information defines the transformation connection, which is the connection on which existing application screens are transformed. SSL security, for secure communication between the HATS server and the Telnet server, can be configured later.

A template is then chosen. This is the static area of the Web pages presented by the HATS application. After initial project creation, a customized template can be created to match your corporate Web "look and feel."

After the developer fills in a three-page wizard, a HATS application is created and can be tested on the integrated WAS. The application screens are rendered in the browser using the default settings, and users can navigate them by using the keyboard or the mouse. Host keys, such as SYSREQ and RESET, are mapped to default key combinations. Host-key-to-physical-key mappings can be modified by the HATS developer, if desired.

Figure 2: This is the iSeries main menu with the screen rendered using default settings.

The next likely project-level customization is tuning the default rendering, which defines the rendering rules for screens that have not been customized. The default rendering consists of a list of component/widget pairs. A component is a visual element of a host screen, such as a command line or a function key. It has configurable properties. For example, function keys in your terminal application are prefixed by "PF:". In addition, a screen region is associated with a component and defines where to "look" for one or more occurrences of the component. A widget defines how a host component should be rendered. For example, a function key component can be rendered as button or a link. Component and widget settings can be modified for your host application screens.

At runtime, the items in the default rendering are processed in the defined order. After a rendering item is applied to a region of the host screen, that region is ?consumed? and won't be processed again.

Figure 3: Configure the default rendering.

Modifying the default rendering can result in dramatic changes across the HATS application. The developer can modify the settings and preview the changes immediately.

Figure 4: This iSeries main menu screen is recognized as a Selection list component and rendered with link, radio button, and button widgets.

The developer can further customize the overall application by configuring text replacement, global rules, and other project-wide settings.

Text replacement allows static text within your application to be replaced with other text, HTML, or a button or link that sends a host key. For example, the string "More..." could be replaced with a "Page Down" button that sends F8. Text replacement rules can also be defined using regular expressions.

Global rules enable application-wide pattern recognition and transformation of host screen input fields.

Figure 5: This global rule looks for an input field with "Birthdate . ." to the left and renders it with a calendar widget.

Further Customization
To better understand how HATS can be used to further improve the flow, usability, and appearance of your existing application requires defining some key concepts:

• Event--A state change in the HATS application that triggers one or more actions. Screen customization events are triggered when screens specified by the developer are recognized. Application events are triggered by state changes in the application's life cycle. Examples of application events include initial access to the HATS application by the end user (Start event) or the application encountering an unrecognized screen (Unmatched Screen event).
• Action--A step that is taken when an event occurs. One or more actions can occur as a result of an event.
• Screen customization--A set of screen recognition criteria used to recognize a specific host screen and a list of actions to be taken when a screen is recognized. Screen recognition criteria might be text on the screen or the number of fields on the screen.
• Transformation--A JSP file displayed to the end user. Typically, it contains HATS component tags that render a specific area of the host screen with a widget. HATS tools offer other capabilities also. For example, the developer can insert the default rendering of a portion of the host screen, a global variable, or a button that drives a macro. Since HATS toolkit is integrated with the Rational SDP, all the Web page editing capabilities inherited from the platform are at the developer's fingertips. Applying a transformation is one of the possible screen customization actions.
• Global variable--A variable that is used to store a value. A global variable exists throughout the lifetime of a browser session. The value of a global variable can be extracted from a host screen or defined by the developer. Global variables can be used in templates, in transformations, in screen customization actions, or as recognition criteria. They can also be shared among applications in the same .ear file. Global variables can also be used in macros and business logic.
• Macro--An XML script that defines a set of screens and the actions to take on those screens. Macros can be used to skip over unnecessary screens or enter information for multiple host screens obtained from one Web page of end user inputs. The macro technology is inherited from the IBM Host On-Demand product and has rich functionality.

Next, an overview of HATS application processing illustrates the flexibility of the HATS framework:

1.   When a host screen is received, HATS compares the screen to a list of defined screen customizations in the order specified in the project.

2.   If a match is found, HATS performs the actions in the designated order. These actions might include any of the following:

• Apply a transformation.

• Execute business logic. Business logic is Java code created by the developer. For example, a database query could be created using information from the terminal application. HATS also provides APIs that the developer can use in business logic or in a transformation.

• Extract an area of the host screen to a global variable.

• Insert data onto the host screen.

• Set a global variable.

• Show a Web page.

• Forward to a URL to transfer control to a specified JSP. This is how control is transferred from the HATS entry servlet to an Integration Object.

• Play a macro.

• Perform a macro transaction. With macro transactions, the HATS application can interact with other terminal applications. Macro transactions run a macro on a background connection (a connection other than the transformation connection). This capability might be used to enter data obtained from the end user or from the default terminal application into the background terminal application. Background connections can be pooled and primed with a connect macro to make the macro transaction efficient. Background connections, which can also be used by Integration Objects, are the only way to interact with VT terminal applications.

Notice that actions can be performed against the host screen before the user interacts with it via an "apply transformation" action and after the "apply transformation" but before an update is sent to the host application.
 

3.   If no there is no match, HATS processes the unmatched screen event. The default action of this event is to apply the default transformation.

4.   As each screen of the existing application is encountered, HATS starts at step one.

Figure 6: This customized screen includes a tabbed folder, a bar graph, a calendar widget, and macro buttons.

HATS applications can also be extended to portal users by creating HATS portlets. These portlets can be further enhanced and integrated with other portlets using the portal development function in the Rational SDP. Note that HATS portlets are implemented using the IBM Portal API.

In addition, HATS Web Express Logon (WEL) is a feature that enables single sign-on to the terminal application using Web credentials. WEL can also be used with HATS portlets in conjunction with WebSphere Portal security for authentication and WebSphere Portal credential mapper for correlation of portal credentials with terminal application credentials. The WEL component is extendable, allowing customization for your own environment.

Transform the Connectivity

The main benefit of this scenario is the ability to incorporate terminal applications into more modern enterprise application flows. You can take advantage of established applications to widen internal, customer, partner, or supplier integration.

HATS Integration Objects are the reusable building blocks that facilitate this. An Integration Object is a JavaBean that encapsulates screen navigations that are captured by recording a macro.

The fact that Integration Objects are JavaBeans allows for flexible integration into a WebSphere application and the extension of Integration Object function to .NET or Java application clients. These are some of the possibilities:

Use HATS wizards to...

• Give a standard Web Service interface to your core business logic. This involves using HATS toolkit, the Rational SDP, and WebSphere's industry-leading Web Service capability to create a Web Service from a wrapper class that includes one or more Integration Objects.
• Create JSF, Struts, or Model 1 JSP pages from Integration Objects.
• Create HATS Enterprise JavaBean (EJB) projects and EJB Access Beans. At a high level, a HATS EJB project contains the HATS EJB and Integration Objects. HATS EJB Access Beans are HATS EJB clients that drive a specific Integration Object through the HATS EJB.

Use the J2EE and Java development capability in the Rational SDP to...

• Incorporate Integration Objects directly into servlets, portlets, Web Services, and EJBs.
• Access Integration Objects remotely via Java application clients (Web Service client or EJB client) or .NET clients (Web Service client).

To create an Integration Object within a HATS project, the HATS developer follows these steps:

1. Define a background connection to the existing application. This task may involve configuring pooling, configuring user lists, and recording connect and disconnect macros. These options provide efficiency by avoiding the overhead of connection set up and priming the connection to the screen where the Integration Object task begins.
2. Create the macro that captures the screen navigations involved in the task. The developer defines prompts indicating points on a terminal screen where data will be solicited from the end user or program and then provided as input to the terminal screen. The developer also defines extracts for screen areas that are to be retrieved and made available as output data from the terminal application.
3. Create an Integration Object with one click that has input properties for the prompts that were defined and output properties for the extracts that were defined.
4. Incorporate the Integration Object directly into the application or extends its function as a Web Service or an EJB Access Bean.

Integration Objects can be standalone, or they can be "chained" together to compose one or more interactive flows through the terminal application. Integration Object chaining is necessary when a single major task can take different screen navigation paths based on programmatic or end user decisions. Chaining is also required when a list of records is returned and an end user or program must choose which record to work with. HATS runtime keeps track of the connection for a specific Integration Object chain and returns it to the pool when the last Integration Object in the chain is complete.

iSeries Features

iSeries-specific features include the following:

• Workstation ID support--Workstation IDs can be assigned during development (using wildcards to avoid collisions) or at runtime (as end user input, an HTTP session variable, or an HTML parameter).
• Enhanced Non-programmable Terminal User Interface (ENPTUI) support--HATS recognizes these 5250 display data stream extensions and renders them using appropriate widgets. The subset of supported functions includes push buttons, check boxes, radio buttons, single-selection list boxes, multiple-selection list boxes, windows, menu bars, and pull-down menus.
• 5250 HTML DDS keyword support--HATS enables HTML, sent from the host application using the HTML DDS keyword, to be rendered in the browser.
• Support of a subset of 5250 check keywords
• 5250 print support using iSeries Access for Web
• Subfile support--HATS visually recognizes subfiles using the subfile component, and renders it with a Web look and feel with the subfile widget. There have been significant enhancements to HATS subfile support, including a wizard for the HATS developer to select and define different aspects of a subfile screen, and new recognition and rendering options, including rendering of foreground colors and extended field attributes.

Figure 7: Here's an example of a HATS default rendering of a subfile screen.

Hats off to HATS

There is a wealth of business logic, data, and stability locked into your existing terminal applications. HATS, built on the Rational SDP and WebSphere base, with its iterative development approach and application transformation potential, is an effective solution for further leveraging those assets.

HATS Resources

HATS Product Web Site
HATS V6 Information Center
HATS Online Demos
HATS Trial Toolkit, for evaluation of HATS
IBM Redbooks, for IBM Redbooks on HATS

Alisa Morse is a member of the HATS development team at the IBM Research Triangle Park lab in Research Triangle Park, North Carolina.