Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 23 Cluster Deployment Descriptor (CDD) : Cluster Deployment Descriptor Overview

Cluster Deployment Descriptor Overview
TIBCO BusinessEvents Express  Content relating to Cache OM and backing store does not apply to TIBCO BusinessEvents Express edition.
The Cluster Deployment Descriptor (CDD) is an XML file used to configure a project for deployment. One EAR file and one CDD file define all the settings for all the engines and agents you want to deploy for a single application.
Because the deploy-time configuration settings for all processing units are in the CDD file, you do not have to rebuild the EAR file to make changes to deploy-time settings. However, as desired, you can use only the copy of the CDD file that is in the EAR, for tighter control and uniformity.
When you deploy a processing unit, you specify these items:
The CDD file you specify can be in the file system or in the EAR file. To specify a CDD located in an EAR file, provide its project path and name.
You can configure multiple CDD files for a project for different purposes such as testing a design, trying out different object management options, dividing the work differently between agents and processing units (engines), and so on. However you use the same CDD file when deploying all the processing units for an application.
Maintaining the CDD File
The CDD is an XML file and you maintain it using the CDD editor.
Working with the CDD Editor
The CDD editor is organized into various tabs. Predefined fields make it easy to maintain common settings. Validation checks assist correct configuration. Settings for less common options are configured by adding properties to property sheets on the CDD editor’s tabs.
Editing the CDD After Deployment
Edit the CDD file in Studio and copy the output to the deployment location as needed.
Great care must be taken to ensure that the deployed CDD is edited correctly and that all CDD files are kept in sync for straightforward project management. If an emergency change is made to the deploy-time file, ensure that such changes are added back to the design-time version of the file and maintained in TIBCO BusinessEvents Studio (and put under source control), so that subsequent redeployment can be done without the need for manual changes.
Direct Editing is Discouraged
Although the CDD file can be edited directly, doing so is strongly discouraged. The file is complex, and must adhere to the schema. The schema itself may change in a release, and migration is handled using TIBCO BusinessEvents Studio.
Defining and Configuring the Cluster and Object Management Type
Of the object management (OM) types available, the most commonly used type for production systems is Cache OM. Cache OM is generally used with a backing store for persistence of data generated in the engine. See TIBCO BusinessEvents Architect’s Guide for an overview of clusters and object management types.
When you configure Cache OM, you must first choose a cache provider, TIBCO or Oracle. The internal TIBCO cache provider, TIBCO BusinessEvents DataGrid, is the default choice. Or you can use a supported version of Oracle Coherence, for which you have a license that is appropriate for your usage. See Chapter 24, Cache OM and Cluster Configuration.
For In Memory OM, no object management configuration is required because all objects are in memory and do not persist.
Configuring Management of Domain (Entity) Object Instances
If you choose Cache OM, you must also configure how to manage the domain (that is, entity) object instances. For example you can determine whether the instances are flushed from the Rete network after each RTC (as is generally recommended) or are kept in the cache.
If you set up a backing store, you can specify additional settings. For example you can define a subset of ontology object instances to be stored in the backing store, and you can control which (if any) object instances are loaded into the cache from the backing store at system startup.
See Chapter 28, Domain Objects Configuration and Chapter 26, Backing Store Configuration.
Defining and Configuring Agent Classes and Processing Units
Cache OM uses multiple processing units, each running one or more agents. You define the agent classes and processing units in the CDD.
Agent Classes
Agent classes define the different sorts of agents you can deploy.
In Memory OM uses only inference agents, and each agent operates independently. With Cache OM, inference agents share the cache data.
For inference agent classes, you distribute a project’s resources among the agent classes to define the specific work each agent will do.
The following types of agent classes require the use of Cache OM:
Collections Tab
At the Collections tab, you can (optionally) group rules, rule functions, and destinations into collections so that they can be easily assigned to agent classes, to simplify agent class configuration.
The Collections tab is also where you define log configurations, which are assigned to processing units (engines).
Startup and Shutdown Rule Functions  At the Collections tab, put rule functions for use at start up (startup rule functions) into different groups from those used at shut down (shutdown rule functions) and arrange them in the order in which they are to be executed. Then you can select them appropriately at the agent classes tab.
See Configuring Agent Classes (All OM Types) and Configuring Collections of Rules, Rule Functions, and Destinations.
Processing Units
Processing units deploy as engines within which the agents run. In the Processing Units tab, you define which agents to include in the processing unit, and which logging configuration to use. Depending on the OM, you also configure some additional settings.
See Configuring Processing Units (All OM Types).

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved