基本介紹
- 外文名：WebLogic Real Time
- 簡稱：WLRT
- 基於：Java的基礎架構
- 旨在：用於競爭性較高的環境中
簡介,產品組合,用例,
簡介
WebLogic Real Time server (WLRT)為事件驅動的套用提供了一個低延遲的輕量級基礎架構。它旨在用於競爭性較高的環境中，在這種環境中，性能非常關鍵，每一毫秒都很重要。例如，特定的行業（比如電信或保險業）要求事務在給定的時間幀中以極低的延遲執行。然而，如果嘗試用標準的Java來實現，則很可能會因為由垃圾收集過程所產生的無法預測的暫停時間而失敗。這就是WLRT的用武之地了。它結合了JRockitJVM，後者引入了一種確定性垃圾收集機制，提供了一個用於執行這些關鍵型套用的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是輕量級的編程模型。
BEA WebLogic Server 9.1 SP4
WebLogic Server 9.1是BEA有著良好口碑的著名企業Java套用伺服器的最新版本。除了完全實現了J2EE 1.4規範外，它還提供了一組標準的API，用於創建可以訪問各種服務（比如資料庫、訊息傳遞服務以及其它與外部企業系統的連線）的分散式Java應用程式。藉助於WebLogic Server，企業可以在一個健壯、安全、高度可用且可伸縮的環境中部署任務關鍵型的應用程式。所有這些都可以使用一組集群化、管理和監控特性在給定的基礎架構中實現。作為WLRT的一部分，WebLogic Server是事件驅動的低延遲應用程式的服務提供程式。
JRockit
垃圾收集對Java性能有著很大的影響。在full垃圾收集期間，Java進程會完全停止。當垃圾收集完成後，進程才會繼續。從堆中清理廢棄對象以及為新對象釋放空間的過程需要進行高度最佳化，以便確保有效的記憶體管理。
在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 Framework
WLRT的最後一部分是用於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作為一個架構組件進行集成，但並不強制用戶使用它。只不過它是一個構建模組化的、可重用的、高性能的應用程式的良好起點。如果使用它來開發應用程式，就很容易遵循常見的用於最佳化資源訪問和靈敏性環境中的其他關鍵因素的著名模式。
用例
了解了WLRT的所有組件之後，我們需要看一下相關的用例。WebLogic Real Time可以使用回響靈敏的應用程式為高性能環境提供解決方案。即使WLRT並沒有附帶相關的示例套用，我們也很容易想到一些。
向套利交易商提出挑戰的衍生工具交易
一家大型零售銀行的投資工具提供了歐洲證券的衍生工具交易。它是一個櫃買中心(over-the-counter，OTC)請求報價和執行系統（但是不提供結算和清算服務）。經紀人提交一個報價請求，並包括了證券代碼和數量。系統接受報價並套用特定的業務規則。根據證券代碼和市場形勢，請求被轉發到特定的第三方做市商（market maker），然後做市商會計算並提供該衍生工具的出價和叫價。回響會通過OTC交易台返回給經紀人。然後經紀人可以通過一個後續請求執行該衍生工具的交易，該請求會通過OTC交易台轉發給相應的做市商。
該場景的複雜性在於，銀行的OTC交易基礎架構處理報價請求的短暫等待延遲可能會被套利交易商所利用。在瞬息萬變的證券市場上，在這個延遲發生期間，該衍生工具的價格就可能發生了變化。這為套利交易商提供了一個利用交易所的低效率的空子，並將投資銀行暴露於其無法承受的風險中。因此投資銀行需要一個性能驅動的軟體基礎架構來交付具有極低延遲的OTC交易。具體來說，為了抵制套利交易商，交易所基礎架構的延遲必須比套利交易商的基礎架構的延遲短。這樣，套利交易商的數據就在交易所的數據之前失效，因此就不可用了。
