PB 應用走向 WEB 的技術方案選擇

— Appeon for PowerBuilder WEB 發(fā)布和 J2EE WEB 應用重寫方案的比較

1 概述

大多數(shù)企業(yè)已經認識到，將現(xiàn)有基于 Client/Server 架構的 PB 應用轉換為成熟的 N-Tier WEB 架構會給企業(yè)帶來諸多的優(yōu)勢。其中最顯著的一點是在延伸企業(yè)應用到 WEB 架構之后，將會有更多的人如員工、合作伙伴、客戶以及其他相關人員，能通過使用該 WEB 應用來運行相關的業(yè)務流程。當他們在獲得授權之后，可以通過互聯(lián)網 (Internet) 隨時隨地訪問 WEB 應用，讓企業(yè)的運轉更加方便、高效而有序。另一方面， WEB 應用和 C/S 應用比較而言，會更具伸縮性、更安全、更加易于維護，同時能有效地降低企業(yè)的總體擁有成本。最為重要的是，應用轉到 WEB 架構之后，能為企業(yè)帶來可持續(xù)增長的利潤和長期的競爭優(yōu)勢，保證企業(yè)在未來的日子里立于不敗之地。

1.1 可行的解決方案

由于 J2EE 平臺的穩(wěn)定性、安全性、平臺無關性，以及許多基于 J2EE 平臺的成功案例，使得很多企業(yè)更加關注 J2EE 平臺。因此本文側重于介紹基于 J2EE 平臺的解決方案：

方案一、利用 J2EE 技術重寫出一個全新的 WEB 應用。重寫以后，將在 J2EE 開發(fā)環(huán)境中維護新的應用。

方案二、使用 Appeon for PowerBuilder （以下簡稱 APB ）產品對原有 PB 應用程序在 PowerBuilder （以下簡稱 PB ）開發(fā)環(huán)境中進行 WEB 發(fā)布 [ 注： APB 不僅可以將應用發(fā)布到基于 J2EE 平臺運行，也可以將應用發(fā)布到基于 .NET 運行 ] 。

1.1.1 利用 J2EE 技術進行 WEB 應用重寫

重寫是指利用 J2EE 技術按照原有的業(yè)務規(guī)則開發(fā)出一套新的 WEB 應用程序。因此，整理出原有 PB 應用的業(yè)務規(guī)則和數(shù)據(jù)結構是所有重寫活動的起點，同時也是重點。原有 PB 應用的業(yè)務規(guī)則和數(shù)據(jù)結構的整理質量對于項目是否成功將起到決定性的作用。然后再使用 HTML 、 CSS 、 JavaScript 、 Jsp 、 Servlet 、 EJB 等技術去實現(xiàn)這些已經整理出來的業(yè)務規(guī)則和數(shù)據(jù)結構。同繼續(xù)使用 PB 開發(fā)應用相比， J2EE 開發(fā)技術難度高，花的時間多，各種不確定因素較多，風險大。

企業(yè)可以選擇自己重寫，也可以選擇外包給另外的公司。不管是企業(yè)自己重寫還是外包，由于 PB 技術和 J2EE 技術本身的差異，企業(yè)將要使用全新的應用開發(fā)和維護流程，這意味著發(fā)生巨大的變化，而這些變化會導致非常多的風險。重寫會在一定程序上改進原有 PB 應用程序的不良設計和編碼，但是也可能會帶來許多新的隱患，新寫的代碼通常都是需要在運行一段時間并不停地修復 Bug 后才能穩(wěn)定。

1.1.2 使用 Appeon for PowerBuilder 產品進行 WEB 發(fā)布

APB 以企業(yè)原有的 PB 應用的源代碼為基礎，自動生成一個映射原有 PB 應用功能的基于多層架構的 WEB 新應用。 APB 生成的 WEB 應用將精確地復制 PB 應用的用戶界面和業(yè)務邏輯。

由于 APB 是基于 PB 源代碼進行地 WEB 發(fā)布。因此，企業(yè)可以讓 PB 開發(fā)人員在 PowerBuilder 開發(fā)環(huán)境內完成企業(yè)原有應用的修改或添加新的功能，再由 APB 來完成 PB 應用程序生成 WEB 應用程序的所有事情。在整個過程中， PB 開發(fā)人員不需要編寫任何 HTML 、 JavaScript 、 CSS 、 Java 代碼 —— PB 開發(fā)人員只需運用標準的 PB 編程技術即可。

利用 APB ，企業(yè)能繼續(xù)使用 PB 開發(fā)新的功能，然后再將其轉化為 WEB 應用。因此 APB 可以幫助企業(yè)使用現(xiàn)有的 PB 技術有效的對原有的 PB 應用進行功能的擴展。

