Leveraging Host Applications
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 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.
Click here for a larger image.
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:
|Host Screen to Browser Mapping||Description|
|One-to-one||One-to-one mappings transform one host screen to one browser document. Controls may be positioned and grouped as desired on customized screens.|
|One-to-many||One-to-many mappings transform one host screen to many browser documents. This may be used to split up a busy screen into two. It also may be used to provide multiple views of the same host screen. In this case, the presence of certain data on the host screen will trigger different customizations to be applied.|
|Many-to-one||A browser document does not suffer from the screen real estate limitation of green screens. Many-to-one mappings transform many host screens to a single scrollable browser document. This type of mapping may be very useful to provide detailed inquiry information from several host screens. However, when used to map several transactional host screens, many-to-one mappings can be difficult or impractical. Navigation paths in the host application must allow a transaction to be replayed from the beginning when screen validations fail.|
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 NetManage1.
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.
Page 1 of 2