Leveraging Host Applications

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Introduction

Are host applications assets to be leveraged or liabilities to retire? In this article, we will look at two classes of products that can leverage existing investments in host applications. We won’t discuss any particular vendor’s product, but focus on the general capabilities, benefits, and risks. First, we’ll discuss web-to-host products that provide an HTML user interface to ‘green screen’ applications. Next, we’ll discuss host integration products that expose host functionality as XML services. Then, we’ll discuss strategies for how these products might be used to extend the life of or eventually replace a host application. Finally, we’ll summarize what we’ve learned.

Web-to-Host

Web-to-host software is used to webify a host application. Figure 1 depicts an IBM 3270 green screen host application being delivered as HTML to a browser through a web-to-host product. The application could have also been one of many other varieties of character-based user interfaces.

If you were to think of your application in terms of tiers and layers, the web-to-host software would be in the presentation tier. It wouldn’t provide any business logic, but just the user interface code. Web-to-host products are not intrusive to the host application and do not require any changes to the host application itself. All existing business logic can be reused from the host application.

Web-to-host products establish a session on the host computer, and then recognize and transform the green screens into an HTML form-based interface. There may be “on-the-fly” transformation of screens through default transformation rules. This capability can expose a host application to the web in a matter of minutes. In addition to the global or default transformations, there also may be individual screen customizations. The web-to-host software will recognize a particular screen and associate the appropriate customizations to be triggered for that screen. The customizations will re-face the screen and transform text fields into GUI controls such as radio groups, combo boxes, and check boxes, as depicted in Figure 2.

Screen customizations may be one-to-one, one-to-many, or many-to-one mappings of host screens to browser documents, as summarized in the following table:

The web-to-host software may provide various ways to extend the functionality of the host application. For example, it may be possible to decorate the browser-based interface in a portal. This allows the green screen application to be integrated with other applications. The web-to-host software itself may allow customizations such as accessing databases or services. This enables the application functionality to be enhanced without actually changing the base application itself.

The benefits of a web-to-host solution

There are many benefits that a web-to-host solution may provide:

• A new and more usable interface for a host application can be exposed to internal and external users.
• A host application need not be changed to expose it to the web.
• A web-to-host solution can be deployed in a short timeframe.
• A web-to-host solution can provide a layered architecture where business logic stays on the host and presentation or user interface code is handled by the web-to-host software.

The consequences of a web-to-host solution

As with all architecture decisions, there are consequences that follow and tradeoffs made:

• The user interface will be constrained by the host application. Navigation limitations on the host application are difficult to get around.
• Certain standard browser features, such as the back button, may not be available and cause a synchronization problem with the host application.
• By nature, a web-to-host solution will require duplicate maintenance. Whenever the green screens change, it is very likely that the screen customizations will also change. This can be mitigated by having maintenance of both the customizations and green screens the responsibility of the same development team; however, this is not always possible or practical. For example, it is entirely possible to customize green screens from a partnering company.
• A web-to-host solution may require significant computing power. The recognition of host screens and subsequent transformation into HTML can be a resource-intensive process.
• There is a danger of putting business logic in the web-to-host product. This adds to the difficulty of maintenance.

Web-to-host vendor products

There are several products offered in the web-to-host product category from vendors such as IBM, Jacada, Seagull Software Systems, ClientSoft, SEEC, Advanced Business Link, Micro Focus International, and NetManage¹.

Host Integration

Host integration products expose existing “green screen” functionality as XML services. You might say that host integration products servicize a host application. For example, a Customer Maintenance application might create a Customer service with methods to add, modify, delete, or search customer records. Figure 3 depicts a J2EE or .NET client application accessing an XML service which happens to be implemented by a host integration product. The client application is not particularly concerned about the implementation of the service.

If you were to think of your application in terms of tiers and layers, the host integration software would reside in the service tier. The host integration services wouldn’t implement any business logic directly, but provide a service interface to host functionality. Host integration products are not intrusive to the host application and do not require any changes to the host application itself. All existing business logic can be exposed from the host application as services. It is entirely possible to access multiple host applications through a single service, for example, to update customer address in multiple systems.

