During our TOSCA Language Ad-Hoc meeting of Wednesday Oct. 23, I promised I would share the high-level outline I use when I give customers and/or prospects a tutorial of TOSCA. Initially, we can use an outline like this to help organize TOSCA examples, but I envision that this could also be used if and when we get back to the "Introduction to TOSCA v2.0" document.
Please feel free to share comments and feedback
Thanks,
- Simple service model example
- Introduce service templates that define graphs
- That consists of nodes
- And relationships
- TOSCA types
- All TOSCA entities are typed
- Types define externally visible façade
- Entities in service templates are validated against their types
- Create reusable building blocks
- Imports
- TOSCA type definitions can be moved into separate TOSCA files
- To support modular designs
- For use by multiple service templates
- To create library of reusable building blocks
- And imported into other TOSCA files
- Namespaces
- TOSCA files can be imported into named namespaces
- To avoid name conflicts
- To make it clear where types are defined
- Profiles
- Type collections can be published as a TOSCA profile
- By advertising a well-known profile name
- And imported using their well-known profile name
- Configuring services
- Services are configured using property values
- Type definitions include property definitions
- Property definitions use data types
- TOSCA uses built-in data types
- Users can define complex data types.
- TOSCA Functions
- Input functions
- Property and attribute functions
- Built-in functions
- Custom functions
- TOSCA Path
- TOSCA graph traversal grammar
- Interfaces and operations
- Nodes and relationships advertise interfaces
- Interfaces are collections of operations
- That can be "called" by an orchestrator to communicate with external implementations
- Interfaces are types
- Interface types define inputs and outputs for operations
- Attributes
- TOSCA attributes track runtime state
- As opposed to properties, which track initial configuration
- Operation outputs map to attributes
- Artifacts
- Node types and node templates can define artifacts
- That can be used as implementations for interface operations
- Artifacts can also be used as operation inputs
- E.g. as config files etc.
- Workflows
- Orchestrators run workflows that call node operations
- Workflows define the sequence in which operations are called
- Ideally, workflows are generated automatically based on dependencies in the service graph
- Requirements and Capabilities
- Relationship links source node requirement to target node capability
- Requirement anchors the source of a relationship
- Capability anchors the target of a relationship
- Node Templates can have dangling requirements
- Requirement assignments that do not explicitly specify target node
- Dangling requirements are expected to be fulfilled by the Orchestrator at service deployment time
- Node filters narrow the set of target node candidates
- By specifying a Boolean expression
- that must evaluate to True
- if the target node were used to fulfill the requirement
- Substitution
- Node templates can be marked with a substitute directive
- Directs to orchestrator to "implement" the node using a substituting service
- Substitution candidate is selected at deployment time
- Substitution filters narrow the set of substitution candidates
- Policies