SDD TutorialOASIS Symposium Solution Deployment Descriptor: An OASIS Standard for Deploying Composable Solutions OASIS Symposium 2008 Tutorial Presenters: Brent A. MillerRandy GeorgeIBM Corp. Chair, OASIS SDD TCOASIS SDD TC Co-Author: Julia McCarthy, IBM Corp., Secretary & Editor, OASIS SDD TC

SDD TutorialOASIS Symposium Tutorial Outline n Survey the use of the OASIS Solution Deployment Descriptor (SDD) standard l Review today’s deployment problems and how SDD can address many of these problems l Discuss deployment lifecycle management of composable software, including SOA solutions l Explore SDD details with realistic examples and use cases l Recognize the benefits of using SDD

SDD TutorialOASIS Symposium Intended Audience n Managers, architects, developers, practitioners, service personnel, IT administrators, solution aggregators, deployers and others who l Deploy software and/or l Package software to be deployed n Anyone interested in better understanding software deployment issues and solutions, in particular the emerging OASIS SDD standard

SDD TutorialOASIS Symposium Learning Objectives n Level-set today’s problems associated with software deployment n Understand how the OASIS SDD emerging standard helps to address these problems n Learn what is included within the SDD standard n Learn how to use the SDD standard l Examples with details showing SDD elements and attributes l Illustrative use case l How SDDs are produced and consumed, including tooling n Take away the benefits of using SDD

SDD TutorialOASIS Symposium Let’s Get Started n Today’s Deployment Problems n The OASIS SDD Standard n Examples with Details n Illustrative Use Case n Benefits of SDD n Resources

SDD TutorialOASIS Symposium Deployment Uncertainty, Lack of Control n Customers cannot adequately plan changes to their environments n Customers often rely on a lot of testing and “reverse engineering” n Customers must analyze individual deployment artifacts for the specific environments where they will be deployed n Once customers determine how to deploy the solution, they are uncertain about the impacts to the environment n Customers lose control of software deployment life cycle management l Installation, configuration, localization, maintenance and uninstallation Can I successfully deploy this software? If so, what will happen to my IT and business environment?

SDD TutorialOASIS Symposium Basic Deployment Knowledge Needed Package Identity What is this thing? What does it contain? Package Variability What parts need to be deployed? Requirements What is needed to deploy this package? What must be maintained for the lifetime of the deployment? Results What does this provide? What effect will this have on my environment? Software Package (logical, not physical) Software deployers need some basic information to adequately plan and execute deployments without disrupting IT & business environments

SDD TutorialOASIS Symposium Similar Knowledge Required for Change Management Processes Increasing emphasis on change control and change management  Standardized change management processes  Changes – simple or complex – need to be tested in pre-production environments  Changes – simple or complex – need to be assessed, approved, scheduled and implemented in production environments  Desire to leverage management tools and knowledge to automate change management process IT Infrastructure Systems Management Change Management Data CMDB ProvisioningMonitoring StorageNetwork Application Server … ApplicationServer … Change Management Process (example) Filter/ Prioritize Change Assess Change Impact Approve Change Verify Change Implement Change … Database

SDD TutorialOASIS Symposium Producing & Consuming this Knowledge Management Application Production VLAN Installation Program Development System Integrator n SOA enables already deployed services to be composed, but l Necessary deployment information (what is needed, what changes will occur in the deployment environment) is not standardized or externalized Intent and requirements known by software developers is not externalized during composition of solutions, deployment planning and deployment operations

SDD TutorialOASIS Symposium And the World is Getting More Complex Increasing emphasis on "solutions"  Combination of hardware and software components supporting a defined business process  Solutions must be installed, configured, deployed, monitored, operated, remediated, maintained,...  These tasks must be driven from a solution perspective  Post-purchase experience should not degenerate to multiple point products and solution components Holistic solution deployment inhibited by inability to aggregate heterogeneous components (from multiple suppliers) because deployment information not externalized or standardized

