Universite joseph fourier – grenoble I




НазваниеUniversite joseph fourier – grenoble I
страница1/44
Дата29.12.2012
Размер1.03 Mb.
ТипДокументы
  1   2   3   4   5   6   7   8   9   ...   44


UNIVERSITE JOSEPH FOURIER – GRENOBLE I


THESE

Pour obtenir le grade de

DOCTEUR de l’Université JOSEPH FOURIER

Discipline : INFORMATIQUE

ECOLE DOCTORALE Mathématiques, Sciences et Technologies de l’Information, Informatique


Présentée et soutenue publiquement par

André BOTTARO

Le 12 décembre 2008


Home SOA : Composition contextuelle de services dans les réseaux d’équipements pervasifs

Directeur de thèse :

Philippe LALANDA

JURY

Président

Andrzej DUDA, Professeur à l’Institut National Polytechnique de Grenoble

Rapporteurs

Valérie ISSARNY, Directeur de Recherche à l'INRIA
Lionel SEINTURIER, Professeur à l'Université de Lille

Examinateurs

Didier PELLEGRIN, Chef de Projet, Schneider Electric
Vincent OLIVE, Responsable d'unité, Orange Labs

Encadrant

Philippe LALANDA, Professeur à l’Université Joseph Fourier

Thèse préparée au sein des Orange Labs et du Laboratoire d’Informatique de Grenoble

Remerciements

Je remercie les membres du jury, en particulier Lionel Seinturier et Valérie Issarny qui ont évalué mon mémoire avec la profondeur de leur expérience dans leurs rapports respectifs. Je remercie également Andrzej Duda d'avoir accepté de présider ce jury, ainsi que Didier Pellegrin et Vincent Olive en tant qu'examinateurs de cette thèse.

Je n'oublierai pas la pédagogie précieuse que m'a dispensé Philippe Lalanda, mon directeur de thèse à l'Université Joseph Fourier et mon mentor depuis mon premier stage à Schneider Electric jusqu'à l'aboutissement de cette thèse à France Télécom.

Merci à Richard S. Hall pour s'être proposé comme second encadrant en début de thèse et avoir mis mes travaux sur des rails techniques concrets durant l'année 2006.

Je reconnais la présence continue de Vincent Olive, mon responsable d'unité à France Télécom. Vincent m'a proposé les projets et la liberté nécessaires à mon épanouissement.

Ce travail s'est déroulé au sein du laboratoire intergiciel des Orange Labs du Groupe France Telecom et de l'équipe Adèle du Laboratoire d'Informatique de Grenoble. Je tiens à remercier généralement les membres de ces deux équipes pour le cadre de travail stimulant offert et à remercier quelques personnes particulières : Merci à Didier Donsez qui m'a poussé dans une candidature de thèse le premier, à Alexandre Avenel, François-Gaël Ottogalli et Roland Airiau qui m'ont fourni un cadre de projets propice à la communication de nouvelles techniques au sein des Orange Labs, à Johann Bourcier, Clément Escoffier, Mourad Alia qui ont élaboré avec moi des prototypes pour des articles à des conférences de haut niveau, à Aimé Vareille avec qui j'ai partagé mon bureau et son ouverture à des domaines vastes touchant peu ou prou le métier de France Telecom, à Serge Martin, Régine Basset, Marc Lacoste pour la représentation de nos travaux dans des projets collaboratifs.

La compréhension de mes motivations par Kathleen Milsted et Alain Chemarin, responsables successifs du laboratoire Orange, a été essentielle pour la menée à bien de ce travail de longue haleine. Jacky Estublier, directeur de recherche de l'équipe Adèle, a aussi saisi l'adéquation de ma motivation et des objectifs de cette thèse en parallèle.

Une section particulière à Anne Gérodolle et Levent Gürgen avec qui j'ai travaillé en binôme durant de longues périodes. Sans les échanges techniques continus avec Anne et l'interchangeabilité atteinte dans nos rôles d'encadrant, le cadriciel Home SOA n'aurait pu devenir ce recueil d'expériences et cette base de code aisément partageable. Sans la motivation et la contribution complémentaire de Levent au Comité UPnP Device Management, France Télécom n'aurait pu paraître aussi présent auprès de nos partenaires.

