(Cloud) Services: An Introduction to TOSCA (Topology and Orchestration Specification for Cloud Services)

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

2. Terminology

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

4. Terminology: Service • “Service” means different things • In SOA: Any kind of (reasonably coarse-grained) application function • 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 • 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

5. Terminology: Orchestration • “Orchestration” means different things • 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

6. Terminology: Composition • “Composition” means different things • 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

7. Conceptual Overview

8. Imagine… • …that you have a nice application that you want to be able to be hosted in different clouds • Why do you want that? • 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

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

10. What are the Technical Problems? • No interoperable description exists of what your application is and what it requires • Virtual images do not suffice at all • 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 • Deep detailed skills about the application and its underlying stack is needed that “arbitrary” providers typically don’t have

11. What Is “(Cloud) Service Template” All About? NodeTypes Topology(Template) Rel.shipTypes (Cloud) Service Template GroupTemplate Plans A new language (“metamodel”) to specify • the building blocks of your application • the management functions thesebuilding 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

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

13. …and More Colorful… Topology Plans

14. …and With Angular Brackets… <ServiceTemplate…> <Extensions/>? <Import />* <Types/>? ( <TopologyTemplate/> | <TopologyTemplateReference/> )? <NodeTypes/>? <RelationshipTypes/>? <Plans/>? </ServiceTemplate>

15. Example: High Level View BPEL Files Node Template uses WSDL Files Relationship Template deployedOn implementedby WebSphere Process Server deployedOn requires …and this is a bit more clomplex… EJBs WebSphere Cell deployedOn requires DB2 Server

16. Example: WebSphere Cell Refined WebSphere Cell exists Properties, e.g.: WAS installlocation, Profile name, Nodename WebSphereCell DB2 Server DB2 Server 1..* IHS Node WAS ND DeployMgrNode WAS ND ManagedNode Cluster DB2 Database Instance "cluster" 1..* "database" Application Server Instance Properties, e.g.: ports, servername, weight

17. Example: Overall Topology Template BPEL Files WSDL Files WebSphere Process Server EJBs WebSphereCell 1..* IHS Node WAS ND DeployMgrNode WAS ND ManagedNode Cluster DB2 Server 1..* Application Server Instance DB2 Database Instance

18. Example: Amazon BPEL Files uses WSDL Files deployedOn implementedby WebSphere Process Server Amazon deployedOn requires EJBs WebSphere Cell deployedOn requires DB2 Server

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

20. Example: Amazon – Refined Scenario WSDL Files BPEL Files uses Implemented by deployedOn EJBs On Premise WebSphere Process Server Amazon deployedOn requires WebSphere Cell WebSphere Cell requires requires DB2 Server (ApplicationData) DB2 Server (WAS Data)

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

22. Example: Reusing Existing Services • 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) „somewhere1“ BPEL Files WS1 uses WSDL Files deployedOn bound to „somewhere2“ WebSphere Process Server WS2 deployedOn requires … WebSphere Cell requires WSn DB2 Server „somewheren“

23. Example: SAP BPEL Files uses WSDL Files deployedOn implementedby SAP Workflow SAP deployedOn requires EJB Netweaver deployedOn requires Oracle

24. Example: Microsoft BPEL Files uses WSDL Files deployedOn implementedby BizTalk Azure deployedOn requires .NetAssemblies .Net deployedOn requires SQL Server

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

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

27. Sample:Websphere Management Plans Initial Provisioning Provision Dmgr DeployMonitoring Agent (Dmgr) Enable Admin Security Start Dmgr Create Cluster Provision ManagedNode Deploy Mon. Agent FederateNode Create Cluster Members Provision IHS Node Deploy Mon. Agent (IHS) Start IHS Configure Webserver Start Cluster Provision ManagedNode Deploy Mon. Agent FederateNode Create Cluster Members Start Cluster Add Nodes UnfederateNode Reconfigure Webserver Remove Mon. Agent DeprovisionManagedNode Remove Nodes

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

29. A Caveat! • 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 • By various domain experts, vendors,…

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

31. Motivation

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

33. Important Note 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

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

35. Scenario 3:Interoperable Service Compositions CloudProvider A Realized By Implemented As CloudProvider B CloudProvider C

36. Scenario 4:Using OVF Packages <ovf:Envelope ... > <ovf:VirtualSystemCollection...> <ovf:VirtualSystem ... > ... <ovf:ProductSection ... > ... </ovf:ProductSection ... > ... </ovf:VirtualSystem> <ovf:VirtualSystem ... > ... </ovf:VirtualSystem> ... </ovf:VirtualSystemCollection> </ovf:Envelope> Note: only subtree of service definition relates to OVF, othersubtrees/nodes can point toshared resources (e.g. DB2,…)

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