SDD TutorialOASIS Symposium Let’s Keep Moving n Today’s Deployment Problems n The OASIS SDD Standard n Examples with Details n Illustrative Use Case n Benefits of SDD n Resources

SDD TutorialOASIS Symposium SDD: Who 1 individual member Current Technical Committee Participants (includes voting members, members, observers)

SDD TutorialOASIS Symposium SDD: Status n Requirements, use cases, glossary complete n SDD and GGF-ACS Alignment l Both adopted SDD PackageDescriptor n Version 1.0 specification, schema Public Review January 18 – March 18, 2008 n Committee Specification April 2008 n OASIS Standard May 2008 n Expository documents available l Primer l Starter Profile l Examples New!

SDD TutorialOASIS Symposium SDD: Ecosystem n Tooling can help with producing and consuming SDDs n Tooling is being developed l Eclipse COSMOS Open-Source project l Tools to assist with SDD creation n Processing XML documents to accomplish their intent requires runtime code l Eclipse COSMOS Open-Source project l Runtime code foundation to assist with building deployment runtimes that process SDDs n Eclipse COSMOS project is not an OASIS effort but l Several COSMOS collaborators are also SDD participants l It is intended to ease and accelerate SDD standard adoption

SDD TutorialOASIS Symposium SDD: Scope of the Standard n SDD consists of declarative descriptive information l Not procedural; does not address APIs or protocols l Standardized, externalized deployment metadata n Useful across the software complexity spectrum l From single-target, single-artifact installation to distributed, complex solution lifecycle management l From software fixes to complete products n Two major portions of SDD are l Package Descriptor l Deployment Descriptor

SDD TutorialOASIS Symposium SDD: Package Descriptor n Package descriptor includes: l Identity l Content n Deployment descriptor n Artifacts n Documentation and readme files n License agreements n Etc. l Optional digital signature n SDD package descriptor adopted by Open Grid Forum Application Content Services (OGF-ACS) standard as their software packaging specification

SDD TutorialOASIS Symposium SDD: Package Descriptor XSD Standardized, Externalized Metadata

SDD TutorialOASIS Symposium Deployment Descriptor Design Pattern Based on “Content Unit / Hosting Environment” Pattern Database Create Table Application Server EJB D Operating System Software Product D Hardware Operating System D A package descriptor that declares the collection of content (files) A deployment descriptor that declares the deployment characteristics of the content unit A hosting environment or container that can accept an artifact An artifact that can be installed A D Content Unit D

SDD TutorialOASIS Symposium Package Identity Package Variability Requirements Results n Deployment descriptor includes: l Identity l Variability n Conditional content n Features n Parameters l Requirements n Environmental resource constraints n Pre-/co-/ex-requisites n Relationships n Conditional requirements l Results n Resources n Changes n Conditional results l Artifacts (files processed to accomplish a deployment operation) SDD: Deployment Descriptor Applies to Installation, Configuration and/or Localization Content

SDD TutorialOASIS Symposium SDD: Deployment Descriptor XSD Top-Level Elements Standardized, Externalized Metadata

SDD TutorialOASIS Symposium SDD: Deployment Descriptor XSD Identity Element Expanded Standardized, Externalized Metadata Identity describes the software package Human-consumable descriptions Name, version and other identifying characteristics of the software Same Identity element as Package Descriptor

SDD TutorialOASIS Symposium SDD: Deployment Descriptor XSD Variables Element Expanded Standardized, Externalized Metadata Variables and Parameters provide a way to obtain and derive values from Resource properties Deployment environment Human deployers Variables can then be used in SDD to influence the deployment process As input arguments to artifacts As values for resource constraints

SDD TutorialOASIS Symposium SDD: Deployment Descriptor XSD Requirements Element Expanded Requirements describe what is necessary for software to be successfully deployed Requirements for disk space, CPU capacity, etc. Requirements for pre-requisite software, configuration settings, etc. Standardized, Externalized Metadata

SDD TutorialOASIS Symposium SDD: Deployment Descriptor XSD ResultingResource Element Expanded Standardized, Externalized Metadata ResultingResource describes what will happen in the deployment environment after successful deployment, in terms of what resources will result in the deployment environment ResultingChange is similar; it describes what changes will result in the deployment environment

