VT2015 akka

Présentation

• Enseignants : Georges-Pierre Bonneau, Didier Donsez (VT2015)
• Sujet : Akka
• Date : 13 novembre 2015
• Auteur : ZHANG Zhengmeng

Résumé

Akka est une trousse à outils open-source et l'exécution de simplifier la construction d'applications concurrents et distribués sur la JVM. Akka soutient plusieurs modèles de programmation pour la concurrence, mais il met l'accent sur la concurrence basée sur les acteurs, avec l'inspiration tirée de Erlang. Les liaisons de langage existent pour Java et Scala. Akka est écrit dans Scala, et à partir de Scala 2.10, la mise en œuvre d'acteur de Akka est inclus dans le cadre de la bibliothèque standard Scala.

Mots clefs

Akka, Toolkit, JVM, Scala, JAVA

Abstract

Akka is an open-source toolkit and runtime simplifying the construction of concurrent and distributed applications on the JVM. Akka supports multiple programming models for concurrency, but it emphasizes actor-based concurrency, with inspiration drawn from Erlang. Language bindings exist for both Java and Scala. Akka is written in Scala, and as of Scala 2.10, Akka's actor implementation is included as part of the Scala standard library.

Key Words

Akka, Toolkit, JVM, Scala, JAVA

Synthèse

Présentation d’Akka

Akka est un framework pour la construction de systèmes distribués basés sur les acteurs. La philosophie adoptée en termes de tolérance de panne pour ces systèmes est “let it crash“. En effet, les acteurs sont des éléments légers, qu’il est facile d’instancier et de relancer en cas de crash (du fait qu’ils ne partagent pas leur état). Pour cela, Akka impose une supervision afin de pouvoir gérer la mort prématurée d’acteurs, et ce dans une hiérarchie de supervision : tout nouvel acteur est supervisé par son parent. Cette supervision permet la création de systèmes qui s’auto-réparent.

De plus les acteurs sont purement asynchrones et peuvent être relocalisés de manière transparente, y compris dans une autre JVM (ce qui permet la création d’un véritable système distribué sur un cluster).

Akka permet de plus d’aller un peu plus loin que le modèle d’acteurs, en introduisant un hybride entre les acteurs et la mémoire transactionnelle logicielle (Software Transactional Memory, STM), qui est une autre alternative à la synchronisation par verrous dans laquelle les opérations sur les données partagées sont effectuées au sein de transactions, en isolation les unes des autres. Akka introduit donc les Transactors, qui ont des flux de messages “atomiques”, avec possibilités de réessayage automatique et de rollback.

Akka a des API en Java, mais fait aussi désormais partie de la pile Typesafe pour la programmation réactive : le langage Scala, Akka, et le framework web Play!.

Les acteurs

Le modèle des acteurs offre un modèle "simple" de faire communiquer différents processus par échange asynchrone de messages grâce à une abstraction plus haut niveau que celle que nous rencontrons avec l'API des threads et des verrous. Nous le verrons avec notre application le modèle des acteurs est particulièrement adapté à l'exécution de tâches indépendantes. Une application conçue avec ce modèle est constituée d'acteurs qui communiquent de manière asynchrone par échange de messages immuables. Un acteur n'expose pas son état interne au monde extérieur, il le garde jalousement pour lui seul évitant ainsi la nécessité de synchroniser lors de l'accès à des données partagées et les erreurs courantes comme les "dead locks" ou autres "race conditions". Chaque acteur dispose d'une boîte à messages qui contient les messages que le monde extérieur lui a envoyés. La vie d'un acteur est relativement routinière : il reçoit des messages, fait des traitements, envoie des messages. C'est presque tout ce qu'il sait faire.

La supervision

La philosophie "Let it crash" implique la nécessité de pouvoir détecter les crashes des composants de l'application. En clair nous devons "monitorer", superviser le système et prendre les décisions qui s'imposent en cas de panne d'un ou de plusieurs composants. Pour cela il faut choisir quels composants de l'application doivent être supervisés et quels autres jouent le rôle de superviseurs. Une fois ce choix opéré nous établissons les liaisons entre composants superviseurs et ceux supervisés. A ce jour, Akka offre deux stratégies de supervision

OneForOne: Dans cette stratégie le superviseur redémarre seulement le composant ayant crashé les autres n'étant pas impactés. AllForOne:Ici contrairement à la stratégie précédente lorsqu'un composant supervisé tombe, celui-ci ainsi que tous les autres sont redémarrés.

Anatomie d'un acteur Akka

Comme le montre l'image ci-dessous, un acteur Akka est constitué de plusieurs composants collaborateurs. Le ActorRef représente l'adresse logique d'un acteur et nous permet d'envoyer des messages de façon asynchrone à l'acteur d'une manière tire et oublie. Le répartiteur - par défaut, il est l'un par système d'acteur - prend soin de enqueuing messages dans la boîte aux lettres d'un acteur ainsi que la planification de la boîte aux lettres pour dequeuing un ou plusieurs messages - mais seulement un à la fois - pour être traité par l'acteur. Last but not least, l'Acteur - généralement la seule API, nous devons mettre en œuvre - encapsule état et le comportement.

Akka nous empêche d'obtenir un accès direct à un acteur et garantit ainsi que la messagerie asynchrone est la seule façon d'interagir avec lui: Il est impossible d'invoquer une méthode sur un acteur.

Il est également intéressant de souligner que l'envoi d'un message à un acteur et le traitement de ce message par l'acteur sont deux activités distinctes, qui se produisent le plus probablement sur différents threads - bien sûr Akka prend soin de la synchronisation nécessaire pour faire en sorte que tous les changements d'état sont visible pour tout fil. Par conséquent Akka sorte de nous permet de programmer dans une illusion mono-thread, soit nous ne pas - et ne devons pas - utiliser des primitives de synchronisation comme volatile ou synchronisé dans notre code d'acteur.

Example: L'application PhoneNumberSearchApp

Voyons maintenant en image l'application que nous allons développer:

Comment marche cette application? Le client dispose d'un ensemble de fichiers dont il souhaite extraire des numéros de téléphone (je dois avouer que cette application m'a été commandée la société Spamming Inc.). Il soumet donc ces fichiers à notre super application qui accomplit cette tâche si gratifiante. Puisque les fichiers peuvent être parsés indépendamment et parallèlement les uns des autres nous créons une tâche par fichier. Les tâches sont traitées suivant le pattern Master/Worker avec un Master qui distribue les tâches entre les Workers qui qant à eux parsent le contenu des fichiers.

Conclusion

Dans cet article, nous avons eu une introduction au modèle d’acteurs, tel qu’implémenté par Akka pour la création de systèmes distribués robustes et réactifs. Nous avons vu comment instancier des acteurs, comment les faire communiquer, et quelles sont les garanties de distribution offertes par la plate-forme, avec des pistes pour aller au-delà, et j’espère que cette entrée en matière vous sera utile dans la conception de votre prochaine application concurrente/distribuée.

Bibliographie

http://blog.nouhoumtraore.com/2011/05/introduction-akka.html

http://akka.io/docs/

https://en.wikipedia.org/wiki/Akka_(toolkit)

http://www.blogbus.com/dreamhead-logs/235916459.html