Cloud Services An Introduction to TOSCA Topology and

(Cloud) Services: An Introduction to TOSCA (Topology and Orchestration Specification for Cloud Services) Gerd Breiter Frank Leymann Simon Moser Thomas Spatzier

Terminology 2

Caution: Terminology n SOA and Systems Management… n …use the terms “service”, “composition”, “orchestration”, … differently n …at least with different foci

Terminology: Service n “Service” means different things n In SOA: Any kind of (reasonably coarse-grained) application function n n Interesting discussion: what is an application? It depends on the domain… In Systems Management: Any kind of resource and appropriate actions required to support business with IT n Interesting discussion: systems management is an application too. Thus, the SOA notion of service applies too – but that might get confusing at this point in time

Terminology: Orchestration n “Orchestration” means different things n n n In SOA: the aggregation of application functions into higher level business functions In Systems Management: the proper sequencing of individual management tasks to manage complex IT artifacts YES: both can be done with the same underlying technology (BPMN, BPEL, …) but the focus is very different

Terminology: Composition n “Composition” means different things n n In SOA/SCA: the aggregation of application functions and their relations for the purpose of proper deployment In Systems Management: the “parts tree” of complex IT artifacts for the purpose of setting up the artifacts correctly, as well as the processes for ensuring the appropriate continuous management of the artifacts

Conceptual Overview 7

Imagine… n n …that you have a nice application that you want to be able to be hosted in different clouds Why do you want that? n n Because you don’t want to be locked into the platform of a single cloud provider, or Because you start in your own private cloud and want to be able to move it to public cloud or to some community cloud or to hybrid cloud

Thus, the Scenario is: Moving Cloud Applications 5. Manage 2. Use 3. Move (i. e. Provision) 4. Use 1. Provision & Manage Cloud Provider A Cloud Provider B 9

What are the Technical Problems? n No interoperable description exists of what your application is and what it requires n Virtual images do not suffice at all n n They are “just” snapshots of the actual state of your application Another provider might not have a clue how to install, deploy, run & manage your application n Deep detailed skills about the application and its underlying stack is needed that “arbitrary” providers typically don’t have

What Is “(Cloud) Service Template” All About? n Node n Types Rel. ship n Types Group n Template Plans n the building blocks of your application the management functions these building blocks offer to be managed the relations between these building blocks Collection of node types and relationship types (for reuse purposes) the procedures to follow in order to manage your application as a whole Topology (Template) (Cloud) Service Template A new language (“metamodel”) to specify

Graphical Representation Service Template Relationship Template Properties type for Interfaces Node Type Topology Template type for Node Template Properties Relationship Type Plans Group Template 12

…and More Colorful… Topology Plans 13

…and With Angular Brackets… <Service. Template …> <Extensions/>? <Import />* <Types/>? ( <Topology. Template/> | <Topology. Template. Reference/> )? <Node. Types/>? <Relationship. Types/>? <Plans/>? </Service. Template> 14

Example: High Level View BPEL Files Node Template uses WSDL Files implemented by deployed. On Relationship Template Web. Sphere Process Server requires EJBs deployed. On Web. Sphere Cell …and this is a bit more clomplex… requires DB 2 Server 15

Example: Web. Sphere Cell Refined Web. Sphere Cell DB 2 Server IHS Node Properties, e. g. : WAS install location, Profile name, Node name WAS ND Deploy. Mgr Node 1. . * WAS ND Managed Node 1. . * DB 2 Server DB 2 Database Instance Cluster exists "cluster" "database" Application Server Instance Properties, e. g. : ports, servername, weight 16

Example: Overall Topology Template BPEL Files WSDL Files Web. Sphere Process Server EJBs Web. Sphere Cell 1. . * IHS Node WAS ND Deploy. Mgr Node WAS ND Managed Node 1. . * Cluster DB 2 Server Application Server Instance DB 2 Database Instance 17

Example: Amazon BPEL Files uses WSDL Files implemented by deployed. On Web. Sphere Process Server Amazon requires EJBs deployed. On Web. Sphere Cell requires DB 2 Server 18

…Which is the “Interoperable Service Templates” Scenario (see later) BPEL Files WSDL Files Web. Sphere Process Server EJBs Amazon Web. Sphere Cell DB 2 Server 19

