Deployed dashboards connect to one or more Correlators via a Dashboard Data Server. As the Scenarios in a Correlator run and their variables change, update events are sent to all connected dashboards. When a dashboard receives an update event, it updates its display in real time to show the behavior of the Scenarios. User interactions with the dashboard, such as creating an instance of a scenario, result in control events being sent via the Data Server to the Correlator.

Applet and Web Start dashboards communicate with the Data Server via servlets running on an application server.

As illustrated in Figure 1, with applet and WebStart deployments, dashboards communicate with your application server, which communicates with the Dashboard Data Server. The Data Server mediates access to the Correlator.

Simple, thin-client, Web-page dashboards communicate with the Display Server via servlets running on your application server bundled with your Apama installation.

As illustrated in Figure 2, with thin-client, Web-page deployments, dashboards communicate with your application server, which communicates with the Dashboard Display Server. The Display Server mediates access to the Correlator.

Locally-deployed dashboards communicate directly with the Data Server.

As illustrated in Figure 3, with local deployments, dashboards communicate with the Dashboard Data Server, which communicates.

You can scale your application by adding Data Servers to your configuration. Each Correlator can communicate with multiple Data Servers, and each Data Server can communicate with multiple Correlators.

As illustrated in Figure 4, each correlator can communicate with multiple Data Servers and Display Servers. Each Data Server and Display Server can communicate with multiple Correlators.

Deployed dashboards have a unique associated default Data Server or Display Server, but advanced users can associate non-default Data Servers with specific attachments and commands. This provides additional scalability by allowing loads to be distributed among multiple servers. This is particularly useful for Display Server deployments. By deploying one or more Data Servers behind a Display Server, the labor of display building can be separated from the labor of data handling. The Display Server can be dedicated to building displays, while the overhead of data handling is offloaded to Data Servers. See Working with multiple Data Servers for more information.