技術(shù)領(lǐng)域

本發(fā)明涉及門戶布局渲染技術(shù)領(lǐng)域，具體地，涉及一種門戶布局渲染方法。

背景技術(shù)：

在企業(yè)中，一般有很多的應(yīng)用系統(tǒng)為其提供管理和IT服務(wù)，隨著企業(yè)的成長和信息的技術(shù)的發(fā)展，會有更多的系統(tǒng)加入。為方便用戶使用這些系統(tǒng)企業(yè)一般會提供一個統(tǒng)一的入口服務(wù)—門戶系統(tǒng)， 用戶可以在門戶布局中操作各業(yè)務(wù)系統(tǒng)的數(shù)據(jù)如：單據(jù)、消息、審批任務(wù)等，門戶布局的渲染性能直接影響著用戶的操控感受，尤其是大量的css 文件和js 文件需要加載，傳統(tǒng)的頁面加載模型很難滿足用戶滿意度的需求，直接結(jié)果就是頁面加載速度變慢，海量數(shù)據(jù)下布局某塊區(qū)域執(zhí)行復(fù)雜業(yè)務(wù)查詢時頁面響應(yīng)速度會進一步下降。

為了解決企業(yè)級布局渲染的性能問題，一般采用前后端結(jié)合改進的方式，這種方式前端主要進行：資源文件壓縮(對css和js文件進行G-zip)、css和js合并、前端緩存（LocalStorage），后端改進：優(yōu)化業(yè)務(wù)代碼、增加后端緩存等。這些方式雖然可以對布局的渲染性能有所提升，但其工作模式也使瀏覽器和服務(wù)端有一定閑置等待時間，且對已有舊系統(tǒng)的代碼改造實施比較困難。

這種模式的缺陷：

1．流程中的操作有著嚴格的順序：如果前面的一個操作沒有執(zhí)行結(jié)束，后面的操作就不能執(zhí)行，即操作之間是不能重疊。

2.造成性能的瓶頸：服務(wù)器生成一個頁面的內(nèi)容時，瀏覽器是空閑的，顯示空白內(nèi)容；而當(dāng)瀏覽器加載渲染頁面內(nèi)容時，服務(wù)器又是空閑的，時間與性能的浪費由此產(chǎn)生。

CN200710002299.4解決了有關(guān)門戶視圖呈現(xiàn)不足，響應(yīng)時間不理想的問題。但使用了響應(yīng)時間監(jiān)視器耦合到門戶服務(wù)器、響應(yīng)時間補救處理器等復(fù)雜的實現(xiàn)機制，不宜實施且運維成本高。

CN200510081392.X通過一種高級的高速緩存組件來緩存動態(tài)門戶頁面減少了門戶頁面訪問時間，但使用的頁面渲染仍是傳統(tǒng)的處理流程，效率不高。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于，針對上述問題，提出一種門戶布局渲染方法，以實現(xiàn)不僅能夠不破壞和修改原來應(yīng)用系統(tǒng)的代碼，快速方便的實施，還可以明顯提升用戶操作頁面滿意度的優(yōu)點。

為實現(xiàn)上述目的，本發(fā)明采用的技術(shù)方案是：一種門戶布局渲染方法，主要包括：

步驟1：初始化，聲明Channel，包括聲明Channel的名稱，BigpipeServlet的URL和是否跨域；

步驟2：為pipeURL注冊一個Handler；

步驟3：開啟Channel，包括開始為每個Chanel創(chuàng)建一個form和iFrame.form中的一個隱藏域jobs，將pipeURL地址轉(zhuǎn)為json后，設(shè)置到j(luò)obs上，并POST到服務(wù)器端地址；

步驟4：在服務(wù)器端BigpipeServlet接收到請求的Job列表，根據(jù)Job信息進行pipeURL的forward，處理完成后以PostMessage形式將數(shù)據(jù)傳遞到父頁面的onBlockReady，onBlockReady查找Handler進行回調(diào)；

步驟5：檢查Channel的所有的Job是否已經(jīng)結(jié)束，結(jié)束時標記Chanel已經(jīng)關(guān)閉，銷毀這個Chanel已經(jīng)創(chuàng)建的Form和iFrame。

