Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
If it ain’t broke, don’t fix it.” That’s what organizations have tended to think about their legacy applications. But the Internet’s lure is changing that. What if you could take Old Reliable and give her a great new interface that could take her anywhere the Internet (or an intranet) can go? The logical answer would be “Depends on how tough it would be for IT to do it.”
In the past, you had two equally unappealing avenues for Web-enabling a legacy app. You could either rewrite it or replace it with a newer equivalent. Rewriting the app required an enormous amount of complex work: translation between languages, switching from structured to object-oriented programming, porting from flat-file or ISAM databases to relational ones. And replacing the app with a newer equivalent usually meant finding one that was “close enough” at best. Even then, finding such a replacement package was often a matter of luck. It might not even exist.
Fortunately, these days you can take a middle path between the classic build or buy conundrum. Your options include:
“Screen scraping”—placing a Web-friendly GUI on the package’s front end.
Automating the legacy app’s screens with middle-tier software—screen scraping on steroids, allowing the creation of Java clients (on the front end), and driving pieces of the legacy app on the back end. To users it looks like a new app.
 | |
| A method to your Java Click here |
Java makes such transformation software possible. Enterprise JavaBeans (EJBs) and servlets have matured enough to let Java cross over from the client side and prove itself as a viable middle-tier language. And the proliferation of Java development tools has also helped its entry into the realm of legacy transformation software (see “Products for Web-adapting your apps”).
| Products for Web-adapting your apps | |
| You can use all these products to build Java-based, Web-based versions of your legacy applications… |
|
Scrape screens for a quick facelift
Screen scraping simply catches, say, a 3270 datastream from a legacy app, and modifies that stream so the user sees a modern UI instead of a text-only “green screen.” All the while the legacy app still thinks it’s talking to a 3270 terminal. Java’s life on the Internet began as a vehicle for providing active content on a Web page, so Java’s right at home acting as the engine for terminal emulation.
Outfitting a legacy app with a Web-enabled Java front end can take anywhere from a week to two months. And imagine the grief you sidestep by not having to rewrite any source code—a great comfort to management if those legacy apps are the heart of your organization. Nor must you pitch all those 3270 screens that have provided years of faithful serviceÉunless, of course, you want to.
Part of a larger suite of legacy migration tools, Computer Associates’ Opal Integrator converts host screens to Web-enabled Opal screens. Opal can handle 3270, 5250, VT220, and HP700 screens. The resulting user interface is called an “Opal Modern GUI”, and is supported by a runtime called the Opal Player. Because the intelligence of the onscreen controls resides in the Opal Player, it can accommodate exceedingly thin clients. Opal’s Data Manager assists in mapping app data to its onscreen representation.
Blue Lobster Software’s Stingray system sits higher on the evolutionary scale. Stingray is more than just a Java- based GUI replacement. It actually records a user’s interaction with an app through the presentation layer, then generates a Java object representing that interaction. Developers can deploy that object wherever they see fit—>even on the server side. Stingray’s runtime is compatible with TN3270 servers such as Bus- Tech’s NetShuttle, which provides connectivity between IBM mainframes and NetWare intranets.
Conextions’ Expresso works in a similar manner. As with Stingray, a developer begins by simply navigating through the app’s screens. ExpressoBuilder “watches” the navigation, during which the user points and clicks to select those onscreen fields that will participate in the final, Web-enabled app. A model of the app results, and is saved in a repository managed by the Expresso Server—a middle-tier tool that simultaneously provides a development and deployment platform. And the model doesn’t just capture information about the onscreen data the developer has selected; it also “knows” screen transitions and the app’s execution flow.
With the model in place, the developer has two routes for deployment on the Web. The first route is, with the help of the Expresso Server, to build JavaBeans (or classes) based on the model information. For example, the developer can build a JavaBean that encapsulates the actions needed to update a client’s balance. (Actually, the Expresso Server knows the actions. The created bean simply knows how to tell the Server which transactions to execute.)
The second route lets the developer treat the entire legacy app as a relational database. Screens appear on the client side as a table. To pass input to the legacy app, the client code simply executes a JDBC function to perform an update or insert. The Java app reads the results by fetching from the database.
| Vendors are giving their Java tools legacy chops | |
| The Java world is making a play for becoming the legacy system conversion tool of choice… | |
When the Web app is built and deployed, regardless of which route the developer takes, the legacy app won’t notice anything unusual. It’s as if the Expresso Server includes a fast typist sitting at a 3270 screen, taking requests from the Java client and sending the results back.
With Expresso, the app can be deployed as 2-tier or n-tier. In addition, the Expresso Server can service multiple back-end legacy apps simultaneously. Consequently, you can actually create a front end that appears to the user as a single app, when, in fact, the back end comprises multiple legacy apps shepherded by the Expresso Server. For truly large operations, the Expresso Domain Server can manage multiple Expresso Servers, and even provide load balancing.
Finally, Blue Lobster’s Mako system—which has both client and server components—offers yet another non-invasive means of Web-enabling a legacy app. Mako overcomes one of the more significant problems with Web-enabling CICS apps: mapping the Cobol-written “copybooks” (which define input and output formats to CICS transactions that are manipulated via 3270 sessions) to the language that will be used to build the Web presentation. Mako allows developers to download the copybook into the Mako development system. Mako parses the copybooks and automatically creates a Java presentation layer. In addition, a Java legacy business object (LBO) is created that represents each transaction. These LBOs are managed by the Mako Server, which communicates with the legacy app through the CICS ECI (external call interface).
Invade old code and conquer
Of course actual transformation of a legacy app takes a bit more effort. A transformation system actually requires a methodology to govern the procedure. Examples include Relativity’s RescueWare and Inter-comp’s JavaMaker. Transformation methodologies attend the software tools in these products. Both start by making an inventory of the legacy system, then go on to parse the source code, translate it, then finally deploy and test the app.
Inventory of the legacy system involves reviewing all the source code, any associated data files (whether databases or flat files) and support programs. After that, parsing can involve not only the Cobol code, but embedded SQL statements, DDL (data definition language), and JCL (job control language) code as well. At this step, “clusters” of code— related functions that have a high degree of internal cohesion— are identified. They’ll be the building blocks for future distributable objects.
The result of the parsing process then goes into a repository. Guided by the information gathered there, the Cobol code is translated to Java code. Of course, more than Cobol code needs to be translated, and the translation app must recognize various Cobol dialects. Embedded SQL, DDL, and BMS (bitmapped screen) data must be translated as well. In some cases, the data itself is migrated from the legacy database to Oracle, SQL Server, Access, etc.
The Java objects are assembled into a new version of the legacy app. Objects can even be connected to form an entirely new app based on a reassembling of the business logic from the old. Finally, the app is deployed and tested.
Actual methodologies are more detailed than what I’ve shown. For example, RescueWare defines a planning and estimation step after the inventory step. In addition, RescueWare’s methodology translates interface code, business process code, and app data in separate steps. In the JavaMaker methodology, developers review the results after parsing, then suggest changes or refinements.
…But you don’t have to go all the way
Not every organization opts for wholesale transformation of an app. And even products that were designed for complete remakes, such as RescueWare, are often used to translate only part of the app. But such partial transformations can be tricky. If you move a piece of business logic from a legacy app to a middle-tier component, you leave a hole behind. So the software that assists in this kind of transformation must not only produce the new, independent component, it must also sew up the hole left behind in the app.
And you have to put some thought into deciding which portions of an app to extract. For example, one company used RescueWare to extend a legacy Cobol app, but wanted the security portion of the app to remain untouched on the mainframe. RescueWare was able to extract the business logic to Java apps and servlets, while leaving the security code in place (and intact).
Of course you could accomplish both full and partial brain transplants with a variety of languages enabled by COM or CORBA. However, if your plans include the Web, using Java offers several advantages. Java grew up on the Web, and it now features mature and well-developed Web support. With maturity comes real IDEs, and you can choose from a new wealth of Java development environments: JBuilder, Visual CafŽ, V++, and VisualAge, to name a few. Developers can choose the IDE they prefer, yet be sure that the Java code generated by any of the transformation tools will be compatible with the tools they already have. And if you’re working in a heterogeneous deployment environment, no other language will get you closer to the “write once, run anywhere” promise.
Meanwhile, Microsoft’s proprietary COM standard is tightly tied to the Windows OS. Of course Microsoft’s flavor of Java supports COM, but support in the Java world peters out beyond that. On the other hand, if you want to use CORBA you’re in great shape. Recent trends appear to be unifying EJBs and CORBA. The Java 2 platform includes a CORBA 2.0 implementation; and CORBA 3.0 has adopted the EJB model. Finally, a growing host of middle-tier app servers already support both EJBs and CORBA objects. The choice between EJB and CORBA may soon become a non-issue.
Given the new spectrum of solutions available, there’s no reason not to Web-enable a legacy app using Java. If you want to put a pretty face on your CICS app, you can do that. If you want to translate pieces of the legacy app for Web exposure, you can do that. And if you want to translate the whole shebang, you can do that, too.
Rick Grehan is a programmer/writer in the Discover Products group at Metrowerks Inc. Rick was a Senior Editor at BYTE Magazine (where he wrote the JavaTalk column) and at Computer Design Magazine. He can be reached at rgrehan@top.monad.net.
| © 1999 FAWCETTE TECHNICAL PUBLICATIONS, all rights reserved. | |
 |
 |