Example: Amazon – Refined Scenario WSDL Files Implemented by On Premise EJBs deployed. On Web. Sphere Cell requires DB 2 Server (Application Data) uses BPEL Files deployed. On Web. Sphere Process Server Amazon requires Web. Sphere Cell requires DB 2 Server (WAS Data) 20

Example: Amazon – Refined Scenario (Details) n n n The Web Services required by the BPEL processes are hosted on premise The EJBs (e. g. ) implementing the Web Services are deployed on Web. Sphere hosted on premise The application data of the WS/EJBs are stored in DB 2 on premise n This ensures compliance with data privacy/confidentiality rules WSDL Files Implemented by On Premise uses n n Process Server etc is installed and managed at Amazon’s EC 2 The corresponding middleware is provided as AMIs The process models are deployed on Process Server maintains state data in DB 2 also running in EC 2 BPEL Files deployed. On EJBs deployed. On Web. Sphere Cell requires DB 2 Server (Application Data) Web. Sphere Process Server Amazon requires Web. Sphere Cell requires DB 2 Server (WAS Data) 21

Example: Reusing Existing Services n „somewhere 1“ BPEL Files uses „somewhere 2“ WS 2 … WSn bound to WS 1 WSDL Files deployed. On Web. Sphere Process Server n n requires Web. Sphere Cell requires n Only the processes and required middleware is managed on a “known” cloud The Web Services needed by the BPEL processes are reused “wherever” they are The existing Web Services are bound to the BPEL process by the established mechanisms Specifying binding details can be part of the build plan of the application’s Service Template (. ste) DB 2 Server „somewheren“ 22

Example: SAP BPEL Files uses WSDL Files implemented by deployed. On SAP Workflow SAP requires EJB deployed. On Netweaver requires Oracle 23

Example: Microsoft BPEL Files uses WSDL Files deployed. On implemented by deployed. On Biz. Talk Azure requires. Net Assemblies deployed. On . Net requires SQL Server 24

Example: Different Hosters of a Particular Application BPEL Files uses WSDL Files implemented by deployed. On IBM deployed. On SAP Workflow requires EJB deployed. On AT&T T-Systems. . . Netweaver requires Oracle 25

…Which is the “Market for Cloud Applications” Scenario (see later) BPEL Files uses WSDL Files implemented by deployed. On IBM AT&T deployed. On SAP Workflow T-Systems. . . requires EJB deployed. On Netweaver requires Oracle 26

Sample: Websphere Management Plans Initial Provisioning Provision Dmgr Provision Managed Node Provision IHS Node Add Nodes Remove Nodes Provision Managed Node Unfederate Node Deploy Monitoring Agent (Dmgr) Deploy Mon. Agent (IHS) Deploy Mon. Agent Reconfigure Webserver Enable Admin Security Federate Node Start IHS Federate Node Remove Mon. Agent Start Dmgr Create Cluster Members Configure Webserver Create Cluster Members Start Cluster Deprovision Managed Node 27

How Plans and Nodes Fit Together … … Create Cluster n Task of a plan refers to interface of a topology node n Topology node specifies all interfaces offered to manage it Interface is bound to a concrete implementation …refers to… Web. Sphere Cell … n …bound to… n Script --------------------------------- n n Implementation already available at providers side, or Implementation is copied from somewhere, or A standardized Cloud Interface (Iaas, Paa. S, Saa. S) is used, or. . . 28

A Caveat! n n n The “(Cloud) Service Template” spec is not (!) about standardizing topologies and plans for a series of concrete products The “(Cloud) Service Template” spec is (!) about standardizing the language that can be used to precisely describe topologies and plans for concrete products Various products (i. e. their topologies and plans) can be standardized base on that at a later time n By various domain experts, vendors, …

Baseline n TOSCA is modular and composable n It does not reinvent the wheel, i. e. it uses existing standards wherever possible n E. g. WSDL, BPMN, OVF, …

Motivation 31

Scenario 1: Mobility of Cloud Applications 6. Use 2. Use 3. Want Use Cloud Provider A Cloud Provider B Service Instance 1. Build 5. Build 4. Move Service Template 32