La taille et la qualité des prototypes réalisés sont le fruit d'une équipe de développement rassemblée au gré des opportunités administratives, financières et humaines saisies au cours de ces années. Mes vifs remerciements aux concepteurs-développeurs ayant contribué durant une période de prestation, de stage ou d'apprentissage à la réalisation du cadriciel Home SOA : Gregory Bonnardel, Fatoumata Camara, Maxime Vincent, Vincent Moreau, Fabrice Jaumes, Teva Paoletti, Nicolas Peru, Xavier Goblet, Eric Simon, Stéphane Seyvoz, Marius Tankeu, Judex MBoulou, Nicolas Chabanoles et Julien Ravoire.

J'adresse enfin une pensée chaleureuse aux membres de ma famille, mes parents, mes frères et mes beaux-parents, ainsi qu'à mes amis qui m'ont toujours soutenu.

Une pensée émue à ma femme Sophie qui m'a accompagné courageusement dans cette thèse. Merci de partager ma vie et d'être attentive à son équilibre. Ces années de thèse ont été par ailleurs les premières années de Lison et Anatole, sources de bonheur et de fierté.

Résumé

Les équipements électroniques envahissent progressivement l'univers quotidien. D’aucuns souhaiteraient que ces équipements puissent intelligemment réagir à l’activité de l’utilisateur afin de l’assister dans ces activités de tous les jours. Le domaine de l’Informatique Pervasive adresse la vision de ce monde naturellement numérique assistant les individus sans être intrusif.

Face aux défis de l'Informatique Pervasive dans les réseaux locaux, notamment la distribution, l'hétérogénéité et la dynamique des équipements, cette thèse répond par une ligne de conduite et l'approche logicielle Home SOA. Cette ligne de conduite distingue les situations où les solutions protocolaires sont pertinentes et ramène les autres situations à des problèmes de génie logiciel. Parmi les solutions protocolaires, la proposition d'une interface uniforme de gestion de cycle de vie logiciel dans le Comité de Travail UPnP Device Management est une des contributions importantes.

Le Home SOA est l'association de technologies de développement modulaire et d'un ensemble de patrons de conception orientés objets. Au-delà de l'orientation objet, le Home SOA exploite les modèles récents de composants à services et le concept de plateforme de services. Les pilotes orientés service masquent les aspects distribués tout en réifiant la dynamique des entités pervasives sur la plateforme. Les pilotes raffinés adaptent les objets mandataires dans des interfaces à la sémantique du domaine d'application visé. La contextualisation des services de la plateforme alliée à l'automatisation de la sélection de service achève de simplifier le développement d'applications. Le cadriciel est implémenté au-dessus de la plateforme OSGi et est validé par la réalisation d'applications conscientes du contexte et mixant des domaines d'applications distincts dans le réseau domestique.

Abstract

Home SOA: Contextual Service Composition In Pervasive Device Networks.

Pervasive Computing aims at filling our environment with communication devices in order to assist us in our daily activities without our explicit intervention. Indeed, in the near future, human beings will engage interactions with a number of smart devices, faded in into the environment, without being aware of their location or their precise nature and without going through complex, specific interfaces.

Addressing Pervasive Computing challenges in local networks such as device distribution, heterogeneity and dynamicity, this thesis exposes a conduct line and a software approach named Home SOA. This conduct line distinguishes the situations where protocol-based solutions are relevant and turn the other situations into Software Engineering problems. Among the protocol-based solutions, the proposition of a uniform protocol interface for software lifecycle management in the UPnP Device Management Working Committee is one of the major contributions.

The Home SOA promotes a set of object-oriented design patterns above modular software platform technologies. Beyond the object orientation, the Home SOA makes benefit of recent service component models and the service platform concept. Distribution is hidden by service-oriented drivers while network dynamicity is locally reified on the platform. Distributed objects are turned by refined drivers into interfaces semantically close to the targeted application domain. Service contextualization and service selection automation reach the objective of simplifying the development or pervasive applications. The proposed framework is implemented on the OSGi platform and is validated by the realization of context-aware applications mixing distinct application domains in the Home network.

Table des Matières

Chapitre I. Introduction 17

