1 / 10

SugarCRM Service Template

SugarCRM Service Template. 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

keefer
Download Presentation

SugarCRM Service Template

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 SugarCRMDB: MySQLDatabase Content SugarCRMApp: 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 Template Node Type Debian OS.Type = Linux Linux.distro = Debian Debian Packages

  9. Node Instances Implementation Artifact Deploy Operation Redhat OS.Type = Linux Linux.distro = RedHat RedHat Packages Node Template Node Type 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=1.2.3.4 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 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 Create custom Node Types and Relations added per application specific needs by extending existing types and specializing the semantics

More Related