Solution Deployment Descriptor: An OASIS Standard for Deploying Composable Solutions

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

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

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

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

5. Let’s Get Started • Today’s Deployment Problems • The OASIS SDD Standard • Examples with Details • Illustrative Use Case • Benefits of SDD • Resources

6. Deployment Uncertainty, Lack of Control Can I successfully deploy this software? If so, what will happen to my IT and business environment? • 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

7. 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 What is this thing? What does it contain? 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? Package Variability What parts need to be deployed? Software Package (logical, not physical)

8. Change Management Process (example) Filter/ Prioritize Change Assess Change Impact Approve Change Implement Change Verify Change … Change Management Data Systems Management CMDB Monitoring Provisioning IT Infrastructure … … Database Storage Application Server Network Application Server 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

9. System Integrator Management Application Production VLAN Installation Program Development Producing & Consuming this Knowledge • 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

10. 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, ... • These tasks must be driven from a solution perspective • Post-purchase experience should not degenerate to multiple point products and solution components

11. Let’s Keep Moving • Today’s Deployment Problems • The OASIS SDD Standard • Examples with Details • Illustrative Use Case • Benefits of SDD • Resources

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

13. www.oasis-open.org 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 New!

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

15. www.oasis-open.org 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

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

17. SDD: Package Descriptor XSD Standardized, Externalized Metadata

18. www.oasis-open.org Deployment Descriptor Design PatternBased on “Content Unit / Hosting Environment” Pattern Content Unit A deployment descriptor that declares the deployment characteristics ofthe content unit A packagedescriptor that declares the collection of content (files) Database D Create Table An artifact that can be installed D A ApplicationServer EJB D A hosting environment or container that can accept an artifact OperatingSystem SoftwareProduct D Hardware D Operating System

19. Results Package Identity Package Variability Requirements www.oasis-open.org SDD: Deployment Descriptor • 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) Applies to Installation, Configuration and/or Localization Content

20. SDD: Deployment Descriptor XSDTop-Level Elements Standardized, Externalized Metadata

21. SDD: Deployment Descriptor XSDIdentity 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

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

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

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

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

26. SDD: Deployment Descriptor XSDOther Elements Described • 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 Standardized, Externalized Metadata

27. SDD1 SDD1 D1 D1 A1 A1 SDD3 SDD3 D3 D3 A3 A3 SDD2 SDD2 D2 D2 A2 A2 www.oasis-open.org 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 SDDAgg DAgg AAgg

28. www.oasis-open.org 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 SDD aggregation supports straightforward generation of deployment information for composable solutions

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

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

31. www.oasis-open.org SDD: Example 1 (Simple) Consider a simple software package for deploying a Java™ runtime environment (JRE) The Deployment Descriptor: • Identifies the JRE 1.5 Package • Declares that the JRE deployment requiresan 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 Server with OS

32. www.oasis-open.org SDD Example 1: InstallableUnitThe JRE InstallableUnit The targetResourceRef attribute identifies the resource that is capable of processing the InstallableUnit’s artifact. • <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> The InstallableUnit’sIdentity provides details about the InstallableUnit – as a unit of packaging. Details are not shown here. 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.

33. www.oasis-open.org SDD Example 1: ParameterA “Logging Level” string input parameter A Variable’sid is used to refer to its value in variable expressions. A Parameter is one of three types of Variables and a StringParameter is one of four types of Parameters. • <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> Every Variable can define a default value. StringParameters can define any number of valid values. 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 ArtifactArgument definition shown later. value="$(LoggingLevel)"

34. www.oasis-open.org SDD Example 1: RequirementDefinition 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 InstallArtifact. <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 > 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 property name comes from the Starter Profile.

35. www.oasis-open.org SDD Example 1: ArtifactJRE Artifact definition 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. • <sdd-dd:Artifacts> • <sdd-dd:InstallArtifacttype="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. 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).

36. www.oasis-open.org SDD: Example 2 (Composite) Application • 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 • SDD aggregation supports straightforward generation of deployment information for composable solutions Client App server Database

37. www.oasis-open.org SDD Example: CompositeInstallableCompositeInstallable of the CompositeApp SDD The CompositeInstallable element organizes the SDD’s content for one operation. • <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> In the CompositeApp sample SDD, the single CompositeInstallable supports the install 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

