經過數月緊張的編碼，我很高興地宣佈 SpringSource Application Platform 1.0 的 beta 版本釋出。

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

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

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

Platform 的核心是 Dynamic Module Kernel (DMK)。DMK 是一個基於 OSGi 的核心，充分利用了 OSGi 平臺的模組化和版本控制功能。DMK 基於 Equinox 並擴充套件了其在配置和庫管理方面的功能，同時為 Platform 提供了核心功能。

為了保持最小的執行時佔用空間，OSGi bundle 由 DMK 配置子系統按需安裝。這使得應用程式可以安裝到執行中的 Platform 中，並且其依賴項可以從外部儲存庫中滿足。這不僅消除了手動安裝所有應用程式依賴項的繁瑣工作，而且最大限度地減少了記憶體使用。

DMK 本身需要一套最小的 bundle 來執行，並透過一個 **profile** 進行配置，以精確控制載入的附加模組集。例如，DMK 不需要 Tomcat，但預設的 Platform profile 包含 Tomcat 以允許部署 Web 應用程式。如果您想在沒有 Tomcat 的情況下執行 Platform，只需編輯 profile 即可，它就不會被安裝。（如果您嘗試這樣做，請記住，刪除 Web 支援意味著 Web 模組將不再部署，因此請刪除 pickup 目錄中的內容，以免 Platform 在啟動時嘗試安裝 Admin 和 splash 螢幕應用程式。）預設的 Platform 配置（安裝了管理控制檯）僅佔用 15MB 記憶體。

我對企業 Java 的一個長期不滿是，應用程式經常被塞進牽強的孤島，並且缺乏對不同應用程式型別的顯式支援。考慮一個線上商店的應用程式。該應用程式有一個 Web 前端、一個訊息驅動的訂單處理模組、一個批處理驅動的庫存重新排序模組和一個 B2B Web 服務模組。如今，許多此類應用程式將被打包成 WAR 或 EAR，並且模組將非常相似，對模組型別差異的支援很少。有趣的是，許多人會將此稱為 Web 應用程式，而不是帶有 Web 模組的應用程式。

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

在 1.0 Platform 版本中，我們支援 **web** 和 **bundle** personality，這使您能夠構建複雜的 Web 應用程式。未來的版本將根據後續詳述包含對更多 personality 的支援。

構建應用程式

Platform 支援三種形式的應用程式打包

1. Java EE WAR
2. 原始 OSGi bundle
3. 平臺歸檔 (PAR)

Platform 直接支援標準的 WAR 檔案。在部署時，WAR 檔案將被轉換為 OSGi bundle 並安裝到 Tomcat 中。所有標準的 WAR 合約都得到遵守，您現有的 WAR 檔案應該可以直接部署而無需更改。

任何符合 OSGi 標準的 bundle 都可以直接部署到 Platform 中，並可以充分利用對 `Import-Package` 和 `Require-Bundle` 所引用的任何依賴項進行的即時配置。

PAR 格式是為 Platform 打包和部署應用程式的推薦方法。PAR 只是一個 OSGi bundle（模組）的集合，這些 bundle 被分組到一個標準的 JAR 檔案中，並帶有一個唯一標識應用程式的名稱和版本。PAR 檔案作為單個單元部署到 Platform。Platform 將提取 PAR 中的所有模組並進行安裝。第三方依賴項將根據需要即時安裝。

與直接將 bundle 部署到 Platform 相比，PAR 格式有三個主要優勢。首先，它更簡單。一箇中等規模的企業應用程式可能包含 12 個以上的 bundle - 手動部署這些 bundle 將非常繁瑣。其次，PAR 檔案為應用程式中的所有 bundle 形成了一個顯式的範圍，防止使用重疊型別或服務的應用程式之間發生衝突。此範圍還用於一些高階功能，例如載入時織入，以確保一個應用程式的織入不會干擾另一個應用程式的織入。最後，PAR 形成了一個邏輯分組，用於定義哪些模組是應用程式的一部分以及應用程式有哪些第三方依賴項。此分組由管理工具用於提供應用程式的詳細檢視。典型的 PAR 應用程式如下所示：

應用程式中模組之間的依賴關係通常使用 Import-Package 和 Export-Package 來表示。對第三方庫的依賴關係也可以用同樣的方式來表達，但對於許多庫來說，這可能既容易出錯又耗時。在使用 Hibernate 等庫時，您通常需要匯入比最初預期的更多的包。為了解決這個問題，您可以使用 Require-Bundle，但它存在一些語義上的不足之處，例如拆分包，即一個邏輯包被拆分到兩個或多個類載入器中，這會在執行時導致問題。該平臺引入了兩種新的機制來引用第三方依賴項：Import-Bundle 和 Import-Libary。 Import-Bundle 類似於 Require-Bundle，但它能避免拆分包以及 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 bundle 和 Spring Framework 庫的模組 bundle。Spring Framework 庫包含使用 Spring 在應用程式中所需的所有 bundle。

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

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

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

可服務性

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

為了幫助診斷問題，Platform 在日誌和跟蹤訊息之間進行了嚴格的劃分。日誌訊息旨在供終端使用者使用，讓您無需篩選大量跟蹤內容即可獲取最重要的失敗資訊。所有應用程式故障都會顯示並編碼在日誌輸出中 - 程式碼可方便地用於訪問知識庫或支援內容。為了理解這一點為何如此有用，請考慮以下 Platform 啟動輸出：

[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'

用於詳細說明啟動呼叫鏈中每個型別內部工作原理的冗長輸出頁面已成為過去。取而代之的是，您將收到真正有意義的訊息。當然，這並不意味著您無法瞭解每個型別的作用：我們仍然維護著一個詳盡的跟蹤。事實上，由於我們將最重要的日誌訊息從跟蹤中分離出來，我們的跟蹤可以更詳細，因為它intended to be read less often（閱讀頻率較低）。

平臺中的嚴重故障會生成一個服務轉儲，可以將其提供給支援人員以協助診斷過程。此轉儲包含平臺中所有主要子系統aneous的狀態，並透過 AspectJ 進行鉤接，以確保我們捕獲到可以引發未檢查異常的每一個可能的站點。

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

路線圖

此 Beta 版僅是 SpringSource Application Platform 的起點。我們已初步確定了 2.0 版本的路線圖，重點關注五個主要領域：管理控制檯、中介軟體整合、附加功能、叢集和 DMK 2.0。

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

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

2.0 版本將引入額外的功能來覆蓋批處理、Web 服務和 SOA 應用程式。

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

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

下一步是什麼？

請下載該平臺並試用。我們非常希望聽到您在構建新應用程式和部署現有應用程式方面的經驗。歡迎所有反饋，無論積極還是消極。我們特別希望聽聽如何讓構建和部署應用程式的過程變得更輕鬆、更愉快。

二進位制版本和論壇可以在此處找到。使用者指南和程式設計師指南都可以線上獲取。我們已在此處設定了 JIRA 例項。