Technical Background: the Solution Installation Schema

As referenced in the SDD TC Charter, the "installable unit" has been documented previously in a June 11, 2004 Member Submission to W3C. IBM and Novell submitted the two-part specification on royalty-free terms, naming InstallShield Software and Zero G Software are co-authors of the submission. IBM also issued "a call to the Industry to form and participate in a standards workgroup to formalize a standard to address the needs addressed by these specifications."

The Solution Installation Schema specification defines "the schema of an XML document describing the characteristics of an installable unit (IU) of software that are relevant for its deployment, configuration and maintenance. The XML schema is referred to as the Installable Unit Deployment Descriptor or IUDD schema."

The technical submission to W3C is published in two parts: Specification and XML schema of Installable Unit Deployment Descriptor and Specification and XML schema of Installable Unit Package Format. The purpose of the specification is "to define the schema of an XML document describing the characteristics of an installable unit (IU) of software that are relevant for its deployment, configuration and maintenance. The XML schema is referred to as the Installable Unit Deployment Descriptor or IUDD schema."

According to the Abstract; "The submitters and co-authors have collaborated to develop this specification as a basis for the description of software solution packaging for the purposes of deployment and maintenance of software artifacts on platforms... The benefits of this specification include: (1) the ability to describe software solution packages for both single and multi-platform heterogeneous environments; (2) the ability to describe software solution packages independent of the software installation technology or supplier; (3) the ability to provide information necessary to permit full lifecycle maintenance of software solutions..."

Bibliographic Information

• Installable Unit Deployment Descriptor Specification Version 1.0. W3C Member Submission 12-July-2004. Authors: Marcello Vitaletti (IBM Autonomic Computing Architecture, Editor), Christine Draper (IBM Autonomic Computing Architecture), Randy George (IBM Tivoli Architecture), Julia McCarthy (IBM SWG Componentization Architecture), Devin Poolman (Zero G Software), Tim Miller (Zero G Software), Art Middlekauff (InstallShield Software Corp), Carlos Montero-Luque (Novell). Version URL: http://www.w3.org/Submission/2004/SUBM-InstallableUnit-DD-20040712/. Latest version URL: http://www.w3.org/Submission/InstallableUnit-DD/. Copyright (c) 2004 InstallShield Software Corporation, International Business Machines, Inc., Novell, Inc. and Zero G Software, Inc., available under the W3C Document License.

• Installable Unit Package Format Specification Version 1.0. W3C Member Submission 12-July-2004. Authors: Heng Chu (IBM Software Strategy, Editor), Christine Draper (IBM Autonomic Computing Architecture), Marcello Vitaletti (IBM Autonomic Computing Architecture), Randy George (IBM Tivoli Architecture), Julia McCarthy (IBM SWG Componentization Architecture), Devin Poolman (Zero G Software), Tim Miller (Zero G Software), Art Middlekauff (InstallShield Software Corp), Carlos Montero-Luque (Novell). Version URL: http://www.w3.org/Submission/2004/SUBM-InstallableUnit-PF-20040712/. Latest version URL: http://www.w3.org/Submission/InstallableUnit-PF/.

Solution Installation Schema FAQ

A Solution Installation Schema FAQs document published by IBM in connection with the Member Submission of the to W3C clarifies the relationship of the Solution Installation to other technical approaches. Excerpted and adapted text from this FAQ document:

• Can the newly announced technology be used to package software in the Java development environment — files like EARs and JARs, etc.? Answer: Yes. The architecture is agnostic to the type of files one would like to package. You can use the Solution Installation technology to package Java files and install them on the target platforms.

• How does Solution Installation differ from RPM? Answer: Solution Installation can invoke any Native Installer like RPM. The Solution Installation technology has built-in actions for deploying native installers like RPM, InstallShield for Multi Platform (ISMP), and Microsoft installer (MSI).

• How does Solution Installation differ from Microsoft's DSI? Answer: Microsoft's Systems Definition Model (SDM) addresses the consistent packaging and distribution of software, as part of their Dynamic Systems Initiative (DSI). DSI today focuses on packaging and distributing the operating system and associated files, primarily in the windows environment. IBM's initiative is much broader than that. By embracing the industry standards where they exist (XML) for packaging the files, adopting a common set of specifications in collaboration with industry leaders like InstallShield, Novell and ZeroG, and intending to take the specifications to the appropriate standards bodies, IBM is making a call to the Industry to come and embrace the open-standard format for packaging & installation of components. In addition, IBM's efforts go beyond just the Operating systems as the target platform. The Solution Installation technology for Autonomic Computing is applicable for a variety of target platforms including operating systems, databases and application servers.

