經過數月熱火朝天的編碼，我很高興宣佈 SpringSource Application Platform 1.0 的 Beta 版釋出。

2007 年初，我們開始討論企業 Java 已變得與單體和重量級應用伺服器同義的替代方案。客戶正在尋找一個輕量級、模組化且足夠靈活以滿足其開發和部署需求的平臺。

Spring 和 Tomcat 的搭配表明開發者和運維人員可以成功地在生產環境中使用輕量級平臺。儘管這種組合取得了成功，但缺乏模組化以及對非 Web 應用的明確支援限制了其適用性和靈活性。

我們著手構建 SpringSource Application Platform 來滿足這些需求並消除這些限制。

平臺的核心是動態模組核心（DMK）。DMK 是一個基於 OSGi 的核心，充分利用了 OSGi 平臺的模組化和版本化特性。DMK 構建於 Equinox 之上，擴充套件了其在配置和庫管理方面的能力，併為平臺提供了核心功能。

為了保持最小的執行時佔用空間，OSGi 捆綁包由 DMK 配置子系統按需安裝。這使得應用可以安裝到正在執行的平臺中，並且其依賴項可以從外部倉庫中滿足。這不僅消除了手動安裝所有應用依賴項的繁瑣需求，還能將記憶體使用量保持在最低水平。

DMK 本身只需要最少的捆綁包即可執行，並透過一個 profile 進行配置，精確控制載入哪些額外的模組。例如，DMK 不需要存在 Tomcat，但預設的平臺 profile 包含了 Tomcat，以便部署 Web 應用。如果您想在沒有 Tomcat 的情況下執行平臺，只需編輯 profile，它就不會被安裝。（如果您嘗試此操作 - 請記住，移除 Web 支援意味著 Web 模組將無法部署，因此請刪除 pickup 目錄的內容，以便平臺在啟動時不會嘗試安裝 Admin 和 splash screen 應用。）安裝了管理控制檯的預設平臺配置僅佔用 15MB 記憶體。

我對企業 Java 一直感到沮喪的一點是，應用通常被硬塞進生硬的筒倉中，並且缺乏對不同應用型別的明確支援。考慮一個線上商店的應用。這個應用有一個 Web 前端、一個訊息驅動的訂單處理模組、一個批處理驅動的庫存重新排序模組和一個 B2B Web 服務模組。如今，許多這樣的應用會打包成 WAR 或 EAR，並且模組看起來非常相似，很少支援模組型別之間的差異。有趣的是，許多人會稱之為 Web 應用，而不是帶有 Web 模組的應用。

在 SpringSource Application Platform 中，應用是模組化的，每個模組都有一個描述其型別的 personality：web、批處理、web 服務等。平臺以特定於 personality 的方式部署每種 personality 的模組。例如，Web 模組在 Tomcat 中配置有 Web 上下文。應用中的每個模組都可以獨立於其他模組進行更新，同時保持其作為更大應用一部分的身份。無論您構建的是何種型別的應用，程式設計模型都保持標準的 Spring 和 Spring DM。

在 1.0 平臺版本中，我們支援 web 和 bundle personality，這使您能夠構建複雜的 Web 應用。未來的版本將包含更多 personality 的支援，詳情將在後面介紹。

構建應用

平臺支援以下三種形式打包的應用

1. Java EE WAR
2. 原始 OSGi 捆綁包
3. 平臺檔案 (PAR)

平臺直接支援標準 WAR 檔案。在部署時，WAR 檔案會被轉換為 OSGi 捆綁包並安裝到 Tomcat 中。所有標準的 WAR 契約都會得到遵循，您現有的 WAR 檔案應該可以直接放入並部署而無需更改。

任何符合 OSGi 規範的捆綁包都可以直接部署到平臺中，並且可以充分利用針對 Import-Package 和 Require-Bundle 引用的任何依賴項的即時配置功能。

PAR 格式是打包和部署平臺應用的推薦方法。PAR 只是將一組 OSGi 捆綁包（模組）組合在一個標準的 JAR 檔案中，並帶有一個唯一標識應用的名稱和版本。PAR 檔案作為一個單獨的單元部署到平臺中。平臺將從 PAR 中提取所有模組並安裝它們。第三方依賴項將根據需要即時安裝。

與直接將捆綁包部署到平臺中相比，PAR 格式有三個主要優點。首先，它更容易。一箇中等規模的企業應用可能包含 12 個或更多的捆綁包——手動部署這些捆綁包會非常麻煩。其次，PAR 檔案在應用中的所有捆綁包周圍形成了一個明確的作用域，這可以防止使用重疊型別或服務的應用相互衝突。此作用域也被一些高階功能（例如載入時織入）使用，以確保一個應用的織入不會干擾另一個應用的織入。最後，PAR 形成一個邏輯分組，用於定義哪些模組是一個應用的一部分以及該應用有哪些第三方依賴項。此分組被管理工具用於提供應用的詳細檢視。一個典型的 PAR 應用如下所示

應用中模組之間的依賴關係通常使用 Import-Package 和 Export-Package 來表達。對第三方庫的依賴也可以用同樣的方式表達，但對於許多庫來說，這可能會容易出錯且耗時。當使用像 Hibernate 這樣的庫時，您通常需要匯入比您最初預期的更多的包。為了解決這個問題，您可以使用 Require-Bundle，但這有一些語義上的缺陷，例如 split packages，其中一個邏輯包被分割到兩個或更多的類載入器中，導致執行時出現問題。平臺引入了兩種新的機制來引用第三方依賴項：Import-Bundle 和 Import-Libary。Import-Bundle 類似於 Require-Bundle，但它防止了 split packages 和 Require-Bundle 的其他問題。Import-Library 提供了一種機制，可以透過單個宣告引用一組捆綁包匯出的所有包，例如 Spring Framework 中的所有捆綁包

Bundle-SymbolicName: com.myapp.dao.jdbc
Bundle-Version: 1.0.0
Import-Bundle: org.apache.commons.dbcp;version="1.2.2.osgi"
Import-Library: org.springframework.spring;version="2.5.4.A"

在這裡，我有一個模組捆綁包，它依賴於 Commons DBCP 捆綁包和 Spring Framework 庫。Spring Framework 庫包含了在您的應用中使用 Spring 所需的所有捆綁包。

Import-Library 和 Import-Bundle 在底層會展開為 Import-Package，因此與標準的 OSGi 語義一致。

平臺理解模組的 personality，並由此可以推斷如何配置模組的執行環境。部署 Web 模組時，典型 Spring MVC 應用所需的所有 Servlet 基礎設施都會自動建立，消除了在不同應用中重新建立這些樣板程式碼的需要。在 1.0 最終版本中，將為 Web 模組 personality 新增更多智慧功能，以支援 Spring Web Flow 等其他技術。

無論您選擇哪種打包格式，程式設計模型都只是 Spring Framework 和 Spring Dynamic Modules，其他 Spring Portfolio 產品在其上執行。

可維護性

可維護性是整個工程團隊的關鍵考慮因素。我們花費了大量時間關注日誌訊息的格式和堆疊跟蹤的大小，以確保診斷應用問題儘可能容易。每當我們發現一項重複且耗時的任務時，我們都會尋找自動化它或完全取消它的方法。

為了幫助問題診斷，平臺在日誌訊息和跟蹤訊息之間進行了嚴格區分。日誌訊息供終端使用者查閱，讓您可以快速獲取最重要的故障資訊，而無需翻閱數 GB 的跟蹤內容。所有應用故障都會在日誌輸出中顯示並編碼——這些程式碼是訪問知識庫或支援內容的便捷方式。要理解為什麼這如此有用，請考慮以下平臺啟動輸出

