Design and Architecture of Complex Software Systems (DACSS)

Assignment 2: Fundamental Architectural Styles: Event-Driven

In this assignment you implement two event-driven applications:

a system simulating the interactions between news agencies and their subscribers
a network of temperature sensors and various displays and processing units

For both applications you need to use an EventBus infrastructure. You have a choice, you can either:

use an eventbus such as GreenRobot
implement your own very simple eventbus according to the simplified design for BasicEventBus presented in Lecture Week3 slides

This assignment puts together two lab sessions (corresponding weeks 4 and 5). The duration of this assignment is 2 weeks (results should be presented no later than week 6). Delays bring a penalty of 1 point for each weeek of delay after the deadline.

General grading policy: Grades reflect your individual knowledge and contribution. Each student must complete and present their own solutions. Fraud attempts will be assigned 0(zero) points. Not doing the assignment is assigned by default 4 points.

References:

Lecture notes of week 3

Detailed description

Event-driven application1: monitoring sensors

There are multiple types of sensors (TemperatureSensor, WaterlevelSensor, HumiditySensor, etc.) and multiple sensor instances of each type (TemperatureSensorTimisoara, TemperatureSensorArad, ...). In the implemented application, the sensors will be simulated by simple data sources that generate random data. There are different types of displays (NumericDisplay, MaxValueDisplay, TextDisplay). There can be multiple display instances of each type of display. Each display instance can choose to receive data from certain types of sensors (Temperature, WaterLevel, Humidity, ...) and will receive data from all sensor instances of that type.

Event-driven application2: news agencies and subscribers

There are multiple news agencies that publish news on various domains (sports, politics, culture, etc.). Each agency can publish news from multiple domains. Different people subscribe to receive news from their domains of interest. Each person can subscribe to one or more domains, and can change the domain/domains to which they are subscribed.

EventBus infrastructure: Choice1 - Using GreenRobot

A tutorial on how to get started with GreenRobot and further documentation is available at link

EventBus infrastructure: Choice 2 - Implementat your own very simple BasicEventBus

The BasicEventBus infrastructure must allow the following:

allows interaction between Publishers and Subscribers in the same process
Publisher components publish events of different types, with possible data attached to the event
Subscriber components register for different types of events. The EventBus infrastructure will send them notifications when these events occur
Subscriber components do not need to know in advance the Publisher components that generate the events they subscribe to, and Publisher components do not need to know the Subscriber components that receive notifications
Event types are not fixed in advance, each application can define its own system of event types.

In a very simple implementation of the BasicEventBus, there is a fixed Subscriber interface that must be implemented by any component that wants to be a subscriber to some event types. The class diagram of such a BasicEventBus is given in Lecture3 slides

Optional development

Bonus requirement: Starting from the BasicEventBus, implement a better design of the EventBus, where there is no fixed Subscriber interface.

The issue with the fixed Subscriber interface is that it requires all subscribers to implement the same handler method. This limitation forces subscribers to handle different event types by first casting the events, which is inefficient and error-prone. A subscriber that subscribes to TypeOneEvent and TypeTwoEvent must have a handler such as:

 public void inform(Event event) {
        if (event instanceof TypeOneEvent) {
            TypeOneEvent e = (TypeOneEvent) event;
            ... do stuff with e as a TypeOneEvent
        }
        if (event instanceof TypeTwoEvent) {
            TypeTwoEvent e = (TypeTwoEvent) event;
            ... do stuff with e as a TypeTwoEvent
        }
}

How to overcome this problem: We need to find a way for each subscriber to define its own handler method(s) for specific event types. The event bus must then be able to identify and use the correct handler for each subscriber and event type.

How can the event bus identify the correct handler? Possible practical implementation solutions are:

solution approach1: when a subscriber registers for an event type, it provides also the name of its handler method that must be called by the event bus in order to handle events of that type.

solution approavch2: define and use custom annotations to mark certain methods of the subscriber as event handlers - this is how GreenRobot EventBus is doing. In this case, the subscribe method only needs to receive the subscriber object. The EventBus will inspect the subscribers class for methods with the custom annotation, using this information to identify the subscribed event types and their handlers.

Both solution approaches rely on the use of Reflective language features - see Lecture Week 4.

In both solution approaches, when a subscription is made, the EventBus must perform verifications to ensure that the subscription is valid (an existing method name, right type of argument, etc).

Implement the better EventBus, using both solution approaches. Analyze the pros and cons of each approach, and create some simple application example scenarios to illustrate the pros and cons of each approach.

Deadline and Grading: This optional part has a HARD deadline in week 7 and brings 1 Bonus point. The Bonus point is granted for a complete fulfillment of the requirements.