diff options
Diffstat (limited to 'frameworks/middleware/handout_middleware.tex')
| -rw-r--r-- | frameworks/middleware/handout_middleware.tex | 173 |
1 files changed, 168 insertions, 5 deletions
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 |