[2008-04-29 12:12:01.124] main                     <SPKB0001I> Platform starting.
[2008-04-29 12:12:04.037] main                     <SPKE0000I> Boot subsystems installed.
[2008-04-29 12:12:06.013] main                     <SPKE0001I> Base subsystems installed.
[2008-04-29 12:12:07.396] platform-dm-1            <SPPM0000I> Installing profile 'web'.
[2008-04-29 12:12:07.674] platform-dm-1            <SPPM0001I> Installed profile 'web'.
[2008-04-29 12:12:07.721] platform-dm-14           <SPSC0000I> Creating ServletContainer on port 8080
[2008-04-29 12:12:08.036] platform-dm-10           <SPPM0002I> Platform open for business with profile 'web'.
[2008-04-29 12:12:09.405] fs-watcher               <SPSC1000I> Creating web application '/admin'
[2008-04-29 12:12:09.652] async-delivery-thread-1  <SPSC1001I> Deploying web application '/admin'

那些詳細描述啟動呼叫鏈中每個型別內部工作機制的長篇大論輸出不見了。取而代之的是，您會收到真正有意義的訊息。當然，這並不意味著您無法瞭解每個型別正在做什麼：我們仍然保留了詳細的跟蹤資訊。實際上，因為我們將最重要的日誌訊息從跟蹤中分離出來，我們的跟蹤資訊可以更詳細，因為它們的目的不是被頻繁閱讀。

平臺中的嚴重故障會生成一個服務轉儲，可以傳遞給支援人員，以幫助診斷過程。此轉儲包含平臺中所有主要子系統的狀態，並透過 AspectJ 介入，以確保我們捕獲到可能丟擲未經檢查異常的每個位置。

平臺還會主動監控 JVM 中的問題並觸發轉儲。在 1.0 版本中，這僅限於死鎖監控，但在未來版本中將包括記憶體、鎖競爭和 CPU 競爭。

路線圖

這個 Beta 版本僅僅是 SpringSource Application Platform 的開始。我們初步定義了 2.0 版本的路線圖，重點關注五個主要領域：管理控制檯、中介軟體整合、額外的 personality、叢集和 DMK 2.0。

透過管理控制檯，我們希望利用平臺所擁有的所有應用知識，並將其提供給終端使用者。管理控制檯將允許從模組級別開始，一直深入到 Bean 級別，對應用進行詳細檢查。應用將與其依賴的庫和捆綁包關聯，管理控制檯將提供動態升級這些庫的能力。透過理解應用包含的不同型別的 Bean，管理控制檯將提供對應用內部的詳細洞察，並允許對某些應用元件進行動態重新配置。

為了支援典型的企業部署場景，平臺 2.0 版本將提供對常見企業中介軟體元件的明確支援，例如 Oracle、TIBCO EMS 和 IBM MQSeries。與管理控制檯的整合將允許在幾分鐘而不是幾小時或幾天內建立與這些中介軟體提供者的連線。應用將能夠使用 OSGi 服務登錄檔和 Spring DM 的 <osgi:reference> 來訪問這些連線。

2.0 版本將引入額外的 personality，以涵蓋批處理、Web 服務和 SOA 應用。

叢集是 2.0 版本的重要功能，其中叢集範圍內的單一系統映像 (SSI) 是關鍵部分，負載均衡和叢集快取也在路線圖上。透過 SSI 支援，管理和部署操作將在整個叢集中傳播。最終，我們希望支援在整個叢集中進行按模組更新，如果升級破壞了已部署的應用，則可以進行完全的叢集回滾。

DMK 2.0 將包括併發子系統的改進，以支援大量頻繁更改的捆綁包，並支援具有更復雜相互依賴關係的大量模組。此外還將包括配置子系統的更新以及對記憶體、執行緒、IO 和 CPU 的整合資源管理和監控。

接下來做什麼？

請下載平臺並試用。我們非常渴望瞭解您構建新應用和部署現有應用的經驗。歡迎所有反饋，無論是積極的還是消極的。我們尤其感興趣的是如何使構建和部署應用的過程更輕鬆、更愉快。

二進位制版本和論壇可以在這裡找到。使用者指南 (user's guide) 和程式設計師指南 (programmer's guide) 都可以線上獲取。我們在這裡設定了一個 JIRA 例項。