path: root/frameworks/middleware/handout_middleware.tex

\documentclass{lxarticle}
\usepackage{english}
\usepackage[utf8]{inputenc}
\usepackage{lxheaders}
\usepackage{lxextras}

\lstset{
	language=C++,
	numbers=left,
	stepnumber=1,
	numbersep=5pt,
	numberstyle=\tiny,
	breaklines=true,
	breakautoindent=true,
	postbreak=\space,
	tabsize=2,
	basicstyle=\ttfamily\footnotesize,
	showspaces=false,
	showstringspaces=false,
	extendedchars=true,
	%backgroundcolor=\color{lbcolor},
	keywordstyle=\bf ,
	commentstyle=\color{green},
	stringstyle=\color{red}
}

\begin{document}

\section*{Middleware}

Distributed systems need to communicate with each other. Middleware assists the
developer by delivering a communication framework. The developer doesn't need
to care about protocols, datatype conversion, low level socket handling, \dots

There are different kinds of middleware:

\begin{description}
\item[RPC] Remote Procedure Calls are used to trigger a function in e.g. Task\_A
	calls a function of Task\_B
\item[MOM] Message Orientated Middleware is used the send messages between Taks.
(1:n and 1:1)
\item[ORB] An Object Request Broker is used to host complete objects of an
application in the broker. Other applications contact the broker; their object
request is handled by the orb.
\end{description}

Also a middleware can provide different degrees of abstraction:

\begin{itemize}
\item Programming Language
\item Operating System
\item Communication Protocol
\item Datatype conversions
\item Localization of Services
\end{itemize}

\subsection*{D-Bus / Desktop Bus}

D-Bus is designed for

\begin{itemize}
\item communication between application and operating system (system-bus)
\item communication between desktop applications (session-bus)
\end{itemize}

and used by several Desktop Environments

\begin{itemize}
\item GNOME
\item KDE4
\item Enlightenment E17
\item XFCE4
\item \dots
\end{itemize}

also \cmd{HAL} host its hardware info at D-Bus.

D-Bus is designed for local IPC only. It is a message based Middleware
supporting 1:n publish/subscribe mechanism and 1:1 message passing. D-Bus has
integrated datatype marschalling.

\subsubsection*{Architecture}

\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/dbus.png}
\caption{D-Bus Architecture}
\label{img:dbus}
\end{figure}

In the centre of the D-Bus architecture (Figure \ref{img:dbus}) is a
\cmd{dbus-daemon}. Connections to the \cmd{dbus-daemon} are established by the
help of the \cmd{dbus-library}. There are many language bindins for the
\cmd{dbus-library}:

\begin{itemize}
\item C/C++
\item JAVA
\item Python
\item Perl
\item PHP
\item Pascal
\item Ruby
\item Tcl
\item Smalltalk
\end{itemize}

A higher level abstraction is served by integrating D-Bus into frameworks. If
possible one of these libraries should be used:

\begin{itemize}
\item glib
\item QT4 (QT3 backport exists)
\item Mono
\item e\_dbus (Enlightenment E17)
\item .NET
\end{itemize}

\paragraph{Terminology}
\begin{description}
\item[bus address] is the name of ther underlying unix socket, e.g.
	\cmd{/tmp/dbus\_lx.socket}
\item[unique bus name] is generated by the daemon for every connection
\item[well-known bus name] must be set by the user for a connection, multiple
	names for one connection are allowed. A well known bus name has a namespace
	and is seperated by dots, e.g. \cmd{de.linutronix.Foo}.
\item[Object] Each Endpoint is called Object. An Object offers services on the
	bus. A client can create multiple Objects.
\item[Proxies] are used to access Objects. The use of Proxies and Objects are
	defined by the language binding, to fit best in the schemantics of the
	programming language.
\item[Methods] may require input parameters. Each call returns its output
	parameters or an exception if the action couldn't be performed.
\item[Signals] are used for 1:n message passing. An application needs to be
subscribed for a signal. A filter can be provided during subscription, to get
only signals with certain values in its parameters.
\item[AMI] Asynchronus Method Invocation can be used to make non blocking calls
to Methods.
\item[Activation] A config file can provide the information which objects are
	hosted by an application. The dbus daemon is able, to activate those
	applications on request or by invoking a method of an object in the context
	of the clients well-known bus name.
\end{description}

\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/dbus-hal.png}
\caption{D-Bus Use-Case: NetworkManager}
\label{img:dbus-hal}
\end{figure}

