We will look at a few vendors offering products in each space.

The ability to access mainframe applications over a network and through a GUI OS has been around for some time through technologies such as terminal emulation and screen-scraping. It should come as no surprise then that they were among the first applications of the mainframe world to move to Java.

Over the past year, products have emerged that fit the traditional "screen-scraping" model; products that allow you to build thin Java clients by cutting and pasting fields from existing character-based host screens, and by mixing in GUI attributes such as buttons, pull-downs, color, etc. These technologies provide the low-cost reach of a browser-based distributed client and the benefits of GUI look and feel.

A product called Jacada from Client/Server Technology (www.cst.com) automates the generation of thin Java clients from host screens using a rules-based technology called KnowlegeBase. The rules engine is designed to recognize patterns in the original host screen and translate them into corresponding graphical objects.

"Java-based graphical clients deliver on the promise of intuitive, easy user access, without the complexity and cost of traditional client/server architectures," said David Holmes, Vice President of Marketing for CST, Inc. "The future is bright for organizations to reap huge returns from their mainstay application investments."

A recent offering from Advanced Transition Technologies (www.att-inc.com) called ResQ!Net uses a patented technology to build thin clients directly from the mainframe datastream. Using the ResQ!Net authoring tool, "ResQ!Net instantly enhances the look and feel of host legacy applications and is such a natural fit for the NC that I won't be surprised to see it running on all IBM's Network Station computers, as well as NCs from other vendors," Todres Yampel, President of AT2 commented.

The next generation of mainframe/Java technology has already begun to appear. In general, they are built around the External Presentation Interface (EPI) and External Call Interface (ECI) methods of accessing CICS transactions.

The ECI allows a non-CICS application to call a CICS program in a CICS server. These calls can be either synchronous or asynchronous, meaning that the application has the option of maintaining control while waiting for a return from the called CICS program. ECI also allows for simultaneous connection to multiple CICS servers from a single application.

The EPI allows you to develop GUI front ends for existing CICS transactions without needing to modify the CICS. Applications can use the EPI to communicate with a CICS transaction and can exploit the presentation facilities of the client system to communicate with the end user. For example, if an application receives input from an external device such as a bar code reader, the application can use the EPI to convert the input into a 3270 data stream to start a CICS transaction and pass the data to it. Output from the CICS transaction is passed back and converted into the normal data type used by the application.

One product from IBM that takes advantage of these interface methods is the CICS Gateway for Java (http://www.hursley.ibm.com/cics/internet/cicsgw4j/index.html). The Gateway sits on the same processor as the Web Server and routes ECI and EPI calls made from Java through a CICS Client to the desired CICS server applications; manages the many communication links to the connected browser or network computers; and controls asynchronous conversations to the CICS server systems.

Another product called Interspace from PlanetWorks (http://www.planetw.com) supports calls to CICS through ECI and EPI. Interspace can also serve as a generic bridge between Java applications and various mainframe messaging middleware, including Distributed CICS, Encina, MQSeries, TOP END or TUXEDO.

"Interspace allows customers to integrate the best of the old with the best of the new and the best of the future. This means that customers are not locked into a dead-end solution, as they would be with a screen scraper approach," said John Santoro, VP of Development for Planetworks.

Blue Lobster Software (http://www.bluelobster.com) Mako Server allows you to create CORBA interfaces to ECI, meaning that Java calls to CICS can be made transparently through an ORB. By using the Mako server, applications can take advantage of all the benefits of Java to CORBA communication.

"Our customers want access to their mainframe data without having to change existing applications," said Andrew Wilson, Chief Architect at Blue Lobster Software. "Our approach is to look at the Mainframe as just another server. Using Java technologies, we can ensure cross-platform compatibility. Using CORBA, we can take advantage of its distributed object capabilities and its inherent security benefits."

Bartels's group at HDS is developing products and services focused on security, wrapping of legacy applications and tools that will enhance object request broker products. Working with some of the vendors mentioned, and developing new tools as they go along, HDS seeks to make all this meaningful to their clients. As an example, he noted that their experience with home banking for a major bank involved interfacing with 15 different legacy applications or data bases. To build a home banking capability rapidly, banks must be able to analyze the existing code and develop quickly the wrappers to link to the coordinating, object oriented application. And home banking, like many other industries, demands applications that are secure and fast.

Over the last twenty years, no platform has a better track record for speed and security than the mainframe (UNIX lovers, please address angry responses to deny-it@if-you-can.com). Now, Java, middleware technologies and distributed architectures promise to extend that record into a new millenium.