...
- The concept of participant replicas into ACM-R and the Participant Intermediary
- A lightweight mechanism for replica update between replicas and ACM-R. Every time a replica changes its data, the change is reported to ACM-R and ACM-R updates all other replicas for that participant
The diagram above depicts data management as implemented today in ACM-R. ACM-R maintains the "source of truth" for all compositions and their elements in the ACM-R database.
- Composition type data is pushed from ACM-R to the participants and is read-only in the participants
- Composition element data (state information mainly) is built up by interactinos between ACM-R and participants for the various ACM operations (Deploy/Update/Undeploy etc) and ACM-R always maintains the current composition element data in the ACM-R database
- Composition element properties are pushed by ACM-R to the participant and can be updated in the participant by the participant implementation. When the properties are updated on the participant side, those changes are propagated to the ACM-R database
Therefore today, for the three types of data above, the ACM-R database has the state of the participant. This means that creation of participant replicas is rather trivial. We
In this solution:
- Participant Design backward compatibility is preserved, there is no change to the participant intermediary interface for participant implementations
- Participant Configuration Backward compatibility is preserved, apart from a new "replicas" parameter (optional, default is 1), there is no change to participant configuration
- ACM-R introduces a new REST API for replica management
- ACM-R is made HA so that it itself can scale
...