finos
Constraining Detailed Architecture Usage in Patterns
Feature Request
Description of Problem:
detailed-architecture provides a "drill down" feature in CALM. A node can provide a detailed architecture link, which corresponds to another CALM architecture with more details of a node.
When using the detailed-architecture feature in patterns, it would be helpful to constrain the detailed-architecture to a specific pattern.
Potential Solutions:
One solution is to provide an optional detailed-pattern or detailed-architecture-pattern, this would constrain the downstream architecture and enable the architect to define any input and output nodes or relationships relevant to the pattern.
It would also enable the downstream pattern to constrain the downstream architecture where necessary and have that also conform to a pattern.
Changing node to have something like
"details": {
"type": "object",
"properties": {
"detailed-architecture": {
"type": "string"
},
"detailed-pattern": {
"type": "string"
}
}
}
Could work really well with patterns.
- It enables a pattern author to say you must provide a detailed-architecture where on is needed.
- It can be constrained to point at a specific detailed architecture (for known systems that have a well established set of components and controls)
- It can be used to say you must provide a detailed architecture and it is constrained by this pattern
cc/ @Budlee @rocketstack-matt
Would the name reference-pattern or required-pattern be more appropriate in terms of intent?
The required-pattern is a nice add here and I believe should resolve what we require
@Budlee the plan is to get it into version 1.
There is a bit of work left open on this issue to validate how it behaves in the CLI. I've assigned to myself to test this and will either close the issue or create a new issue for CLI support.
Still open as we need to validate if this works correctly in the cli
So say you specify detailed architecture that links to another CALM spec, what would denote the entry point and exit point?
If say Node A connects to Node B and node B has a detailed architecture, it follows that there is a specific node that Node A is connecting to in Node B.
Likewise if Node B connects to C, C would be receiving a connection from a node from the detailed architecture in B
Moreover, if say Node A connects to Node B and node B has a detailed architecture, it follows that there is a specific node and potentially a specific interface that Node A is connecting to in Node B.
- Could architectures (especially those that are intended as detailed architectures) specify 'public' nodes or interfaces, intended for connection from other architectures?
- Or do actor nodes perform the function of identifying the public node/interface connection points into a detailed architecture? Or is this unnecessary?
- Could the interfaces of a node with a detailed architecture reference the detailed architecture's actor node?
Example for point 3 only:
detailed-arch.json:
"nodes": [
"node": { "unique-id": "api-producer", "interfaces" : [
{ "unique-id": "api-endpoint" }
]
}
],
top-level-arch.json - node B has an interface that references the unique-ids of a node and (optionally) interface in the detailed arch.
"nodes": [
"node": { "unique-id": "A" },
"node": { "unique-id": "B",
"details" : {"detailed-architecture": "detailed-arch.json"},
"interfaces" : [
{ "unique-id": "bees-api", "detailed-arch-node" : "api-producer", "detailed-arch-interface": "api-endpoint" }
]
}
],
"relationships": [
{ "unique-id" : "a-to-b",
"connects" : {
"source": { "node": "A"},
"destination": { "node": "B", "interface": "bees-api" }
}
}
]
