InformationWeek

ntranet applications are making a wider array of information available throughout the enterprise. But as noted in the feature story " A New Face On Legacy Data ," a huge amount of corporate data remains on legacy systems-applications residing on mainframes and minicomputers, typically accessed through terminals or terminal emulators. l Web and legacy terminal applications have a lot in common. For one, they're both thin-client applications-if you consider a Web browser a thin client-that present applications essentially as a mix of text and data fields. So merging the two seems a natural step, one that many software vendors hope to help you with. l While technologies such as object-encapsulation of legacy code are probably the best long-term fix for bringing older applications into the world of Web and Java applications, they require a good deal of additional development time to implement. But there are faster ways to move 3270 applications and other host apps into Web and Java environments. Some require a modicum of additional development time, while others deliver almost immediate results. They include three basic approaches: on-the-fly conversion of terminal applications to HTML; delivery of actual terminal sessions within or accompanying a Web page; and application servers that broker data transfers between Web and host applications through the High Level Language Application Programming Interface (HLLAPI) and other interfaces. l The first two methods offer the fastest turnaround time. But the third offers the most elegant set of solutions. It also provides an opportunity to take the greatest advantage of browser and Java interfaces.

The most straightforward way to get terminal sessions to browser users is to convert the presentation of data in a terminal session into HTML automatically. A number of gateways do just that, letting users enter and view data in HTML forms.

Generally, conversion of host application terminal data to HTML is accomplished by a gateway application connected to the host-either one residing on the Web server or its own server. In som e cases, the conversion is accomplished by the host itself, making applications on the host directly accessible by Web browsers.

Generally, the host applications need no changes to be run from Web browsers. But there are some problems caused by the nature of HTML. Web browser connections to a host aren't persistent-they only connect to the host when downloading or refreshing a page. Users can move back and forth among Web pages that have been downloaded already, or connect to another host entirely, all without sending any information to the host application.

HTML conversion applications can take advantage of browser capabilities such as Secure Sockets Layer (SSL) encryption and can use cookies and other user techniques to track users through applications. But straight conversion of terminal data to HTML doesn't take full advantage of the nature of Web clients. So although it's a quick way to get legacy applications on an intranet, this method is best suited for quick fixes.

Perhaps the quickest and easiest way to give Web browsers access to host-based applications is to give the browsers actual terminal emulation capabilities-through a Java or ActiveX terminal component.

These components generally fall into two categories: those that provide an essentially unadulterated 3270 or TN3270 connection through a Java applet such as IBM's Host On Demand, OC://Web Connect from Open Connect Systems of Dallas, and Sunfire from Eicon Technologies of Montreal, and desktop host access products that integrate with Web-page elements through ActiveX or Java, such as Rumba Office from Wall Data Inc. in Kirkland, Wash.

Java and ActiveX terminal emulation has one major advantage over HTML-based access to host data: terminal emulation connections are persistent. This means that unlike pure HTML-based interfaces, the host in a terminal session is always aware of where the client is within an application and can detect when the session ends.

The simpler, straight-emulation applets typically can be pushed dow n to the client on demand: Host On Demand can be delivered by IBM's Communication Server; Open Connect Systems' OC://WebConnect delivers its own Java-based terminal emulation upon request; and Attachmate's Extra! HostView Server pushes either an ActiveX or Java terminal emulator to the Web client on demand.

This is probably the simplest way to implement legacy application access on an intranet, as it uses the SNA gateway and other network resources already used to access host applications from networked desktops, and it presents experienced terminal users with the same interface they've always used. Both provide a fairly rich-featured terminal emulation, with graphical buttons for common functions and programmable functions (PFs).

Ready To Rumba
Rumba's more complex ActiveX-based emulator goes a bit further toward integrating legacy applications with Web-and desktop-apps. It exposes functions of the Enhanced High Level Language Application Programming Interface (EHLLAPI), an interface fo r connecting terminal applications to graphical front-end ones, to other components within the Web page or applet, or to desktop applications that can take advantage of the ActiveX component architecture (like Visual Basic).

