\chapter{NoTA Overview}\label{chap:overview}

\section{Introduction}

This chapter introduces the main components of NoTA and its

architecture\index{architecture}. In the next chapters we will discuss each of

the parts in more detail, but this chapter should give you a good overall idea

of what NoTA is all about.

\section{Overview and terminology}

We start with a short introduction into the core NoTA-concepts and

terminology. NoTA sometimes has some of its own terminology, and sometimes

uses existing terms in a slightly different way. It's helpful to understand

where.

\begin{wrapfigure}{r}{0.3\textwidth}

\includegraphics[width=6cm]{image/an-sn.png}

\caption{Application nodes and service nodes}\label{figure:an-sn}

\end{wrapfigure}

\subsection{Nodes, messages and streams}

NoTA is all about communication between {\em nodes}, which are logical

entities, either in hardware or software. For example, you can think of an

video-player node requesting some video data from a file-storage node. After

receiving the data, it can send it to the MPEG-node for decoding, and

finally to the video and audio nodes for showing the video.

Structurally, there are \textbf{two} kinds of nodes:

\begin{itemize}

\item {\em application nodes}\index{application node} (ANs) - the nodes

  (subsystems) that request services to other nodes; also known as {\em

    clients};

\item {\em service nodes}\index{service node} (SNs) - the nodes (subsystems)

  that provide services to other nodes; also known as {\em services}.

\end{itemize}

These nodes can communicate in two ways:

\begin{itemize}

\item sending {\em messages}\index{message} to other nodes. Messages are blobs

  of structured data for asking other nodes to do something or inform them of

  some event; this is sometimes called the {\em control plane}\index{control

    plane};

\item sending {\em streams}\index{stream} of data to other nodes. For

  bulk-transfer of data, it's much more efficient to send it as opaque data to

  other nodes. This is sometimes called the {\em data plane}\index{data

    plane}.

\end{itemize}

\subsection{Message passing}

As mentioned, control between nodes takes place by sending {\em messages};

this is called {\em message passing}\index{message passing}. At least

conceptually, the sending of messages is fully asynchronous. That is, a node

sends a message to another node; depending on the kind of message, the

receiver may send a response message, which could come at some later

time. Asynchronous messages are different from function calls, in that the

caller (sender) does not wait for the answer, but instead has to be ready

receive the response at any time.

Message passing is more flexible than mere function calls -- the latter can be

considered a special, simple case of the former. The flip side of that coin is

that true message passing makes things harder for the programmer.

As an example of message passing, one could think of an SN that implements a

music player, and accepts messages such as {\tt play()}, {\tt pause()} and

{\tt stop()}. At any time during playing some songs, the SN could send

messages back to the AN, for example to indicate song changes, or error

conditions. 

\subsection{Programming NoTA nodes}

Application programmers usually interface with NoTA on the {\tt

  h\_in}-level. Technically, the core NoTA specifications do {\bf not} specify

the API\index{application programming interface} of the {\tt h\_in}. For

practical reasons, we use the API that the reference implementation offers,

which was inspired by BSD-sockets\cite{Stevens2003}. However, one could imagine

other interfaces to the underlying NoTA-protocol as well. The BSD-socket

interface was chosen because it provides a familiar abstraction. The

similarity is {\em not} complete though, so you should be careful with

assumptions based on knowledge of BSD-sockets.

On top of the {\tt h\_in} lives a special service node that is part of the

NoTA specification: the {\em resource manager}\index{resource manager}

(RM). The resource manager's role is somewhat similar to that of a combination

DNS and DHCP-server in a network: it hands out addresses to services, and

allows you to find them.

Services register themselves with the RM to retrieve an address (the {\em

  service-id}\index{service-id} or {\em SID}). Applications can then query the

RM for these services, and provide the information they need for

connecting. In addition, the RM has an \emph{event interface}, which means

that it can notify you when some service (SN) becomes available or goes away.

Finally, the NoTA reference implementation offers a tool called the {\tt

  stubgen}, which takes specification in the {\em Web Service Description

  Language}~\cite{Booth:07:WSD}\index{Web Services Description Language}

(WSDL), and generates the stub code for ANs and SNs. The stub-generator

generates some of the low-level 'plumbing' code, allowing software developers to

concentrate on the problem they try to solve, rather than on the details of

NoTA. The stub-generator is the NoTA-equivalent of what is called an

IDL-compiler in e.g. CORBA\index{CORBA} and COM\index{COM}.

Figure~\ref{figure:an-sn} gives a schematic overview of a NoTA-based system.

\section{NoTA Components}

\subsection{Architecture}

\begin{figure}

\centering

\includegraphics[width=80mm]{image/nota-arch.png}

\caption{NoTA layered architecture}

\label{fig:nota-layered-architecture}

\end{figure}

NoTA nodes live on top of the NoTA architecture, which consists of two layers, inspired by the classic ISO/OSI network

model\cite{ISOOSI94}:

\begin{itemize}

\item The {\tt l\_in} ({\em low-level interconnect}\index{low-level interconnect})

  is an abstraction of the network layer. This allows nodes to communicate

  over e.g. TCP/IP, USB or Bluetooth, without having to worry about the

  idiosyncrasies of the network protocols involved. The {\tt l\_in} is

  subdivided in the {\tt l\_in-down} and the {\tt l\_in-up};

\item On top of that, there is the {\tt h\_in} ({\em high-level

    interconnect}\index{high-level interconnect}), which provides an API for

  applications that want to use NoTA. 

\end{itemize}

Some of the other NoTA literature refers to the {\tt h\_in} and {\tt l\_in}

