除錯 SCA 呼叫

這個由兩部分組成的系列介紹如何使用 IBM® WebSphere® Process Server V6.1 中的應用程式響應度量（Application Response Measurement，ARM）標準來監視服務元件體系結構（Service Component Architecture，SCA）呼叫。您可以使用諸如 IBM Tivoli® Composite Application Manager for Response Time Tracking 等 ARM 實現來生成 SCA 呼叫的圖形檢視。本文是該系列的第一部分，將首先描述 ARM 並介紹如何使用 Tivoli Composite Application Manager for Response Time Tracking 來除錯同步場景。在第 2 部分中，您將獲得關於 SCA 呼叫模式的介紹，並瞭解如何除錯非同步場景。

引言

WebSphere Process Server 引入了 SCA，將其作為構建面向服務的體系結構（Service-Oriented Architecture，SOA）系統的程式設計模型。作為企業解決方案，SCA 支援現有的技術，例如 Java™ 和 Web 服務，並建立統一的檢視來組裝各種實現 Java 或 Web 服務描述語言（Web Services Description Language，WSDL）介面的元件。通常，在設計改進、效能優化或故障排除過程中的執行時期間，您需要監視 SCA 元件。您可以通過分析效能指標來解決諸如故障條件或不可接受的延遲等問題。

WebSphere Process Server V6.1 提供了用於 SCA 呼叫的觀察功能，並支援各種統計資訊輸出標準，包括公共事件基礎設施（Common Event Infrastructure，CEI）、效能監視基礎設施（Performance Monitoring Infrastructure，PMI）和 ARM。通過選擇相應的監視點以向 CEI 發出事件，您可以監視某些服務元件，或者可以通過 PMI 或 ARM 獲取效能統計資訊。

WebSphere Process Server V6.1 中的 ARM 是 SCA 級別的效能度量，與其他格式相比，ARM 可產生有關效能的某些方面的更詳細資訊。ARM 主要集中於 SCA 中每個流程的完成狀態、間隔時間和事務沿襲 (lineage)。由於 ARM 的性質，效能統計資訊邏輯地相互聯絡在一起，從而可以更好地檢測 SCA 呼叫中的瓶頸。

什麼是 ARM？

ARM 是一個 Open Group 標準，用於測量應用程式或業務服務的效能和可用性。應用程式在開發階段中對其進行檢測，並在執行時使用它來分析所涉及到的事務。

ARM 的基本功能是記錄每個事務的啟動和停止時間戳（附帶執行結果）。事務通過 ARM 生成的令牌互連在一起，並由應用程式進行傳遞。在所有事務都完成以後，可以在相關事務的基礎上提取出拓撲，並且系統管理員可以分析統計資訊以確定代價昂貴和有問題的執行路徑在何處。

在某種程度上，ARM 的工作類似於一個功能強大的秒錶，並提供了一個包含 start() 和 stop() 條目的介面，就像教練使用的秒錶一樣。不同的運動員就像各個事務，並且呼叫鏈就像接力賽跑，接力棒從一個運動員傳遞到下一個運動員，非常類似於將事務聯絡起來的相關令牌。

WebSphere Process Server V6.1 通過一個 ARM 4.0 標準 Java 繫結接受檢測，並支援監視 SCA 呼叫的事務統計資訊。注意：WebSphere Process Server 沒有附帶 ARM 代理；它支援 ARM 標準，這意味著使用者將選擇自己的實現提供者。（請參閱參考資料，以獲取指向 Open Group 網站上的 ARM 標準官方文件的連結。）

使用 Tivoli Composite Application Manager for Response Time Tracking 除錯 WebSphere Process Server V6.1 中的同步 SCA 呼叫

在本文中，Tivoli Composite Application Manager for Response Time Tracking 是收集和分析 WebSphere Process Server V6.1 中的 SCA 呼叫資料的 ARM 實現提供者。這裡，您將使用一個單模組、多元件的 SCA 呼叫場景，作為了解如何提供 ARM 資料的示例（請參見圖 1）。在此場景中，所有呼叫都是通過同步實現來進行的同步呼叫（請求-響應操作）。（本系列的第 2 部分將對相關模式進行描述）。對於元件 1、2、3、4 和 6，預設的本地處理時間為 0.5 秒；對於元件 5，該時間為 3 秒，是瓶頸之所在。

圖 1. 單模組中的 SCA 呼叫示例

安裝和檢測

Tivoli Composite Application Manager for Response Time Tracking 引入了客戶機/伺服器體系結構，其中管理代理收集資料，管理伺服器則監視、維護和分析代理所收集到的資料。

在此場景中，您將設定一個帶有 WebSphere Process Server V6.1 的客戶機和一個管理代理，其中管理代理是一個帶有管理伺服器的伺服器。作為管理伺服器設定先決條件的 WebSphere Application Server and IBM DB2® 也安裝在伺服器端（請參見表 1）。

表 1. 該場景中的設定環境

客戶端	伺服器端
WebSphere Process Server V6.1	Tivoli Composite Application Manager for Response Time Tracking V6.1 管理伺服器
Tivoli Composite Application Manager V6.1 管理代理	WebSphere Application Server V6.0.2
	IBM DB2 Enterprise Server V9.1

注意：有關安裝和配置的更多資訊，請訪問 IBM Tivoli 資訊中心以獲取 IBM Tivoli Composite Application Manager for Response Time Tracking Installation and Configuration Guide（在左側窗格中單擊 Composite Application Manager for Response Time Tracking > Installation and Configuration Guide）。

