You will need to develop a plan for the flow of information between databases before you can use DCM effectively. A DCM methodology defines what information is replicated between which databases. A replication topology defines whether the databases replicate data directly with each other, or through intermediate hub databases.
- A DCM methodology defines what information is replicated between which databases. It also defines the purpose, and how the software component or application is built from such shared changes. Some typical DCM methodologies include:
- A replication topology defines whether the databases replicate data directly with each other, or through intermediate hub databases. Some typical replication topologies include:
- Point-to-point topology
- Each database generates a transfer package for a database to which information is to be sent.
- Hub and spoke topology
- Spoke databases do not replicate directly between each other. Instead, they replicate using one or more hub databases. In a DCM cluster that contains databases running on earlier releases of Rational Synergy, any hub databases must be at the latest release. See Supported transfers from Rational Synergy releases before 7.1 for more specific details.
- Together, the DCM methodology and replication topology define the nature and direction of transfers. To help you define your methodology and topology, answer these questions:
- What is the purpose of the DCM cluster?
- What is the purpose of each database in the DCM cluster?
- What is the nature of the object sharing (for example, to distribute tested projects, or to share products)?
- Which objects are local to a given database and are not shared?
- Which objects are local to a given database and are shared with other databases?
- Which objects are not local to a given database, but are used by it?
- How often does each database require a transfer?
- Does the DCM cluster require central control of objects?
- Does one person manage the DCM cluster (for example, a DCM administrator)?
The contents of transfer packages are not addressed by the DCM methodology. Transfer packages are part of the implementation of the methodology and are controlled by each source database.
Note: Within a given DCM cluster, different software components can use different methodologies. For example, an application that is being developed across multiple sites might use the Master and Satellite methodology. In the same cluster, however, a software feature that is shipped as a tested released component might be transferred using the Publish and Subscribe methodology.