• How does Solution Installation differ from Shell scripts? Answer: Shell scripts can be used to deploy software, but are limited by their platform-specific nature and lack of encapsulation. Solution Installation allows you to create software packages which contain all of the files necessary to install and which declare the steps necessary to deploy in a platform-independent XML schema. In addition, Solution Installation provides an action for invoking external commands like a batch file or shell script.

Related Standards Activities

The Solution Deployment Descriptor (SDD) TC Call for Participation identifies six related standards activities with technology designs that may warrant close communication and liaisons.

• GGF Configuration Description, Deployment, and Lifecycle Management Working Group (CDDLM)

  The SDD TC's CFP says: "It is the hope of the TC that this work will be referenced as the software packaging schema in the GGF Configuration Description, Deployment, and Lifecycle Management (CDDLM) workgroup and the newly formed Application Contents Services (ACS) workgroup in updated versions of their specifications. Currently these workgroups are developing their own schema. Having this single industry wide schema would help ensure interoperability between Grid and non-Grid environments. The SDD TC will form liaison with these two workgroups to gather their requirements to ensure the SDD schema meets the needs of the Grid environment. The schema will incorporate needs that are broadly applicable to other parts of the industry and will provide extensibility to permit Grid specific extensions to be defined by the respective workgroup."

  The CDDLM-WG Charter specifies that the WG would address how to: describe configuration of services; deploy them on the Grid; and manage their deployment lifecycle (instantiate, initiate, start, stop, restart, etc.). The intent of the WG is to gather researchers, developers, practitioners, and theoreticians in the areas of services and application configuration, deployment, and deployment life-cycle management and to explore the community need for a broader effort in this area." An overview is provided in the CDDLM Foundation Document.

  Several draft specifications have been produced within the CDDLM-WG:

  • Configuration Description Language: The CDDLM Configuration Description Language (CDL) is an XML-based language for declarative description of system configuration that consists of components (deployment objects) defined in the CDDLM Component Model. The Deployment API uses a deployment descriptor in CDL in order to manage deployment lifecycle of systems. The language provides ways to describe properties (names, values, and types) of components including value references so that data can be assigned dynamically with preserving specified data dependencies.
  • Component Model: The CDDLM Component Model outlines the requirements for creating a deployment object responsible for the lifecycle of a deployed resource. Each deployment object is defined using the CDL language and mapped to its implementation The deployment object provides a WS-ResourceFramework (WSRF) compliant 'Component Endpoint' for lifecycle operations on the managed resource. The model also defines the rules for managing the interaction of objects with the CDDLM Deployment API in order to provide an aggregate, controllable lifecycle and the operations which enable this process.
  • Deployment API: The deployment API is the WSRF-based SOAP API for deploying applications to one or more target computers. Every set of computers to which systems can be deployed hosts one or more 'Portal Endpoints', WSRF resources which provide a means to create new 'System Endpoints'. A System Endpoint represents a deployed system. The caller can upload files to it, then submit a deployment descriptor for deployment. A System Endpoint is effectively a component in terms of the Component Model specification -it implements the properties and operations defined in that document. It also adds the ability to resolve references within the deployed system, enabling remote callers to examine the state of components with it..."

  IBM's Thomas Studwell (Senior Technical Staff Member for Autonomic Computing Technology at IBM) commented on IUDD in the standards arena: Next, 2005: "What we're doing next is, when we published the Solution Installation specifications last year, we made a call to the industry to form a work group to formalize this set of specifications (or to formalize a set of specifications that satisfy the same requirements). We've been working with a number of competitors and partners to kick off that work group. The key thing about this is that we're going to formalize a specification related to the deploying of software on multiple heterogeneous platforms and that specification is referenced in other works that are going on in the industry... The work we're doing is called the Installable Unit Deployment Descriptor. It can form a basis that will be referenced in a number of works. For example, GGF has a committee doing some work called the Configuration Description, Deployment and Lifecycle Management, CDDLM, which included a specification for describing the software that gets deployed on a system. This completely overlaps the work we're doing. We worked with that technical committee to have them agree that they would take a look at refactoring their specification to reference that aspect, which is to be standardized in this new work group. So we get a lot more mileage out of a specification and almost immediately achieve broader acceptance by having this single specification. And there are other workgroups that can reference this same type of information."

• GGF Application Contents Working Group (ACS)

  From the ACS-WG Overview: "In order to install and operate complex systems such as three-tier systems more efficiently and automatically, it is necessary to specify and manage, as a unit, a diverse set of application related information. The Application Contents Service (ACS) provides central management of such application information. Because application contents can consist of many different artifacts it is useful to be able to bundle them into a single archive to reduce operational overhead and minimize the possibility of inconsistency. The archive must be complete to exclude the instability and/or mismatch between the contents, but can make use of the reference to the external but stable storage to improve the efficiency in transport and storage..."

  An 'IUDD and AAF Overview' from the presentation "Installable Unit Deployment Descriptor," by Thomas Studwell addresses IUDD Principles: "For more complete autonomic functionality, the installation of OS and grid container must be automated and born from the network. Generic enough to apply to any computing container solution, Grid or otherwise. Must be able to deal with heterogeneous pools of hardware. An increasing percentage of software is aggregated as a component within a larger, integrated 'solution'. Grid applications are, by definition, an aggregated solution. Customers outages are often caused by their inability to rollout changes to applications because of the complex interdependencies with other application components and products. In order to enable autonomic deployment and configuration management, standardized formats are needed for declaring the structure of a solution and dependencies among its software components... IUDD in Relationship to ACS: Application Contents Service defines a repository interface (ARI) and format for contents of the respository (AAF). While the requirements for a grid application archive are unique to grid, the description of the contents are not. The description must define the application artifacts, dependencies, and deployment mechanisms. Add software life cycle management to the mix and you have the requirements for Installable Unit Deployment Descriptor (IUDD). Only requirements difference between AAF and IUDD are any wrappers needed for storage within ACS repository..."

• Open Services Gateway Initiative (OSGi)

  The SDD TC's CFP suggests that "aggregation of OSGi Bundles could be represented as Installable Units in an SDD representation. An alliance partnership does not exist today [with the OSGi Alliance], but should exist to provide the broadest level of industry acceptance of a single software installation and life-cycle management schema."

  According to website materials [2005-04] "the OSGi Alliance has developed many standard component interfaces that are available from common functions like HTTP servers, configuration, logging, security, user administration, XML, and many more. Plug compatible implementations of these components can be obtained from different vendors with different optimizations... Software component architectures address an increasing problem in software development: The large number of configurations that need to be developed and maintained. The standardized OSGi component architecture simplifies this configuration process significantly.

  In the OSGi Service Platform, bundles are the only entities for deploying Java-based applications. A bundle is comprised of Java classes and other resources which together can provide functions to end users and provide components called services to other bundles, called services. A bundle is deployed as a Java ARchive (JAR) file. JAR files are used to store applications and their resources in a standard ZIP-based file format..."

  OSGi has been implemented by several Fortune 100 companies, as well as in open source projects. The following OSGi Alliance member companies offer certified service plaforms: Atinav, Connected Systems, Espial, Gatespace Telematics, IBM, Mitsubishi Electric, ProSyst, Siemens VDO Automotive, Samsung, Sun. Other implementations include the open source Oscar Bundle Repository (OBR), Eclipse, and Knopflerfish.

• Distributed Management Task Force (DMTF)

  The SDD TC's CFP reads: "The SDD specification plans to rely on appropriate resource models for artifacts and hosting platforms, which DMTF develops. A strong liaison between the DMTF and the SDD technical committee will be necessary to ensure that the models contain the necessary elements required to achieve the goals of the SDD technical committee. In particular, we envision a strong alliance with the DMTF Application Workgroup as the SDD TC discovers new requirements for the expression of software artifacts and host platform models."

• OASIS Web Services Distributed Management (WSDM) TC

  The SDD TC's CFP reads: "There is a natural synergy with the WSDM TC as we see future implementations of installers and life-cycle managers moving to a Web services environment. The newly developed WSDM specification will form a solid base from which tools relying on SDD can perform software installation and life-cycle management. This technical committee will work closely with the WSDM TC in developing the requirements for management capabilities that need to be available to support software life-cycle management using SDDs. The product of the synergies between WSDM and SDD, i.e., the interfaces to the deployment engines, is intended to be standardized in a technical committee other than the SDD TC.

