There are thousands of Windows Forms applications conceived and developed before the Internet era. One of the challenges that the developers of these applications face is the need to update their software to work in a connected world before their customers’ needs for Internet-enabled applications force them to move to other applications or platforms. Compounding the problems is the fact that many of these developers live on software maintenance revenues rather than new software sales, meaning that they have to upgrade their software without any guarantee that their investment will result in additional revenue.

Against this backdrop, I worked with a company that we’ll call Purchasing Management Company (PMC) to help rearchitect its purchasing management software (I’ll call it PMS). Let’s take a look at the company’s software and the valuable lessons it learned when considering the options for moving its PMS legacy Windows application to the Web.

The scenario
PMS has been deployed in several hundred companies over the last several years. Originally developed in RM/Cobol to enable it to run on multiple platforms, the company migrated the code base to MicroFocus COBOL three years ago and refocused it to support Windows clients, COM business objects, and multiple back-end databases. At the time of the rewrite, PMC’s clients had no interest or need to Internet-enable the PMS application. PMS was designed to serve the needs of a corporation’s internal purchasing department, and it interfaced with other corporate systems that handled most of the interaction with the outside world.

New customers mean new requirements
But as PMC sells its application to more small and midsize companies, they’re demanding out-of-the-box Internet integration. These customers want to access the PMS information from a browser so that they can use the system from another place in the office, a customer location, or home. They also want to give their suppliers and internal departments access to the information without requiring them to install a full-blown Windows client application on the desktop. As PMC investigated its options, it came up with three that were viable.

The first option was to simply install the application on a central server and use either Citrix or Microsoft Terminal Server to allow internal and external users to run the application from there. Although simple to implement, this option had two major flaws. First, the application was never built to allow different levels of access because it was intended to be used only by internal purchasing agents. Exposing it using a terminal service client meant opening up all of the application to any user. The second major flaw is the terminal services licensing cost. This option would require them to buy and support terminal services licenses for all of their clients and to deal with installation and support issues surrounding not only the license itself, but also environmental issues like printing and e-mail integration.

When it became clear that some kind of rewrite would be required to move this application to the Internet, PMC’s developers first looked at porting the application to .NET and adding the necessary security infrastructure during the rewrite. Unfortunately, a port to .NET using MicroFocus COBOL wasn’t even feasible until the middle of 2003. MicroFocus has announced that its .NET compiler won’t be available for general distribution until mid-2003. Fujitsu’s NetCOBOL for .NET is the only other COBOL vendor to announce support for Microsoft .NET and ASP.NET, including Web services. Its COBOL compiler is available now, but although the language itself is the same, the environment and tools used to generate screens and handle the UI is different between the compilers. A straight port to either COBOL compiler would be a major undertaking that would take months to complete.

The final option they considered—and ultimately opted for—was to use the existing COM-based business objects but to expose them from a new Web layer built on top of ASP.NET. This option allows them to reuse the existing business processes encapsulated in the COM objects, but add a new set of .NET wrapper classes that implement security and expose the underlying processes to a Web application written in ASP.NET. This architecture also positions them positively for the future. After this revision, they will be able to use the same .NET wrapper classes as the basis for Web services that will allow them to add EAI capabilities to the application. They’re even prototyping a new set of .NET Windows Forms that access the existing business objects and add the ability to dynamically download application updates.

Lessons learned
The developers at PMC have learned some valuable lessons while considering their options for moving their legacy application to the Web. Although all of these may not apply to you, they’re certainly worth considering in your development environment.

  • Always architect an enterprise application to allow differing levels of access, whether you expose them or not. If the information is worth managing, you will inevitably need to allow people with different permissions to see or use the information differently. You can save yourself even more time in .NET by architecting the application to use Active Directory to manage users and groups, eliminating the need for you to maintain a different set of credentials within your application.
  • Recognize that adoption of .NET does not mean that COM goes away. In fact, it’s more important than ever to understand how COM works in an enterprise environment. Make sure that someone in your organization understands how to use COM packages, transactions, and other key elements of the COM infrastructure.

PMC would never have been able to use this approach to move its application to the Web if the developers didn’t have the foresight to architect their application in multiple tiers. The separation of the Windows Forms UI from the COM business objects was the key decision that allowed us to implement additional interfaces without having to resort to a massive code rewrite first.