OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sdd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Fw: Re 2.5.5 - Independent lifecycle operations


Here's the analysis I promised on requirement 2.5.5, I believe the schema adequately meets the above requirement, as described below, although there are a couple of extensions that might be needed if there are important use cases for them. Please see if you agree and/or provide use cases that aren't met.



"Reqt 2.5.5: The SDD specification must support the definition of whether a composed component, product or solution may be installed, uninstalled or updated independently."


The current schema supports the following:

  1. Distinguishing content that is required from content that can be selected during install/uninstall, and can be added/removed after the initial install. Defining dependencies between selectable content.
  2. Grouping selectable content into "features" and indicating what combinations of features make sense (via features/feature selection rules)
  3. Update packages to update an installed component (resources) either as part of an overall solution update, or individually.
  4. Specifying that an installed component (resulting resource) is a dedicated part of a solution, and should therefore not be updated independently from the solution, or by a package that updates any other solution.

The schema would need extending to support the following, if we decide they are needed:


This is broken down into four sections.

1) Given a base installation package, how do I tell what parts of the solution can be separately installed or uninstalled.
2) Given an update package, how do I tell whether it can be applied to an installed resource, and what parts of it must or may be applied.
3) Given 2, how does a solution composer control whether its components can be independently updated.
4) How do I tell what packages can be used to install/uninstall content from an existing installed solution.


Within a single descriptor, selectable content and dependencies are used to determine which components of a solution must be installed, and which may be installed.

Features and feature selection rules provide "best practices" to help make sensible (e.g. functionally valid) selections of selectable content when installing, adding new features or removing features. Features are guidance; dependencies are the mandatory rules.

The asserted behaviour is that optional content which is not selected at initial install may be added subsequently using the same package or any other compatible package (see 4 later for discussion on compatible packages). Similarly, optional content may be independently removed, subject to dependencies. Other than for complex wrappers (WrapperIU content type), the current schema does not support controlling this - i.e. it is not possible to assert that features may not be added or removed. The WrapperIU content type has attributes to define this, because it is not uncommon for complex legacy install packages with built-in features to have this limitation.

Within a composite package (multiple descriptors), the top-level SDD defines what is independently installable/uninstallable at the solution level. The selection of optional components in composed packages is controlled by:

There are two types of update package:
  1. A solution update, which updates a solution resource (indicated by a resulting resource in the RootIU) to a given level. All relevant updates must be applied.
  2. A bundle of updates, typically applied to a single resource. In a bundle, there is no resulting resource at the RootIU level. The user may select from specified content within the bundle.

When can an update be installed?

An update or set of updates can be installed if:
  1. At the point each update is installed, its required base and other requirements are met
  2. By the time the install of the update(s) is complete, the results do not break runtime dependencies defined by installed solutions which use the updated resources.
  3. The results of installing the update(s) are compatible with installed solutions that contain the updated resources.

"Compatible" means that the resulting resource declares backwards compatibility to the version of the resource which was defined in the installed solution.

The above rules allow the folllowing important cases:
  1. Applying a set of updates to maintain system integrity, where it may not be possible to apply each update independently.
  2. Applying an update to a component of a solution, without necessarily providing an update for the whole solution. This is important to allow independent teams to produce maintenance for components/products that are then combined into multiple solutions. It is unworkable to require that maintenance to then be re-packaged as maintenance specific to each solution.
  3. Allowing multiple solutions to provide updates to the same shared components, not requiring each component to maintained as part of one specific solution.

What parts of the update are installed , for a solution update?

Best practices for a solution update would not allow updates to include new features, and so there would not be any distinguished "selectable content".

In this case, the rule for applying updates is as follows. For each IU or CU immediately below the Root IU:
The above rules ensure that all relevant updates are applied, whilst accommodating optional content.

Solution update with features

In a solution update which does include new features, the optional new content should be specified as "selectable content". That part of the RootIU should be processed as for an install. The remaining content should be processed as for update.

What parts of the update are installed, for a bundle update?

A bundle (with no resulting resource at the RootIU level) may have updates in "selectable content". The user may select from these. Dependencies are used to determine coreqs/prereqs.


A composing solution may want to prevent a component from being updated independently or by any other solution, i.e. to prevent the independent update scenarios described above.

The schema allows an SDD author to assert that a resulting resource is for the dedicated use of the solution (dedicated attribute on resource). This means no other solution should contain or use it. A runtime (at a TBD compliance level) should only allow dedicated resources to be updated as part of the solution to which they are dedicated. This would add a fourth rule to the update rules:

4. An update that is applied to a dedicated resource (has this as its required base) must be part of an update to the solution that the resource is dedicated to.

Note that this assumes that the runtime has access to the metadata for the solution that contains the resource, otherwise it will not know that it is a dedicated component.

A runtime should allow shared components to be independently updated, using a package intended for that purpose (i.e. with that resource as its required base).

If there is a requirement to allow dedicated resources to be independently updated, then an addition to the schema would be required.


In the simple case in (1), the user uses the same package that was used for base install, to add new features or to uninstall features or the whole solution. Even if subsequent updates have been applied, it is reasonably simple to understand that it should be valid to add features from the original base install package, as long as any updates are then applied to the new content. Similarly, even if updates have been applied, it should be valid to uninstall features defined in the original package providing any updated uninstall artifacts are used.

Unfortunately, there are very reasonable scenarios where the user may not use exactly the same package. The user installs V1.0 and then a whole set of incremental update to get them to V1.1. The manufacturer provides a V1.1 package - it is reasonable to expect to be able to add features from the V1.1 package, rather than going back to V1.0 and reapplying all the updates. Providing the V1.1 package has content corresponding to the currently installed solution, this should be permitted, even if the features in V1.1 do not correspond directly to features in V1.0.

A similar statement should be true for uninstall, although this is perhaps less obvious. It should be possible to use the V1.1 descriptor to drive the uninstall of a feature or of the whole solution.

The main aspect of the schema that allows this is the identification of required bases, which allows a runtime to determine when a package is compatible based on what was actually installed, even if it does not use the same IU names or have the same features as a previous package.

Senior Technical Staff Member
IBM, 11501 Burnet Road, Mail Point 901-6B10
Austin, TX 78758
1-512-838-3482 tl 678-3482

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]