Figure \ref{img:dbus-hal} shows a typical D-Bus use-case. The
HAL\footnote{Hardware Abstraction Layer} daemon is connected with the Linux
kernel by the Device interfaces. Objects and Methods which represent the
hardware of the device running the Linux kernel are hosted on the D-Bus system
message bus by HAL. The NetworkManager user daemon and the NetworkManager daemon
are also connected to the D-Bus system bus. The NM\footnote{NetworkManager}
user daemon is getting the Network Settings from the User via config file or
NM Applet and sends it to the D-Bus system bus. The NM daemon listens for the
messages from the NM user daemon and configures the networking stack via system
calls.

\subsubsection*{Tools}

\paragraph{qdbusviewer}
is a tool to browse through the hosted objects and call any method. (Figure
\ref{img:qdbusviewer})

\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/qdbusviewer.png}
\caption{qdbusviewer}
\label{img:qdbusviewer}
\end{figure}

\subsubsection*{Conclusion}

D-Bus is good for accessing System Infos and for IPC of Desktop Applications.
Its small API has bindings for all common languages and frameworks and is easy
to learn.

On the other hand D-Bus is limited on local IPC. Applications hosted on other
machines cannot be reached via D-Bus. Also there are no QoS features integrated,
to guarantee any real-time behaviour. There is even no message ordering. There
is no guarantee which method returns first, if two methods are invoked around
the same time.

\subsection*{CORBA}

CORBA is a middleware, which allows RPC\footnote{Remote Procedure
  Call}-based IPC\footnote{Inter Process Communication} between
different operating systems and different programming languages
(Figure \ref{img:orb}).

The communication interfaces are defined in IDL\footnote{Interface Definition
  Language}. The IDL files are compiled into, e.g. c++, java, \dots,
code which does the (de)serialization of the datatypes. The interface
implementations (CORBA objects) are registered with language
specific ORB\footnote{Object Request Broker}s. Each CORBA process owns
one ORB, which handles the function requests and returns the
calculated values.

\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/orb.jpg}
\caption{Object Request Broker}
\label{img:orb}
\end{figure}

\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/rtcorbaext.jpg}
\caption{Real-time Object Request Broker (source: [1])}
\label{img:rtorb}
\end{figure}

As shown in figure \ref{img:rtorb}, a real-time capable ORB extends a standard 
ORB with the following features: locating objects in constant time,
preallocation of resources, operating system independent priority
handling, priority based scheduling.

ACE is an open-source c++ framework for platform-independent system-
and network-programming. TAO is a Real-time CORBA implementation build
on top of ACE (Figure \ref{img:ace}).

\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/ace.jpg}
\caption{ACE Framework (source: [2])}
\label{img:ace}
\end{figure}

The ACE/TAO package is available for all important operating
systems. The framework can be trimmed for embedded systems: Each
application described in this paper consumes less than 1 MByte of
RAM. Also the consumed CPU time is suprisingly low.

\subsubsection{Conclusion}

CORBA offers a wide variety of middleware communication methods. There is no
limitation for a communication between different operating systems, even the
network protocols can be exchanged. CORBA provides a Real-time extension.

On the other hand, the framework is complex and difficult to learn.

\subsection*{Exercises}

An application should be created, to send a message to the 'server' with a
variable payload, that the time needed for the call / return of the call can be
measured in the client.

The above described application will be implemented with ACE/TAO RTCORBA and
the D-Bus glib bindings:

\subsubsection*{ACE/TAO RTCORBA ping-pong}

\subsubsection*{D-Bus glib bindings ping-pong}

First \cmd{ping-server.c} will be created to host the ping object:

\begin{lstlisting}
#include <dbus/dbus.h>
#include <dbus/dbus-glib.h>
#include <time.h>

static DBusHandlerResult signal_filter
		(DBusConnection *connection, DBusMessage *message, void *user_data);

int main(int argc, char **argv)
{
	GMainLoop *loop;
	DBusConnection *bus;
	DBusError error;

	loop = g_main_loop_new (NULL, FALSE);
	dbus_error_init (&error);
	bus = dbus_bus_get (DBUS_BUS_SESSION, &error);

	if (!bus) {
		g_warning ("Failed to connect to the D-BUS daemon: %s", error.message);
		dbus_error_free (&error);
		return 1;
	}

	dbus_connection_setup_with_g_main (bus, NULL);
	/* listening to messages from all objects as no path is specified */
	dbus_bus_add_match (bus, "type='signal',interface='de.linutronix.Ping'",
		&error);
	dbus_connection_add_filter (bus, signal_filter, loop, NULL);
	g_main_loop_run (loop);

	return 0;
}