Designers of intranet applications can use Rumba and similar components to provide users with an enhanced Web interface to existing terminal applications, with elements such as control buttons for handling special keyboard commands and PFs. But Rumba Office must be installed and licensed on each desktop before it can be run by a Web browser application. Since Rumba's ActiveX components run only within 32-bit Windows operating systems (Windows 95 and Windows NT), applications built using them will run only on PCs that run those operating systems.

Terminal sessions within browsers may offer access to host applications from Web browsers, but they don't necessarily make getting to that information any easier. The user still has to be trained how to use the terminal application, and t here's no easy way to link data in legacy applications with data from other sources such as other intranet applications and client-server databases. Still, for applications that users absolutely must have access to, this method is the most reliable.

Using A Middleman
Perhaps the most flexible approach to moving legacy applications quickly into an intranet environment is using an application server. While conversion gateways simply take terminal data streams and convert them to HTML, these application servers let intranet developers pull data out of host applications and present it in an application written specifically for a Web browser or as a Java applet.

Essentially, the middleman application is a server version of the "screen-scrape" approach to building host connectivity applications. Generally, this category of solutions works like this: An application is configured on a server to pull data from a host application through EHLLAPI, HLLAPI, or some other interface. Then the application is "trained" where to look within terminal screens for data, and how to navigate through host applications to get to those screens.

The application presents this data through a generated HTML interface or a Java applet. The logic for the application resides on the server, and only the data and presentation format are downloaded to the client.

Examples of this type of application middleware are Attachmate's Extra! Host Publishing System, Infresco's Opal, Open Connect Systems' OC://WebConnect Pro, and Centura's ForeSite. Each has a different approach to the details of its application server architecture and how client interfaces are built, but they all essentially follow the approach detailed above.

Attachmate's Extra! Host Publishing System offers perhaps the easiest way to build Web-to-host applications for organizations familiar with the screen-scrape approach to getting host data into client applications-it uses ActiveX objects and Microsoft's Visual Basic. "QuickApp" objects provide host conn ectivity, and also convert all of the VB application interface elements to HTML for a Web server to present to clients. A QuickDB object provides a link to mainframe and minicomputer IBM DB2 databases through an Open Database Connect driver for IBM's Distributed Relational Database Architecture.

Since VB applications can also connect to other local and remote databases, intranet developers can integrate all their organizational databases into Web applications, linking them with logic running on the Extra! HPS server. Extra! HPS can handle up to 250 concurrent connections per server.

There are several advantages to this approach. First, since HPS converts everything to HTML, almost any Web browser can be used to access the application-there's no concern about what level of Java support the browser has. Also, less data needs to be pushed across the network to the client to present the data, so low-bandwidth clients (such as browser users calling in over a modem or connecting from across the Internet) can run the applications with relative ease.

The resulting intranet applications aren't limited to accessing just existing host applications, as they are in straight on-the-fly host-to-HTML conversion. A whole new set of applications, linking existing host applications with existing client-server applications, is possible.

HPS has a few shortcomings. It doesn't have load-balancing or fault-tolerance features to help ensure that its applications are always available to clients. The only way to make sure that the application stays up and active is to restart it when it fails-not exactly the ideal way to manage an enterprise application. Attachmate has promised load-balancing technology by early next year, either with internal technology or through Microsoft's Wolfpack clustering technology and other features of Windows NT 5.0. In the meantime, Extra! HPS is probably best suited for departmental intranet integration with host applications.

Centura's ForeSite version 2.5, like HPS, presents its appl ications as HTML, but it can also use Java applets and communicate through the Internet Inter-ORB Protocol (IIOP) or Remote Method Invocation (RMI). Also, ForeSite has its own application-integration tool, and is more scalable than HPS.

ForeSite is a multitiered system. A ForeSite installation includes one or more Dispatcher servers-one acts as a primary, and the others as backups-to broker incoming application requests, one or more PageServer systems to handle the applications, and System Integration Modules (SIMs) to connect the PageServers to data sources. ForeSite SIMs are available for ActiveX-Distributed Common Object Model server objects, ODBC data sources, terminal applications, transaction servers (such as IBM's CICS and BEA Systems' Tuxedo), Java and IIOP connections, and specific applications (such as SAP's R/3).

The most straightforward method in ForeSite to build intranet applications is as HTML pages. Through a tool called Integrator, intranet content developers connect different data so urces to the application, and link them to a dynamic HTML document. The document is based on a template, which can be modified in any HTML editing tool to make the application look like the rest of the corporate intranet or Internet site.

When a request for an application is made through a Web server, a Dispatcher server connects the Web server to an available PageServer with the application. All of the interface is interpreted into HTML and sent to the browser client as a Web page.

Java developers can build ForeSite applications as well; ForeSite's JavaBeans SIM can be integrated into a component-based Java applet and interact with other JavaBeans components. ForeSite Java applications bypass the Web server for their application connection, going directly to the Dispatcher server via IIOP or RMI.

Write Once, Run Many
Infresco's Opal v. 2.0 takes a slightly different path to integrating intranet and host applications. It is designed not just for building intranet applications, but sta ndalone desktop applications as well. It uses a proprietary application architecture, which can be run on a Web browser through an ActiveX control, Netscape plug-in component, or Opal Java client (which will ship by year's end).

Opal can connect to any host application, database, client-server application, or DCOM object on the network. The product is designed to aid in re-purposing parts of applications. It also includes a user interface development client for building special-purpose front ends, such as multimedia kiosk interfaces.

Applications are built in Opal Integrator, a visual tool that lets developers connect host applications and client-server databases to a graphical form. No coding is required to connect the back-end data sources to the interface, and forms can be easily connected to special user interfaces built with the user-interface development tool.

Like HPS, Opal sets up its interface with terminal applications by "training" them where to look for data within terminal applicatio n screens. It also uses ODBC to connect to local and client-server data sources. But while Opal has the added advantage of being able to deploy its integrated applications as "thick" desktop client applications, its server lacks the scalability of ForeSite; Infresco doesn't see Opal as middleware, but rather as a flexible application development environment.

OC://WebConnect Pro from Open Connect Systems doesn't use a server back end to provide application logic. It uses Java applets to provide the glossy front end for legacy applications. All the server does is provide the host connection for the Java front end.

WebConnect Pro's OpenVista Java rapid application development tool provides access to 3270, 5250, and VT220 applications as well as Java Database Connectivity (JDBC) data sources-essentially any client-server database configured to allow access from Java clients. For those who want to look behind the curtain and see what the application is sending to the host, OpenVista apps can be configured to display the WebConnect Pro terminal session that it uses for a host interface along side its GUI.

OpenVista applets are published like any other Java applet on the Web server. When applications are generated, an accompanying HTML file is created as well; the HTML file and all the Java class and code files must be copied to a Web server. There are no application-management tools provided; however, the files can easily be managed from within Microsoft FrontPage or similar Web-site management tools.

While WebConnect Pro delivers on the host application side, intranet developers are essentially left on their own to provide integration with client-server data sources. The OpenVista tool provides JDBC capability, but the server side doesn't act as a JDBC gateway for server databases. This means developers will have to rely on other software for that connectivity, and on separate security schemes to handle user validation.

Flexible Approach
Tools such as WebConnect Pro, Extra! Host Publis hing System, ForeSite, and Opal offer a lot more flexibility and better integration with the rest of the intranet than simple host-to-HTML gateways and browser-integrated terminal emulators. But which approach you take to bringing your host applications to your intranet depends a lot on what your hosts are and where your intranet users are.

Extra! HPS offers the best route to jump-starting host-Web integration for organizations with smaller intranets and in-house experience with Visual Basic. WebConnect Pro is best suited to intranets where a client-server database access solution for Java clients has already been set up and a Java applet-with a persistent host connection-is the preferred client interface.

ForeSite offers the best scalability of the system architectures discussed here, and it offers the best solution for big intranet and Internet applications with a large number of clients with low-bandwidth connections to the network. Opal is well-suited to organizations that want to use a common to ol for deploying intranet, multimedia, and specialized desktop applications using data from host-based systems.

  Back to Labs

  Send Us Your Feedback

  Top of the Page