Application (OTP)

Applications are the way you package related modules in Erlang. The focus here isn’t on packaging for distribution but on being able to treat a bunch of modules as a single entity. Although OTP applications can be merely some library code for others to call, more often they're like creatures with a life of their own: they start up, do what they’re designed to do, and shut down. Some can have multiple running instances, and some are limited to one instance at a time. (Logan, Merritt, and Carlsson 2010, 119)

Active Applications

All applications have the same basic structure (…). The application behaviour encapsulates starting and stopping the application. When started, a running application has a root Supervisor, which directly or indirectly manages all the other processes of the application (including any subsystem supervisors). (Logan, Merritt, and Carlsson 2010, 243)

Active Applications have a life cycle and must be started in order to be useful.

erlang_application_structure.png

Metadata

OTP needs a certain amount of information to make sense of active applications, like what to start/stop (provided you implement the application behaviour) in your module and which dependencies are require to do so. This sort of information is contained within the .app file. All this metadata is needed to proper manage the application, the vsn tuple is particularly importante in the context of release management. 

{application, example,
  [{description, "Description Example"},
   {vsn, "0.0.1"},
   {modules, [example, example_sup, example_module]},
   {registered, [example, example_sup]},
   {applications, [kernel,stdlib]},
   {mod, {example_app,[]} }]}.

  1> application:loaded_applications().

The Application Controller

There is only one application controller per runtime system, registered under the name application_controller. (…) The controller is also responsible for loading the .app file for the application and checking that all the applications it depends on have been started first. (Logan, Merritt, and Carlsson 2010, 245)

Start Types

  • permanent
  • temporary

Library Applications

Library applications are a passive collection of modules to be used by other applications, and they don't need to be started or stopped.

Making a Release

Packaging of functionality in Erlang/OTP can be viewed as a hierarchy. At the lowest level are modules, which encapsulate code. Modules are grouped into applications, which encapsulate dynamic behavior and higher-level functionality. Finally, applications are grouped into releases. (Logan, Merritt, and Carlsson 2010, 245)

Releases

A release consists of a set of applications together with some metadata specifying how to start and manage those applications as a system. The applications in a release execute together in the same Erlang runtime system: a target system, stripped down to run only these applications.

(…)

To summarize:

  • A release describes a running Erlang runtime system.
  • A release has a version.
  • A release aggregates a number of versioned applications along with metadata on how to manage the system.
  • Installing a release on a host machine produces a target system.

(Logan, Merritt, and Carlsson 2010, 246)

erlang_release_structure.png

Metadata

System Configuration

The standard name for a configuration file is sys.config. The name can be anything as long as it ends with the extension .config. Just like the .app file and the .rel file, the .config file contains a single Erlang term followed by a period. (Logan, Merritt, and Carlsson 2010, 250)

References:

Logan, Martin, Eric Merritt, and Richard Carlsson. 2010. Erlang and Otp in Action. Manning Publications Co.

Backlinks: