由於企業、機構和技術持續演變,為其提供服務的軟體系統必須能夠因應演變的趨勢。企業可能因為合併、新增服務或擴充可用的服務,而急需重建企業資訊系統。在此迫切的情況下,企業需要整合新的元件或儘可能有效地延展現有的元件。整合異質元件最簡單的方法並非將其重建為同質元素,而是提供一個層級,使其可以無視差異進行通訊。此層級稱為中介軟體,可讓獨立開發及在不同網路平台上執行的軟體元件 (應用程式、Enterprise Java Bean、Servlet 和其他元件) 彼此互動。當此互動成為可能時,網路就能變成電腦。
如圖 1–1 所示,中介軟體介於應用程式層與平台層 (作業系統與基礎網路服務) 之間。
分散於不同網路節點的應用程式會使用應用程式介面進行通訊,而不用考量執行其他應用程式的作業環境細節,也不用考量將其連線到這些應用程式的服務。此外,藉由提供管理介面,這種新型虛擬的互連應用程式系統非常可靠安全。其效能可以測量和調校,並且可以在不遺失功能的情況下進行延展。
中介軟體可以分為下列種類:
遠端程序呼叫 (RPC 型) 中介軟體,這可允許應用程式中的程序像呼叫本機程序那樣呼叫遠端應用程式中的程序。該中介軟體執行連結機制,尋找遠端程序並使其可供呼叫者使用。在過去,這類中介軟體會處理程序型程式,現在它還可包含物件型元件。
訊息導向 (MOM 型) 中介軟體,可讓分散的應用程式透過傳送與接收訊息,進行通訊與交換資料。
所有這些模型均可以透過網路,使一個軟體元件影響另一個元件的運作方式。不同之處在於 RPC 型和 ORB 型中介軟體會建立元件緊密耦合的系統,而 MOM 型系統則允許耦合較鬆散的元件。在 RPC 或 ORB 型系統中,當一個程序呼叫另一個程序時,必須等候被呼叫的程序傳回,才能夠進行其他工作。如前所述,在這些模型中,中介軟體的部分功能是超級連結程式,在網路上尋找被呼叫程序,並使用網路服務傳送函數或方法參數至此程序,然後再傳回結果。
MOM 型系統可透過非同步交換訊息來進行通訊,如圖 1–2 所示。
訊息導向中介軟體利用訊息傳送提供者協調訊息傳送作業。MOM 系統的基本元素為用戶端、訊息和 MOM 提供者 (包含 API 和管理工具)。MOM 提供者會使用不同的架構來路由和傳送訊息:它可以使用集中化訊息伺服器,或者將路由和傳送功能分發給每部用戶端電腦。部分 MOM 產品則結合這兩種方法。
使用 MOM 系統時,用戶端會發出 API 呼叫,將訊息傳送至提供者管理的目標。此呼叫會呼喚提供者服務來路由和傳送訊息。用戶端可在傳送訊息後繼續其他作業,確信提供者會保留訊息直到接收的用戶端接收到訊息為止。此訊息型模型會耦合提供者的協調,以便有可能建立元件鬆散耦合的系統。這類系統即使在個別元件或連線失敗時,還能夠可靠地繼續運作,而不會當機。
讓訊息傳送提供者協調用戶端之間的訊息傳送還有一個優點,就是透過增加管理介面,得以監視並調校效能。因此,除了傳送、接收及處理訊息問題之外,用戶端應用程式能有效解決每個問題。若要解決互通性、可靠性、安全性、延展性和效能等問題,需視執行 MOM 系統的程式碼以及管理員而定。
到目前為止,我們已描述了使用訊息導向中介軟體連接分散式元件的優點。但是也有缺點:其中一個缺點源於鬆散耦合本身。使用 RPC 系統,要等到被呼叫的函數完成其工作後,才會傳回提出呼叫的函數。在非同步系統中,呼叫的用戶端可以繼續接收載入工作,直到需要處理此工作的資源耗盡且被呼叫的元件失敗為止。當然,透過監視效能和調整訊息流量可減少或避免這些狀況,但是,這不是 RPC 系統的必要工作。重要的是瞭解每種系統的優點和職責。各個系統適用於不同的工作。有時,需要結合兩種系統才能取得需要的實際運作方式。
圖 1–3 顯示 MOM 系統如何啟用兩種 RPC 型系統之間的通訊。圖的左側顯示將用戶端、伺服器和資料存放區元件分發到不同網路節點,以改善效能的應用程式。這是折扣航空訂位系統:一般使用者付費使用此服務,指定目的地和時間以尋找最便宜的機票。資料存放區會保留參與此程式的註冊使用者和航空公司之相關資訊。根據使用者的請求,伺服器會依邏輯操作,詢問參與航空公司的價格、排序資訊,然後向使用者顯示最便宜的三家航空公司。圖的右側顯示的 RPC 型系統,表示任何一家使用該系統的航空公司訂票/訂位系統。圖的右側將會視折扣程式連線到航空公司的數量重複。對於各家這類航空公司,資料存放區可保留可訂位航班的資訊 (座次、航班時間和票價)。伺服器元件會回應一般使用者輸入的資料來更新該資訊。航空公司的伺服器也可訂閱 MOM 服務,接受來自折扣訂位系統的資訊請求,並傳回座次和票價資訊。如果客戶決定購買 PanWorld 航空公司的折扣機票,該系統的伺服器元件會更新資料存放區的資訊,然後開出請求者的機票,或傳送訊息到折扣服務以開出機票。
此範例描述 RPC 系統和 MOM 系統之間的一些差異。分散式元件耦合方式的不同之處,在前面已有所說明。還有一項差異是 RPC 系統通常用於分發與連接用戶端元件和伺服器元件,其中用戶端通常是一般使用者;而對於 MOM 系統,用戶端通常是異質軟體元件,僅能透過訊息傳送的方式互通。
MOM 系統有一個較為嚴重的問題,即 MOM 是實作為專用產品。當依賴 SuperMOM-X 的公司併購使用 SuperMOM-Y 的公司時,會發生什麼事?要有標準的訊息傳送介面才能解決此問題。如果 SuperMOM-X 和 SuperMOM-Y 均實作此介面,則開發為可在其中一個系統上執行的應用程式,也可以在另一個系統上執行。這類介面應該簡單易懂,卻又能提供足夠的功能,以支援複雜的訊息傳送應用程式。1998 年推出的 Java Message Service (JMS) 規格即為此應運而生。下一節將描述 JMS 的基本功能,並說明該標準的開發方式,如何涵蓋現有專用 MOM 產品的一般元素,以及允許差異性和未來發展。