File: des_princ.html

package info (click to toggle)
erlang-doc-html 1%3A11.b.2-1
links: PTS
area: main
in suites: etch, etch-m68k
size: 23,284 kB
ctags: 10,724
sloc: erlang: 505; ansic: 323; makefile: 62; perl: 61; sh: 45
file content (348 lines) | stat: -rw-r--r-- 9,510 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
  <TITLE>Overview</TITLE>
  <SCRIPT type="text/javascript" src="../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
      ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="1"><!-- Empty --></A>
<H2>1 Overview</H2>

<P>The <STRONG>OTP Design Principles</STRONG> is a set of principles for how
to structure Erlang code in terms of processes, modules and
directories.<A NAME="1.1"><!-- Empty --></A>
<H3>1.1 Supervision Trees</H3>

<P>A basic concept in Erlang/OTP is the <STRONG>supervision tree</STRONG>.
This is a process structuring model based on the idea of
<STRONG>workers</STRONG> and <STRONG>supervisors</STRONG>.
<P>
<UL>

<LI>
Workers are processes which perform computations, that is,
        they do the actual work.
</LI>


<LI>
Supervisors are processes which monitor the behaviour of
        workers. A supervisor can restart a worker if something goes
        wrong.
</LI>


<LI>
The supervision tree is a hierarchical arrangement of
        code into supervisors and workers, making it possible to
        design and program fault-tolerant software.
</LI>


</UL>

<P>
<CENTER>
<IMG ALT="sup6" SRC="sup6.gif"><BR>
<EM><A NAME="sup6"><!-- Empty --></A>Supervision Tree
</EM>

</CENTER>

<P>In the figure above, square boxes represents supervisors and
circles represent workers.<A NAME="1.2"><!-- Empty --></A>
<H3>1.2 Behaviours</H3>

<P>In a supervision tree, many of the processes have similar
structures, they follow similar patterns. For example,
the supervisors are very similar in structure. The only difference
between them is which child processes they supervise. Also, many
of the workers are servers in a server-client relation, finite
state machines, or event handlers such as error loggers.
<P><STRONG>Behaviours</STRONG> are formalizations of these common patterns.
The idea is to divide the code for a process in a generic part
(a behaviour module) and a specific part (a <STRONG>callback
        module</STRONG>).
<P>The behaviour module is part of Erlang/OTP. To implement a
process such as a supervisor, the user only has to implement
the callback module which should export a pre-defined set of
functions, the <STRONG>callback functions</STRONG>.
<P>An example to illustrate how code can be divided into a generic
and a specific part: Consider the following code (written in
plain Erlang) for a simple server, which keeps track of a number
of &#34;channels&#34;. Other processes can allocate and free the channels
by calling the functions <CODE>alloc/0</CODE> and <CODE>free/1</CODE>,
respectively.<A NAME="ch1"><!-- Empty --></A>
<PRE>
-module(ch1).
-export([start/0]).
-export([alloc/0, free/1]).
-export([init/0]).

start() -&#62;
    spawn(ch1, init, []).

alloc() -&#62;
    ch1 ! {self(), alloc},
    receive
        {ch1, Res} -&#62;
            Res
    end.

free(Ch) -&#62;
    ch1 ! {free, Ch},
    ok.

init() -&#62;
    register(ch1, self()),
    Chs = channels(),
    loop(Chs).

loop(Chs) -&#62;
    receive
        {From, alloc} -&#62;
            {Ch, Chs2} = alloc(Chs),
            From ! {ch1, Ch},
            loop(Chs2);
        {free, Ch} -&#62;
            Chs2 = free(Ch, Chs),
            loop(Chs2)
    end.
    
</PRE>

<P>The code for the server can be rewritten into a generic part
<CODE>server.erl</CODE>:
<PRE>
-module(server).
-export([start/1]).
-export([call/2, cast/2]).
-export([init/1]).

start(Mod) -&#62;
    spawn(server, init, [Mod]).

call(Name, Req) -&#62;
    Name ! {call, self(), Req},
    receive
        {Name, Res} -&#62;
            Res
    end.

cast(Name, Req) -&#62;
    Name ! {cast, Req},
    ok.

init(Mod) -&#62;
    register(Mod, self()),
    State = Mod:init(),
    loop(Mod, State).

loop(Mod, State) -&#62;
    receive
        {call, From, Req} -&#62;
            {Res, State2} = Mod:handle_call(Req, State),
            From ! {Mod, Res},
            loop(Mod, State2);
        {cast, Req} -&#62;
            State2 = Mod:handle_cast(Req, State),
            loop(Mod, State2)
    end.
    
</PRE>

<P>and a callback module <CODE>ch2.erl</CODE>:
<PRE>
-module(ch2).
-export([start/0]).
-export([alloc/0, free/1]).
-export([init/0, handle_call/2, handle_cast/2]).

start() -&#62;
    server:start(ch2).

alloc() -&#62;
    server:call(ch2, alloc).

