基于WEB服務(wù)器多框架解決方案

【摘要】在INTRANET上設(shè)計(jì)基于WEB的MIS時(shí)，大批量數(shù)據(jù)錄入變成了操作上的瓶頸，并給WEB SERVER與DATABASE造極大的負(fù)擔(dān)。

為解決這個(gè)問(wèn)題，我們?cè)O(shè)計(jì)了多框架結(jié)構(gòu)，將應(yīng)用的功能進(jìn)行細(xì)分，然后交給各框架分別完成，這種分工協(xié)作方式可以使操作界面上的數(shù)據(jù)實(shí)現(xiàn)受控的部分刷新，有效地減小了網(wǎng)絡(luò)的數(shù)據(jù)傳輸量，縮短了各部分的處理時(shí)間，同時(shí)了也大大減輕了WEB SERVER與DATABASE的系統(tǒng)負(fù)擔(dān)。

多框架解決方案采用ASP（ActiveX Server Pages）及ADO(ActiveX Data Objects)完成與數(shù)據(jù)庫(kù)的交互工作。采用DOM技術(shù)解決和框架之間的協(xié)作問(wèn)題。

一、問(wèn)題的提出

最初，我們采用ASP及ADO技術(shù)在INTRANET上設(shè)計(jì)基于WEB的MIS（下文簡(jiǎn)稱MIS）時(shí)，沿用了以往設(shè)計(jì)WEB站點(diǎn)時(shí)的設(shè)計(jì)習(xí)慣。但隨著設(shè)計(jì)的深入，我們發(fā)現(xiàn)，現(xiàn)有的系統(tǒng)結(jié)構(gòu)無(wú)法承擔(dān)大批量的數(shù)據(jù)錄入工作，因此，必須重新構(gòu)造系統(tǒng)的總體設(shè)計(jì)結(jié)構(gòu)。

MIS與普通的WEB站點(diǎn)之間最大的區(qū)別在于處理信息的方式。普通WEB站點(diǎn)的主要功能是發(fā)布信息，采集信息只是它極小的一部分功能，而且這些信息采集功能也都是比較簡(jiǎn)單的。但對(duì)于MIS系統(tǒng)來(lái)說(shuō)，信息的采集及維護(hù)工作占有比較高的比例，在這些信息采集功能中還存在一些較為復(fù)雜及大批量的數(shù)據(jù)錄入功能，這些功能成為了系統(tǒng)中的設(shè)計(jì)難點(diǎn)。

二、問(wèn)題的分析

當(dāng)一個(gè)系統(tǒng)涉及到復(fù)雜及大批量的數(shù)據(jù)錄入功能時(shí)，同時(shí)也就涉及到了響應(yīng)速度及界面的問(wèn)題。在以往的C/S方式中，客戶端的錄入速度由錄入員來(lái)控制，一般情況下，當(dāng)錄入員熟悉了操作方式之后，錄入速度是不受系統(tǒng)限制的。但在WEB方式下，頁(yè)面采用完全刷新方式，每次的交互操作至少要造成一個(gè)頁(yè)面的刷新。這種刷新的工作不僅更新了數(shù)據(jù)，也將界面上的一些固定內(nèi)容重新加載了一遍。對(duì)于普通用戶來(lái)說(shuō)，這種短時(shí)間的刷新并不會(huì)造成影響；但對(duì)于長(zhǎng)時(shí)間進(jìn)行操作的錄入員來(lái)說(shuō)，錄入一條數(shù)據(jù)就要等待一段時(shí)間（這一段時(shí)間可能是2-3秒，也可能是十幾秒甚至幾分鐘），是絕對(duì)不能接受的。即使，網(wǎng)絡(luò)有足夠的帶寬，頁(yè)面的重載也會(huì)造成一種閃動(dòng)的效果，這種一閃一閃的刷新造成錄入員必須重新識(shí)別頁(yè)面上的各種元素，不僅也會(huì)拖慢了他們的錄入速度，還造成眼睛的快速疲勞。

三、解決方案

如果能夠“不”刷新頁(yè)面而“快速更新”頁(yè)面中的數(shù)據(jù)，問(wèn)題應(yīng)該能夠解決了。而且頁(yè)面由于沒(méi)有刷新，一些必須由服務(wù)器保存的狀態(tài)信息也能夠在客戶端保存下來(lái)了，從而減輕服務(wù)器的負(fù)擔(dān)。那么如何達(dá)到這個(gè)目標(biāo)呢？下面將詳細(xì)討論。

1．設(shè)計(jì)思路

