建立樣品客戶端應用
要建立樣品客戶端應用，請將下列文件系統添加到IDE中：＜download directory＞/Metrics/TransactionClient.
該文件系統包含一個應用類和一個Xact 軟件包。應用類可模仿客戶端事務的執行，Xact 軟件包包含客戶端Web服務處理器。
Xact軟件包可使用Sun Web服務開發者工具包來創建，這個工具包包括在Sun ONE應用框架內。批文件gen.bat使用wscompile命令創建Xact軟件包。如果你想重建該軟件包的話， 你只需調整環境變量和它使用的config.xml 中的URL。但是，如果你這樣做的話，你得重寫添加到Stub 類Web方法的代碼行，你要用它來覆蓋原來的代碼行。
我們看看XactClientApp，樣品客戶端應用程序類：
import Xact.*;
import javax.xml.rpc.Stub;
import Payload.*;
public class XactClientApp {
/** Creates a new instance of XactClientApp */
public XactClientApp() {
}
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
try {
int cyclesPerXact = 1;
int numberXacts = 5;
String transactionID = "";
String transactionType =
String.valueOf(cyclesPerXact) +" submit,check,gets";
Stub stub = createProxy();
XactServiceServantInterface xact = (XactServiceServantInterface)stub;
CurrentReport cr = new CurrentReport();
for (int x=1; x＜= numberXacts;x++){
cr.BeginTransaction();
for (int i=1; i＜=cyclesPerXact;i++){
transactionID = xact.submitWork("new transaction");
System.out.println("Transaction:" + transactionID);
boolean unused = xact.checkWork(transactionID);
String ignore = xact.getResult(transactionID);
}
cr.CommitTransaction(transactionID, transactionType,"success");
}
} catch (Exception ex) {
ex.printStackTrace();
}
}
private static Stub createProxy() {
return (Stub)(new XactService_Impl()).getXactServiceServantInterfacePort();
}
}
先看它的內部循環。客戶端應用判斷商業事務的組成。在本例中，它包括三個Web服務調用：針對submitWork()、checkWork()和getResult()的分別調用。客戶端使用beginTransaction()和 commitTransaction()定界事務。在該循環的第二個循環中，在CurrentReport.LastReport 對象中將出現一個完整的ClientReport。當客戶端調用submitWork()時，Web 服務客戶端Stub 類中相應方法調用Serializer.attachPendingReportToMessage() 將該報告連接到SOAP信息上。
CyclesperXact和numberXacts用於控制每件事務的Web服務調用數和客戶端在運行過程中遞交的事務數。
右擊應用程序圖標XactClientApp；先選擇Build All項，接著選擇Execute項。在執行窗口中，你會看到：對於每件事務，應用都報告它收到的事務標志符。觀察應用服務Windows輸出控制台，你可以看到以下的代碼行：
INFO: CORE3274: successful server startup
INFO: CORE5053: Application onReady complete.
INFO: CORE3282: stdout: Exception occurred connecting to queue: javax.naming.Nam
eNotFoundException
INFO: CORE3282: stdout: Exception occurred connecting to queue: javax.naming.Nam
eNotFoundException
INFO: CORE3282: stdout: Exception occurred connecting to queue: javax.naming.Nam
eNotFoundException
INFO: CORE3282: stdout: Exception occurred connecting to queue: javax.naming.Nam
eNotFoundException
我們還沒有安裝應用服務次數排列或者配置應用服務次數讀取器EJB。客戶端產生次數福建，服務器接收它，並試圖將它列隊到一個不存在的隊列中。Serializer 類只是報告錯誤並允許應用程序繼續運行。回想我們的目標之一就是保持商業事物系統的總可靠性。可是我們卻看到即使新的次數組件失敗，關鍵的商業事務仍然可以照常進行。
定義服務器次數隊列
為了定義服務器的次數隊列，我們必須創建一個Java Messaging Service (JMS) 隊列以便我們可以異步地傳遞來自於Web服務處理器的次數附件到處理次數的EJB組件中。
Sun ONE應用服務器有一個嵌入式的Sun ONE信息隊列(MQ) 服務器。你可以三步完成應用服務器內的隊列的定義。首先，定義一個物理目的文件。其次，創建一個關聯的JMS 目的文件的源文件。最後，定義QueueConnectionPool，使它能允許應用連接到隊列中並完成操作。
你可以使用Application Server Administration Console 來完成這三個步驟。在Windows下，點擊開始菜單，依次選擇程序、Sun 微系統、Sun ONE應用服務 、最後選擇Start Administrator Console即可。
要創建物理目的文件，你得通過應用服務器來實現，這可以通過依次選擇JMS、Services 和Physical Destinations來完成。點擊按鈕New 就可創建一個新的目的文件。將新文件命名為TestMDBQueue，選擇一個隊列類型，然後點擊OK。
創建隊列的源目的文件也得通過應用服務器。同樣的，選擇JMS，再選Destination Resources。點擊按鈕New，輸入jms/TestMDBQueue作為JNDI (Java 命名和目錄接口) 名，選擇類型javax.jms.queue並點擊OK。創建了目的文件後，惦記他，然後點擊它的Properties 按鈕。輸入唯一的屬性imqDestinationName，並將它賦值為TestMDBQueue。這可以使隊列與我們剛才創建的物理目的文件關聯起來。
最後，我們要創建連接工廠。這也得在應用服務器上進行。選擇JMS，然後選擇Connection Factories；點擊New，輸入jms/TestMDBFactory作為JNDI名，選擇類型javax.jms.QueueConnectionFactory，然後點擊OK。
你必須將修改應用到實際的隊列組件上。點擊應用服務器上的Apply Changes 按鈕， 在服務器控制台輸出窗口內你將看到創建的新組件：
INFO: JMS5002: Binding [＜ JMS Destination: jms/TestMDBQueue, javax.jms.Queue, [
imqDestinationName=TestMDBQueue ] ＞]
INFO: JMS5002: Binding [＜ JMS Connection Factory: jms/TestMDBFactory, javax.jms.
QueueConnectionFactory, No properties ＞]
建立和配置服務器次數讀取器EJB組件
我們已經創建了一個服務器隊列，現在我們可以配置信息驅動的EJB組件，它可讀取來自隊列的次數附件。首先安裝文件系統＜download directory＞/Metrics/MDBTester 並點擊 TestMDB(EJB) 圖標。在它的屬性窗口內，點擊Sun ONE AS 跳格鍵並檢測最後兩個屬性：映射訪問。點擊這兩個屬性並確認他們能夠訪問我們前面定義的JMS 源文件。
右擊EJBModule_TestMDB並選擇Deploy項。在EJB組件配置後，我們在應用服務器控制台的輸出窗口內會看到與下列信息類似的信息：
INFO: MDB00044: Deploying message-driven bean [EJBModule_TestMDB:TestMDB], consu
ming from [jms/TestMDBQueue]
INFO: MDB0001: Create message-driven bean pool with maximum pool size [640], bea
n idle timeout [600] seconds
INFO: MDB00022: [EJBModule_TestMDB:TestMDB]: Message-driven bean listening on JM
S destination [TestMDBQueue]
INFO: LDR5010: All ejb(s) of [EJBModule_TestMDB] loaded successfully!
這個 EJB組件可放在一個單獨的模塊內因為我們在其他的服務中配置它的機率比事務服務應用中的配置機率還大一些。
運行樣品實現
至此，我們已經配置了次數報告所需的所有基礎設施，我們可以看一些客戶端相應次數的報告。再次執行XactClientApp ；這一次，應用服務控制台輸出窗口內將出現下列信息：
INFO: CORE3282: stdout: Took:2613 MS. for: 1 submit,check,gets
INFO: CORE3282: stdout: Took:431 MS. for: 1 submit,check,gets
INFO: CORE3282: stdout: Took:4307 MS. for: 1 submit,check,gets
INFO: CORE3282: stdout: Took:871 MS. for: 1 submit,check,gets
每一次次數讀取器EJB組件都收到一個客戶端報告，它將報告解碼到ClientReport 上並報告clientElapsedMS 字段。在本例中，IDE和應用服務器都在 Compaq公司的 Presario 膝上型電腦上運行，所以報告的響應次數當然不是典型的應用服務次數。
注意，當客戶端執行五個事務時，實際上只有四個報告。客戶端應用會話期的最後一個事務不報告因為對於整個報告來說沒有後續的事務可運載報告。
此次實現基本上是一個取樣。它收集了大多數事務——當然足夠測量服務的質量——但是不是全部。要糾正它我們得對客戶端應用做一些調整。提高Payload軟件包可持續會話期間的次數報告，但是這仍然不能保證所有事務都報告。因為我們在次數收集失敗時仍然允許事務繼續，這是一個很重要的目標，整個系統必須總是一個事務取樣器，而不是徹底的記錄器。
改進和後續工作
這個實現可在幾個方面得到改進，從而為企業提供更多的便利。
你可以擴展ClientReport類，這樣客戶端就可以報告更多關於事務的信息。當分析服務器上的響應次數時，我們知道的關於事務的信息越多，分析就會越好。辨別出哪種事務要占用很長時間，這很重要。由於服務器瓶頸問題，占用很長時間的事務與生俱來的就要復雜一些。減小服務器瓶頸的壓力是原則性的目標。改進ClientReport最好的方法是添加 (attribute,value)字符串排列，該排列允許客戶端報告事務的二進制特征。
次數收集結構也有助於企業服務管理的其它方面。當服務器在域中有上千個或者上萬個客戶端的話，保證服務器軟件升級後仍與現有的客戶端庫兼容，這很重要。但是哪種軟件版本是客戶端運行的呢？這常常難以確定，但是如果ClientReport 類可以使用客戶端軟件版本域擴展，也可使用客戶端操作系統版本擴展，簡單的次數數據庫查詢就會提供該信息。
你可以改進Payload軟件包來報告客戶端軟件錯誤。客戶端異常處理可保存產生失敗的上下文的細節，這樣當應用程序重啟時Payload軟件包可以上傳該信息。這突出了主要潛在問題的一個方面：警報。 次數讀取器EJB組件在收到客戶端軟件錯誤報告時，就可以開始它的商業工作流程處理。它可以產生一個SNMP (簡單網絡管理協議)陷阱或者發送email，允許客戶服務人員啟動一個調用到擅長解決問題的用戶那裡去。
接收精確的客戶端響應次數
在本文中，我展示了如何將事務響應次數記錄層壓到現有的J2EE服務應用上。該方法可用於測量客戶端應用方面的精確的響應次數。這個實現是輕便的。客戶端和服務器之間不需要新的網絡通信。次數有效載荷為低優先級的登記列隊等待，所以預訂服務器資源來處理應用程序。（全文完）
