概要
本文實現了記錄J2EE（Java2平台企業版）Web服務的客戶端響應次數的一個通用的結構。記錄的響應次數是真實的客戶端響應次數，所以它們實際上反映了用戶對服務質量的看法。
![]()
![]()
![]()
![]()
<!-- frame contents -->
<!-- /frame contents -->
![]()
![]()
![]()
![]()
實驗的樣品是使用Sun ONE （開放式網絡環境）應用服務器和IDE建立起來的，但是這個方法很普通，很輕易推廣到其它J2EE實現上。
Web服務正迅速的成為實現客戶端-服務器系統的首選結構。它的優點是：企業可以正式的定義一組服務，然後生成通訊用的完整的客戶端和服務器的代碼庫，從而簡化新的客戶端對合法的Web資源的訪問。
但是，Web 服務在簡化客戶端-服務器系統的建立的同時，監控服務質量就變得很重要。 假設有一個在用戶的立場上提交處理的客戶端應用程序。而企業事務通常要調用好幾個Web服務：初始調用遞交工作內容，接下來的調用檢查實現，最終調用得出結果。一個調用就是一個非凡的HTTP/SOAP (簡單對象訪問協議)交換。假設你是IT部門專門負責監控服務器裝載和猜測未來需要的工作人員，你必須得回答這個基本問題："我現在治理我的客戶端怎樣呢？對於將來的治理，我還需要什麼東西？"
假如你只有HTTP日志的話，就很難回答上述問題了。客戶端只關心事務的處理，但是因為每個事務包括幾個HTTP請求，對於評估服務質量，你最多只能開發自定義數據采集軟件，該軟件可通過HTTP日志做出指示並建立用戶事務處理的模型。就算是這樣，你所擁有的信息仍然有限，因為它不能反映網絡傳送或者客戶端應用程序的內務操作。
本文的中心思想是：事務服務質量用客戶端評估最好。這兒采用的方法就是答應客戶端記錄實際的事務響應次數。客戶端應用程序通過將響應時間報告添加到下一個彈出的事務處理請求上，從而上傳響應時間報告給服務器。服務器取出這些附件並將他們排隊儲存和在線分析。
結構
基於客戶端的頻率記錄結構的目標就是：記錄用的下部構造必須是輕型的，它不但有利於實現運行的內務開銷還可以減輕添加它到一個現有的實現的負擔。我們也希望該結構對提供的服務沒有限制，我們很想可以將服務添加到一個現有的、可以盡可能輕易地使用Web服務的客戶端-服務器系統上。
我們的結構的另一個目標是：企業應用程序自身的可靠性不要太差。我們將引入一些新的、輕易做到的步驟到應用程序的處理工作流程中。而且我們可以保證這些新步驟中的任何故障都可以得到處理，我們不會因為不能將頻率用於程序就讓企業事務的處理失敗
下圖顯示了一個典型的J2EE(Java 2 平台企業版)Web服務的客戶端-服務器應用程序。典型的組件用粗線標明；我們添加的新組件用於收集頻率，它采用紅線標明。
J2EE Web services: Metrics-gathering architecture
"J2EE Application Server"區域表示現有的服務器資源。他們是用來處理客戶端請求的企業JavaBeans (EJB) 組件。工具可自動的生成Web服務軟件包。EJB組件和相關的 Web 服務模塊被當作J2EE應用程序配置到J2EE服務器上。當應用程序配置時，客戶端可以通過調用程序WSDL (Web 服務描述語言)服務來判定一個服務。WSDL服務對程序提供的服務給出正式的定義。
"Application Client"區域由程序組件和Web服務軟件包組成。程序組件實現商業邏輯和用戶界面。Web服務軟件包可自動地通過WSDL編譯器和J2EE服務器程序提供的WSDL服務創建出來。
從理論上來說，整個客戶端-服務器系統有兩層。應用程序層在服務器端擁有EJB組件，在客戶端擁有一個應用程序。Web 服務層有一個服務器實現和一個客戶端實現，兩者都可以自動產生。
典型地，用戶的商業事務處理包括許多個服務期調用。第一個調用初始化事務，返回一個"handle" 給客戶端。後來的調用查詢事務的完成--客戶端使用句柄調用服務來檢查事務是否得到處理。通常最後一個調用可得到完成的事務的狀態。因此，一個商業模型，可在客戶端程序內實現的商業模型，總是使得事務與低級別的服務器調用聯系起來。
我們可以將收集頻率的組件添加到我們的標准J2EE Web服務結構上。上圖中的Payload軟件包在服務器和客戶端都有配置。稍後我會具體的討論這個軟件包，但是從結構的意義上來講，這個軟件包提供了幾個服務。例如：客戶端程序可以使用beginTransaction() 和 commitTransaction()來定界事務和記錄次數。客戶端Web服務軟件包使用Payload軟件包來連載次數報告給SOAP信息附件。服務器端的Web服務軟件包使用Payload軟件包將SOAP附件從引入的請求中剝離出來，並將它列隊登記和報告。
這個實現中的系統操作很少因為客戶端和服務器不交換任何新的通信--完成的事務的頻率報告與下一個客戶端請求一起運送。引入的唯一的新的處理就是客戶端上的一些連載和服務器端排隊等待的附件。整個實現很輕便，因為只要添加一行代碼到每個程序Web方法上，並且代碼還是一樣的--假如Web方法的標記不變的話他也不會發生變化。
引入的最後一個組件就是信息驅動的EJB組件，它可讀取連載的頻率附件。典型的，這些附件將會記錄到一個數據庫中所以企業可以保存事務服務質量的歷史紀錄。企業可以使用這個數據庫將真實的事務響應次數與服務器資源的使用聯系起來，從而可以鑒定性的判定出哪個服務器組件才是要害的服務瓶頸。因為附件是排隊等待的，所以頻率讀取器EJB組件應該在不同的J2EE服務器上運行，我們不希望使用商業EJB組件紀錄的頻率附件競爭資源。進入討論組討論。
