如何從技術上選擇中間件

評估中間件掌握方法是關鍵
要選擇一個技術上符合要求的中間件既要了解自己的需求，還得能對一個中間件軟件作出技術上的評估。我們這里不談如何了解您的需求，只談如何對中間件做技術上的評估。隨著中間件的廣泛應用，最終用戶和應用開發商時常面臨這個問題。中間件的種類越來越多，單一產品的功能特性又越來越豐富，如果不得要領，就會陷入到無盡的細節之中。因此，掌握方法就非常重要。
選擇中間件當然不能只關注技術，必須考慮廠商實力、提供的服務、價格等相關因素，但技術上是否滿足需要無疑是位居第一位的。
以同類中間件的“標準功能”作為參考
你完全可以從你的具體需求出發，看看這個軟件是否適用，或者好不好。如果你知道你要評估的這一類中間件軟件通常具有的功能——我們稱它是“標準功能”——你就有了一個可作為參考的依據。你可以看一看你面前的中間件有沒有這些“標準功能”，如果沒有，是否對你有重要的影響。
各種中間件軟件的“標準功能”是什么？對于這個問題沒有標準和絕對的答案，但可以有多數人或多數廠家可以接受的答案，你不妨以之作為參考。如果找不到現成的，你也可以自己試著去歸納。向各個廠家要一下產品的介紹材料，做一下比較?！皹藴使δ堋蓖ǔ０诋a品的共性功能中。
把握功能需求、非功能需求與技術標準三個方面
我們在設計一個軟件時，可以把對軟件的需求劃分成功能需求和非功能需求。功能需求指明軟件必須執行的功能，定義系統的行為——即軟件在某種輸入條件下要給出確定的輸出必須做的處理或轉換。功能需求通常是軟件功能的“硬指標”——如“支持分布式環境中消息的可靠傳輸”；非功能需求不描述軟件做什么，描述軟件如何做。非功能需求通常作為軟件設計的“軟指標”——如“系統具有可伸縮性”。為此，我們可以把功能需求對應的功能稱為“功能性特征”，把非功能需求對應的功能稱為“非功能性特征”。評估一個中間件軟件，最主要的是看這個軟件的功能，包括功能性特征和非功能性特征，是否符合我們的要求，或者符合大多數人的通常要求。
如果你知道某一種中間件軟件的“標準功能”，你可以進一步把它分成“功能性的特征”和“非功能性特征”。如果你不知道，你只需從你的需求出發，研究一下你面前中間件的“功能性特征”和“非功能性特征”是否滿足你的功能需求和非功能需求。
中間件是處于支撐地位的通用軟件，其技術的標準化具有重要意義。中間件對技術標準的支持表現為使用標準的API、使用標準化的技術和實現標準化的功能等幾個方面。中間件支持標準通常意味著用戶和應用對廠商的依賴更小、應用開發人員學習使用一種新產品更容易，中間件軟件可以和更多的系統互操作，技術更開放。因此，評估一個中間件不僅要看它是否具有某項功能，還要看這個功能是否使用了標準的技術。
功能性特征是中間件的基本特征
中間件的功能性特征是一種中間件軟件的基本特征。不同種類的中間件的差異首先表現為基本功能的不同，因此我們不能總結出一套適合所有中間件門類的、一般性的“功能性特征”。
對于某一個具體的中間件軟件，我們能夠把它的功能性特征提取出來。我們假定某一中間件定位于解決分步式環境中消息的發送者和接收者之間消息傳輸、管理和控制問題，該軟件提供了多種消息交換方式、支持多種消息類型，提供可靠傳輸等服務質量控制機制，該軟件支持多系統平臺，支持高吞吐量的業務處理…。很顯然，我們可以把“提供多種消息交換方式、支持多種消息類型，提供可靠傳輸等服務質量控制機制”看成是該中間件的功能性特征，而把“支持高吞吐量的業務處理”作為非功能性的特征。
如果中間件的選擇者能夠從自己的需求中歸納出對中間件的“功能需求”，就可以把它們和面前的中間件的功能性特征做一下對照。
功能性特征一般比較容易測試，因而也比較容易驗證。
非功能性特征是跨中間件的共性特性
軟件的“非功能需求”是軟件需求的重要方面。中間件軟件的“非功能性特征”也是中間件功能的重要方面。事實上，中間件軟件的非功能性特征是跨中間件種類的、非常重要的一般性特征，是中間件軟件功能強大的表現。
我們這里采用了AberdeenGroup在2000年的《中間件——達成靈便的電子商務的技術基礎》一文中對成功的中間件的共性特征的歸納（做了一點裁減）：

許多情況下，非功能性和功能性并非有嚴格的界線。比如，對于消息中間件來說，可靠傳輸一定是功能性的特征；對于其它的中間件未必如此；對于安全中間件來說，安全不能算作非功能性特征。
非功能性特征一般比較難以測試，但仍然是一定程度可測試的。
支持標準對于中間件必可缺少
面向消息的中間件一直以來缺乏技術標準/規范。自從J2EE制定出基于Java的Java消息傳輸服務（JMS）以后，人們對消息中間件的技術要求就有多了一項內容。相比較而言，事務處理監控程序（交易中間件）相關的技術規范就要多一些，主要是X/OPEN（現稱為OPENGROUP）的分布式事務處理系列規范，包括TPM的架構、應用與TPM的接口及事務提交管理協議等重要內容。對于J2EE應用服務器，技術規范的影響就更大。我們甚至可以說，J2EE應用服務器的功能體現在了對技術標準和規范的支持上。
標準/規范雖然重要，我們不可迷信，唯標準是從。因為，第一，“標準”可能僅是建議性的，并非所有的廠商都會遵守；第二，“標準”可能是妥協的結果，只是將提交的多個可選內容統統收入，各項內容甚至不能互換；第三，“標準”可能是不完整的，僅僅實現了標準要求的內容可能意味著欠缺重要的功能。
比如，X/OPEN DTP模型中定義的應用與TPM的接口就是妥協的結果。所謂“標準”就是兩個廠家提交的完全不同的建議的羅列，兩者完全不能互換。事實上也未見第三家廠商遵從上述的“標準”。這樣的“標準”也只咎由自取參考意義。在看JMS，JMS當前規范只涉及一個消息服務器，規范只保證該服務器的客戶方都使用一個一致的接口。如果廠商只是實現了JMS規范定義的內容，那么它就必不能支持服務器到服務器之間的可靠傳輸，其功能就會大打折扣。無論是用戶還是中間件廠商，對標準都不應該迷信。
中間件對標準的支持一般會體現在軟件的功能性特征上，多數情況下是可測試和驗證的。

原文轉自：http://www.anti-gravitydesign.com