The TOSCA Object Model

There is a genuine interest in the cloud and networking industries to come up with a common information model that can be used across a variety of management and orchestration technologies. Unfortunately, discussions about unifying information models tend to get tend to get stuck because of a reluctance to deviate too much from legacy designs, because of different modeling philosophies used by different Standards Development Organizations (SDOs), or by disagreements on how best to represent domain-specific features. As a result, these harmonization efforts are not moving nearly as fast as anyone would like.

To move the discussions along, I would suggest that it might be helpful to focus first on a set of common modeling patterns that should be used by all information models, and then introduce domain specific models and features within the context of those core patterns. Leveraging the same core set of modeling patterns would allow us to build a generic set of orchestration and management tools that can process various models in a similar way.  While this wouldn’t immediately lead to unified models, it would result in unified modeling abstractions on top of which existing models can get refactored. If domain-specific models are expressed using the same core modeling abstractions, we’re bound to more easily find commonalities between these models, and common tooling will likely also make it easier to extract those common features from domain-specific models.

Of course, this begs the question of what common set of modeling patterns should be used. This is where I believe TOSCA can help tremendously. The TOSCA object model is sufficiently generic that it can be used across a wide variety of modeling domains. At the same time, it enforces a small number of very powerful abstractions that could provide the modeling foundation we just talked about.

Unfortunately, the TOSCA modeling abstractions are not widely understood. While TOSCA is designed for model-driven orchestration, the TOSCA specification focuses almost exclusively on the grammar of the language, and the object model for TOSCA service models is only implicitly defined in the language, rather than being explicitly spelled out. This write-up is an attempt at more clearly articulating the TOSCA object model. 

At the core, the TOSCA object model has the following features:

TOSCA models are graphs

TOSCA uses graphs as the core modeling construct for services:

• A TOSCA service is modeled as a topology graph that consists of a set of nodes as well as the relationships between these nodes. Nodes are the vertices in a service graph, and relationships are the edges in the graph.
• TOSCA nodes are intentionally as generic as possible. Nodes are essentially nothing more than a collection of named properties and their associated values. Nodes are named, and are labeled using a node type (more on that later).
• Relationships are first-class entities in a TOSCA graph. Just like nodes, relationships have properties, a label, and a name.

The following figure shows a skeleton diagram of the basic TOSCA graph elements.

As you can see, using graphs as the basic modeling construct makes TOSCA completely domain-independent. Any domain-specific meaning of nodes and relationships is introduced using the type field in nodes and relationships. TOSCA types provide specifications that constrain the types of properties (and their values) that can be associated with specific nodes and relationships.

The use of graphs as the fundamental modeling construct combined with types as the specification mechanism makes TOSCA a flexible, general-purpose foundation for modeling a wide variety of application domains.

TOSCA implements the component model

Any modeling infrastructure must include a capability to model how large-scale systems are composed of smaller building blocks. There are currently two competing patterns in the industry for modeling composition:

• The atomic/composite pattern. Using this pattern, systems are modeled as a collection of components, where each component is explicitly defined to be either atomic or composite. Composite components can in turn be composed of other components, which can again be either atomic or composite. Using this pattern, systems can be decomposed into an arbitrary number of levels, and components must be explicitly defined to be composite or atomic at design time.
• The component pattern: Using this pattern, systems are also modeled as a collection of components as before. However, the model does not try to further specify whether components are atomic or composite and components themselves do not further model their internal composition. If it is necessary to describe the internals of a specific component, then that component must be modeled as a separate system that is itself composed of other components, and a decomposition relationship must be established between the component and the system that describes its internals.

The industry is converging on the component pattern as the only pattern that is flexible enough to accommodate a wide variety of composition scenarios. This is based on the key observation that whether a component is atomic or composite is not an intrinsic characteristic of that component. Instead, it is just an artifact of where the modeler stopped decomposing (if you think about it, even atoms are not atomic).

TOSCA implements the component pattern through its substitution mappings feature as shown in the following figure:

• All TOSCA services are modeled as a topology that consists of a set of nodes.
• A node in one TOSCA topology can be substituted by an entirely different topology with its own set of nodes. The substituting topology models the internals of the node it substitutes.
• TOSCA maintains a substitutes relationship between the substituting service topology and the substituted node.

TOSCA unifies run-time, orchestration time, and design time

Orchestrators and management tools use models across the entire service lifecycle:

• Models are used to represent the run-time state of a system and can be used for operational management of that system.
• They can be used as intent models that represent the desired outcome of a (model-driven) orchestration process.
• Models can be used at design time to create reusable service components.

Ideally, it should be possible to use the same models—and the same modeling framework—to cover run-time, orchestration time, and design time. TOSCA allows you to do just that:

• TOSCA has its origin as an orchestration tool for model-driven orchestration, and as such it has very strong orchestration-time functionality
• However, TOSCA also includes a type system that can be used by service designers to create a set of reusable components from which service designers can construct service models. As a result, TOSCA is also a powerful design-time tool.
• More recent work on TOSCA includes a representation of the instance model, which provides a dynamic representation of the run-time state of services and their component that were orchestrated using TOSCA models.

TOSCA models connect these three areas together in the following way as shown in the figure:

• Run-time instances (i.e. nodes in an instance model) keep references to the node templates from which they were created
• Node templates keep a reference to the node type that defines the schema for the properties in the node.
• Node types provide the specifications that turn generic nodes into reusable domain-specific components.

The TOSCA object model

The following picture shows how these various features fit together into the overall TOSCA object model:

If we assumed a modeling foundation based on these TOSCA patterns, then creating a unified information model becomes a challenge of harmonizing type systems, which is something that could get done gradually over time.