SDD TutorialOASIS Symposium 2008 1 Solution Deployment Descriptor: An OASIS Standard for Deploying Composable Solutions OASIS Symposium.

SDD Tutorial OASIS Symposium 2008 1

Solution Deployment Descriptor:Solution Deployment Descriptor:An OASIS Standard for An OASIS Standard for

Deploying Composable SolutionsDeploying Composable Solutions

www.oasis-open.org

OASIS Symposium 2008Tutorial

Presenters:Brent A. Miller Randy GeorgeIBM Corp. IBM Corp.Chair, OASIS SDD TC OASIS SDD TC

Co-Author:Julia McCarthy, IBM Corp.,

Secretary & Editor, OASIS SDD TC


Tutorial Outline Survey the use of the OASIS Solution

Deployment Descriptor (SDD) standard Review today’s deployment problems and how

SDD can address many of these problems Discuss deployment lifecycle management of

composable software, including SOA solutions Explore SDD details with realistic examples

and use cases Recognize the benefits of using SDD


Intended Audience Managers, architects, developers, practitioners,

service personnel, IT administrators, solution aggregators, deployers and others who

Deploy software and/or Package software to be deployed

Anyone interested in better understanding software deployment issues and solutions, in particular the emerging OASIS SDD standard


Learning Objectives Level-set today’s problems associated with

software deployment Understand how the OASIS SDD emerging

standard helps to address these problems Learn what is included within the SDD standard Learn how to use the SDD standard

Examples with details showing SDD elements and attributes

Illustrative use case How SDDs are produced and consumed, including tooling

Take away the benefits of using SDD


Let’s Get Started

Today’s Deployment Problems The OASIS SDD Standard Examples with Details Illustrative Use Case Benefits of SDD Resources


Deployment Uncertainty, Lack of Control

Customers cannot adequately plan changes to their environments

Customers often rely on a lot of testing and “reverse engineering”

Customers must analyze individual deployment artifacts for the specific environments where they will be deployed

Once customers determine how to deploy the solution, they are uncertain about the impacts to the environment

Customers lose control of software deployment life cycle management

Installation, configuration, localization, maintenance and uninstallation

Can I successfully deploy this software?If so, what will happen to my IT and business environment?


Basic Deployment Knowledge Needed

www.oasis-open.org

Package IdentityWhat is this thing?

What does it contain?

Package VariabilityWhat parts need to be

deployed?

RequirementsWhat is needed to deploy this package?

What must be maintained for the lifetime of the deployment?

ResultsWhat 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


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

SystemsManagement

ChangeManagement

DataCMDBCMDBProvisioningProvisioningMonitoringMonitoring

StorageStorage NetworkNetworkApplication Server

Application Server

… ApplicationApplication ServerServer…

Change Management Process (example)

Filter/Prioritize Change

Filter/Prioritize Change

Assess Change Impact

Assess Change Impact

Approve Change

Approve Change

Verify ChangeVerify

ChangeImplement

ChangeImplement

Change… …

DatabaseDatabase


Producing & Consuming this Knowledge

Management Application

Production VLANInstallation

ProgramDevelopment

System Integrator

SOA enables already deployed services to be composed, but 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


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


Let’s Keep Moving



SDD: Who

www.oasis-open.org

1 individual member

Current Technical Committee Participants(includes voting members, members, observers)


SDD: Status Requirements, use cases, glossary complete SDD and GGF-ACS Alignment

Both adopted SDD PackageDescriptor Version 1.0 specification, schema Public Review January

18 – March 18, 2008 Committee Specification April 2008 OASIS Standard May 2008 Expository documents available

Primer Starter Profile Examples

www.oasis-open.org

New!


SDD: Ecosystem

Tooling can help with producing and consuming SDDs Tooling is being developed

Eclipse COSMOS Open-Source project Tools to assist with SDD creation

Processing XML documents to accomplish their intent requires runtime code

Eclipse COSMOS Open-Source project Runtime code foundation to assist with building deployment runtimes

that process SDDs Eclipse COSMOS project is not an OASIS effort but

Several COSMOS collaborators are also SDD participants It is intended to ease and accelerate SDD standard adoption


SDD: Scope of the Standard SDD consists of declarative descriptive information

Not procedural; does not address APIs or protocols Standardized, externalized deployment metadata

Useful across the software complexity spectrum From single-target, single-artifact installation

to distributed, complex solution lifecycle management From software fixes to complete products

Two major portions of SDD are Package Descriptor Deployment Descriptor

www.oasis-open.org


SDD: Package Descriptor Package descriptor includes:

Identity Content

Deployment descriptor Artifacts Documentation and readme files License agreements Etc.

Optional digital signature SDD package descriptor adopted by Open Grid

Forum Application Content Services (OGF-ACS) standard as their software packaging specification

www.oasis-open.org


SDD: Package Descriptor XSD

Standardized,Externalized

Metadata


Deployment Descriptor Design PatternBased on “Content Unit / Hosting Environment” Pattern

www.oasis-open.org

DatabaseCreate Table

ApplicationServer

EJBD

OperatingSystem

SoftwareProduct

D

HardwareOperating SystemD

A package descriptor that declares the collection of content (files)

A package descriptor that declares the collection of content (files)

A deployment descriptor that declares the deployment characteristics ofthe content unit

A deployment descriptor that declares the deployment characteristics ofthe content unit

A hosting environment or container that can accept an artifact

A hosting environment or container that can accept an artifact

An artifact that can be installed

An artifact that can be installed

AD

Content UnitContent Unit

D


Package Identity

Package Variability

Requirements

Results

Deployment descriptor includes: Identity Variability

Conditional content Features Parameters

Requirements Environmental

resource constraints Pre-/co-/ex-requisites Relationships Conditional requirements

Results

Resources Changes Conditional results

Artifacts (files processed to accomplish a deployment operation)

SDD: Deployment Descriptor

www.oasis-open.org

Applies to Installation, Configuration and/or Localization Content


SDD: Deployment Descriptor XSDTop-Level Elements


Metadata


SDD: Deployment Descriptor XSDIdentity Element Expanded


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: Deployment Descriptor XSD Variables Element Expanded


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: 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.


Metadata


SDD: Deployment Descriptor XSD ResultingResource Element Expanded


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: Deployment Descriptor XSD Artifacts Element Expanded


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: Deployment Descriptor XSDOther Elements Described


Metadata

Selectable Features are mechanisms to select content portions for a particular deploymentConditions 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: Aggregation Key SDD characteristic is ability

to author SDDs with aggregation for composable solutions

Individual descriptors aggregated into composite SDD representing software solution, rather than individual components

SDD author for aggregated solution uses information for each individual software unit

Specify additional information that applies to the aggregated solution

www.oasis-open.org

SDD1

A1D1

SDD2

A2D2

SDD3

A3D3

SDDAgg

AAggDAgg

SDD1

A1D1

SDD2

A2D2

SDD3

A3D3


SDD: More on Aggregation SDD can consist of a descriptor that contains multiple content units SDD can aggregate other packages, from other sources

Each component can be described and deployed individually by its own SDD Individual SDDs can be aggregated into a new “entire solution” SDD Aggregating Package Descriptor declares each Aggregated Package Descriptor

Packages can be Requisites (may be used to satisfy solution requirements) Packages can be Solution Content (Referenced Packages)

• Can further constrain Requirements or control variability of Aggregated Packages

Aggregating Deployment Descriptor represents requirements, conditions, dependencies, constraints, features, results for entire solution

For example, component disk space requirements are additive; the aggregating SDD represents the total amount of disk space required for the solution

Requirements could specify software version that satisfies all components

www.oasis-open.org

