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

同樣在 M5 里程碑中，完全移除了對複製 (cloning)的支援。 區域隔離和作用域計畫 (scoped plans) 兩者之間提供了更簡單且更易於管理的解決方案，以解決複製原本旨在解決的最常見問題。

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

區域新聞 (The regional news)

區域 (Region)就像一個 OSGi 框架——應用程式在其中安裝、解析和執行。

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

核心套件 (Kernel bundles) 不安裝在使用者區域中（除了少數幾個區域管理所需的套件）。 支援核心的必要功能在 OSGi 框架中執行，但使用者區域應用程式無法看到它，除了通常提供的服務。 應用程式與核心實作隔離。

這種隔離具有許多優點：例如，核心和使用者的應用程式不再需要使用相同版本的 Spring Framework。（事實上，核心並未安裝所有 Spring Framework——它不需要。） 如果核心已更新，則應用程式需要升級或調整以適應此變更的可能性會大大降低。 因此，核心實作更加穩定且具有彈性，並且應用程式更有可能在版本之間的 Kernel 升級中倖存。

值得高興的區域 (Regions to be cheerful)

• 使用Shell或管理主控台 (Admin Console)，您只會看到使用者區域 (User Region)——核心實作套件不可見，從而簡化了管理視圖。[2009 年 10 月 15 日新增：一些核心套件仍然在使用者區域中可見，因為核心已將它們安裝在那裡用於區域管理。]
• 該設計完全能夠擴展以適應未來版本中的多個使用者區域； 管理區域的開銷很小且是固定的——該實作是可擴展的。
• 使用者區域的基本初始化是可配置的，並且完全獨立於核心。
• 區域的實作是完全通用的——它不以任何方式依賴 Spring 或 Spring DM。 如果需要，可以配置使用者區域，而完全不支援 Spring，如果那是您需要的。

送入複製 (Send in the clones)

Rob 在dm Server Roadmap中於 4 月份描述了複製。 複製是一種分離兩個應用程式的相依性的方法，否則這兩個應用程式要麼共享不應共享的工件 (artefacts)，要麼嘗試共享無法共享的工件。

例如，與靜態狀態 (static state)共享套件可能是不合需要的，並且能夠擁有此類套件的副本（複製）意味著不同的應用程式可以使用不同的複製（應用程式作用域機制允許我們在框架中使用不同的名稱安裝多個副本）。 在另一種情況下，當較低層級的套件通過一個常見的中介者 (intermediary) 釘選相依性時（通常是 Spring Framework 的一部分），複製該中介者允許該複製依賴於不同的 lover-level 套件，從而釋放該複製以滿足原始中介者無法滿足的傳遞約束。

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

一個仔細的複製者 (One careful cloner)

移除複製的最重要原因是自動複製太過脆弱且無法預測

• 當它工作時很棒，但通常需要很長時間（才能失敗或成功）。
• 非常難以理解發生了什麼複製以及原因，並且無法保證每次部署相同工件時都會獲得相同的複製解決方案。

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

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

• 在釘選情況（如上所述）中，可能需要複製相當多的中介者。
• 預先確定需要哪些複製是非顯而易見的。（正是這種困難使得自動複製難以做得好且高效。）

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

最後，複製實作必須將 Spring 相依性作為特殊情況包括在內才能有效地工作。 Spring DM 擴展器也引入了特殊情況：這些對於其他擴展器和其他庫根本無法通用化。 它太過於 Spring 特有。

總體而言，儘管複製和自動複製的一些成果令人印象深刻，但該功能根本不夠穩定，無法在現場支援，因此為了整體品質和穩定性而將其移除。

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

高音符和低音符 (High notes and low notes)

儘管可能有些人會哀悼複製支援的消失（並且編寫它很有趣，儘管不適合偵錯），但區域隔離和現有的作用域應用程式（和計畫）為常見的相依性問題提供了更簡單且更強大的解決方案。

釘選問題幾乎都是通過 Spring Framework 產生的，因此使用者區域的隔離為大多數這些問題提供了一個解決方案。

其他常見情況可以通過適當使用作用域應用程式來解決，並且這實際上是一種更可控制和可支援的方式來管理伺服器中安裝的工件。 作用域計畫 (Scoped plans)可以輕鬆創建所需的作用域，並且解析佈線 (resolution wiring) 在生產過程中保持穩定，因為框架上下文會發生變化。