Jul/090
OTP, késako ?
L’application développée devra être écrite le plus possible dans les règles de l’art de la plateforme OTP.
Le problème est de comprendre exactement ce qu’est OTP, la documentation du site officiel étant à ce sujet très peu facile à lire… Les descriptions suivantes correspondent donc uniquement à ma compréhension du sujet.
Définition succinte
Open Telecom Platform est une « plateforme » comprenant un ensemble de librairies globalement nécessaires pour toute application. OTP structure la façon dont les programmes Erlang sont réalisés, tant au niveau des processus, des modules ou des répertoires.
Il est possible de dire - même si cela peut être apparenté à un abus de langage - qu’OTP rentre dans la mouvance de ce qui est nommé « convention over configuration », ou les bonnes pratiques par rapport à un ensemble de conventions. Autrement dit, si l’application livrée respecte certaines contraintes (de nommage, de conception ou design pattern, etc. bref les « conventions »), alors le système dans lequel tourne ces applications assure le développeur d’un certain nombre de comportements.
Et justement, OTP permet de définir des comportements pré-définis dans les applications. De plus, une structure de travail doit être respectée et normalise toutes les applications de type OTP.
Un développeur ayant connaissance d’OTP rentrera d’autant plus facilement dans une application respectant ces principes.
Ces principes s’ajoutent aux règles de programmation et bonnes pratiques concernant le langage lui même.
Caractéristiques principales (dans le désordre)
Respect d’une structure de fichiers.
La structure de base à respecter est simple et est la suivante :
root src/ > sources ebin/ > binaires (compilation) priv/ > données propres à l'application (?) include/ > dépendances
Création de comportements à partir de callback.
Il s’agit de la formalisation d’un comportement utilisé régulièrement pour réutilisation et simplification de son implémentation. Cette formalisation est divisée en une partie générique (fournie par OTP en tant que behavior) et une partie personnalisée (implémentée par l’application sous forme de fonctions de callback).
Les comportements standards sont :
- Server
- Le serveur d’une relation client/serveur, lorsqu’une ressource doit être partagée par exemple. Finite State Machine
- Permet d’implémenter des workflows. Event
- Création d’un gestionnaire d’événements pouvant contenir plusieurs fonctions de réaction aux événements. Supervisor
- Permet la création de processus de surveillance. Un superviseur peut surveiller de 1 à n processus. Il a la responsabilité de maintenir ses processus fils (surveillés) en vie et les redémarrer potentiellement si ils viennent à se terminer de façon impromptue.
Les comportements sont indiqués grâce à la directive behaviour, comme indiqué dans l’en tête :
-behaviour(gen_server).
Un code source comportant cette directive devra obligatoirement implémenter des fonctions callback qui seront ensuite appelée par le système.
Création d’applications.
Cette notion se rapport aux notions de « package » connus dans les autres environnements de programmation. Il est nécessaire de créer une application si l’on veut fournir un ensemble de traitements comme une seule entité.