SDD aggregation supports straightforward generation of deployment information for composable solutions


SDD: Profiles SDD describes artifacts, deployment environment, etc. At deployment time, specific, concrete information required

For example, operating system type, property names and values, etc. This information is specific to deployment environment

Profiles map between metadata and deployment environment Common “vocabulary” for SDD producer/consumer interoperability Types, requirements, conditions, inputs/outputs, etc. for deployment

environment For example, disk space units (megabytes or blocks) For example, processor type and speed

OASIS SDD TC publishes Starter Profile Values sufficient to address published examples Uses DMTF CIM resource model Other Profiles can be created; these could use other resource models


Let’s Dive in to Some Details



SDD: Example 1 (Simple)

The Deployment Descriptor: Identifies the JRE 1.5 Package Declares that the JRE deployment requires

an AIX® Operating System Must be at least version 5.1 Versions 5.1 – 5.3 are “certified” (tested for compatibility)

Declares that the JRE deployment requires 2688 512-byte blocks on /usr file system

Enables deployer to specify the logging level used during deployment

Default is “INFO” Describes the deployment Artifact, an RPM file

www.oasis-open.org

Server with OS

Consider a simple software package for deploying a Java™ runtime environment (JRE)


<sdd-dd:InstallableUnit id="ID000026" targetResourceRef="os"><sdd-dd:Identity softwareID="2000-123"> ... </sdd-dd:Identity><sdd-dd:Variables> ... </sdd-dd:Variables><sdd-dd:Requirements> ... </sdd-dd:Requirements><sdd-dd:ResultingResource resourceRef="JRE">

<sdd-dd:Description>An instance of Java(TM) Runtime Environment, Standard Edition Version 5.0 is installed as a result of this deployment </sdd-dd:Description><sdd-dd:Name>Java(TM) Runtime Environment, Standard Edition</sdd-dd:Name><sdd-dd:Version>1.5.0</sdd-dd:Version>

</sdd-dd:ResultingResource><sdd-dd:Artifacts> ... </sdd-dd:Artifacts>

</sdd-dd:InstallableUnit>

www.oasis-open.org

SDD Example 1: InstallableUnitThe 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-dd:Variables> <sdd-dd:Parameters> <sdd-dd:StringParameter sensitive="false" id="LoggingLevel" defaultValue="Level.INFO"> <sdd-dd:Description>Default logging level for logging messages coming from JRE</sdd-dd:Description> <sdd-dd:ValidValue>Level.FINEST</sdd-dd:ValidValue> <sdd-dd:ValidValue>Level.FINER</sdd-dd:ValidValue>

<sdd-dd:ValidValue>Level.FINE</sdd-dd:ValidValue> <sdd-dd:ValidValue>Level.CONFIG</sdd-dd:ValidValue> <sdd-dd:ValidValue>Level.SEVERE</sdd-dd:ValidValue> <sdd-dd:ValidValue>Level.INFO</sdd-dd:ValidValue> <sdd-dd:ValidValue>Level.WARNING</sdd-dd:ValidValue>

</sdd-dd:StringParameter> </sdd-dd:Parameters></sdd-dd:Variables>

www.oasis-open.org

SDD Example 1: ParameterA “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)"


www.oasis-open.org

SDD Example 1: RequirementDefinition 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.

<sdd-dd:Requirement id="UsrDiskSpace" operation="install"> <sdd-dd:Description>This JRE requires 2688 512-byte blocks on the /usr file system </sdd-dd:Description> <sdd-dd:ResourceConstraint id="UsrDiskSpaceRequirement“ resourceRef="UsrFilesys" > <sdd-dd:ConsumptionConstraint> <sdd-dd:PropertyName>cim:CIM_FileSystem.AvailableSpace </sdd-dd:PropertyName> <sdd-dd:Value unit="512-blocks">2688</sdd-dd:Value> </sdd-dd:ConsumptionConstraint> </sdd-dd:ResourceConstraint></sdd-dd:Requirement >


