受管理物件

JMS 規格建立一套標準，結合了現有 MOM 系統的許多元素，但並不打算涵蓋所有可能性。相反地，它試圖建立可延伸的方案，以容納差異並得以進一步發展。JMS 讓個別提供者自行決定要如何定義與實作許多訊息傳送元素。這些元素包括負載平衡、標準錯誤訊息、管理 API、安全性、基礎線路協定和訊息存放區。下一節Message Queue：元素和功能將說明 Message Queue 如何實作其中的許多元素，以及如何延伸 JMS 規格。

JMS 未完全定義的訊息傳送元素有兩個：連線工廠和目標。雖然這兩個都是 JMS 程式設計模型中的基本元素，但是提供者定義與管理這些物件的方式存在許多現有和預期的差異，所以不可能也不需要建立共同的定義。因此，這兩個物件不會以程式設計的方式建立，一般會使用管理工具來建立與配置。這兩個物件之後會儲存在物件存放區，並由 JMS 用戶端透過標準 JNDI 查找來存取。

• 連線工廠受管理物件可用於產生用戶端至代理程式的連線。這些物件封裝提供者專用的資訊，以管理訊息傳送運作方式的特定方面：連線處理、用戶端識別、訊息標頭置換、可靠性和流量控制等。源自指定連線工廠的每個連線會以該工廠的配置方式運作。

• 目標受管理物件可用於參照代理程式上的實體目標。這些物件封裝提供者專用的命名 (位址語法) 慣例，並指定使用何種訊息傳送網域以使用目標：佇列或主題。

JMS 用戶端不需要查找受管理物件，而可以透過程式設計建立這些物件 (之後這些物件會儲存在代理程式的記憶體中)。若要有快速參考原型，透過程式設計建立這些物件可能是最簡單的方式。但是若要在生產環境中部署，在中央儲存庫內查找受管理物件，會比較容易控制與管理訊息傳送的運作方式：

• 管理員針對連線工廠物件使用受管理物件，可以經由重新配置這些物件，來調校訊息傳送的效能。不需要重新撰寫程式碼就能改善效能。

• 管理員針對實體目標使用受管理物件，可以經由要求用戶端存取這些預先配置的物件，來控制這些目標不會在代理程式上激增。

• 受管理物件讓開發者不用考量提供者專用的實作細節，讓他們為一個提供者開發的程式碼在不變更或變更很少的情況下，就可移植至其他提供者。

受管理物件為基本的 JMS 應用程式圖片增添了最終的創意，如圖 1–5 所示。

圖 1–5 JMS 應用程式的基本元素

圖 1–5 顯示訊息產生器和訊息用戶如何使用目標受管理物件存取對應的實體目標。標示的步驟表示管理員和用戶端應用程式使用此機制傳送和接收訊息時，需要採取的動作。

使用受管理物件作為目標

1. 管理員在代理程式上建立實體目標。

2. 管理員建立目標受管理物件，並透過指定其對應的實體目標名稱和以下類型進行配置：佇列或主題。

3. 訊息產生器使用 JNDI 查找呼叫，查找目標受管理物件。

4. 訊息產生器傳送訊息到目標。

5. 訊息用戶查找目標受管理物件，期望從中獲取訊息。

6. 訊息用戶從目標取得訊息。

   使用連線工廠受管理物件的程序很類似。管理員使用管理工具建立並配置連線工廠受管理物件。用戶端查找連線工廠物件，並以此建立連線。

   雖然使用受管理物件增加了訊息傳送程序的步驟，但同時也會增強訊息傳送應用程式的牢固性和可移植性。