一套可行的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.