** 於 5 月 2 日更新了案例研究 :- 請參閱本文底部的詳細資訊 ** 我相信閱讀此部落格的大多數人都已經看到了昨天 SpringSource 應用程式平台的公告。如果沒有，請務必查看 Rob 的部落格文章，其中描述了部分動機、程式設計模型和藍圖。

人們提出了一些常見問題，我想在此文章中立即解決。之後，我將描述另外兩個令人興奮的公告，它們補充了 SpringSource 應用程式平台本身，但昨天沒有成為頭條新聞：...

經過數月的熱烈編碼，我很高興地宣布 SpringSource 應用程式平台 1.0 的 Beta 版發布。

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

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

我們著手構建 SpringSource 應用程式平台來解決這些需求並消除這些限制。

該平台的核心是動態模組核心 (DMK)。DMK 是一個基於 OSGi 的核心，它充分利用了 OSGi 平台的模組化和版本控制。 DMK 建立在 Equinox 之上，並擴展其配置和庫管理功能，以及為平台提供核心功能。

為了保持最小的運行時佔用空間，OSGi 綁定由 DMK 配置子系統按需安裝。這允許將應用程式安裝到正在運行的平台中，並從外部儲存庫中滿足其依賴關係。這不僅消除了手動安裝所有應用程式依賴關係的需要，這將是乏味的，而且還使記憶體使用量保持在最低限度。

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

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

在 SpringSource 應用程式平台中，應用程式是模組化的，並且每個模組都有一個 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 只是標準 JAR 文件中組合在一起的 OSGi 綁定（模組）的集合，以及一個名稱和一個唯一標識應用程式的版本。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 語義一致。

平台了解模組的 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…

自 Spring Dynamic Modules 的第一個里程碑以來，開始收到在 OSGi 中運行 Web 應用程式的請求。它可能是最受請求的功能之一，也難怪，一旦 1.0 最終版本發布，Web 支援就成為 1.1 分支的主要焦點。我很高興地報告，隨著剛剛 發布 的 M2，正如 Juergen 已經 暗示 的那樣，Spring-DM 不僅支援 vanilla wars（自 1.1.0 M1 開始可用），還支援在 OSGi 內部運行的 Spring-MVC 應用程式。在這篇文章中，我想簡要討論典型的 OSGi Web 方案和 Spring-DM 的方法。但首先，

為什麼要在 OSGi 中部署 WAR？

為什麼 OSGi 中的 web 應用程式會有問題？

…

昨天，我發表了一篇關於 Spring 如何幫助最大化應用程式可移植性 的文章。即使可移植性問題在企業 Java 領域已經持續多年，這篇文章還是很及時的。今天，甲骨文宣布其以 67 億美元收購 BEA Systems 的交易已經完成。兩家公司的產品組合之間存在大量的重疊，因此這必然會給 WebLogic 和 OC4J 的客戶群帶來不確定性。WebLogic 和 OC4J 都可能屬於 "J2EE 伺服器" 類別，但它們是非常不同的產品，具有非常不同的特性。

由於許多企業…

可移植性是 Spring 世界中的一個關鍵因素。我們相信框架層級的可移植性：應用程式組件是針對特定的框架 (或框架世代) 編寫的，例如 Spring 2.5；然後，框架負責適應任何底層的託管環境。但是，特定的應用程式框架高於且不同於託管環境。只要環境的基本功能足夠，就可以將全新的框架版本部署到已建立的託管平台世代上。這種方法…

昨天我在德國威斯巴登的 JAX 會議 上發表了開幕主題演講。JAX 是歐洲最大的 Java 會議之一，有超過 2,000 名與會者。主題是 *企業 Java 的未來*，我擴展了我的 最近的預測部落格 的主題，更詳細地介紹了 Java EE 6 的影響 以及應用程式伺服器的未來。
我已經 上傳了投影片，其中包括對企業 Java 發展有趣時期的 8 項預測。這是我第一次在同一個簡報中提到約瑟夫·史達林、莫妮卡·萊溫斯基和巨蟒劇團。
…

Spring Security 2.0 已經發布。這是 Spring Portfolio 的一大進步。Spring (Acegi) Security 已經是 Java 平台上使用最廣泛的企業安全框架，在 SourceForge 上有超過 250,000 次下載，每次發布有超過 20,000 次下載。通過使其更易於使用，此版本無疑將採用提升到一個新的水平。

我特別為這個版本感到高興，原因有很多：

• 這對 Spring 社群來說是一件很棒的事情。它（更容易）使用，而且功能更強大。它將最強大的企業 Java 安全解決方案置於更多用戶的觸手可及之處，幾乎消除了採用的障礙。請參閱此 教學，以了解它使保護典型 web 應用程式變得多麼容易。XML bean 定義的激增已成為過去。
• 它是 Spring 2.x 工作的延續，通過應用自定義 XML 命名空間的力量來實現積極的預設設置，同時仍然允許自定義。
• 與 Spring 2.5 一樣，它展示了當前 Spring Portfolio 朝著大幅減少對 XML 需求趨勢發展。
• 這是 SpringSource 商業模式價值的證明。我們的收入模式使我們能夠比以往任何時候都更多地投資於創建開放原始碼軟體。如果沒有能夠同時聘請 Acegi/Spring Security 創始人 Ben Alex 和另一位主要提交者 Luke Taylor，這個版本要么不會發生，要么就不會如此廣泛。
• 這對 仙子王國來說是一件好事。

Acegi/Spring Security 創始人 Ben Alex 和 Luke Taylor 做得很棒。Ben 將在下個月的 Java One 上談論 Spring Security。如果…

Spring Security 2.0.0 現在可用。

下載 | 變更日誌 | 公告 | 網站