首先，我們確立采用多框架建立頁(yè)面?？蚣?Frames)其實(shí)不是什么新東西，許多站點(diǎn)上都用它來(lái)完成顯示固定標(biāo)題及菜單的功能。采用框架能夠避免一些頁(yè)面的重復(fù)訪問(wèn)。但是如果結(jié)合使用DOM（Document objects model)，框架可以完成許多細(xì)致的工作。

按照DOM的定義，框架可以被當(dāng)作一個(gè)對(duì)象。假設(shè)我們建立了一個(gè)框架，并給它取名為A，則對(duì)于建立框架的頁(yè)面來(lái)說(shuō)，A是Frames集合中的一個(gè)成員，而對(duì)于A中的頁(yè)面來(lái)說(shuō)，A相當(dāng)于window對(duì)象。因些，雖然框架之間不存在從屬關(guān)系，但可以通過(guò)它們的父頁(yè)面（對(duì)象）建立各框架之間的關(guān)系。

如右圖所示：框架之間能夠進(jìn)行相互控制與數(shù)據(jù)傳送。

1）．在框架A中用的是最常用的框架控制方式，利用＜A TARGET＝“B” HREF=”URL”＞ 控制B框架中的頁(yè)面重載。

2）．在框架B中，通過(guò)按鈕的點(diǎn)擊事件對(duì)框架C進(jìn)行控制，這里的控制是通過(guò)DOM來(lái)實(shí)現(xiàn)的。(假設(shè)B中按鈕Name值為“B1”)

控制C中的URL，在按鈕的ONCLICK事件中加入以下代碼：(VBScript)

sub b1_onclick

set Bframe = parent.B

Bframe.location.href = “URL”

End sub

控制C中的文本框內(nèi)容，在按鈕的ONCLICK事件中加入以下代碼：(VBScript)

sub b1_onclick

set Bframe = parent.B

Brame.document.all.txt1.value = “劉念”

‘txt1是C框架中文本框的Value值

end sub

2．新的框架結(jié)構(gòu)

如上圖，我們定義了一個(gè)新的框架結(jié)構(gòu)。在新的框架結(jié)構(gòu)中，除了用來(lái)放置一、二級(jí)菜單的MENU1、MENU2和用來(lái)放置三級(jí)菜單及具體應(yīng)用功能的Aapp之外，還增加了三個(gè)專門(mén)用來(lái)處理數(shù)據(jù)的框架（在上圖中用虛線表示）。這三個(gè)框架不需要界面，在應(yīng)用執(zhí)行的時(shí)候是看不見(jiàn)的。

三個(gè)數(shù)據(jù)處理框架的與Aapp框架分工合作，完成具體的功能。

Aapp 針對(duì)具體功能的界面和專用控制腳本

Bfun 客戶端公用函數(shù)和全局變量

Cbuf 數(shù)據(jù)集合存儲(chǔ)緩沖區(qū)

Dcom 服務(wù)器端命令執(zhí)行結(jié)果存儲(chǔ)緩區(qū)

在系統(tǒng)中，根據(jù)生存周期按Bfun→Aapp→Cbuf→Dcom的順序從大到小存放變量和數(shù)據(jù)對(duì)象。具體約定如下：

Bfun 系統(tǒng)級(jí)全局變量。如：用戶的登錄信息和操作記錄。

Aapp 功能級(jí)全局變量。如：步驟狀態(tài)參數(shù)、功能常數(shù)。

Cbuf 如果一個(gè)功能在操作上存在多個(gè)步驟，在其中不確定的連續(xù)幾個(gè)步驟中會(huì)用到的公共數(shù)據(jù)就保存在這個(gè)

框架中，如一個(gè)緩沖表。

Dcom 針對(duì)Cbuf，此框架只保存在多個(gè)步驟中的一步里需要用到的數(shù)據(jù)。如：函數(shù)計(jì)算結(jié)果。

Cbuf及Dcom框架中保存的數(shù)據(jù)主要從服務(wù)器上取得。

3．程序流程說(shuō)明

在一個(gè)具體的功能中，Aapp對(duì)整個(gè)程序流程進(jìn)行控制。Aapp通過(guò)對(duì)象關(guān)系取得Bfun中的變量值或調(diào)用Bfun中的函數(shù)。而Cbuf及Dcom中會(huì)包含一個(gè)完整的服務(wù)器端處理流程，AAPP在適當(dāng)?shù)臅r(shí)候?qū)I(yè)務(wù)流程控制權(quán)交給Cbuf或Dcom，Cbuf或Dcom在流程執(zhí)行完成之后必須將流程控制權(quán)還給Aapp。由于借助了DOM中對(duì)象的方法與觸發(fā)事件,Aapp中可以實(shí)現(xiàn)部分?jǐn)?shù)據(jù)更新,就象一個(gè)C/S中的客戶端程序。