www.oasis-open.org

SDD Example 1: ArtifactJRE Artifact definition

<sdd-dd:Artifacts><sdd-dd:InstallArtifact type="rpm" contentRef="JRE_RPM">

<sdd-dd:Arguments><sdd-dd:Argument name="LogLevel" value="$(LoggingLevel)" />

</sdd-dd:Arguments></sdd-dd:InstallArtifact>

</sdd-dd:Artifacts>

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: Example 2 (Composite) Consider a software solution that consists of:

3-tier J2EE application with user interface, backend business logic and database connection

Optional J2EE simple client Requires JRE runtime with a minimum version

JRE runtime of version that satisfies the J2EE simple client requirement

Optional German and French language packs for the J2EE simple client Each component can be described individually by its own SDD Aggregated Package Descriptor represents all solution content

Aggregated Deployment Descriptor represents requirements, dependencies, conditions, constraints, selectable features and resulting changes that apply to the complete solution


www.oasis-open.org

Client

Application

App server Database


<sdd-dd:CompositeInstallable id="CompApp" operation="install"><sdd-dd:Identity softwareID="6000-123"> ... </sdd-dd:Identity><sdd-dd:Variables> ... </sdd-dd:Variables><sdd-dd:Languages> ... </sdd-dd:Languages><sdd-dd:BaseContent>

<sdd-dd:ContainedPackage id="SimpleCompositeApp_PKG" contentRef="SC_pkg">

... </sdd-dd:ContainedPackage>

</sdd-dd:BaseContent><sdd-dd:SelectableContent>

<sdd-dd:Features> … </sdd-dd:Features><sdd-dd:ContainedPackage id="SimpleAppClient_PKG" contentRef="SAC_pkg">

...</sdd-dd:ContainedPackage>

</sdd-dd:SelectableContent><sdd-dd:LocalizationContent> ... </sdd-dd:LocalizationContent>

</sdd-dd:CompositeInstallable>

www.oasis-open.orgSDD Example: CompositeInstallableCompositeInstallable 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-dd:ContainedPackage id="SimpleCompositeApp_PKG" contentRef="SC_pkg"><sdd-dd:Arguments>

<sdd-dd:Argument name="JDBC_User" value="$(DatabaseUserName)"/><sdd-dd:Argument name="JDBC_Password" value="$(DatabaseUserPassword)"/>

</sdd-dd:Arguments><sdd-dd:ResultingResourceMap resourceRef="SimpleJ2eeApp" foreignId="SimpleJ2eeApp">

<sdd-dd:Name>Simple Application</sdd-dd:Name></sdd-dd:ResultingResourceMap><sdd-dd:ResultingResourceMap resourceRef="SimpleJ2eeServlet" foreignId="SimpleJ2eeServlet">

<sdd-dd:Name>Simple Application Servlet</sdd-dd:Name></sdd-dd:ResultingResourceMap><sdd-dd:ResultingResourceMap resourceRef="SimpleDatabase" foreignId="SimpleDatabase">

<sdd-dd:Name>Simple Application Database</sdd-dd:Name></sdd-dd:ResultingResourceMap><sdd-dd:RequiredResourceMap resourceRef="J2eeServletServer" foreignId="J2eeServletServer"/><sdd-dd:RequiredResourceMap resourceRef="J2eeAppServer" foreignId="J2eeAppServer"/><sdd-dd:RequiredResourceMap resourceRef="DatabaseServer" foreignId="DatabaseServer"/>

</sdd-dd:ContainedPackage>

www.oasis-open.orgSDD Example: ContainedPackageCompositeInstallable 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-dd:SelectableContent><sdd-dd:Features>