There are two models in which a host integration service may deal with the host—stateless and stateful. In the stateless model, each service request logs onto the host, traverses some screens in order to perform the requested function, logs off, and returns data. A pool of sessions might be used by the host integration software. In a stateful model, a session is established on the host for a given service client, and then a conversation is conducted with that client spanning multiple service requests. Finally, the client will log off at the end of the conversation.

The benefits of a host integration solution

Why might you consider a host integration solution?

• A host integration solution exposes host functionality as XML services to heterogeneous client applications built on technologies such as J2EE and .NET.
• A host application need not be changed to expose its functionality as services.
• A host integration solution can be deployed in a short timeframe.
• A host integration solution provides a layered architecture and acts as an adapter to the host application.
• A new user interface, unconstrained by the host application, can be built, but still leverage the host application as the system of record.

The consequences of a host integration solution

Let’s look at the consequences of choosing host integration products:

• Data capture rules and edits present in the host application will need to be duplicated in the client applications. This will cause duplicate maintenance. If the edits are not kept in sync, a service request may fail when the host integration software is performing the requested function in the host application.
• As with web-to-host solutions, a host integration solution usually will require changes to services when the host screens change.
• As with web-to-host solutions, the functionality of the service will be limited to the functionality of the host applications being accessed.

Host integration vendor products

There are several products offered in the host integration product category from vendors such as IBM, Jacada, ClientSoft, Seagull, Neon, WRQ, Software AG, Micro Focus, Attachmate, SEEC, Sabratec, Mitem, CommerceQuest, Inner Access, GT Software, Red Oak, NetManage, and Progeni².

Leveraging Host Application Considerations

There two sides of a coin that you should consider when thinking about leveraging host applications through web-to-host or host integration products.

First side of the coin

A host application may be thought of as a company asset that has paid dividends over and over again. You could view the host application as money in the bank. Leveraging the application means earning interest.

Second side of the coin

A host application may be thought of as a huge liability that is costly to maintain, inflexible to change, and a competitive disadvantage. You could view the host application as a ball and chain holding you back. If it is money in the bank, maybe it’s in a very low-paying CD losing ground to inflation.

Which of these views is correct? It is hard to say. In some sense the host application is an asset. However, there is a point when an asset becomes a liability.

There is no denying that web-to-host and host integration products provide the ability to leverage existing assets. Host applications can be quickly exposed as HTML user interfaces or XML services. But in either scenario, limitations of the host application live on and duplicate maintenance becomes necessary.

Re-writing a host application can be a daunting task. There is a great deal of business logic to be harvested from the host application. The host application may have a very high bar in terms of functionality that needs to be delivered even in a first release making replacement difficult in a short timeframe.

Web-to-host and host integration products could be used in a transition strategy. Consider the following scenarios:

• An HTML user interface could be provided through web-to-host software while pieces of the application are re-written in newer technology.
• Services could be built with host integration products to maintain the host application back-end functionality while creating a new user interface. This strategy would allow the presentation tier and resource tier upgrades to proceed independently or in parallel.

These and other incremental approaches could be more practical than a big bang approach. In terms of our banking analogy, we would be putting the money from the low-paying CD into better-paying investments gradually over time rather than in one fell swoop.

Summary

You could say that the trouble with many host applications is that they work. As much as we want to replace them, we need to manage these existing assets and co-exist with them.

Web-to-host products provide an HTML user interface to host applications. Host integration products expose host functionality as XML services. These tools can be used to extend the life of these assets and to expose them in new ways. Both classes of products do not require changes to the host application itself. While they require duplicate maintenance and maintain the limitations of the host application, they can be a part of a transition strategy to eventually retire these applications.

Are your host applications assets to be leveraged or liabilities to retire? Will you webify, servicize, rewrite, or simply live with your host applications? The rest is up to you!

References

1 Gartner, Noninvasive Legacy Web Enablement Is Still Viable, March 2003

2 Gartner, Programmatic Integration Servers Are a Growth Opportunity, March 2003

About the Author

Jeff Ryan is an architect for Hartford Financial Services. He has twenty years experience designing, developing and delivering automated solutions to business problems. His current focus is on Java, XML and Service Oriented Architecture. He may be reached at jryan@thehartford.com.