OTP
OTP is a domain-independent set of frameworks, principles, and patterns that guide and support the structure, design, implementation, and deployment of Erlang systems. Using OTP in your projects will help you avoid accidental complexity: things that are difficult because you picked inadequate tools.
OTP is said to consist of three building blocks that, when used together, provide a solid approach to designing and developing systems in the problem domain we’ve just described. They are Erlang itself, tools and libraries, and a set of design principles. (Cesarini and Vinoski 2016, 4)
The Tripartite Structure of OTP
Erlang
Tools and Libraries
Basic Applications
Together with the compiler, these are the minimal subset of applications necessary in any system written in Erlang/OTP to do anything meaningful. (Cesarini and Vinoski 2016, 8)
- ERTS
- The kernel
- The Standard Libraries (stdlib)
- The System Architecture and Support Libraries (sasl)
Database Applications
- MNESIA
odbc
Operations and Maintenance Applications
os_monsnmpotp_mibs
Interface and Communication Applications
eierl_interface
System Design Principles
The third building block of OTP consists of a set of abstract principles, design rules, and generic behaviors. The abstract principles describe the software architecture of an Erlang system, using processes in the form of generic behaviors as basic ingredients. Design rules keep the tools you use compatible with the system you are developing. Using this approach provides a standard way of solving problems, making code easier to understand and maintain, as well as providing a common language and vocabulary among the teams.
OTP generic behaviors can be seen as formalizations of concurrent design patterns. Behaviors are packaged into library modules containing generic code that solves a common problem. They have built-in support for debugging, software upgrade, generic error handling, and built-in functionality for upgrades. (Cesarini and Vinoski 2016, 10)
Behaviors
Behaviours are a way of formalizing common patterns in process-oriented programming. For example, the concept of a server is general and includes a large portion of all processes you’ll ever need to write. All those processes have a lot in common—in particular, whether they should be made to follow OTP conventions for supervision and other things. (…)
Instead, an OTP behaviour takes such a recurring pattern and divides it into two halves: the generic part and the application-specific implementation part. These communicate via a simple, well-defined interface. (Logan, Merritt, and Carlsson 2010, 97)
Components of a Behaviour
The idea behind OTP behaviors is to split up the code into two modules: one for the generic pattern, referred to as the behavior module, and one for specifics, referred to as the callback module. The generic behavior module can be seen as the driver. While it doesn’t know anything about what the callback module does, it is aware of a set of exported callback functions it has to invoke and the format of their return values. The callback module isn’t aware of what the generic module does either; it only complies with the format of the data it has to return when its callback functions are invoked.
- The interface
- The implementation
- The container
Behavior Types
OTP provides six behaviors that cover the majority of all cases:
- Application (OTP): Implements the
applicationbehaviours, which is a way to package related modules in Erlang. - Gen Server: An OTP generalization of the client/server model.
- Supervisor: Used to implement supervision trees.
- Gen StateM and : Both are implementations for State Machines, the latter being deprecated in favor of the former.
- Gen Event: Used for building event handlers (like error loggers).
Among those, gen_servers, FSMs, and gen_event handlers are examples of workers
processes, i.e. they perform the bulk of the computations. Worker processes are
held together and monitored by supervisors, which themselves are part of
applications.