Inter-Transport Communication » History » Version 5
Version 4 (J. Moringen, 06/23/2011 01:46 AM) → Version 5/6 (J. Moringen, 06/25/2011 08:06 PM)
h1. Inter-Transport Communication
h2. Introduction
!>inter-transport-simplified.png!
Inter-transport communication becomes necessary, when participants that connect to the bus using different transport mechanisms want to communicate.
h2. Inter-Transport Setup
!>inter-transport.png!
This page describes how to setup [[Glossary|participants]] for inter-transport communication using following scenario which is illustrated in the figure to the right: below:
* Participants reside in two separate processes
** One process is an instance of the program @inprocessAndSpread@
*** There is one @Informer@ in the process. It has two connectors
**** One connector for the Spread transport
**** One connector for the inprocess transport
*** There is one @Listener@ in the process. It has two connectors
**** One connector for the Spread transport
**** One connector for the inprocess transport
** The other process is an instance of the program @spreadOnly@
*** There is one @Listener@ in the. It has a single connector for the Spread transport.
h2. Inter-Transport Setup
There are two ways to attach multiple transports to participants:
# Via [[Configuration|configuration options]] (config file, environment variables, etc.)
# Programmatically
These two alternatives are described below.
h2. Via Configuration Options
When configured via the configuration mechanism, the multi-transport setup will have a global effect in the following sense: it will affect all participants in all processes which are not explicitly instantiated with a different set of connectors.
In addition to the Spread transport which is (currently) enabled by default, other transports can be enabled globally using a configuration file fragment like this:
<pre>
[transport.inprocess]
enabled = 1
</pre>
h2. Programmatically (C++)
The set of transports used by individual participants or as a default by all newly created participants can be configured by modifying @ParticipantConfig::Transport@ objects. These objects contain, among other things, an option which controls whether a particular transport is enabled. A modified @ParticipantConfig@ object can be used in two ways:
* As new default participant configuration for the entire process
* As a configuration for one or more individual participants
These alternatives are discussed in the following sections.
h3. Globally for a Process
The example programs @inprocessAndSpread.cpp@ and @spreadOnly.cpp@ implement the inter-transport setup described above by modifying the default participant configuration in the @inprocessAndSpread@ process to include the inprocess transport.
The source code of both programs is available here:
source:trunk/cpp/core/examples/inter_transport/inprocessAndSpread.cpp
source:trunk/cpp/core/examples/inter_transport/spreadOnly.cpp
h3. Locally for a Participant
In order to use a prepared @ParticipantConfig@ object only locally instead of installing it as a global default, it can be passed to the following methods:
* @Factory::createReader@
* @Factory::createListener@
* @Factory::createInformer@
In each of these cases, the modified configuration options will only effect the participant created by the method call.
h2. Introduction
!>inter-transport-simplified.png!
Inter-transport communication becomes necessary, when participants that connect to the bus using different transport mechanisms want to communicate.
h2. Inter-Transport Setup
!>inter-transport.png!
This page describes how to setup [[Glossary|participants]] for inter-transport communication using following scenario which is illustrated in the figure to the right: below:
* Participants reside in two separate processes
** One process is an instance of the program @inprocessAndSpread@
*** There is one @Informer@ in the process. It has two connectors
**** One connector for the Spread transport
**** One connector for the inprocess transport
*** There is one @Listener@ in the process. It has two connectors
**** One connector for the Spread transport
**** One connector for the inprocess transport
** The other process is an instance of the program @spreadOnly@
*** There is one @Listener@ in the. It has a single connector for the Spread transport.
h2. Inter-Transport Setup
There are two ways to attach multiple transports to participants:
# Via [[Configuration|configuration options]] (config file, environment variables, etc.)
# Programmatically
These two alternatives are described below.
h2. Via Configuration Options
When configured via the configuration mechanism, the multi-transport setup will have a global effect in the following sense: it will affect all participants in all processes which are not explicitly instantiated with a different set of connectors.
In addition to the Spread transport which is (currently) enabled by default, other transports can be enabled globally using a configuration file fragment like this:
<pre>
[transport.inprocess]
enabled = 1
</pre>
h2. Programmatically (C++)
The set of transports used by individual participants or as a default by all newly created participants can be configured by modifying @ParticipantConfig::Transport@ objects. These objects contain, among other things, an option which controls whether a particular transport is enabled. A modified @ParticipantConfig@ object can be used in two ways:
* As new default participant configuration for the entire process
* As a configuration for one or more individual participants
These alternatives are discussed in the following sections.
h3. Globally for a Process
The example programs @inprocessAndSpread.cpp@ and @spreadOnly.cpp@ implement the inter-transport setup described above by modifying the default participant configuration in the @inprocessAndSpread@ process to include the inprocess transport.
The source code of both programs is available here:
source:trunk/cpp/core/examples/inter_transport/inprocessAndSpread.cpp
source:trunk/cpp/core/examples/inter_transport/spreadOnly.cpp
h3. Locally for a Participant
In order to use a prepared @ParticipantConfig@ object only locally instead of installing it as a global default, it can be passed to the following methods:
* @Factory::createReader@
* @Factory::createListener@
* @Factory::createInformer@
In each of these cases, the modified configuration options will only effect the participant created by the method call.