One of the more practical reasons cited is the user interface. If you experienced some training challenges getting users to understand your legacy software's interface, the Web could put that behind you. The browser's interface means there will be no user interface training. This can be analysis software that demonstrates corporate expertise, a design tool helping to select among your products, or even your accounting software yielding a customer's order status. The pressure is mounting to port such software to Java. Its compatibility to the Web is unsurpassed, and it is the language of the future--or is it? The trade journals are certainly beating the drum, but the skeptics are starting to come out of the closet, including in my own article Java, a Balanced Perspective."

For a thousand lines of analysis code, a Java development project may be the ideal approach to evaluating a new langua ge, but software that reflects a company's core competence may have passed 100,000 lines as it accumulated years of evolving knowledge. If the conversion budget is not in the checkbook, or the spirit of adventure is similarly absent, then we can discuss alternatives.

One of the first, sometimes with a clever name such as middleware, requires developing a Web interface so users can simply operate your software across the Internet. This Web interface is often back to Java as the programming language, or perhaps ActiveX, and the scope of effort varies widely depending on the I/O complexity and speed of your legacy software.

Your software's speed is an issue because a browser will produce a nondescript error message if your middleware fails to produce a response within 120 seconds. There is sometimes a way to get around this, but the problem is inherent to the Internet as a stateless system that doesn't track users or the status of their requests. Like so many surprises involving nascent technology, t his annoying detail is sometimes revealed after middleware has been developed that is otherwise functional.

Now for an alternative that is cheap and low-risk, but only if you are solving a common subset of the Web-interface problem. For this alternative, the legacy software you wish to connect to the Web cannot be iterative, like a spreadsheet program, where the user tries an input, gets a result and immediately tries another input based on the result.

Your software can:

• produce an analytical result, like a finite analysis program;
• simulate a test and produce a report;
• evaluate application criteria to yield a product selection diagram;
• pass a query to your accounts receivable to produce a customer statement, or
• anything else where the basic architecture is: user input -> software process -> user output

Step 1: Design Web pages to collect the user input, typically through online forms. This can include simple fill-in fields, perhaps with a few snippets of Javascript for entry validation, and links to help pages to explain the desired entries. Pick lists and buttons can replicate much of your legacy software's existing user interface. You can include file attachments from other application programs or simply suggest a clip-and-paste into Web form fields.

Step 2: After the user presses the "Submit" button, even the most primitive Web server will produce an e-mail message for your mailbox with the user's selections. This message is simply ASCII text in a repeating format that lends itself to straightforward parsing. You could probably write in a day a parser that produces an input list in a format palatable to your legacy software, assuming, of course, that it can read input from a file.

Step 3: You now run your legacy software and specify the input data file parsed from the e-mail message in Step 2. You can clip and paste the result into an e-mail message back to the user, or you can write post-processor to your legacy software that does it automatically. Remember that the e-mail message you produce is almost always just ASCII text, and most e-mail software provides a way to add messages into their queues. If your result requires graphics, you produce the file in the format your users want and attach it to the message.

Step 4: The user gets your response as an e-mail message. In the case of an iterative program, this would be unacceptable since your users would prefer an instantaneous response on a Web page. Except for those cases, the proposed approach is usually superior when you consider what engineers would do with the result of your legacy software if the result appeared as a Web page. They would typically save the resulting Web page to their hard drives, and then do something with it (paste it into a report, input it into their software programs, etc.). Their e-mail programs are already set up to gather a nd store information, and sometimes to pass the info to the next step. Viewing a Web page result is not.

Steps 2 and 3 can be automated by running your legacy software in an endless loop that either runs the parser if an e-mail message is found in a specified mailbox (and processes the resulting input data file) or loops to check for the message again.

If you are looking for a quick proof-of-concept demo, look to your accounting software. Customer requests for order status or statement of account are hardly iterative, and most serious accounting software comes with a 4GL or database development environment for customization. If the report generator reads report specs from an ASCII text file, for example, you may only need to write the e-mail parser. Produce the online form for customers to request an order status or statement of account, and you're done.

Once that is up and running, you can tackle the more complex I/O of some of your company's remaining legacy software. You can gather more support after you demonstrate total success on a small project than partial success on a big project.

A few words about security. The output of your legacy software can contain sensitive information--for example, the customer's statement of account in the above example. The first level of security simply requires the user to enter his or her invoice number for the open order status, the account number for a statement of account or some other piece of information that only the user is likely to know. Although this piece of information is hardly a secret, you may be surprised how many of your customers will prefer this to the next level of security, remembering a password. For more security, the output message of your legacy software could use S-MIME, an e-mail encryption standard. For even more security, your message response could be sent on a virtual private network (even if the request was originally a Web form). Such virtual private networks are more secure than anything on the Internet, and they transport many billions of dollars worth of sales orders and purchase orders each year using the Electronic Data Interchange (EDI) standard.

Not only is the approach described in this article simple, reliable, cheap, secure and quick to implement, but consider these other benefits:

• No server code is required as would be the case with interactive Web pages. This makes you portable as server software and the companies involved continue their unprecedented pace of change.
• If your company develops analysis software, for example, this approach allows you to arrange online alpha tests with responses much faster and cheaper than distributing software. Even better, when a customer's input hangs the computer or wipes out Windows registries, your company's embarrassment is limited to a polite e-mail message thanking them for finding the bug.
• Human intervention can be designed into the process. If your legacy software can be misused by competitors to pry, you ca n include human oversight into the response that would otherwise be totally automated. Likewise, if certain inquiries speak to an exceptional marketing opportunity, the processing could be switched to humans in your marketing department. None of these options exist where the real-time response is a Web page.
• Except for the above interface enhancements going little beyond file reads, the bulk of your software needs no modifications because "If it's not broken, don't fix it."