www oasisopen org Solution Deployment Descriptor An OASIS

www. oasis-open. org Solution Deployment Descriptor: An OASIS Standard for Deploying Composable Solutions OASIS Symposium 2008 Tutorial Presenters: Brent A. Miller IBM Corp. Chair, OASIS SDD TC Randy George IBM Corp. OASIS SDD TC Co-Author: Julia Mc. Carthy, IBM Corp. , Secretary & Editor, OASIS SDD TC SDD Tutorial OASIS Symposium 2008 1

Tutorial Outline n Survey the use of the OASIS Solution Deployment Descriptor (SDD) standard l l SDD Tutorial 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 OASIS Symposium 2008 2

Intended Audience n Managers, architects, developers, practitioners, service personnel, IT administrators, solution aggregators, deployers and others who l l n 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 SDD Tutorial OASIS Symposium 2008 3

Learning Objectives n n 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 l l l n 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 Tutorial OASIS Symposium 2008 4

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

Deployment Uncertainty, Lack of Control Can I successfully deploy this software? If so, what will happen to my IT and business environment? n n n 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 l SDD Tutorial Installation, configuration, localization, maintenance and uninstallation OASIS Symposium 2008 6

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

Similar Knowledge Required for Change Management Processes Change Management Process (example) Filter/ Prioritize Change Systems Management Storage Assess Change Impact … Approve Change Monitoring Application Server Implement Change Provisioning … Network Application Database Verify Change CMDB … Change Management Data IT Infrastructure Server 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 SDD Tutorial OASIS Symposium 2008 8

Producing & Consuming this Knowledge 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 System Integrato r Development Management Application Installation Program Production VLAN Intent and requirements known by software developers is not externalized during composition of solutions, deployment planning and deployment operations SDD Tutorial OASIS Symposium 2008 9

And the World is Getting More Complex Holistic solution deployment inhibited by inability to aggregate heterogeneous components (from multiple suppliers) because deployment information not externalized or standardized 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, . . . § SDD These tasks must be driven from a solution perspective Tutorial OASIS Symposium 2008 10

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

www. oasis-open. org SDD: Who Current Technical Committee Participants (includes voting members, observers) 1 individual member SDD Tutorial OASIS Symposium 2008 12

www. oasis-open. org SDD: Status n Requirements, use cases, glossary complete n SDD and GGF-ACS Alignment l n n Both adopted SDD Package. Descriptor Version 1. 0 specification, schema Public Review January 18 – March 18, 2008 Committee Specification April 2008 OASIS Standard May 2008 New! Expository documents available l l l Primer Starter Profile Examples SDD Tutorial OASIS Symposium 2008 13

SDD: Ecosystem n n Tooling can help with producing and consuming SDDs Tooling is being developed l l n Processing XML documents to accomplish their intent requires runtime code l l n Eclipse COSMOS Open-Source project Tools to assist with SDD creation 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 l l Several COSMOS collaborators are also SDD participants It is intended to ease and accelerate SDD standard adoption SDD Tutorial OASIS Symposium 2008 14

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

www. oasis-open. org SDD: Package Descriptor n Package descriptor includes: l l Identity Content n n n l n 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 SDD Tutorial OASIS Symposium 2008 16

SDD: Package Descriptor XSD Standardized, Externalized Metadata SDD Tutorial OASIS Symposium 2008 17

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

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

SDD: Deployment Descriptor XSD Top-Level Elements Standardized, Externalized Metadata SDD Tutorial OASIS Symposium 2008 20

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 Tutorial OASIS Symposium 2008 21

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 Tutorial OASIS Symposium 2008 22

SDD: Deployment Descriptor XSD Requirements Element Expanded Standardized, Externalized Metadata 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. SDD Tutorial OASIS Symposium 2008 23

SDD: Deployment Descriptor XSD Resulting. Resource Element Expanded Standardized, Externalized Metadata Resulting. Resource describes what will happen in the deployment environment after successful deployment, in terms of what resources will result in the deployment environment Resulting. Change is similar; it describes what changes will result in the deployment environment SDD Tutorial OASIS Symposium 2008 24

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 Tutorial OASIS Symposium 2008 25

SDD: Deployment Descriptor XSD Other Elements Described Standardized, Externalized Metadata SDD Tutorial 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 OASIS Symposium 2008 26

