Features

The component BC Gateway enables to create secured (encrypted and authenticated) bridges between Petals domains governed by separate entities.

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.

It is possible to rewrite propagated services (interface and service names) in the consumer domain if needed.

Basic Concepts

The objective of the Gateway BC is to propagate services from a domain to another one.

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.

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.