path: root/frameworks/middleware/handout_middleware.tex

\input{confighandout}

\subsection{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}

\subsubsection{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}

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.

\paragraph{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}

\subparagraph{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.

\paragraph{Tools}

\subparagraph{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}

\paragraph{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.

\subsubsection{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.

\paragraph{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.

\subsubsection{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:

\paragraph{ACE/TAO RTCORBA}

First an IDL for the Ping interface will be created (\cmd{ping.idl}:

\begin{lstlisting}
module Linutronix{
	interface Ping{
		oneway void send(in string payload);
	};
};
\end{lstlisting}

Then a IDL compiler is used to generater headers and wrappers for client and 
server and a dummy implementation file:

\cmd{tao\_idl -GI ping.idl}

The following files will be generated:

\begin{itemize}
\item pingC.cpp
\item pingC.h
\item pingC.inl
\item pingI.cpp
\item pingI.h
\item pingS.cpp
\item pingS.h
\item pingS.inl
\end{itemize}

Before editing the implementation dummy, we alter its name, to avoid that it is
overwritten by a further \cmd{tao\_idl} call:

\cmd{mv pingI.cpp ping\_I.cpp}

Now we can alter the \cmd{ping\_I.cpp} file, that it looks like this:

\begin{lstlisting}
#include <time.h>
#include <iostream>

#include "pingI.h"

// Implementation skeleton constructor
Linutronix_Ping_i::Linutronix_Ping_i (void)
{
}

// Implementation skeleton destructor
Linutronix_Ping_i::~Linutronix_Ping_i (void)
{
}

void Linutronix_Ping_i::send (
    const char * payload)
{
  // Add your implementation here
	struct timespec time_rx;
	clock_gettime(CLOCK_MONOTONIC, &time_rx);
	std::cout<<time_rx.tv_sec<<":"<<time_rx.tv_nsec/1000<<": "<<payload<<"\n";
}

\end{lstlisting}

Next step is to create an application \cmd{Receiver.cpp} which hosts the Ping
implementation:

\begin{lstlisting}
#include <iostream>

#include "pingI.h"

#include "orbsvcs/CosNamingC.h"
#include <tao/RTCORBA/RTCORBA.h>

int main(int argc, char* argv[]){
	try{
		// initialize ORB
		CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "ServerORB");
		std::cout<<"ORB initialized"<<std::endl;
	
		// access RT Extensions
		CORBA::Object_var rtorb = orb->resolve_initial_references("RTORB");
		RTCORBA::RTORB_var rt_orb = RTCORBA::RTORB::_narrow(rtorb);
		std::cout<<"RT Extensions OK"<<std::endl;
	
		// obtain root_poa
		CORBA::Object_var poa = orb->resolve_initial_references("RootPOA");
		PortableServer::POA_var root_poa = PortableServer::POA::_narrow(poa.in());
	
		// activate POA Manager
		PortableServer::POAManager_var poa_manager = root_poa->the_POAManager();
		poa_manager->activate();
		std::cout<<"root_poa OK"<<std::endl;
	
		// create Policy
		CORBA::PolicyList ping_policy(1);
		ping_policy.length(1);
		ping_policy[0] = rt_orb->create_priority_model_policy(
			RTCORBA::CLIENT_PROPAGATED, RTCORBA::maxPriority);

		// create ObjectAdapter, assign Policy
		PortableServer::POA_var ping_poa =
			root_poa->create_POA("ping_poa", poa_manager.in(), ping_policy);

		std::cout<<"Policy assigned"<<std::endl;

		// create the servant
		Linutronix_Ping_i ping_i;

		// activate servant
		PortableServer::ObjectId_var object_id = ping_poa->activate_object(&ping_i);
		CORBA::Object_var ping_obj = ping_poa->id_to_reference(object_id.in());
		CORBA::String_var ior = orb->object_to_string(ping_obj.in());
		std::cout<<"Servant activated"<<std::endl;

		// NameService
		CORBA::Object_var naming_obj =
			orb->resolve_initial_references("NameService");

		CosNaming::NamingContext_var naming_context =
			CosNaming::NamingContext::_narrow(naming_obj.in());

		CosNaming::Name name(1);
		name.length(1);
		name[0].id = CORBA::string_dup("Receiver");
		naming_context->rebind(name, ping_obj.in());
		std::cout<<"Bound Receiver to NameService"<<std::endl;

		// start ORB
		orb->run();
		std::cout<<"ORB ready"<<std::endl;

		//destroy
		root_poa->destroy(1,1);
		orb->destroy();

		} catch(CORBA::Exception &any) {
			std::cout<<"Exception: "<<any<<std::endl;
		}
    return 0;
}
\end{lstlisting}

Then we create an application \cmd{Supplier.cpp} which raises calls to the Ping
interface:

\begin{lstlisting}
#include <iostream>
#include <string>
#include <unistd.h>
#include <orbsvcs/CosNamingC.h>
#include <tao/RTCORBA/RTCORBA.h>

#include "pingC.h"

static Linutronix::Ping_var ping;
static std::string str;

int main(int argc, char* argv[])
{
	if (argc > 1)
		str = argv[1];
	else
		str = "no argument given";

	try{
		// initialize ORB
		CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "ClientORB");
		std::cout<<"ORB ok"<<std::endl;

		// get RTORB
		CORBA::Object_var rtorb = orb->resolve_initial_references("RTORB");
		RTCORBA::RTORB_var rt_orb = RTCORBA::RTORB::_narrow(rtorb.in());
		std::cout<<"RTORB ok"<<std::endl;

		// NamingService
		CORBA::Object_var naming_obj =
			orb->resolve_initial_references("NameService");

		CosNaming::NamingContext_var naming_context =
			CosNaming::NamingContext::_narrow(naming_obj.in());

		std::cout<<"NamingService ok"<<std::endl;

		CosNaming::Name name(1);
		name.length(1);
		name[0].id = CORBA::string_dup("Receiver");

		// receive Object
		CORBA::Object_var ping_obj = naming_context->resolve(name);
		ping = Linutronix::Ping::_narrow(ping_obj.in());
		std::cout<<"TransferOjekt ok"<<std::endl;

		// Private Connection Policy
		CORBA::PolicyList pc_policy(1);
		pc_policy.length(1);
		pc_policy[0] = rt_orb->create_private_connection_policy();

		CORBA::Object_var new_tran =
			ping->_set_policy_overrides(pc_policy, CORBA::SET_OVERRIDE);

		ping = Linutronix::Ping::_narrow(new_tran.in());
		std::cout<<"PrivateConnection ok"<<std::endl;

		struct timespec time_tx;
		struct timespec time_done;

		for(unsigned int i = 0; i < 100; i++)
		{
			clock_gettime(CLOCK_MONOTONIC, &time_tx);
			ping->send((const char*)str.c_str());
			clock_gettime(CLOCK_MONOTONIC, &time_done);
			std::cout<<time_tx.tv_sec<<":"<<time_tx.tv_nsec/1000<<"\n";
			std::cout<<time_done.tv_sec<<":"<<time_done.tv_nsec/1000<<"\n\n";
		}

		// destroy ORB
		orb->destroy();

	} catch(CORBA::Exception &any) {
		std::cout<<"Exception occured: "<<any<<std::endl;
	}
	return 0;
}
\end{lstlisting}

Typically ACE/TAO projects are build with MPC\footnote{MakeProjectCreator}. An
appropirate config file (\cmd{ping.idl}) looks like this:

\begin{lstlisting}
project(*Receiver): rt_server, naming {
	requires += exceptions
	Source_Files {
		ping_I.cpp
		Receiver.cpp
	}
}

project(*Supplier): rt_client, naming {
	requires += exceptions
	Source_Files {
		pingC.cpp
		Supplier.cpp
	}
}
\end{lstlisting}

Debian Users can use the following commands to translate all stuff:

\cmd{export ACE\_ROOT=/usr/share/ace}
\cmd{export TAO\_ROOT=/usr/share/ace/TAO}
\cmd{mpc-ace -type make ping.mpc}
\cmd{make -f Makefile.Ping\_Receiver}
\cmd{make -f Makefile.Ping\_Supplier}

To run the applications, first a NamingService has to be started:

\cmd{Naming\_Service -ORBEndpoint iiop://localhost:55555}

Then the server and client can be started:

\begin{enumerate}
\item \cmd{./server -ORBInitRef NameService=corbaloc:iiop:localhost:55555/NameService}
\item \cmd{./client -ORBInitRef NameService=corbaloc:iiop:localhost:55555/NameService}
\end{enumerate}

\subsubsection*{D-Bus glib bindings}

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}
\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}

\input{tailhandout}