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

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

1 概述

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

1.1 可行的解決方案

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

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

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

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

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

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

1.1.2 使用 Appeon for PowerBuilder 產品進行 WEB 發布

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

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

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

1.2 如何選擇解決方案？

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

· 由于企業策略原因需要的是使用 Java 開發工具去開發 WEB 應用還是繼續使用 PowerBuilder 進行應用開發？

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

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

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

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

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

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

2 APB WEB 發布和 J2EE 重寫的綜合比較

2.1 成本和風險

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

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

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

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

2.2 功能

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

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

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

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

2.3 生產力

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

· 查詢數據；

· 精確查找數據；

· 查詢相應的明細數據；

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

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

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

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

下表統計了整個過程的工作量：

方案

WEB Deployment

（ PowerBuilder + APB ）

J2EE Rewrite

（ Eclipse ）

案例準備（小時）

案例開發 ( 小時 )

代碼規模 ( 行 )

182

總代碼行： 1950

重用代碼行： 1185

手工編寫： 765

表 1 生產力統計數據

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

2.4 應用維護

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

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

2.5 集成能力

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

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

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

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

2.6 性能和伸縮性

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

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

應用服務器采用的是 WebSphere 。數據庫服務器則采用的是 Oracle 。

網絡帶寬為 100M 。測試工具為 LoadRunner 。測試中的思考時間為 20 秒，每隔 1 秒鐘增加一個虛擬在線用戶。利用 LoadRunner 統計如圖 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 發布后的 WEB 應用的內存使用量要比 J2EE WEB 應用多了少許，差距為 5 – 20 Mb 之間，這種差距在實際應用中幾乎可以忽略不計。從圖上看，兩種應用的內存使用量都很平穩，這與為應用服務器預先分配了 1280M 內存有一定的關系。

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

2.6.4 小結

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