TOSCA functional architectures

[Chris Lauwers <lauwers@ubicity.com>]

Based on Tuesday’s discussion in the Language Ad-Hoc, I updated the “simple architecture” diagrams as shown in the attached slides:

 

1. For now, the slides only consider architectures that use an external orchestrator. To reflect this, the slides use the term “TOSCA Processor” rather that “TOSCA Orchestrator” for the functional blocks that process TOSCA.
2. The first slide shows an even simpler “Simple TOSCA Processor” architecture that our original “Simple Processor”. This architecture processes TOSCA service templates without performing requirement fulfilment or substitution mapping.
1. I renamed the earlier “semantic template”  to “compiled service template” (based on a comment from Tal)
2. I clarified what we/I mean by instantiation and service instance model
3. The second slide adds “requirement fulfilment” and “substitution” to get back to our original “Simple TOSCA Processor”.
1. Peter coined the term “model evaluation” for these functions in some of his earlier slides. I suggested the term “model build-out” instead.
2. Model build-out results in more complete service instance models
4. Slide 3 is the most opinionated (and as a result controversial):
1. It details my opinion about how requirement fulfilment should be done, and which node instances should be considered as candidates for fulfilling dangling requirements
2. It details my opinion about which templates should be considered as candidates for substituting abstract nodes.

 

I encourage everyone to comment over email so we can have a very productive meeting next week.

 

Thanks,

 

Chris

 

Attachment: TOSCA Functional Architectures 2020-12-01.pptx
Description: TOSCA Functional Architectures 2020-12-01.pptx