dm Server 使用者經常詢問我們在未來幾個版本中的計劃。在這篇博文中，我將概述我們路線圖上的主要功能。我們遵循 Scrum 實踐，因此您可以期待我們的衝刺產生相對頻繁的里程碑版本，並且我們在處理新需求和優先順序變化方面非常靈活。

共享倉庫

共享倉庫允許您擁有一個集中位置來管理可安裝到 dm Server 例項中的製品。然後，這些共享倉庫可以新增到 dm Server 配置中的倉庫鏈的任何位置。

共享倉庫就是一個 dm Server 節點，它管理一個檔案系統倉庫並將其提供給其他節點使用。這些託管倉庫的節點稱為 dm 倉庫節點。共享倉庫的數量及其順序不是固定的 - 您可以自由選擇適合您環境的任何倉庫結構。

客戶端 dm Server 節點使用 REST API 與倉庫節點通訊。此 REST API 將會被文件化並提供，以便第三方工具能夠與共享倉庫基礎設施整合。我們設想了一些場景，例如建立工具來管理倉庫，以及在第三方倉庫產品之上實現 REST API 的其他場景。

我們將升級企業捆綁包倉庫 (Enterprise Bundle Repository) 的軟體，使其作為一個完整的 dm 倉庫執行，並提供 REST API 訪問。

倉庫和配置增強

dm Server 的配置系統已升級，以處理廣義的製品抽象，而不是專門處理捆綁包。主要原因是 dm Server 2.0 將支援許多不同的部署單元，而不僅僅是捆綁包和 WAR 檔案。

倉庫基礎設施已得到擴充套件，使得單一倉庫能夠管理不同型別的製品。然後，您的 dm Server 節點可以查詢倉庫以獲取所需的所有制品。

計劃檔案

dm Server 對 PAR 檔案的支援允許您將捆綁包組合成一個邏輯單元。在 PAR 中，捆綁包和服務被放置在一個 範圍 (scope) 內，該範圍將其與系統的其餘部分隔離。這種範圍劃分確保捆綁包彼此連線，並且優先看到彼此的服務，而不是來自範圍之外的服務。範圍劃分還防止應用程式程式碼洩漏到全域性範圍或其他應用程式的範圍中。

計劃檔案（或簡稱計劃）泛化了 PAR，以支援

• 捆綁包以外的製品
• 可選範圍劃分
• 製品生命週期控制

計劃也消除了 PAR 所需的額外打包步驟 - 計劃只需引用倉庫中的其他製品。

<plan name="greenpages" version="1.0.0" scoped="true" atomic="true">
  <artifact type="bundle" name="greenpages.db" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.app" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.jpa" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.web" version="${plan.version}"/>
</plan>

在此示例中，您可以看到一個名為 greenpages、版本為 1.0.0 的計劃，它引用了 4 個捆綁包。

計劃的 scoped 屬性控制計劃中的製品是否應該安裝到計劃特定的範圍。停用範圍劃分時，製品部署到全域性範圍，並可供所有其他製品訪問。

atomic 屬性控制計劃中製品的生命週期是否繫結在一起。將計劃設為 atomic 意味著計劃中單個製品的安裝、啟動、停止和解除安裝事件將提升到計劃中的所有制品。此外，在 atomic 計劃中，dm Server 會防止製品處於不一致的狀態。例如，如果一個製品啟動失敗，dm Server 將停止計劃中的所有制品。

計劃內部製品宣告的順序很重要。為了支援順序約束，dm Server 將按照製品在計劃中定義的順序向製品廣播生命週期事件。這使得您可以建立在啟動時具有順序依賴關係的捆綁包，而無需擔心如何控制部署時的順序。

計劃泛化了當今 dm Server 中可用的許多構造。PAR 等同於一個範圍化 (scoped)、原子化 (atomic) 的計劃，而庫 (library) 等同於一個未範圍化 (unscoped)、非原子化 (non-atomic) 的計劃。dm Server 內部的子系統構造只是一個未範圍化、原子化的計劃。