free(Ch) -&#62;
    server:cast(ch2, {free, Ch}).

init() -&#62;
    channels().

handle_call(alloc, Chs) -&#62;
    alloc(Chs). % =&#62; {Ch,Chs2}

handle_cast({free, Ch}, Chs) -&#62;
    free(Ch, Chs). % =&#62; Chs2
    
</PRE>

<P>Note the following:
<P>
<UL>

<LI>
The code in <CODE>server</CODE> can be re-used to build many
        different servers.
</LI>


<LI>
The name of the server, in this example the atom
        <CODE>ch2</CODE>, is hidden from the users of the client functions.
        This means the name can be changed without affecting them.

</LI>


<LI>
The protcol (messages sent to and received from the server)
        is hidden as well. This is good programming practice and allows
        us to change the protocol without making changes to code using
        the interface functions.
</LI>


<LI>
We can extend the functionality of <CODE>server</CODE>, without
        having to change <CODE>ch2</CODE> or any other callback module.
</LI>


</UL>

<P>(In <CODE>ch1.erl</CODE> and <CODE>ch2.erl</CODE> above, the implementation
of <CODE>channels/0</CODE>, <CODE>alloc/1</CODE> and <CODE>free/2</CODE> has been
intentionally left out, as it is not relevant to the example.
For completeness, one way to write these functions are given
below. Note that this is an example only, a realistic
implementation must be able to handle situations like running out
of channels to allocate etc.)
<PRE>
channels() -&#62;
   {_Allocated = [], _Free = lists:seq(1,100)}.

alloc({Allocated, [H|T] = _Free}) -&#62;
   {H, {[H|Allocated], T}}.

free(Ch, {Alloc, Free} = Channels) -&#62;
   case lists:member(Ch, Alloc) of
      true -&#62;
         {lists:delete(Ch, Alloc), [Ch|Free]};
      false -&#62;
         Channels
   end.    
</PRE>

<P>Code written without making use of behaviours may be more
efficient, but the increased efficiency will be at the expense of
generality. The ability to manage all applications in the system
in a consistent manner is very important.
<P>Using behaviours also makes it easier to read and understand
code written by other programmers. Ad hoc programming structures,
while possibly more efficient, are always more difficult to
understand.
<P>The module <CODE>server</CODE> corresponds, greatly simplified,
to the Erlang/OTP behaviour <CODE>gen_server</CODE>.
<P>The standard Erlang/OTP behaviours are:
<P>
<DL>

<DT>
<A HREF="gen_server.html">gen_server</A>
</DT>

<DD>
For implementing the server of a client-server relation.

</DD>

<DT>
<A HREF="fsm.html">gen_fsm</A>
</DT>

<DD>
For implementing finite state machines.
</DD>

<DT>
<A HREF="events.html">gen_event</A>
</DT>

<DD>
For implementing event handling functionality.
</DD>

<DT>
<A HREF="sup_princ.html">supervisor</A>
</DT>

<DD>
For implementing a supervisor in a supervision tree.
</DD>

</DL>

<P>The compiler understands the module attribute
<CODE>-behaviour(Behaviour)</CODE> and issues warnings about
missing callback functions. Example:
<PRE>
-module(chs3).
-behaviour(gen_server).
...

3&#62; c(chs3).
./chs3.erl:10: Warning: undefined call-back function handle_call/3
{ok,chs3}
    
</PRE>
<A NAME="1.3"><!-- Empty --></A>
<H3>1.3 Applications</H3>

<P>Erlang/OTP comes with a number of components, each implementing
some specific functionality. Components are with Erlang/OTP
terminology called <STRONG>applications</STRONG>. Examples of Erlang/OTP
applications are Mnesia, which has everything needed for
programming database services, and Debugger which is used to
debug Erlang programs. The minimal system based on Erlang/OTP
consists of the applications Kernel and STDLIB.
<P>The application concept applies both to program structure
(processes) and directory structure (modules).
<P>The simplest kind of application does not have any processes,
but consists of a collection of functional modules. Such an
application is called a <STRONG>library application</STRONG>. An example
of a library application is STDLIB.
<P>An application with processes is easiest implemented as a
supervision tree using the standard behaviours.
<P>How to program applications is described in
<A HREF="applications.html">Applications</A>.<A NAME="1.4"><!-- Empty --></A>
<H3>1.4 Releases</H3>

<P>A <STRONG>release</STRONG> is a complete system made out from a subset of
the Erlang/OTP applications and a set of user-specific
applications.
<P>How to program releases is described in
<A HREF="release_structure.html">Releases</A>.
<P>How to install a release in a target environment is described
in the chapter about Target Systems in System Principles.<A NAME="1.5"><!-- Empty --></A>
<H3>1.5 Release Handling</H3>

<P><STRONG>Release handling</STRONG> is upgrading and downgrading between
different versions of a release, in a (possibly) running system.
How to do this is described in
<A HREF="release_handling.html">Release Handling</A>.<CENTER>
<HR>
<SMALL>
Copyright &copy; 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>