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 softwarescreen 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...
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 codea 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 Servera 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 systemwhich has both client and server componentsoffers 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 firstname.lastname@example.org.
© 1999 FAWCETTE TECHNICAL PUBLICATIONS, all rights reserved.