摘要:在分析現有Web服務機制的基礎上,提出自主研發適應時效索引機制的Web服務單元。它能夠提高服務端響應速度,兼容現有瀏覽器,實現主動式有狀態的索引服務單元,并為Web服務的專項功能開發提供基礎。
關鍵詞:Web服務擴充;時效索引;主動式
中圖分類號:TP316.4文獻標志碼:A
文章編號:1001-3695(2007)07-0224-03
現有Web服務存在兩個主要問題:① 現有Web服務是一種被動式無狀態的服務機制,沒有考慮到提供與其他服務站點共享資源的方法,這樣不僅不利于資源發現,更不能有效地進行資源管理。② 國際上相繼提出了OGSA(Open Grid Service Architecture)架構[1]和WSRF(Web Service Resource Framework)規范。WSRF規范雖然擴充了Web Service狀態管理的部分[2],但是網格服務仍然建立在Web容器提供的腳本語言解釋基礎之上,因此仍然存在不可忽視的響應延遲。
1時效索引機制設計思想
對現有的Web服務機制作出相應的改進:改進的Web服務單元可以實現將站點資源和狀態直接發送到指定的索引服務單元,實現Web服務單元主動提交信息的索引機制。這里提到的Web服務單元和索引服務單元本文分別稱其為信息節點和索引節點。每一個信息節點均可以通過索引節點準確地反映其有效性。所謂時效索引即這種索引機制是信息節點和索引節點雙向動態建立的,使用戶在進行Web瀏覽時清楚地了解資源的內容和狀態,這樣用戶不需要費時費力地搜索,就可以獲得自己所需的所有當前正常服務器的資源和運行狀態,充分地利用已有的網絡資源[3]。
1.1Web服務機制的改進
目前Web服務器主要由網絡接口、腳本解釋、服務器配置幾部分程序組成(圖1(a))。當服務器獲得請求時,網絡接口程序完成對HTTP協議的處理,根據協議格式取得請求的文件名等信息,如果是一般文件,則打開該文件并按照HTTP協議發送給瀏覽器。如果是腳本文件,則進行腳本解釋程序執行腳本并處理數據,將結果按照HTTP協議返回給瀏覽器。
改進的服務器包括網絡接口、控制單元和服務器配置幾部分程序(圖1(b))。其響應過程也是通過網絡接口程序完成對HTTP協議的處理,根據協議格式取得請求的文件名等信息,如果是一般文件,則打開該文件并按照HTTP協議發送給瀏覽器。如果是腳本文件,則使用編譯好的可執行代碼直接運行操作并返回結果。經過這樣的設計,控制單元就好像游戲引擎一般,通過編寫的邏輯關系把數據、文件資源、功能服務以超鏈接的方式組織起來,提供給用戶使用。
(a) 現有Web服務單元用例(b) 改進Web服務單元用例
1.2主動提交的索引機制
目前的Web服務提供了站點的網絡化(圖2(a)),即站點資源可以是網絡上的任何一臺電腦,但不能主動在網絡中聲明自己有什么資源,處于何種狀態,從而出現了現在的搜索引擎網站,它們的工作就是不停在網絡上查找存在的網絡資源,搜索引擎的好壞就成為能否使用資源的最大問題[4]。改進的Web服務機制(圖2(b))可以實現將站點資源和狀態直接發送到指定的索引服務器,這樣用戶在進行Web瀏覽時,不需要費時費力的搜索就可以獲得當前所有正常服務器的資源和運行狀態的詳細信息,使用戶可以充分地利用已有的網絡資源[5]。
(a) 現有Web網絡服務結構(b) 資源時效索引用例
2服務節點的設計與實現
2.1服務節點設計模式
依據MVC設計模式構造服務節點。模型包括網絡接口、專項功能接口和數據庫接口。其中網絡接口的核心功能是建立可靠連接,解析HTTP協議頭和按照HTTP協議要求發送結果信息。解析好的協議內容將被存儲在結構體中,以便其他模塊調用,結果信息通過重載的Send函數直接發送,而不用關心HTTP協議頭的格式。專項功能的核心功能根據實際的需求編寫,因為有了網絡接口模塊的支持,使得在設計過程中無須考慮HTTP協議的細節,直接使用模型中提供的功能函數,完成與瀏覽器之間的信息交換。在數據庫連接上,微軟提供了如ODBC和ADO等數據庫接口,所以可直接調用。在此視圖和控制器表示為服務器的界面,視圖包括服務器狀態顯示、日志等,控制器包括配置和服務器操作功能等。
使用MVC模式,通過變更—傳播機制保證了模型與用戶界面之間的一致性。在服務節點設計中使用該模式可以使核心功能和數據成為共用的部分,以提高代碼的重用性,方便維護和更新。在需要移植時,相同系統中只需修改視圖和控制器,不同系統中由于核心與界面是分開編寫,代碼結構清晰,減小了移植的難度。從高級編程語言來看,C和C++語言實現的代碼執行效率最高,函數庫較豐富,能夠實現的功能較強,而且目前VC的封裝機制使得代碼的重用性較強,因此本文以Windows平臺為切入點,通過VC來實現Web時效索引的功能。
2.2網絡接口的設計
網絡接口的設計主要是為了達到網絡部分的程序能獨立工作,并能對HTTP協議[6]完全支持的要求。服務節點的設計是把HTTP協議頭封裝在網絡接口模塊中,使開發者不用關心協議的格式就能直接獲得協議的內容,對請求進行響應。
在服務器啟動后,程序進入監聽狀態,每一個請求都將創建一個新的連接與之通信,所有的通信過程都由網絡接口處理。二次開發人員只需按照HTTP協議的內容對客戶作出響應。在完成響應以后斷開連接,網絡接口程序會自動將其資源從內存中釋放,繼續下一個服務。這樣的設計又需二次開發人員簡單啟動網絡接口,其他工作都由該接口自動完成。
首先創建監聽類(MListen),再創建請求類(Request)。在MListen類中添加指針列表,用于記錄創建的新連接的地址,還需重載OnAccept函數。該函數在接收客戶端連接時會被調用。代碼如下:
void MListen::OnAccept(int nErrorCode)
{Request *pRequest = new Request(this);
if ( Accept( *pRequest ) )
{m_rqtList.AddTail(pRequest);
pRequest->AsyncSelect( FD_READ|FD_CLOSE );}
CAsyncSocket::OnAccept(nErrorCode);}
當收到瀏覽器的連接請求時,創建新的通信類Request,并接收請求與Request類進行通信,如果接收成功,則與瀏覽器建立了可靠的TCP連接,再把新分配的內存地址記錄在指針列表之中,通過AsyncSelect函數選擇開始讀取瀏覽器的請求。
編寫請求類需要重載OnReceive、OnSend、OnClose函數。OnReceive函數在通信收到數據時被調用,OnSend函數在發送數據時被調用,OnClose函數在連接中斷時被調用。當服務器收到請求數據時,在OnReceive函數中完成對HTTP協議的分析,并將其內容存儲在數據結構中。如果是資源文件就直接通過OnSend函數將其發送給瀏覽器,若是專項功能調用事件則通知專項功能類,調用接口函數執行相應操作。發送函數代碼如下:
void MRequest::OnSend(int nErrorCode)
{int nBytes = Send( m_buf, m_step );
if ( nBytes != SOCKET_ERROR )
{if(m_reqStatus==REQ_FILE) //資源文件則直接發送
{if(m_file)
{if(!feof(m_file))
{m_step = fread(m_buf,1,1024,m_file);
AsyncSelect( FD_WRITE | FD_CLOSE );}
else{
fclose(m_file);
m_file = NULL;
m_reqStatus = REQ_HEADER;
}}}
if(m_reqStatus==REQ_STRING)//專項功能
{m_pSpecial->Run(this);//入口函數的調用
m_reqStatus = REQ_HEADER;//結束調用,進入開始狀態
}}
else{if ( GetLastError()!=WSAEWOULDBLOCK )
{ShutDown( both );
OnClose(0);}
else
AsyncSelect( FD_WRITE | FD_CLOSE );}
CAsyncSocket::OnSend(nErrorCode);}
最后在OnClose函數中關閉連接結束響應,并釋放內存。
2.3數據庫接口和專項功能類
在分布式系統設計中有多種數據庫操作方法[7]。其中ODBC和ADO是目前比較常用的。兩種對數據庫的操作方法在代碼結構上差不多。前者的錯誤處理代碼已被MFC封裝了,后者需自己來完成。但從微軟提供的文檔和用后的經驗來看,后者更易于使用、速度快、內存支出少、磁盤遺跡小。其他相關類和操作方法可查閱MSDN。
專項功能類與具體的應用領域相關。在專項功能類的入口函數處將調用專項功能函數,在代碼入口處,需要事先檢測是否是執行該專項功能,執行完后,應把數據結果以HTML的形式返回給瀏覽器,最后斷開連接。專項功能的實現,不僅可以做解釋性語言做到的功能,還可靈活地開發各種功能,如基于Web的遠程控制、外圍設備控制等一般解釋性語言無法做到的功能,而且代碼執行的效率也比解釋性語言要高很多。所以在同樣的網絡流量下,專項服務器能響應的用戶數比一般服務器要多。圖2中的Web時效索引節點也是專項功能的一種具體表現形式。下面給出它的實現方法。
3 Web時效索引實現方法
自主設計Web服務單元,它可以實現將站點資源和狀態直接發送到指定的索引服務單元(一種特殊的Web服務單元)。實現Web服務單元主動提交信息的索引機制如下:
(1)Web服務器的功能擴展代碼的編寫。其功能的擴展代碼包括服務器類型識別、有效性識別方法、時效性識別方法、延時計算方法、過濾器篩選方式。
(2)資源服務器與索引服務器的會話協議。使用現有的HTTP協議,增加協議的文件類型,擴展為服務器會話協議。為了完成服務器與用戶之間的交流,提供有效的目前服務器還沒有的功能,在原有的協議基礎上創建新的會話類型,滿足擴展功能的需要。其會話協議主要包括服務內容信息、服務器狀態信息、服務器響應時間。
(3)索引服務器與索引服務器的會話協議。協議完成索引服務器與索引服務器之間的會話,需要解決在什么時間內有效,確定有效性的間隔時間與網絡負載之間的平衡,要取得間隔時間短,但網絡開銷不大的平衡點,包括索引服務器列表信息、索引服務器狀態信息、響應時間等。
(4)資源服務器的優先選擇方法。設計可根據用戶的要求顯示相關的信息內容,包括資源服務器的信息分類、過濾器的設計,并要解決如何查找最快的資源服務器的算法問題,以及信息可按照響應延時、點擊率、在線情況、內容屬性等項目進行分類和篩選的方案,使用戶得到快速而高質量的服務。
(5)服務器資源的加密。為了增強服務器的安全性,以解決目前Web服務器存在的安全隱患,需設計資源的加密算法和資源路徑屏蔽的問題。
4結束語
自主設計的服務節點將提高Web服務的響應速度和擴展Web服務的專項功能,實現主動提交資源索引機制,讓用戶能夠以集成協作的方式使用來自多個組織的數據和信息,完成目前Web服務器無法實現的專項功能,如通過該服務節點,用戶可以通過單一入口訪問所有信息,輕松實現企業資源管理、信息查詢、自動化控制等。
參考文獻:
[1] FOSTER I,KISHIMOTO H,SAVVA A,et al.The open grid services architecture,version1.0. informational document[EB/OL].[2005-01-29].http://www.gridforum.org/documents/GWD-I-E/GFD-I.030.pdf.
[2]CZAJKOWSKI K,FERGUSON D F,FOSTER I,et al.The WS-Resource framework[EB/OL].[2005-03-05].http://www.globus.org/wsrf/specs/ws-wsrf.pdf.
[3]FOSTER I.Globus toolkit version 4:software for service-oriented systems:LNCS 3779[C].Berlin:Springer-Verlag, 2005:2-13.
[4]STOCKINGER H,SAMAR A,ALLCOCK B. File and object replication in data grids[J].Journal of Cluster Computing, 2002,5(3):300-310.
[5]STEEN M,HOMBURG P,TANENBAUM A.Globe:a wide-area distributed system[J]. IEEE Concurrency, 1999,7(1):70-78.
[6]FIELDING R,IRVINE U C,GETTYS J,et al.RFC 2616 Hypertext Transfer Protocol HTTP/1.1[S].[S.l.]:Network Working Group, 1999.
[7]ATKINSON M P,DIALANI V,GUY L,et al.Grid database access and integration:requirements and functionalities[DB/CD].GGF Document GFD.13, Global Grid Forum (GGF), 2003.
注:“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”