Figure out Business Logic Module

[xuther]

There are requirements for Business Logic out in front of the API.

Basically the current proposal is to write a module that is in front of the API (and consumes the API) that runs all of the 'room' logic for the API, separate from the control offered by the API.

This module can

• subscribe to and consume events to have rules that are aware of all actions performed on a room.
• queue actions to be taken against a room that can be time delayed or dependent on a subsequent event.

[xuther]

So current thoughts on architecture (This is just a proposal). This is just me thinking aloud and writing it down:

1. We accept PUT requests on rooms similar to those accepted by the AV-API. The body may be different, but it's still RESTFul. (We'll need to think about how we handle returning state that is queued. Do we include it as a field? Include a callback address? Make them pass in a callback?)

   • I'm a fan of just adding a field that is like 'queuedState' or something like that, and basically return our action structure in side of it.
   • They can just subscribe to events to get the state of a queued event. That's probably the easiest way.

2. Similar to the AV-API we have a concept of a RoomConfiguration and CommandEvaluators. A room configuration contains one or more command evaluators. The CommandEvaluators generate actions, similar to the AV-API, but those actions look different - it isn't an action to be executed against a device, rather an action to be executed by the Business Logic Layer. An action contains

   • State to set. This is functionally a PUT body to be sent to the control API. (or some way of denoting the state to change)
   • Queued. Basically a boolean denoting if the action should be queued or executed immediately.
   • If Queued: Run at time - absolute time to run the action
   • If Queued: Run events - this is the names (and maybe some matching function?) of a set of events that will trigger this action.
   • If Queued: Cancellation events - names (and maybe some matching function) of a set of events that will cancel this action.
   • If Queued: Cancellation State - Some Room State that, if matched (or not matched?) will cancel this action at execution time. <- Potentially superfluous, depending on how we decide to handle events

3. The flow on request is something like:

======================================= On Request ===========================================

                                                                            +--> Send State to API --+
                     +---> Command Evaluator----+                          /                         |
                     |                          |                       Not Queued                   |
                     |                          |                        /                           |
Request---Put Body---+---> Command Evaluator----+---Actions--->Separate +                            +--Current State--> Return
                     |                          |                        \                           |
                     |                          |                      Queued                        |
                     +---> Command Evaluator ---+                          \                         |
                                                                            +-->Send to Queue -------+

4. On some time tick we check for events that need to be run:

ForEach item in queue:
	if item.runAtTime < now:
		if !item.CheckCancellationState():
			Send state to API

5. When we receive an event we check for actions in the queue affected by the event:

ForEach item in queue: 
	//Event name and pattern match received event.
	if item.CheckRunEvents(Received Event): 			
		if !item.CheckCancellationState():
			Send state to API
	if item.CheckCancelEvents(Received Event):
		Remove item from queue. 

We could decide to only pay attention to events that correspond to the current room or to all rooms, depending on the configuration.

This sort of architecture seems to allow us to handle all the business logic cases that I can think of (and please poke holes in this @danclegg @danielwells @bls68 ) by allowing us to:

• Make events sequential (Run on event)
• Make events time sensitive (Run at time)
• Allow for events to be triggered and/or cancelled on event
• Allow for a "don't run if" scenario

Thoughts?

[xuther]

A few more musings on this subject as I was thinking about it tonight.

Currently the pi's are self contained (almost completely) - if we allow users (us) to define business logic dependent on events, that implies that we have to have some sort of self contained event hub local to the pie, separate from that that goes out to the University Event Hub (or whatever we end up using).

Further, this means that we have to have some way of reconciling duplicate events (those passed locally and those passed via the university event hub). If this means we have a separate 'local room' and 'remote room' entity types and pi's only subscribe to 'remote room' events ( events not generated by a pi operating on it's own room) or we filter based on room, or generator, or some sort of UUID the reconciliation would need to occur.

[danclegg]

@xuther I'm mapping out thoughts tonight and tomorrow morning, so I don't have much to comment right now, but your last musings definitely bring up a sticky point. With room autonomy as a definitive requirement, I am not in favor of going to the complexity of our own MQ or event hub.

Definitely something to be mapped out and discussed by the team.

[jessemillar]

@danclegg How different is the university event bus compared to Rabbit MQ? If the differences are trivial in our use cases, we could easily set up a Docker container local to the Pi's to handle self-contained events. Reconciling duplicates is a whole 'nother beast, but wanted to throw in my two cents to earn brownie points.

[xuther]

@danclegg @jessemillar I spent some time last night with a RabbitMQ docker container and the ideas behind it seem very similar, but based on my reading of the documentation of the University Event Hub they've wrapped the AMQP endpoints in some more friendly ones.

We could check to see if they're still exposing the AMQP protocol somewhere (it wouldn't surprise me if they were) but the base implementation seemed different, from what I was looking at.

A few options that I see:

1. We run a localized RabbitMQ in docker on the pi - it handles local messages. All events are emitted twice - once to the local instance and once to the university instance.
2. We run a localized RabbitMQ in a docker on the pi - however we create another service that consumes those events and functionally echoes them to the University Event Hub. This means we don't emit twice, but has the added overhead of yet another service.
3. We build a simple relay that forwards the events to just the containers that care about them (business logic and UI) as well as to the event hub. It's a simple fan distributor.
4. We directly return events to the containers (a distributed mesh-like event bus between our containers.) as well as to the University Event Bus.

I don't really like any of the options, they all feel kind of kludgy - though the last feels the most in line with what we've been doing.

Thoughts?