38. Cloud Management & Orchestration Components in a compositeservicecancomefromoneCloud, multiple Clouds, orcanbenon-Cloudresources (e.g. existingcompany LDAP or private DBs). Service SaaS SaaS offerings exist (e.g Google Apps), but as standalone offerings restricted to the SaaS layer. Application Management Scope PaaS PaaS offerings exist (e.g. MicroSoft Azure), but are restricted solely to the PaaS layer. AppSrv DB Interfaces between PaaS and IaaS starting to evolve. IaaS Server Server Storage IaaS is maturing. Evolution of standards like OVF or defacto standards like EC2 or S3 enable growth of ecosystems. Cloud Management & Orchestration Deploy, Decommission Start, Stop, Resize Management Plans covering the complete service life cylce. Management Functionality

39. Service Template: Specification Overview

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

41. Structure of .ste Document <ServiceTemplate id="ID" name="string" targetNamespace="anyURI"> <Extensions/>? <Import />* <Types/>? ( <TopologyTemplate/> | <TopologyTemplateReference/> )? <NodeTypes/>? <RelationshipTypes/>? <Plans/>? </ServiceTemplate> Topology Template Relationship Types Node Types Plans

42. Node Types: Overall Structure <NodeTypes>? <NodeType id="ID" name="string">+ <NodeTypeProperties element="Qname"?type="QName"?/>? <DerivedFromnodeTypeRef="QName"/>? <InstanceStates/>? <Interfaces/>? <DeploymentArtifacts/>? <Policies/>? </NodeType> </NodeTypes> Node Types Node Type Interface Properties

43. Interfaces of Node Types <Interfaces>?   <Interface>+   ( <WSDLportType="QName“ operation="NCName">+ | <REST method="GET | PUT | POST | DELETE" requestURI="anyURI" requestPayload="QName"? responsePayload="QName"?>+ | <Operation name="NCame">+   <InputParameters>?   <InputParamter name="string" type="string" required="yes|no">+   </InputParameters>   <OutputParameters>?   <OutputParamter name="string" type="string">+   </OutputParameters> <Implementations> <Implementation implementationID="anyURI"? language="anyURI"?>+ ( <ImplementationProper>? code </ImplementationProper> | <ImplementationReference ref="anyURI"/>? ) <Implementation>  </Implementations> </Operation> ) </Interface>  </Interfaces> Interfaces

44. Deployment Artfactsof Node Types <DeploymentArtifacts>? <DeploymentArtifact name="string" type="anyURI">+ artifact specific content </DeploymentArtifact> </DeploymentArtifacts>

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

46. Example: Node Types ... <Interfaces> <Interface> <Operation name="CreateProject"> <InputParameters> <InputParamter name="ProjectName" type="string"/> <InputParamter name="Owner" type="string"/> <InputParamter name="AccountID" type="string"/> </InputParameters> <Implementations> <Implementation> ... </Implementation> </Implementations> </Operation> </Interface> </Interfaces> </NodeType> </NodeTypes> </ServiceTemplate>> <ServiceTemplate name="myService" targetNamespace="http://www.ibm.com/sample"> <NodeTypes> <NodeType name="Project"> <documentation xml:lang="EN"> A reusable definition of a node type supporting the creation of new projects. </documentation> <NodeTypeProperties element="ProjectProperties"/> <InstanceStates> <InstanceState state="www.my.com/active"/> <InstanceState state="www.my.com/onHalt"/> </InstanceStates>  ...

47. Relationship Types <RelationshipTypes> <RelationshipType id="ID" name="string" semantics="anyURI" cascadingDeletion="yes|no">+ <RelationshipTypeProperties element="QName"? type="QName"?/>? <InstanceStates>? <InstanceState state="anyURI">+ </InstanceStates> </RelationshipType> </RelationshipTypes> Relationship Types Relationship Type Properties

48. Example: Relationship Types <RelationshipTypes> <RelationshipType name="processDeployedOn" semantics="www.my.com/RelSemantics/procDeployedOn" cascadingDeletion="yes"> <RelationshipTypeProperties element="ProcessDeployedOnProperties"/> <InstanceStates> <InstanceState state="www.my.com/successfullyDeployed"/> <InstanceState state="www.my.com/failed"/> </InstanceStates> </RelationshipType> </RelationshipTypes>

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

50. Topology Template (cont.) <TopologyTemplate id="ID" name="NCName"> (  <NodeTemplateid="ID" name="string" nodeType="QName" minInstances="int"?maxInstances="int|string"?>+  <PropertyDefaults>? XMLDocument </PropertyDefaults>  <PropertyConstraints>?  <PropertyConstraint property="string" constraintType="anyURI">+ constraint? </PropertyConstraint>  </PropertyConstraints>  <Policies/>? <EnvironmentConstraints>? <EnvironmentConstraintconstraintType="anyURI">+ constraint type specific content? </EnvironmentConstraint> </EnvironmentConstraints>  <DeploymentArtifacts/>? </NodeTemplate>  |  <RelationshipTemplate/>  | <GroupTemplate/> )+  </TopologyTemplate> Relationship Template …type for… Node Template …type for… Group Template