1. SugarCRM Service Template

2. Realizing a Service Template
Given an application topology (e.g. SugarCRM)
Create a Node Template for each entity in the topology
Add the necessary Relation Templates to represent the node interdependencies
Associate the necessary Deployment Artifacts with each Node Template
To override Node Type defaults
To enable variation
Set and constrain variant attributes

3. SugarCRM Service Template
Each contained object represents the use of a hostedOn relation
Node Template name
Node Type name
SugarCRM: ApplicationContainer
WebTier: ScalableTier
DBTier: SingleNodeTier
WebVM: VMImage
DBVM: VMImage
LinuxOS: OperatingSystem
LinuxOS: OperatingSystem
WebServer:
ApacheWebServer
Database: MySQLDatabase
ConnectsTo
SugarCRM DB:
MySQLDatabase Content
SugarCRM App: ApacheWebApp
dependsOn
PHP Module: ApacheMdule

4. Deployment Variability
The purpose of templates is to express variability
We desire a single semantic representation of a deployment which can be used in multiple contexts (versus having to create one unique to each context and manage their equivalence over time)
With Service Topologies it is desirable to express two kinds of variability
Node attribute variability
Node instance variability

5. Node Attribute Variability
The Node Type defines the attributes which can be varied in a deployed Node Instance
The Node Template represents the specific binding of a set of values to an attribute required for deployment
The value (scalar or range) of a property
Deployment Artifacts and Policies to be applied in realizing the Node Instances (if different than the defaults specified in the Node Type)
Some attributes will be defined only at runtime, E.g. addresses, ports, etc.

6. Node Instance Variability
Given a Service Template it is desirable to allow different realizations of the Node Instances, thus generalizing the applicability, and hence, portability
E.g. we’d like to be able to deploy SugarCRM in RedHat or Debian Linux requiring Instance Variability at the OS and Component Node Templates
E.g. we’d like to be able to deploy SugarCRM in different clouds that vary across VM Image formats requiring Instance Variability at the VM Image Node Templates

7. Deployment Artifacts
Multiple Deployment Artifacts may be associated with a Node Template expressing how to realize a Node instance in different contexts
Context expressions match the applicable contexts
Redhat
OS.Type = Linux
Linux.distro = RedHat
RedHat
Packages
Node Template
Debian
OS.Type = Linux
Linux.distro = Debian
Debian
Packages

8. Implementation Artifacts
The logic in an Implementation Artifact uses the information in the Deployment Artifacts to select and deploy the appropriate content
Implementation Artifact
Deploy Operation
Redhat
OS.Type = Linux
Linux.distro = RedHat
RedHat
Packages
Node Type
Node Template
Debian
OS.Type = Linux
Linux.distro = Debian
Debian
Packages

9. Implementation Artifact
Node Instances
Implementation Artifact
Deploy Operation
Redhat
OS.Type = Linux
Linux.distro = RedHat
RedHat
Packages
Node Type
Node Template
Debian
OS.Type = Linux
Linux.distro = Debian
Debian
Packages
The resulting Node Instance is realized appropriately and contains appropriate concrete values for the deployment context
Node Instance
IPAddr=
Linux.distro=RedHat …

10. Realizing a Service Template
Meta Model
Service Template
Service Deployment
Node Types
Relation Types
Default Deployment Artifacts and Policies
Node Templates
Relation Templates
Override defaults
with more specific parameterization
Node Templates realized as physical Node Instances
User + assembly tool
Plan/
Operation execution
Create custom Node Types and Relations added per application specific needs by extending existing types and specializing the semantics
Complete service topology represented
Constrains the Node Type semantics to the specific set of values required for deployment
Node instances are generated from each Node Template with all template variables resolved with concrete non-conflicting values