| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: SDD Use Cases
- From: Christine Draper <firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 14 Jun 2005 07:40:16 -0500
Here's my input regarding use cases for the SDD, as requested at the last meeting.
Product installation and componentization
A software vendor needs to package their product on (potentially multiple) physical media or for download by multiple customers. The product is typically shipped with an interactive install program to guide the user during install. The ability to specify optional content and the rules for how it may be selected (features, feature selection rules) is important. 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. Another driver is to address the limitations of existing install technology in areas such as:
- dependencies that span multiple hosting environments
- handling multiple software instances
- coordination of install/rollback
- integrity checking/lifecycle management based on dependencies
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.
Another common requirement is to support localization packages, which may be distributed separately.
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.
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. 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.
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.
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. 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
- Aggregation of consumption dependencies (e.g. diskspace)
- Matching dependencies in one package that are to be satisfied in another
- Mapping variables between different components
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. 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. 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.
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.
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.
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.
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. It may also involve installing multiple packages in order to satisfy 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.
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. 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.
Senior Technical Staff Member
IBM, 11501 Burnet Road, Mail Point 9037A013
Austin, TX 78758
1-512-838-3482 tl 678-3482
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]