進一步地，所述步驟1還包括聲明pipeURL。

進一步地，步驟4中根據(jù)Job信息進行pipeURL的forward，所述Job信息包括是否異步信息、優(yōu)先級信息和緩存的eTag信息。

進一步地，若Job信息攜帶eTag信息，pipeURL的后端將收到If-None-Match，如果pipeURL返回了步驟4中的請求狀態(tài)，則瀏覽器端將使用LocalStorage中的緩存來回調(diào)Handler。

進一步地，若步驟1中，Chanel跨域請求時先向宿主服務(wù)器發(fā)送請求，宿主服務(wù)器根據(jù)秘鑰、時間戳和用戶名加密出一個token，輸出一個form，然后提交這個form到Chanel上；Chanel上的BigpipeServlet校驗這個token，校驗通過后調(diào)用注冊的上下文處理Invocation RestoreHandler生成上下文；前端采用PostMessage方式進行處理；

所述宿主服務(wù)器中包括一個跨域Chanel列表，只有在這個列表中的才生成Form。

進一步地，步驟3之前中還包括對意外流程的處理，如果注冊Handler的時候Channel已經(jīng)關(guān)閉，若pipeURL已經(jīng)聲明過，從Channel中獲取數(shù)據(jù)并且傳遞給Handler 如果沒有聲明過該URL，重新創(chuàng)建一個channel來處理；

如果注冊Handler的時候Channel已經(jīng)開啟，若Channel開啟前沒有declare過該pipeURL，channel結(jié)束后重新創(chuàng)建一個channel來處理。

本發(fā)明各實施例的一種門戶布局渲染方法，由于主要包括：首先client組件為布局中的每個pipeURL建立channel通道，向服務(wù)端發(fā)起請求，在服務(wù)端server組件會為每一個pipeURL設(shè)定一個job(包含優(yōu)先級、etag等信息)，根據(jù)job信息進行pipeURL的forward，處理完成后以PostMessage形式到客戶端client組件，client組件負責(zé)回調(diào)handler，當(dāng)所有channel的job結(jié)束時關(guān)閉channel完成頁面渲染；從而可以克服現(xiàn)有技術(shù)中工作模式也使瀏覽器和服務(wù)端有一定閑置等待時間，且對已有舊系統(tǒng)的代碼改造實施比較困難的缺陷。

本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本發(fā)明而了解。

下面通過附圖和實施例，對本發(fā)明的技術(shù)方案做進一步的詳細描述。

附圖說明

附圖用來提供對本發(fā)明的進一步理解，并且構(gòu)成說明書的一部分，與本發(fā)明的實施例一起用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的限制。在附圖中：

圖1為本發(fā)明實施例所述的門戶布局渲染方法原理圖；

圖2為本發(fā)明實施例所述的門戶布局渲染方法流程圖；

圖3為本發(fā)明實施例所述的門戶布局渲染方法中描述的跨域處理原理圖。

具體實施方式

以下結(jié)合附圖對本發(fā)明的優(yōu)選實施例進行說明，應(yīng)當(dāng)理解，此處所描述的優(yōu)選實施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。

具體地，一種門戶布局渲染方法，主要包括：

步驟1：初始化，聲明Channel，包括聲明Channel的名稱，BigpipeServlet的URL和是否跨域；

步驟2：為pipeURL注冊一個Handler；

步驟3：開啟Channel，包括開始為每個Chanel創(chuàng)建一個form和iFrame.form中的一個隱藏域jobs，將pipeURL地址轉(zhuǎn)為json后，設(shè)置到j(luò)obs上，并POST到服務(wù)器端地址；

步驟4：在服務(wù)器端BigpipeServlet接收到請求的Job列表，根據(jù)Job信息進行pipeURL的forward，處理完成后以PostMessage形式將數(shù)據(jù)傳遞到父頁面的onBlockReady，onBlockReady查找Handler進行回調(diào)；

步驟5：檢查Channel的所有的Job是否已經(jīng)結(jié)束，結(jié)束時標記Chanel已經(jīng)關(guān)閉，銷毀這個Chanel已經(jīng)創(chuàng)建的Form和iFrame。