經過近兩年的開發，Spring Security 2.0.0 現在可以下載了。這個重要的新版本取代了 Acegi Security，成為 Spring 應用程式的官方安全模組。它提供了大幅簡化的配置，以及無數其他新功能，包括 OpenID、NTLM、JSR 250 註解、AspectJ 切入點支持、網域 ACL 增強、RESTful URI 授權、群組、層級角色、使用者管理 API、資料庫支援的 "記住我"、portlet 驗證、其他語言、Web Flow 2.0 支持、Spring IDE 可視化和自動完成、通過 Spring Web Services 1.5 增強的 WSS 支持等等。

親愛的 Spring 社群：

我們很高興地宣布 Spring Web Flow 2.0.0.RC1 現在可用。下載 | 文件

2.0.0.RC1 引入了幾個新功能，並修復了先前里程碑版本中報告的所有已知問題。

我們建議從先前的 Web Flow 2 里程碑版本 升級 到 2.0.0.RC1。我們也建議 Web Flow 1 的使用者開始評估他們升級到 Web Flow 2 的時間，因為 RC1 引入了全面的版本 2 文件，以及一個用於自動將版本 1 的流程轉換為版本 2 語法的工具。

開始使用 Web Flow 2 的最佳方法是評估發行版中包含的 參考應用程式，並輔以 參考指南。 Spring Web Flow 2 需要 Spring Framework 2.5.3 和 Java 1.4 或更高版本。

在下面的 2.0.0 RC1 版本中查找新的和值得注意的功能：

2.0.0.RC1 新功能和值得注意的功能

• 引入了 Web Flow 2 參考指南，提供 PDF 和 HTML 格式。新指南以 "快速參考" 樣式編寫，並提供可運行的程式碼範例。在 線上 閱讀它，或下載可列印的 PDF。

• 增加了從 Web Flow 1 升級到 2 的支持。此發行版中包含一個 *WebFlowUpgrader* 工具，能夠將流程從版本 1 語法轉換為版本 2 語法。有關如何使用此工具的說明，請參閱參考指南。

• 增加了對流程定義繼承的支持。使用此功能，流程可以擴展一個或多個流程。流程狀態也可以擴展另一個狀態。此功能用於促進共享通用結構的流程和狀態之間的重用。

• 引入了 Spring Portlet MVC 支持。有關範例，請參閱參考指南的 Portlet 部分以及 booking-mvc-portlet 和 booking-faces-portlet 範例應用程式。

• 正式引入了新的 "Spring Javascript" 模組，包含在 spring-js-2.0.0.RC1.jar 中。此模組提供了一個 Javascript 抽象框架，用於以一致的方式應用客戶端行為，例如表單驗證和 Ajax。它還捆綁了一個 ResourceServlet，用於從 jar 提供 Javascript 和 CSS（也包含一個 CSS 框架）。此框架構建的預設 UI 工具包是 Dojo 1。Spring 的 JSF 整合模組稱為 "Spring Faces"，它建立在 spring-js 之上，以提供一個輕量級的 JSF 組件庫，用於表單驗證和 Ajax。

• 增加了 Spring Faces 與 RichFaces JSF 組件庫的整合。Rich Faces 可以與 Spring Faces 組件庫一起使用，也可以單獨使用。我們的 JIRA 系統 中提供了一個說明此整合的範例應用程式。

• 增加了一個 "jsf-booking" 參考應用程式，該應用程式提供了傳統 JSF web 應用程式和使用 JSF 作為 UI 組件模型的 Spring web 應用程式之間的比較。將 jsf-booking 與 booking-faces 進行比較，以查看架構方法和實作方面的差異。這種比較對於有興趣了解更多關於 Spring 的 JSF 開發人員尤其重要。

• 引入了 Spring MVC 中對自動模型綁定和驗證的支持。這種支持提供了一種簡潔的替代方案，可以替代手動 FormAction setupForm 和 bindAndValidate 呼叫。這種支持還允許在整個應用程式中註冊資料輸入格式化器，從而減少了在許多情況下於逐個視窗註冊 PropertyEditors 的需要。提供對於取消按鈕點擊等事件抑制資料綁定的支持。提供通過慣例調用驗證器的支持。有關範例，請參閱 booking-mvc 範例。

• 引入了視窗範圍。視窗範圍在視窗狀態進入時分配，並在視窗狀態退出時銷毀。該範圍對於通過一系列 Ajax 請求更新特定於一個視窗的模型非常有用。它也是用於管理 JSF 組件狀態的範圍。

• 增加了對流程訊息捆綁包的支持。在流程的工作目錄中創建一個 messages.properties 檔案，用於您需要支持的語言環境，然後就可以開始使用了。

• 引入了可配置的視窗狀態歷史記錄策略。視窗狀態可以保留其歷史記錄以支持回溯，丟棄其歷史記錄以防止回溯，並使所有先前的歷史記錄無效，以禁止在不可逆轉的點之後回溯。請參閱視窗狀態元素上的新 'history' 屬性。

• 改良了流程執行快照程序。 這些改進捕捉了回傳時的檢視狀態表單值，以支援在回溯時還原這些值。 這在使用瀏覽器返回按鈕返回流程範圍中儲存的資料時，保留了編輯。

• 簡化了流程執行測試，允許您跳轉到任何狀態以開始測試案例。 請參閱 booking-mvc 和 booking-faces 以取得流程測試案例的範例。
  

• 改進了 booking-mvc 作為參考應用程式，展示了 @Controllers 與 Flows 的結合使用。 一個新的 FlowHandler 概念在 Controllers 和 Flows 之間提供了一個清晰的橋樑，允許兩種處理程序以結構化的方式進行交互。 此外，還改進了參考應用程式 Spring 配置的組織方式，以說明最佳實踐。