| Company | Product | Description | |
|---|---|---|---|
| Intercomp Ltd. Herzlyia, Israel www.intercomp-sys.com | JavaMaker | Invasive. Full or partial conversion of legacy apps, including app extensions (SQL, DB/2 ISAM, and CICS, for example). | |
| Relativity Tech., Inc. www.relativity.com | RescueWare | Invasive. Full or partial conversion of legacy apps, including extensions(BMS, JCL). Can generate languages other than Java (VB, C++). | |
| Conextions www.conextions.com | Expresso | Noninvasive. Watches user interaction with legacy app screens and builds automation objects accordingly. Can access a legacy app as if it were a relational database. | |
| IBM www.software.ibm.com/java/ | VisualAge for Java | Enterprise Access Builder can build DB2-aware beans. | |
| Computer Associates www.cai.com | Opal | Noninvasive. Intelligent runtime allows for super-thin clients. |
| Products for Web-adapting your apps. You can use all these products to build Java-based, Web-based versions of your legacy applications. You can also use many of them to support other development environments as well, though. For example, Conextions’ Expresso can produce code in Visual Basic, Forté, Visual C++ and more. |
| Vendors are giving their Java tools legacy chops |
|---|
| The Java world is making a play for becoming the legacy system conversion tool of choice. For example, Java became available on the AS/400 in February ’98, and IBM is already promoting it as the “RPG of the future for that platform.” Ironically, Java and the AS/400 share some architectural similarities, such as being built on a two-layer architecture. For an executing Java app, the upper layer is the bytecode representation of the program. Bytecodes are executed within a JVM, which contains all the target-specific (hardware dependent) logic. Meanwhile, apps on the AS/400 execute in the upper layer-called OS/400-which communicates to a lower-level, hardware-dependent layer, called SLIC (System Licensed Internal Code). Some impedance mismatches intrude, however. For example, it took two years to bring Java to the AS/400, the main stumbling block being that OS/400 lacked thread support. In addition, once the engineers on the porting project decided-for performance reasons-to implement the AS/400 JVM in the lower-level SLIC layer, rather than running the JVM under OS/400, they were faced with the fact that the Javasoft JVM was written in C, while SLIC was written in C++. So the engineers had to make several enhancements to implement a SLIC-level JVM. Some legacy upgrades require no more than access to the mainframe database. In such cases, IBM’s VisualAge for Java can help. VisualAge provides support through IBM’s NCF (network computing framework) for accessing a DB2 database through a JDBC/DB2 interface. VisualAge’s Enterprise Access Builder will query a DB2 database, then query the tables within that database at the user’s selection. VisualAge can generate access beans for tables selected within the database. You can then use VisualAge’s Visual Composition Editor to construct applets that access the DB2 database. |
 |
| A method to your Java. Want to transform all or part of a legacy app to a Web-enabled Java one? Automated transformation products use a methodology similar to the one shown here. First, an inventory of the app is taken. Next, the source is parsed and a repository created which holds the knowledge obtained by the parsing process. This repository feeds the next step, in which the actual Java code is created. The created objects (usually EJBs) can then be assembled into your final, Web-aware Java app. |
