Instance Model Structure
[email protected]
Serialization to YAML
• Allows us to look at a snapshot of the instance model without having
to define query/navigation techniques
• … but need to maintain a clear concept of the information to be
represented
• Approach:
• Encode input values provided by user as input_instances
• Encode policies applied as policy_instances linking to affected templates and
instances
• Encode requirement resolution as needed for automated matching for
fulfillment
• Generate node_instances for final topology
• Encode output with final values
Information Model
Type Schema
Templates
Types
Instances
Type w
…
Type x
derived from
Properties
name: type
attributes
Met model of a
TOSCA Type
E.g. Class, data
type, references,
attributes
NodeType,
CapabilityType, …
Template y
Type x
properties
attributes
Instance z
Template y
properties
Attributes
Dynamic info
Normative?
Env specific
Parameterized
“constructors”
Parameterized
“constructors”
Relations between Node Instances
Node
Template
A
M
N
Node
Template
B
A[0]
B[0]
A[1]
B[1]
A[2]
Node instances have m x n cardinality
by default but we’ll need to support
other kind of configurations.
Instance Model Example