E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (6)
View Page History
...
{section} This bridge will mirror a set of endpoints from one domain to another according to a configuration describing which service must be propagated.
{petalslink}link to the topology/domain doc.{petalslink}
{tip}See also the documentation for [Topologies and Domains|petalsesbsnapshot:Topology Configuration] to better understand domains.{tip}
From the point of view of this BC, one (or several in case of HA) container in each Petals domain will either play the role of provider domain or consumer domain:
* A provider domain, materialised with Consumes Service Units, propagates services of its domain to a consumer domain that connects to it via one or several links.
* A consumer domain, materialised with Provides Service Units, connects to a provider domain and create endpoints for the propagated services in its domain.
By default the Gateway BC takes care of reconnecting in case of disconnection, polling for changes in the activated endpoints to keep the consumer domain a mirror of the provider domain and it is possible to rewrite propagated services names in the consumer domain if needed.
...The Provides SU (deployed in a consumer domain) declares a list of provider domains (usually only one) to which they will connect and propagate services from.
{petalslink}add schemas{petalslink}
The particularity of the Gateway BC is that, while Consumes SUs explicitly define which are the consumed services that are going to be propagated from their domain, Provides SUs do not have to (but can) define the services that are going to be propagated to their domain: these are inferred based on the services actually propagated by the provider domain.
Furthermore, only the services that are actually activated on the provider domain are actually propagated: in this way, the consumer domain will constantly mirror the current reality of the provider domain.
Furthermore, only the services that are actually activated on the provider domain are actually propagated: in this way, the consumer domain will constantly mirror the current reality of the provider domain.
...Technically, the component onto which the Consumes SUs are deployed must define how to listen to incoming connections (on a host and TCP port currently) from Provides SUs.
These are called transport listeners and can be shared between multiple Consumes SUs if needed (to avoid duplicating open ports) or not (to isolate certain consumer domains).
These are called transport listeners and can be shared between multiple Consumes SUs if needed (to avoid duplicating open ports) or not (to isolate certain consumer domains).
{multi-excerpt}
{column}
{column}
...