Before you can use DCM effectively, develop a
plan for the flow of information between databases. 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.2 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.