摘要:許多老舊的Oracle Forms程序都面臨著更新?lián)Q代的壓力。然而更大的壓力來自于Oracle Forms,這一曾經(jīng)輝煌的快速開發(fā)平臺已完全過時這一事實。本文通過分析Oracle Forms和ASP.NET的部分功能, 提出了一套由舊的Oracle Forms系統(tǒng)漸近地、逐步地遷移向使用最新技術(shù)的基于ASP.NET的應(yīng)用程序的技術(shù)方案。該方案可以分期地實施, 并在實施過程中最大化地降低用戶的不便性。本文旨在通過該方案為那些受困于老舊的Oracle Forms程序的維護人員指出一條跳出圍城的路子。
關(guān)鍵詞:ASP.NET; Oracle Forms; 遷移; 漸近; 遺留系統(tǒng); 無縫切換
中圖分類號:TP311 文獻(xiàn)標(biāo)識碼: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作為一項誕生于上世紀(jì)七十年代的終端實用技術(shù),以其簡單的編程模式以及與Oracle數(shù)據(jù)庫的緊密集成,曾在上世紀(jì)末、本世紀(jì)初廣泛用于數(shù)據(jù)密集型應(yīng)用程序的開發(fā)與實現(xiàn)。而且,迄至目前,許多程序也仍在使用。然而,隨著各行業(yè)的業(yè)務(wù)運營規(guī)則及運營模式的不斷發(fā)展變化,支持該項業(yè)務(wù)的Oracle Forms應(yīng)用程序也必然要實時更新以滿足業(yè)務(wù)需求的升級改變。這些程序的維護人員大都面臨著一個重要抉擇:是繼續(xù)擴充現(xiàn)有的Forms程序,還是遷移到一個現(xiàn)代化的開發(fā)平臺上(比如.NET或Java)?但是這種遷移卻將導(dǎo)致一定壓力,而這種壓力則主要來自于以下幾個方面:
(1)僵硬的用戶界面。依靠Java Applet來顯示其用戶界面的機制, 不能充分適應(yīng)當(dāng)今軟硬件的發(fā)展現(xiàn)狀,比如高分辨率顯示器(高于1024 X 768像素)的廣泛應(yīng)用,不同用戶對不同設(shè)備的個性喜好,而這些設(shè)備則包括了各種尺寸的普通電腦屏幕、筆記本電腦、Tablets、智能手機等等。
(2)日趨不兼容的運行環(huán)境。在當(dāng)今的操作系統(tǒng)及瀏覽器中,尋獲可以運行Oracle Forms程序的瀏覽器及Java版本的難度已明顯增大。
(3)日趨不兼容的開發(fā)環(huán)境。Oracle Forms Builder 10gR1 (9.0.4)[1]在Windows XP上可以順利運行,但在Windows 7上卻不能正常工作。而Windows XP的使用卻正在成為歷史。
(4)有限的功能。Oracle Forms,作為一個4GL快速開發(fā)工具,由于其性能高端,缺乏現(xiàn)代化程序編制中應(yīng)該具備的眾多設(shè)置,進而也欠缺了一定的靈活性。比如,Oracle Forms只有可數(shù)的幾項支持SOAP Web Service的功能,這就使其只能作為Web Service的客戶端,并且還要編寫大量代碼以實現(xiàn)底層SOAP協(xié)議的操作處理。
(5)不適于團隊開發(fā)的源代碼格式。Oracle Forms的源代碼采用非文本的二進制格式。當(dāng)代的團隊開發(fā)模式經(jīng)常會涉及源代碼的合并(Merge),既可以是在同一代碼分支中不同程序員之間的合并, 也可以是在不同代碼分支之間的合并。但是采用二進制格式的Oracle Forms源代碼卻無法借助于任何合并工具的現(xiàn)有成果,而與其有關(guān)的全部合并只能依靠程序員的記憶或額外的文檔經(jīng)由純手工的操作來實現(xiàn)。不僅耗時,而且容易出錯。
(6)昂貴的升級成本。歷史上幾次主要的Oracle Forms升級都涉及到為數(shù)眾多代碼的改動或者運行環(huán)境的改變,由此而導(dǎo)致了漫長的開發(fā),測試的周期。
(7)稀缺的程序員資源。時下的就業(yè)市場上具有Oracle Forms開發(fā)經(jīng)驗的程序員日益稀少。僅存的有限數(shù)目的Oracle Forms程序員,也在逐漸轉(zhuǎn)換到其它的開發(fā)平臺上去。
1Oracle Forms到ASP.NET的遷移選項分析
1.1選項一:用ASP.NET完全重新實現(xiàn)
這一選項顯然耗資費時,往往需要幾個到幾十個人工周期年。如果投入很多人力來加速開發(fā),卻少有企業(yè)能夠擔(dān)負(fù)起如此一筆預(yù)算。但若只是投入較少人力來緩解預(yù)算壓力,工期又會無限延伸。而且,又由于項目范圍大、工期長,最終產(chǎn)品對用戶需求在滿足上的欠缺(包括設(shè)計缺陷和需求分析缺陷)將會集中突顯,由此形成較大的負(fù)面影響。
但是,該選項也并非沒有可稱道之處。由于一切都是嶄新起點,設(shè)計者既可以吸取舊程序中的經(jīng)驗教訓(xùn),也可以自由選擇當(dāng)前各種最新技術(shù),包括自由選擇體系結(jié)構(gòu)。并且如果設(shè)計開發(fā)管理均顯優(yōu)良,新程序即可達(dá)到較高的可維護性。
1.2選項二:借助于某些遷移工具來將Oracle Forms程序“翻譯”到ASP.NET
相對于選項一,運用這樣的工具無疑會大大地加快遷移周期,然而,這種遷移也并非全自動的過程,諸如Forms2Net(www.forms2net.com)工具。其工作原理主要是實現(xiàn)從Oracle Forms form到ASP.NET Web Form的一對一翻譯,但由其生成的Web Forms通常要經(jīng)過些許微調(diào)才能進入正常工作。若要生成的Web Forms看似更接近于普通的Web程序而非Oracle Forms程序,就需要加入更多的人力。據(jù)稱,相對于完全手工遷移,F(xiàn)orms2Net可以節(jié)省約75%的人力。
值得一提的是,由此類工具協(xié)助生成的代碼,體系結(jié)構(gòu)上卻并不完善。例如,這些工具通常要借助于其自身的一定量程序庫來填補Oracle Forms和ASP.NET體系結(jié)構(gòu)上的差別,從而使得生成的代碼依賴于這些額外的程序庫,由此必將提高對新員工的培訓(xùn)成本。 再如,從數(shù)據(jù)訪問上,此類工具往往會使用某一種數(shù)據(jù)訪問機制(比如基本的ADO.NET),這就在一定程度上限制了另外一些更為現(xiàn)代化的數(shù)據(jù)訪問機制(比如NHibernate、 Entity Framework等)的選擇使用。
針對該選項的價值評估,其預(yù)算大約相當(dāng)于選項一的30%~40%,而見效周期卻通常相當(dāng)于選項一的25%。但由于這些移植工具只能起到輔助作用,且每個Form都需要經(jīng)過或多或少的手工移植才能正常工作,無形中必然增加了漏洞(Bug)機率。另外,由于遷移過程是頁面對頁面的“一對一”翻譯,新程序至少在總體流程方面必將受到舊程序的設(shè)計制約。同時,代碼中也必將充斥著遷移工具“注入”的各種與業(yè)務(wù)邏輯完全無關(guān)的“噪音”代碼。并且,用戶雖然可能較早地開始使用新程序,但是由于新程序是由舊程序逐屏翻譯得來的,在用戶體驗上也應(yīng)該與舊程序較為接近。
1.3選項三:漸進式的遷移
筆者目前尚未見過有類似遷移方式的研究文獻(xiàn),因而本文將致力于這一遷移方式的探索分析。其可行性成果在于:程序功能可以漸進地,長期性地從Oracle Forms遷移到新的基于ASP.NET的程序中;新的ASP.NET程序具有采用任何體系結(jié)構(gòu),任何程序庫,以及任何框架的自由;并且在遷移過程中,新舊程序可以并行存在,同時允許用戶由舊程序向新程序進行“無縫”(無需重新登錄,無需重新定位數(shù)據(jù)記錄)切換。企業(yè)可根據(jù)自身人力物力情況而自由調(diào)整前期項目的規(guī)模?;诖耍捎谛吕铣绦蚩梢酝瑫r存在,新程序可以在很短的時間內(nèi)付諸運行,哪怕最初只有可數(shù)的幾樣功能。第4期崔陽華:一套可行的Oracle Forms - ASP.NET遷移方案智能計算機與應(yīng)用第4卷
另外,由于整個項目可分為無數(shù)個小項目來分期實施,每一期項目既可以包含新功能的開發(fā),也可以包含對前期項目缺陷的修復(fù)。尤其是,在程序維護性方面,該選項將不僅具有選項一的所有優(yōu)點,而且,早期不當(dāng)?shù)捏w系結(jié)構(gòu)設(shè)計也會在實踐中得到及時的發(fā)現(xiàn)與修復(fù)。仍然需要指出的是,在用戶體驗上,用戶可以很早就開始使用新程序上的新功能。盡管在相當(dāng)長一段時間內(nèi),用戶將不得不同時使用新舊兩個程序并在二者之間來回切換,但是切換的過程是流暢自然的,而且無需重復(fù)輸入登錄口令。
綜上所述。三種遷移方案在若干性能方面的優(yōu)缺點對比則如表1所示。
(6)其后的新程序中每次添加新功能后,可重復(fù)步驟(3), 即在舊程序中添加一個指向新功能的連接。這樣,在一段時間之后,新程序中的功能就日漸增多,舊程序中功能將日漸減少。直至某一天,舊程序?qū)⑼耆珡U棄。企業(yè)可以根據(jù)自身預(yù)算及其它因素,具體決定整個遷移過程的進行速度。
3實際應(yīng)用性能分析
將本文所述漸進式遷移應(yīng)用在一個基于Oracle Forms 9.0.4的醫(yī)療程序中。但是由于最初需求分析的不夠充足,程序中某一配型模塊不僅很難使用,還經(jīng)常引入錯誤數(shù)據(jù),而且也跟不上該醫(yī)學(xué)技術(shù)近幾年的最新發(fā)展成果,于是決定對此模塊進行修改。鑒于這是一個較大項目,在老舊的Oracle Forms平臺上重寫將會是資源上的一個極大浪費。所以最終選擇將這一項目作為漸進式遷移的試驗項目。該課題共耗四個人年左右(四人團隊,一年時間)。項目結(jié)束時,重建模塊在一個嶄新的基于ASP.NET的程序中獲得實現(xiàn),舊程序中原有的模塊則隨之得到了隱藏。用戶若要訪問新的模塊,既可以直接登錄到新程序中,也可以從舊程序中通過點擊相應(yīng)的菜單項而流暢無縫地切換到新程序中去。產(chǎn)品應(yīng)用之后,已經(jīng)收到了眾多好評。該項目成功地驗證了漸進式遷移策略的可行性,為日后的不斷縮減舊程序,并日漸擴充新程序奠定了一定的理論及實踐基礎(chǔ)。
4結(jié)束語
本文討論的這套遷移機制,其最大特點在于保持整個遷移進程進度的靈活性而同時又不會給終端用戶帶來任何不便。另外,從廣義角度來說,這套機制對于從Oracle Forms向Java平臺遷移也具有重要的指導(dǎo)意義及借鑒價值。
參考文獻(xiàn):
[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內(nèi)置函數(shù)UTL_ENCODE.BASE64_ENCODE() 的說明文檔:http://psoug.org/reference/utl_encode.html.
[4]PL/SQL內(nèi)置函數(shù)DBMS_OBFUSCATION_TOOLKIT.DES3ENCRYPT() 的說明文檔:http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_obtool.htm.