www. oasis-open. org SDD: Aggregation n n SDD 1 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 l l SDD author for aggregated solution uses information for each individual software unit Specify additional information that applies to the aggregated solution SDD Tutorial OASIS Symposium 2008 SDD 2 A 1 A 2 D 2 SDD 3 A 3 SDDAgg AAgg SDD 1 A 1 SDD 2 A 2 SDD 3 A 3 27

www. oasis-open. org SDD: More on Aggregation n n SDD can consist of a descriptor that contains multiple content units SDD can aggregate other packages, from other sources l Each component can be described and deployed individually by its own SDD Individual SDDs can be aggregated into a new “entire solution” SDD l Aggregating Package Descriptor declares each Aggregated Package Descriptor l 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 l 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 SDD aggregation supports straightforward generation of deployment information for composable solutions SDD Tutorial OASIS Symposium 2008 28

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

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

www. oasis-open. org SDD: Example 1 (Simple) Consider a simple software package for deploying a Java™ runtime environment (JRE) The Deployment Descriptor: n n Identifies the JRE 1. 5 Package Declares that the JRE deployment requires an AIX® Operating System l l n n 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 l n Server with OS Default is “INFO” Describes the deployment Artifact, an RPM file SDD Tutorial OASIS Symposium 2008 31

www. oasis-open. org SDD Example 1: Installable. Unit The JRE Installable. Unit The target. Resource. Ref attribute identifies the resource that is capable of processing the Installable. Unit’s artifact. target. Resource. Ref="os"> <sdd-dd: Installable. Unit id="ID 000026" <sdd-dd: Identity software. ID="2000 -123">. . . </sdd-dd: Identity> <sdd-dd: Variables>. . . </sdd-dd: Variables> The Installable. Unit’s Identity provides <sdd-dd: Requirements>. . . </sdd-dd: Requirements> details about the Installable. Unit – as a unit of packaging. Details are not shown here. <sdd-dd: Resulting. Resource resource. Ref="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: Resulting. Resource> <sdd-dd: Artifacts>. . . </sdd-dd: Artifacts> The Resulting. Resource element describes the The artifact, requirement and variable definitions </sdd-dd: Installable. Unit> JRE resource as it will exist in the deployment we have already seen are defined within the JRE. xml’s single Installable. Unit. SDD Tutorial environment after a successful deployment OASIS Symposium 2008 32

www. oasis-open. org SDD Example 1: Parameter A “Logging Level” string input parameter A Parameter is one of three types of Variables and a String. Parameter is one of four types of Parameters. A Variable’s id is used to refer to its value in variable expressions. <sdd-dd: Variables> <sdd-dd: Parameters> <sdd-dd: String. Parameter sensitive="false" id="Logging. Level" default. Value="Level. INFO" > <sdd-dd: Description>Default logging level for logging messages coming from JRE</sdd-dd: Description> <sdd-dd: Valid. Value>Level. FINEST</sdd-dd: Valid. Value> <sdd-dd: Valid. Value>Level. FINER</sdd-dd: Valid. Value> Every Variable can define a <sdd-dd: Valid. Value>Level. FINE</sdd-dd: Valid. Value> default value. <sdd-dd: Valid. Value>Level. CONFIG</sdd-dd: Valid. Value> <sdd-dd: Valid. Value>Level. SEVERE</sdd-dd: Valid. Value> String. Parameters can define <sdd-dd: Valid. Value>Level. INFO</sdd-dd: Valid. Value> any number of valid values. <sdd-dd: Valid. Value>Level. WARNING</sdd-dd: Valid. Value> </sdd-dd: String. Parameter> </sdd-dd: Parameters> </sdd-dd: Variables> The reference to a variable in a variable expression value="$(Logging. Level)" SDD Tutorial 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. OASIS Symposium 2008 33

