Web-Enabling Legacy Applications
Marcel Gagné You've just spent a small fortune making sure that after January 1st, 2000, you'll still be in business. A lot of time and money has gone into this project. The only problem is that when all is said and done, your old application looks just as unexciting as it did before you started your Y2K conversion. Making your old applications available to a distributed networked environment, limiting logins by providing small Web interfaces to simple tasks, and generally putting a fresh face on what have become dull applications by today's standards, are additional reasons for Web-enabling legacy applications. Go ahead; turn on your green-screen dumb terminal and page through your menus. You'll find other reasons, as well. Simply put, the Web's friendly face is everywhere and many people in your office will be familiar with its workings. It makes sense to leverage this familiar interface to enhance your day-to-day business requirements. By making those old programs browser friendly, you make it possible to deploy a centralized information solution, or intranet. The browser then becomes your business's one-stop shop for providing the software that runs your organization and (this is where it gets exciting) disseminating important information. "Stop right there," you say. "How difficult is this going to be?" In theory, it's very simple. The general idea goes something like this. Between the browser and your old applications, deploy another set of applications (Perl, Java, or some form of CGI) to glue both sides together. Presto! Your old application has entered the browser age! There is perhaps a bit more to it than that, so I will explain. Analyzing the Need The first thing to consider is whether you should even bother. Your ugly old application may really be all you need. Sure, the dumb terminal looks ancient, but a Windows terminal emulator or xterm can make the application accessible without a lot of rewrite effort. Don't underestimate this notion. A number of years ago, I went to a computer show where the company I worked for had a display of their application. We were showing off the software on a green-screen Wyse terminal. A couple of booths over, our competitor had their wares on display, but they were showing off their dumb terminal application on a PC running Windows. Guess whose software looked more high-tech? The aesthetics issue can be important. Systems administrators are generally more interested in a product that gets the job done than in how the product looks. In a flashy, hyperactive, Web world, however, looking at something that appears to have been created in the sixties can be demoralizing for users. Some users may feel that they are being left behind by being forced to work with something that, to them, is obsolete. With these thoughts in mind, maybe you don't need to convert everything. By carefully evaluating your environment, you will find that certain programs are better suited to the browser format. For instance, a call center filling in the same form over and over again doesn't need a complex series of menus. Another example is a user who needs to run a small handful of reports every day. This is an ideal application for a Web-driven interface. Is your business distributed across several locations? Persistent telnet connections may not be the most attractive solution. They can be slow, and they can impact performance for both the end user and the system. On many legacy systems, database licensing is handled on a concurrent user basis. For casual queries, it does not make sense to have a user logged on all day long. Several people can make use of a single license or two if you use a form-driven browser interface. With a Web POST request, the connection is active for as long as the request is being filled. Upon completion, the connection is severed, and the user is essentially logged off, thus making the license available to the next person. If you were nodding at any of the preceding suggestions, then you probably qualify under the need category. Now, let's look at how to accomplish the task. When undertaking this kind of a project, you have to know what you are starting with. The likelihood is that under all that GUI glitz, it's just your old application doing what it always did. This means you will need a thorough understanding of what your software does. System administrators know that there are many ways to do everything. The same goes for your Web conversion. You can make it as simple or as complex as you want. The telnet session in a Web page example that follows is the simplest way to Web-enable your applications. Your Web-Enabler's Toolkit The easiest way to get your people on board is to start thinking of your application as part of a larger intranet concept. The old dumb terminal app then becomes one stop in a larger information center. There are many browser-based telnet applications. As with so much in the wired world these days, the costs range from free software distributed under the Gnu Public License (GPL) to commercial applications costing a few hundred dollars per seat. Look for the Web sites of commercial alternatives at the end of this article. For starters (at the financial bottom of the scale), try:
http://www.first.gmd.de/persons/leo/java/Telnet/ This little Java applet (created by Matthias L. Jugel and Marcus Meißner) might be all you need to make the jump. Take a look at Figure 1 for a look at a legacy screen accessible from a Web menu. You'll notice that there are few buttons at the top of the telnet app. These can be programmed on your Web page to issue custom commands back to your legacy software. For instance, I created an administrator's quick command bar. You could also create small function keys if your old terminal application made use of them. See Listing 1 for an example of my applet tags. Notice buttons 4 through 7. Commonly used keystrokes or shortcuts to other menu levels could be embedded in your button bar, enhancing the "point and click" feel of your quick Web-converted application. Several commercial emulators are also available. While the example in Listing 1 is vt320/ANSI, others also serve up both ANSI and 3270 emulations. The commercial alternatives I tested offered (in some cases) more emulations, color control, and additional server-side functionality. For instance, check out Century Software for their TinyTERM WebServer edition, or JSB Software Technologies for their Multiview 2000 product. In the 3270 world, you have ScreenSurfer and Platypus Partners, to name just two. Addresses for all of these can be found in the references section at the end of this article. The Web-based terminal emulator is the simplest and easiest way to Web-enable your legacy software. The next method involves writing HTML forms and CGI scripts to interface between your browser and the old software. A Corporate Phone Book Example Having recently tackled a few Web conversions, I found it wasn't generally a case of taking an entire package and revamping it for the Web. In most cases, it involved taking applications that were ideally suited to the Web-centric world and moving only those to the new interface. Previously I mentioned reports, which tend to be a popular candidate for Webification. Another example (which we will look at here, is an employee telephone book. Why have a dozen or more people logging in when all they really make use of is the online phone book? Converting this single application saved processor resources and a couple of thousand dollars in database licenses. Listing 2 is a simple Web form designed with a few search fields. I haven't dressed it up a great deal, but it pretty much represents what the users see when doing a phone lookup. Listing 3 is the Perl script called by the HTML form. Of particular note are the following lines (roughly halfway down the script).
# Now, pass all this to UniVerse and return search results.
$pickreturn = `cd /home/SCIWEB; /home/uv/bin/uv
"SEARCH.PHONE.BOOK $search_params"`;
print $pickreturn;
Our system uses a UniVerse database (based on the PICK database). What we are doing here is passing a delimited list of parameters from which our PICK basic program will generate a simple text list of names and phone numbers, much the same as it would have done in the original program. These results however, appear in a browser window. In the span of a few seconds, the user logs on, performs a search, and logs out. This example could be even simpler. We could be capturing the output of a simple report in the same way. Using these techniques, it is possible to create complex Web forms to address many different levels of complexity. Start Over? With some applications, the question becomes whether you should just start over with new code. This is often the hardest thing to do. In the Windows world, we've grown accustomed to throwing out our software every time a new release shows up. In the corporate IS shop where our main business application was developed and kept us going for years, it can be much more difficult. Despite our emotional attachment to those things we developed ourselves, we must consider the issue of cost. Mainframe software can cost tens and even hundreds of thousands of dollars. You don't let go of something like that easily. Sometimes, though, it becomes necessary to view all software very critically. If after extensive cost-benefit analysis, you cannot adequately justify your old tools, then no amount of face-lifting is going to hide the ugly truth - that it's time to start over. If, on the other hand, you can honestly say that the software still does what you need, then a makeover may be what you need to convince your users. References The Java (tm) Terminal Applet:
http://www.first.gmd.de/persons/leo/java/Telnet/ Century Software (TinyTERM WebServer Edition):
http://www.censoft.com JSB Multiview 2000:
http://multiview.jsb.com JET 3270 Emulators (Platypus Partners):
http://www.platypuspartners.com ScreenSurfer (3270 emulation):
http://www.screensurfer.com Telnet Video Terminal Information (Richard S. Shuford's page at the University of Tennessee:
http://www.cs.utk.edu/~shuford/terminal/pc_emulation.html
About the Author
Marcel Gagné lives in the mythical city of Mississauga, Ontario. There he is president of Salmar Consulting Inc, a systems integration and network consulting firm. He also writes science fiction and fantasy, and edits TransVersions, a science fiction, fantasy, and horror magazine. He has loved UNIX and all its flavors for more than 15 years now and will even admit it in public. He can be reached at mggagne@salmar.com. You can find out more from his Web site www.salmar.com.
|