\section{Architecture}
\label{sec:architecture}
This chapter describes the architecture of the collaboration framework for the Lively kernel in detail. Figure \ref{fig:highlevel_architecture} shows the overall architecture: A Lively application is embedded in the web environment and is therefore a client server architecture. On the client side, a \verb+Command Manager+ executes or undoes commands and queues new commands in the \verb+Local Command Queue+. When the client creates a new command, it is serialized and send to the server as explained in section \ref{sec:approach}. On the server side, a web server is listening for new client connections and commands at which the latter are stored in the \verb+Global Command Queue+.

\begin{figure}[h]
\begin{center}
\includegraphics[width=1.0\textwidth]{resources/high_level_architecture_fmc.pdf}
\caption{High-level architecture of collaboration framework}
\label{fig:highlevel_architecture}
\end{center}
\end{figure}

Next subsections will explain the client and server architecture in more detail (see figure \ref{sec:architecture}).

\subsection{Client Architecture} % (fold)
\label{sub:client_architecture}
The client intercepts some core Lively morph methods with \emph{ContextJS} to record the user's (visual) changes (see table \ref{tab:contextjs}). These methods are grouped into three \emph{ContextJS layers}, which can be separately switched on and off. Since some functionality (especially the \verb+onMouseMove+) can produce much synchronization overload, this might be helpful in situations with slow internet connection.. The \verb+Command Manager+ queues the commands and sends them via the \verb+Connection+ singleton instance to the server.

The \verb+Connection+ singleton holds a persistent connection to the server which is established as soon as a client opens a collaboration-enabled Lively page. This connection is realized through the emerging WebSocket \cite{w3c:websocket} technology, which allows bidirectional communication with a smaller footprint. Thus, pushing messages (in our case primarily commands) from server to clients and the other way round is easily possible without much overhead - it's much like using sockets in desktop programming.

\begin{table}
\ra{1.3}
	\begin{center}
		\begin{tabular}{lllll}
\multicolumn{1}{c}{\textbf{Layer}} & \phantom{abc} & \multicolumn{1}{c}{\textbf{Class}} & \phantom{abc} & \multicolumn{1}{c}{\textbf{Method}}	\\
			\hline
			\verb+CollabMorphLayer+ && \verb+Morph+ && 	\verb+rotateBy+\\
			&&                           &&         \verb+translateBy +\\
			&&                           &&         \verb+setPosition+\\
			&&                           &&        ...\\
			\verb+CollabMouseMove+ && \verb+Morph+ && 	\verb+onMouseMove +\\
			\verb+CollabTextMorphLayer+&& \verb+TextMorph+ && \verb+setTextString+\\
		\end{tabular}
		\caption{Overview of intercepted Lively methods}
		\label{tab:contextjs}
	\end{center}
\end{table}

\begin{figure}[h]
\begin{center}
\includegraphics[width=1.0\textwidth]{resources/architecture_fmc.pdf}
\caption{Detailed client and server architecture of collaboration framework}
\label{fig:architecture}
\end{center}
\end{figure}

% subsection client_architecture (end)

\subsection{Server Architecture} % (fold)
\label{sub:server_architecture}

The architecture of the server is shown on the right side of figure \ref{fig:architecture}. The server is split into two main parts, the \verb+Collaboration Server+ acting as the web server and the \verb+Redis Server+ representing the database. The \verb+Collaboration Server+ is written in Node.js\footnote{http://nodejs.org/}, an event-driven I/O framework that enables writing server-side JavaScript. Redis\footnote{http://code.google.com/p/Redis/} is an in-memory key-value store that allows advanced data types as values (e.g. strings, lists, sets, ...) and can persist its data to the disk in configurable intervals. It perfectly fits in the collaboration use case since it provides fast access to the data while being semi-persistent so that most of the data can be restored when the server crashes.

The \verb+Collaboration Server+ accepts \emph{WebSocket} connections and commands from clients. Every command is saved into the Redis database to enable the playback of commands and inform new clients about the stored commands. Table \ref{tab:key_value} gives an example snapshot of the Redis database to show which data is stored. Every key is scoped to the user's page URL so that commands of different pages aren't merged. 

The \verb+Collaboration Server+ uses the \emph{publish/ subscribe} mechanism (based on channels) of Redis to send new commands to every client. Three channels are exposed by the  \verb+Collaboration Server+: \emph{commands}, \emph{milestones} and \emph{mouse}. All channels, except for the mouse cursor, are saved semi-persistent into the Redis key-value store. Mouse cursor events are directly propagated to all clients since they are only of interest in a short time slice. Thus, the Server subscribes to the \emph{command} channel in Redis with a callback, which is called every time the server publishes a new command from a client. This callback function sends then the published command to every client. 

\begin{table}
\ra{0.9}
	\begin{center}
		\begin{tabular}{lll}
			\multicolumn{1}{c}{\textbf{Key}} & \phantom{abc} & \multicolumn{1}{c}{\textbf{Example Value}}	\\
			\hline
			\verb+<url>//milestones+ && 	\verb+["140", "234"]+\\
			\verb+<url>//commands-current-id+ && \verb+"336"+\\
			\verb+<url>//commands+ 	&& \verb+[{+\\
										&& \verb+  id:336",+ \\
										&& \verb+  commandType:"SetPositionCommand",+ \\
										&& \verb+  morphId:"user_0366079:Morph",+ \\
										&& \verb+  val:{x:10, y:10},+ \\
										&& \verb+  oldVal:{x:5, y:5},+ \\
										&& \verb+  timestamp:"1280353890466",+ \\
										&& \verb+  userId:"user_0"+ \\
										&& \verb+}]+ \\
			\verb+<url>//users+ && \verb+["user_1", "user_2"]+ \\
		\end{tabular}
		\caption{Exemplary snapshot of Redis key-value database}
		\label{tab:key_value}
	\end{center}
\end{table}
