1. SugarCRM Use Case: Plans 1

2. Reminder When a service template is deployed, its implementation artifacts are deployed – From that time on, the operations of the node types can be used in the particular environment Now, tasks of the plans can be bound to the implementation of the operations in this environment – I.e. plans are bound to the environment (as usual) in which they are executing Node Type … Task in Plan … … Script - - - - - - - …refers to… …bound to… ImplArtifacts Script - - - - - - - JAR - - - - - - - REST API (reference) deploy 2

3. VM Node Type … Task, Program,... Script - - - - - - - 3. use Implement. Artifacts Script - - - - - - - JAR - - - - - - - REST API (reference) 1. deploy Operations realize 2. bind EAR - - - - - - - Deployment Artifacts realize VM 4. deploy Reminder: Refined View 3

4. 4 SugarCRM Topology Template 4 VM-Apache (VirtualMachine) OS-Apache (OperatingSystem) ApacheWebServer (ApacheWebServer) SugarCRM App (SugarCrmApp) PHP Module (PhpModule) HostedOn DependsOn VM-MySQL (VirtualMachine) OS-MySQL (OperatingSystem) MySQL (MySQL) SugarCRM DB (SugarCrmDb) HostedOn ConnectsTo Web Tier (Tier) HostedOn DB Tier (Tier) HostedOn

5. Interfaces of Node Types Need to specify all operations required for managing cloud services – Lifecycle operations – Specific operations needed for particular node types Identify kind of interface – Script, REST, Web Service Take care of implementation artifacts  This is independent of plans! 5

6. Lifecycle Operations Each node type must support the following lifecycle operations – Define the “names” of the operations only The concrete parameters will need to be specified in detail for each node type – First candidates Start, stop Provision, de-provision – Note: these operations might have variants in meaning for particular node types E.g. “start” of a storage node type attaches storage 6

7. Plans are Optional If you don’t want to provide plans… – …you need to provide other mechanisms to allow execution of management actions on the service E.g. scripting, command line interface, GUI etc – …and these mechanisms will make use of the operations of your node types 7

8. How to Model Plans Just “draw” the sequencing of steps that you would otherwise… – …implement in a “super-script” – …document in an install guide BUT: you should exploit features that process management systems provide – Parallelism – Recovery – Human involvement – … 8

9. How to Create a Build Plan As a rule of thumb, read the topology template from leaves to root to create a first draft of a build plan – I.e. reverse the edges of the topology template – Rename each node into a corresponding “deploy task” – Connect these tasks with control flow connectors BUT: the result is typically not a correct (or “good”) process model – Need to refine control flow …to reflect dependencies due to more than one incoming edge – Clear expression of parallelism, synchronization, end & start Finally, semantics of relationship types require creation of new tasks – E.g. “connects_to” requires such a task 9

10. Sample Plan Draft Here, we need to refine control flow Original relation in topology template requires creation of additional task VM-Apache (VirtualMachin e) OS-Apache (OperatingSyst em) ApacheWebSer ver (ApacheWebSe rver) SugarCRM App (SugarCrmApp) PHP Module (PhpModule) HostedOn DependsOn VM-MySQL (VirtualMachin e) OS-MySQL (OperatingSyst em) MySQL (MySQL) SugarCRM DB (SugarCrmDb) HostedOn ConnectsTo Web Tier (Tier) HostedOn DB Tier (Tier) HostedOn “Reversed Topology Template” 10

11. Refined SugarCRM Build Plan 11

12. Bind Tasks to IT Artifacts Bind tasks to operations of their corresponding node types Define input and output of tasks – Data to be passed as input of operations – Output of operations passed to “process context” Define input message and output message of plan Consider additional features of process technology – Compensation, human tasks, exception handling, event handling (time, messages, signals,…),… 12

13. Sample Binding Operation Input/Output Getting input from process context 13

14. Input Message 14

15. Kind of Plans Each topology template will have at least – Build plan (provision) – Start plan – Stop plan – Termination plan (de-provision) Then, for each management action you will have further plans – For elasticity, license management, user management, database backup/restore,… 15