1 Contexte 17

2 Problématique 18

3 Contribution 19

4 Cadre de travail 20

5 Organisation du document 21

Chapitre II. Informatique Pervasive et Orientation Service 23

1 Le Génie Logiciel au secours de l'Informatique Pervasive 23

2 Intergiciels distribués orientés services 28

request-response : ce mode opératoire est le plus commun. Le client envoie un message de requête, le serveur répond par un message de réponse. Les 2 types de messages sont donc définis dans cette opération. 32

one-way : ce mode opératoire dérive du mode request-response. La différence est qu'aucun message de réponse n'est attendu après réception et traitement de la requête par le serveur. 32

solicit-response : ce mode opératoire est un mode inverse au mode request-response. Le serveur prend ici l'initiative d'envoyer un message au client auquel celui-ci répond par un message. Ce mode nécessite la souscription préalable du client sur les événements adéquats du serveur (cf. section 2.6 pour les mécanismes de souscription). Il est disponible par exemple avec WSDL. L'ordre d'écriture des messages d'entrée et de retour dans la définition d'une opération indique implicitement le mode opératoire choisi. Dans le mode solicit-response, le message de retour – output – est écrit avant le message d'entrée – input (cf. Figure 3). 32

notification : ce mode dérive du mode solicit-response. La différence est qu'aucun message de réponse n'est attendu par le serveur après notification du client. Il nécessite de même la souscription préalable du client sur les événements adéquats du serveur (cf. section 2.6 pour les mécanismes de souscription). Ce mode de notification est répandu dans la plupart des intergiciels de communication réparti au contraire du mode solicit-response. 32

3 Gestion des aspects distribués dans une application orientée service 35

4 Gestion de l'hétérogénéité des équipements 48

5 Sélection, substitution et continuité de service 61

6 Synthèse 73

Chapitre III. Le réseau domestique, environnement pervasif par excellence 75

1 Contrôle d'équipements 77

2 Communication interpersonnelle 88

3 Administration d'équipements 94

des paquetages de déploiement : téléchargement, suppression, installation. 99

des unités de déploiement : installation, désinstallation, mise à jour, etc. 99

des unités d'exécution : démarrer, stopper, mettre en pause, reprendre. 99

des paquetages de déploiement : téléchargé, supprimé. 99

des unités de déploiement : installé, désinstallé, résolu. 99

des unités d'exécution : démarré, arrêté. Dans certains modèles particuliers, un état de pause peut être défini. 99

Des propriétés génériques optionnelles décrivant la provenance du bundle : Bundle-Category, Bundle-ContactAddress, Bundle-Copyright, Bundle-Description, Bundle-DocURL, Bundle-Localization, Bundle-Name, Bundle-Vendor, Bundle-Version. 104

Des propriétés spécifiques à la plateforme OSGi utiles au déploiement et à l'exécution du bundle : Bundle-ActivationPolicy, Bundle-Activator, Bundle-Classpath, Bundle-ManifestVersion, Bundle-NativeCode, Bundle-RequiredExecutionEnvironment, Bundle-SymbolicName, Bundle-UpdateLocation, DynamicImport-Package, Export-Package, Export-Service, Fragment-Host, Import-Package, Import-Service, Require-Bundle. 105

Des propriétés génériques optionnelles décrivant la provenance de la MIDlet Suite : MIDlet-Name, MIDlet-Version, MIDlet-Vendor, MIDlet-Jar-URL, MIDlet-Jar-Size, MIDlet-Description, MIDlet-Icon, MIDlet-Info-URL, MIDlet-Data-Size. 106

Des propriétés spécifiques à la plateforme Java MIDP utiles au déploiement de la MIDlet Suite et à l'exécution de ses MIDlets : MicroEdition-Profile, MicroEdition-Configuration, MIDlet-n, MIDlet-Install-Notify, MIDlet-Delete-Notify, MIDlet-Permissions, MIDlet-Permissions-Opt, MIDlet-Push-n, MIDlet-specific attributes, MIDlet-Jar-RSA-SHA1 106

des unités de déploiement : Install, Remove, Update. 106

des unités d'exécution : StartApp, StopApp. Les 2 premières versions de MIDP ajoutaient l'opération de mise en pause (PauseApp). Cette opération est rendue obsolète dans la 3ème version. 107

