Objective

Work with a small group to build a peer-to-peer, distributed solution to the Fast Flower Delivery exercise. The exercise was not necessarily heterarchical, so your architecture for the final project will likely differ significantly from what you did for that exercise. 

Constraints

• Your group must have at least two and not more than three people
• You must use at least two APIs listed at ProgrammableWeb Links to an external site.. If you want to use an API not listed in ProgrammableWeb, be sure to get permission. 
• Your architecture must be primarily event-driven and based on picos. 
• You must get your proposal approved before you begin

Proposal

You are required to submit a written proposal (less than 300 words plus a diagram) to the TA that includes the following information:

• What the system will do, what problem it will solve. 
• A high-level description of your event architecture, including actors in the system (i.e. pico types) and events that they send to each other. 
• A list of the APIs you will use
• Who is in your group
• A work plan delineating who is going to do what. 

A picture at this stage is very helpful.

We will judge your proposal for

• Clarity of what is to be built
• Scale and scope (e.g. too big or too small)
• Completeness
• Appropriate use of events to create a non-hierarchical, distributed solution

Implementation Notes

• Flower shops do not necessarily need to know about each other. 
• Each shop can have a relationship with one or more drivers. 
• The Fast Flower Delivery exercise just says that the flower shop "broadcasts" the need for a delivery, but doesn't say how. Use a Gossip protocol like you developed in Lab 9: Gossip Protocols.
• You may assume all drivers will be connected through one or more links to any driver that gets the initial delivery request. 
• You may also assume that drivers are altruistic and reliably propagate delivery messages (i.e. they don't maliciously squash messages to disadvantage other drivers). 
• The assignment message can also be propagated using the Gossip network so everyone knows who got the job if your implementation needs this. 
• You don't need to get too fancy on driver ranking or selection. Just make a proposal. 

Deliverables

You will present your project to the TA sometime before the last day of classes. You should be prepared to discuss the problem you're solving and give a convincing demonstration that your project solves it. A few slides with pictures. might help. You should plan on the TA presentation taking no more than 10 minutes total. If you cannot meet with the TA, you can arrange to submit a screencast of 5 minutes instead. 

You will also submit your code and a written document about your project. That is due on the last day of class and will be graded separately from your presentation.

The description should include:

• Statement of the problem you were solving
• List of component APIs and why you chose them
• Description of the actors (event generators and consumers)
• Description of the API (i.e. events and queries)
• Architectural diagram and explanation
• Analysis of why events were or were not a good solution to the problem you chose. Give pros and cons.