Harmonize capabilities of Platform nodes

[lauwers]

The Platform node type in the base profile currently defines three capabilities that all define similar functionality:

• An execution-environment capability to host Application nodes
• A data-platform capability to host Data nodes
• A host capability to host other Platform nodes

It might be simpler and cleaner to consolidate all or some of these capabilities, and instead use the valid_source_node_types to restrict which nodes can target this capability.

[Roberto-Mameli-Eng]

Of course, both approaches are feasible, but in my opinion keeping three separate capabilities is slightly cleaner and contributes to add clarity. In fact, the concept behind keeping 3 separate capabilities is that when they get refined in derived nodes, they may possibly be specialized with different set of properties/attributes.

Consider e.g. an application written in PHP running together with a mySQL DB into the same node, which actually consists in a VM realized on top of a VMWare stack. The VM is the target of 2 relationships (from PHP Application and from mySQL Data) and source of another relationship to a VirtualizationPlatform node. All capabilities and relationship involved in this scenario are obviously characterized by different sets of properties (e.g. minimum PHP version, other relevant PHP configuration parameters vs minimum mySQL version, DB schemas, credentials, etc.).

In principle, part of those properties may be managed through the implementation_details mechanism discussed here. However, some of them may derive from mapping capabilities/relationships from abstract nodes to substituting templates. If we have just one capability at the top level, it might end up in mixing together properties in the substituted nodes which have nothing in common one another, mapping them to different node templates in the substituting template.

Of course, this is just my opinion, but I believe that keeping 3 distinct capabilities helps to keep things separated and, ultimately, enables a cleaner approach.

[lauwers]

@Roberto-Mameli-Eng makes good points. Let's try to work through various use cases that create substituting templates for the various abstract types, and analyze whether keeping capabilities separate does indeed simplify substitution.