Lab 7: Reactive Programming Patterns

  • Due No Due Date
  • Points 100
  • Submitting a text entry box, a website url, a media recording, or a file upload

Objective

The purpose of this lab is to

  • introduce actor-model programming principles using picos
  • introduce actor-model programming patterns
  • use asynchronous style interactions in a distributed system

Reading and Reference

Read or view the following:

 

The following readings might also be helpful: 

Prerequisites

You should have completed:

  •  Lab 6: Subscriptions

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 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>]
                 }
}
  • The rule in the management pico responding to reporting events from sensor will have to count how many sensor picos have reported to know it's done. You can use the rule condition and the postlude to do this. The finally section in the postlude may help with this. If you don't see how to do this, ask the TAs for help. 
  • You can use the sensor emulator ruleset to create a collection of temperature sensor picos. 

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 synchronously queried each sensor pico. 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 its 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 or you had many more sensors in a collection, 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 in each sensor pico that listens for the event sent in (1), and sends an event back to the originator of the event with the most recent temperature reading. The sensor might also need to send its Rx channel 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? 
0