IBM: SDD Use cases with some outline requirements

[Christine Draper <cdraper@us.ibm.com>]

All,

Here's a slightly updated version of the use cases I sent previously, if we get to them tonight. I've started to identify what requirements or constraints there might be on the SDD, arising from various aspects of the use case.

Product installation and componentization

A software vendor needs to package their product on (potentially multiple) physical media or for download by multiple customers.
Requirement: map to physical packaging separate from deployment descriptor

The product is typically shipped with an interactive install program to guide the user during install.
Requirement: package may optionally contain interactive install program
Requirement: ability to refer to individual parts of the schema (e.g. requirements/checks)
Requirement: descriptions and NLS for parts of the schema (IUs, features, requirements...)

The ability to specify optional content and the rules for how it may be selected (features, feature selection rules) is important.
Requirement: Features, feature selection, ways to categorize/group features for different user roles or purposes

Increasingly, the need to compose product offerings from other products and components - including embedding third-party products - is becoming important. This need to support composition is one of the key drivers for a common declarative descriptor.
Requirement: package composition
Requirement: package must be installable by third party using information in descriptor. Should not require use of interactive install program or understanding of proprietary formats.

Another driver is to address the limitations of existing install technology in areas such as:

• dependencies that span multiple hosting environments

Requirement: Expressing dependencies on multiple resources with defined relationships
Requirement: Expressing dependencies on environments other than OS

• handling multiple software instances

Requirement: ability to distinguish instances, e.g. when expressing dependencies

• coordination of install/rollback

Requirement: undo support

• integrity checking/lifecycle management based on dependencies

Requirement: dependency information, related to lifecycle operations

These vendors may have sophisticated requirements around maintenance, driven by the need to support an evolving product in a wide customer base and in many different modes of use. This includes incremental updates, fixes, upgrades (including between different editions of a product), migration, "rollup" of versions, obsoletion of content, complex supersedes relationships, independent update of components.
Requirement: provide information needed to manage maintenance lifecycle, and define relationships between successive descriptors

Another common requirement is to support localization packages, which may be distributed separately.
Requirement: localization package support - e.g. defining localization relationships; understanding need to add or remove localization content when you add/remove product content. 

A subset of vendors have a requirement to develop cross-platform install packages. Leaving aside the need for a common format for the install artifact/actions (outside scope of this WG), these vendors need a descriptor that can specify both cross-platform dependencies (in a common way) and platform-specific dependencies. 
They may also need to include content conditionally, based on platform.
Requirement: Platform-neutral (resource neutral) description
Requirement: Expressing conditions that determine what content is installed
Requirement: Variables based on environment

Traditionally, product installation means installing software into the operating system environment. Increasingly today, vendors are creating products that include other software, such as J2EE applications, and are recognizing the need to treat other content such as database tables and web content as a formal part of the product that requires lifecycle management. 
Requirement: Pluggable mechanism for specifying target environments and artifacts to be installed. Opaque artifacts. Descriptor is platform/resource-neutral. 
This introduces the need to coordinate an installation across multiple hosting environments on a single machine. In addition, different features of the product may commonly be installed on different machines.
Requirement: Multiple-machine target topologies. 

As vendors increasingly compose individual products into higher-value solution offerings, the need to provide a product installation program that can coordinate the installation across multiple machines increases. This blends into the distributed change management scenario, at least in terms of requirements on the descriptor and on the technology to perform the dependency checking and installation. It also highlights a requirement to be able to create "wrappers" for existing products that they want to be able to compose. 
Requirement: Wrapper support. 
Requirement: Ability to co-exist and express dependencies on software installed through other mechanisms (need to describe how to detect the IU in the hosting environment).  

Componentization is driven by the desire of vendors to structure their products into components that can readily be composed into offerings to meet specific market needs. 
Requirement: package composition.  Shared versus dedicated components. Restrictions on sharing.... 
The components may be finer-grained than existing products. A key requirement is the composability of the installation packages, including:

• Installation order driven by dependencies, including on required state

Requirement: Internal dependencies expressed. Dependencies include state (created, installed, running...)

• Aggregation of consumption dependencies (e.g. diskspace)

Requirement: Declarative dependencies, defined semantics ("consumption" of what, on what)

• Matching dependencies in one package that are to be satisfied in another

Requirement: Ability to determine that installing one package will satisfy a dependency in another

• Mapping variables between different components

Requirement: descriptor composition (mapping variables) 

A particular challenge with fine-grained componentization is that the user may not be aware (or at least does not want to be aware) of the individual components in the product. 
Requirement: Support different IU categories to distinguish a product from a component?
The composite package needs to reflect the view that the user should be aware of (e.g. features, parameters, target environment for the product), and map that into the information needed to install the individual components, allowing automated decisions where user input is not available or expected. 
Requirement: descriptor composition (mapping of variables, features, etc. Identifying input parameters vs derived variables vs queried properties.) 
The install service needs to record and track the details of the component instances and dependencies, but also needs to be able to hide this detail when it is not required. 
Requirement: Categorization of IUs.   

Distributed change management of composite applications

The second major category focuses on users developing solutions (composite applications) that are typically intended for a more specific purpose and end-user. Within this category, it is probably useful to distinguish:

• Application developers who create new application code (e.g. J2EE apps, web content, .NET apps), which forms a composite application typically spanning multiple machines and environments. This role might be split into two - the application modeler, and the application packager.
• Solution integrators who bring together products from multiple vendors, plus the composite applications described above, and configure them into an overall solution.
• Administrators/release managers who define a set of packages to be installed together, but not necessarily for a single purpose.

Application modelers describe the expectation around the structure of the application, the resources that it creates, and their target environment for deployment. Application packagers refine the deployment information, adding detail about its content, dependencies, target environment and resulting resources. 
Requirement: Declaration of created resources, relationships, requirements   

Solution integrators will typically be focussed on the ability to create wrappers for existing products, and to aggregate descriptors into a composite descriptor. They also need to be able to add configuration to the composite, in order to bring the overall solution into a usable state.
Requirement: Wrappers. 
Requirement: Specifying configuration.   

Although these solutions are typically deployed into a more specific environment than a product, it is important to note that there is still a strong requirement to support the definition of a logical target environment which can then be mapped to multiple physical environments. This is because a solution will be deployed into multiple different environments, both as part of its lifecycle (development, system test, performance test, acceptance test, production) and because a solution may be deployed to multiple production environments. 
Requirement: Declarative description of logical target environment.  

The distributed scenario typically involves the use of general purpose change management applications that manage the lifecycle of a set of resources (data center), rather than a solution-specific installation program. Planning for a change will involve making a set of decisions such as provisioning new servers or repurposing existing ones, deciding on a network topology, configuring firewalls, etc. 
Requirement: Declaring requirements, including specifying required connectivity between resources.   
Requirement: Ability to check dependencies and plan deployment based on descriptor plus resource instance information (without direct access to target environment).
It may also involve installing multiple packages in order to satisfy dependencies.
Requirement: Ability to understand interpackage sequencing dependencies.   
The desire is that automated assistance can be provided in this planning process, based on information in the descriptor. To support this, the descriptors for both the overall solution and the individual products or applications need to provide information about the resulting resources and relationships that will be established by installing a package, as well as describing the required resources and relationships. 
Requirement: Ability to match resulting resources of one package to requirements of another.   

Improved lifecycle management is an important value that the SDD contributes to this scenario, including coordination of install and rollback, as well as managing maintenance.
Requirement: undo support
Requirement: Ability to specify updates to an existing solution
 The dependency information establishes a good basis for impact assessment during incident management and change planning, and provides information for problem determination. The latter is assisted by providing traceability back into the development environment (build) as part of the descriptor.
Requirement: Traceability to build environment.   



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