配置供應

dm Server 2.0 將支援的最令人興奮的新部署製品之一是配置檔案。配置檔案就是一個屬性檔案，它使用 OSGi Config Admin 服務在執行時可用。

配置檔案具有完整的生命週期支援，可以在執行時進行更新和重新整理。您的應用程式可以訂閱其配置檔案的重新整理通知並相應地進行調整。

與計劃結合使用時，配置檔案為管理應用程式的外部配置資料提供了極好的機制。考慮以下 JDBC 配置檔案：

jdbc.url=jdbc:h2:tcp:///~/greenpages
jdbc.user=greenpages
jdbc.password=pass
jdbc.driverClassName=org.h2.Driver

這個配置檔案可以以名稱 greenpages.jdbc.dev、版本 1.0 釋出到倉庫中。然後，在我們的計劃中，我們可以引用這個配置檔案：

<plan name="greenpages.dev" version="1.0.0" scoped="true" atomic="true">
  <artifact type="properties" name="greenpages.jdbc.dev" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.db" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.app" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.jpa" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.web" version="${plan.version}"/>
</plan>

這裡，一個名為 greenpages.dev 的計劃引用了 greenpages.jdbc.dev 配置檔案。現在我們可以構建一個名為 greenpages.prod 的計劃，它引用一個不同的配置檔案。

為了減少在這種場景中所需的重複，計劃本身就是倉庫中的製品，因此可以從其他計劃中引用。

<plan name="greenpages.bundles" version="1.0.0" abstract="true">
  <artifact type="bundle" name="greenpages.db" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.app" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.jpa" version="${plan.version}"/>
  <artifact type="bundle" name="greenpages.web" version="${plan.version}"/>
</plan>

<plan name="greenpages.dev" version="1.0.0" scoped="true" atomic="true">
  <artifact type="properties" name="greenpages.jdbc.dev" version="${plan.version}"/>
  <artifact type="plan" name="greenpages.bundles" version="${plan.version}"/>
</plan>

<plan name="greenpages.prod" version="1.0.0" scoped="true" atomic="true">
  <artifact type="properties" name="greenpages.jdbc.prod" version="${plan.version}"/>
  <artifact type="plan" name="greenpages.bundles" version="${plan.version}"/>
</plan>

這裡，一個名為 greenpages.bundles 的計劃被 greenpages.prod 和 greenpages.dev 計劃引用。greenpages.bundles 計劃被宣告為抽象的，阻止其獨立部署到 dm Server 中。

構建增強

我們最近釋出了 Bundlor 工具，該工具簡化了在 Maven、Ant 和 Eclipse 中建立 OSGi manifest 的過程。我們將隨著 dm Server 2.0 釋出 Bundlor 的一系列增強功能，包括：

• 從 Maven 和 Ivy 檔案自動檢測版本
• 支援 bnd 風格的版本範圍表示式
• 批次捆綁包處理

自動版本檢測使 Bundlor 能夠利用 Maven 或 Ivy 檔案中的資訊確定包或捆綁包依賴項的版本。目前，這些資訊包含在 TEMPLATE.MF 檔案或外部屬性檔案中。

使用版本範圍表示式，您可以將輸入版本擴充套件為一個版本範圍。這允許將 Maven 或 Ivy 檔案中定義的版本在對映到包依賴項時擴充套件為範圍。

批次捆綁包處理將允許大量 JAR 自動轉換為捆綁包。JAR 之間的關係用於推斷版本資訊，因此您在模板中需要編寫的程式碼更少。

模組化 Web 應用

我們計劃的未來最令人興奮的功能之一是支援模組化 Web 應用。目前，在 dm Server 1.0 中，可以將應用程式的大多數層拆分為捆綁包，但 Web 層往往會帶來問題。靜態資源解析、會話共享以及需要從多個貢獻者組合 UI，使得此功能對於純 OSGi 而言成為一個難題。

