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

同樣在里程碑M5中，對克隆的支援被完全移除。區域隔離和帶作用域的計劃共同為克隆旨在解決的最常見問題提供了更簡單、更易於管理的解決方案。

在以下兩節中，我將概述這些更改以及我們做出這些更改的原因。

區域新聞

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

dm Kernel 建立一個單獨的 使用者區域，用於執行應用程式，並且所有應用程式（包括 dm 伺服器提供的 Splash、Admin、Web 和託管儲存庫）都部署到這個 使用者區域 中。

核心 bundle 不會 安裝在 使用者區域 中（除了少數用於區域管理的 bundle）。支援核心所需的函式在 OSGi 框架中執行，但使用者區域應用程式看不到它，除了通常提供的服務。應用程式與核心實現是 隔離 的。

這種隔離有許多好處：例如，核心和使用者應用程式不再需要使用相同版本的 Spring Framework。（實際上，核心並沒有安裝所有 Spring Framework——它不需要這樣做。）如果核心更新，應用程式需要升級或調整以適應這種情況的可能性大大降低。因此，核心實現更加穩定和彈性，應用程式在釋出版本之間的核心升級中倖存的可能性更大。

區域令人歡欣鼓舞

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

克隆來襲

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

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

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

一個謹慎的克隆者

移除克隆的最重要原因是自動克隆過於脆弱和不可預測

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

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

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

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

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

最後，克隆實現必須將 Spring 依賴項作為特例包含在內才能高效工作。Spring DM 擴充套件器也引入了特例：這些特例對於其他擴充套件器和其他庫根本不通用。它太 Spring 特有。

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

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

高音和低音

儘管一些人可能會哀悼克隆支援的逝去（編寫它很有趣，但除錯起來卻不），但區域隔離和現有作用域應用程式（和計劃）為常見的依賴問題提供了更簡單、更健壯的解決方案。

鎖定問題幾乎都是透過 Spring Framework 產生的，因此使用者區域的隔離為大多數這些問題提供瞭解決方案。

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