我們收到許多 dm Server 使用者關於未來幾個版本中會發生什麼的問題。在這篇部落格文章中，我將概述我們路線圖上的主要功能。我們遵循 Scrum 實踐，因此您可以預期我們的 sprint 會產出相當頻繁的里程碑版本，並且我們靈活地處理新的需求和優先順序的變化。

共享倉庫

共享倉庫允許您擁有一個集中式位置，用於管理可安裝在您的 dm Server 例項中的工件。然後，這些共享倉庫可以在其倉庫鏈中的任何點新增到 dm Server 配置中。

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

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

我們將升級我們的企業 Bundle 倉庫的軟體，使其作為完整的 dm 倉庫執行，並支援 REST API 訪問。

倉庫和配置增強

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

倉庫基礎設施已擴充套件，以使不同型別的工件可以由單個倉庫管理。您的 dm Server 節點然後可以查詢倉庫以獲取其所需的所有工件。

計劃檔案

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

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

• 除 bundle 之外的工件
• 可選範圍
• 工件生命週期控制

計劃還消除了 PARs 所需的額外打包步驟——計劃只引用您倉庫中的其他工件

<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 個 bundle。

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

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

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

計劃泛化了當今 dm Server 中可用的許多構造。PAR 等同於一個有範圍的原子計劃，而庫等同於一個無範圍的非原子計劃。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 清單的建立。我們將釋出 dm Server 2.0 的一系列 Bundlor 增強功能，包括

• 從 Maven 和 Ivy 檔案自動檢測版本
• 支援 bnd 樣式的版本範圍表示式
• 批次 bundle 處理

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

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

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

模組化 Web 應用程式

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

使用 dm Server 中的模組化 Web 應用程式支援，您可以將您的 Web 內容分佈到多個 bundle 中，這些 bundle 稱為 web fragments。應用程式中的所有 Web 片段共享相同的 ServletContext 會話狀態。每個 Web 片段都分配處理應用程式 URL 空間的一個子部分，就像 WAR 應用程式的 Web 上下文對映一樣。例如，考慮下圖

此圖表示一個 Web 應用程式 Spring Travel，它對映到 /springtravel 上下文路徑。Spring Travel 應用程式由三個 Web 片段組成，每個片段都對映到 /springtravel 的子路徑。例如，flights Web 片段服務 /springtravel/flights/* 的請求。

Web 片段可以動態新增到應用程式中，並且應用程式可以隨著這些片段的安裝和解除安裝而適應。

模組化 Web 應用程式最有趣的功能是支援 UI 組合。Web 主 bundle 可以定義 Web 應用程式的基本模板、佈局、樣式和影像。然後，Web 片段可以向現有頁面貢獻部分，或貢獻適合主模板提供的全新頁面。

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

分散式管理

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

• 工件安裝/解除安裝
• 工件啟動/停止
• 工件重新整理
• 倉庫釋出/刪除

AMS 負責人 Jennifer Hickey 將在即將釋出的部落格文章中詳細討論此事。

克隆

克隆是我們為了解決高階使用者面臨的一些棘手問題而引入的一項功能。

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

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

克隆旨在解決的第二個問題是所謂的固定。固定阻止您安裝兩個依賴於相同第三方 bundle 但版本不同的 bundle。固定發生在你安裝的兩個 bundle 的依賴圖部分重疊，非重疊部分違反了 uses 約束。考慮下圖中的情況

這裡 Bundle A 依賴於 Spring 2.5.6 和 EclipseLink 1.0.0。此依賴配置檔案是正常的，並且假設所有其他依賴項都滿足，bundle 將正確安裝。

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

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

為了解決這些問題，克隆提供了建立 bundle 的受管克隆的能力，並且該克隆可以繫結到應用程式的範圍。在使用 Import-Bundle 引用 bundle 時可以手動呼叫克隆。您可以使用它為您的應用程式 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 中時，您將得到類似這樣的結果

這裡，Log4J bundle 的一個克隆在 app.bundle 的範圍（由虛線表示）中建立。

如果 dm Server 遇到 uses 約束衝突，克隆將在配置期間自動觸發。回顧前面 Bundle B 和 EclipseLink 1.0.1 的例子，克隆將給出以下結果

在配置期間，dm Server 檢測到 Bundle B 的依賴項無法滿足，並建立 Spring 2.5.6 的克隆來解決此問題。

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

改進的日誌和跟蹤支援

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

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

我們將提供一系列 LogBack（可能還有 Log4J）附加程式，它們將把使用者和應用程式特定的跟蹤路由到 dm Server 跟蹤檔案中。這裡最有趣的可能是選擇性地選擇要寫入應用程式特定跟蹤的 bundle 的能力。同樣重要的是要注意，當使用應用程式特定跟蹤時，應用程式目標是根據 dm Server 中當前的工作單元動態選擇的。這意味著同一個共享庫可以根據其用途將其跟蹤寫入不同的應用程式跟蹤檔案。

我感到興奮的一個功能是支援從倉庫部署 LogBack 配置。一旦配置安裝到 dm Server 中，bundle 就可以選擇繫結到該配置作為其日誌配置源。這提供了一種簡單的機制，支援多個不同的日誌配置並存，以及跨多個 bundle 共享日誌配置。

企業級 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 月份的最終釋出。