1.2 如何選擇解決方案？

企業(yè)選擇解決方案的時候，首先應當考慮的是解決方案本身是否和企業(yè)自身的發(fā)展策略方向一致；其次是解決方案是否能夠支撐起企業(yè)的業(yè)務運轉，同時能應付將來的業(yè)務擴展；最后需要考慮的是解決方案本身的成本以及會給企業(yè)帶來的風險。下面列示的是企業(yè)在進行解決方案選擇的時候必須謹慎考慮的主要因素：

· 由于企業(yè)策略原因需要的是使用 Java 開發(fā)工具去開發(fā) WEB 應用還是繼續(xù)使用 PowerBuilder 進行應用開發(fā)？

· 原有 PB 應用功能是否滿足企業(yè)目前的業(yè)務需要？

· 原有 PB 應用是否能夠有效的進行功能擴展，以滿足企業(yè)新的業(yè)務需求？

· 原有 PB 應用程序的現(xiàn)狀是代碼質量很好、維護成本很低還是與之相反？

· 原有 PB 應用程序轉換為 WEB 應用程序之后對于最終用戶的影響是正面的還是負面的？通常表現(xiàn)在最終用戶對于新的 WEB 應用程序在用戶界面和操作方式上的適應性，以及是否能夠高效率的對應用進行操作。

· 在原有 PB 應用程序轉換為 WEB 應用程序的過程中，企業(yè)能否承受較長的開發(fā)周期、較多的成本及較高的風險？。

企業(yè)能準確的回答上面的問題之后，便可以選出最合適企業(yè)的解決方案。如果企業(yè)不打算繼續(xù)使用 PowerBuilder 做為企業(yè)的主流開發(fā)工具，那么使用新的 J2EE 進行重寫是最佳方案。反之，企業(yè)可以考慮另一種更加務實的方案——使用 APB 對原有的 PB 應用進行發(fā)布。因為 APB 可以幫助企業(yè)在進行 PB 應用程序向 WEB 應用程序轉換的過程中縮短開發(fā)時間、減少開發(fā)成本、降低開發(fā)風險。后面的章節(jié)將對于上述兩個解決方案做出更加詳盡的分析和說明。

2 APB WEB 發(fā)布和 J2EE 重寫的綜合比較

2.1 成本和風險

使用 APB 對 PB 應用進行 WEB 發(fā)布，不僅可以實現(xiàn)對原有程序代碼的重用，還可以繼續(xù)利用企業(yè)現(xiàn)有 PB 開發(fā)人員的開發(fā)技能和對應用商業(yè)邏輯的理解。用 APB 進行 WEB 發(fā)布之后的 WEB 應用不僅具有和利用 J2EE 技術重寫的 WEB 應用相同的架構優(yōu)勢，而且還保留了 PB 應用原來的業(yè)務邏輯和用戶界面，最終用戶無需經過培訓即可使用發(fā)布后的 WEB 應用。并且企業(yè)可以繼續(xù)讓現(xiàn)有的 PB 開發(fā)人員對新的 WEB 應用進行維護以及添加新的功能。 APB 的這些特點將讓企業(yè)的成本和風險降到最低。

而使用 J2EE 進行重寫這種方式，需要支出更多的成本。第一，需要引進新的 J2EE 開發(fā)團隊，或引進部分 J2EE 開發(fā)人員帶領原有部分 PB 開發(fā)人員組建新的團隊；第二，必需購置新軟件和硬件去支持基于 J2EE 平臺的開發(fā)；第三，新的成員必須要花時間適應新的工作環(huán)境；第四，需要對 PB 開發(fā)人員培訓如何使用 J2EE 技術進行 WEB 開發(fā)，并且需要培訓那些新加入項目團隊的 J2EE 開發(fā)人員熟悉應用的商務邏輯。第五，現(xiàn)有 PB 應用源代碼無法重用，需要全部重寫。并且原有 PB 開發(fā)人員需要經過很長的時間才能達到熟練運用 J2EE 技術開發(fā)的水平，況且 J2EE 平臺開發(fā)生產力本身就比 PB 差很多。所以開發(fā)成本相對直接進行 WEB 發(fā)布要高很多。

另外，重寫這種方式還面臨更多的風險。第一，由于部分成員對 J2EE 新技術的應用缺乏必要的經驗，由他們寫出的代碼可能會存在較多的隱患或者不夠高效；第二，久經考驗的 PB 應用邏輯必須重新編寫，由于這個過程是由人工完成地，因此，有經驗的人知道，會不可避免的出現(xiàn)一些錯誤；第四，新的代碼需要花大量的時間去測試，并且上線后還會逐漸出現(xiàn)各種錯誤 (Bug) ，這會對最終用戶的工作造成影響，嚴重時會對企業(yè)整個業(yè)務流程造成影響。第五，由于新開發(fā)的 WEB 應用在界面上和流程上同以前的應用會有很多的不同，有可能會大大影響最終用戶的工作效率。