<sdd-dd:Feature id="ClientFeature" addOn="true"><sdd-dd:DisplayName>Thick Client for Simple Application</sdd-dd:DisplayName><sdd-dd:Multiplicity multiplesAllowed="true"/><sdd-dd:ContentElement contentElementRef="SimpleAppClient_PKG" />

</sdd-dd:Feature></sdd-dd:Features><sdd-dd:ContainedPackage id="SimpleAppClient_PKG" contentRef="SAC_pkg"> ... </sdd-dd:ContainedPackage>

</sdd-dd:SelectableContent>

www.oasis-open.org

SDD Example: FeaturesCompositeApp 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-dd:Topology><sdd-dd:Resource id="servlet_os" type="cim:CIM_OperatingSystem">

<sdd-dd:HostedResource id="J2eeServletServer" type="cim:CIM_J2eeServer"><sdd-dd:HostedResource id="SimpleJ2eeServlet" type="cim:CIM_J2eeServlet"/></sdd-dd:HostedResource>

</sdd-dd:Resource><sdd-dd:Resource id="appServer_os" type="cim:CIM_OperatingSystem">

<sdd-dd:HostedResource id="J2eeAppServer" type="cim:CIM_J2eeServer"><sdd-dd:HostedResource id="SimpleJ2eeApp" type="cim:CIM_J2eeApplication"/></sdd-dd:HostedResource>

</sdd-dd:Resource><sdd-dd:Resource id="os" type="cim:CIM_OperatingSystem">

<sdd-dd:HostedResource id="DatabaseServer" type="cim:CIM_DatabaseSystem"><sdd-dd:HostedResource id="SimpleDatabase" type="cim:CIM_CommonDatabase"/></sdd-dd:HostedResource>

</sdd-dd:Resource><sdd-dd:Resource id="Client_OS" type="cim:CIM_OperatingSystem">

<sdd-dd:HostedResource id="JRE" type="cim:CIM_InstalledProduct"/><sdd-dd:HostedResource id="SimpleAppClient" type="CIM_Application"/>

</sdd-dd:Resource></sdd-dd:Topology>

www.oasis-open.org

SDD Example 2: TopologyTopology 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.


Let’s Keep Moving



Consider a software solution that consists of: A Web server An application server A database One or more applications

Each component can be described individually by its own SDD Individual SDDs can be aggregated into a new “entire solution” SDD Aggregated Package Descriptor represents all solution content

Aggregated Deployment Descriptor represents requirements, dependencies, conditions, constraints, selectable features and resulting changes that apply to the complete solution

For example, component disk space requirements are additive; the aggregated SDD represents the total amount of disk space required for the solution

Requirements could specify hosting environment software version that satisfies all components


www.oasis-open.org

Web server

Applications

App server Database

SDD: Illustrative Use CaseComplex Aggregated Solution


SDD: Illustrative Use Casewww.oasis-open.org

SDDAgg

AAggDAgg

SDDDatabase

ADBDDB

SDDAppServer

AASDAS

SDDWebServer

AWSDWS

SDDApplication

AApp2DApp2

SDDApplication

AApp1DApp1

SDDDatabase

ADBDDB

SDDAppServer

AASDAS

SDDWebServer

AWSDWS

SDDApplication

AApp2DApp2

SDDApplication

AApp1DApp1


www.oasis-open.org

SDD: Illustrative Use CaseSDDs define user inputs

SDDDatabase

ADBDDB

SDDAppServer

AASDAS

SDDWebServer

AWSDWS

SDDApplication

AApp1DApp1

SDDApplication

AApp2DApp2

DB Admin ID

DB Admin ID

Web Admin ID

WebAdmin ID

Web Admin ID

Web Admin ID


www.oasis-open.org

SDD: Illustrative Use CaseThe Solution SDD maps solution inputs to inputs required by individual SDDs

SDDAgg

AAggDAgg

SDDWebServer

AWSDWS

SDDAppServer

AASDAS

SDDDatabase

ADBDDB

SDDApplication

AApp2DApp2

SDDApplication

AApp1DApp1

DB Admin ID

WebAdmin ID


www.oasis-open.org

SDD: Illustrative Use CaseSDDs define required and resulting resources

SDDDatabase

SDDAppServer

SDDWebServerSDDApplication 1

SDDApplication 2

OS

OS

OS

OS

OS

WebServer

WebServer AppServer

AppServer

AppServer

Database

Database App2

App1


www.oasis-open.org

SDD: Illustrative Use CaseThe Solution SDD maps solution resources to resources associated with individual SDDs

SDDAgg

SDDWebServer

OS WebServer

SDDAppServer

OS WebServer AppServer

SDDDatabase

OS Database

SDDApplication 2

OS AppServer Database App2

SDDApplication 1

OS AppServer App1

Database OSApplication OS

SOA Application

System 1:Applications

System 2:Database


www.oasis-open.org


SDDAgg

SDDWebServer

OS WebServer

SDDDatabase

OS Database

SDDApplication 2


SDDApplication 1

OS AppServer App1

AppServer

WebServer

Database

SDDAppServer


SOA Application


www.oasis-open.org


SDDAgg

SDDWebServer

OS WebServer

SDDAppServer


SDDDatabase

OS Database

SDDApplication 2


SDDApplication 1

OS AppServer App1

App1

App2

SOA Application


Let’s Wrap Up



SDD: Quick Review Standard for deployment lifecycle management

Standardized, externalized metadata for deployment Captures deployment knowledge, removes the “brick wall” Install, configure, fix/maintain, operate, localize, uninstall

Aggregation for complex, integrated solutions Applies for SOA solutions

XML Schema Package Descriptor Deployment Descriptor

Useful across the software complexity spectrum From single-target, single-artifact installation to distributed, complex

solution lifecycle management

www.oasis-open.org

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 ConditionsFeaturesParameters

Requirements

Results

Artifact inputs and outputs


SDD: Benefits SDD offers standardized way to externalize deployment information

that facilitates: Tools to generate deployment information Runtime software that performs deployment operations Interoperability!

One necessary and important piece of the interoperability puzzle

SDD enables aggregation and solution composition from multiple components

Including components from multiple suppliers IT administrator perspective: SDD enables analysis of:

Proposed changes to the IT environment Impacts to capacity and availability plans

Overall, SDD helps IT professionals build deployment plans, including scheduling and ordering changes

www.oasis-open.org


SDD: Takeaway

www.oasis-open.org

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.


Let’s Leave You With References



SDD: Resources OASIS SDD TC Public Web Page (includes access to Specification,

Schema, Primer, Starter Profile): http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdd

Eclipse COSMOS Open Source project (includes planned SDD reference implementation): http://www.eclipse.org/cosmos/

Wikipedia entry for SDD: http://en.wikipedia.org/wiki/Solution_Deployment_Descriptor

IBM Autonomic Computing article:

http://www-03.ibm.com/autonomic/industry_sdd.html IBM Systems Journal article that includes SDD:

http://portal.acm.org/citation.cfm?id=1331914.1331928&coll=&dl=GUIDE

www.oasis-open.org


About the Authors

www.oasis-open.org

Randy Georgeis 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 e-mail at [email protected]

Julia McCarthyis 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 e-mail at [email protected]

Brent A. Milleris 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 e-mail at [email protected]


Notices Windows™ is a registered trademark of Microsoft Corporation

in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the

U.S. and other countries. IBM® and AIX® are registered trademarks of IBM in the

United States, other countries, or both. Java ™ is a trademark or registered trademark of Sun

Microsystems, Inc. in the United States and other countries. Other company, product and service names may be

trademarks or service marks of others.

www.oasis-open.org

SDD TutorialOASIS Symposium 2008 1 Solution Deployment Descriptor: An OASIS Standard for Deploying Composable Solutions OASIS Symposium.

Documents