SDD TutorialOASIS Symposium SDD: Deployment Descriptor XSD Artifacts Element Expanded Standardized, Externalized Metadata Artifacts accomplish the deployment operations. The Artifact element describes artifacts, along with the inputs and outputs, including substitution values, used when processing those artifacts.

SDD TutorialOASIS Symposium SDD: Deployment Descriptor XSD Other Elements Described Standardized, Externalized Metadata Selectable Features are mechanisms to select content portions for a particular deployment Conditions enable flexible processing by declaring which aspects are applicable (or can be ignored) in certain circumstances Conditional content (determine if a content element is applicable) Conditional Variables (choose values) Conditional Features (determine when a feature is applicable) Conditional Resulting Resources (determine when a particular result is applicable) Conditional Completion Actions (determine if a completion action is necessary) Topology (logical) describes all solution resources relevant for deployment and their relationships Completion Actions such as restart and logoff can be specified as required before a deployment operation is considered complete

SDD TutorialOASIS Symposium SDD: Aggregation n Key SDD characteristic is ability to author SDDs with aggregation for composable solutions n Individual descriptors aggregated into composite SDD representing software solution, rather than individual components l SDD author for aggregated solution uses information for each individual software unit l Specify additional information that applies to the aggregated solution SDD 1 A1A1 D1D1 SDD 2 A2A2 D2D2 SDD 3 A3A3 D3D3 SDD Agg A Agg D Agg SDD 1 A1A1 D1D1 SDD 2 A2A2 D2D2 SDD 3 A3A3 D3D3

SDD TutorialOASIS Symposium SDD: More on Aggregation n SDD can consist of a descriptor that contains multiple content units n SDD can aggregate other packages, from other sources l Each component can be described and deployed individually by its own SDD l Individual SDDs can be aggregated into a new “entire solution” SDD l Aggregating Package Descriptor declares each Aggregated Package Descriptor n Packages can be Requisites (may be used to satisfy solution requirements) n Packages can be Solution Content (Referenced Packages) Can further constrain Requirements or control variability of Aggregated Packages n Aggregating Deployment Descriptor represents requirements, conditions, dependencies, constraints, features, results for entire solution l For example, component disk space requirements are additive; the aggregating SDD represents the total amount of disk space required for the solution l Requirements could specify software version that satisfies all components SDD aggregation supports straightforward generation of deployment information for composable solutions

SDD TutorialOASIS Symposium SDD: Profiles n SDD describes artifacts, deployment environment, etc. n At deployment time, specific, concrete information required l For example, operating system type, property names and values, etc. l This information is specific to deployment environment n Profiles map between metadata and deployment environment l Common “vocabulary” for SDD producer/consumer interoperability l Types, requirements, conditions, inputs/outputs, etc. for deployment environment n For example, disk space units (megabytes or blocks) n For example, processor type and speed l OASIS SDD TC publishes Starter Profile n Values sufficient to address published examples n Uses DMTF CIM resource model n Other Profiles can be created; these could use other resource models

SDD TutorialOASIS Symposium Let’s Dive in to Some Details n Today’s Deployment Problems n The OASIS SDD Standard n Examples with Details n Illustrative Use Case n Benefits of SDD n Resources

SDD TutorialOASIS Symposium SDD: Example 1 (Simple) The Deployment Descriptor: n Identifies the JRE 1.5 Package n Declares that the JRE deployment requires an AIX® Operating System l Must be at least version 5.1 l Versions 5.1 – 5.3 are “certified” (tested for compatibility) Declares that the JRE deployment requires byte blocks on /usr file system n Enables deployer to specify the logging level used during deployment l Default is “INFO” n Describes the deployment Artifact, an RPM file Server with OS Consider a simple software package for deploying a Java™ runtime environment (JRE)

