bea weblogic real time (wlrt)伺服器提供了一種基於java的基礎架構來滿足實時處理需求。這在java領域中是比較少見的：按照實時需求處理請求，而不是只要求j2ee伺服器可運行且可靠即可。使新特性成為可能的關鍵組件是jrockit java virtual machine (jvm)。本文將介紹bea weblogic server與bea jrockit的完美結合，並提供一些實時計算的基礎知識。在文章的末尾，我們將簡要介紹與weblogic real time相關的用例。
關於實時在開始討論weblogic real time之前，我們必須首先思考一下該產品中的兩個單詞的意思：“real”和“time”。關於“實時”（real time），存在著許多種定義，許多文章也描述了不同的概念——第一個java specification request (jsr 1)甚至就是專門針對此主題的。然而，實時的定義並不是一成不變的。沒有人可以給出一個確定的定義，說明到底什麼是實時以及如何確定它，但是似乎大家都認為，如果看到實時，自己就會知道了。為了更好地說明實時的概念，我們將引入幾個常見的定義。根據douglas jenson對實時的討論，存在兩種類型的實時：“軟”實時和“硬”實時。
硬實時：定義了一個系統，其中所有可調度和不可調度的實體的執行都要遵守規定的完成時間約束。其它時間約束（也稱為“上界”）可能也必須滿足。實體的行為和運行時間是可預測的、確定的。 軟實時：表示不屬於硬實時的所有其它實時情況。所有時間約束都是軟性的。基本上，這就意味著所有可調度和不可調度的實體都可能被最佳化以便以最佳狀態執行，但是執行時間不可預測。在一個硬實時系統中，必須遵守時間期限，否則計算結果就會無效。例如，考慮汽車中的嵌入式系統。如果您要加速，而電子加速器的回響延遲了，那么就會得到無法預料的行為。而如果剎車系統延遲了，就會導致可怕的後果。軟實時系統中的定時約束沒這么嚴格，甚至在超出了時間約束之後，計算結果也可能仍然有用。
音頻流就是一個軟實時系統的例子。如果一個數據包延遲或丟失了，音頻的質量會降低，但是流可能依然有效。
為了保證滿足實時系統的定時需求，底層計算系統的行為和計時必須是可預測的。一個可預測的定時系統，其所有操作所需的時間必須是有限制的。這意味著所有操作在最壞情況下的定時是已知的。實時系統通常都是用多個異步執行緒實現的。這是因為他們通常需要回響事件以及控制異步設備。
另一個常見需求是優先權。因為特定事件的緊急程度以及需要處理的事件的數目都不同，因此必須支持優先權的概念，以便確保時間關鍵型的任務不會由於非時間關鍵型的任務而被延遲。讓非關鍵型的任務以與時間關鍵型的任務相同的優先權運行就有可能導致此問題。由於這種優先權倒置，任務需要具有互相通信的能力。因此，實時系統必須提供同步和通信功能。簡而言之，實時系統必須以最小的開銷實現可預測性。
實時計算還有許多其它的理論，比如調度理論，在“參考資料”部分包括有相關的連結。您可能已經猜到了，我們將討論的wlrt是軟實時系統。這種對“硬性”和“軟性”的討論是有價值的，可以幫助理解期望從產品中獲得的特性以及產品所針對的用例。下面是一些在討論weblogic real time相關概念時所使用的其它術語和定義：
實時是一種計算機回響等級，在這種等級下，用戶可感知到足夠快，或者計算機能夠跟得上某個外部流程。 延遲是指系統花在從一個指定點傳輸數據到另一個指定點的時間。 抖動是延遲偏差。一個具有確定性的應用程式抖動應該較低。該術語基本上描述了一種度量確定性的方法。 吞吐量是計算機在給定的時間幀中所能處理的工作量。 確定性垃圾收集是一個執行概念，用於描述快速的、可預測暫停時間的記憶體堆垃圾收集。垃圾收集是從堆中清理廢棄對象以便收回空間用於新對象的過程。 weblogic real timeweblogic real time server (wlrt)為事件驅動的套用提供了一個低延遲的輕量級基礎架構。它旨在用於競爭性較高的環境中，在這種環境中，性能非常關鍵，每一毫秒都很重要。例如，特定的行業（比如電信或保險業）要求事務在給定的時間幀中以極低的延遲執行。然而，如果嘗試用標準的java來實現，則很可能會因為由垃圾收集過程所產生的無法預測的暫停時間而失敗。這就是wlrt的用武之地了。它結合了jrockit jvm，後者引入了一種確定性垃圾收集機制，提供了一個用於執行這些關鍵型套用的j2ee運行時。確定性垃圾收集確保程式執行期間的暫停時間非常短，而且掛起的請求會在定義的時間幀中得到處理——從而允許購建高性能和確定性的應用程式。
架構要了解該新產品，我們需要詳細看一下整個產品組合。wlrt是一個依賴於jrockit jvm中的新特性的weblogic server，它使用集成的bea spring framework支持輕量級編程：
bea weblogic server 9.1是實時應用程式的j2ee服務提供程式。 bea jrockit 5.0 r26為確定性垃圾收集提供了基礎。 bea spring framework 1.2.6是輕量級的編程模型。下面我們將逐一詳細介紹這3個組件。
bea weblogic server 9.1 sp4weblogic server 9.1是bea有著良好口碑的著名企業java套用伺服器的最新版本。除了完全實現了j2ee 1.4規範外，它還提供了一組標準的api，用於創建可以訪問各種服務（比如資料庫、訊息傳遞服務以及其它與外部企業系統的連線）的分散式java應用程式。藉助於weblogic server，企業可以在一個健壯、安全、高度可用且可伸縮的環境中部署任務關鍵型的應用程式。所有這些都可以使用一組集群化、管理和監控特性在給定的基礎架構中實現。作為wlrt的一部分，weblogic server是事件驅動的低延遲應用程式的服務提供程式。
jrockit垃圾收集對java性能有著很大的影響。在full垃圾收集期間，java進程會完全停止。當垃圾收集完成後，進程才會繼續。從堆中清理廢棄對象以及為新對象釋放空間的過程需要進行高度最佳化，以便確保有效的記憶體管理。
jrockit可以使用一種動態的“確定性”垃圾收集優先權(-xgcprio:deterministic)。該策略被最佳化以確保暫停時間非常短，並限制定義良好的時間幀（也稱為“滑動視窗”（sliding window））中的這些暫停的總次數。這對特定的應用程式來說很有用，尤其是對事務延遲有嚴格要求的應用程式。然而，即使較短的確定性暫停時間也不一定能保證較高的應用程式吞吐量。確定性垃圾收集的目標是降低在執行垃圾收集時運行的應用程式的延遲。與常規垃圾收集相比，確定性垃圾收集產生的暫停時間會短得多。通過在jrockit 5.0 r26中引入確定性垃圾收集優先權，可以保證以下的事務延遲：
在99%的情況下，在任何50ms的滑動視窗中，每周由垃圾收集引起的總暫停時間不超過30m。 在任何130ms的滑動視窗中，由垃圾收集引起的總暫停時間不超過100ms。對於具有1 gb堆以及在收集時平均30%或更少的活動數據的應用程式，這些目標很容易實現。wlrt文檔聲明，這已經在以下硬體上得到了驗證：
2 x intel xeon 3.6 ghz，2 mb level 2快取，4 gb ram 4 x intel xeon 2.0 ghz，0.5 mb level 2快取，8 gb ram在具有不同堆大小且/或者有更多活動數據的更慢的硬體上運行可能會破壞這一確定性行為。在這種情況下，可能需要使用-xpausetarget選項增加暫停時間目標。確定性垃圾收集只作為wlrt的一部分可用。如果沒有相應的許可檔案而試圖啟用該功能，則會在伺服器控制台上出現警告。
weblogic spring frameworkwlrt的最後一部分是用於bea weblogic real time的spring framework 1.2.6。作為一個輕量級的應用程式開發框架，它的開發工作比起傳統的j2ee開發有了極大的簡化。實踐證明，它非常靈活、易用，並且能夠運行在具有高度的延遲敏感性的環境中。通過將plain old java object (pojo)用作ejb的替代方案，spring framework仍然能夠訪問weblogic server的所有可靠性特性。此外，它實施了模組化和可重用的編碼實踐。它還包括基於javabean的配置、一個aop框架、聲明式事務管理、jdbc支持和一個web mvc框架。它在weblogic server上得到了認證（從9.0版本開始）。可以從weblogic real time產品下載頁面下載受bea支持的spring版本。關於該框架及其與weblogic server集成的更多信息，請參見spring與weblogic server的集成（中文版，dev2dev，2006年3月）。
將各組件組合起來在了解了組成wlrt的所有單個組件之後，接下來就是要把它們放在一起考慮了。圖1展示了所有組件協同工作的方式。其中，必要的構件塊是具有新增的確定性垃圾收集功能的jrockit jvm。比起其它jvm，它保證了極短的垃圾收集時間。只有在高性能容器的基礎上構建應用程式，才可以獲得這樣的結果。對於wlrt 1.0來說，這是指weblogic server 9。但是在完成時，高性能且可靠的應用程式的關鍵是您自己的代碼。wlrt尊重這一點，它只將spring framework作為一個架構組件進行集成，但並不強制用戶使用它。只不過它是一個構建模組化的、可重用的、高性能的應用程式的良好起點。如果使用它來開發應用程式，就很容易遵循常見的用於最佳化資源訪問和靈敏性環境中的其他關鍵因素的著名模式。
圖1. weblogic real time伺服器架構實時用例
了解了wlrt的所有組件之後，我們需要看一下相關的用例。weblogic real time可以使用回響靈敏的應用程式為高性能環境提供解決方案。即使wlrt並沒有附帶相關的示例套用，我們也很容易想到一些。
向套利交易商提出挑戰的衍生工具交易一家大型零售銀行的投資工具提供了歐洲證券的衍生工具交易。它是一個櫃買中心(over-the-counter，otc)請求報價和執行系統（但是不提供結算和清算服務）。經紀人提交一個報價請求，並包括了證券代碼和數量。系統接受報價並套用特定的業務規則。根據證券代碼和市場形勢，請求被轉發到特定的第三方做市商（market maker），然後做市商會計算並提供該衍生工具的出價和叫價。回響會通過otc交易台返回給經紀人。然後經紀人可以通過一個後續請求執行該衍生工具的交易，該請求會通過otc交易台轉發給相應的做市商。
該場景的複雜性在於，銀行的otc交易基礎架構處理報價請求的短暫等待延遲可能會被套利交易商所利用。在瞬息萬變的證券市場上，在這個延遲發生期間，該衍生工具的價格就可能發生了變化。這為套利交易商提供了一個利用交易所的低效率的空子，並將投資銀行暴露於其無法承受的風險中。因此投資銀行需要一個性能驅動的軟體基礎架構來交付具有極低延遲的otc交易。具體來說，為了抵制套利交易商，交易所基礎架構的延遲必須比套利交易商的基礎架構的延遲短。這樣，套利交易商的數據就在交易所的數據之前失效，因此就不可用了。
網上購物平台：beaybeay為用戶提供了一個銷售商品的系統。除了常規的購物功能外，用戶還可以利用系統的一部分進行商品的競拍。賣家為出價者設定競拍期限（幾周或幾個小時）。到期限結束時出價最高的顧客會被接受。成功的關鍵是要儘可能多地出價，但是不要比前一個最高出價高出太多。越接近競拍期限的尾聲，做出正確的出價就愈發顯得具有時間關鍵性。
假如說有兩個用戶在爭最高出價，並且它們都在最後5秒中提交了一個報價。其中出價較高的那個正好遇上了系統延遲（可能是由於運行了垃圾收集），因此出價較低的那個用戶就會在競拍期限結束後被接受。這樣，購物系統操作員錯過了可能的更高利潤份額，賣家錯過了更高出價，而顧客則失去了對該系統的信任。因此，beay需要一個具有極低延遲的高性能基礎架構，以便確保在適當的時間期限內，所有顧客都擁有使他們的出價被接受的同等機會。
結束語weblogic real time 1.0最近剛剛發布，該產品包應該能夠啟用一些支持實時應用程式的新特性。雖然這首個版本並沒有提供所有的實時概念，但是以後還將出現更多的新特性。下一個wlrt版本（預計會於今年年中發布），將會提供補丁以及進一步最佳化的確定性垃圾收集功能。以後的wlrt版本應該會進一步精化實時服務，比如實時執行緒和調度程式，以及高解析度計時器。還可以期待wlrt會解決一些與事件流處理和分散式快取相關的問題。
wlrt適用於任務關鍵型環境，並支持低延遲和性能關鍵型應用程式的運行。在這個新的企業java領域，它還只是邁出了第一步。雖然並不是人人都需要實時特性，但是它填補了企業java領域中以前阻礙此類應用程式開發的鴻溝。weblogic server、jrockit和spring輕量級套用框架的組合為我們打開了一個令人興奮的開發空間。
參考資料weblogic real time下載頁面 weblogic real time documentation——產品文檔 performance analysis of the weblogic real time 1.0 "trader" application，tom barnes (dev2dev，2006年4月) spring與weblogic server的集成，andy piper等（中文版，dev2dev，2006年3月）——對weblogic spring framework的很好的介紹 jsr 1: real-time specification for java——對實時java的很好的介紹 對douglas jenson所描述的實時概念的很好的介紹