LUGE - Actor framework, survole

[Olivier-JOURDAN]

Présentation réalisée lors de la rencontre développeur du 4 juillet 2013

L'objectif était de faire une introduction à l'AF est d'ouvrir la discussion.

Pour ceux qui souhaite approfondir, direction le groupe https://decibel.ni.com/content/groups/actor-framework-2011

[CharlesB64]

Super récap de l'actor framework; comme je me pose les même questions que le dernier slide,  je suis particulièrement preneur des réponses que vous y avez apporté afin d'aider ma reflexion...

[Olivier-JOURDAN]

Pas facile de résumé la discussion. Pour le faire en 2 mots : ça semble être un framework puissant, mais avec une mise en oeuvre délicate et une "présentation" très inhabituelle.

Question est-ce que le jeu en vos la chandelle lorsque l'on sait se débrouiller sans ?

Pour ma part, je devrais pourvoir enfin le tester en grandeur nature et je pense qu cela peut apporter beaucoup, notamment pour éviter l'utilisation de classes référencées qui peuvent apporter de petits soucis "colatéraux".

Olivier

[CharlesB64]

Un des problèmes est que c'est massivement orienté objet (acteurs et messages sont des classes). Dans l'absolu ça me va, mais si LabVIEW est OOP,  l'utilisation n'est ni aisée ni fluide. Cela créée beaucoup de VIs qui ne font rien de fonctionnel (boilerplate), et même s'ils sont créés automatiquement ça vient encombrer le code source.

Pour un nouveau projet, je serais partant, mais mon problème se pose pour une application existante dont j'ai besoin d'étendre l'architecture. S'il y avait déjà un framework de messaging, autant rester avec.

Dans mon cas le messaging est basique (chaque contrôleur reçoit des commandes en QMH, qui lui-même a soit du DVR pour instancier les objets de comm hardware, soit pas de DVR mais l'objet de comm hardware met ses data en queue). C'est là que le choix est difficile, le passage à de l'AOP s'apparentant presque à une réécriture. Mais comme je dois remanier pas mal de choses de toutes façons, ça me titille...

Là où j'ai du mal à me représenter la chose, c'est quand une action dépend d'un acteur qui est en train de faire le job, et que tu dois attendre sa réponse, sachant que AristosQueue (le concepteur du framework) dit que tu dois oublier le messaging synchrone (envoie commande, attente réponse). L'asynchronicité me trouble

[Behr-33]

Je m'interroge aussi sur la mise en application de l'AF.

Concrètement, j'ai réalisé une architecture GOOP pour un projet avec des Objets dont le comportement était de fait asynchrones. Ce projet traite de la gestion de trames arrivant sur le port réseau UDP afin de suivre l'activité et le status de différents instruments déportés.
Au bénéfice de congés bien mérités, j'ai pris temps de me documenter sur l'AF afin d'identifier s'il pouvait contribuer efficacement à ce projet, le moment était propice puisqu'aucune implémentation n'était réalisée.
Conclusion, même si le moment et le sujet s'y prétait fortement, j'ai jugé que les points suivants pourraient nuire à une implémentation s'appuyant sur l'AF.

• L'AF doit être connu de l'ensemble de l'équipe de développement. Mon équipe ne satisfait pas ce critère. L'AF nécessite une forte expertise en Labview. Je crains finalement qu'utiliser l'AF rime avec, je fais le projet tout seul.
• Même les maitres Jedi de Labview Français (ils se reconnaitront) n'ont pas encore une grande culture de ce Framework. Je ne serais pas pionner sur cette technologie.
• Enfin, on croit profondemment que c'est plus efficace, plus maintenable ... mais pour l'heure on a pas de retour d'expérience et finalement si on fait ce choix, on est prisonnier de cette architecture. C'est peut être ça qui me fait le plus peur. On voit assez bien (je conseille à ce titre fortement de suivre la formation Objet de labview pour ceux qui sont intéressés, je l'ai suivi et ça m'a servi) comment faire du GOOP, un peu, beaucoup voire du full objet, c'est graduel. Avec l'AF, je crains (c'est un jugement de valeur) que ce soit beaucoup plus binaire.

Je souhaite bon courage à tous ceux qui feront le premier pas. L'AF me séduit profondemment, j'aurais un grand plaisir à l'implémenter... mais pas dans l'immédiat.

[Desruelle_luc]

salut, @Behr-33, je partage tes retours sur l'AF, surtout  ".../... L'AF doit être connu de l'ensemble de l'équipe de développement. Mon équipe ne satisfait pas ce critère. L'AF nécessite une forte expertise en LabVIEW. .../...