SAAFA-76-MRRRCH
Informatique ubiquitaire et services Web
Informatique ubiquitaire et services Web
Caractéristiques d’un environnement ubiquitaire I.2.1 L’hétérogénéité Les équipements utilisés dans un environnement ubiquitaire sont très variés (ordinateur portable, PDA, smart phone, etc.). Ces derniers fonctionnent avec différents systèmes d‟exploitation (tels que Windows, Linux, Windows CE, PalmOS, Symbian, etc.), et éventuellement avec des configurations matérielles et logicielles différentes. De plus, ces équipements s‟appuient sur diverses technologies de communication fil et sans fil. L‟hétérogénéité se manifeste alors sur trois niveaux : L’hétérogénéité au niveau des architectures matérielles : L‟industrie informatique a¨ connu récemment une évolution très rapide. La figure I.1 modélise de manière cyclique ce processus et montre les transitions entre les différentes périodes d‟utilisation Ce processus commence d‟abord par une période d‟invention et d‟utilisation de la technologie, avant que cette dernière soit introduite dans notre vie de tous les jours. L‟accent a été mis par la suite sur la miniaturisation afin de faciliter l‟utilisation et de permettre la construction de dispositifs de plus en plus intégrés. Comme une alternative nécessaire à la complexité inhérente aux équipements conçus pour supporter n‟importe quelle application informatique, L‟horizontalisation propose la conception de multiples composants dédiés à une utilisation spécifique. Ces derniers effectueront leurs tâches par coopération, et non plus par intégration. Cette étape provoquera donc une croissance de l‟hétérogénéité des entités informatiques car leur nombre augmentera. Comme dernière étape du processus, la technologie devienne invisible à l‟utilisateur. L’hétérogénéité au niveau des composants logiciels : L‟apparition des systèmes¨ d‟exploitation dans les années 60 a offert aux applications une plate-forme d‟exécution indépendante de la couche matérielle sous-jacente. Avec le temps, l‟hétérogénéité se pose au niveau du logiciel s‟exécutant au-dessus du système d‟exploitation. L‟indépendance par rapport au système d‟exploitation est réalisée grâce à l‟utilisation des langages de programmation interprétés tels que Java et C#, ou des langages de script tels que Chapitre I : Informatique ubiquitaire et services Web 6 JavaScript et Python. Un programme écrit, par exemple en Java, est censé s‟exécuter partout sur une machine virtuelle Java. L’hétérogénéité au niveau de l’infrastructure de communication : Comme le montre¨ la figure I.2, plusieurs technologies filaires et sans fil sont cohabitées afin d‟accéder au médium de communication. Il existe une large gamme de technologies d‟accès développées ces dernières années. Nous citons quelques unes, sans être exhaustif. Pour les réseaux cellulaires, on trouve les technologies : GSM (Global System for Mobile Communications), GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System) qui offrent une large couverture géographique, nationale voire internationale, à des débits limités. Pour les réseaux filaires, PSDN (PacketSwitched Data Network) et DSL (Digital Subscriber Line) offrent des débits importants. Les réseaux sans fil, tels que Wi-Fi (IEEE 802.11a/b/g) ou Bluetooth, pour des communications courtes/moyennes portée, offrent les mêmes services que l‟Ethernet sans avoir besoin d‟une infrastructure fixe. Par conséquent, Les terminaux seront équipés de plusieurs interfaces réseau pour pouvoir utiliser la totalité des réseaux d‟accès déployés. Limitation des ressources La miniaturisation des équipements est l‟un des facteurs qui a poussé vers l‟informatique mobile. La plupart des équipements mobiles sont conçus d‟une manière à être facilement transportables par les utilisateurs. Ils sont petits non seulement en terme du facteur forme, mais aussi en terme de puissance de traitement, mémoire, la taille d‟affichage et l‟énergie de la batterie. Tous ces facteurs limitent le type de traitement qui peut être effectué sur ces équipements. Malgré les progrès technologiques, les capacités de ces équipements resteront, sans doute, toujours limités par rapport aux PC de bureau. I.2.3 Limitation des réseaux La connexion sans fil utilisée dans les équipements mobiles est souvent limitée en bande passante et instable par rapport à la connexion filaire. A présent, les technologies standard sans fils incluent le Blutooth, Wi-Fi, GPRS, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g et d‟autres en cours de développement. La vitesse lente de ces technologies par rapport au réseau filaire a été toujours une barrière pour exécuter de grandes applications et déplacer des données volumineuses sur les mobiles. Chapitre I : Informatique ubiquitaire et services Web 7 I.2.4 Une mobilité très élevée Les utilisateurs dans un environnement pervasif sont très mobiles. Sans êtres attachés à un équipement fixe, les utilisateurs peuvent se déplacer librement d‟une place à une autre. Par exemple, un utilisateur dans sa voiture utilise un afficheur numérique pour regarder une conférence. En se déplaçant de la voiture vers la maison, il transfère la conférence à son PDA. Une fois qu‟il est arrivé à la maison, il continue de regarder la vidéo conférence sur son PC. Cette nature élevée de mobilité provoque un changement continu de l‟environnement, et du contexte qui peut affecter l‟exécution de certaines applications. I.2.5 Applications distribuées Les environnements ubiquitaire sont de nature distribuée. En effet, les dispositifs qui se trouvent dans un tel environnement se situent dans des endroits différents et proposent leurs propres services. Ces dispositifs sont interconnectés via des réseaux filaires ou sans fil, et exploitent les infrastructures (middlewares) de communication développées dans le cadre des systèmes distribués telles que CORBA, SOA, etc. Ces infrastructures permettent de présenter les services, les exécuter, et les échanger entre les différents dispositifs si nécessaire. I.2.6 La sensibilité au contexte Le dynamisme de l‟environnement provoque des changements dans le contexte des applications. Les premières applications sensibles au contexte, en informatique ubiquitaire, étaient sensibles à la localisation, en se basant notamment sur le système GPS (Global Positioning System) [73]. Le contexte peut comporter d‟autres types d‟informations tels que : les préférences et environnement de l‟utilisateur, le terminal utilisé, les informations indiquant l‟état physique ou émotionnel des personnes (la température corporelle, le rythme cardiaque, etc.)[55]. Le contexte à prendre en compte est toujours différent et dépend du but de l‟application que l‟on veut rendre sensible. Dans différents contextes, les utilisateurs accèdent aux même données et aux mêmes services mais reçoivent des réponses qui peuvent être différentes ou présentées différemment ou encore à des niveaux de détails différents [11]. Par exemple, un médecin consulte le dossier médical d‟un patient à l’hôpital à l’aide d’un ordinateur de bureau. Dans un autre contexte, il consulte le même dossier mais chez le patient à l‟aide d‟un ordinateur de poche. Il peut aussi avoir une synthèse vocale du même dossier dans un autre contexte. Les informations contextuelles sont donc un élément très important à prendre en considération en informatique ubiquitaire. I.3 Les middlewares de communication La communication dans les environnements ubiquitaires nécessite de faire fonctionner tous les dispositifs qui y sont disséminés. Pour rappel, ces environnements sont composés des équipements hétérogènes, formant un système distribué à grande échelle, ouvert et dynamique, dans lequel les ressources disponibles et le contexte d‟utilisation changent fréquemment. Dans ce cas, la gestion de la différence abstraite entre les besoins de haut niveau de l‟utilisateur et les fonctionnalités fournies par les équipements nécessite une approche de communication flexible et modulaire, dans laquelle l‟adaptation aux activités de l‟utilisateur résulte de la construction dynamique de l‟application à partir des ressources appropriées, et de la reconfiguration continuelle des applications pour s‟adapter aux changements de l‟environnement [62]. La mise en place d‟un tel système de communication nécessite alors de prendre en compte toutes ces caractéristiques soulignées.
Architecture Orientée Service (SOA)
La notion de service Un service est une brique logicielle autonome qui fournie une fonction bien définie [82] telle que l‟analyse d‟informations, la recherche d‟informations, etc. Un service est autonome dans la mesure où il peut se suffire à lui même, toutefois il peut être publié et rendu disponible pour être utilisable par des tiers. Ainsi des services peuvent être utilisés tels quels ou bien être composés pour mener à terme un processus complexe et atteindre un objectif précis de plus haut niveau. D‟un point de vue implémentation, un service peut être implémenté en utilisant différents paradigmes : objet, composant ou agent. Il est décrit et utilisé indépendamment de sa réalisation grâce aux mécanismes d’encapsulation et de liaison retardée. La liaison proprement dite n’est effectuée qu’au moment de l’exécution. Un service est décrit par son descripteur de service, sa spécification en quelque sorte. Le descripteur comporte des : Informations fonctionnelles : la sémantique des opérations, le comportement du service¨ (pré condition, post-condition, invariant, exception, propriétés), l’interface du service. Informations non fonctionnelles : prix, politique, spécification des mesures de la qualité¨ de service, information de déploiement, etc. Informations additionnelles : composées d’informations sur le service, non spécifiées par¨ le fournisseur du service telles que les notes, les rapports d’utilisation, etc. I.3.2.2 La notion de SOA Voici la définition de SOA donnée par le site service-architecture.com [82]: « L‟architecture orientée service est essentiellement une collection de services. Ces services communiquent entre eux à l‟aide de données simple ou d‟autres services coordonnant une certaine activité. SOA n‟est pas quelque chose de nouveau, la première architecture orientée service pour beaucoup de personnes dans le passé était DCOM ou CORBA.». Nous constatons bien que l‟approche SOA prend ses origines dans les anciennes architectures. C‟est une technologie d‟information ou bien une stratégie par laquelle les applications utilisent les services disponibles sur le réseau tel que le WWW (Word Wide Web) [52]. Cette approche vient pour combler le manque de canevas architectural permettant de guider la conception, développer, intégrer et réutiliser des applications plus facilement et plus rapidement. De plus, comme le domaine de métier d’une entreprise est en constante évolution, les systèmes de cette entreprise doivent suivre cette évolution pour répondre à de nouveaux problèmes. Une architecture orientée service permettrait d’assembler des composants et des services pour construire et fournir dynamiquement des solutions à ces problèmes. Le SOA peut être à la fois une architecture au sens propre du terme et un modèle de programmation. Chapitre I : Informatique ubiquitaire et services Web 13 I.3.2.3 Principe de SOA La figure ci-dessous illustre une vision simpliste d’une architecture orientée service et des interactions entre les différents acteurs à savoir : le fournisseur de service (service provider), l‟utilisateur de service (service user) et le registre ou l‟éditeur de service (service publisher). Un fournisseur de service développe le service et le publie dans un annuaire ou registre. L‟utilisateur de service aussi appelé consommateur ou client cherche des services qui satisfassent la tâche qui veut accomplir. Le registre de service peut être aussi couplé avec un composant qui stocke des informations additionnelles sur chaque service tel que le coût d‟utilisation du service. Plusieurs services peuvent être utilisés ensemble d‟une manière coordonnée. Le service agrégé ou composé peut être utilisé pour satisfaire des exigences plus complexes de l‟utilisateur. En fait, une façon de regarder à une SOA est comme une approche pour connecter des applications (exposées comme services) de telle sorte qu‟elles puissent communiquer entre elles et chacune tire profit de l‟autre. De plus, SOA est une manière de partager des fonctions (typiquement des fonctions métiers) de façon flexible et universelle.
|
Table des matières
Introduction générale
Chapitre I : Informatique ubiquitaire et services Web
I.1 Introduction
I.2 Caractéristiques d‟un environnement ubiquitaire
I.2.1 L‟hétérogénéité
I.2.2 Limitation des ressources
I.2.3 Limitation des réseaux
I.2.4 Une mobilité très élevée
I.2.5 Applications distribuées
I.2.6 La sensibilité au contexte
I.3 Les middlewares de communication
I.3.1 Middlewares à objets répartis
I.3.1.1 CORBA
I.3.1.2 RMI
I.3.1.3 DCOM
I.3.2 Architecture Orientée Service (SOA
I.3.2.1 La notion de service
I.3.2.2 La notion de SOA
I.3.2.3 Principe de SOA
I.3.3 Comparaison entre l„Architecture distribuée et l‟Architecture Orientée Service
I.4 Les services Web
I.4.1 Définitions et caractéristiques
I.4.2 Langages standards des services Web
I.4.3 Scénario général d‟utilisation
I.4.4 Le Web sémantique
I.4.4.1 Ontologie : définition
I.4.4.2 Langages du Web sémantique
I.5 Convergence du Web et des technologies ubiquitaires
I.5.1 Représentation de connaissances
I.5.2 Les services d‟agents
I.5.3 Architectures à agents orientées services
I.6 Synthèse
Chapitre II : Contexte et sensibilité au contexte
II.1 Introduction
II.2 La notion du contexte
II.2.1 Définition du contexte
II.2.2 Classification du contexte
II.2.3 Caractéristiques des informations du contexte
II.2.4 Acquisition des informations du contexte
II.2.5 Délivrance du contexte à l‟application
II.2.6 Modélisation du contexte
II.3 La sensibilité au contexte
II.3.1 Définition de la sensibilité au contexte
II.3.2 Mécanismes d‟adaptation
II.3.3 Les services sensibles au contexte
II.3.4 Les intergiciels sensibles au contexte
II.4 Synthèse
Chapitre III : Vers la composition de services
III.1 Introduction
III.2 Concepts et définitions
III.2.1 Composition de services
III.2.2 Orchestration
III.2.3 Chorégraphie
III.2.4 Définition formelle d‟un problème de composition de services
III.2.5 Synthèse des approches de matching
III.3 Domaines d‟application de la composition de services
III.3.1 Les services Web
III.3.2 Les applications B2B
III.3.3 Les applications de Grid
III.3.4 L‟informatique ubiquitaire
III.3.5 Quelques caractéristiques
III.3.6 Quelques scénarios illustratifs de la composition de services
III.3.6.1 Recherche d‟un restaurant préféré
III.3.6.2 Service d‟impression à partir d‟un mobile
III.4 Architecture et méthodes de composition de services
III.4.1 Architecture générale d‟un modèle de composition de services
III.4.2 Méthodes de composition de services
III.4.2.1 Composition de services à base du workflow
III.4.2.2 Composition de services à base d‟ IA
III.4.3 Prise en compte du contexte dans la composition de services
III.5 Synthèse
Chapitre IV : Construction automatique d’une composition de services
IV.1 Introduction
IV.2 Modélisation du contexte
IV.2.1 Approche basée ontologie pour représenter les classes du contexte
IV.2.2 Exemple d‟instanciation
IV.2.3 Outils pour représenter l‟ontologie du contexte
IV.3 Modélisation d‟un service sensible au contexte
IV.3.1 Service concret (concret service
IV.3.2 Les règles de contexte (Rc)
IV.3.3 Estimation du QoS d‟un service concret
IV.3.4 Exemples de services concrets
IV.3.5 Service abstrait (abstract service
IV.3.6 Exemples de services abstraits
IV.4 Architecture du système de composition de services
IV.5 Approche pour la composition des services
IV.5.1 Hypothèses et définitions
IV.5.2 Principe de l‟approche proposée
IV.5.3 Un algorithme pour la composition de services
IV.5.4 Principe de l‟algorithme
IV.5.5 Déroulement de l‟algorithme sur un exemple
Chapitre V : Approche basée MDP pour la composition de services
V.1 Introduction
V.2 Processus de décision markoviens (MDP
V.2.1 Les composantes d‟un MDP
V.2.1.1 Définition d‟un processus de décision markovien (MDP
V.2.1.2 L’ensemble des actions
V.2.1.3 La fonction de transition
V.2.1.4 La fonction de récompense
V.2.2 La résolution d‟un MDP
V.2.2.1 La notion de politique
V.2.2.2 L’évaluation d’une politique
V.2.2.3 Le principe d’optimalité de Bellman
V.2.2.4 L’algorithme Value Iteration
V.3 Modélisation de la composition de services par un MDP
V.3.1 Définition des éléments du MDP
V.3.2 Représentation graphique du MDP
V.4 Apprentissage Bayésien
V.5 Algorithme de sélection de services basé MDP
V.5.1 Présentation de l‟algorithme
V.5.2 Fonctionnement des modules de composition et de sélection de services
V.5.3 Exemple d‟application de l‟algorithme
Chapitre VI : Approche basée agents pour la composition de services
VI.1 Introduction
VI.2 La notion d‟agent
VI.2.1 Définition
VI.2.2 Caractéristiques
VI.3 Système Multi-agents
VI.3.1 Définition
VI.3.2 Exemple
VI.3.3 Interaction dans les SMA
VI.3.4 Communication dans les SMA
VI.3.5 Organisation des interactions dans les SMA
VI.4 Les agents dans le cadre de notre travail
VI.4.1 Définition des agents qui participent à la composition
VI.4.2 Organisation de la communication inter agents de composition
VI.4.3 Algorithmes de fonctionnement des agents de composition
VI.4.4 Exemple d‟application
Chapitre VII : Implémentation et validation
VII.1 Introduction
VII.2 Services pour l‟assistance et la surveillance d‟une personne dépendante
VII.2.1 Système de capture
VII.2.2 Services sensibles au contexte
VII.2.3 Système de composition de services
VII.2.4 Application des approches de composition
VII.2.4.1 Plan de composition
VII.2.4.2 Approche MDP
VII.2.4.3 Approche agents
VII.3 Implémentation et testes
Conclusion et perspectives
Bibliographie
Télécharger le rapport complet
