3 État de l’art
3.2 Composition dynamique et automatique de services et de com- com-posants logiciels
3.2.3 Analyse et positionnement
Nous reprenons les travaux de composition automatique et dynamique de services et de composants logiciels précédemment présentés et indiquons comment ils répondent aux exi-gences que nous avons définies (cf. chapitre2). Le Tableau3.1 et le Tableau3.2 présentent
l’analyse des travaux sur la composition dynamique et automatique lorsque le plan d’as-semblage est connu (cf. section3.2.1) et lorsqu’il est inconnu (cf. section3.2.2). Le symbole
“-” indique que l’exigence n’est pas couverte par le travail analysé. Le symbole “+” indique que l’exigence est traitée. Le nombre de “+” indique le niveau de satisfaction de l’exigence, ce nombre varie de 1 à 3.
Tous les travaux présentés répondent à l’exigence d’automatisation[AR1]et à l’exigence de décision[DA1]. Les approches proposées arrivent à automatiser la composition. Qu’elles soient basées sur un plan d’assemblage prédéfini ou sur des buts ou besoins explicites de l’utilisateur, elles sélectionnent les bonnes briques à composer et décident ainsi des applications à construire.
Tous les travaux, à l’exception de [Desnos et al., 2006] répondent à l’exigence de connais-sances[DA3]. Dans le travail de [Desnos et al., 2006], lorsque le système doit décider entre plusieurs services candidats, il ne se base pas sur une forme de connaissance mais sur une heuristique prédéfinie (par exemple : choisir le service candidat qui ajoute le moins de dépendances). Les autres travaux utilisent des connaissances dans la prise de décision, comme, la QoS [Zeng et al., 2003, Liu et al., 2012, Wang et al., 2010, Cossentino et al., 2015, Wang et al., 2016b, Wang et al., 2016a, Liu et al., 2016, Sabatucci et al., 2018], la sémantique [Kalasapur et al., 2005, Mayer et al., 2016, Elhabbash et al., 2020, Nundloll et al., 2020], les deux [Fki et al., 2017] ou encore les priorités des services [Bartelt et al., 2013].
Tous les travaux, à l’exception de [Kalasapur et al., 2005, Wang et al., 2010, Wang et al., 2016b, Wang et al., 2016a], répondent à l’exigence de généricité de l’archi-tecture [AR2]. Le travail [Kalasapur et al., 2005] ne s’applique qu’aux composants de type multimédia. Dans les travaux [Wang et al., 2010, Wang et al., 2016b, Wang et al., 2016a], l’absence de généricité est due à l’utilisation d’un processus de décision de Markov (MDP) pour modéliser le plan d’assemblage. Le MDP est construit pour un cas d’utilisation particulier ; il n’est pas applicable à un autre domaine d’application.
Plusieurs travaux ne répondent pas aux exigences [AR3] et [AR4] qui concernent, res-pectivement, la perception de l’environnement ambiant et l’adaptation à ce dernier.
Les approches proposées dans [Zeng et al., 2003, Desnos et al., 2006, Liu et al., 2012, Khanouche et al., 2019, Wang et al., 2010, Wang et al., 2016b, Wang et al., 2016a] se basent sur un ensemble de services fixé avant l’exécution. Ils ne prennent donc pas en charge la dynamique et l’instabilité des environnements hébergeant les services, ce qui les rend inadaptés pour les environnements ambiants. Les approches proposées dans [Kalasapur et al., 2005, Liu et al., 2016, Fki et al., 2017], quant à eux, se basent sur un en-semble de services découverts dynamiquement au début de l’exécution. Elles ne détectent donc pas l’apparition, la disparition et la réapparition des services en cours d’exécution et les applications construites ne sont pas recomposées.
Certains travaux comme [Bartelt et al., 2013, Mayer et al., 2016, Cossentino et al., 2015, Sabatucci et al., 2018] répondent partiellement aux exigences [AR3] et [AR4]. L’approche proposée dans [Bartelt et al., 2013] peut détecter l’apparition d’un composant et l’intégrer dans l’assemblage en cours de construction (car un composant est capable de modifier sa
connexion pendant l’exécution). De même, l’approche proposée dans [Mayer et al., 2016]
peut détecter la disparition d’un service et réagir en cherchant un remplaçant poten-tiel qui continue à satisfaire les buts de l’utilisateur. Les approches proposées dans [Cossentino et al., 2015, Sabatucci et al., 2018] supportent elles aussi la disparition des ser-vices grâce à la réorganisation dynamique des agents du système multi-agent.
Seuls les travaux exposés dans [Elhabbash et al., 2020, Nundloll et al., 2020] ré-pondent complètement aux exigences [AR3] et [AR4]. L’approche proposée dans [Elhabbash et al., 2020, Nundloll et al., 2020] est capable de s’adapter à un environne-ment dynamique, ouvert et instable grâce au mécanisme de diffusion périodique de la description des systèmes et la maintenance du modèle de composition du contrôleur. Ainsi, lorsqu’un système disparaît (respectivement apparaît) il est supprimé (respectivement ajouté) dans le modèle.
Seul le travail de [Mayer et al., 2016] en proposant un VSL pour visualiser l’ordre d’exécution des services répond à des exigences liées à l’interaction avec l’utilisateur comme l’appropriation et l’intelligibilité [AR6] et [AR11]. Mais aucun ne répond aux exigences [AR5], [AR7], [AR8], [AR9] et [AR10]. Les applications étant construites selon un plan d’assemblage prédéfinie ou pour répondre à des besoins explicites, il n’est pas nécessaire de présenter à l’utilisateur l’application qu’il a demandée (et qui par conséquent ne devrait pas le surprendre). On peut également supposer que ce dernier n’a pas besoin de garder le contrôle des propositions du système de composition.
Les approches proposées construisent des applications pertinentes pour l’utilisateur répondant ainsi à l’exigence [DA2]. Ceci est en partie expliqué par la nécessité d’indiquer directement ou indirectement au système les besoins de l’utilisateur, Ces derniers sont explicités sous la forme :
- de besoins et de buts [Kalasapur et al., 2005,Desnos et al., 2006,Cossentino et al., 2015, Sabatucci et al., 2018,Mayer et al., 2016],
- de contraintes et de préférences en termes de QoS [Zeng et al., 2003, Liu et al., 2012, Liu et al., 2016, Khanouche et al., 2019, Wang et al., 2010, Wang et al., 2016b, Wang et al., 2016a],
- d’intentions de l’utilisateur [Fki et al., 2017]. Il s’agit en fait d’une combinaisons des éléments des deux items précédents,
- de priorités de services, ces priorités étant données par l’utilisateur [Bartelt et al., 2013].
Concernant les dernières exigences liées à la décision et à l’apprentissage du système de composition, il existe plusieurs travaux, comme [Wang et al., 2010, Wang et al., 2016a, Wang et al., 2016b, Liu et al., 2016], qui ont intégré de l’apprentissage automatique dans leurs approches de composition, répondant ainsi à l’exigence d’apprentissage[DA5].
Cependant, dans ces approches, l’apprentissage ne concerne pas les préférences de l’uti-lisateur (comme sa préférence entre un service connu et un service nouveau) et ne prend pas
en considération le feedback de l’utilisateur. Par conséquent, ces travaux ne répondent pas aux exigences[DA4],[DA6],[DA7].
Nous revenons plus en détail sur ces aspects dans la section suivante3.3.
En ce qui concerne l’exigence de généricité de la décision et de l’apprentissage [DA8], tous les travaux y répondent (complètement ou partiellement) à l’exception de [Kalasapur et al., 2005].
Les travaux de [Wang et al., 2010, Wang et al., 2016b, Wang et al., 2016a] et de [Liu et al., 2016] répondent complètement à cette exigence. Le modèle d’apprentissage proposé dans leur approche se base sur une méthode d’apprentissage par renforcement (Q-Learning et le raisonnement par cas respectivement) qui peut opérer sans connaissance préalable. De plus les décisions de connexions sont prises indépendamment de la nature des services et du domaine d’application.
Les autres travaux présentés dans cette section ne proposent pas de modèle d’apprentis-sage. Cependant, dans leur approche, les décisions de connexions sont prises indépendam-ment de la nature des services et du domaine d’application. C’est la raison pour laquelle, ces travaux répondent partiellement à l’exigence[DA8].