不管是企業(yè)自己重寫，還是選擇某個外包公司重寫，在項目進行過程中會一直伴隨著需求、技術、成本和進度等諸多的風險。而采用 APB 解決方案，可以在大幅度地降低成本的同時有效的規(guī)避風險。

2.2 功能

APB 在擁有將 PB 應用直接發(fā)布成 WEB 應用的能力，同時讓用戶界面、用戶交互方式和原有 PB 應用一模一樣。 APB 支持絕大多數(shù)的 PB 用戶界面元素以及和它們相關聯(lián)的事件機制，其中就包括掩碼編輯器、菜單、工具條、標簽頁， MDI 窗口等復雜的用戶界面元素。正因為這些復雜用戶界面元素和與之綁定的事件驅動機制，大大地豐富了 WEB 應用的用戶界面，提供了最佳的最終用戶的使用體驗。最終用戶再也不需要面對傳統(tǒng) WEB 應用中煩人的一次又一次的頁面刷新，一個頁面到另一個頁面的鏈接和跳轉。

APB 另一個最重要也是最吸引人的地方是，它完全支持了 PowerBuilder 引以為傲的數(shù)據(jù)庫訪問功能和靈活實用的報表功能，包括 Datawindow ， DataStore ， Embedded SQL 以及與之相關的豐富的數(shù)據(jù)的更新、查詢、過濾、查找功能。

APB 的這些功能，讓發(fā)布后 WEB 應用擁有了和原 PB 應用一樣豐富的用戶界面，強大的數(shù)據(jù)處理能力以及生成復雜數(shù)據(jù)報表能力，極大地提高了生產效率和最終用戶的使用體驗。

而使用 J2EE 技術重寫的 WEB 應用，由于普通網頁技術的局限性，大多數(shù)的界面相對簡陋、交互性很差。這將直接導致用戶界面的不友好，使得最終用戶的體驗很差，進而降低最終用戶的工作效率。另外，在 J2EE 中實現(xiàn)類似 APB 的超強的數(shù)據(jù)處理功能有一定的難度，除非企業(yè)投入大量的資金去研究和開發(fā)。

2.3 生產力

本文以一個實際的案例來評估 APB WEB 發(fā)布和 J2EE 重寫的生產力。案例實現(xiàn)了很多 PB 應用中很常用的一組和數(shù)據(jù)庫進行交互的功能：

· 查詢數(shù)據(jù)；

· 精確查找數(shù)據(jù)；

· 查詢相應的明細數(shù)據(jù)；

使用 APB 進行 WEB 發(fā)布后的用戶界面如圖 1 所示，使用 J2EE 進行重寫后的 WEB 應用用戶界面如圖 2 所示。

圖 1 使用 APB 進行 WEB 發(fā)布后的應用界面截圖

圖 2 J2EE 重寫出的 WEB 應用界面截圖

開發(fā)過程分兩部分：案例準備和案例開發(fā)。案例準備包括準備好案例需要使用的數(shù)據(jù)庫，和撰寫設計說明書。案例開發(fā)階段，由一名精通 PowerBuilder 技術和另一名精通 J2EE 技術的開發(fā)人員分頭用 PowerBuilder 和 Java 開發(fā)工具進行編碼、調試、發(fā)布和部署 WEB 應用。

下表統(tǒng)計了整個過程的工作量：

方案

WEB Deployment

（ PowerBuilder + APB ）

J2EE Rewrite

（ Eclipse ）

案例準備（小時）

案例開發(fā) ( 小時 )

代碼規(guī)模 ( 行 )

182

總代碼行： 1950

重用代碼行： 1185

手工編寫： 765

表 1 生產力統(tǒng)計數(shù)據(jù)

從表上可以看出，案例開發(fā)過程中， J2EE 重寫花的時間是 APB 方案的 6 倍，手工編碼量是 APB 方案 4.2 倍，總代碼量是 APB 方案的 10.7 倍。需要指出的是，此案例中并不是對一個已經存在的 PB 應用進行 WEB 發(fā)布和重寫。當對一個已存在的 PB 應用進行 WEB 發(fā)布時， APB 方案的應用開發(fā)和發(fā)布時間將會更少。而且此案例非常簡單，如果對一個界面和業(yè)務邏輯都異常復雜的應用進行 WEB 發(fā)布， APB 方案的生產力將會更高。

2.4 應用維護