SDD TutorialOASIS Symposium An instance of Java(TM) Runtime Environment, Standard Edition Version 5.0 is installed as a result of this deployment Java(TM) Runtime Environment, Standard Edition SDD Example 1: InstallableUnit The JRE InstallableUnit The InstallableUnit’s Identity provides details about the InstallableUnit – as a unit of packaging. Details are not shown here. The targetResourceRef attribute identifies the resource that is capable of processing the InstallableUnit’s artifact. The ResultingResource element describes the JRE resource as it will exist in the deployment environment after a successful deployment The artifact, requirement and variable definitions we have already seen are defined within the JRE.xml’s single InstallableUnit.

SDD TutorialOASIS Symposium Default logging level for logging messages coming from JRE Level.FINEST Level.FINER Level.FINE Level.CONFIG Level.SEVERE Level.INFO Level.WARNING SDD Example 1: Parameter A “Logging Level” string input parameter Every Variable can define a default value. StringParameters can define any number of valid values. A Variable’s id is used to refer to its value in variable expressions. The reference to a variable in a variable expression indicates how and when it plays a role in the deployment. A variable with no reference would be meaningless. This reference comes from the JRE’s Artifact Argument definition shown later. A Parameter is one of three types of Variables and a StringParameter is one of four types of Parameters. value="$(LoggingLevel)"

SDD TutorialOASIS Symposium SDD Example 1: Requirement Definition of JRE Artifact’s Disk Space Requirement The resourceRef attribute tells us that the constraints defined in the ResourceConstraint element all apply to the UsrFileSys resource. In this example, there is only a single constraint, a consumption constraint, defined on the UsrFileSys. The operation attribute tells us which artifacts are associated with this Requirement. The install operation is associated with the InstallArtifact. The property name comes from the Starter Profile. This JRE requires byte blocks on the /usr file system cim:CIM_FileSystem.AvailableSpace 2688

SDD TutorialOASIS Symposium SDD Example 1: Artifact JRE Artifact definition JRE_RPM is the id of the Content element in the package descriptor that contains metadata about the RPM file used to deploy the JRE. The element name InstallArtifact tells us that this artifact is used for install, i.e. creation, of a resource. The type attribute tells us that this artifact is an RPM file. In this example, the JRE RPM takes a single input argument named LogLevel. Its value is determined by the value of the variable LoggingLevel defined elsewhere in the SDD (shown earlier in this example).

SDD TutorialOASIS Symposium SDD: Example 2 (Composite) n Consider a software solution that consists of: l 3-tier J2EE application with user interface, backend business logic and database connection l Optional J2EE simple client n Requires JRE runtime with a minimum version l JRE runtime of version that satisfies the J2EE simple client requirement l Optional German and French language packs for the J2EE simple client n Each component can be described individually by its own SDD n Aggregated Package Descriptor represents all solution content l Aggregated Deployment Descriptor represents requirements, dependencies, conditions, constraints, selectable features and resulting changes that apply to the complete solution n SDD aggregation supports straightforward generation of deployment information for composable solutions Client Application App serverDatabase

SDD TutorialOASIS Symposium … SDD Example: CompositeInstallable CompositeInstallable of the CompositeApp SDD In the CompositeApp sample SDD, the single CompositeInstallable supports the install operation. The CompositeInstallable element organizes the SDD’s content for one operation. The SelectableContent includes Features that can be selected for this particular deployment (detailed later). The LocalizationContent (German and French language packages) would appear here

SDD TutorialOASIS Symposium Simple Application Simple Application Servlet Simple Application Database SDD Example: ContainedPackage CompositeInstallable of the CompositeApp SDD The Arguments shown here provide values for input parameters defined within the SimpleCompositeApp SDD. ContainedPackages define the Requirements, Inputs, Outputs and ResourceMappings relevant for using the aggregated SDD within the aggregation. The ResultingResourceMap elements identify the association between resources created by SimpleCompositeApp and resources defined in the CompositeApp's topology. The RequiredResourceMap elements identify the associations between resources required by SimpleCompositeApp and resources defined in the CompositeApp’s topology.

