Intergiciel pour l'Informatique Ambiante
Domaine de la HDR :
Message : Basé sur une définition restreinte de la notion d'intergiciel = masquer la distribution et les communications réseaux
Message : Basé sur une définition plus générale d'intergiciel =
Nouveaux challenges :
1> Aujourd'hui des blocs distincts et/ou organisés en couche : OS / Runtime Graphique / Middleware Réseau / Contexte …
Pourtant la non interaction autre qu'applicative (en bloc) ou la hiérarchie (en couche) entre ces middlewares ne sont aproprié. Exemple (thèse hourdin) le contexte peut tout autant influencer les fonctionalités offertes par un middleware réseau que le middleware réseau intervenir dans la gestion du contexte.
Séparation des préocuppation OK mais entrelacement (tissage).
2> Chaque ressource est alors associée à un gestionnaire ayant pour objectif de garantir le comportement de la ressource en cas d'accès multiples et concurrents. (travaux avec Annie Ressouche, vers des proxies prouvés)
L'environnement est alors perçu au travers des données représentatives et rafraichies. Sauf dans quelques cas extrêmes (Temps Réel par exemple), le comportement temporel de l'application est souvent prise en compte tardivement dans une phase d'optimisation. Cela est acceptable dans la mesure où de telles optimisations et évolutions des performances matérielles peuvent répondre à l'amélioration du comportement temporelle de l'application. Il est pourtant bien des cas ou la complexité croissante et mal maitrisé de la collecte et du traitement de l'information rende cette quête vaine. Il est dans ce cas important de garantir au système la capacité de réagir avec des temps de réponses acceptables et appropriés quitte à réduire l'étendue des données collectées et la complexité des traitements mis en jeux.
Ce constat inspire une démarche appelée décomposition comportementale de l'application. Elle consiste à limité la collecte de l'information et son traitement pour l'accomplissement du seul comportement que l'on veut que le système adopte. Il s'agit alors de composer de tels entités tout en maitrisant leurs interactions.
Cette démarche à largement fait ses preuves en Robotique.
Définition du comportement : par Wiener Norbert (en définissant la notion de cybernetique) : “boucle fermée permettant d'évaluer les effets de ses actions et de s'adapter à une conduite future grâce aux performances passées”.
Cf. livre Middleware Cf. Adaptation Dynamique Model at Runtime Cf Benomo
Problème commun réduire la complexité des adaptations Les Ecoles : - MOP (reflexivité) - Aspects classiques - Policy based … - concept-based - Multi-agent … - Model at Runtime et AOM
* Perspective : End User programming
Le principe de subsomption (subsumption) promu par Brooks pour sa décomposition comportementale définit par nature une relation héirarchique entre ces comportements. En effet la notion de subsomption se définti ainsi (Cf. http://fr.wikipedia.org/wiki/Subsomption) : La subsomption désigne une relation hiérarchique entre des concepts, dans les logiques de description. Cette notion est proche de la relation « est impliqué par » en logique classique, ou encore « contient » en logique ensembliste. (La relation de subsomption permet de construire un treillis de Galois à partir d'un ensemble d'individus et de propriétés.)
Exemples:
de même que pour Brooks un comportement de haut niveau comme chercher une boîte dans l'environnement du robot subsume un comportement de plus bas niveau comme éviter les obstacles autour du robot.
A la différence des composants qui sont instanciés à la demande et peuvent avoir plusieurs instances en même temps, un service est unique. Il correspond au design pattern Singleton. (Cf. http://fr.wikipedia.org/wiki/Architecture_orient%C3%A9e_services#Le_service)
Un composant est un élément de base d'un ensemble plus complexe (structuré ou composite), lequel est un assemblage de composants souvent différents. (Cf. http://fr.wikipedia.org/wiki/Composant)
http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_composant
A LIRE : http://www.irisa.fr/triskell/publis/2004/Jezequel04b.pdf (historique des paradigmes logiciels)
A LIRE : http://blog.xebia.fr/2009/06/04/soa-du-composant-au-service-sans-etat-stateless/ (composant versus service et statelessness)
A LIRE :http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles (Statelessness)