www. oasis-open. org SDD Example 1: Requirement Definition of JRE Artifact’s Disk Space Requirement The operation attribute tells us which artifacts are associated with this Requirement. The install operation is associated with the Install. Artifact. <sdd-dd: Requirement id="Usr. Disk. Space" operation="install"> <sdd-dd: Description>This JRE requires 2688 512 -byte blocks on the /usr file system </sdd-dd: Description> <sdd-dd: Resource. Constraint id="Usr. Disk. Space. Requirement“ resource. Ref="Usr. Filesys" > <sdd-dd: Consumption. Constraint> <sdd-dd: Property. Name>cim: CIM_File. System. Available. Space </sdd-dd: Property. Name> <sdd-dd: Value unit="512 -blocks">2688</sdd-dd: Value> </sdd-dd: Consumption. Constraint> </sdd-dd: Resource. Constraint> </sdd-dd: Requirement > The property name comes from the Starter Profile. SDD Tutorial The resource. Ref attribute tells us that the constraints defined in the Resource. Constraint element all apply to the Usr. File. Sys resource. In this example, there is only a single constraint, a consumption constraint, defined on the Usr. File. Sys. OASIS Symposium 2008 34

www. oasis-open. org SDD Example 1: Artifact JRE Artifact definition The element name Install. Artifact 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. <sdd-dd: Artifacts> <sdd-dd: Install. Artifact type="rpm" content. Ref="JRE_RPM"> <sdd-dd: Arguments> <sdd-dd: Argument name="Log. Level" value="$(Logging. Level)" /> </sdd-dd: Arguments> JRE_RPM is the id of the Content </sdd-dd: Install. Artifact> element in the package descriptor that </sdd-dd: Artifacts> contains metadata about the RPM file In this example, the JRE RPM takes a single input argument named Log. Level. Its value is determined by the value of the variable Logging. Level defined elsewhere in the SDD (shown earlier in this example). SDD Tutorial OASIS Symposium 2008 used to deploy the JRE. 35

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

SDD Example: Composite. Installable www. oasis-open. org Composite. Installable of the Composite. App SDD The Composite. Installable element organizes the SDD’s content for <sdd-dd: Composite. Installable id="Comp. App" operation="install"> one operation. <sdd-dd: Identity software. ID="6000 -123">. . . </sdd-dd: Identity> <sdd-dd: Variables>. . . </sdd-dd: Variables> <sdd-dd: Languages>. . . </sdd-dd: Languages> <sdd-dd: Base. Content> <sdd-dd: Contained. Package id="Simple. Composite. App_PKG" content. Ref="SC_pkg"> In the Composite. App sample SDD, the. . . single Composite. Installable supports the install operation. </sdd-dd: Contained. Package> </sdd-dd: Base. Content> The Selectable. Content includes Features <sdd-dd: Selectable. Content> that can be selected for this particular <sdd-dd: Features> … </sdd-dd: Features> deployment (detailed later). <sdd-dd: Contained. Package id="Simple. App. Client_PKG" content. Ref="SAC_pkg"> The Localization. Content (German and French. . . language packages) would appear here </sdd-dd: Contained. Package> </sdd-dd: Selectable. Content> <sdd-dd: Localization. Content>. . . </sdd-dd: Localization. Content> SDD Tutorial OASIS Symposium 2008 37 </sdd-dd: Composite. Installable>

SDD Example: Contained. Package www. oasis-open. org Composite. Installable of the Composite. App SDD Contained. Packages define the <sdd-dd: Contained. Package id="Simple. Composite. App_PKG" Requirements, Inputs, Outputs and content. Ref="SC_pkg"> Resource. Mappings relevant for <sdd-dd: Arguments> using the aggregated SDD within <sdd-dd: Argument name="JDBC_User" value="$(Database. User. Name)"/> the aggregation. <sdd-dd: Argument name="JDBC_Password" value="$(Database. User. Password)"/> The Arguments shown here </sdd-dd: Arguments> provide values for input <sdd-dd: Resulting. Resource. Map resource. Ref="Simple. J 2 ee. App" parameters defined within the Simple. Composite. App foreign. Id="Simple. J 2 ee. App"> SDD. <sdd-dd: Name>Simple Application</sdd-dd: Name> </sdd-dd: Resulting. Resource. Map> <sdd-dd: Resulting. Resource. Map resource. Ref="Simple. J 2 ee. Servlet" foreign. Id="Simple. J 2 ee. Servlet"> <sdd-dd: Name>Simple Application Servlet</sdd-dd: Name> The Resulting. Resource. Map elements identify </sdd-dd: Resulting. Resource. Map> the association between resources created by <sdd-dd: Resulting. Resource. Map resource. Ref="Simple. Database" Simple. Composite. App and resources foreign. Id="Simple. Database"> defined in the Composite. App's topology. <sdd-dd: Name>Simple Application Database</sdd-dd: Name> The Required. Resource. Map elements identify </sdd-dd: Resulting. Resource. Map> the associations between resources required by Simple. Composite. App and resources <sdd-dd: Required. Resource. Map resource. Ref="J 2 ee. Servlet. Server" defined in the Composite. App’s topology. foreign. Id="J 2 ee. Servlet. Server"/> SDD Tutorial OASIS Symposium 2008 38 <sdd-dd: Required. Resource. Map resource. Ref="J 2 ee. App. Server"