SDD TutorialOASIS Symposium Thick Client for Simple Application... SDD Example: Features CompositeApp Client Feature with Multiplicity The Multiplicity element indicates that the Feature can be selected multiple times resulting in the SimpleAppClient being deployed multiple times. Features identify the content elements that will be used if the feature is selected. In this example, the ContainedPackage for the SimpleAppClient is selected by the CompositeApp’s ClientFeature Feature.

SDD TutorialOASIS Symposium SDD Example 2: Topology Topology of the CompositeApp SDD The resource ids are used to refer to these resources in Requirements, Conditions, Variables and ResultingResources The composite application can be distributed across 4 servers; these are represented as 4 operating system resources in Topology.

SDD TutorialOASIS Symposium Let’s Keep Moving n Today’s Deployment Problems n The OASIS SDD Standard n Examples with Details n Illustrative Use Case n Benefits of SDD n Resources

SDD TutorialOASIS Symposium n Consider a software solution that consists of: l A Web server l An application server l A database l One or more applications n Each component can be described individually by its own SDD n Individual SDDs can be aggregated into a new “entire solution” SDD n Aggregated Package Descriptor represents all solution content l Aggregated Deployment Descriptor represents requirements, dependencies, conditions, constraints, selectable features and resulting changes that apply to the complete solution n For example, component disk space requirements are additive; the aggregated SDD represents the total amount of disk space required for the solution n Requirements could specify hosting environment software version that satisfies all components n SDD aggregation supports straightforward generation of deployment information for composable solutions Web server Applications App serverDatabase SDD: Illustrative Use Case Complex Aggregated Solution

SDD TutorialOASIS Symposium SDD: Illustrative Use Case SDD Agg A Agg D Agg SDD Database A DB D DB SDD AppServer A AS D AS SDD WebServer A WS D WS SDD Application A App2 D App2 SDD Application A App1 D App1 SDD Database A DB D DB SDD AppServer A AS D AS SDD WebServer A WS D WS SDD Application A App2 D App2 SDD Application A App1 D App1

SDD TutorialOASIS Symposium SDD: Illustrative Use Case SDDs define user inputs SDD Database A DB D DB SDD AppServer A AS D AS SDD WebServer A WS D WS SDD Application A App1 D App1 SDD Application A App2 D App2 DB Admin ID Web Admin ID

SDD TutorialOASIS Symposium SDD: Illustrative Use Case The Solution SDD maps solution inputs to inputs required by individual SDDs SDD Agg A Agg D Agg SDD WebServer A WS D WS SDD AppServer A AS D AS SDD Database A DB D DB SDD Application A App2 D App2 SDD Application A App1 D App1 DB Admin ID WebAdmin ID

SDD TutorialOASIS Symposium SDD: Illustrative Use Case SDDs define required and resulting resources SDD Database SDD AppServer SDD WebServer SDD Application 1 SDD Application 2 OS WebServer AppServer Database App2 App1

SDD TutorialOASIS Symposium SDD: Illustrative Use Case The Solution SDD maps solution resources to resources associated with individual SDDs SDD Agg SDD WebServer OS WebServer SDD AppServer OS WebServerAppServer SDD Database OS Database SDD Application 2 OS AppServerDatabaseApp2 SDD Application 1 OS AppServerApp1 Database OS Application OS SOA Application System 1: Applications System 2: Database

SDD TutorialOASIS Symposium SDD: Illustrative Use Case The Solution SDD maps solution resources to resources associated with individual SDDs SDD Agg SDD WebServer OS WebServer SDD Database OS Database SDD Application 2 OS AppServerDatabaseApp2 SDD Application 1 OS AppServerApp1 AppServer WebServer Database SDD AppServer OS WebServerAppServer SOA Application

SDD TutorialOASIS Symposium SDD: Illustrative Use Case The Solution SDD maps solution resources to resources associated with individual SDDs SDD Agg SDD WebServer OS WebServer SDD AppServer OS WebServerAppServer SDD Database OS Database SDD Application 2 OS AppServerDatabaseApp2 SDD Application 1 OS AppServerApp1 App2 SOA Application