完成安裝以後，伺服器將識別代理（請參見圖 2），因此使用者應該能夠為代理建立偵聽監視器，本文稍後將對此進行介紹。

圖 2. 識別出的代理

下一步是客戶端上的 ARM 檢測：

1. 將 armjni4.jar 從 \lib\ 複製到其類檔案可由 WebSphere Process Server V6.1 載入的位置。
2. 在客戶端啟動伺服器。
3. 在管理控制檯中，選擇 Application servers > ${SERVER_NAME} > Process Definition > Java Virtual Machine > Custom Properties，並向 Java 虛擬機器新增如表 2 所示的條目。

表 2. 要新增的 Java 虛擬機器屬性

名稱	值
Arm40.ArmMetricFactory	com.ibm.tivoli.transperf.arm4.metric.Arm40MetricFactory
Arm40.ArmTranReportFactory	com.ibm.tivoli.transperf.arm4.tranreport.Arm40TranReportFactory
Arm40.ArmTransactionFactory	com.ibm.tivoli.transperf.arm4.transaction.Arm40TransactionFactory

4. 重新啟動 WebSphere Process Server V6.1 並執行該應用程式。管理代理快取 ARM 資料，並將其傳送到管理伺服器。
5. 開啟管理伺服器管理控制檯，您應該在其中看到該事務已被發現（請參見圖 3）。

圖 3. 已發現的事務

偵聽監視器應該根據所發現的事務來進行配置。（請參見圖 4）。

圖 4. 偵聽監視器

6. 再次執行該應用程式。該監視器稍後捕獲來自代理的效能資料，然後可以生成報告。

分析資料

Tivoli Composite Application Manager for Response Time Tracking 提供了統計或基於例項的檢視來分析結果。

1. 選擇 Dashboard 以檢視當前監視器狀態，如圖 5 所示。

圖 5. 監視器狀態

2. 要在此同步場景中除錯單個例項，請單擊 Reports > General Reports > Topology，並選擇感興趣的例項。拓撲如圖 6 所示。

圖 6. 拓撲報告

在此拓撲檢視中，ARM 呼叫鏈以圖形形式重現，這與通過 IBM WebSphere Integration Developer 開發的場景一致（請參見圖 1）。

在圖 1 所示的級別中，詳細的事務按事務名稱或 SCA 事件源名稱進行分組，其中事務名稱由元件的唯一名稱、介面名稱和操作名稱組成：Transaction Name = SCA..MethodInvocation.__

您可以看到 Component5 在該呼叫中的本地時間是 3.008 秒。黃色的感嘆號表示該元件是整個鏈的瓶頸（請參見圖 7）。

圖 7. 呼叫中的瓶頸

注意：在此檢視級別中，事務進行了分組，此級別在大多數情況下已經足夠了。如果您想除錯元件之間的內部事務，可以單擊感興趣的事務組的標記。與模式相當（本系列的第 2 部分將對此進行描述）的內部事務將顯示出來。圖 8 顯示了展開名為 SCA.com.ibm.xmlns.prod.websphere.scdl._6_0_0.Component5.MethodInvocation_FooInterface_fooOperation 的事務組的示例，該事務組包括 Component4 與 Component5 之間的呼叫中的兩個事務。從圖 8 中可以看到，在這個同步呼叫中，參考端事務僅花了 0.004 秒 (3.006 – 3.002)，而目標端事務花了 3.002 秒 (3.002 – 0)。

圖 8. 事務的展開檢視

實際上，您可以在事務細分報告（請參見圖 9）中視覺化並容易地識別事務時間長度，該報告包括一個表和一個細分檢視。如果細分檢視中的某欄太短而無法看到完整的名稱，只需選擇該欄並在提示訊息框中或左側高亮顯示的表中查閱該名稱。

圖 9. 事務細分報告

在對某個元件執行時間分析時，您將挑選聯絡在一起並具有共同名稱的事務。這是因為，對於某個呼叫中的兩個元件之間的事務，當針對同一個元件時，事務名稱是相同的（請參見圖 10）。

圖 10. 具有相同名稱的事務

在細分檢視中，事務欄的長度表示每個事務的響應時間。在這個同步請求-響應呼叫中，本地時間等於響應時間減去下游時間，因此您可以繪製出本地時間的圖形（請參見圖 11）。顯然，Component5 所花的本地時間最長。

圖 11. 對事務細分的本地時間分析

如果 Component5 引發 ServiceBusinessException，則拓撲報告將其標記為紅色，因此您可以容易地識別故障點，如圖 12 所示。

圖 12. 拓撲報告中的故障點

上面的呼叫是典型的同步呼叫場景。對於諸如非同步呼叫等場景，事務細分檢視稍微有所不同。（本系列的第 2 部分將對此進行描述。）

結束語

現在您應該能夠使用 Tivoli Composite Application Manager for Response Time Tracking 作為檢視 ARM 資料的實用工具，從而容易地除錯並發現 WebSphere Process Server V6.1 中的典型 SCA 同步呼叫中的瓶頸或故障點。

同步呼叫型別只是可能的呼叫型別之一；SCA 程式設計模型還支援另外三種非同步呼叫：

• 單向
• 延遲響應
• 回撥

若要更深入地瞭解這些呼叫中的 ARM 事務和使用 Tivoli Composite Application Manager for Response Time Tracking 的除錯技術，請繼續關注本系列的第 2 部分。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-406626/，如需轉載，請註明出處，否則將追究法律責任。