使用動態緩存提升 WebSphere Process Server 和 WebSphere ESB 解決方案的性能
當您在開發 SCA 解決方案時，會經常需要一些難以獲取或難以計算的數據。為了獲得這些數據，您可 能需要調用 Web 服務、連接到數據庫、執行復雜的邏輯運算或從多個數據源匯總數據。如果這些數據不 會隨時間發生變化，您可以通過適度使用緩存來獲得顯著的性能提升。本教程將向您展示一種簡單有效的 緩存技術 DynaCache，它基於一個成熟的產品特性，能夠幫助您滿足應用程序性能需要。此外，通過使用 DynaCache，緩存數據復制的復雜性和網絡部署拓撲節點間的同步將會交由底層基礎架構自動、透明處理 。
關於本教程
本教程基於一個檢索並返回地點明細的虛擬服務。您可以將該服務想象成一 個房間預定系統的一部分，其中系統的校園和設施信息從別處獲得。您確定校園設施信息很少變化，因此 您考慮完全可以用本地緩存來實現這個特別的服務。當地點明細數據發生變化時，您還將學習如何使緩存 條目失效並清除緩存。
目標
您將學會如何：
定義服務接口。
構建緩存組 件。
測試緩存組件。
使用緩存條目及清理緩存。
前提條件
本教程假設您對 Java™ 編程語言有一定了解，熟悉 SCA 編程模型，對 WebSphere® Integration Developer 中的 WSDL 接口、數據類型、SCA 組件以及集成測試客戶端的使用比較熟練。
系統需求
本教程使用 WebSphere Integration Developer V6.2.0.2 開發。但是，代碼能在各 版本產品中編譯運行，包括即將發布的第 7 版。
學習時間
學習本教材大約需要 1 小時 。
定義服務接口
在本部分，您將著手准備訪問服務所需的接口和數據類型。
任務 1: 新建 WebSphere Integration Developer 項目
啟動 WebSphere Integration Developer，新建一個工作區，並切換到 Business Integration 視圖 。
使用 File -> New -> Module 菜單, 將模塊命名為 CachingTutorial，保留默認項，單擊 Finish。
任務 2：創建服務接口和消息類型
您將會用到四種數據類型表示請求和響應信息：
LocationBasicInfo
Address
Facility
LocationDetails
在 Business Integration 視圖中右鍵單擊 Data Types 文件夾並選擇 New -> Business Object 新建一個數據類型。
將新建的業務對象命名為 LocationBasicInfo。此數據類型表示請求 消息並包含用以檢索地點明細的 地點 ID。
為該對象添加兩個字符串類型的屬性，並分別命名為 id 和 name。使用 Add Field 工具添加屬性， 如圖 1 所示。
圖 1. 請求消息
接下來，創建其余的三個業務對象，它們合起來組成響應數據結構。請特別注意 LocationDetails 上 的 “Facilities” 字段，它是一個 Facility 類型對象的數組（圖 2）。
圖 2. 響應消息
最後，創建服務接口。您可以通過右鍵單擊 Interfaces 文件夾完成。將接口命名為 LocationService，創建一個名為 retrieveLocationDetails 的請求-響應操作，它有一個類型為 LocationBasicInfo、名為 request 的輸入參數和一個類型為 LocationDetails、名為 response 的輸出 參數（圖 3）。
圖 3. 服務接口
現在，您已經有了請求和響應數據結構的定義，以及對服務接口及操作的描述。
我故意 將響應消息的結構設計成像 LocationDetails 這樣。響應對象將最終存儲在緩存中，我想展示一下我們 的緩存解決方案處理各種數據結構的能力。如果您再次查看 圖 2，您將看到響應對象包含一個簡單類型 （String 類型的 name），一個復雜類型（Address 類型的 address）和一個 序列（Facility 類型對象 數組 facilities）。
構建緩存組件
在本部分中，您將學習如何通過創建一個 Java 組件來構建一個透明緩存。這個 Java 組件實現了與 目標服務相同的接口，並能與 WebSphere 動態緩存服務交互。
在 Business Integration 視圖中右鍵單擊打開 Assembly Diagram。您可以檢查剛創建好的業務對象 和接口。它們會顯示在 Business Integration 視圖中，如圖 4所示。
圖 4. Business Integration 視圖
在 Assembly Diagram 中創建一個 Java 組件。將此組件命名為 CachingComponent 並使用它的彈出 工具欄添加一個接口和對該組件的引用。為兩者使用 LocationService 接口。保存裝配圖。參考圖 5 中 完成的裝配。
圖 5. 完成的裝配
對本教程來說，裝配已經完成，現在已完成一個工作模塊用於測試。在實踐中，目標服務 位於別處，您可以通過使用 Import 來綁定。您也可以在使用 Export 把服務暴露給客戶前使用中介模塊 來調停請求和響應。
在這種布局下，客戶將綁定到您的模塊輸出上。在輸出和中介模塊之間插入緩存組件對服務使用者是完全 透明的。
雙擊緩存組件生成其實現。這將為 retrieveLocationDetails 操作生成一個 stub 方法，這個操作將 在稍後實現。
在實現接口操作前，您需要創建一個靜態類成員和靜態類方法來查找默認 DynaCache 對象的緩存實例 （清單 1）。
清單 1. 默認對象緩存實例
private static DistributedObjectCache cache = initCache();
static DistributedObjectCache initCache(){
try {
InitialContext ic = new InitialContext();
return (DistributedObjectCache) ic.lookup("services/cache/distributedmap");
} catch (NamingException e) {
e.printStackTrace();
return null;
}
}
將清單 2 中的導入添加到類中。
清單 2. 緩存組件導入
import javax.naming.InitialContext;
import javax.naming.NamingException;
import com.ibm.websphere.cache.DistributedObjectCache;
既然有了對 DynaCache 對象緩存實例的引用，您必須實現該接口操作，如清單 3 所示。
清單 3. 接口操作實現
public DataObject retrieveLocationDetails(DataObject request) {
// retrieve key to cache from the request
String key = request.getString("id");
DataObject responseObject = null;
// get response from cache
responseObject = cache == null ? null : (DataObject) cache.get(key);
// if cache miss invoke service and update cache
if (responseObject == null) {
DataObject responseMessage = (DataObject)
locateService_LocationServicePartner().invoke("retrieveLocationDetails", request);
responseObject = responseMessage == null ? null :
responseMessage.getDataObject("response");
if ((cache != null) && (responseObject != null)) {
cache.put(key, responseObject);
}
}
return responseObject;
現在花點時間來理解這段代碼。作為 WebSphere Process Server 和 WebSphere ESB 運行時架構基礎 的 WebSphere Application Server 提供了一種分布式的緩存基礎架構和 API。
可以使用 JNDI 名稱 services/cache/distributedmap 找到現成的默認對象緩存實例。對於本教程來 說，使用該實例是可以的，但在生產系統中，最佳實踐是為您想緩存響應的每個服務創建一個專用實例。 這將保證緩存實例的獨立性，並為禁用緩存條目和清空緩存提供了更細的粒度。
接口方法將會從請求中檢索 id 屬性，然後將其用作從緩存中檢索響應的鍵值。如果未找到對應的響應 ，代碼將調用服務伙伴。
保存並關閉 Java 編輯器。
測試緩存組件
在本部分，您將模塊部署到測試服務器上並確認服務緩存能按要求運行。
在裝配圖中，右鍵單擊 CachingComponent 並選擇 Test Component。
在 Initial Request Parameters 面板中，填充請求 ID 並繼續測試，確認部署位置。此時，測試服 務器將啟動，模塊也將自動部署。
測試客戶端提供了對組件引用的手動模擬器。當調用引用時，需要手動模擬服務。進入模擬器的 Output Parameters 部分並輸入響應值，包括設施列表中的一些元素，然後繼續測試。
一旦測試完成，請注意 Events 面板（圖 6），這上面顯示了模擬服務。
圖 6. 首次運行 — 來自 服務的響應
返回測試並使用相同的請求 ID。這一次，模擬器將不會執行。請再看一下圖 7 中顯示的事件。請注 意緩存組件不再需要調用其服務伙伴，因為它現在已在動態緩存中找到與請求 ID 對應的響應信息。
圖 7. 再次運行 — 來自緩存的響應
最後，第三次運行測試，但這次使用不同的請求 ID。這次，引用模擬器再次運行，您需要輸入新的響 應值。圖 8 顯示的是第三次運行後的事件面板。
圖 8. 第三次運行 — 來自服務的響應
使用緩存條目以及清空緩存
作為可安裝應用程序 的一部分，同時提供的還有緩存監視器應用程序。緩存監視器用作監視 servlet 緩存實例。為了能監視對象 緩存實例, 您需要參考 IBM Extended Cache Monitor for IBM WebSphere Application Server 技術前瞻 來擴展此應用程序。
緩存監視器應用程序安裝並更新後，您就可以從 Web 浏覽器訪問緩存監視器，方法是打開 Web 浏覽 器，輸入 URL：http://localhost:9080/cachemonitor/。實際端口可能有所不同。
緩存監視器使用的驗證憑證與管理控制台相同，WebSphere Integration Developer 默認安裝後通常 是 “admin/admin”。
從下拉列表中選擇 default 緩存實例並單擊 OK。如果默認實例未顯示，需要單擊 Refresh Instances（圖 9）。
注意：一旦測試執行，默認緩存實例只能生成一次。 在使用緩存監視器前，一 定要確認完成了 測試緩存組件 部分的操作。
圖 9. 默認緩存實例
單擊 Cache Statistics 並仔細研究圖 10 中的表。緩存中有兩個使用過的條目。其中一個請求已由 緩存服務，兩個請求未被緩存的響應滿足。請注意 Clear Cache 按鈕，它可以清空緩存。可以通過重啟 服務器清空緩存，或者使用 clear() 方法以編程方式清空緩存。
圖 10. 緩存統計
最後，單擊 Cache Contents。在該面板中（圖 11），您將看到兩個緩存條目，它們的 ID 是在請求 中使用的。可以在緩存內容面板中設置各緩存條目無效。
圖 11. 緩存內容
還有許多參數和策略設置可以應用到緩存實例以控制多個屬性，如緩存大小、緩 存條目回收標准、允許緩存條目卸載到二級存儲、緩存條目相關性、緩存條目超時以及其它。
結束語
在本教程中，您學習了如何從 SOA 的視角來使用 WebSphere Dynamic Cache 服務。您完成了一個服 務，其響應信息被緩存以提高解決方案的性能。您還學習了如何使用 WebSphere Integration Developer 構建一個透明的 SCA 緩存組件。您還測試了該緩存組件，學習了如何監視並管理緩存。另外，本教程還 討論了使用對象緩存實例的最佳實踐。
本文配套源碼
