(2009年10月15日更新) 從里程碑 M5 開始，dm Server 2.0 採用 區域 來將核心與使用者應用程式隔離開來。這意味著核心實現對應用程式和應用程式管理來說幾乎完全不可見。

同樣在里程碑 M5 中，對克隆的支援被完全移除。區域隔離及其之間的範圍計劃為克隆旨在解決的最常見問題提供了大大簡化且更易於管理的解決方案。

在接下來的兩節中，我將概述這些變更以及我們進行這些變更的原因。

區域新聞

一個 區域 就像一個 OSGi 框架一樣——它是應用程式安裝、解析和執行的地方。

dm Kernel 建立了一個單一的 使用者區域 用於執行應用程式，並且所有應用程式（包括 dm Server 提供的——Splash、Admin、Web 和 Hosted Repository）都部署到 使用者區域 中。

Kernel bundles 未安裝在使用者區域中（除了少數區域管理所需的）。支援核心的必要功能在 OSGi 框架中執行，但使用者區域的應用程式無法看到它，除非是正常提供的服務。應用程式與核心實現是隔離的。

這種隔離有很多好處：例如，核心和使用者應用程式不再需要使用相同版本的 Spring Framework。（事實上，核心沒有安裝全部的 Spring Framework——它也不需要。）如果核心更新，應用程式需要升級或調整來適應它的可能性會大大降低。因此，核心實現更加穩定和有彈性，並且應用程式更有可能在版本之間的核心升級中存活下來。

區域帶來的好處

• 使用 Shell 或 Admin Console，您只能看到使用者區域——核心實現 bundles 是不可見的，這簡化了管理檢視。[2009年10月15日補充說明：少量核心 bundles 仍然在使用者區域中可見，因為核心已將其安裝在那裡用於區域管理。]
• 該設計完全能夠在未來的版本中擴充套件以支援多個使用者區域；管理一個區域的開銷很小且固定——實現是可伸縮的。
• 使用者區域的基本初始化是可配置的，並且完全獨立於核心。
• 區域的實現是完全通用的——它不以任何方式依賴於 Spring 或 Spring DM。如果需要，一個使用者區域可以配置為完全不支援 Spring，如果這是您所需要的。

克隆的終結

Rob 在四月份的 dm Server 路線圖中描述了克隆。克隆是一種分離兩個應用程式依賴關係的方式，否則它們會要麼共享不應該共享的構件，要麼嘗試共享不能共享的構件。

例如，共享帶有靜態狀態的 bundles 可能不是理想的，而能夠擁有這樣一個 bundle 的副本（克隆）意味著不同的應用程式可以使用不同的克隆（應用程式作用域機制允許我們在框架中以不同的名稱安裝多個副本）。在另一種情況下，當下層 bundle 透過一個共同的中介軟體（通常是 Spring Framework 的一部分）被依賴鎖定（pinned）時，克隆這個中介軟體允許克隆依賴於不同的下層 bundle，從而使克隆能夠滿足原始中介軟體無法滿足的傳遞性約束。

在 dm Server 2.0 的里程碑版本（直到 M4）中，克隆支援（包括手動和自動）一直可用。我們從這個實現中收到了很多反饋和經驗，並且作為一項實驗，它證明是富有成效的。然而，時間和經驗表明，這還沒有準備好用於生產環境，因此克隆已從 M5 中移除，並且不會是最終 2.0 版本的一部分。區域隔離結合範圍計劃，可以用來管理克隆旨在解決的最常見問題。這些解決方案更容易理解，並且在生產環境中大大更容易支援。

克隆的問題

移除克隆的最重要原因是自動克隆太脆弱且不可預測。

• 它工作時很棒，但通常需要很長時間（才能失敗或成功）。
• 要理解發生了哪些克隆以及為什麼發生，是極其困難的，並且不能保證對於部署相同的構件，每次都會獲得相同的克隆解決方案。

這些特性不是大多數系統管理員希望用於生產系統的（儘管它們有時在開發中很方便）。在生產環境中，我們需要一個可預測的配置，可以信賴它每次都以相同的方式工作（否則會快速失敗）。

手動克隆相對穩定，但即使是手動克隆也存在問題。

• 在鎖定（pinning）的情況下（如上所述），可能需要克隆相當多的中介軟體。
• 事先確定需要哪些克隆並非易事。（正是這種困難使得自動克隆難以做好並且效率低下。）

兩種克隆解決方案也依賴於作用域（scoping），並且這些解決方案不適用於無作用域（unscoped）的應用程式。

最後，克隆實現必須將 Spring 依賴作為特例包含進來才能高效工作。Spring DM extender 也引入了特例：這些對於其他 extender 和其他庫完全沒有通用性。它太過於特定於 Spring 了。

總的來說，儘管克隆和自動克隆的一些成果令人印象深刻，但這項功能在現場根本不夠穩定，因此為了整體質量和穩定性而被移除。

最重要的問題可以透過區域隔離和顯式作用域來解決。

總結

儘管可能會有人為克隆支援的移除感到惋惜（編寫它很有趣，儘管除錯時並非如此），但區域隔離和現有的範圍應用程式（和計劃）為常見的依賴問題提供了更簡單、更強大的解決方案。

鎖定（pinning）問題幾乎都產生於 Spring Framework，因此使用者區域的隔離為解決這些問題提供瞭解決方案。

其他常見情況可以透過適當使用範圍應用程式來解決，這實際上是管理伺服器中安裝構件的一種更可控、更易於支援的方式。範圍計劃使得建立所需的作用域變得容易，並且在框架上下文更改時，解析佈線在生產過程中保持穩定。