在Internet时代之前，就有成千上万个Windows窗体应用程序被孕育和开发出来。这些应用程序的开发者现在所面临的一个挑战是：在客户需要使用Internet应用程序而迫使他们改用其它应用程序或者平台之前，就需要升级他们的软件，使其能够适应网络的要求。和这些问题密切相关的是，这些开发人员中的许多人都靠软件维护的收入获益，而不是靠软件销售的收入，这就意味着他们不得不升级其软件，还不能保证其投资会带来其他的收入。
在这个背景下，我曾经为一家我们叫做采购管理公司（PMC）的机构工作过，帮助他们重新构建其采购管理软件（我把它叫做PMS）。现在让我们来看看这个公司的软件，学习一下如何将其PMS的原有Windows应用程序迁移到Web上。
在过去几年中，PMS已经被部署在几百个公司里。这个公司原来使用RM/Cobol编写代码让其能够运行在多个平台上，而三年前又将这些代码移植到了MicroFocus
COBOL上，并让其能够支持Windows客户、COM商业对象和多后端数据库。在重新编写代码的时候，PMC的客户不感兴趣也不需要使用Internet的PMS应用程序。PMS被设计用来满足企业内部采购部门的需要，而且还有和其他合作系统的接口，这些系统负责处理大多数和外部事件的交互操作。
但是随着PMC将其应用程序卖给了更小规模的和中等规模的公司，他们正需要即开即用的Internet集成。这些用户想要从浏览器访问PMS的信息，这样他们就能够使用办公室里另一个地方、用户所在地或者家里的系统。他们也想要为其供应商和内部部门提供访问信息的权限，而不需要在计算机上安装完整的Windows客户应用程序。由于PMC调查了其选择，所以它提供了三种可行的方法供选择。
第一种方法是简单地将应用程序安装到一个中央服务器，再使用Citrix或者微软的终端服务器（Terminal Server）让内部和外部用户从中央服务器运行这个应用程序。尽管这种方法实现简单，但是它有两个主要的缺陷。首先，这个应用程序从来都不是针对允许不同的访问级别而设计的，因为它只是设计用来给内部采购人员使用的。使用终端服务客户程序将它公开就意味着将这个应用程序的所有内容都对任何用户开放了。第二个主要的缺陷是终端服务许可证的成本。这种方法需要他们为其客户购买和支持客户服务许可证，还要处理和许可证本身相关的安装和支持问题，以及环境问题，例如打印和电子邮件的集成。
当把应用程序迁移到Internet需要在某种程度上重写代码时，PMC的开发人员在重写代码期间首先就要把应用程序迁移到.NET，并添加必要的安全基础结构。不幸的是，使用MicroFocus
COBOL编写的应用程序想要移植到.NET不到2003年中期是不太可能的。MicroFocus已经宣布其.NET编译器直到2003中期才会发布。而富士通公司用于.NET的NetCOBOL是唯一一个宣布支持微软.NET和ASP.NET以及Web服务的COBOL。其COBOL编译器现在已经有了，尽管语言本身是相同的，但是两个编译器用于生成屏幕显示和处理用户界面的环境和工具是不同的。向这两个COBOL编译器其中任何一者的直接移植将是一个需要数月才能完成的主要任务。
他们所考虑的最后一种方法——也是最最合适的选择——是使用已有的基于COM的事务对象，但是在ASP.NET顶层构建的新Web层将其公开。这个选项让他们能够重新使用原有的封装在COM对象里的事务处理，但是新增加了一套.NET包装类，用来实现安全和向使用ASP.NET编写的Web应用程序公开底层处理。这个结构也让他们在未来处于有利的地位。在进行过这样的改进以后，他们就能够使用相同的.NET包装类作为Web服务的基础，这些Web服务能让他们具有向应用程序添加EAI的能力。他们甚至还能作为新一套.NET
Windows窗体的原型，这些窗体能够访问原有事物对象，还能增加运用动态下载应用程序来进行升级的能力。
在将原有应用程序迁移到Web的过程中，PMC的开发人员学到了获益匪浅。尽管这些收益中不是所有的都能够适用于你，但是在你的开发环境里它们肯定是值得考虑的。
如果开发人员不能够以前瞻的眼光将其应用程序建立在多层结构上，那么PMC现在就不能够使用这种方法将其应用程序转移到Web上。Windows窗体的用户界面同COM的事务对象的分离，是能够让我们实现额外的接口而不需要重新首先大量编写代码的关键决定。