des unités de déploiement : Installed, Removed. 107

des unités d'exécution : Destroyed, Active. L'état "Paused" est obsolète depuis la version 3. Les MIDlets apparaissent avec l'état "Destroyed" lorsque la MIDlet Suite associée est installée (cf. partie droite de la Figure 35). 107

Des propriétés génériques optionnelles décrivant la provenance du package : Package, Version, Section, Installed-Size, Maintainer, Description. 107

Des propriétés spécifiques à la plateforme Debian et utiles au déploiement : Priority, Architecture, Essential, Depends, Pre-Depends, Recommends, Suggests, Conflicts, Replaces, Provides. 108

des unités de déploiement : Install, Remove, Upgrade. 108

des unités d'exécution : Start, Stop. Ce sont les opérations les plus communément supportées par les scripts RC et autres processus init. [RoF07] montre des listes d'opérations différentes disponibles sur quelques distributions en supplément de start et stop (e.g., restart, respawn, init, kill). 108

des unités de déploiement : Installed, Removed, Resolved. Comme les mécanismes de résolution de dépendances existent sur les plateformes Debian et RedHat, l'état "Resolved" pourrait être un état pour les packages de la plateforme. De nombreux états intermédiaires existent selon les distributions mais ne sont pas représentés ici. 108

des unités d'exécution : Inactive, Active. Les scripts RC peuvent être defines alors que les packages utiles ne sont pas encore disponibles. Toutefois, il ne peuvent être activés que lorsque ces packages sont présents. 108

Des propriétés génériques optionnelles décrivant la provenance de l'assembly : Culture, Flags, Version, Company, Copyright, FileVersion, InformationalVersion, Product, Trademark, DefaultAlias, Description, Title. 109

Des propriétés spécifiques à la plateforme .NET utiles au déploiement et à l'exécution des assemblies : Name, FileList, TypeReference, ReferencedAssemblies, EntryPoint, Configuration, DelaySign, KeyFile, KeyName. 109

Des propriétés génériques optionnelles décrivant la provenance du package : name, description, version, PkgType. 110

Des propriétés spécifiques à la gestion SCOMO et utiles au déploiement : PkgID (DP), PkgURL, ID (DC), data. 110

des paquetages de déploiement (cf. Figure 38) : Download, DownloadInstall, DownloadInstallInactive, Install, InstallInactive, Remove. Des actions composées sont spécifiées : DownloadInstall, DownloadInstallInactive. La raison pourrait être a priori la possibilité de s'adapter au mieux aux différentes opérations spécifiées dans les différentes plateformes logicielles existantes. Elle pourrait être aussi de rendre les opérations plus rapides et assurer leur cohérence en les groupant. La citation suivante, qui indique qu'une action composée est effectuée par réalisation des deux actions correspondantes, semble en faveur de la seconde raison : "When a Composed Primitive is executed, two state transitions happen in the Device. For example if DownloadInstall is executed, a Deployment Component transits from Not Downloaded State to Delivered State after successful download procedure. It transits to Active State after successful installation procedure. If the latter processing fails it remains in previous state and the second state transition does not happen." 111

des unités de déploiement (cf. Figure 39) : Activate, Deactivate, Remove. Les unités de déploiement sont explicitement activables et dés-activables. L'état "Inactive" correspond à un état où aucune application ne peut utiliser l'unité. L'activation permet l'accessibilité des applications dépendantes à l'utilisateur. Cette activation semble correspondre à la demande de résolution des dépendances de l'unité. Les applications n'apparaissent à l'utilisateur que lorsque tous les DUs correspondants sont actifs. 111

des paquetages de déploiement (cf. Figure 38) : Not Downloaded, Delivered, Installed, Removed. 111

des unités de déploiement (cf. Figure 39) : Inactive, Active, Removed. 111

4 Synthèse 112

Chapitre IV. Problématique du développement d'applications pervasives 115

1 Les défis de l'Informatique Pervasive 115

2 Exigences techniques 117

3 Contraintes 119

4 Limites des réponses actuelles 120

5 Ce que propose cette thèse 122

