Deployed dashboards connect to one or more correlators via a dashboard data server. As the DataViews 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 DataViews. User interactions with the dashboard, such as creating an instance of a DataView, result in control events being sent via the data server to the correlator.

Simple, thin-client, web-page dashboards communicate with the display server via servlets that run on your application server. These servlets are bundled with Apama. You must provide your own Java web application server (servlet container). Typically, you install the dashboard servlets in your existing web infrastructure.

The following image shows the process architecture for 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.

The following image shows the process architecture for local deployments. Dashboards communicate with the dashboard data server, which in turn communicates with the correlator(s).

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.

The following image shows the process architecture after you add data servers to your configuration. 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.