Objective

The purpose of this lab is to introduce actor-model programming principles using picos and introduce actor-model programming patterns. 

Reading and Reference

Read the following:

• Using the Scatter-Gather Pattern to Asynchronously Create Fuse Reports Links to an external site.
• Reactive Programming Patterns: Examples from Fuse Links to an external site.
• Pico-Based Systems Lesson Links to an external site.

The following may be helpful:

• Looping in rules Links to an external site.

Prerequisites

You should have completed:

•  Lab 6: Pico-Based Systems

Implementation Notes

• Be sure to use a correlation identifier string to ensure that you're storing data about the right temperatures.
• You don't have to deal with any failures of the sensors to respond with retries. 
• The sensor management pico might have subscriptions to picos other than the temperature sensors. Be sure you are only asking temperature sensors for reports. 
• The "on final" guard condition Links to an external site. may be helpful for incrementing the report id only on the last iteration of a foreach.
• A collection report is simply a JSON structure that includes the reports from each sensor (you may assume the subscriptions ruleset's skyQuery never fails), a count of how many temperature sensors are in the collection, and a count of how many responded. For example: 

{<report_id>: {"temperature_sensors" : 4,
                  "responding" : 4,
                  "temperatures" : [<temperature reports from sensors>]
                 }
}

Do This

In Lab 6: Pico-Based Systems you created a sensor management pico and the functionality to make it work. You generated temperature reports using a function. That is a good example of synchronous interaction between distributed processes. The report generation depended on everyone returning some result and waits for each one in turn. In this part of the lab, you'll generate a collection temperature report using the scatter-gather pattern. This will generate the report asynchronously. Each sensor pico can work concurrently to get it's temperature and return it. This request isn't big enough that you'll notice much difference between the synchronous and asynchronous methods, but if answering the temperature query took more time, you'd notice. 

1. You will need a rule in the  manage_sensors ruleset that sends an event to each sensor pico (and only sensors) in the collection notifying them that a new temperature report is needed. Be sure there's a correlation ID in the event sent to the sensor picos and that it's propagated. 
2. You will need a rule that listens for the event sent in (1), calls its own temperatures function (do NOT use skyQuery or http for this), and sends an event back to the originator of the event with the result. As you can imagine, the sensor might also need to send its Rx back to the originator so that the originator can differentiate what reports came from whom. The originator is usually the sensor management pico, but don't make assumptions. 
3. You will need a rule in the  manage_sensors ruleset that selects on the event from (2) and stores the results in a collection temperature report. Be sure the report includes a counter of the number of responding sensors. Store the report with the correlation ID as the key. 
4. Add a function that returns a JSON structure with the five latest collection temperature reports. 
5. Generate some reports. Make sure things work. 

Deliverables

Turn in the following:

1. The source URLs for your rulesets
2. Short screencast (< 3 min with sound) showing the report generation process. 
3. Answers to the following questions:

Questions

• Can a sensor be in more than one collection based on the code you wrote? Why or why not? What are the implications of a sensor being in more than one collection? 
• How could you ensure that only certain picos can raise an event that causes a temperature report to be generated? 
• How do the debug logs show that your scatter-gather system worked?
• How can you know a report is done and all the sensors that are going to respond have reported? 
• Given your answer above, how would you recover if the number of responding sensors is less than the total number of sensors?