我們從 dm Server 使用者那裡收到許多關於未來幾個版本期望的提問。在這篇部落格文章中，我將概述我們產品藍圖上的主要功能。我們遵循 Scrum 實務，因此您可以預期從我們的 sprints 輸出中看到相當頻繁的里程碑，並且我們在處理新需求和優先順序變更方面具有彈性。

共用儲存庫

共用儲存庫允許您擁有一個集中位置來管理可在您的 dm Server 實例中安裝的組件。然後，這些共用儲存庫可以隨時添加到 dm Server 配置的儲存庫鏈中。

共用儲存庫只是一個 dm Server 節點，用於管理檔案系統儲存庫並使其可供其他節點使用。這些儲存庫託管節點稱為 dm 儲存庫節點。共用儲存庫的數量及其順序不是固定的 - 您可以自由選擇任何對您的環境有意義的儲存庫結構。

用戶端 dm Server 節點使用 REST API 與儲存庫節點通訊。此 REST API 將被記錄並公開，以便第三方工具可以與共用儲存庫基礎架構整合。我們設想了一些情境，其中建立工具來管理儲存庫，以及其他在第三方儲存庫產品之上實作 REST API 的情境。

我們將升級我們的企業套件組合儲存庫軟體，使其作為完整的 dm 儲存庫執行，並完整配備 REST API 存取。

儲存庫和佈建增強功能

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

儲存庫基礎架構已擴展，以便不同類型的組件可以由單個儲存庫管理。然後，您的 dm Server 節點可以向儲存庫查詢其所需的所有組件。

計劃檔案

dm Server 中對 PAR 檔案的支援允許您將套件組合作為單個邏輯單元組合在一起。在 PAR 內，套件組合和服務被放置到一個範圍中，該範圍將它們與系統的其餘部分隔離。此範圍設定確保套件組合相互連接，並優先於來自範圍外部的服務查看彼此的服務。範圍設定還可以防止應用程式碼洩漏到全域範圍或其他應用程式的範圍中。

計劃檔案（或簡稱計劃）將 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 屬性控制計劃中組件的生命週期是否應綁定在一起。使計劃成為原子意味著計劃中單個組件的安裝、啟動、停止和解除安裝事件將升級到計劃中的所有組件。此外，在原子計劃中，dm Server 會阻止組件處於不一致的狀態。例如，如果一個組件啟動失敗，則 dm Server 將停止計劃中的所有組件。

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

計劃將當今 dm Server 中可用的許多結構廣義化。PAR 相當於範圍設定的原子計劃，而程式庫相當於未範圍設定的非原子計劃。dm Server 內部的子系統結構只是一個未範圍設定的原子計劃。

配置佈建

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

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

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

jdbc.url=jdbc:h2:tcp://127.0.0.1/~/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 樣式的版本範圍運算式
• 批量套件組合處理

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

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

批量套件組合處理將允許自動將大量 JAR 轉換為套件組合。JAR 之間的關係用於推斷版本資訊，因此您需要在範本中編寫的程式碼更少。

模組化 Web 應用程式

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

使用 dm Server 中的模組化 Web 應用程式支援，您將能夠將 Web 內容拆分到多個套件組合中，這些套件組合稱為 Web 片段。應用程式中的所有 Web 片段共用相同的 ServletContext 會話狀態。每個 Web 片段都分配用於處理應用程式 URL 空間的子部分，這很像使用 WAR 應用程式完成 Web 內容映射。例如，考慮下圖

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

Web 片段可以動態添加到應用程式中，並且應用程式可以在安裝和解除安裝這些片段時進行調整。

模組化 Web 應用程式最有趣的功能是支援 UI 組合。Web 主套件組合可以定義 Web 應用程式的基本範本、版面配置、樣式和圖片。然後，Web 片段可以將區段貢獻到現有頁面或適合主套件組合提供的範本之一的全新頁面。

我們仍在定義此 UI 模型的外觀，但我希望最初我們能夠支援 JSF 作為定義範本和貢獻的一種方式。

分散式管理

AMS 團隊將擴展其 dm Server 支援，以允許跨一組 dm Server 節點執行以下操作

• 組件安裝/解除安裝
• 組件啟動/停止
• 組件重新整理
• 儲存庫發佈/移除

AMS 負責人 Jennifer Hickey 將在即將發佈的部落格文章中更詳細地介紹這一點。

複製

複製是我們引入的一項功能，旨在解決我們進階使用者面臨的許多棘手問題。

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

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

複製旨在解決的第二個問題是稱為釘選的問題。釘選會阻止您安裝兩個依賴於同一個第三方套件組合但版本不同的套件組合。當您要安裝的兩個套件組合具有部分重疊的依賴關係圖，並且非重疊部分破壞了 uses 約束時，就會出現釘選。考慮下圖中的情況

在這裡，套件組合 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 套件組合，否則此約束會阻止 套件組合 B 連接到 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 中時，您將獲得如下所示的內容

在這裡，Log4J 套件組合的副本在 app.bundle 的範圍（以虛線表示）中建立。

如果在佈建期間 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）附加程式，這些附加程式將使用者和應用程式特定的追蹤路由到 dm Server 追蹤檔案中。這裡最令人感興趣的可能是選擇性地選擇您要寫入應用程式特定追蹤的套件組合的能力。同樣重要的是要注意，當使用應用程式特定的追蹤時，應用程式目的地是根據 dm Server 內部的當前工作單元動態選擇的。這表示同一個共用程式庫可以根據其使用情況將其追蹤寫入不同的應用程式追蹤檔案中。

我感到興奮的一個功能是支援從儲存庫部署 LogBack 配置。一旦配置安裝到 dm Server 中，套件組合就可以選擇綁定到該配置作為其日誌記錄配置來源。這為並排支援多個不同的日誌配置以及在多個套件組合之間共用日誌記錄配置提供了一種簡單的機制。

企業 OSGi

今年應該會看到第一個專門針對企業使用的 OSGi 規範發佈。我們積極參與此過程，並且我們希望 dm Server 2.0 成為執行企業 OSGi 應用程式的最佳場所。我們將支援

• RFC66 - OSGi 的 Web 容器
• RFC119 - 分散式 OSGi
• RFC124 - Blueprint Service（從 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 月的某個時候發佈最終版本。