E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (45)
View Page History
...
{section} h1. On the Petals ESB Topology
Petals ESB is a fully distributed ESB that features many types of topology both dynamically or statically. The topology of a Petals ESB cluster can be configured through a topology definition (i.e., {{topology.xml}}) and [server properties|Container Configuration] (i.e., {{server.properties}}).
This document will explain to you how to properly configure the topology of your Petals ESB cluster.
...h1. Topology composition
A Petals ESB cluster is composed of a *domain* divided into *sub-domains* that contain the *containers*. A sub-domain aims to limit the visibility of service endpoints.
A Petals ESB cluster is *domain* that contains the *containers*. A domain aims to limit the visibility of service endpoints.
Inside a sub-domain:
* all service providers can be seen by all service consumers without restrictions,
* all service providers must be accessible directly to all service consumers.
* all service providers must be accessible directly to all service consumers.
Using a gateway, it is possible to interact between sub-domains pairs:
* by default, service endpoints of a sub-domain are not propagated to other sub-domains,
* the gateway is configured to propagated a selection of service endpoints in both ways,
* a message sent from a service consumer located into the sub-domain #1 to a service provider located in sub-domain #2 will pass through the gateway.
*Note: in the current version of Petals ESB, the notion "sub-domain" is not fully implemented, and the "gateway" is not yet available. The processing is as if the domain contains only one sub-domain: all service endpoints can be seen by all.*
{note}For now the Gateway is not implemented, it will be in the future as a Binding Component, see PETALSDISTRIB-175 for details{note}
{gliffy:name=topology-subdomain|version=5|size=L|align=center}
h1. Configuring the sub-domain
The sub-domain configuration is composed of several part:
* the sub-domain identification,
* the sub-domain mode,
* the sub-domain registry configuration.
h2. Configuring the sub-domain mode
A Petals sub-domain supports two different modes :
* static : no new container can be added to a running Petals sub-domain. All containers of the sub-domain must be stop and restart to take into account changes
* static: no new container can be added to a running Petals domain. All containers of the domain must be stopped and restarted to take into account changes.
* dynamic : a container can be attached to or detached from a running sub-domain, domain without requiring a full start/stop of the sub-domain domain.
h3. Choosing the sub-domain mode
The sub-domain mode 'static' is recommended in following use-cases:
* you want to prevent forbid to add or remove container from your sub-domain,
* you don't plan to do hot topology refactoring
If you have a worst constraint about the availability of the Petals ESB (24/24, 7/7), you shoudl should use the mode 'dynamic' to be able to apply topology changes without stopping the Petals ESB.
h3. Using the static mode
To use the static mode, in the sub-domain element of the topology definition, you just have to change the mode property to *static* :
{code:lang=xml}<tns:sub-domain name="your-subdomain-name" mode="static">{code}
{code:lang=xml}<tns:domain name="your-domain-name" mode="static">{code}
See : [^static-topology-sample.xml]
...h3. Using the dynamic mode
To use the dynamic mode, in the sub-domain element of the topology definition, you just have to change the mode property to *dynamic* :
{code:lang=xml}<tns:sub-domain name="your-sub-domain-name" mode="dynamic">{code}
{code:lang=xml}<tns:domain name="your-domain-name" mode="dynamic">{code}
See : [^dynamic-topology-sample.xml]
h2. Configuring the sub-domain registry
h3. Configuring the implementation to use
Firstly, the The implementation of the sub-domain registry must can be defined through the tag '{{registry-implementation}}' that contains the class name of the implementation to use:
{code}
<tns:sub-domain name="subdomain-0" mode="static" xmlns:tns="http://petals.ow2.org/topology">
<tns:domain name="domain-0" mode="static" xmlns:tns="http://petals.ow2.org/topology">
...
<tns:registry-implementation>org.ow2.petals.microkernel.registry.overlay.RegistryOverlayImpl</tns:registry-implementation>
...
<tns:registry-implementation>org.ow2.petals.microkernel.registry.overlay.RegistryOverlayImpl</tns:registry-implementation>
...
</tns:sub-domain>
{code}
The default implementation is the Petals Registry Overlay is used. And the tag '{{registry-implementation}}' cab be omitted.
The tag '{{registry-implementation}}' can be omitted and in that case the default implementation is the Petals Registry Overlay.
h3. Configuring the implementation itself
Secondly, the The implementation itself must be configured using an extension of the sub-domain tag. See the [documentation of the registry implementation|Petals ESB "Registry"#Implementations] for more information.
Example:
{code}
<tns:sub-domain name="subdomain-0" mode="static" xmlns:tns="http://petals.ow2.org/topology">
<tns:domain name="domain-0" mode="static" xmlns:tns="http://petals.ow2.org/topology">
...
<tns:registry-implementation>org.ow2.petals.microkernel.registry.overlay.RegistryOverlayImpl</tns:registry-implementation>
<tns:registry-implementation>org.ow2.petals.microkernel.registry.overlay.RegistryOverlayImpl</tns:registry-implementation>
... </registry:overlay-members>
</registry:configuration>
</registry:configuration>
</tns:sub-domain>
{code}
...h2. Generic container configuration
Each Petals ESB container declared within must conforms to the following XML structure : structure:
{code:lang=xml}
...h1. Configuring the local container
As we have seen, the {{topology.xml}} file contains the declaration of a Petals ESB cluster. This information is not sufficient to determine which configuration must be chosen by the local container at startup. To do so, you must give a container name declared within the {{topology.xml}} file to the property {{petals.container.name}} declared in the {{server.properties}}.
As we have seen, the {{topology.xml}} file contains the declaration of many Petals ESB containers: to determine which configuration must be used by the local container at startup, you must specify one of the container name to the property {{petals.container.name}} declared in the {{server.properties}}.
{noformat}
...