SugarCRM Use Case: Plans 1. Reminder When a service template is deployed, its implementation artifacts are deployed – From that time on, the operations.

Slides:



Advertisements
Similar presentations
Why Do We Need a (Plan) Portability API? Gerd Breiter Frank Leymann Thomas Spatzier.
Advertisements

Mapping Service Templates to Concrete Network Semantics Some Ideas.
SugarCRM Database Deployment Variants DB in separate Service Template DB external to Service Template.
SugarCRM Database Deployment Variants DB in separate Service Template DB external to Service Template.
1 Software Testing and Quality Assurance Lecture 13 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
WEXTOOL User Guide v1.0 E.P. PLANETE B.B.R.. Plan Introduction & Architecture of Wextool Installation Scenario description Experimentation phase Saving/Synchronizing.
Documentation Letts Study Guide Information Systems - IT Chapter 19.
TOSCA SugarCRM Deployment
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Objectives The key roles an architecture description plays in a software project. The key roles an architecture description plays in a software project.
Sharif University of Technology1 Design and Use-case Realization Software Engineering Laboratory Fall 2006.
Lesson-21Process Modeling Define systems modeling and differentiate between logical and physical system models. Define process modeling and explain its.
Chapter 4: Threads. 4.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 4: Threads Overview Multithreading Models Threading Issues.
Systems Analysis I Data Flow Diagrams
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
Topology and Orchestration Specification for Cloud Applications (TOSCA) Standard TOSCA Interoperability Demonstration Join the TOSCA Technical Committee.
Karolina Muszyńska Based on: S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2.0 w modelowaniu SI”
TOSCA Workloads with OpenStack Heat-Translator
Additional SugarCRM details for complete, functional, and portable deployment.
TOSCA Interoperability Demonstration
 Cloud computing  Workflow  Workflow lifecycle  Workflow design  Workflow tools : xcp, eucalyptus, open nebula.
Hybrid-Cloud App Consuming External Services Sketches of Hybrid Cloud Apps using On-Premise Services…
Connecting OurGrid & GridSAM A Short Overview. Content Goals OurGrid: architecture overview OurGrid: short overview GridSAM: short overview GridSAM: example.
Chapter 4: Threads. 4.2CSCI 380 Operating Systems Chapter 4: Threads Overview Multithreading Models Threading Issues Pthreads Windows XP Threads Linux.
ITEC224 Database Programming
Proposal by CA Technologies, IBM, SAP, Vnomic
Interaction Modeling. Introduction (1) Third leg of the modeling tripod. It describes interaction within a system. The class model describes the objects.
SugarCRM LAMP App Deployment Usecase IBM Vnomic. 2 Objective Using an application which is simple, but also presents the most fundamental deployment challenges,
Topology and Orchestration Specification for Cloud Applications (TOSCA) Standard TOSCA Interoperability Demonstration Join the TOSCA Technical Committee.
11 CORE Architecture Mauro Bruno, Monica Scannapieco, Carlo Vaccari, Giulia Vaste Antonino Virgillito, Diego Zardetto (Istat)
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Web Services Flow Language Guoqiang Wang Oct 7, 2002.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Objective Propose a simple and concise set of “Core” Entities and Relations for TOSCA useful for any application deployment in a cloud Enable users to.
1 ECCF Training 2.0 Implemental Perspective (IP) ECCF Training Working Group January 2011.
SugarCRM Service Template
BPEL Business Process Engineering Language A technology used to build programs in SOA architecture.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 4: Threads.
Week 04 Object Oriented Analysis and Designing. What is a model? A model is quicker and easier to build A model can be used in simulations, to learn more.
Normative Types & connectsTo The RelationshipType base type of “connectsTo” in the current draft on Normative Types in Tosca seems to be incomplete. In.
Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 Procedural Activity Patrick Bailey Keith Vander Linden Calvin College.
Script Invocation Conventions TOSCA Interop SC
Hybrid-Cloud App Consuming External Services Sketches of Hybrid Cloud Apps using On-Premise Services…
TOSCA Interoperability Demonstration
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Topology and Orchestration Specification for Cloud Applications (TOSCA) Standard TOSCA Interoperability Demonstration Join the TOSCA Technical Committee.
Objective Propose a simple and concise set of “Core” Entities and Relations for TOSCA useful for any application deployment in a cloud Enable users to.
TOSCA Interop SC – Proposed Timeline for Discussion Revised Sept 10, 2012 Matt Rutkowski.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Cliquez pour modifier le style du titre Cliquez pour modifier les styles du texte du masque Deuxième niveau Troisième niveau Quatrième niveau Cinquième.
Deployment Diagram.
CHAPTER
Deployment Diagram.
COMPONENT & DEPLOYMENT DIAGRAMS
SugarCRM Service Template
Activity Diagram.
TOSCA Interoperability Demonstration
Deployment Diagram.
iVend Retail Extensibility
Unified Modeling Language
Web Application Architectures
Analysis models and design models
Web Application Architectures
Design Yaodong Bi.
Web Application Architectures
Software Development Process Using UML Recap
Presentation transcript:

SugarCRM Use Case: Plans 1

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

VM Node Type … Task, Program,... Script 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 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

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

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

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

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

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

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

Refined SugarCRM Build Plan 11

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

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

Input Message 14

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