經過幾個月熱烈的程式碼編寫，我很榮幸地宣布 SpringSource 應用程式平台 1.0 的 beta 版本發布。

在 2007 年初，我們開始討論企業 Java 日益同義的單體式且笨重的應用程式伺服器的可能替代方案。客戶正在尋找一個輕量、模組化且足夠靈活的平台，以滿足他們的開發和部署需求。

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

我們開始建構 SpringSource 應用程式平台，以解決這些需求並消除這些限制。

該平台的核心是動態模組核心 (DMK)。 DMK 是一個基於 OSGi 的核心，它充分利用了 OSGi 平台的模組化和版本控制。 DMK 建構於 Equinox 之上，並擴展了其在佈建和函式庫管理方面的能力，同時為平台提供了核心功能。

為了保持最小的執行時佔用空間，OSGi 套件由 DMK 佈建子系統按需安裝。 這允許將應用程式安裝到正在運行的平台中，並從外部儲存庫滿足其依賴性。 這不僅消除了手動安裝所有應用程式依賴項的需要（這將是繁瑣的），而且還將記憶體使用量保持在最低限度。

DMK 本身只需要一組最少的套件即可運行，並且配置了配置檔以精確控制加載的其他模組集。 例如，DMK 不需要存在 Tomcat，但預設的平台配置檔包括 Tomcat 以允許部署網路應用程式。 如果您想在沒有 Tomcat 的情況下運行平台，您可以簡單地編輯配置檔，它將不會被安裝。（如果您嘗試這樣做 - 請記住，刪除網路支援意味著網路模組將不再部署，因此請刪除拾取目錄的內容，以便平台在啟動時不會嘗試安裝管理和啟動畫面應用程式。）預設的已安裝管理控制台的平台配置僅佔用 15MB 的記憶體。

我一直以來對企業 Java 的一個挫折感是，應用程式通常被硬塞進人為的孤島中，並且缺乏對不同應用程式類型的明確支援。 考慮一個線上商店的應用程式。 該應用程式具有網路前端、訊息驅動的訂單處理模組、批次驅動的庫存重新排序模組和 B2B 網路服務模組。 如今，許多這樣的應用程式將被打包為 WAR 或 EAR，並且這些模組看起來非常相似，對模組類型之間的差異幾乎沒有支援。 有趣的是，許多人會將此稱為網路應用程式，而不是具有網路模組的應用程式。

在 SpringSource 應用程式平台中，應用程式是模組化的，並且每個模組都有一個人格，描述了它是什麼類型的模組：網路、批次、網路服務等。該平台以特定於人格的方式部署每個人格的模組。 例如，網路模組在 Tomcat 中配置有網路上下文。 應用程式中的每個模組都可以獨立於其他模組進行更新，同時保持作為較大應用程式的一部分的身份。 無論您正在構建何種類型的應用程式，編程模型仍然是標準的 Spring 和 Spring DM。

在 1.0 平台版本中，我們支援 網路和套件人格，使您可以建構複雜的網路應用程式。 未來的版本將包括對更多人格的支援，詳情將在稍後介紹。

建構應用程式

該平台支援以三種形式打包的應用程式

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，但它有一些語義上的粗糙邊緣，例如拆分套件，其中一個邏輯套件被拆分到兩個或多個類別加載器中，導致運行時出現問題。 該平台引入了兩種新的機制來引用第三方依賴項：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 套件和 Spring Framework 函式庫。 Spring Framework 函式庫包含在您的應用程式中使用 Spring 所需的所有套件。

Import-Library 和 Import-Bundle 在幕後擴展為 Import-Package，因此與標準 OSGi 語義一致。

該平台了解模組的人格，並可以從中推斷出如何配置模組的執行環境。 部署網路模組時，會自動建立典型 Spring MVC 應用程式所需的所有 servlet 基礎架構，從而無需跨應用程式重新建立此樣板代碼。 在 1.0 最終版本中，將向網路模組人格添加更多智慧功能，以支援其他技術，例如 Spring Web Flow。

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

可用性

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

為了幫助診斷問題，平台在日誌訊息和追蹤訊息之間有很強的分隔。 日誌訊息旨在供最終使用者使用，並允許您訪問最重要的故障資訊，而無需遍歷千兆位元組的追蹤內容。 所有應用程式故障都會在日誌輸出中顯示和編碼 - 這些代碼是訪問知識庫或支援內容的便捷方式。 為了了解這有多有用，請考慮以下來自平台啟動的輸出

[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 應用程式平台的開始。 我們已經暫時定義了一個路線圖，涵蓋 2.0 版本，重點關注五個主要領域：管理控制台、中介軟體整合、其他人格、集群和 DMK 2.0。

我們希望透過管理主控台(Admin Console)運用平台所具備的所有應用程式知識，並將其提供給終端使用者。管理主控台將允許從模組層級開始，一直到 Bean 層級，對應用程式進行詳細的檢查。應用程式將會連結到它們所依賴的程式庫和套件(bundle)，而管理主控台將提供動態升級這些程式庫的能力。透過了解應用程式包含的不同 Bean 類型，管理主控台將能夠提供對應用程式內部運作的深入了解，並允許對某些應用程式組件進行動態重新配置。

為了支援典型的企業部署情境，2.0 版本的平台將會明確支援常見的企業中介軟體元件，例如 Oracle、TIBCO EMS 和 IBM MQSeries。與管理主控台整合後，連接到這些中介軟體供應商所需的時間將從數小時或數天縮短到數分鐘。應用程式將能夠使用 OSGi 服務註冊表和 Spring DM 的 <osgi:reference>來存取這些連接。

2.0 版本將引入額外的特性(personalities)，以涵蓋批次處理、網路服務和 SOA 應用程式。

叢集(Clustering)是 2.0 版本的一項重要功能，其中叢集範圍的單一系統映像(Single System Image, SSI) 是關鍵要素，而負載平衡和叢集快取也在規劃藍圖中。透過使用 SSI 支援，管理和部署操作將會在整個叢集中傳播。最終，我們希望支援跨叢集的每個模組更新，如果升級導致已部署的應用程式發生錯誤，則可以完全回滾整個叢集。

DMK 2.0 將改進並行子系統(concurrency subsystem)，以支援大量頻繁變更的套件(bundle)，並支援具有更複雜相互依賴關係的更多模組。同時也將包含對佈建子系統的更新，以及針對記憶體、線程、IO 和 CPU 的整合資源管理和監控。

接下來呢？

請下載平台並試用看看。我們很想了解您建置新應用程式和部署現有應用程式的經驗。我們歡迎所有回饋意見，無論是正面的還是負面的。我們特別有興趣了解我們如何讓建置和部署應用程式的過程變得更輕鬆、更愉快。

二進位版本和論壇可以在這裡找到。 使用者指南和程式設計師指南都可以在線上取得。我們已經建立了 JIRA 實例，可以在這裡存取。