Chapitre V. Home SOA : techniques de composition de services pervasifs 123

1 Une architecture plateforme-centrique 124

2 Plateforme de services et patrons associés 125

Plusieurs objets doivent être notifiés des changements d'une même donnée au cours du temps. 131

Une liaison entre deux objets nécessite que les appels soient initiés parfois par l'un et parfois par l'autre des objets. Si les deux objets définissent un lien d'association vers l'autre, les deux objets sont alors fortement couplés. 131

3 Distribution et pilotes orientés services 134

4 Hétérogénéité et pilotes raffinés 139

5 Contextualisation de la sélection de services 146

6 UPnP Device Management : une réponse protocolaire 150

des paquetages de déploiement : Download(), Remove(), SetUp(). 153

des unités de déploiement : Install(), Uninstall(), Update(). 153

des unités d'exécution : Start(), Stop(). 153

des paquetages de déploiement : 2 états stables : Downloaded, Removed; 2 états transitoires : Downloading, Removing. 153

des unités de déploiement : 3 états stables : Installed, Resolved, Uninstalled; 2 états transitoires : Installing, Uninstalling. Les plateformes qui permettent le diagnostique de résolution de dépendances indiquent la satisfaction des dépendances de chaque unité par l'état Resolved. 153

des unités d'exécution : 2 états stables : Inactive, Active; 2 états transitoires : Starting, Stopping. 153

7 Synthèse 156

Chapitre VI. Expérimentations 159

1 Composition de services sur la plateforme OSGi 159

0..1 – Optionelle et singulière. 162

1..1 – Obligatoire et singulière. 162

0..n – Optionelle et multiple. 162

1..n – Obligatoire et multiple. 162

2 Extended Service Binder 169

3 DPWS Base Driver : un pilote orienté service 172

4 Pilotes raffinés pour le controle d'équipements 177

5 Communication interpersonnelle enrichie 184

6 UPnP-IGRS : coexistence et interopérabilité 188

7 Spécification UPnP Device Management 189

8 Synthèse 195

Chapitre VII. Validation 197

1 Tests du DPWS Base Driver 197

2 Comparaisons des pilotes du cadriciel Home SOA 199

UPnP Base Driver : pilote issu du projet Apache felix et amélioré dans les travaux de cette thèse pour la compatibilité à des équipements existants. 199

SmartUPnP Refined Driver : pilote raffiné représentant les objets UPnPDevice issus du pilote précédent dans les interfaces SmartDevice. 199

Bonjour Base Driver : pilote orienté service reprenant la base de code open source jmdns (jmdns.sourceforge.net) et l'emballant dans un bundle OSGi en suivant les patrons de conception énuméré dans ce mémoire. 199

DMAP (ou iTunes) Refined Driver : pilote raffiné représentant les objets BonjourDevice dans les interfaces associées à la classe DMAPServer. Ce pilote n'a pas été cité dans les chapitres précédents par simplicité. Bonjour n'est qu'un ensemble protocolaire restreint aux couches d'adressage, de découverte et de nommage. Apple iTunes utilise Bonjour et définit le protocole DMAP, pour le contrôle et la notification spécifique à iTunes. 199

SmartBonjour Refined Driver : pilote raffiné adaptant les objets BonjourDevice et DMAPServer dans les interfaces SmartDevice. 199

DPWS Base Driver : pilote orienté service développé durant ces travaux de thèse et délivré en open source au projet Amigo 199

SmartDPWS Refined Driver : pilote raffiné représentant les objets DPWSDevice issu du pilote précédent dans les interfaces SmartDevice. 200

3 Composition distribuée de services 202

4 Gestion de l'hétérogénéité 202

5 Composition contextuelle 205

6 Pertinence du Home SOA pour l'opérateur de télécommunication 206

7 Synthèse 206

Chapitre VIII. Conclusion 209

1 Les défis de l'Informatique Pervasive des reseaux locaux 209

2 Les réponses de cette these 210

3 Les enseignements et les limites des propositions 211

4 Les perspectives de ces travaux 213

Chapitre IX. Bibliographie 215

1 Publications 215

2 References 217

Table des Figures

Figure 1 Architecture Orientée Service 25

Figure 2 Architecture Orientée Services avec utilisation de moyens multicast 30

