There are a number of samples that can be found in the samples/docker/applications directory of your Apama installation. The Simple sample that is referenced in Using Docker Compose with Apama contains a Hello world application. The other samples in the above directory cover more complex use cases. These samples build upon the base image and demonstrate how to use a dockerized Apama correlator to build your own application or service.

The README.txt files that are provided in the samples/docker/applications directory and in each of the individual sample subdirectories guide you through the process of building and running. The samples demonstrate various ways in which Docker can be used to deploy Apama and related Software AG products. They also demonstrate interactions between Docker containers and normal applications such as dashboards.

This sample deploys Apama's Weather demo. It demonstrates that various Apama components can be run in distinct containers. The sample creates a correlator container and a separate container for the dashboard server which connects to the correlator just as in the non-Docker Weather sample. This sample also creates a Compose network called front which is used to allow both containers to communicate.

You can view this network using the following command:

This sample starts an IAF in a container, which connects to a correlator running in another container. The IAF is running the File transport. An EPL application is deployed into the correlator, which requests the contents of a file inputFile.txt from the File adapter, and then directs it to write those contents back out to another file outputFile.txt.

The output file is stored within the container, but can be retrieved via Docker:

Earlier samples showed how to use Dockerfiles to create derived images that give Apama components from the base image access to configuration and EPL code. However, this approach only suffices for static data that can be reproduced by copying in files from a canonical source. For containers to share dynamic data, they need a live view on that data. This is provided by a Docker feature called volumes, which allows containers to share parts of their file system with each other.

This sample contains a toy application MemoryStoreCounter.mon that makes use of the MemoryStore to lay down persistent state on disk in the form of a number that increments each time the monitor is loaded. While the correlator container is the one reading and writing to the MemoryStore, the persistent file is on a Docker volume which is persisted between container restarts.

You can view the created volume using the following command:

Docker volumes give you the ability to manage data that has a different lifecycle to the container that uses it. In an application like this, you can replace the other containers with equivalents that are based on a newer version of Apama. After bringing them up again, the correlator will still have access to the MemoryStore data that it wrote in a previous iteration, as this data is owned by the volume.

This sample demonstrates two Apama correlators communicating with each other via a Universal Messaging realm server, all in separate containers. This sample requires an installation of Universal Messaging.

This sample demonstrates a use of Docker that tries to approximate a real world scenario and requires Terracotta. It shows the use of replicas and handling dependencies on startup in the docker-compose.yml configuration file. After starting the Terracotta container which provides the store, the correlators are started. The user then sends through events to a correlator that processes the events according to the query parameters. The results are then updated in the Terracotta store and shared with all the correlators. This can be demonstrated by sending through events to a second correlator container created by the deployment.

This sample demonstrates how to use Docker secrets to set variables in correlator configuration files. These can then be loaded at runtime into a correlator.