francois-normandin
commented
6 years ago I modified the underlying functions to register new instances of SMO. Identity attribute now stores a "Given Name" field. This allowed modification of the object registration workflow to allow for the same object name if those instances have different fully qualified names (FQN).
For example, two pumps can be created with a given name "Pump". The first instance's unique name will be "Pump" and the second will be "Pump_0001". Since they are not owned by any subsystems at this point, their fully qualified names are equal to their unique names. If two subsystems called "Subsystem1" and "Subsystem2" then take ownership (Launch Dependency method) of one pump each, the first pump will get a new FQN of "Subsystem1.Pump" while keeping a unique name of "Pump". The second pump will get a new FQN of "Subsystem2.Pump" as this name is unique in the FQN domain. The unique name will also be "Pump" instead of "Pump_0001" since there is no potential for confusion anymore.
In a nutshell, GUID and FQN will both be unique to a single subsystem, but FQN can change over time as the SMO is appropriated through composition.
(Note that a SMO that is already owned through composition will keep its FQN tied to its owner even though it is aggregated (shared dependency) by a second subsystem. If this isn't clear how or why, please ask... this is a bit more advanced topic and orthogonal to this discussion.)
Unit tests tend to show that this will have no impact on current projects (backward-compatible) other than if configuration files are used to spawn subsystems at runtime through dependency injection. In fact, it should still work, but the unique name might need to change to reflect that the subsystem will tend to retain its given name if possible at all. Configuration-based dependency injected systems are probably configured to provide different given names in the first place, so the only change that I can think of is that this requirement is no longer needed.
One name limitation that exists right now is that we can have a situation where we have two pumps in a system, and we could not both call them pumps even though they have different qualified paths.
Since we have a GUID for each object (already a unique identifier), it would be a good feature to be able to have qualified path unicity instead of name unicity.
This feature implies a displayed name that does not have to be unique, and a unique qualified path (constructed from the composition/aggregation tree).