使用 APB 對 PB 應用進行 WEB 發(fā)布的方案，能讓原開發(fā)團隊繼續(xù)保持原有的開發(fā)習慣和遵循已有的開發(fā)流程。而且可以通過維護同一套代碼來支持不同的部署方式：按傳統(tǒng)的 C/S 方式運行或發(fā)布為 WEB 應用程序以 B/S 方式運行。另外，眾所周知， PB 提供了強大的所見即所得以及事件驅動的編程方式，能非常容易地維護應用。

使用 J2EE 技術對 PB 應用進行 WEB 重寫，則需要利用 Java IDE 如 Eclipse 來維護應用。 Java 開發(fā)工具的可用性在過去幾年里得到了提高，但同那些 4GL 開發(fā)工具如 PB 、 VB 、 Delphi 相比，還有較大差距。同時，新開發(fā)的 WEB 應用中會包含各種類型的代碼，如 HTML ， JavaScript ， CSS ， JSP ， Java 等等。這將直接導致了如上一節(jié)所描述的問題——新的 WEB 應用的代碼規(guī)模將變得很大。因此，使用 J2EE 技術重寫的 Web 應用不僅維護的量很大，而且 Java IDE 并不能幫助企業(yè)開發(fā)人員高效的維護應用。同時，在代碼規(guī)模很大的情況下，調試和定位錯誤將變得非常困難。

2.5 集成能力

利用 J2EE 技術進行重寫后的 WEB 應用能在服務器端和其他的組件進行集成，包括對 EJB 、 WEB Service 和 CORBA 調用。

APB 方案不僅提供基于服務器端的集成，還提供基于客戶端的集成。例如在發(fā)布后的 WEB 應用中，可以和客戶端的 OLE/OCX 集成，并且支持對客戶端 DLL 及 Windows API 的調用 ( 如圖 3 所示 ) 。

圖 3 Appeon for PowerBuilder 集成能力示意圖

（注：圖中的星號 (“*”) 表示 CORBA 和 PB 的 NVO 對象需要特定應用服務器的支持）

2.6 性能和伸縮性

將生產力比較那一節(jié)中提到的 APB 和 J2EE 案例部署到相同的軟硬件環(huán)境中，然后進行相應的性能和伸縮性測試：

為基于 APB 發(fā)布的 WEB 應用和基于 J2EE 重寫的 WEB 應用采用同樣的性能優(yōu)化措施：對從服務器端傳到客戶端的內容進行 ZIP 壓縮，并對界面進行局部更新，同時都按照分頁的方式讀取數(shù)據(jù)。

應用服務器采用的是 WebSphere 。數(shù)據(jù)庫服務器則采用的是 Oracle 。

網絡帶寬為 100M 。測試工具為 LoadRunner 。測試中的思考時間為 20 秒，每隔 1 秒鐘增加一個虛擬在線用戶。利用 LoadRunner 統(tǒng)計如圖 4 所示的第 1-4 步的響應時間（未包括界面更新的時間），以及 Application Server 上應用服務器的 CPU 占用率和內存占用情況。考慮到 WEBSphere 在配置好預分配內存之后的性能會更好，所以事先給 WebSphere 預分配了 1280M 內存。

圖 4 性能和伸縮性測試網絡架構圖

2.6.1 響應時間

從圖 5 中可以看出， JSP 和 APB 的差距并不明顯，二者非常接近。而且保持相同的趨勢。可見， JSP 和 APB 應用的性能非常接近。

圖 5 APB 和 J2EE WEB 應用的響應時間對比

2.6.2 CPU 占用

從圖 6 中可以看出， J2EE WEB 應用的 CPU 占用率要略低于 APB ，但非常接近。

圖 6 APB 和 J2EE WEB 應用的 CPU 占用率對比

2.6.3 內存使用

從圖 7 中可以看出，用 APB 發(fā)布后的 WEB 應用的內存使用量要比 J2EE WEB 應用多了少許，差距為 5 – 20 Mb 之間，這種差距在實際應用中幾乎可以忽略不計。從圖上看，兩種應用的內存使用量都很平穩(wěn)，這與為應用服務器預先分配了 1280M 內存有一定的關系。

圖 7 APB 和 J2EE WEB 應用的內存使用量對比

2.6.4 小結

從上面的數(shù)據(jù)可以看出，在 WegSphere 應用服務器上，用 APB 發(fā)布后的 WEB 應用和與用 J2EE 技術重寫后的 WEB 應用相比，在響應時間、 CPU 占用以及內存占用三個方面都非常接近。因此，可以看出在同等條件下，兩種方案產生的 WEB 應用在性能上并不存在差距。同時，由于 APB 采用的是 Rich Client 技術，可以充分利用客戶端的計算能力。因而當應用的 UI 和邏輯非常復雜時， APB 發(fā)布后的 WEB 應用會擁有更好的性能和伸縮性。