6.3 Implementation Details
This section describes the modifications that were made on the current system by addressing the components that has been changed and how they differ from the existing solution. It presents the separation between the general functionality and the use case specific logic and outlines how it works.
6.3.1 Channel Definition
The proposed improvements defines a channel as a separated messaging channel for a single use case or, in the case of the reference use case, a single event. Each event or use case gets its own channel which it uses to send and receive messages over for the corresponding use case or event. These channels represent the core functionality of the generalization that this implementation introduces. The idea is that clients subscribes to channels instead of just connecting to the web server where a client that is a subscriber of a channel can send and receive messages on that channel. The channel functionality is present in three components, the client interface, the web server and the client validation cache, see Figure 6.1 for an overview of all components of solution with addressed components highlighted.
The channel id, or reference, is for the voting use case intended to be similar to that of a path component of a URL. A channel reference is also meant to be a composition of an account and the name of an event, such as ”/dohi/event1”. This is used for the request handlers and the channel manager in the web server to be able to group channel specific logic and to further minimize overhead by, for example, let a client subscribe to a channel when connecting to the server using a certain URL.
6.3.2 Components
There are four components that have been modified to some extent and how these have been changed is described in the following subsections. The overall architecture has not been changed from the existing solution and components are still only interacting with those it do in the reference system, see Figure 6.2 for an overview of the system architecture where modified components have been highlighted with a wider and rounded border.
Web Server
The web server has been completely reworked from the ground up to accommodate for the core functionality of the channels. It consists of two levels where the first level consists of the core functionality and the second level consists of use case specific logic. When a client first connects to the web server, the web server directly sends a respond to the client containing the validation token that the connected client must use in every message to validate itself.
A connected client can then send subscription requests to the server which, depending if there is any channel module that validates the request, sets the client as a subscriber to the channel and sends a response back that may contain use case specific information such as initial state.
The web server holds channel modules which are bound by a mapping expression for how an id or reference to the channel could look. The web server uses these modules to perform lazy initialization on channels, triggering when the first client subscribes to a channel. See Algorithm 6 for a step by step description of the subscription procedure used in the web server. The initialization of a channel includes setting up a topic on SNS for the channel and call a channel modules initialization method. The SNS topic is used for channel messaging
66 Chapter 6. Implementation of Improvements
between internal components of the system and the module initialization call is used to let the use case or event specific logic to do an initialization. When the last client unsubscribes from an initialized channel on a web server, the web server tears down the channel by unsubscribing to the SNS topic and calling a destructor method on the channel module.
A channel module can hold regular handlers for HTTP request/response logic which do not go through the subscription procedure but is still exposed to the channel module and the messaging functionality for a channel and can as such still interact with the use case
Figure 6.1: An overview of the components in the solution which highlights the general functionality of the messaging channels that is not tied to any use case. It separates the web server in two levels: a higher level which contains use case specific functionality in separate modules and a lower level that manages these modules. It introduces a web client interface that the clients use to express their interest in events or channels. The client validation cache is also used directly by the lower level of the web servers. The load balander and the notification system is also viewed as part of the basic functionality.
6.3. Implementation Details 67
Figure 6.2: Overarching components in the solution with modified components highlighted.
Those that were modified during the implementation are the web client, web server, notifi-cation system and database. Other components were used as they were.
logic.
Algorithm 6: Routing algorithm for a node in a Pastry overlay network.
Data: The set of channel modules P : id, for possible channels Data: The set of active channels A : channel
Data: The set of channels S that the client is subscribing to Data: The channel c that the client is trying to subscribe to if c /∈ S then
if c ∈ A and A(c) validates the subscription then add c to S and send OK response
else
if c matches any channel module in P and P (c) validates the subscription then
set up topic for c on SNS set up channel, add it to A and call init method on channel add c to S and send OK response with
end end end
68 Chapter 6. Implementation of Improvements
The event module for the current use case is similar to the use case functionality in the reference system, except it does not operate on the complete global state but instead only on its own channel state. When the channel manager in level 1 asks the event module to validate a channel it checks if the channel exists in the database and accepts the validation if it does. When the logic for an event initializes, it fetches the state of the channel from the database and stores it locally and then gives it to the channel manager whenever the channel manager asks for a channel subscription response. The admin interface handling is done exactly the same by using HTTP request/response handlers and directly querying the database. The data model has been changed, though, from storing happenings to storing channels and, because of that, the admin handlers has been modified to support the new data model.
To further minimize the number of steps that needs to taken in the starting phase when a client connects, a client can, instead of connecting to the root of the server address, connect to the server using a path component that starts with ”/channel/”. The web server will interpret this as a connection with a single subscription request to a channel whose reference is represented the remaining part of the path component.
Notification System
The notification system is still SNS and the internal components do still communicate using a single topic but the web server now also creates a topic for each channel that can be used to send messages over its own channel and further separate use cases or events.
Database
The data model has been modified to accommodate the new separation of data with chan-nels. When a channel for an event is initialized, the event logic needs to be able to fetch the state of that single event. Instead of using happenings, surveys, questions and options, the database now stores channels as a substitution for happenings and surveys grouped together where each channel in the database represents a channel or event for the current use case.
A user is no longer tied to a happening but can instead be tied to a number of accounts where an account represents a group of channels.
Front end
The front end has been divided into two parts where a client interface has been extracted from the use case specific web client. The client interface is a Javascript library that pro-vides functionality to connect to a server, disconnect from a server, subscribe to a channel, unsubscribe to a channel and send and receive messages for a channel. This interface hides the low level communication with the web server, such as token handling and sending sub-scribe messages, and provides a more abstract functionality where clients can be notified about channel specific information by registering callbacks.
The current voting client has been modified so that it uses the new client interface to connect to the server and subscribe to a channel. The data model handler has also been changed to support the new data model where only the specific event data is stored locally.
The client implementation has been limited to the rating functionality where a user can rate a subject and then receive a result, in the form of a sliding window mean value of votes, which it displays in a heatometer.