With our current community-edition (V6.7), you unfortunately can’t configure multiple DDSI-services in a single ‘standalone-application’ (also called a ‘single-process‘ deployment mode, which is the deployment model supported by our community edition).
Our commercially supported versions include the ability to deploy applications in a so-called ‘federated deployment‘ mode where a set of applications share a single set of middleware-services and where we use a shared-memory segment to ‘contain’ all nodal DDS data (thus allowing for extreme ‘nodal-scalability‘ allowing for hundreds of applications on a machine enjoying ‘single-copy data-sharing where there’s at most 1 copy of the data in the shared-memory, independent of the number of appliations, as well as very low End-to-End latency within a machine of appr. 10 us on an i7 based machine).
Now when you utilize that federated mode you can configure multiple DDSI-services as part of that federation where each DDSI-service ‘manages’ 1 network(-adaptor). We can also dynamically ‘bridge’ between networks using such a configuration (in which case there might be no application at all running on the federation, but only 2 DDSI-services and a so-called ‘bridge-service’ that bridges data based on emerging interest, so fully dynamic and where you can furthermore specify white/black-lists to confine certain data on specific networks).
Alternatively and especially if you want to create an hierarchical system where data on a LAN should be selectively forward to either another LAN or into a cloud, we also have smart routing-services called Vortex-Fog and/or Vortex-Cloud that provide dynamic-discovery-based selective routing of DDSI-based data between LAN’s directly or indirectly via a Vortex-Cloud service deployed on a private or public cloud. These solutions implement a transparent ‘extension’ of the ‘DDS-backbone’ where data gets routed from writers to readers based on emerging interest and where these Vortex Fog services mediate between using multicast on the LAN and using (secure-)TCP connectivity over the WAN (towards either another LAN-based ‘FOG’ subsystem or route their data securely (i.e. using authentication, access-control and encryption) towards a Vortex-Cloud service deployed on a public or private cloud.
So plenty of features to assure that we can very efficiently (and transparently) ‘extend’ the reach of the logical “DDS-backbone” towards potentially hierarchical compositions of nodes/devices, LAN’s and/or WAN’s.