Important Note n n n TOSCA deals with interoperability of Service Templates here I. e. portability of the ingredients of an IT Service (especially the code artifacts) is not addressed by TOSCA Similarly, mobility of data used by a corresponding service instance is not in the scope of TOSCA

Scenario 2: Creating a Market For Cloud Applications 3. Browse and Select Service Catalog 5. Use 4. Provision Service Instance 2. Publish Service Template 1. Create 34

Scenario 3: Interoperable Service Compositions Cloud Provider A Realized By Implemented As Cloud Provider B Cloud Provider C 35

Scenario 4: Using OVF Packages <ovf: Envelope. . . > <ovf: Virtual. System. Collection. . . > <ovf: Virtual. System. . . >. . . <ovf: Product. Section. . . >. . . </ovf: Virtual. System> <ovf: Virtual. System. . . >. . . </ovf: Virtual. System>. . . Note: only subtree of service definition relates to OVF, other subtrees/nodes can point to shared resources (e. g. DB 2, …) </ovf: Virtual. System. Collection> </ovf: Envelope> 36

Refined View How. . . BPEL The business processes of the application (BPEL, BPMN, Human Tasks, …) EAR (EJBs, …) The business logic of the application, e. g. EJBs, JSPs, JPEG, … OVF OVF The images of the middleware (DB 2, Websphere, …) required to run the application ------- With. . . ------- ---Scripts Workflows (Existing) scripts used by task of plans to manage the cloud application (Existing) workflows used by subprocess-tasks of plans 37

Cloud Management & Orchestration Components in a composite service can come from one Cloud, multiple Clouds, or can be non-Cloud resources (e. g. existing company LDAP or private DBs). Management Scope Service Saa. S Application App. Srv Paa. S DB Saa. S offerings exist (e. g Google Apps), but as standalone offerings restricted to the Saa. S layer. Paa. S offerings exist (e. g. Micro. Soft Azure), but are restricted solely to the Paa. S layer. Interfaces between Paa. S and Iaa. S starting to evolve. Server Storage Iaa. S Cloud Iaa. S is maturing. Evolution of standards like OVF or defacto standards like EC 2 or S 3 enable growth of ecosystems. Management & Orchestration Deploy, Start, Decommission Stop, Resize Management Plans covering the complete service life cylce. Management Functionality 38

Service Template: Specification Overview 39

Ingredients of a Service Template Relationship Template Properties type for Interfaces Node Type Topology Template type for Node Template Properties Relationship Type Plans Group Template 40

Structure of. ste Document <Service. Template id="ID" name="string" target. Namespace="any. URI"> <Extensions/>? Topology Template Relationship Types <Import />* <Types/>? ( | Node Types <Topology. Template/> <Topology. Template. Reference/> )? Plans <Node. Types/>? <Relationship. Types/>? <Plans/>? </Service. Template> 41

Node Types: Overall Structure <Node. Types>? <Node. Type id="ID" name="string">+ <Node. Type. Properties element="Qname"? type="QName"? />? <Interfaces/>? <Deployment. Artifacts/>? Node Types Node Type Interface <Instance. States/>? Properties <Derived. From node. Type. Ref="QName"/>? <Policies/>? </Node. Type> </Node. Types> 42

