Application structure

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Application structure

Walter C. Reel III
I'm trying to learn Erlang and create a 'Proof of Concept' system at the same
time. I came across the Application structure in the 'Design Principles'
documentation.  Would it be better to start from this structure and work
upwards?  It would seem there is a lot of built in functionality that relates
to the application structure.

If so, does a node correspond to an application?  The mnesia schema would go
under 'App/priv' or 'App/priv/schema', right?

Thanks,
 - Walt


Reply | Threaded
Open this post in threaded view
|

Application structure

Ulf Wiger-4

My apologies - this reply got stuck in my drafts box for far
too long. I see noone else has replied to your question, so
I will send what I had written. Sorry if incomplete.

/Uffe

On Sun, 13 Apr 2003, Walter C. Reel III wrote:

>I'm trying to learn Erlang and create a 'Proof of Concept'
>system at the same time. I came across the Application
>structure in the 'Design Principles' documentation.  Would
>it be better to start from this structure and work upwards?
>It would seem there is a lot of built in functionality that
>relates to the application structure.

You should probably not try to comply to all of it at once.
Some basic initial steps could be taken to ease the
transition into more complex stuff later:

1) File structure

Organize your code into App/src, App/ebin, etc.
Try to keep the organization symmetric, e.g.
MyLib/App1
     /App2

You do not really have to dive into .app files and boot
scripts. If you want ready access to all your code, you can
add instructions in a .erlang file in your home directory
(assuming you're using UNIX):

code:add_paths([".../MyLib/App1/ebin", ...]).


2) Behaviours

If you use e.g. gen_server, it will be easier to adapt
your code to a supervision structure, and applications,
later.


3) Nodes and applications

>If so, does a node correspond to an application?  The
>mnesia schema would go under 'App/priv' or
>'App/priv/schema', right?


A node is one instance of the Erlang VM. You can run several
interconnected VM instances on the same machine, or on
different machiens across a network. OTP Applications are a
way of grouping modules and processes into a logical entity
that can be started, stopped or upgraded together.

Each OTP library (stdlib, kernel, inets, etc.) is an
application. Some (e.g. stdlib) do not actually start any
processes when starting the application (they can still be
started and stopped, but mainly for consistency and
convenience.)

A common setup is to keep the same code on all nodes -- i.e.
identical application trees. One very good reason for doing
this is to avoid having different versions of the same
module in the system. You may also start each node with the
same boot script, and rely on the OTP application controller
to decide which applications should run where.

Given this, naming the mnesia directory e.g. priv/mnesia or
priv/schema will work as long as you have only one node. The
default name for the mnesia directory is Mnesia.<nodename>.
You can have a similar setup under your priv/ directory, but
I would propose instead a habit of creating a
<systemname>.<nodename>/ directory, and under it, e.g. a
mnesia/ directory, logs/, etc. This will allow you to test
your system running several nodes on the same machine -- a
very nice aspect of Erlang.

/Uffe
--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes




Reply | Threaded
Open this post in threaded view
|

Application structure

Walter C. Reel III
Many thanks.  That pointed me in a much better direction.

On Thursday 17 April 2003 01:21 pm, Ulf Wiger wrote:
>
> 1) File structure
>
> Organize your code into App/src, App/ebin, etc.
> Try to keep the organization symmetric, e.g.
> MyLib/App1
>      /App2

I've noticed (after you mentioned it) that the standard libraries in the OTP
distribution adhere to that same type of organization.  Although I may be
stretching it, would it be safe to say that applications closely resemble the
idea of a package in Python or Java?

So, just to make sure I understand the terminology, a "system" is a collection
of interoperating nodes (which could be running on different machines) and a
"node" is an instance of the Erlang VM which could host multiple
application/server/etc. processes.  Right?
(Of course my current place of employment uses those terms but with completely
different meanings ;)

Cheers,
 - Walt


Reply | Threaded
Open this post in threaded view
|

Application structure

Lennart Ohman
Hi,
a problem is that many general terms are used to denote
(different) specific things in different contexts. In the Erlang/OTP
world the following is usually meant by:

Applications
are collections of resources. Today these are usually code (modules)
and processes (or supervision structures (trees) of processes).
Applications are the smallest piece which is handled by the release-
handler. Hence the smallest piece which can be replaced. The idea
is that application shall be idependent in a way that it can be
reused in other places. Dependencies among applications are of course
allowed. All applications depend on stdlib and kernel for instance.

A system, in this context, usually referes to a collection of applications.
These applications are usually started through a boot-script file generated
by a tool in the sasl application.

When you start a "standard Erlang" system, you use a standard boot-script
which starts a system with the applications kernel and stdlib.

Best Regards,

Lennart


Walter C. Reel III wrote:

> Many thanks.  That pointed me in a much better direction.
>
> On Thursday 17 April 2003 01:21 pm, Ulf Wiger wrote:
>
>>1) File structure
>>
>>Organize your code into App/src, App/ebin, etc.
>>Try to keep the organization symmetric, e.g.
>>MyLib/App1
>>     /App2
>
>
> I've noticed (after you mentioned it) that the standard libraries in the OTP
> distribution adhere to that same type of organization.  Although I may be
> stretching it, would it be safe to say that applications closely resemble the
> idea of a package in Python or Java?
>
> So, just to make sure I understand the terminology, a "system" is a collection
> of interoperating nodes (which could be running on different machines) and a
> "node" is an instance of the Erlang VM which could host multiple
> application/server/etc. processes.  Right?
> (Of course my current place of employment uses those terms but with completely
> different meanings ;)
>
> Cheers,
>  - Walt


--
-------------------------------------------------------------
Lennart Ohman                   phone   : +46-8-587 623 27
Sjoland & Thyselius Telecom AB  cellular: +46-70-552 6735
Sehlstedtsgatan 6               fax     : +46-8-667 8230
SE-115 28 STOCKHOLM, SWEDEN     email   : lennart.ohman



Reply | Threaded
Open this post in threaded view
|

Application structure

Ulf Wiger (AL/EAB)
From: "Lennart ?hman" <lennart.ohman>

> Applications are the smallest piece which is handled by the release-
> handler. Hence the smallest piece which can be replaced.

... by the release handler.  ;-)  (I know that's what you meant.)

The release handler provides ways to upgrade a collection of applications
(a system) in an orderly fashion. This includes performing a synchronized
upgrade across nodes in a multi-node(*) system. The release handler
also supports reversal of an upgrade, so that one can fall back to the
last stable version if something goes wrong.

An erlang module can of course be replaced by simply loading a new
version, but this is only safe under special circumstances (e.g. if the
module does not contain a representation of internal process state which
changes during the upgrade, and if the interface of the module doesn't
change.) This method of replacing code is of course still extremely
useful and used extensively during development and testing.

/Uffe

(*) as in Erlang node.