一套可行的Oracle Forms — ASP.NET迁移方案

摘要：许多老旧的Oracle Forms程序都面临着更新换代的压力。然而更大的压力来自于Oracle Forms，这一曾经辉煌的快速开发平台已完全过时这一事实。本文通过分析Oracle Forms和ASP.NET的部分功能， 提出了一套由旧的Oracle Forms系统渐近地、逐步地迁移向使用最新技术的基于ASP.NET的应用程序的技术方案。该方案可以分期地实施， 并在实施过程中最大化地降低用户的不便性。本文旨在通过该方案为那些受困于老旧的Oracle Forms程序的维护人员指出一条跳出围城的路子。

关键词：ASP.NET； Oracle Forms； 迁移； 渐近； 遗留系统； 无缝切换

中图分类号：TP311 文献标识码：A文章编号：2095-2163（2014）04-0106-03

Abstract：Many legacy Oracle Forms-based applications are facing tremendous pressure of evolution. However， greater pressure comes from the fact that Oracle Forms， the once popular RAD development environment， has become an obsolete technology. This article analyzes some features of Oracle Forms and ASP.NET， and introduces a migration plan from legacy Oracle Forms applications to newer ASP.NET-based applications that utilize latest technologies. The plan can be carried out progressively， in phases， and minimize inconvenience to the end users during the migration. Through this plan， this article intends to give some guidance to those confused developers who are maintaining Oracle Forms applications.

Key words：ASP.NET； Oracle Forms； Migration； Progressive； Legacy Systems； Seamless Switch

0引言

Oracle Forms作为一项诞生于上世纪七十年代的终端实用技术，以其简单的编程模式以及与Oracle数据库的紧密集成，曾在上世纪末、本世纪初广泛用于数据密集型应用程序的开发与实现。而且，迄至目前，许多程序也仍在使用。然而，随着各行业的业务运营规则及运营模式的不断发展变化，支持该项业务的Oracle Forms应用程序也必然要实时更新以满足业务需求的升级改变。这些程序的维护人员大都面临着一个重要抉择：是继续扩充现有的Forms程序，还是迁移到一个现代化的开发平台上（比如.NET或Java）？但是这种迁移却将导致一定压力，而这种压力则主要来自于以下几个方面：

（1）僵硬的用户界面。依靠Java Applet来显示其用户界面的机制， 不能充分适应当今软硬件的发展现状，比如高分辨率显示器（高于1024 X 768像素）的广泛应用，不同用户对不同设备的个性喜好，而这些设备则包括了各种尺寸的普通电脑屏幕、笔记本电脑、Tablets、智能手机等等。

（2）日趋不兼容的运行环境。在当今的操作系统及浏览器中，寻获可以运行Oracle Forms程序的浏览器及Java版本的难度已明显增大。

（3）日趋不兼容的开发环境。Oracle Forms Builder 10gR1 （9.0.4）[1]在Windows XP上可以顺利运行，但在Windows 7上却不能正常工作。而Windows XP的使用却正在成为历史。

（4）有限的功能。Oracle Forms，作为一个4GL快速开发工具，由于其性能高端，缺乏现代化程序编制中应该具备的众多设置，进而也欠缺了一定的灵活性。比如，Oracle Forms只有可数的几项支持SOAP Web Service的功能，这就使其只能作为Web Service的客户端，并且还要编写大量代码以实现底层SOAP协议的操作处理。

（5）不适于团队开发的源代码格式。Oracle Forms的源代码采用非文本的二进制格式。当代的团队开发模式经常会涉及源代码的合并（Merge），既可以是在同一代码分支中不同程序员之间的合并， 也可以是在不同代码分支之间的合并。但是采用二进制格式的Oracle Forms源代码却无法借助于任何合并工具的现有成果，而与其有关的全部合并只能依靠程序员的记忆或额外的文档经由纯手工的操作来实现。不仅耗时，而且容易出错。

（6）昂贵的升级成本。历史上几次主要的Oracle Forms升级都涉及到为数众多代码的改动或者运行环境的改变，由此而导致了漫长的开发，测试的周期。

（7）稀缺的程序员资源。时下的就业市场上具有Oracle Forms开发经验的程序员日益稀少。仅存的有限数目的Oracle Forms程序员，也在逐渐转换到其它的开发平台上去。

1Oracle Forms到ASP.NET的迁移选项分析

1.1选项一：用ASP.NET完全重新实现

这一选项显然耗资费时，往往需要几个到几十个人工周期年。如果投入很多人力来加速开发，却少有企业能够担负起如此一笔预算。但若只是投入较少人力来缓解预算压力，工期又会无限延伸。而且，又由于项目范围大、工期长，最终产品对用户需求在满足上的欠缺（包括设计缺陷和需求分析缺陷）将会集中突显，由此形成较大的负面影响。

但是，该选项也并非没有可称道之处。由于一切都是崭新起点，设计者既可以吸取旧程序中的经验教训，也可以自由选择当前各种最新技术，包括自由选择体系结构。并且如果设计开发管理均显优良，新程序即可达到较高的可维护性。

1.2选项二：借助于某些迁移工具来将Oracle Forms程序“翻译”到ASP.NET