所述步驟1還包括聲明pipeURL。

步驟4中根據(jù)Job信息進行pipeURL的forward，所述Job信息包括是否異步信息、優(yōu)先級信息和緩存的eTag信息。

若Job信息攜帶eTag信息，pipeURL的后端將收到If-None-Match，如果pipeURL返回了步驟4中的請求狀態(tài)，則瀏覽器端將使用LocalStorage中的緩存來回調(diào)Handler。

若步驟1中，Chanel跨域請求時先向宿主服務(wù)器發(fā)送請求，宿主服務(wù)器根據(jù)秘鑰、時間戳和用戶名加密出一個token，輸出一個form，然后提交這個form到Chanel上；Chanel上的BigpipeServlet校驗這個token，校驗通過后調(diào)用注冊的上下文處理Invocation RestoreHandler生成上下文；前端采用PostMessage方式進行處理；

所述宿主服務(wù)器中包括一個跨域Chanel列表，只有在這個列表中的才生成Form。

步驟3之前中還包括對意外流程的處理，如果注冊Handler的時候Channel已經(jīng)關(guān)閉，若pipeURL已經(jīng)聲明過，從Channel中獲取數(shù)據(jù)并且傳遞給Handler 如果沒有聲明過該URL，重新創(chuàng)建一個channel來處理；

如果注冊Handler的時候Channel已經(jīng)開啟，若Channel開啟前沒有declare過該pipeURL，channel結(jié)束后重新創(chuàng)建一個channel來處理。

形態(tài)和概念

1、形態(tài)

bigpipe-server組件以jar的形式提供給第三方

bigpipe-client 組件提供bp.js的瀏覽器客戶端.

2、 概念

通道（Channel）channel規(guī)定了當(dāng)前屬于哪一個頻道(大約對應(yīng)應(yīng)用服務(wù)器中的context). 比如/hr , /portal 或者http://www.nccloud.com/ipu因為要做服務(wù)器端forward.所以需要每個context中配置一下bigpipe的server端

URL（pipeURL）pipeURL是一個提供數(shù)據(jù)的特殊的網(wǎng)絡(luò)地址，相對于普通的URL, pipeURL有以下不同：

1）僅支持GET方式

2）URL必須以channel開頭.如果URL不能與任意一個channel開頭匹配,將會被忽略,如果有多個匹配,取最大的匹配

3）返回結(jié)果必須是一個JSON.編碼為UTF-8.僅支持Etag/If-None-Match頭.其他緩存頭將被忽略.

4）如果需要異步請求,需要在URL后面加入一個參數(shù)_bp_async_=1 ,如

5）如果需要調(diào)整執(zhí)行的優(yōu)先級,需要在URL后加入一個參數(shù)_bp_order_=0.參數(shù)值越高優(yōu)先級越高

處理器（Handler）handler是客戶端注冊的處理數(shù)據(jù)的方法.由bigpipe回調(diào).只有一個參數(shù):data

任務(wù)（Job）服務(wù)器端會為每個pipeURL設(shè)定一個Job .這個Job中包含了pipeURL執(zhí)行的優(yōu)先級,是否同步執(zhí)行.緩存的eTag信息. BigpipeServlet依據(jù)這些信息處理每個pipeURL。

結(jié)合圖1，在WEB開發(fā)中，HTTP/1.1 支持的chunked編碼，可以由瀏覽器接收到服務(wù)器發(fā)送的chunked塊后，立即解析該塊代碼。因為chunked編碼使消息主體成塊發(fā)送，每塊有自己的大小指示器，在所有的塊之后會緊接著一個可選的包含實體頭域的尾部。這種編碼充許發(fā)送端能動態(tài)生成內(nèi)容，并能攜帶能讓接收端判斷消息是否接收完整的有用信息

