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

WebTier: ScalableTier

WebVM: VMImage

LinuxOS: OperatingSystem

WebServer: ApacheWebServer

SugarCRM App: ApacheWebApp

PHP Module: ApacheMdule

dependsOn

DBTier: SingleNodeTier

DBVM: VMImage

LinuxOS: OperatingSystem

Database: MySQLDatabase

SugarCRM DB:MySQLDatabase

Content

SugarCRM: ApplicationContainer

ConnectsTo

Node Template name Node Type nameEach contained object represents the use of a hostedOn relation

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

Node Template

Redhat

Debian

OS.Type = LinuxLinux.distro = Debian

OS.Type = LinuxLinux.distro = RedHat

DebianPackages

RedHatPackages

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

8

Implementation Artifacts

Node Template

Redhat

Debian

OS.Type = LinuxLinux.distro = Debian

OS.Type = LinuxLinux.distro = RedHat

DebianPackages

RedHatPackages

The logic in an Implementation Artifact uses the information in the Deployment Artifacts to select and deploy the appropriate content

Node Type

Implementation Artifact

Deploy Operation

9

Node Instances

Node Template

Redhat

Debian

OS.Type = LinuxLinux.distro = Debian

OS.Type = LinuxLinux.distro = RedHat

DebianPackages

RedHatPackages

The resulting Node Instance is realized appropriately and contains appropriate concrete values for the deployment context

Node Type

Implementation Artifact

Deploy Operation

Node Instance

IPAddr=1.2.3.4Linux.distro=RedHat

…

10

Realizing a Service Template

Node TypesRelation Types

Default Deployment Artifacts and

Policies

Node TemplatesRelation Templates

Override defaultswith more specific parameterization

Node Templates realized as physical

Node Instances

Meta Model Service Template Service Deployment

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

User + assembly tool

Plan/Operation execution