• OASIS Data Center Markup Language (DCML) TCs

  The SDD TC's CFP reads: "A liaison relationship needs to exist with the DCML Applications and Services TC in order to ensure that DCML documents can refer to or include SDD components where appropriate."

  The Data Center Markup Language( DCML), sponsored by the OASIS DCML Member Section, "provides the first specification that provides a structured model and encoding to describe, construct, replicate, and recover data center environments and elements. Using DCML, companies now have a standard method to enable data center automation, utility computing, and system management solutions to exchange information about the data center environment to make the vision of automated computing a reality."

From the SDD TC Charter and Call for Participation

Name and Abbreviation

OASIS Solution Deployment Descriptor (SDD) Technical Committee

Purpose

Deployment and lifecycle management of a set of interrelated software, hereinafter referred to as a solution, is a predominantly manual operation because there is currently no standardized way to express installation packaging for a multi-platform environment. Each hosting platform or operating system has its own format for expressing packaging of a single installable unit but, even on these homogeneous platforms, there is no standardized way to combine packages into a single aggregated unit without significant re-creation of the dependency and installation instructions. The problem is compounded when the solution is to be deployed across multiple, heterogeneous, platforms. A standard for describing the packaging and means to express dependencies and various lifecycle management operations within the package would alleviate these problems and subsequently enable automation of these highly manual and error-prone tasks. The purpose of this Technical Committee is to define XML schema to describe the characteristics of an installable unit (IU) of software that are relevant for core aspects of its deployment, configuration, and maintenance. This document will be referred to as the Solution Deployment Descriptor (SDD). SDDs, previously described as IUDDs, also are described in http://www.w3.org/Submission/2004/04/.

SDDs will benefit member companies and the industry in general by providing a consistent model and semantics to address the needs of all aspects of the IT industry dealing with software deployment, configuration, and lifecycle management. The benefits of this work include:

• ability to describe software solution packages for both single and multi-platform heterogeneous environments
• ability to describe software solution packages independent of the software installation technology or supplier
• ability to provide information necessary to permit full lifecycle maintenance of software solutions

Scope of the Technical Committee

The Technical Committee will define XML schema for SDDs, as well as a package format to associate SDDs, resource content, and software artifacts. SDDs are intended to describe the aggregation of installable units at all levels of the software stack. The resulting XML schema shall be partitioned to allow for layered implementations covering the range of applications from the definition of atomic units of software (Smallest Installable Units) to complex, multi-platform, heterogeneous solutions. A solution is any combination of products, components or application artifacts addressing a particular user requirement. This includes what would traditionally be referred to as a product offering (e.g., a database product), as well as a solution offering (e.g., a business integration platform comprising multiple integrated products), or a user application (e.g., a set of application artifacts like J2EE applications and database definitions). All the software constituents of a solution can be represented by a single SDD as a hierarchy of installable unit aggregates. In addition to the installable units that comprise a solution, the SDD also describes the requirements of targets onto which the solution can be deployed. There are a number of aspects of software deployment, configuration, and life-cycle management that are expressly outside of the scope of this technical committee. Specifically this committee will not specify host platform models, host platform management interfaces, or the design or implementations of deployment or life-cycle managers. Other standards efforts in other parts of the industry cover these aspects and other related standards activities may emerge. This technical committee may develop recommendations regarding these aspects but will feed these recommendations through appropriate liaison with the respective standards committees.

TC Deliverables

The TC's deliverables are:

• A set of specifications which include XML schemas for SDDs (Target completion: January 2006) Includes:
  • Core descriptors
  • Extensions for multi-platform solutions
• A software package format specification for SDDs and associated resources (Target completion: January 2006)
• A primer with real life examples to aid developers of SDDs and those who develop SDD tooling (Target completion: April 2006)
• Requirements to be forwarded to DMTF and other appropriate standards bodies (Target completion: April 2006)
• A document describing best practices in constructing SDDs for solution installation and life-cycle management (Target completion: April 2006)

IPR Mode

This TC will operate under the RF on Limited Terms mode

Audience for the Work

The anticipated audience includes:

