Je ne suis pas certain de bien comprendre toutes tes remarques. Or, vu ton expérience d'ex mainteneur d'un framework d'objet actif, j'aimerais être certain de bien comprendre tes remarques.
Un objet actif c'est masquer derrière un proxy ayant une sémantique orientée objet quelque chose qui ne l'est pas du tout (appel de méthode local synchrone VS dispatch distant asynchrone).
Pour moi, les com entre objets actifs sont toujours asynchrones (par exemple par envoi de message dans des boites aux lettres). Tu es d'accord avec cela ?
Si oui, en gardant cette analogie avec les BAL, puis-je considérer que le proxy, c'est celui qui ecrit dans la BAL (ou les BAL) de l'objet actif (ou des objets actifs) les messages, c'est bien cela ? L'objet actif lui est en attente en lecture sur sa BAL. Des qu'un message arrive, il le traite alors et exécute ou non ses propres méthodes internes.
Bref, pour moi, cela reste fondamentalement asynchrone et très conception orienté objet (En conception OO, les objets communiquent par envoi de message).
C'est grosso modo le même problème que les systèmes de type RPC, connu depuis très longtemps mais après 20 ans on arrive toujours au même conclusion.
Du coup, je ne comprend pas cette comparaison avec le RPC (qui est pour moi une com synchrone, on reste dans l'appel de méthode avec attente, qu'il soit distant ou non).
Surtout que dans l'article que tu donnes, ce qu'ils me semblent critiquer dans le RPC, c'est justement cette volonté de vouloir conserver l'illusion du synchronisme alors que dans un monde distribué, c'est plutôt l'asynchrone qui est de mise.
Effectivement, ce postulat d'asynchronisme des com oblige le concepteur à penser à pas mal de chose (par exemple, tout besoin de com synchrone doit être transformée en 2 com asynchrone). Ce travail supplémentaire, c'est cela que tu critiques ?
Pour ma part, je trouve cela justement bien car on ne laisse rien d'implicite.
Et du coup, je comprend pas ta remarque sur les erreurs (j'imagine de com). Car pour moi, elles doivent être gérées par le concepteur (avec des com asynchrone, on n'a pas de garantie sur la réception du message, plus précisément par sa prise en compte par l'appelé). Il n'a pas le choix, et je ne comprend pas ta remarque sur ce pb de la gestion des erreurs.
Un modèle à objet actif, je veux bien au sein d'un unique processus mais ça me semble un mauvais compromis, vu que t'as le pire de deux mondes entre un truc mono-process bien designé qui va vite et une abstraction solide pour exprimer du parallélisme potentiellement distribué.
La non plus, je ne comprend pas trop le problème. Pour moi, un objet actif ne présente justement que des avantages pour passer à du multi-tâche car il permet d'isoler les parties ayant un vrai besoin de parallélisme (par rapport à la logique métier de l'applicatif). Ensuite, le mapping un objet actif = un thread/process/tache n'est pas toujours aussi simple certes, mais cela marche souvent.
[Note: vision biaisée d'un ex-mainteneur d'un framework à objet actifs...]
Ca m'intéresse de savoir lequel car utilisant celui de Quantum Leap (voir lien donné dans mon post précédant), je le trouve super et ne vois pas trop de problème.
[^] # Re: Retour sur les objets actifs
Posté par BlueDian . En réponse à la dépêche Instantané sur le parallélisme et le code. Évalué à 2. Dernière modification le 23 juin 2015 à 11:56.
Bonjour,
Je ne suis pas certain de bien comprendre toutes tes remarques. Or, vu ton expérience d'ex mainteneur d'un framework d'objet actif, j'aimerais être certain de bien comprendre tes remarques.
Pour moi, les com entre objets actifs sont toujours asynchrones (par exemple par envoi de message dans des boites aux lettres). Tu es d'accord avec cela ?
Si oui, en gardant cette analogie avec les BAL, puis-je considérer que le proxy, c'est celui qui ecrit dans la BAL (ou les BAL) de l'objet actif (ou des objets actifs) les messages, c'est bien cela ? L'objet actif lui est en attente en lecture sur sa BAL. Des qu'un message arrive, il le traite alors et exécute ou non ses propres méthodes internes.
Bref, pour moi, cela reste fondamentalement asynchrone et très conception orienté objet (En conception OO, les objets communiquent par envoi de message).
Du coup, je ne comprend pas cette comparaison avec le RPC (qui est pour moi une com synchrone, on reste dans l'appel de méthode avec attente, qu'il soit distant ou non).
Surtout que dans l'article que tu donnes, ce qu'ils me semblent critiquer dans le RPC, c'est justement cette volonté de vouloir conserver l'illusion du synchronisme alors que dans un monde distribué, c'est plutôt l'asynchrone qui est de mise.
Effectivement, ce postulat d'asynchronisme des com oblige le concepteur à penser à pas mal de chose (par exemple, tout besoin de com synchrone doit être transformée en 2 com asynchrone). Ce travail supplémentaire, c'est cela que tu critiques ?
Pour ma part, je trouve cela justement bien car on ne laisse rien d'implicite.
Et du coup, je comprend pas ta remarque sur les erreurs (j'imagine de com). Car pour moi, elles doivent être gérées par le concepteur (avec des com asynchrone, on n'a pas de garantie sur la réception du message, plus précisément par sa prise en compte par l'appelé). Il n'a pas le choix, et je ne comprend pas ta remarque sur ce pb de la gestion des erreurs.
La non plus, je ne comprend pas trop le problème. Pour moi, un objet actif ne présente justement que des avantages pour passer à du multi-tâche car il permet d'isoler les parties ayant un vrai besoin de parallélisme (par rapport à la logique métier de l'applicatif). Ensuite, le mapping un objet actif = un thread/process/tache n'est pas toujours aussi simple certes, mais cela marche souvent.
Ca m'intéresse de savoir lequel car utilisant celui de Quantum Leap (voir lien donné dans mon post précédant), je le trouve super et ne vois pas trop de problème.