Now that we have our three components completed, it's time to test them out.
Here is the start up order for our processes:

1. Start the Qpid Broker first
2. Video Display
3. Face Detection
4. Camera Capture last

Why do we need to start them in a particular order?
None of our comonents check with the broker to see if any other components are connected.
If we start the Camera Capture first, then it will fill up the queue with frames. When the other components connect they will need to process all the old images before they can get the current frames.
If the Camera Capture and Face Detect are started before the Video Display, the face detect results will have a delay. When the Face Detection acknowledges the image from the CameraCapture, if it is the only receiver connected to the VideoTopic, the image will be removed from the topic. When the Video Display finally connects, it will begin receiving the current frames along with the Face Detect. However, when it fetches the ImageRegions from the FaceQueue, they will be from old images.
These types of issues can be handled by monitoring the status of the queues and topics.
To further ensure the Video Display is getting the correct data, we can have the Camera Capture set the the 'id' field of the PortableImage. The Face Detector could then set the 'imageId' field of the ImageRegions. When the Video Display receives a PortableImage and ImageRegions, it can check that they go together.
Here is a sketch of how our processes are working together:



However, we didn't all that to make a simple face detector. We have some basic compnents for a distributed image processing system. Let's look at what else we can do with these. (There is no accompanying code for the examples ahead.) One immediate feature is that we can configure our broker to be available on the network, and we can move some of the components to another computer. I can move the Camera Capture process to another computer, and begin streaming the camera feed across the network.

What if we want to watch the same Video Display on our computer and another computer. If we launch a second Video Display process, they will each receive a copy of the current camera frame from the VideoTopic. However, we are using a queue for our ImageRegions, the FaceQueue. By changing this to a topic we can replicate the ImageRegions for multiple Video Displays. Now we can launch several displays which will show the same video.



Our Face Detector works for faces that are looking at the camera. Supposed we want to dected face profiles as well.
We can use the haar object detector to do this by loading "haarcascade_profileface.xml" instead of "haarcascade_frontalface_default.xml". With a change to the Video Display, we could fetch multiple ImageRegions for each PortableImage. Now we can launch a second Face Detector with a different classifier, and the results from both of them can be displayed in our Video Display.




If we have our two Face Detectors, but want to view the results of each one on it's own video. To do this, we would need to set up each Face Detector to send results to different queues, and have a separate Video Display connected to each queue. And we can now watch the results of different processors on different displays.




For the last example, Avro's compact binary format and json schemas are great for persisting and loading data. When used with Qpid, it can allow for almost effortless logging and replaying of messages passed between components.
In most cases, if we want to save a record of all the messages being passed, it would take little more than using a topic and attaching another receiver. The new receiver would pass the messages to a process that saves Avro binary data to disk.




Later when we want to replay the data, we just load it from disk and send it.