Petals-BC-Gateway

Features

The component BC Gateway enables to create secured (encrypted and authenticated) bridges between Petals domains governed by separate entities.
This bridge will mirror a set of endpoints from one domain to another according to a configuration describing which service must be propagated.

See also the documentation for Topologies and Domains to better understand domains.

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.

By service, we mean one as defined in a WSDL: it is specified by an interface name and a service name.
Thus, endpoints are not propagated as such and if multiple endpoints of a given service are available in the provider domain, then there will be only one activated service in the consumer domain for all these endpoints.

Usually, an interface name characterises a generic functionality while a service name characterises an implementation of that functionality. On the other hand, an endpoint name is simply a technical mean to locate a given instance of this service in the bus.
Full Size
A Gliffy Diagram named: example-multi-domains

Service Units Configuration

In terms of configuration (i.e., definition of Service Units), this results in two different artefacts: Consumes and Provides SUs.
The Consumes SUs (deployed in a provider domains) declares a list of consumer domains that are allowed to connect to them and to which a selection of services (also defined in the Consumes SU) will be propagated.
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.

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.

Component Transport Listeners

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).

Contributors
No contributors found for: authors on selected page(s)
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.