Figure 3 Exemple d'opération solicit-response décrite dans le langage WSDL 32

Figure 4 Appel de méthode distante [KrS05] 39

Figure 5 Le patron de conception export-bind [Kra08] 40

Figure 6 Systèmes distribué traditionnel et systèmes de code mobile [FPV98] 41

Figure 7 Système d'appel de procédure distant [BiN84] 44

Figure 8 Partitionnement automatique de programmes Java avec J-Orchestra 45

Figure 9 Domaines d'applications et protocoles hétérogènes 49

Figure 10 Terminal de télécommunication éclaté sur plusieurs équipements 50

Figure 11 Communication interpersonnelle entre deux réseaux domestiques 55

Figure 12 Passerelle et adaptation logicielle entre un protocole d'administration et un protocole de contrôle d'équipements [NPD07] 56

Figure 13 Modèle de données des composants de déploiement SCOMO 59

Figure 14 Service d'adaptation et répertoire d'Adapteurs [Vay01] 60

Figure 15 Une radio qui suit l'utilisateur lorsqu'il change de pièce 64

Figure 16 Architecture d’une radio qui suit l’utilisateur dans la maison 64

Figure 17 Gestion de transfert automatique d'état dans le système de [FEL07] 72

Figure 18 Le réseau domestique vu par le projet IST Amigo 76

Figure 19 Points de contrôle, équipements et services UPnP 82

Figure 20 IGRS AV [IGRS06], une architecture similaire à celle d'UPnP AV 84

Figure 21 Pile protocolaire DPWS 85

Figure 22 Salutations managers, transport managers, services and clients [Ric00] 87

Figure 23 Principes et architecture d'une session SIP 90

Figure 24 Premier mode d'utilisation de la méthode REFER 91

Figure 25 Deuxième mode d'utilisation de la méthode REFER 91

Figure 26 Mobilité de session par utilisation du mécanisme 3PCC 92

Figure 27 Interaction avec un transcodeur contrôlable par le protocole SIP 93

Figure 28 Agencement des protocoles utilisés par le protocole H.323 93

Figure 29 Extrait du modèle de données DMTF CIM 95

Figure 30 Réponse conforme à un format générique à une requête de type Get 97

Figure 31 Réponse au format original de l'équipement à la même requête 97

Figure 32 La demande de création d'un objet au format DIDL-Lite 98

Figure 33 Architecture d'administration de bout en bout du Broadband Forum – www.broadband-forum.org 100

Figure 34 Cycle de vie du bundle OSGi 105

Figure 35 Cycles de vie d'une MIDlet Suite et de ses MIDlets 106

Figure 36 Vision simple des diagrammes d'états des entités logicielles Linux 108

Figure 37 Diagramme d'état d'un assembly .NET 110

Figure 38 Diagramme d'état du Delivery Package SCOMO 111

Figure 39 Diagramme d'état du Deployment Component (execution unit) SCOMO 112

Figure 40 Une vision plateforme-centrique des réseaux pervasifs 125

Figure 41 Patron de conception "Plateforme de service" 129

Figure 42 Automatisation de la composition de services 131

Figure 43 Patron de conception "Observateur" 132

Figure 44 Patron de conception "Tableau Blanc" 133

Figure 45 Patron de conception "Publish-subscribe orienté service" 134

Figure 46 Patron de conception export-bind et découverte de service [Kra08] 136

Figure 47 Pilote orienté service pour l'import 137

Figure 48 Pilote orienté service pour l'export 138

Figure 49 Chaine de pilotes : "Discovery Base Driver" et "Specific Driver" 139

Figure 50 Patron de conception Adapteur 140

Figure 51 Patron de conception Pilote Raffiné 141

Figure 52 Médiation technique à partir d'équipements aux protocoles et aux domaines d'applications différents 142

Figure 53 Pont protocolaire entre deux plateformes intelligentes 143

Figure 54 Action Play dans le protocole de description d'UPnP 144

Figure 55 Appel de l'action Play dans l'API Java "UPnP Device Service" 144

Figure 56 Appel de l'action Play dans l'API générée par l'UPnP Device Generator 144

Figure 57 Génération d'adaptateurs sémantiques à la volée 145