如上圖，Cbuf與Dcom負(fù)擔(dān)了與WEB SERVER及DATABASE的數(shù)據(jù)交換工作，使Aapp在第一次被裝入后就只需要在客戶端瀏覽器中運(yùn)行。這樣，Aapp中的主要界面就不需要進(jìn)行刷新，避免了頁(yè)面刷新時(shí)造成的延遲和閃爍問(wèn)題。而Cbuf與Dcom中可以只根據(jù)約定格式返回?cái)?shù)據(jù)和一個(gè)事件觸發(fā)腳本，數(shù)據(jù)傳輸量可以根據(jù)需要降到最小，又因?yàn)镃buf與Dcom沒(méi)有可視界，因此在瀏覽器中的加載速度也是最快的。另外，Bfun中保存了大部分的函數(shù)和變量，即使Aapp的頁(yè)面需要重載，也只需要重載該頁(yè)面專用的一部分內(nèi)容。

4．?dāng)?shù)據(jù)存儲(chǔ)格式約定

將數(shù)據(jù)寫(xiě)入Aapp界面中的方式有兩種：

一種是在Cbuf與Dcom定制腳本將數(shù)據(jù)寫(xiě)到Aapp中；

另一種則是由Aapp中的腳本讀取Cbuf與Dcom中的數(shù)據(jù)再寫(xiě)到自已的界面上。

兩種方法最終都要保證Aapp取得程序流程控制權(quán)。

當(dāng)從服務(wù)器上取到的數(shù)據(jù)比較少時(shí)（比如出錯(cuò)提出示信息），前一種方法是可行的。但當(dāng)從服務(wù)器取回的是一個(gè)數(shù)據(jù)集合（比如多行的記錄集）時(shí)，前一種方法會(huì)造成控制腳本太長(zhǎng)的問(wèn)題，而且靈活性也不如后一種方法。而且按照各框架的分工，數(shù)據(jù)的控制功能應(yīng)該由Aapp去完成。因此后一種方法是數(shù)據(jù)控制的主要方法，但采用后一種方法必須在Cbuf與Dcom中定義一個(gè)數(shù)據(jù)格式。

在數(shù)據(jù)量少的時(shí)候，可以用變量保存數(shù)據(jù)，變量名可以在提交URL時(shí)定義，也可以使用默認(rèn)變量名。兩種定義方式性能差別不大，具體采用那一種可以根據(jù)個(gè)人喜好而定。

在數(shù)據(jù)量比較大時(shí)，最常見(jiàn)的情況是在服務(wù)器上取回了一個(gè)若干行的記錄集。這時(shí)可以采用表格保存數(shù)據(jù)。具體格式如下：

假設(shè)在提交ASP文件的URL時(shí)定義的表格對(duì)象名為rsTest，則會(huì)返回兩個(gè)表格對(duì)象rsTest和rsTestStru。

RsTestStru用來(lái)存放記錄集的列屬性數(shù)據(jù)。這個(gè)表由固定的五列組成：

1．ID 列順序號(hào)

2．NAME 名稱

3．TYPE 數(shù)據(jù)類型

4．LENGTH 長(zhǎng)度

5．PREC 小數(shù)位

RsTest用來(lái)存放記錄集的各行數(shù)據(jù)。

在DOM中，表格對(duì)象的行和列都有屬于相應(yīng)的對(duì)象集合。通過(guò)指定行和列的序號(hào)能夠很準(zhǔn)確的定位到任何一個(gè)數(shù)據(jù)元素，再結(jié)合innerText屬性便可以取出想要的數(shù)據(jù)。但DOM并沒(méi)有給出對(duì)表格元素進(jìn)行排序及查找的方法，因此我們必須自己編寫(xiě)這方面的函數(shù)腳本。

對(duì)于實(shí)際的WEB-MIS，還要考慮ASP及數(shù)據(jù)庫(kù)方面的程序優(yōu)化問(wèn)題；一些額外的功能，如打印控制等，仍需要借助ActiveX或Java applet來(lái)實(shí)現(xiàn)，這里不作討論。

四、應(yīng)用實(shí)例

本方案在“深圳市自來(lái)水公司管理信息系統(tǒng)（SW-MIS）”的“抄表收費(fèi)分系統(tǒng)”中獲得了應(yīng)用，“抄表數(shù)據(jù)錄入”功能在采用本方案進(jìn)行優(yōu)化后，在50個(gè)并發(fā)用戶的測(cè)試中達(dá)到了不少于10條/（用戶*分鐘）的錄入速度。而且WEB SERVER與SQL SERVER的CPU占用率能夠始終保持在10%左右。

更多計(jì)算機(jī)與外設(shè)信息請(qǐng)關(guān)注：21ic計(jì)算機(jī)與外設(shè)頻道