• ISVs and independent developers who wish to create software packages for managed or unmanaged environments
• Internal corporate software development organizations
• IT staff who need to manage deployment and lifecycle within their infrastructure
• Software consumers who want reliable and predictable software installation and lifecycle
• Other domain specific standards bodies, such as GGF, who need a standardized way to express SDDs within their domain
• Developers of tooling which is used either for packaging of software for installation or used in the process of software life-cycle management

Language

The TC will conduct its business in English

First Meeting

The first meeting will be held by phone, June 1, Wednesday, 7:00 PM to 8:00 PM Eastern Time. Call in will be sponsored by IBM.

Ongoing Meeting Schedule

Face to face meetings will be held quarterly or sooner on an as-needed basis. Sponsors for face to face meetings will be solicited from participating members. Target date for first face to face meeting will be determined in the first meeting of the TC.

TC Proposers

• Joshua Allen, Zero G, joshua.allen@ZeroG.com
• Debra Danielson, Computer Associates, Debra.Danielson@ca.com
• Christine Draper, IBM, cdraper@us.ibm.com
• James Falkner, Sun Microsystems, james.falkner@sun.com
• Keisuke Fukui, Fujitsu, kfukui@labs.fujitsu.com
• Thomas Hennessy, HP, thomas.hennessy@hp.com
• Lance Johnson, Macrovision, ljohnson@macrovision.com
• Seiji Kobayashi, IBM, kobayas@jp.ibm.com
• Takashi Kojo, NEC, kojo@bk.jp.nec.com
• Art Middlekauff, Macrovision, amiddlekauff@macrovision.com
• Tim Miller, Zero G, Tim.Miller@ZeroG.com
• Dejan Milojicic, HP, dejan.milojicic@hp.com
• Carlos Montero-Luque, Novell, carlos@novell.com
• Rob Ross, Zero G, Rob.Ross@ZeroG.com
• Stuart Schaefer, Softricity, Sschaefer@softricity.com
• Igor Sedukhin, Computer Associates, Igor.Sedukhin@ca.com
• Thomas Studwell, IBM, studwell@us.ibm.com
• Jun Tatemura, NEC, tatemura@ccrl.sj.nec.com
• William Vambenepe, HP, vbp@hp.com

TC Convener

Catherine Pleil, IBM, pleil@us.ibm.com

Proposed TC Chair

Thomas Studwell, IBM, studwell@us.ibm.com

Early TC Documents

• [June 15, 2005] "SDD Use Cases." By James Falkner, Charlotte Allen, and Gowri Sivaprasad. Discussion draft ("informal document") provided by Sun Microsystems. 2005-06-15. 9 pages. Posted to the SDD TC list. [source PDF]
• [June 14, 2005] "SDD Use Cases." Posted by Christine Draper. June 14, 2005.

Principal References

• Announcement: Call for Participation: OASIS Solution Deployment Descriptor (SDD) Technical Committee.
• Announcement 2005-05-17: "OASIS Forms Committee to Standardize Software Installation Characteristics for Lifecycle Management. Computer Associates, Fujitsu, HP, IBM, NEC, Novell, Sun Microsystems, Zero G, and Others Collaborate on Packaging for Distributed Application Environments."
• Technical background: W3C Solution Installation Schema
• OASIS Solution Deployment Descriptor TC web site
• SDD TC Charter
• SDD TC Members
• SDD TC mailing list archive
• Related topics. References to standards activities in multiple related areas of computing resource management, including software solution installation and deployment technologies in a heterogeneous environment:
  • Overview
  • Specifications and Initiatives
    • Common Information Model (CIM)
    • Data Center Markup Language (DCML)
    • Distributed Management Task Force (DMTF)
    • GGF Application Contents Working Group (ACS)
    • GGF Configuration Description, Deployment, and Lifecycle Management Working Group (CDDLM)
    • GGF XML Configuration Description Language (CDL) Specification
    • OASIS Web Services Distributed Management (WSDM)
    • Open Services Gateway Initiative (OSGi)
    • Oscar Bundle Repository (OBR)
    • Simple Network Management Protocol (SNMP)
    • SNIA Storage Management Initiative Specification (SMI-S)
    • Systems Management Architecture for Server Hardware (SMASH)
    • Universal Plug and Play (UPnP)
    • W3C Open Software Description Specification (OSD)
    • W3C Solution Installation Schema
    • Web-Based Enterprise Management (WBEM) Initiative
    • Web Services for Management (WS-Management)
  • General: Articles, Papers, News