相对于选项一，运用这样的工具无疑会大大地加快迁移周期，然而，这种迁移也并非全自动的过程，诸如Forms2Net（www.forms2net.com）工具。其工作原理主要是实现从Oracle Forms form到ASP.NET Web Form的一对一翻译，但由其生成的Web Forms通常要经过些许微调才能进入正常工作。若要生成的Web Forms看似更接近于普通的Web程序而非Oracle Forms程序，就需要加入更多的人力。据称，相对于完全手工迁移，Forms2Net可以节省约75%的人力。

值得一提的是，由此类工具协助生成的代码，体系结构上却并不完善。例如，这些工具通常要借助于其自身的一定量程序库来填补Oracle Forms和ASP.NET体系结构上的差别，从而使得生成的代码依赖于这些额外的程序库，由此必将提高对新员工的培训成本。 再如，从数据访问上，此类工具往往会使用某一种数据访问机制（比如基本的ADO.NET），这就在一定程度上限制了另外一些更为现代化的数据访问机制（比如NHibernate、 Entity Framework等）的选择使用。

针对该选项的价值评估，其预算大约相当于选项一的30%～40%，而见效周期却通常相当于选项一的25%。但由于这些移植工具只能起到辅助作用，且每个Form都需要经过或多或少的手工移植才能正常工作，无形中必然增加了漏洞（Bug）机率。另外，由于迁移过程是页面对页面的“一对一”翻译，新程序至少在总体流程方面必将受到旧程序的设计制约。同时，代码中也必将充斥着迁移工具“注入”的各种与业务逻辑完全无关的“噪音”代码。并且，用户虽然可能较早地开始使用新程序，但是由于新程序是由旧程序逐屏翻译得来的，在用户体验上也应该与旧程序较为接近。

1.3选项三：渐进式的迁移

笔者目前尚未见过有类似迁移方式的研究文献，因而本文将致力于这一迁移方式的探索分析。其可行性成果在于：程序功能可以渐进地，长期性地从Oracle Forms迁移到新的基于ASP.NET的程序中；新的ASP.NET程序具有采用任何体系结构，任何程序库，以及任何框架的自由；并且在迁移过程中，新旧程序可以并行存在，同时允许用户由旧程序向新程序进行“无缝”（无需重新登录，无需重新定位数据记录）切换。企业可根据自身人力物力情况而自由调整前期项目的规模。基于此，由于新老程序可以同时存在，新程序可以在很短的时间内付诸运行，哪怕最初只有可数的几样功能。第4期崔阳华：一套可行的Oracle Forms - ASP.NET迁移方案智能计算机与应用第4卷

另外，由于整个项目可分为无数个小项目来分期实施，每一期项目既可以包含新功能的开发，也可以包含对前期项目缺陷的修复。尤其是，在程序维护性方面，该选项将不仅具有选项一的所有优点，而且，早期不当的体系结构设计也会在实践中得到及时的发现与修复。仍然需要指出的是，在用户体验上，用户可以很早就开始使用新程序上的新功能。尽管在相当长一段时间内，用户将不得不同时使用新旧两个程序并在二者之间来回切换，但是切换的过程是流畅自然的，而且无需重复输入登录口令。

综上所述。三种迁移方案在若干性能方面的优缺点对比则如表1所示。

（6）其后的新程序中每次添加新功能后，可重复步骤（3）， 即在旧程序中添加一个指向新功能的连接。这样，在一段时间之后，新程序中的功能就日渐增多，旧程序中功能将日渐减少。直至某一天，旧程序将完全废弃。企业可以根据自身预算及其它因素，具体决定整个迁移过程的进行速度。

3实际应用性能分析

将本文所述渐进式迁移应用在一个基于Oracle Forms 9.0.4的医疗程序中。但是由于最初需求分析的不够充足，程序中某一配型模块不仅很难使用，还经常引入错误数据，而且也跟不上该医学技术近几年的最新发展成果，于是决定对此模块进行修改。鉴于这是一个较大项目，在老旧的Oracle Forms平台上重写将会是资源上的一个极大浪费。所以最终选择将这一项目作为渐进式迁移的试验项目。该课题共耗四个人年左右（四人团队，一年时间）。项目结束时，重建模块在一个崭新的基于ASP.NET的程序中获得实现，旧程序中原有的模块则随之得到了隐藏。用户若要访问新的模块，既可以直接登录到新程序中，也可以从旧程序中通过点击相应的菜单项而流畅无缝地切换到新程序中去。产品应用之后，已经收到了众多好评。该项目成功地验证了渐进式迁移策略的可行性，为日后的不断缩减旧程序，并日渐扩充新程序奠定了一定的理论及实践基础。

4结束语

本文讨论的这套迁移机制，其最大特点在于保持整个迁移进程进度的灵活性而同时又不会给终端用户带来任何不便。另外，从广义角度来说，这套机制对于从Oracle Forms向Java平台迁移也具有重要的指导意义及借鉴价值。

参考文献：

[1]Oracle Application Server 10g – Integrating Oracle Reports in Oracle Forms Services Application.http：//www.oracle.com/technetwork/database/migration/frm10gsrw10g-132606.pdf.

[2]Oracle 9i AS Forms Services - Best Practices for Application Development. http：//www.oracle.com/technetwork/developer-tools/forms/documentation/bestpractices9i-134677.pdf.

[3]PL/SQL内置函数UTL_ENCODE.BASE64_ENCODE（） 的说明文档：http：//psoug.org/reference/utl_encode.html.

[4]PL/SQL内置函数DBMS_OBFUSCATION_TOOLKIT.DES3ENCRYPT（） 的说明文档：http：//docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_obtool.htm.