\chapter{Development with NoTA}\label{chap:development}

\section{Introduction}

In the previous chapters, we discussed the major NoTA building blocks. That

should provide us with an excellent background to create our own NoTA

services. In this chapter, we will go through the development of an example

NoTA client and server. The complete code is available in Appendix

\ref{chap:example}.

\section{Design}

Before implementing NoTA services (ANs and SNn), it's important to think about

the {\em design}\index{design} first. A full discussion of interface design

goes beyond the scope of this guide, but we will gives some tips.

For example, when defining the service interfaces, it's important to consider:

\begin{itemize}

\item Make interfaces\index{interface} as simple as possible; not simpler. Try

  to limit the number of entry points to a minimum of orthogonal functions;

\item Choose clear names for your functions, and make the names in an

  interface consistent;

\item Remember the '{\em Rule of the least surprise}'\cite{Raymond03};

\item Limit the number of parameters, and keep the parameters simple;

\item Version\index{versioning} your interfaces (add a number), so you can

  evolve in the future without breaking clients of older versions;

\item NoTA services are \emph{asynchronous} - multiple \texttt{\_req}s and

  \texttt{\_rsp}s might be underway at any time. So make sure you can

  determine which \texttt{\_rsp} refers to whic h\texttt{\_req};

\item Taking it one step further: there is no guarantee that messages arrive in

  the same order as they were sent. Therefore, don't make services that depend

  on that.

\end{itemize}

We also heartily recommend you to read \cite{Vinoski2008} and \cite{Kendall94}

about the common pitfalls when designing distributed systems. The common

fallacies applicable to NoTA can be summarized:

\begin{enumerate}

   \item The network is reliable.

   \item Latency\index{latency} is zero.

   \item Bandwidth is infinite.

   \item The network is secure.

   \item Transport cost is zero.

   \item System clocks are identical.

\end{enumerate}

To make it clear: {\bf none of these are true}. When designing a NoTA-based

system, it is good to keep that in mind. Another valuable source for design

advice you might want to consult is {\em The Art of UNIX

Programming}\cite{Raymond03}.

\section{Naming and handling}

The naming of functions and variables is to some extent a matter of

taste. Some people prefer {\tt DoThisNow()}, while others like {\tt 

doThisNow} better. The author prefers {\tt do\_this\_now()}. 

Although that conflict cannot be solved here, we recommend some

common suffices for the message/signals, in accordance with common usage. If

you use these, for example in your WSDL descriptions, it's clear for the

(human) users of the specifications what they mean. In particular, they

clarify the role of both application node (AN) and service node (SN).

\begin{itemize}

\item {\tt \_req} should be used for {\em requests}, where an AN is

  \emph{requesting} something from a service node. {\tt \_req}-messages are

  handled (implemented) by service nodes;

\item {\tt \_cnf} should be used for {\em

  confirmations} from the SN in response to some request from the AN; {\tt

  \_cnf}-messages are to be handled (implemented) by the AN; 

\item {\tt \_ind} should be used for {\em indications}, i.e.,

  responses which are not direct response to requests; {\tt \_ind}-messages

  are sent by the SN to the AN and are to be handled (implemented) by the

  latter;

\item {\tt \_rsp} should be used for {\em responses} to {\tt \_ind}-messages,

  and are sent by the AN to the SN. Thus, the SN needs to handle (implement) these.

\end{itemize}

\section{Implementation}

In addition to all the other wise lessons already mentioned, we'd like to add

a couple more, based on some common misconceptions / errors when implementing

NoTA-systems. FIXME

\section{Questions}

To test your understanding of this chapter, some questions are provided. You

can find the answers in appendix~\ref{chap:answers}.

\begin{enumerate}

\item Can you list the use cases for the {\tt \_req}, {\tt \_cnf}, {\tt \_ind}

  and {\tt \_rsp}?

\end{enumerate}