使用 dm Server 中的模組化 Web 應用支援，您可以將 Web 內容拆分到多個捆綁包中，這些捆綁包稱為 web fragments。應用程式中的所有 web fragments 共享相同的 ServletContext 會話狀態。每個 web fragment 被分配處理應用程式 URL 空間的子部分，這與 WAR 應用的 Web 上下文對映類似。例如，考慮下面的圖：

此圖表示一個名為 Spring Travel 的單個 Web 應用，它對映到 /springtravel 上下文路徑。Spring Travel 應用由三個 web fragments 組成，每個 fragment 對映到 /springtravel 的子路徑。例如，flights web fragment 處理對 /springtravel/flights/* 的請求。

Web fragments 可以動態新增到應用程式中，並且應用程式可以隨著這些 fragments 的安裝和解除安裝進行調整。

模組化 Web 應用最有趣的特性是支援 UI 組合。主 web 捆綁包可以定義 Web 應用的基本模板、佈局、樣式和影像。然後，web fragment 可以為現有頁面貢獻部分，或者貢獻符合主捆綁包提供的某個模板的全新頁面。

我們仍在確定這個 UI 模型具體是什麼樣子，但我希望最初我們能夠支援 JSF 作為定義模板和貢獻的一種方式。

分散式管理

AMS 團隊將擴充套件其對 dm Server 的支援，以允許跨一組 dm Server 節點執行以下操作：

• 製品安裝/解除安裝
• 製品啟動/停止
• 製品重新整理
• 倉庫釋出/移除

AMS 負責人 Jennifer Hickey 將在即將釋出的博文中詳細介紹這方面的內容。

克隆

克隆是我們引入的一個功能，旨在解決高階使用者面臨的一些棘手問題。

克隆解決的第一個問題是共享具有靜態狀態的捆綁包的問題。靜態狀態與其定義的類耦合。在 OSGi 中，使用具有靜態狀態的類的捆綁包不會獲得該類自己的版本。作為一個例子，考慮在應用程式中使用 Log4J。

Log4J 將其配置狀態儲存在靜態變數中。當您將應用程式部署為 WAR 檔案時，這不太可能成為問題。Log4J 將部署在 WEB-INF/lib 中，並且您的應用程式將擁有自己的 Log4J 類私有副本。然而，在 OSGi 中，您可能會有許多捆綁包共享同一個 Log4J 捆綁包，因此也共享相同的 Log4J 類。

克隆旨在解決的第二個問題稱為 pinning。Pinning 阻止您安裝依賴於同一第三方捆綁包但版本不同的兩個捆綁包。當您安裝的兩個捆綁包的依賴關係圖部分重疊，並且非重疊部分違反 uses 約束時，就會出現 Pinning。考慮下圖中所示的情況：

這裡，捆綁包 A 依賴於 Spring 2.5.6 和 EclipseLink 1.0.0。這種依賴配置沒問題，假設滿足所有其他依賴項，捆綁包將正確安裝。

現在考慮當我們想引入第二個捆綁包 捆綁包 B，並且我們希望這個捆綁包依賴於 Spring 2.5.6，同時我們想將 EclipseLink 的版本升級到 1.0.1 時會發生什麼。

您可以看到 捆綁包 B 和 EclipseLink 1.0.1 之間的依賴是可以滿足的，但 捆綁包 B 無法連線到 Spring 2.5.6。原因是 Spring 對所有 org.eclipse.persistence 包都有一個 uses 約束。這個約束阻止 捆綁包 B 連線到 Spring 2.5.6 以及一個 EclipseLink 捆綁包，除非它連線到與 Spring 2.5.6 相同的 EclipseLink 捆綁包。關於 uses 的更多資訊可以在 Glyn 的介紹性博文和我的關於診斷 uses 失敗的博文中找到。

為了解決這些問題，克隆提供了建立捆綁包託管克隆的能力，並將其繫結到應用程式的作用域中。在使用 Import-Bundle 引用捆綁包時，可以手動呼叫克隆。您可以使用此方法為應用程式捆綁包建立 Log4J 的克隆。

Manifest-Version: 1
Bundle-ManifestVersion: 2.0
Bundle-SymbolicName: app.bundle
Bundle-Version: 1.0.0
Import-Bundle: com.springsource.org.apache.log4j;bundle-version="1.3.4";sharing:=clone

當這被安裝到 dm Server 中時，您將獲得類似以下內容：

這裡，在 app.bundle 的作用域（由虛線表示）中建立了一個 Log4J 捆綁包的克隆。

如果 dm Server 遇到 uses 約束衝突，克隆將在供應期間自動觸發。回顧前面 捆綁包 B 和 EclipseLink 1.0.1 的例子，克隆將產生以下結果：

在供應期間，dm Server 檢測到 捆綁包 B 的依賴項無法滿足，並建立一個 Spring 2.5.6 的克隆來解決此問題。

dm Server 執行時管理模型將完全理解克隆。您可以查詢附加到給定捆綁包的克隆，並且對捆綁包的更新和重新整理也會影響該捆綁包的克隆。

改進的日誌和跟蹤支援

我們收到了很多關於 dm Server 1.0 中日誌和跟蹤支援的反饋，在 2.0 版本中，我們將解決使用者提出的最緊迫的問題。

對於 dm Server 2.0，我們將徹底改造所有跟蹤功能，使其執行在 SLF4J 之上，底層使用 LogBack 實現。此外，我們的日誌框架將被重新設計，使其作為 SLF4J 之上的一個薄層。

我們將提供一系列 LogBack（可能還有 Log4J）的 appender，它們將使用者和應用程式特定的跟蹤路由到 dm Server 的跟蹤檔案中。這裡最值得關注的可能是選擇性地選擇哪些捆綁包寫入應用程式特定跟蹤的能力。同樣重要的是要注意，在使用應用程式特定跟蹤時，應用程式目的地是根據 dm Server 內部當前的“工作單元”動態選擇的。這意味著同一個共享庫可以根據其用法將跟蹤寫入不同的應用程式跟蹤檔案。

我對一個特性感到興奮，那就是支援從倉庫部署 LogBack 配置。一旦配置安裝到 dm Server 中，捆綁包可以選擇繫結到該配置作為其日誌配置源。這提供了一種簡單機制，支援多個不同的日誌配置並行存在，並在多個捆綁包之間共享日誌配置。

企業 OSGi

今年應該會看到專門針對企業用途的 OSGi 規範首次釋出。我們積極參與此過程，並打算讓 dm Server 2.0 成為執行企業 OSGi 應用程式的最佳場所。我們將支援：

• RFC66 - 適用於 OSGi 的 Web 容器
• RFC119 - 分散式 OSGi
• RFC124 - Blueprint 服務（源自 Spring Dynamic Modules 中的工作）
• RFC139 - 適用於 OSGi 的 JMX 介面
• RFC142 - JNDI 和 OSGi 整合

RFC124 的參考實現正在由 SpringSource 基於 Spring Dynamic Modules 中完成的工作建立。我們還在使用 dm Server 1.0 中已有的 Web 應用程式支援來構建 RFC66 的參考實現。

管理 shell

管理 shell 提供安全、命令列的 dm Server 管理功能訪問。使用管理 shell，您可以：

• 管理配置的倉庫
• 安裝/解除安裝製品
• 啟動/停止製品
• 更新/刷新制品
• 查詢製品依賴關係圖
• 查詢執行中的服務
• 診斷依賴解析問題

管理 shell 完全支援外掛，可以輕鬆新增自定義命令。

Tomcat 配置

由於廣泛的需求，我們將從 dm Server 特定機制配置 Tomcat 切換回使用 Tomcat 自身的配置檔案格式。

下一步是什麼？

在接下來的幾天裡，我們將釋出 dm Server 2.0 M1，其中將包含我們計劃和共享倉庫功能的預覽。從那時起，我們希望能夠定期釋出里程碑版本，直至我們計劃於 7 月某個時候釋出的最終版本。