本發(fā)明采用“bigpipe-client” + “bigpipe-server”組件結(jié)合的方式提高布局的渲染效率。首先client組件為布局中的每個pipeURL建立channel通道，向服務(wù)端發(fā)起請求，在服務(wù)端server組件會為每一個pipeURL設(shè)定一個job(包含優(yōu)先級、etag等信息)，根據(jù)job信息進行pipeURL的forward，處理完成后以PostMessage形式到客戶端client組件，client組件負責(zé)回調(diào)handler，當(dāng)所有channel的job結(jié)束時關(guān)閉channel完成頁面渲染。

結(jié)合圖2，主要過程如下：

下面是本方案的處理流程。

1.初始化:聲明Channel，包括Channel的名稱，BigpipeServlet的URL，是否跨域

2.初始化-預(yù)先聲明: declare一下pipeURL(這個是,不是必須的.)

3.為pipeURL注冊一個Handler

4.開啟Channel: 開始為每個Chanel創(chuàng)建一個form和iFrame.form中一個隱藏域jobs，將pipeURL地址轉(zhuǎn)json后，設(shè)置到j(luò)obs上.POST到服務(wù)器端地址。

5.在服務(wù)器端BigpipeServlet接收到請求的Job列表，根據(jù)Job信息(是否異步,優(yōu)先級)進行pipeURL的forward，處理完成后以PostMessage形式將data傳遞到父頁面的onBlockReady方法，onBlockReady查找Handler進行回調(diào)。

檢查Channel的所有的Job是否已經(jīng)結(jié)束，結(jié)束時標記Chanel已經(jīng)關(guān)閉.銷毀這個Chanel已經(jīng)創(chuàng)建的Form和iFrame。

緩存、跨域、意外流程的處理是本方案的主要步驟，下面詳細介紹這三個方面。

緩存

如果pipeURL的輸出頭中聲明了eTag,那么這個請求將被onBlockReady方法存儲在localStorage中.在bigPipe處理的時候?qū)贘ob信息中攜帶eTag信息，pipeURL的后端將收到If-None-Match，如果pipeURL返回了304的請求狀態(tài),那么瀏覽器端將使用LocalStorage中的緩存來回調(diào)Handler。

緩存的一些問題:

1） 支持且僅支持http協(xié)議中的eTag.其他的緩存指令忽略(以不緩存處理)

2） 如果輸出了eTag,在客戶端將以用戶-pipeURL-etag做key,將輸出內(nèi)容存儲在localStorage中.這樣不同的用戶被隔離開，但是潛在的風(fēng)險是這些信息存儲在瀏覽器端,所以不要將敏感信息設(shè)置為緩存。

結(jié)合圖3，在處理跨域的時候.需要向?qū)Ψ椒?wù)器端傳送一個token信息，傳送過程如下:

1.Chanel跨域請求時先向宿主服務(wù)器發(fā)送請求,宿主服務(wù)器根據(jù)秘鑰 ,時間戳,用戶名加密出一個token.輸出一個form.然后提交這個form到Chanel上.

2.宿主機中包括一個跨域Chanel列表.只有在這個列表中的才生成Form

3.Chanel上的BigpipeServlet校驗這個token,校驗通過后調(diào)用注冊的上下文處理InvocationRestoreHandler生成上下文.

4.前端處理的時候使用PostMessage方式.。

意外流程的處理：

1、注冊Handler的時候Channel已經(jīng)關(guān)閉

如果pipeURL已經(jīng)declare過.從Channel中獲取數(shù)據(jù)并且傳遞給Handler 如果沒有declare過該URL,重新創(chuàng)建一個channel來處理

2、注冊Handler的時候Channel已經(jīng)開啟

如果Channel開啟前沒有declare過該pipeURL,等等channel結(jié)束重新創(chuàng)建一個channel來處理(連接數(shù)限制)

至少可以達到以下有益效果：這種方案能夠不僅能夠不破壞和修改原來應(yīng)用系統(tǒng)的代碼，快速方便的實施，還可以明顯提升用戶操作頁面滿意度。

最后應(yīng)說明的是：以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，盡管參照前述實施例對本發(fā)明進行了詳細的說明，對于本領(lǐng)域的技術(shù)人員來說，其依然可以對前述各實施例所記載的技術(shù)方案進行修改，或者對其中部分技術(shù)特征進行等同替換。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。