From cb5dfc68d3fb4c35295271814715d08820eb2f0a Mon Sep 17 00:00:00 2001
From: Manuel Traut <manut@linutronix.de>
Date: Tue, 23 Jun 2009 19:27:09 +0100
Subject: middleware: added d-bus sections

Signed-off-by: Manuel Traut <manut@linutronix.de>
---
 frameworks/middleware/handout_middleware.tex | 173 ++++++++++++++++++++++++++-
 1 file changed, 168 insertions(+), 5 deletions(-)

(limited to 'frameworks/middleware/handout_middleware.tex')

diff --git a/frameworks/middleware/handout_middleware.tex b/frameworks/middleware/handout_middleware.tex
index f708883..c6e3145 100644
--- a/frameworks/middleware/handout_middleware.tex
+++ b/frameworks/middleware/handout_middleware.tex
@@ -1,5 +1,5 @@
 \documentclass{lxarticle}
-\usepackage{german}
+\usepackage{english}
 \usepackage[utf8]{inputenc}
 \usepackage{lxheaders}
 \usepackage{lxextras}
@@ -8,9 +8,162 @@
 
 \section*{Middleware}
 
-\subsection*{DBUS}
+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
 
-Text
+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}
 
@@ -62,9 +215,19 @@ 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.
 
-\subsection*{\"Ubungen}
+\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}
+
+\subsubsection*{ACE/TAO RTCORBA ping-pong}
 
-\subsection*{Quellen}
+\subsubsection*{D-Bus GLib bindings ping-pong}
 
 \begin{thebibliography}{9}%use this if you have <=9 bib refs
 %\begin{thebibliography}{99}%use this if you have >9 bib refs
-- 
cgit v1.2.3

