Understanding Replication Replication Management
The registry administrator creates a Subscription on the Master Registry, which determines the set of information that is propagated from the Master into the Slave. The Replication is then in the Slave Registry, and determines how frequently
the replication is performed.
By default, all new or updated businessEntities are copied to the Slave Registry. However it is possible to limit the data that is replicated using subscription filters configured on the Slave Registry. Note in the image above that not all entities
that exist on the Master have been replicated to the Slave. In addition, the Slave can have its own data which does not exist in the Master.
At the time of execution, the Slave Registry performs a get_subscriptionResults call on the Master Registry based on the subscription key and time range interval specified in the replication. For the purposes of this introductory section,
keep in mind that the subscription on the Master must be a find_business subscription. When the Slave runs the subscription, it gets back a set of keys corresponding to new or changed businessEntities. A businessEntity is considered
to be changed if:
• Any of its businessServices or bindingTemplates have been modified.
• A new businessService or bindingTemplate was created within it.
The Slave registry will then retrieve the complete businessEntity, and store it in the Slave Registry. If an instance of the businessEntity already exists on the Slave, it will be overwritten with the replicated data. As such, the Master is the “source
of truth”.
Replication is set up by a subscription defining the set of businessEntities or tModels being replicated. The subscription filter is a find_business or find_tModel query with no special requirements.
Each time replication is invoked, the slave registry retrieves a set of changed businessEntities and referenced tModels. The tModels are referenced in tModelKeys of either tModelInstanceInfos or keyedReferences. These changes are then
saved.
New features of replication
This release adds the following replication features: •
A Replcation Definition can hold several subscriptions. tModel dependencies are resolved automatically. •
Programatic filtering of transferred entities can be configured not documented, but available, we use it to filter some undesirable entities from replications.
• Replication time specifications are more flexible like unix cron scheduler.
• Reports have also been improved.
Page 322
New features of replication
Table 1. Replication feature issues
Descriptions Replication feature issue
Multiple subscriptions are possible. Typical use is one for business entities,
other tModels. Number of subscriptions in replication item.
Transactional – either fully replicated or nothing.
Failure modes. The tModel will not be replicated. This
will cause failure when the referencee The tModel of the same key is missing
in target registry. Some tModels are not a part of a
subscription yet referenced from other replicated entities.
entity is replicated. Causing a rollback of the replication.
The tModel will not be replicated. It may contain different data.
The tModel of the same key is present in target registry.
The tModel will not be replicated. This will cause failure when the referencer
What happens when the tModel was originally missing and replication is run
for second time. Combination of two rows above.
entity is replicated. Causing a rollback of the replication. Second replication
will start in same state and for same reason it will also roll back.
The other subscription which covers the tModel must be part of same replication
The tModel of the same key is missing in the target registry.
Some tModels are referenced from other replicated entities. But another
subscription which is part of replication covers them.
item other wise transactional processing will end with roll back. The
tModel will be replicated correctly.
The tModel is covered by a subscription that is part of the replication. It will be
The tModel of the same key is present in target registry.
replicated correctly even when it changes on source registry.
Time is specified in format similar to the UNIX cron scheduler. This allows
Specification of time when the replication is run. definition patterns like: every day at
2:00am, every hour at :15, every Saturday 1:00am.
Yes. Correctness when used in a cluster of Registries
Yes. SSL certificate fetch in a replication item edit page.
A colored HTML report is written to the log directory and the report is presented
Reports when replication is run directly from
Web UI. Yes - in Tibco 2.1, Oracle 11g. No - in
HP SOA Registry Foundation probably until next version is released.
Replicate on behalf of original user instead of fixed user of entity.
Page 323
New features of replication
Descriptions Replication feature issue
Yes. Also the mark called Node or Operational Id has the effect that non-
admin users cannot edit the entities on the target Registry that come from
another Registry. This assures that no ordinary user can change entities so that
they are out of synchronization yet not tracked by subscription which is on the
source Registry. Replicated entities carry identification of source Registry.
Yes. No known issues. Configuration in database feature interaction.
Limitations
Important
Selective One-way Replication is not an implementation of the UDDI v3 Inter-Node Replication APIs as defined in the UDDI specification, which is not supported by Oracle Service Registry. The Inter-Node replication is
intended to solve a different problem. Instead, the replication mechanism in Oracle Service Registry is based on a UDDI subscription-based pull model.
Selective One-way Replication does not provide Federation capabilities, such as for a federated search where one registry propagates queries to other registries and consolidates the results.
Important
Replicated data should not be changed because such changes in the slave registry will be lost when someone changes these entities in the master registry and then replication is automatically processed. Note also that
replicated data should be stored under an account having administrator privileges admin.