38. www.oasis-open.org SDD Example: ContainedPackageCompositeInstallable of the CompositeApp SDD ContainedPackages define the Requirements, Inputs, Outputs and ResourceMappings relevant for using the aggregated SDD within the aggregation. • <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> The Arguments shown here provide values for input parameters defined within the SimpleCompositeApp SDD. The ResultingResourceMap elements identify the association between resources created bySimpleCompositeApp and resources defined in the CompositeApp's topology. The RequiredResourceMap elements identify the associations between resources required bySimpleCompositeApp and resources defined in the CompositeApp’s topology.

39. www.oasis-open.org SDD Example: FeaturesCompositeApp Client Feature with Multiplicity 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’sClientFeatureFeature. • <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> The Multiplicity element indicates that the Feature can be selected multiple times resulting in the SimpleAppClient being deployed multiple times.

40. www.oasis-open.org SDD Example 2: TopologyTopology of the CompositeApp SDD The composite application can be distributed across 4 servers; these are represented as 4 operating system resources in Topology. • <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> The resource ids are used to refer to these resources in Requirements, Conditions, Variables and ResultingResources

41. Let’s Keep Moving • Today’s Deployment Problems • The OASIS SDD Standard • Examples with Details • Illustrative Use Case • Benefits of SDD • Resources

42. www.oasis-open.org SDD: Illustrative Use CaseComplex Aggregated Solution Applications • 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 • SDD aggregation supports straightforward generation of deployment information for composable solutions Web server App server Database

43. SDDWebServer SDDWebServer DWS DWS AWS AWS SDDAppServer SDDAppServer DAS DAS AAS AAS SDDDatabase SDDDatabase DDB DDB ADB ADB SDDApplication SDDApplication SDDApplication SDDApplication DApp1 DApp2 DApp1 DApp2 AApp1 AApp1 AApp2 AApp2 www.oasis-open.org SDD: Illustrative Use Case SDDAgg DAgg AAgg

44. SDDWebServer DWS AWS SDDAppServer DAS AAS SDDDatabase DDB ADB SDDApplication SDDApplication DApp1 DApp2 AApp2 AApp1 www.oasis-open.org SDD: Illustrative Use CaseSDDs define user inputs WebAdmin ID Web Admin ID Web Admin ID DB Admin ID DB Admin ID Web Admin ID

45. SDDWebServer DWS AWS SDDAppServer DAS AAS SDDDatabase DDB ADB SDDApplication SDDApplication DApp1 DApp2 AApp1 AApp2 www.oasis-open.org SDD: Illustrative Use CaseThe Solution SDD maps solution inputs to inputs required by individual SDDs SDDAgg DAgg AAgg WebAdmin ID DB Admin ID

46. www.oasis-open.org SDD: Illustrative Use CaseSDDs define required and resulting resources SDDApplication 1 SDDWebServer OS WebServer OS AppServer App1 SDDDatabase OS Database SDDApplication 2 OS AppServer Database App2 SDDAppServer OS WebServer AppServer

47. SDDApplication 1 SDDDatabase SDDWebServer OS AppServer App1 OS Database OS WebServer SDDAppServer SDDApplication 2 OS WebServer AppServer OS AppServer Database App2 www.oasis-open.org SDD: Illustrative Use CaseThe Solution SDD maps solution resources to resources associated with individual SDDs SDDAgg SOA Application System 1: Applications Application OS Database OS System 2: Database

48. SDDWebServer OS WebServer SDDApplication 1 OS AppServer App1 SDDAppServer SDDApplication 2 OS WebServer AppServer OS AppServer Database App2 SDDDatabase OS Database www.oasis-open.org SDD: Illustrative Use CaseThe Solution SDD maps solution resources to resources associated with individual SDDs SDDAgg SOA Application AppServer WebServer Database

49. SDDWebServer OS WebServer SDDApplication 1 SDDAppServer OS AppServer App1 OS WebServer AppServer SDDApplication 2 OS AppServer Database App2 SDDDatabase OS Database www.oasis-open.org SDD: Illustrative Use CaseThe Solution SDD maps solution resources to resources associated with individual SDDs SDDAgg SOA Application App1 App2

50. Let’s Wrap Up • Today’s Deployment Problems • The OASIS SDD Standard • Examples with Details • Illustrative Use Case • Benefits of SDD • Resources