SDD TutorialOASIS Symposium Let’s Wrap Up n Today’s Deployment Problems n The OASIS SDD Standard n Examples with Details n Illustrative Use Case n Benefits of SDD n Resources

SDD TutorialOASIS Symposium SDD: Quick Review n Standard for deployment lifecycle management l Standardized, externalized metadata for deployment l Captures deployment knowledge, removes the “brick wall” l Install, configure, fix/maintain, operate, localize, uninstall n Aggregation for complex, integrated solutions l Applies for SOA solutions n XML Schema l Package Descriptor l Deployment Descriptor n Useful across the software complexity spectrum l From single-target, single-artifact installation to distributed, complex solution lifecycle management Package Descriptor Identity Content descriptors (metadata) for: Deployment descriptor Artifacts Documentation and readme files License agreements and so on Optional digital signatures Deployment Descriptor Identity Variability Conditions Features Parameters Requirements Results Artifact inputs and outputs

SDD TutorialOASIS Symposium SDD: Benefits n SDD offers standardized way to externalize deployment information that facilitates: l Tools to generate deployment information l Runtime software that performs deployment operations l Interoperability! n One necessary and important piece of the interoperability puzzle n SDD enables aggregation and solution composition from multiple components l Including components from multiple suppliers n IT administrator perspective: SDD enables analysis of: l Proposed changes to the IT environment l Impacts to capacity and availability plans n Overall, SDD helps IT professionals build deployment plans, including scheduling and ordering changes

SDD TutorialOASIS Symposium SDD: Takeaway SDD is a valuable tool in the software deployment toolbox, both for “native” environments and SOA environments. SDD applies to a full range of software, from single-target, single-artifact deployments to complex, aggregated solution deployments in heterogeneous environments. Because SDD incorporates aggregation as an inherent construct for complex solution deployment, it participates in and complements service-oriented environments.

SDD TutorialOASIS Symposium Let’s Leave You With References n Today’s Deployment Problems n The OASIS SDD Standard n Examples with Details n Illustrative Use Case n Benefits of SDD n Resources

SDD TutorialOASIS Symposium SDD: Resources n OASIS SDD TC Public Web Page (includes access to Specification, Schema, Primer, Starter Profile): open.org/committees/tc_home.php?wg_abbrev=sddhttp:// open.org/committees/tc_home.php?wg_abbrev=sdd n Eclipse COSMOS Open Source project (includes planned SDD reference implementation): n Wikipedia entry for SDD: n IBM Autonomic Computing article: 03.ibm.com/autonomic/industry_sdd.htmlhttp://www- 03.ibm.com/autonomic/industry_sdd.html n IBM Systems Journal article that includes SDD:

SDD TutorialOASIS Symposium About the Authors Randy George is a Senior Technical Staff Member and Team Leader in IBM’s Tivoli Systems Division, Software Group. Randy is a long-time member and subject matter expert in the OASIS SDD Technical Committee. His previous assignments in IBM include [blah, blah] and he also [is a mediocre golfer/whatever]. He can be reached by at Julia McCarthy is a Senior Software Engineer in IBM’s Application and Integration Middleware Division, Software Group. Julia serves as Editor and Secretary for the OASIS SDD Technical Committee. Her previous assignments in IBM include everything from the bits and bytes of device driver development to the blue-sky of cross-organization strategy. Julia can be reached by at Brent A. Miller is a Senior Technical Staff Member and Chief Architect for Autonomic Computing in IBM’s Tivoli Systems Division, Software Group. Brent currently chairs the OASIS SDD Technical Committee. His previous assignments in IBM include printer development, network computing, mobile software and service provider solutions. He is the principal author of the book, Bluetooth Revealed. Brent can be reached by at

SDD TutorialOASIS Symposium Notices n Windows™ is a registered trademark of Microsoft Corporation in the United States and other countries. n Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. n IBM® and AIX® are registered trademarks of IBM in the United States, other countries, or both. n Java ™ is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. n Other company, product and service names may be trademarks or service marks of others.