Configuration

The configuration of the BlackTie components is expressed in standard XML files validated against a set of schemas defined and imposed by the BlackTie system.

A discussion of the available configuration options within the XML files themselves is beyond the remit of this article, however assistance on configuring specific components can be found on our wiki pages.

Of particular note here is that the configuration has been designed to support being held within a central configuration management system such as Subversion (svn). Although this is an optional method of distributing the configuration files and may be superseded in later revisions of the project, it is currently the most suitable method.

Domain level

At the domain level exist two configuration files, the btconfig.xml (validated by a similarly named .xsd file). The btconfig.xml file is responsible for describing the location of the administered services (naming service, transaction manager, etc).

Server level

The group level is used to record the collection of services that form a server/services grouping. It is required that any server that uses the configuration from the group level is able to support execution of all the services expected from that group.

Below the domain level configuration, exists a sub-aggregation type to collect the service configurations available from specific server groups. In the diagram these are called tomsGroup1 and tomsGroup2. You can also see that the service configuration itself is optional and is only used to override the defaults present in the actual code itself. The btconfig.xml file lists the services and their initial state (advertised/not) and function names and libraries to bind to the name.

NOTE: A further option when adding the configuration files to a repository such as svn is to fully enforce permissions in the repository and to allocate svn accounts on a per server group/client basis. For example, the clients may only be allowed to download the btconfig.xml, whereas, the server in tomsGroup2 may only be able to download btconfig.xml. The advantage here is that passwords which may/may not be present in configuration files would only be visible to the minimal number of components

A final point to note is that if there is only one intended server (group) in the application, the convention we have adopted is to assume the existence of a server “default”. This negates the need for users to indicate the name of the server (group) during server start-up.

NOTE: If the folder default does not exist or the name of a folder to use was not passed to the server at start-up, then the server shall fail to launch.

Clusters

Servers that checkout and run the same configuration (group) act as a cluster.

Click to go on to BlackTie Architecture (Page 4)