<!-- Adapted from /docs/html/federation/federation.html -->
# OpenDDS Repository Federation Design
* [Introduction](#introduction)
* [Use Cases](#use-cases)
* [Normal Operation](#normal-operation)
* [Application creates a new service Entity](#application-creates-a-new-service-entity)
* [Application updates an existing service Entity](#application-updates-an-existing-service-entity)
* [Application destroys an existing service Entity](#application-destroys-an-existing-service-entity)
* [DataWriter or DataReader becomes associated with other DataReader or DataWriter](#datawriter-or-datareader-becomes-associated-with-other-datareader-or-datawriter)
* [DataWriter or DataReader becomes unassociated with other DataReader or DataWriter](#datawriter-or-datareader-becomes-unassociated-with-other-datareader-or-datawriter)
* [Failover](#failover)
* [ServiceParticipant changes manager for domain to new repository](#serviceparticipant-changes-manager-for-domain-to-new-repository)
* [Discovery](#discovery)
* [Join Federation](#join-federation)
* [Repository joins an unfederated repository](#repository-joins-an-unfederated-repository)
* [Repository joins an already federated repository](#repository-joins-an-already-federated-repository)
* [Operate Federated](#operate-federated)
* [Leave Federation](#leave-federation)
* [Architecture](#architecture)
## Introduction
OpenDDS is an implementation of the OMG Data Distribution Service (DDS)
specification. This implementation is managed by attaching individual
application ServiceParticipant to a remote repository process which provides a
CORBA IDL interface for managing the service. Application code need not be
aware of the details of this interface as it is used internally by the DDS
ServiceParticipant. The application is required to establish and maintain
connections with these remote processes.
As of this time, each ServiceParticipant is allowed to attach to one or more
repositories for management of individual domains. Currently there is one
repository allowed to manage one or more DDS defined domains for an application
with each domain used by an application managed by one and only one repository.
This means that if the remote repository process managing a specific domain for
an application fails for any reason, that domain and any Topics, publications
or subscriptions will no longer be available to the application. This is
undesirable.
In order to eliminate this problem for users of OpenDDS, a mechanism that
allows multiple repositories to become federated and manage the same domains is
being proposed. This mechanism means that if one repository fails, another
repository will be able to replace it so that applications will be able to
operate correctly as long as at least a single repository is attached.
The proposed mechanism is required to satisfy several use cases during
operation. These cases include operating in the presence of one or more
repositories, switching the management of an applications DDS
ServiceParticipant for any given domain from a failed repository to one that is
still operational.
Previous work done to demonstrate the ability of DDS to provide a data transfer
capability within a dynamic topology of point to point links established the
ability of the DDS service to route data over defined connections within a
topology. Work was done on that project that prototyped interfaces needed to
manage the federation of repositories and can be used directly.
## Use Cases
Federation of repositories is required to satisfy the following use cases:
### Normal Operation
Application ServiceParticipant operates with one or more federated repositories
This is the steady state of an application using a DDS service provisioned by
federated repositories. Applications initialize attaching to one or more
repositories. Each domain utilized by that application is then mapped to a
single repository for managing the Entities within that domain.
#### Application creates a new service Entity
Application creates a new service Entity. Note that these scenarios do not show
any resulting behavior triggered by the creation event. The Operate Federated
use case describes that information.
#### Application updates an existing service Entity
The repository processing is essentially the same as performed for scenario 1
but with the DCPSInfo interface call to the corresponding 'update_..._qos'
method for the entity being destroyed. The application would also need to have
called the corresponding 'update' method as well.
#### Application destroys an existing service Entity
The repository processing is essentially the same as performed for scenario 1
but with the DCPSInfo interface call to the corresponding 'remove' method for
the entity being destroyed. The application would also need to have called the
corresponding 'destroy' method as well.
#### DataWriter or DataReader becomes associated with other DataReader or DataWriter
This operation proceeds without modification from the existing repository and
ServiceParticipant processing. The only difference is that a repository may
have only one end of the association for which to call back into the
ServiceParticipant to make the association. The information to make the
`add_associations` call to the RemoteDataWriter or RemoteDataReader is
available to the repository since it is part of the distributed update
information. This includes the transport endpoint information required for
establishing the connection. Note that this requires that all participants be
able to connect directly with all other participants.
The event that triggers an `add_associations()` call within a repository is
predicated on the ownership of the endpoint. This means that if a repository
'owns' a particular publication or subscription, then it needs to issue the
callback. Since ownership may be passed (see Failover) it is not sufficient for
the repository to check the repository identifier of the actor but ownership
needs to be checked explicitly. It may be the case that an application
ServiceParticipant has passed ownership of remotely created Entities to this
repository or that locally created Entities have had ownership passed to
another repository.
Processing within a given ServiceParticipant is unaffected. Once the
`add_associations` call is made to the RemoteDataWriter or RemoteDataReader all
subsequent processing proceeds without modification.
#### DataWriter or DataReader becomes unassociated with other DataReader or DataWriter
The processing of this scenario is the complement of that described in the
associating scenario. The key is the triggering the `remove_associations`
callback correctly.
### Failover
Application ServiceParticipant redirects service management to different
repository
This is how each application ServiceParticipant redirects its management to a
different repository. If the repository managing a domain within an application
becomes unavailable, through either process or communication failure, then the
application needs to attach to a different repository to manage that domain and
pass ownership within the federation for that applications data to the new
repository.
Scenarios include:
- ServiceParticipant detects repository as unavailable
- ServiceParticipant changes manager for domain to new repository
#### ServiceParticipant changes manager for domain to new repository
This is currently shown as a remote call to the Federator::Manager to assert
ownership with a CORBA request/response call to each remote repository in the
federation to propagate the ownership through the federation. This may be
better done by distributing the ownership information via DDS (as with the
update topics) instead.
The remap operation as shown presumes that all of the Entities created within
the ServiceParticipant are switc
OpenDDS：OpenDDS是对象管理组（OMG）数据分发服务（DDS）的开源C ++实现。 OpenDDS还通过JNI支持Java绑定 （2000个子文件） 
Sedp.cpp 238KB XTypesAssignability.cpp 192KB ut_ParameterListConverter.cpp 161KB Spdp.cpp 153KB marshal_generator.cpp 148KB dds_qos.cpp 145KB RtpsUdpDataLink.cpp 139KB TypeObject.cpp 121KB DataReaderImpl.cpp 110KB Service_Participant.cpp 102KB Config.cpp 90KB DataWriterImpl.cpp 89KB xcdr.cpp 84KB CryptoBuiltInImpl.cpp 80KB DomainParticipantImpl.cpp 79KB DCPSInfo_i.cpp 78KB langmap_generator.cpp 74KB TypeAssignability.cpp 74KB StaticDiscovery.cpp 74KB AccessControlBuiltInImpl.cpp 69KB TransportSendStrategy.cpp 69KB im_jni.cpp 60KB main.cpp 57KB typeobject_generator.cpp 55KB AccessControlTest.cpp 55KB ParameterListConverter.cpp 54KB WriteDataContainer.cpp 54KB AuthenticationBuiltInImpl.cpp 50KB FederatorManagerImpl_updates.cpp 49KB DCPS_IR_Domain.cpp 49KB AuthenticationTest.cpp 48KB OpenDDS_DCPS_jni.cpp 44KB TransportRegistry.cpp 43KB MonitorDataStorage.cpp 42KB sample_dissector.cpp 40KB FederatorManagerImpl.cpp 39KB TransportReceiveStrategy_T.cpp 39KB RelayHandler.cpp 39KB RtpsUdpReceiveStrategy.cpp 39KB RtpsDiscovery.cpp 38KB TransportClient.cpp 37KB QosSettingsTest.cpp 37KB MemoryPoolTest.cpp 36KB main.cpp 36KB TryConstruct.cpp 36KB FaceTSS.cpp 36KB DataLink.cpp 35KB TryConstruct.cpp 35KB WriteDataContainerTest.cpp 34KB ReplayerImpl.cpp 34KB SerializerTest.cpp 34KB InfoRepoDiscovery.cpp 34KB SystemException.cpp 33KB packet-opendds.cpp 33KB DisjointSequence.cpp 33KB RtpsDiscoveryTest.cpp 33KB RecorderImpl.cpp 33KB rtps_reliability.cpp 33KB RtpsRelay.cpp 32KB SubscriberImpl.cpp 32KB PersistenceUpdater.cpp 31KB DCPS_IR_Participant.cpp 31KB main.cpp 31KB TcpConnection.cpp 31KB PubDriver.cpp 30KB MonitorTask.cpp 28KB EndpointManager.cpp 28KB Fragmentation.cpp 28KB PublisherImpl.cpp 28KB QueryConditionTest.cpp 28KB main.cpp 27KB DataDurabilityCache.cpp 27KB RtpsUdpTransport.cpp 27KB Checklist.cpp 27KB main.cpp 26KB metaclass_generator.cpp 26KB main.cpp 26KB be_global.cpp 26KB main.cpp 26KB DCPS_IR_Subscription.cpp 25KB RtpsSampleHeader.cpp 25KB im_java.cpp 25KB DCPS_IR_Publication.cpp 25KB TcpTransport.cpp 25KB ReliableSession.cpp 25KB rapidjson_generator.cpp 25KB v8_generator.cpp 24KB FilterEvaluator.cpp 24KB TestMonitor.cpp 24KB main.cpp 24KB monitor.cpp 24KB RtpsUdpSendStrategy.cpp 24KB Stun.cpp 23KB FileSystemStorage.cpp 23KB main.cpp 22KB DataSampleHeader.cpp 22KB RTDServer.cpp 22KB main.cpp 21KB MultiTopicTest.cpp 21KB subscriber.cpp 21KB共 2000 条
- 1
- 2
- 3
- 4
- 5
- 6
- 20
评论1