static DBusHandlerResult signal_filter
		(DBusConnection *connection, DBusMessage *message, void *user_data)
{
	/* User data is the event loop we are running in */
	GMainLoop *loop = user_data;

	/* A signal from the bus saying we are about to be disconnected */
	if (dbus_message_is_signal(message, "org.freedesktop.Local",
		"Disconnected"))
	{
		/* Tell the main loop to quit */
		g_main_loop_quit (loop);
		/* We have handled this message, don't pass it on */
		return DBUS_HANDLER_RESULT_HANDLED;
	}
	else if (dbus_message_is_signal (message, "de.linutronix.Ping", "Ping"))
	{
		DBusError error;
		char *s;

		dbus_error_init (&error);

		if (dbus_message_get_args(message, &error, DBUS_TYPE_STRING, &s,
			DBUS_TYPE_INVALID))
		{
			struct timespec rx_time;
			clock_gettime(CLOCK_MONOTONIC, &rx_time);
			g_print("ping received: %s - %d:%d\n", s, rx_time.tv_sec,
				rx_time.tv_nsec/1000);
			// dbus_free (s);
		} else {
			g_print("ping received, but error getting message: %s\n", error.message);
			dbus_error_free (&error);
		}
		return DBUS_HANDLER_RESULT_HANDLED;
	}
	return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
\end{lstlisting}

The server application will be compiled with the following command:

\cmd{gcc -o server `pkg-config --libs --cflags dbus-glib-1` -lrt ping-server.c}

Next a file \cmd{ping-client.c} with the following content is created:

\begin{lstlisting}
#include <glib.h>
#include <dbus/dbus.h>
#include <dbus/dbus-glib.h>
#include <time.h>

static gboolean send_ping (DBusConnection *bus);
static const char *v_STRING;

int main (int argc, char **argv)
{
	GMainLoop *loop;
	DBusConnection *bus;
	DBusError error;

	if (argc > 1)
		v_STRING = argv[1];
	else
		v_STRING = "no arg given";

	/* Create a new event loop to run in */
	loop = g_main_loop_new (NULL, FALSE);

	/* Get a connection to the session bus */
	dbus_error_init (&error);
	bus = dbus_bus_get (DBUS_BUS_SESSION, &error);
	if (!bus) {
		g_warning ("Failed to connect to the D-BUS daemon: %s", error.message);
		dbus_error_free (&error);
		return 1;
	}

	/* Set up this connection to work in a GLib event loop */
	dbus_connection_setup_with_g_main (bus, NULL);
	/* Every second call send_ping() with the bus as an argument*/
	g_timeout_add (1000, (GSourceFunc)send_ping, bus);

	/* Start the event loop */
	g_main_loop_run (loop);
	return 0;
}

static gboolean send_ping (DBusConnection *bus)
{
	DBusMessage *message;
	struct timespec tx_time;
	struct timespec done_time;

	message = dbus_message_new_signal ("/de/linutronix/Ping",
                                   "de.linutronix.Ping", "Ping");
	/* Append the string to the signal */
	dbus_message_append_args (message,
														DBUS_TYPE_STRING, &v_STRING,
														DBUS_TYPE_INVALID);
	clock_gettime(CLOCK_MONOTONIC, &tx_time);
	/* Send the signal */
	dbus_connection_send (bus, message, NULL);
	clock_gettime(CLOCK_MONOTONIC, &done_time);
	g_print("%d:%d\n%d:%d\n\n", tx_time.tv_sec, tx_time.tv_nsec/1000,
		done_time.tv_sec, done_time.tv_nsec/1000);
	/* Free the signal now we have finished with it */
	dbus_message_unref (message);
	/* Return TRUE to tell the event loop we want to be called again */
	return TRUE;
}
\end{lstlisting}

The client application will be compiled with the following command:

\cmd{gcc -o client `pkg-config --libs --cflags dbus-glib-1` -lrt ping-client.c}

To run the applications start them with:
\begin{itemize}
\item \cmd{./client WhatEverYouWantAsPayLoad}
\item \cmd{./server}
\end{itemize}

The order, which application is started first doesn't matter. Take care that
the \cmd{dbus-daemon} is running.

\begin{thebibliography}{9}%use this if you have <=9 bib refs
%\begin{thebibliography}{99}%use this if you have >9 bib refs
\bibitem{paper1},{\it Real-time CORBA Specification},2005, {\sc OMG}
\bibitem{paper2},{\it Overview of ACE},2007\\{\it http://www.cs.wustl.edu/schmidt/ACE-overview.html}
\end{thebibliography}

\end{document}