一、C/S結構的限制
網絡應用絕大部分都可分爲以下四個層次:表現層、事務層、數據邏輯層和數據存儲層。在C/S結構中,表現層和事務層都放在客戶端,而數據邏輯層和數據存儲層則置於服務器端。這種組織安排帶來諸多的限制:
1、客戶端很龐大,以致於應用程序升級和維護時十分困難且耗資很大;
2、事務層不能與跨平臺的客戶端共享;
3、孤立了不同的邏輯組件;
4、沒有統一的數據邏輯層來提供不同種類的數據存儲層;
5、C/S組織結構不支持Internet。
做過C/S結構下的MIS開發和維護的人們對第1點體會頗深:對應用程序一個小小的改動,就必須通知或親臨每一個客戶端去更新;新增或升級一臺機器,都要把應用及其相關的文件安裝在客戶端上。如果整個系統有成千上萬個客戶端,可以想象維護的工作量有多大。
二、Web應用的解決方案
Web平臺是一個調度任務集中的、以客戶爲中心的應用程序平臺;它是一個分佈式、開放、適用性強、高性能、端到端的平臺;它使企業利用技術獲取競爭優勢。
1. 分佈式
C/S技術的出現,給系統集成方案帶來了集中的信息和本地的PC環境,但其數據的共享程度是很不夠的,大家可以想想,在C/S應用中,有多少人能夠得到你想發佈的信息。當今的信息技術需要新的解決方案,它提供以客戶爲中心的用戶界面和Web的分佈結構,它帶有IT環境的個人特徵,如數據存取、安全性能等,這就是我們通常所說的三層結構。
2. Web結構的優勢
在Web結構中,事務層和數據邏輯層放在中間組件層,這是關鍵,是與C/S結構的最大區別,它能解決以下幾個問題:
(1) 客戶端很瘦小,並且很容易在運行時自動升級;
(2) 事務層可在跨平臺的客戶端上共享;
(3) 不同邏輯組件的分離意味着圖形設計人員、事務邏輯開發人員和數據庫分析人員可以獨立地設計他們各自的部分;
(4) 統一的、抽象的用戶界面可使用戶更有效地從同一數據源中存取數據;
(5) 這種結構可更有效地在企業內部網、國際互聯網和外聯網上運行。
中間組件層充當一個服務器,這就是通常所說的應用服務器。
3. 開放性
Web是一個開放的環境,應用由複用組件集成,通過標準語言彙編、跨平臺的統一協議發佈,用標準用戶界面顯示,它與硬件平臺和操作系統無關。現在有三種組件模型:Activ eX、JavaBeans和CORBA,每一種模型有它自己的通信協議:ActiveX用COM和DCOM,JavaBea ns和CORBA用ⅡOP。但並不是每一種瀏覽器都支持動態的HTML,Java腳本的擴充至少支持三種模型:Active Server、LiveWire和PowerDynamo。
4. 適應性
一個可適應的開發環境是非常重要的,採用應用服務器的目的在於它支持多種組件模型,但在客戶端和數據庫服務器端需要有更強的適應性。
隨着Web技術的介入,用戶界面設計已發生了巨大的變化,因爲在站點上,並沒有類似迷惑用戶的東西或用戶手冊。一個成功的站點應首先吸引用戶,而後留住用戶。而引入新的、面向圖形化的和直覺的用戶界面標準,就允許最終用戶可以直接與它們交流。
三、Web結構中各部分的分工
1. Web發佈部分
如上圖,Web服務器僅僅是把要顯示的內容從站點上以文件的形式讀取,然後以靜態的HTML格式送到客戶端的瀏覽器;也可以Applet增強表現能力,但它僅僅是利用 ActiveX或JavaBeans通過頁面或組件,並沒有通過任何事務數據服務器。
2. Web數據處理部分
Web數據處理增強了標準Web站點存取數據的能力,包括許多數據類型。我們可根據數據的存取容量把數據分成兩大組類:標準的在線事務處理(OLTP)程序將花費大量時間去檢索和操作核心在線數據,這種數據需要連續讀取和回寫。而另一種輔助數據是隻讀的,如幫助文件、用戶信息和文檔等。Web數據處理主要集中在輔助數據,而Web OLTP主要集中在覈心在線數據。
3. 客戶端
客戶端是表現邏輯層,執行含有各種擴展的HTML(包括動態HTML)頁面,這些擴展既來自瀏覽器,也來自可視化JavaBeans和ActiveX組件。在任何情況下,我們至少需要一個HT ML頁面,由此HTTP可從服務器端傳至客戶端,應用程序的其它部分可以是一個整體。因爲大部分的Web應用都是爲Internet編寫的,對專業的IT應用而言,Web是一個成功的平臺,用戶可以在斷開連接後繼續工作,這就意味着遠程象本地一樣可存取事務和邏輯數據。這樣不僅要分發應用程序,而且還要分發數據。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
4. 應用和數據服務器端
Web結構中的剩餘部分就是完成應用程序如何與數據協同工作。數據可分成兩大類:事務邏輯和數據邏輯。數據邏輯駐在數據服務器中,而事務邏輯則置於應用服務器中。事務邏輯又可分爲兩類:事務組件和應用服務,事務組件定義了事務及其操作,而應用服務則是提供一般應用性能的組件,如菜單管理、主從數據格式等。
前面我們已介紹了Web發佈、Web數據處理和Web OLTP。事實上,在一個完整的應用中,這三種方式往往同時存在。例如,對不存取任何數據的Web頁面,傳統的Web方法是很好的,由Web服務器從文件系統中讀取頁面,然後送給客戶端。
四、移植的步驟
當我們確定移植順序時,牢記以下幾個因素:第一、要知道你能承受多大風險,由此決定每一步你做多大的修改;第二、儘管我們關注配置環境本身,但開發環境很關鍵,一個完整的Web解決方案應包括這兩部分。下面詳述從C/S移植到Web平臺的五個步驟:
1. 爲事務邏輯選定開發平臺
首先,要爲事務邏輯的開發及客戶端與應用服務器間的通信選定組件模型,然後決定採用何種應用服務器來實現事務邏輯。對於事務邏輯,頁面服務器是最簡單的選擇,但它是否採用動態數據對象(Active Da ta bjects,簡稱ADO)或JavaBeans,或兩者都採用,這將取決於很多因素,如當前配置、開發工具和平臺限制等。通常採用關聯組件的通信模型,但並不需要選擇支持多種組件的應用服務器,比較典型的是包含兩類服務器:一類是基於HTTP的頁面服務器,用來處理Web數據流程;而另一類則是事務服務器,用來處理Web在線事務處理(OLTP)。
如果當前是兩層結構,爲第三代語言開發環境,則不必考慮遺留的事務邏輯,因爲當前並沒有應用服務器;但若是兩層結構、第四代語言開發的應用程序,則可利用它自身的應用服務器和事務邏輯擴展爲三層結構的應用。PowerBuilder及其不可視對象提供了一個很好的開發環境。現存的三層結構應用,無論是第三代或第四代應用都有應用服務器的形式,你可選用舊服務器,也可轉到新的服務器。
2. 爲表現邏輯選定開發平臺
選擇客戶端的開發環境要求比較謹慎,因爲帶寬和功能間的協調在不同應用之間差異很大。無論如何,要選擇可視化的組件和你所期望能支持的瀏覽器,若兩種瀏覽器都要求支持,則需要自己編寫一些通用的程序。對於應用服務器,ActiveX和JavaBeans之間的選擇完全取決於開發經驗、策略以及市場上可用的組件。
關心當前應用程序,就象關心表現邏輯一樣,看它是兩層結構還是三層結構,儘管兩層結構的應用是肥客戶端,必須分開,但真正的技術卻不需要改變。僅需要至少一個HTML來啓動頁面,重新配置表現邏輯,並允許HTTP機制存取它。
3. 選定開發環境
選擇好的開發環境是移植至Web平臺的關鍵,因爲開發工具有助於開發進程。可以選擇符合工業標準的組件模型,它將爲你生成事務邏輯,然後不必修改源程序而生成這些組件。有些工具可生成多樣的表現層次,如 JavaScript、Java或ActiveX組件等。
在此描述的開發環境是第四代語言的範圍,這類工具可在統一的、集成的環境中創建一個完整的應用,所有的表現和事務邏輯都用同一種語言來編寫。在配置階段,根據運行平臺生成不同的組件和語言模型。
4. 統一併構建事務邏輯
在此必須有一個關於開發和配置環境的詳細圖表,重新規劃現有的編碼。可以先忽略改變語言和組件模型的細節,而僅重視邏輯本身。從事務邏輯中分離表現邏輯,然後在把事務邏輯從應用服務器中分離出來。一旦定義好事務邏輯,就可配置應用服務器。組織事務邏輯有兩種比較好的方法:從數據模型或客戶端應用中提取邏輯。有些數據邏輯存放在當前的應用中,所以要把它當成組件重新生成。
5.爲Web應用重新配置表現邏輯
必須重新配置表現邏輯才能適應瀏覽器環境,這一過程相當嚴格,因爲瀏覽器環境把客戶端組件送至用戶,有許多可選方案。如果開發環境支持一般的技術,而又想在這種技術下使用最好的策略,例如PowerBuilder支持由數據窗(DataWindow)生成HTML,但又計劃將來生成更完整的應用程序,在這種情況下,符合Java的數據窗是可以考慮的。
當表現邏輯改成Web環境時,需要開發一些新的組件。如果沒有生成任何新的頁面,則C/S應用與Web應用的用戶界面可以完全一樣。