Interfaces of Node Types Interfaces <Interfaces>? <Interface>+ ( <WSDL port. Type="QName“ operation="NCName">+ | <REST method="GET | PUT | POST | DELETE" request. URI="any. URI" request. Payload="QName"? response. Payload="QName"? >+ | <Operation name="NCame">+ <Input. Parameters>? <Input. Paramter name="string" type="string" required="yes|no">+ </Input. Parameters> <Output. Parameters>? <Output. Paramter name="string" type="string">+ </Output. Parameters> <Implementation implementation. ID="any. URI"? language="any. URI"? >+ ( <Implementation. Proper>? code </Implementation. Proper> | <Implementation. Reference ref="any. URI"/>? ) <Implementation> </Implementations> </Operation> ) </Interface> </Interfaces> 43

Deployment Artfacts of Node Types <Deployment. Artifacts>? <Deployment. Artifact name="string" type="any. URI">+ artifact specific content </Deployment. Artifact> </Deployment. Artifacts> 44

Policies of Node Types <Policies>? <Policy name="string" type="any. URI">+ policy specific content </Policy> </Policies> 45

Example: Node Types <Service. Template name="my. Service" target. Namespace="http: //www. ibm. com/sample"> <Node. Types> <Node. Type name="Project"> <documentation xml: lang="EN"> A reusable definition of a node type supporting the creation of new projects. </documentation> <Node. Type. Properties element="Project. Properties"/> <Instance. States> <Instance. State state="www. my. com/active"/> <Instance. State state="www. my. com/on. Halt"/> </Instance. States>. . . <Interfaces> <Interface> <Operation name="Create. Project"> <Input. Parameters> <Input. Paramter name="Project. Name" type="string"/> <Input. Paramter name="Owner" type="string"/> <Input. Paramter name="Account. ID" type="string"/> </Input. Parameters> <Implementation>. . . </Implementation> </Implementations> </Operation> </Interfaces> </Node. Types> </Service. Template>>

Relationship Types <Relationship. Types> <Relationship. Type. Properties element="QName"? type="QName"? />? <Instance. States>? <Instance. State state="any. URI">+ </Instance. States> Relationship Types Relationship Type Properties <Relationship. Type id="ID" name="string" semantics="any. URI" cascading. Deletion="yes|no">+ </Relationship. Type> </Relationship. Types> 47

Example: Relationship Types <Relationship. Types> <Relationship. Type name="process. Deployed. On" semantics="www. my. com/Rel. Semantics/proc. Deployed. On" cascading. Deletion="yes"> <Relationship. Type. Properties element="Process. Deployed. On. Properties"/> <Instance. States> <Instance. State state="www. my. com/successfully. Deployed"/> <Instance. State state="www. my. com/failed"/> </Instance. States> </Relationship. Types>

Topology Template <Topology. Template id="ID" name="string"? > ( <Node. Template/> | <Relationship. Template/> | <Group. Template/> )+ </Topology. Template>^ Relationship Template …type for… Node Template …type for… Group Template 49

Topology Template (cont. ) <Topology. Template id="ID" name="NCName"> ( <Node. Template id="ID" name="string" node. Type="QName" min. Instances="int"? max. Instances="int|string"? >+ <Property. Defaults>? XMLDocument </Property. Defaults> <Property. Constraints>? <Property. Constraint property="string" constraint. Type="any. URI">+ constraint? </Property. Constraint> </Property. Constraints> <Policies/>? <Environment. Constraints>? <Environment. Constraint constraint. Type="any. URI">+ constraint type specific content? </Environment. Constraint> </Environment. Constraints> <Deployment. Artifacts/>? </Node. Template> | <Relationship. Template/> | <Group. Template/> )+ </Topology. Template> Relationship Template …type for… Node Template …type for… Group Template 50

Topology Template (cont. ) <Topology. Template id="ID" name="NCName"> ( <Node. Template/> | <Relationship. Template id="ID" name="string" relationship. Type="QName">+ <Source. Node. Element id="IDREF"/> ( <Target. Node. Element id="IDREF"/> | <Target. Node. Template. Reference name="QName"/> ) <Property. Defaults/>? <Relationship. Constraints>? <Relationship. Constraint constraint. Type="any. URI">+ constraint? </Relationship. Constraint> </Relationship. Constraints> </Relationship. Template> | <Group. Template/> )+ </Topology. Template> Relationship Template …type for… Node Template …type for… Group Template 51

Topology Template (cont. ) <Topology. Template id="ID" name="NCName"> ( <Node. Template/> | <Relationship. Template/> | <Group. Template id="ID" name="string"? min. Instances="int"? max. Instances="int|string"? > ( <Node. Template. . . /> | <Relationship. Template. . . /> | <Group. Template. . . /> )+ <Policies/> </Group. Template> )+ </Topology. Template> Relationship Template …type for… Node Template …type for… Group Template 52

Example: Service Topology Template <Service. Template name="my. Service" target. Namespace="http: //www. ibm. com/sample" xmlns: abc="http: //www. ibm. com/sample"> <Import namespace="http: //www. ibm. com/sample" import. Type=" http: //www. example. org/STE"/> <Topology. Template name="Virtual. Server. Project"> <Node. Template id="my. Project" node. Type="abc: Project"> <Property. Defaults> <Project. Properties> <Owner>Frank</Owner> <Project. Name>Thomas’ favorite project</Project. Name> </Project. Properties> </Property. Defaults> <Node. Template/> <Node. Template id="my. Virtual. Server" node. Type="abc: Virtual. Server" min. Instances="0" max. Instances="unbounded"/>. . . … <Relationship. Templates> <Relationship. Template name="my. Relationship" relationship. Type="contains"> <Source. Node. Element id="my. Project"/> <Target. Node. Element id="my. Virtual. Server"/> </Relationship. Templates> </Topology. Template> </Service. Template> 53

Plans <Plans> <Plan id="ID" name="string"? plan. Type="any. URI" language. Used="any. URI">+ <Pre. Condition expression. Language="any. URI">? condition </Pre. Condition> ( <Plan. Model> actual plan </Plan. Model> | <Plan. Model. Reference reference="any. URI"/> ) </Plan> Plans </Plans> 54

Example: Plans <Plans> <Plan id="Deploy. Application" name="Sample Application Build Plan" plan. Type= "http: //www. example. org/STE/Plan. Types/Build. Plan" language. Used="http: //www. omg. org/spec/BPMN/2. 0/"> <Pre. Condition expression. Language="www. my. com/text">? Run only if funding is available </Pre. Condition> <Plan. Model> <process name="Deploy. New. Application" id="p 1"> <task id="t 1" name="Create. Account"/> <task id="t 2" name="Acquire. Network. Addresses" is. Sequential="false" loop. Data. Input="t 2 Input. Loop. Counter"/> <sequence. Flow id="s 1" target. Ref="t 2" source. Ref="t 1"/>. . . </process> </Plan. Model>. . . <Plan id="Remove. Application" plan. Type= "http: //www. example. org/STE/Plan. Types/Terminatio. Plan" language. Used= "http: //docs. oasis-open. org/wsbpel/…/executable"> <Plan. Model. Reference reference="prj: Remove. App"/> </Plans>

Scenario 56

Sample Node Type: Super. Storage <Node. Type name="Super. Storage"> <Node. Type. Properties element="Storage. Properties"/> <Interface> <Operation name="Create. Storage. Container"> <REST method="POST" … <Operation name="Add. File"> <REST method="PUT" … … </Interface> </Node. Type> <xs: element name="Storage. Properties"> <xs: complex. Type> <xs: sequence> <xs: element name="Total. Storage. Amount" type="xs: string"/> <xs: element name="IPAddress" type="xs: string"/> … </xs: sequence> </xs: complex. Type> </xs: element>

Vendor „Best. Storage. Vendor“ Sells ist Devices with Corresponding Node Template <Node. Template name="Best. Storage. Device" node. Type="Super. Storage"> <Property. Defaults> <Total. Storage. Amount>1000 TB</Total. Storage. Amount> </Property. Defaults> <Deployment. Artifact name="Interface. Implementation" type="WARref">. . . </Deployment. Artifact> </Deployment. Artifacts> </Node. Template> n n Best. Storage. Vendor defines Node Template to specify its Best. Storage. Device based on former Node Type Vendor sets Properties that are known from the outset n n n Total. Storage. Amount is known IPAddress is set during installation/deployment Implementation of interface is referenced from Node Template

Customer Deploys New Device 1. IPAddress-Property of Device is set 2. Storage. API. war is deployed • IP address of Servlet Container is set 3. IP-Address of Servlet Container becomes HOST header for REST API Service Template . . . . Deployment Artifacts Storage API. war … . . . 2 1 TOSCA Container Storage API. war 3 TOSCA Database

Tasks of Plans are Deployed … Create Storage … 2. requires data… 1. refers to… Create. Storage. Container Best Storage Device <Node. Template name="Best. Storage. Device" node. Type="Super. Storage"> <Property. Defaults> <Total. Storage. Amount>1000 TB</Total. Storage. Amount> </Property. Defaults> <Node. Type name="Super. Storage"> <Interface> <Operation name="Create. Storage. Container"> <REST method="POST" … … 3. values from… TOSCA Database 4. locates code… Storage API. war

End of Document 61