(updated 15Oct2009) Beginning in milestone M5, dm Server 2.0 employs regions to isolate the kernel from users’ applications. This means that the kernel implementation is almost completely invisible to applications and to application management.

Also in milestone M5, support for cloning is completely removed. Region isolation and scoped plans between them offer much simpler and more manageable solutions to the most common problems that cloning was intended to address.

In the following two sections I outline these changes, and the reasons we made them.

The regional news

A Region is just like an OSGi framework—it is where applications are installed, resolved and run.

dm Kernel creates a single User Region in which to run applications and all applications (including the ones that dm Server supplies—Splash, Admin, Web and Hosted Repository) are deployed into the User Region.

Kernel bundles are not installed in the user region (apart from a few needed for region management). The necessary function to support the kernel runs in the OSGi framework, but the user region applications cannot see it, except for the services that are normally offered. The applications are isolated from the kernel implementation.

This isolation has many benefits: for example, it is no longer necessary for the kernel and the users’ applications to use the same version of the Spring Framework. (In fact the kernel doesn’t install all of the Spring Framework—it doesn’t need to.) If the kernel is updated it is far less likely that applications will need to be upgraded or adjusted to accommodate this. The kernel implementation is therefore much more stable and resilient and applications are much more likely to survive kernel upgrades between releases.

Regions to be cheerful

• Using the Shell or the Admin Console you only see the User Region—the kernel implementation bundles are not visible, simplifying the administration view. [Note added 15Oct2009: a few kernel bundles are still visible in the User Region, because the kernel has installed them there for region management.]
• The design is quite capable of being extended to accommodate multiple user regions in future releases; there is a small and fixed overhead to managing a region—the implementation is scalable.
• Basic initialisation of the user region is configurable and entirely independent of the kernel.
• The implementation of regions is completely general—it does not depend upon Spring or Spring DM in any way. If required, a user region can be configured with no Spring support at all, if that’s what you need.

Send in the clones

Cloning was described in April by Rob in the dm Server Roadmap. Cloning is a way of separating the dependencies of two applications that would otherwise either share artefacts which should not be shared, or try to share artefacts which cannot be shared.

For example, sharing bundles with static state may not be desirable, and being able to have a copy (clone) of such a bundle means that different applications can use the different clones (the application scoping mechanism allows us to have multiple copies installed in the framework under distinct names). In another case, when a lower-level bundle is pinned by a dependency through a common intermediary (which is often part of the Spring Framework), cloning the intermediary allows the clone to depend upon a different lover-level bundle, freeing the clone to satisfy a transitive constraint the original intermediary could not.

In the milestone releases of dm Server 2.0 (up to M4) cloning support (both manual and automatic) has been available. We have received a lot of feedback and experience from this implementation and as an experiment it has proved fruitful. However, time and experience have shown us that this is not yet ready for production, so cloning is removed from M5, and will not be part of the final 2.0 release. Region isolation, together with scoped plans, can be used to manage the most common problems that cloning was designed to address. These solutions are much easier to understand and much easier to support in production.

One careful cloner

The most important reason for removing cloning is that automatic cloning is far too brittle and unpredictable:

• It is brilliant when it works, but in general it can take a very long time (to fail or to succeed).
• It is extremely hard to understand what cloning has happened and why, and it cannot be guaranteed that the same cloning solutions will be obtained every time for deployment of the same artefact.

These are not properties that most system administrators want for a production system (though they can sometimes be convenient in development). In production we need a predictable configuration which can be relied upon to work the same way every time (or else fail quickly).

Manual cloning is relatively stable, but even here there are problems:

• In the pinning situation (outlined above) rather a lot of intermediaries may need to be cloned.
• It is non-trivial to determine which clones are needed beforehand. (It is precisely this difficulty that makes auto-cloning hard to do well and efficiently.)

Both cloning solutions also depend upon scoping and these solutions do not work for unscoped applications.

Finally, the cloning implementation had to include Spring dependencies as a special case in order to work efficiently. The Spring DM extender also introduced special cases: these do not generalise at all well for other extenders and other libraries. It’s just too Spring-specific.

Overall, although some of the achievements of cloning and auto-cloning were impressive, the function is simply not stable enough to support in the field and is therefore removed in the interests of overall quality and stability.

The most important problems can be solved by region isolation and explicit scoping.

High notes and low notes

Although it is likely that some will mourn the passing of cloning support (and it was fun to write, though not to debug), region isolation and existing scoped applications (and plans) offer a much simpler and more robust solution to common dependency problems.

The pinning problems were nearly all produced through the Spring Framework, so the isolation of the user region offers a solution to most of these issues.

Other common cases can be solved through appropriate use of scoped applications, and this is actually a much more controllable and supportable way of managing the artefacts installed in the server. Scoped plans make it easy to create the desired scopes, and the resolution wiring remains stable during production as the framework context changes.