|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (10)
View Page Historyh1. Setting up a simple domain-to-domain propagation
h2. Provider Partner
Let's consider two domains A and B.
The number of containers in each of the domain is not important here: we must only select for each one container onto which the Gateway BC and its SU will deployed.
The number of containers in each of the domain is not important here: we must only select for each one container onto which the Gateway BC and its SU will deployed.
h2. Consumer Partner
The domain A will act as the provider domain and will thus declare in its SU a set of Consumes as well as information needed to identify the consumer domain.
The domain B will act as the consumer domain and will thus declare in its SU the information needed to connect to the provider domain.
Let's consider that A will propagate several services:
* One denoted only by its interface name {{Interface1}} (hence it will matches all endpoints of that interface, potentially with different service name and of course with different endpoint names).
* One denoted by its interface name {{Interface2}} and service name {{Service2}} (hence it will matches all endpoints of that interface and service name).
* One denoted by its interface name {{Interface3}}, service name {{Service3}} and endpoint name {{endpoint3}} (hence it will match exactly one endpoint).
h2. Provider Domain A
For the provider domain, it is necessary to both declare a Consumes SU and a transport listener in the component.
h3. Consumes SU
The Consumes SU deployed on the Domain A is as follow:
{code:lang=xml}
<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jbi="http://java.sun.com/xml/ns/jbi"
xmlns:cdk="http://petals.ow2.org/components/extensions/version-5" xmlns:g="http://petals.ow2.org/components/petals-bc-gateway/version-1.0"
xmlns:test="http://test/">
<jbi:services binding-component="true">
<jbi:consumes interface-name="test:Interface1">
<!-- CDK specific elements -->
<cdk:mep xsi:nil="true" />
<!-- Component specific elements -->
<g:consumer domain="domainB" />
</jbi:consumes>
<jbi:consumes interface-name="test:Interface2" service-name="test:Service2">
<!-- CDK specific elements -->
<cdk:mep xsi:nil="true" />
<!-- Component specific elements -->
<g:consumer domain="domainB" />
</jbi:consumes>
<jbi:consumes interface-name="test:Interface3" service-name="test:Service3" endpoint-name="endpoint3">
<!-- CDK specific elements -->
<cdk:mep xsi:nil="true" />
<!-- Component specific elements -->
<g:consumer domain="domainB" />
</jbi:consumes>
<g:consumer-domain id="domainB" transport="transport1">
<g:auth-name>UniquelySharedBetweenA&B</g:auth-name>
</g:consumer-domain>
</jbi:services>
</jbi:jbi>{code}
Here we see we chose to use the authentication name {{UniquelySharedBetweenA&B}} and the consumer domain will need to know this information.
{warning}The authentication name is +NOT+ meant to introduce security in the use of the Gateway BC: for that it is necessary to use [SSL|#ssl]!{warning}
h3. Component's Transport Listener
As we can see the Consumes SU relies on the existence of a transport called {{transport1}}.
By default there is no pre-configured transport listener on the Gateway BC but there is multiple ways to define them statically (see [#component-configuration] below) or dynamically with Petals CLI (see [petalsclisnapshot:Petals BC Gateway tooling]).
For example, we can use the following CLI command to create the transport listener before deploying the Consumes SU:
{code}
> bc-gateway.add-transport-listener -i transport1 -p 7500
{code}
Here we can see we chose the port 7500 and the consumer domain will need to know this information.
h2. Consumer Domain B
{anchor:ssl}
Let's consider that A will propagate several services:
* One denoted only by its interface name {{Interface1}} (hence it will matches all endpoints of that interface, potentially with different service name and of course with different endpoint names).
* One denoted by its interface name {{Interface2}} and service name {{Service2}} (hence it will matches all endpoints of that interface and service name).
* One denoted by its interface name {{Interface3}}, service name {{Service3}} and endpoint name {{endpoint3}} (hence it will match exactly one endpoint).
h2. Provider Domain A
For the provider domain, it is necessary to both declare a Consumes SU and a transport listener in the component.
h3. Consumes SU
The Consumes SU deployed on the Domain A is as follow:
{code:lang=xml}
<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jbi="http://java.sun.com/xml/ns/jbi"
xmlns:cdk="http://petals.ow2.org/components/extensions/version-5" xmlns:g="http://petals.ow2.org/components/petals-bc-gateway/version-1.0"
xmlns:test="http://test/">
<jbi:services binding-component="true">
<jbi:consumes interface-name="test:Interface1">
<!-- CDK specific elements -->
<cdk:mep xsi:nil="true" />
<!-- Component specific elements -->
<g:consumer domain="domainB" />
</jbi:consumes>
<jbi:consumes interface-name="test:Interface2" service-name="test:Service2">
<!-- CDK specific elements -->
<cdk:mep xsi:nil="true" />
<!-- Component specific elements -->
<g:consumer domain="domainB" />
</jbi:consumes>
<jbi:consumes interface-name="test:Interface3" service-name="test:Service3" endpoint-name="endpoint3">
<!-- CDK specific elements -->
<cdk:mep xsi:nil="true" />
<!-- Component specific elements -->
<g:consumer domain="domainB" />
</jbi:consumes>
<g:consumer-domain id="domainB" transport="transport1">
<g:auth-name>UniquelySharedBetweenA&B</g:auth-name>
</g:consumer-domain>
</jbi:services>
</jbi:jbi>{code}
Here we see we chose to use the authentication name {{UniquelySharedBetweenA&B}} and the consumer domain will need to know this information.
{warning}The authentication name is +NOT+ meant to introduce security in the use of the Gateway BC: for that it is necessary to use [SSL|#ssl]!{warning}
h3. Component's Transport Listener
As we can see the Consumes SU relies on the existence of a transport called {{transport1}}.
By default there is no pre-configured transport listener on the Gateway BC but there is multiple ways to define them statically (see [#component-configuration] below) or dynamically with Petals CLI (see [petalsclisnapshot:Petals BC Gateway tooling]).
For example, we can use the following CLI command to create the transport listener before deploying the Consumes SU:
{code}
> bc-gateway.add-transport-listener -i transport1 -p 7500
{code}
Here we can see we chose the port 7500 and the consumer domain will need to know this information.
h2. Consumer Domain B
{anchor:ssl}
h1. Using SSL to authenticate and encrypt exchanges between domains
h2. Provider Partner
h2. Provider Domain A
h2. Consumer Partner
h2. Consumer Domain B
h1. Service Rewriting
h2. Provides
{anchor:component-configuration}
h1. Component Configuration