Figure 58 Contextualisation des fournisseurs de services 147

Figure 59 Contextualisation des requêtes déclarées de services 148

Figure 60 Cycle de vie des et classement de services contextuel 150

Figure 61 Administration de bout en bout et UPnP Device Management 151

Figure 62 Diagrammes d'état des paquetages et des unités de déploiement 153

Figure 63 Diagramme d'état des unités d'exécution 154

Figure 64 Patron de conception SOA sur la plateforme OSGi 160

Figure 65 Bundle OSGi et composants à service 162

Figure 66 Cycle de vie d'un composant selon "Declarative Services" 163

Figure 67 Déclaration de dépendances de service 164

Figure 68 Recherche du meilleur service de restitution de messagerie ambiante 165

Figure 69 Boucle de rétroaction pour la reconfiguration de chaque composant 165

Figure 70 Dépendance de service contextualisée par un gestionnaire iPOJO 166

Figure 71 Extended Service Binder SLP-RMI 170

Figure 72 Vision schématique du DPWS Base Driver 172

Figure 73 Architecture logicielle du DPWS Base Driver 174

Figure 74 Interfaces de contrôle des services DPWS 176

Figure 75 Architecture logicielle de l'application de contrôle générique 177

Figure 76 API Smart Device 178

Figure 77 Architecture du "home cinéma" réactif 180

Figure 78 Génération de code d'interfaces Java à partir de descriptions UPnP 181

Figure 79 Intergiciel pour communication interpersonnelle enrichie 184

Figure 80 Architecture pour la communication interpersonnelle enrichie 185

Figure 81 Pilote orienté service SIP (SIP Base Driver) 186

Figure 82 Interactions entre équipements SIP, UPnP et transcodeur 187

Figure 83 Architecture pour le contrôle UPnP DM de la plateforme OSGi 193

Figure 84 Architecture pour le contrôle UPnP DM de la plateforme .NET 194

Figure 85 Architecture pour le contrôle UPnP DM de la plateforme Linux Ubuntu 195

Figure 86 Tests de performance du DPWS Base Driver 197

Figure 87 Moyennes olympiques des temps d'exécution des tests 198



Table des Tableaux

Tableau 1 Comparaison des différentes spécifications protocolaires Plug-n-Play 77

Tableau 2 Couches techniques des standards répandus dans le réseau domestique 78

Tableau 3 Pile protocolaire UPnP 81

Tableau 4 L'objet .LAN.IPPingDiagnostics. de la spécification TR-106 du Broadband Forum 96

Tableau 5 Comparaison des technologies de plateformes d'exécution 99

Tableau 6 Equivalence entre structures UPnP et structures Java/OSGi 181

Tableau 7 Equivalence entre types UPnP et types Java 182

Tableau 8 Equivalence entre actions UPnP et méthodes Java 182

Tableau 9 Equivalence entre mécanismes de notification UPnP et notification Java/OSGi 182

Tableau 10 Temps d'exécution moyens dans les deux couches de pilotes UPnP 200

Tableau 11 Temps d'exécution moyens dans les deux couches de pilotes Apple 201

Tableau 12 Temps d'exécution moyens dans les deux couches de pilotes DPWS 201


  1   2   3   4   5   6   7   8   9   ...   44

Похожие:

Universite joseph fourier – grenoble I iconПрограмма конференции
...
Universite joseph fourier – grenoble I iconSession 2: Fourier Transform Infrared (ft ir) & Fluorescence Spectroscopy

Universite joseph fourier – grenoble I iconApplications of Vector Analysis and Fourier Series and Its Transforms

Universite joseph fourier – grenoble I iconLig laboratoire Informatique de Grenoble

Universite joseph fourier – grenoble I iconLig laboratoire Informatique de Grenoble

Universite joseph fourier – grenoble I iconUniversité catholique de Louvain

Universite joseph fourier – grenoble I iconUniversité du Québec à Rimouski

Universite joseph fourier – grenoble I iconProf. Uri Bar-Joseph

Universite joseph fourier – grenoble I iconST. joseph’s college (autonomous) bangalore

Universite joseph fourier – grenoble I icon© 2006-2007 by Joseph P. Larkin

Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница