Use Case: Modularity for Substitutability and Alternative Implementations.

Support for substitutability in Tosca models can be understood in several ways. Strong substitutability allows NodeTemplates to be "replaced" by another NodeTemplate or sub-topology that is functionally equivalent to, or a superset of, the functionality of the replaced NodeTemplate.

The additional notion of modularity is that the functionally equivalent or functionally expanding topology model could be "added" to the existing model without replacing a part of the existing model. Strong modularity would require that no change is required to any component of the existing xml elements in the model representation. (Of course, the root element ("Definitions") would be changed, but not the descendents of the root.) These additions would add modular alternatives to a Tosca model.

Modular additions might also exist for components other than NodeTemplates. ArtifactTemplates are also a candidate for alternatives.

This current issue is to describe enhancements to Tosca 1.0 to accommodate ArtifactTemplate alternatives. Use cases of special concern are (1) supporting alternative databases for an application, (2) supporting communications between on-premise and cloud applications with gateways having capabilities for interoperable secure protocols and (3) alternative implementations of cryptographic modules [added].

Basic Direction

The basic direction is to leverage the current support of Requirements and Capabilities, and begin by allowing ArtifactTemplates to have Capabilities and Requirements. Let us view our current Topology as a Specification plane for systems, and our current collection of Artifacts as an Implementation plane of the modeled systems. When we connect Specification with Implementation, it becomes possible to execute the operations as specified in Interfaces on NodeTemplates. [Metaphorically, the topology is like a Java interface that the artifacts, like Java classes, implement.] To enable multiple alternative implementations, we need to enhance Tosca's expressive powers to permit ArtifactTemplates to provide Capabilities that can then be matched with a NodeTemplates requirements.

There are both Deployment Artifacts and Implementation Artifacts. Implementation Artifacts will need to have both Capabilities as well as an index that indicates what Operation of a NodeType is supported. Initially Deployment Artifacts can presumably be linked to the Installation operation.

The proposed direction will require several schema changes in the content models (complexTypes) that currently are defined for version 1. It may be possible to unify V 1 syntax with a successor by introducing choices in complexTypes or, in some cases, possible to make more "natural" extensions.

In effect, a new mechanism of Reference is also introduced in the XML. Beyond Ids and IdRefs, and beyond Qnames, a one to many reference mechanism will be introduced based on matches between the Requirement identifiers and their correlative Capability identifiers. Multiple artifacts will have the same set of Capability identifiers that match a NodeTemplate's Requirement identifiers. It is probably better to call this relation one where a NodeTemplate "denotes" various ImplementationArtifacts, or some other term that has a "one-to-many" connotation.

If this denotational referential mechanism is added, the "hard links" that currently tie NodeTypes to ArtifactTemplates can be made optional in the schema. When that happens, processing to carry out Operations will have to find Artifacts using the denotational matching sketched above.