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
* dynamic : a container can be attached to or detached from a running sub-domain, without requiring a full start/stop of the sub-domain
h2. Choosing the sub-domain mode
The sub-domain mode 'static' is recommended in following use-case:
* you want to prevent to add or remove container from your sub-domain,
* you don't plan hot topology refactoring
If you have a worst constraint about the availability of the Petals ESB (24/24, 7/7), you shoudl use the mode 'dynamic' to be able to apply topology changes without stopping the Petals ESB.
h2. 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}
See : [^static-topology-sample.xml]
h2. 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}
See : [^dynamic-topology-sample.xml]
h1. Declaring containers configurations
As we have seen, the {{topology.xml}} resource is used to declare the configuration of a Petals ESB cluster.
h2. Generic container configuration
Each Petals ESB container declared within must conforms to the following XML structure :
{code:lang=xml}
<tns:container name="0">
<tns:description>description of the container 0</tns:description>
<tns:host>localhost</tns:host>
<tns:user>petals</tns:user>
<tns:password>petals</tns:password>
<tns:webservice-service>
<tns:port>7600</tns:port>
<tns:prefix>petals/ws</tns:prefix>
</tns:webservice-service>
<tns:jmx-service>
<tns:rmi-port>7700</tns:rmi-port>
</tns:jmx-service>
<tns:transport-service>
<tns:tcp-port>7800</tns:tcp-port>
</tns:transport-service>
</tns:container>
{code}
The meaning of these properties is summarized in the following table :
{center}
|| Property name || Default value || Required || Description ||
| {{name}} | 0 | yes | name of the container |
| {{description}} | description of the container 0 | no | description of the container |
| {{host}} | localhost | yes | host name or ip address of the container |
| {{user}} | petals | no | jmx username |
| {{password}} | petals | no | jmx password |
|| {{webservice-service}} || || || ||
| {{port}} | 7600 | yes | administration webservices port (topology, information, ...) |
| {{prefix}} | petals/ws | yes | path of the webservice |
|| {{jmx-service}} || || || ||
| {{rmi-port}} | 7700 | yes | jmx service port |
|| {{transport-service}} || || || ||
| {{tcp-port}} | 7800 | yes |NIO transporter port |
{center}
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}}.
{noformat}
#This property specifies the name of the container. In distributed mode, this property is mandatory
#and must match a container name in the topology.xml file
petals.container.name=0
{noformat}
The container name given to the {{petals.container.name}} property must be declared within the {{topology.xml}} file, otherwise, Petals ESB won't be able to start. This mean that you must have declared the local container configuration within the {{topology.xml}} file.
h1. Appendix
h2. Topology XML Schema
E-mail
...