together as the \emph{Device Interconnect Protocol} or DIP\index{device

interconnect protocol}. We will not use that name; just remember that DIP

refers to the protocol that {\tt h\_in} and {\tt l\_in} offer, i.e. what goes

on inside the cloud of figure~\ref{figure:an-sn}.

\subsection{L\_IN}\index{low-level interconnect}

The {\tt l\_in} or {\em low-level

  interconnect}\cite{Eriksson2008:1,Eriksson2008:2} abstracts various network

technologies (transport) that NoTA can use. It consists of two sub-layers:

\begin{enumerate}

\item the {\tt l\_in-down}, is the network adaption layer, and translates

  between the NoTA world and the various network types or {\em transports}),

  for example TCP, Bluetooth and USB;

\item the {\tt l\_in-up} lives on top of the {\tt l\_in-down}, and provides an

  interface to the {\tt h\_in}.

\end{enumerate}

In NoTA-publications, the network abstraction is often referred to as being

\emph{transport agnostic}\index{transport agnostic} - above the level of the

\texttt{l\_in} you don't have to care (or know) what the underlying transport

technology is. Nodes can be connected using different transports, and when one

of the transport fails (e.g., a cable gets disconnected), the next one can

take over. There are of course limits to the transport-agnosticism because of

the different throughput and latency characteristics that different transports

have.

\subsection{H\_IN}\index{high-level interconnect}

The {\tt h\_in} or {\em high-level interconnect}

\cite{Eriksson2008:3,Eriksson2008:4} lives on top of the {\tt l\_in}, and

provides the application-layer. It is the {\tt h\_in} where the application

programmer interacts with NoTA. 

NoTA specifies the workings of the {\tt h\_in} in terms of service elements

and their interactions. However, it does {\bf not} mandate a specific

API\index{application programming interface}. It is the reference

implementation of NoTA that defines the programmer-API - other implementations

could offer other APIs.

\subsection{resource manager}\index{resource manager}

The resource manager~\cite{Eriksson2008:5} is a special kind of Service Node,

that can be used to find other Service Nodes. Its mission in life is somewhat

similar to that of a DHCP-server in a network, but with added functionality

for searching. It also provides an event-interface, with which nodes can be

notified when certain service nodes appear or disappear.

For small, static setups, you don't really \emph{need} the resource manager,

but that approach becomes quickly unfeasible for larger systems.

More about the resource manager in chapter~\ref{chap:rm}.

\subsection{stub-generator}\index{stub-generator}

\begin{figure}

\centering

\includegraphics[width=50mm]{image/stubgen.png}

\caption{NoTA stubs}

\label{fig:stubgen}

\end{figure}

The stub-generator is a programmer tool that takes a service definition (SIS)

written following the {\tt WSDL} ({\em Web Services Description

  Language})~\cite{Booth:07:WSD}\index{Web Services Description Language}, and

generates stub implementations for the message handlers, for both Application

Nodes and Service Nodes.

Use of the stub-generator avoids writing some of the 'plumbing code', and

allows the programmer to concentrate on the business logic of his program,

rather than on NoTA-plumbing details. The stub-generator is discussed in

chapter~\ref{chap:stubgen}.

Even without the stub-generator, the WSDL service definitions are a useful

tool to specify the functionality that your services offer to the outside

world.

\section{Portability}\index{portability}

\subsection{General}

There is little in the NoTA-design that favors any particular software

platform; in fact, NoTA has been designed to scale from

embedded\index{embedded} systems to PC-class systems, while ports to other

platforms are very much encouraged.

Having said that, it must be noted that the {\em reference

  implementation}\index{reference implementation} we are discussing in this

guide has been developed on Linux, which influences some implementation

choices. A conscious effort has been made though to very much limit the use of

platform-specific component and, when they are unavoidable, isolate them.

Thus, the reference implementation works on Linux -- on the x86 architecture,

but also on ARM and AMD64. Outside Linux\index{Linux}, NoTA is known to work

on Cygwin\cite{Cygwin}, and ports are underway for

Symbian\cite{Symbian}\index{Symbian}, T-Kernel/TRON\cite{TRON}\index{TRON} and

Windows-CE\index{Windows-CE}, in various states of completion. 

It is, however, true that the reference implementation was developed on Linux

systems, so in general, the more a system looks like Linux, the easier the

porting effort will be. For a system very different from Linux, it might make

more sense to not port NoTA, but instead re-implement it from specification.

\subsection{{\tt l\_in-down}}\index{portability!low-level interconnect}

While the general part of the NoTA software is quite portable, the {\tt

  l\_in-down}\index{low-level interconnect} network adaptations are quite

system-specific. 

For example, Bluetooth-support requires the {\em Bluez}\cite{Bluez}-libraries

on Linux.  Bluez is not available on any other system, so other systems would

need to implement their own Bluetooth adaption, using the Bluetooth-libraries

on that system.

The same is true is for USB and to a lesser extent for TCP. Because the

TCP-interfaces on different systems are more similar (following the BSD-socket

model)\index{socket}, the {\tt l\_in-down} for TCP is easier to port.

\section{Questions}

To test your understanding of this chapter, you could try to answer some of

these questions. You can find the answers to these question in

appendix~\ref{chap:answers}.

\begin{enumerate}

\item Which two kinds of nodes are distinguished in a NoTA system? What is the

  difference between them?

\item What is the difference between message passing and function calls?

\item In NoTA, nodes can communicate using either message passing or

  streaming. Can you give some examples of when you would use either one of

  those?

\item What are the two layers in the NoTA architecture? What's the purpose of

  each of these layers?

\item What does the resource manager do? Why would you use the stub-generator?

\item Do you need to run Linux to run NoTA?

\end{enumerate}