SDD Example: Features Composite. App Client Feature with Multiplicity www. oasis-open. org Features identify the content elements that will be used if the feature is selected. In this example, the Contained. Package for the Simple. App. Client is selected by the Composite. App’s add. On="true"> Client. Feature. <sdd-dd: Selectable. Content> <sdd-dd: Features> <sdd-dd: Feature id="Client. Feature" <sdd-dd: Display. Name>Thick Client for Simple Application</sdd-dd: Display. Name> <sdd-dd: Multiplicity multiples. Allowed="true"/> <sdd-dd: Content. Element content. Element. Ref="Simple. App. Client_PKG" /> </sdd-dd: Features> <sdd-dd: Contained. Package id="Simple. App. Client_PKG" The Multiplicity element indicates that the content. Ref="SAC_pkg"> Feature can be selected multiple times. . . resulting in the Simple. App. Client </sdd-dd: Contained. Package> being deployed multiple times. </sdd-dd: Selectable. Content> SDD Tutorial OASIS Symposium 2008 39

SDD Example 2: Topology www. oasis-open. org Topology of the Composite. App SDD The composite application can be distributed across 4 servers; these are represented as 4 operating <sdd-dd: Topology> system resources in Topology. <sdd-dd: Resource id="servlet_os" type="cim: CIM_Operating. System"> <sdd-dd: Hosted. Resource id="J 2 ee. Servlet. Server" type="cim: CIM_J 2 ee. Server"> <sdd-dd: Hosted. Resource id="Simple. J 2 ee. Servlet" type="cim: CIM_J 2 ee. Servlet"/> </sdd-dd: Hosted. Resource> The resource ids are </sdd-dd: Resource> used to refer to these <sdd-dd: Resource id="app. Server_os" type="cim: CIM_Operating. System"> resources in <sdd-dd: Hosted. Resource id="J 2 ee. App. Server" type="cim: CIM_J 2 ee. Server"> Requirements, <sdd-dd: Hosted. Resource id="Simple. J 2 ee. App" type="cim: CIM_J 2 ee. Application"/> Conditions, Variables </sdd-dd: Hosted. Resource> and Resulting. Resources </sdd-dd: Resource> <sdd-dd: Resource id="os" type="cim: CIM_Operating. System"> <sdd-dd: Hosted. Resource id="Database. Server" type="cim: CIM_Database. System"> <sdd-dd: Hosted. Resource id="Simple. Database" type="cim: CIM_Common. Database"/> </sdd-dd: Hosted. Resource> </sdd-dd: Resource> <sdd-dd: Resource id="Client_OS" type="cim: CIM_Operating. System"> <sdd-dd: Hosted. Resource id="JRE" type="cim: CIM_Installed. Product"/> <sdd-dd: Hosted. Resource id="Simple. App. Client" type="CIM_Application"/> </sdd-dd: Resource> </sdd-dd: Topology> SDD Tutorial OASIS Symposium 2008 40

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

www. oasis-open. org SDD: Illustrative Use Case Complex Aggregated Solution n Consider a software solution that consists of: l l n n n A Web server An application server A database One or more applications Web server App server Database 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 l Aggregated Deployment Descriptor represents requirements, dependencies, conditions, constraints, selectable features and resulting changes that apply to the complete solution n Applications 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 SDD aggregation supports straightforward generation of deployment information for composable solutions SDD Tutorial OASIS Symposium 2008 42

www. oasis-open. org SDD: Illustrative Use Case SDDWeb. Server DWS AWS SDDAgg SDDApp. Server DAS AAS SDDDatabase DDB ADB SDDApplication DAgg AAgg SDDWeb. Server DWS AWS SDDDatabase DDB ADB SDDApp. Server DAS AAS SDDApplication DApp 2 AApp 1 DApp 1 SDD Tutorial OASIS Symposium 2008 43

www. oasis-open. org SDD: Illustrative Use Case SDDs define user inputs Web. Admin ID SDDWeb. Server DWS Web Admin ID AWS DApp 1 AApp 1 Web Admin ID DB Admin ID SDDDatabase DDB SDD Tutorial SDDApplication SDDApp. Server DAS ADB DB Admin ID SDDApplication Web Admin ID DApp 2 AApp 2 OASIS Symposium 2008 44

www. oasis-open. org SDD: Illustrative Use Case The Solution SDD maps solution inputs to inputs required by individual SDDs SDDWeb. Server SDDAgg AAgg AWS DWS SDDApp. Server Web. Admin ID DAS AAS DB Admin ID SDD Tutorial SDDApplication DApp 1 AApp 1 DApp 2 AApp 2 OASIS Symposium 2008 SDDDatabase DDB ADB 45

www. oasis-open. org SDD: Illustrative Use Case SDDs define required and resulting resources SDDApplication 1 SDDWeb. Server OS OS Web. Server App 1 SDDDatabase OS SDDApplication 2 Database OS App. Server Database App 2 SDDApp. Server OS SDD Tutorial Web. Server App. Server OASIS Symposium 2008 46

www. oasis-open. org SDD: Illustrative Use Case The Solution SDD maps solution resources to resources associated with individual SDDs SDDAgg System 1: Applications Application OS Database OS SDDApplication 1 SDDWeb. Server OS OS Web. Server App. Server SDDApp. Server OS SDD Tutorial Web. Server SOA Application App. Server SDDDatabase OS App 1 System 2: Database SDDApplication 2 OS App. Server OASIS Symposium 2008 Database App 2 47

www. oasis-open. org SDD: Illustrative Use Case The Solution SDD maps solution resources to resources associated with individual SDDs SDDAgg SDDWeb. Server OS SOA Application Web. Server App. Server SDDApplication 1 OS OS Web. Server SDDApplication 2 App. Server OS SDDDatabase SDD Tutorial App 1 SDDApp. Server Web. Server OS App. Server Database App 2 Database OASIS Symposium 2008 48

www. oasis-open. org SDD: Illustrative Use Case The Solution SDD maps solution resources to resources associated with individual SDDs SDDWeb. Server OS SDDAgg SOA Application Web. Server App 1 SDDApp. Server OS Web. Server SDDApplication 1 App 2 OS App. Server App 1 SDDApplication 2 OS App. Server Database App 2 SDDDatabase OS SDD Tutorial Database OASIS Symposium 2008 49

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

www. oasis-open. org SDD: Quick Review n Standard for deployment lifecycle management l l l n Aggregation for complex, integrated solutions l n Applies for SOA solutions XML Schema l l n Standardized, externalized metadata for deployment Captures deployment knowledge, removes the “brick wall” Install, configure, fix/maintain, operate, localize, uninstall Package Descriptor Deployment Descriptor 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 Useful across the software complexity spectrum l From single-target, single-artifact installation to distributed, complex solution lifecycle management SDD Tutorial OASIS Symposium 2008 51

www. oasis-open. org SDD: Benefits n SDD offers standardized way to externalize deployment information that facilitates: l l l Tools to generate deployment information Runtime software that performs deployment operations Interoperability! n n SDD enables aggregation and solution composition from multiple components l n Including components from multiple suppliers IT administrator perspective: SDD enables analysis of: l l n One necessary and important piece of the interoperability puzzle 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 SDD Tutorial OASIS Symposium 2008 52

www. oasis-open. org 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, singleartifact 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 SDD Tutorial OASIS Symposium 2008 service-oriented environments. 53

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

www. oasis-open. org SDD: Resources n n OASIS SDD TC Public Web Page (includes access to Specification, Schema, Primer, Starter Profile): http: //www. oasisopen. 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 n IBM Systems Journal article that includes SDD: http: //portal. acm. org/citation. cfm? id=1331914. 1331928&coll=&dl=GUIDE SDD Tutorial OASIS Symposium 2008 55

www. oasis-open. org 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 e-mail at randyg@us. ibm. com SDD Tutorial Julia Mc. Carthy 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 crossorganization strategy. Julia can be reached by email at julia@us. ibm. com OASIS Symposium 2008 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 e-mail at 56

www. oasis-open. org Notices n n n 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. SDD Tutorial OASIS Symposium 2008 57