The BusinessEvents design-time project is deployed as a BusinessEvents application. When Cache object management is used, the deployment can span multiple host servers.
All of the deployment methods use two resources: an EAR file and a cluster deployment descriptor, which is an XML file. To deploy using BusinessEvents Monitoring and Management, you also need a site topology file.
The Enterprise Archive Resource (EAR) is the deployable version of a BusinessEvents application. The EAR file contains runtime version of the project ontology, the channel definitions, the state machines (if TIBCO BusinessEvents Data Modeling add-on software is used), and so on. When you are finished designing the project in BusinessEvents Studio, you simply choose a menu option to build the EAR.
Also in the CDD you configure the agents and processing units (engines) that will use the rules and ontology types you designed in your project.
Each engine equates to one processing unit, which runs in one JVM (Java Virtual Machine). One processing unit can host multiple agents, except in the case of a cache agent. A processing unit that hosts a cache agent cannot host any other agents. Each BusinessEvents agent is a runtime component of the overall application.
Different kinds of agents play different roles in a large application. For example, inference agents perform rule evaluation, and cache agents manage the object instances generated and used by the inference agents (when the Cache object management option is used). To include multiple agents in an engine instance you add multiple BusinessEvents agent classes in one processing unit.
Before you can use MM for deployment, you define the site topology using the site topology editor in BusinessEvents Studio. You can also edit the underlying XML file directly. However, In BusinessEvents Studio, the site topology editor introspects the CDD and EAR files to provide project information used during configuration.
In the site topology editor you configure deployment units and host machines. Each deployment unit consists of one or more processing units, and related deploy-time settings. Each host machine is configured with details such as the software used for remote deployment. Then you bind deployment units to the desired host machines.
Once you have configured MM to communicate with the cluster to be monitored and defined the site topology file, you can use the MM Console to deploy, stop and start, pause, and resume processing units.
MM can also monitor units you start in other ways: all it needs is the PID of the JVM running the processing unit. However it can’t start engines that are not predefined in the site topology file.
The BusinessEvents Monitoring and Management (MM) component maintains a history of statistics, continuously queries the deployed engines for their status, and invokes methods on engines, as specified by the administrator. Various overview panels and panes provide graphical views and alerts about the health of the cluster. You can configure the health thresholds as desired.
You can also use TIBCO Administrator features for monitoring and management. However they are not specialized for BusinessEvents in the ways that the MM component features are.
TIBCO BusinessEvents includes a set of TIBCO Hawk microagent methods that allow you to manage your TIBCO BusinessEvents deployment using TIBCO Hawk. These functions are listed and described in
Appendix E, TIBCO Hawk Microagent Methods. These are useful if you do not use BusinessEvents Monitoring and Management. BusinessEvents Monitoring and Management provides a similar set of methods.
Depending on the changes made to your BusinessEvents project, you may be able to replace an EAR file for a BusinessEvents project with an updated one, without stopping the BusinessEvents engine. This feature is referred to as hot deployment. For more information about the BusinessEvents hot deployment feature, including the project changes that are supported, see
TIBCO BusinessEvents Administration.