Notifications, Communication, Traitement et Configuration DJBEL – 04/12/2010NSY208 CNAM 1

Plan Notifications et synchronisations Communication réseau Traitement des requêtes Configuration 2

3

Notifications / Observateur Problème –Comment permettre à des systèmes, nombreux et hétérogène, de se coordonner simplement ? Forces –Il faut que le moyen de coordination soit flexible –L’événement de coordination doit être paramétrable –Chaque système doit réagir qu’1 seule fois à 1 événement –On ne doit pas introduire de couplage fort entre les systèmes 4

Notifications / Observateur Solution –L’observateur permet à un ensemble d’objets (Observateurs) de se mettre à jour quand l’état d’un autre (Sujet) a évolué –Mécanisme d’enregistrement/propagation 5

Notifications / Observateur 6

Notifications / Publisher-Subscriber Problème –Comment permettre à des systèmes de se coordonner de manière fiable, anonyme et asynchrone ? Forces –Peu ou pas d’infrastructure réseau –Mobilité est dimension importante –Offrir le choix pour que les systèmes puissent être notifiés pour les événements qu’ils souhaitent –Un canal fiable, redondance 7

Notifications / Publisher-Subscriber Solution –Publisher-Subscriber est une spécialisation du modèle observateur –Les messages sont d’abord dirigés vers un canal avant d’être délivrés –2 stratégies de mise en oeuvre par sujet (newsgroup) par contrainte 8

Notifications / Publisher-Subscriber 9

Réseau / Proxy Problème –Comment créer des compositions avec des systèmes distribuées ? Forces –Transparence vis-à-vis de l’infrastructure et de la distribution spatiale –L’invocation des services doit être la même –Du fait de la mobilité, la composition peut se faire de manière dynamique 10

Réseau / Proxy Solution –Le modèle proxy a pour but de fournir localement un objet de substitution pour un objet réel et distant –L’objet de substitution reçoit les requêtes et les fait suivre vers l’objet réel –Le substitut et l’objet concret implémente la même interface –# types de Proxy Proxy dynamique, Cache proxy, Proxy distant, … 11

Réseau / Proxy 12

Réseau / Requeteur Problème –Comment découpler l’ouverture d’1 connexion réseau de la transmission et de passage de paramètres ? Forces –A préalable de l’ouverture de connexion il faut déterminer le protocole à utiliser –Il faut identifier les erreurs éventuelles –Le masquage de la mécanique réseau est nécessaire 13

Réseau / Requeteur Solution –Le modèle requeteur centralise toutes les opérations nécessaires à l’ouverture et la fermeture réseau. 14

Réseau / Stratégie Problème –Comment permettre à une requête d’utiliser tel ou tel protocole de manière transparente ? Forces –L’ouverture et la fermeture de connexions sont spécifiques à chaque protocole ? –La liste des protocoles supportés par le système peut varier et doit être définie dans un fichier externe –La sélection du protocole dépend du contexte –Le support d’un nouveau protocole doit se faire sans difficultés 15

Réseau / Stratégie Solution –Le modèle stratégie permet de définir une famille d’algorithmes, de les encapsuler et de les rendre interchangeables –Il est possible d’utiliser un algorithme sans pour autant connaître son fonctionnement interne 16

Réseau / Stratégie 17

Réseau / Marshaller Problème –Comment convertir une donnée du type de simple (comme un entier) ou complexe (comme un objet) en un flux binaire ? Forces –La sérialisation doit se faire par type de donnée. –Il faut conserver l’identité d’un objet sérialisé même après son transport d’un nœud à un autre. –Si les plateformes ou les langages de programmation utilisés sont différents entre le nœud de départ et le nœud de destination, cela peut engendre une incompatibilité binaire ou une incompatibilité entre les types 18

Réseau / Marshaller Solution –Le modèle proxy a pour but de fournir localement un objet de substitution pour un objet réel et distant –L’objet de substitution reçoit les requêtes et les fait suivre vers l’objet réel –Le substitut er l’objet concret implémente la même interface –# types de Proxy Proxy dynamique, Cache proxy, Proxy distant, … 19

Réseau / Marshaller 20 Toute communication entre deux SE de l’intergiciel via le réseau se fait par échange de messages. Pour le protocole HTTP, il suffit il suffit juste d’un navigateur Internet, les requête sont déballé côté serveur à l’aide d’un empaqueteur HTTP. Pour le protocole Bluetooth, les messages échangés sont au format XML, l’empaqueteur XML est utilisé. A chaque fois que le Requêteur traite une demande client, il utilise l’Emballeur adéquat.

Réseau / Réseau / Server Request Handler Problème –Comment attendre, réceptionner et déballer la requête ou le flux reçu ? Forces –Les demandes de services arrivent sous une forme quelconque. –Le SE n’a pas à se préoccuper des opérations inhérentes à la communication réseau : ouverture de canal, attente, réception et analyse de la requête, déballage des paramètres... –Les connexions réseau sont des ressources coûteuses, il faut donc optimiser leur usage 21

Réseau / Réseau / Server Request Handler Solution –Le Récepteur de Requêtes (Server Request Handler) [64 p 45] traite de toute la problématique liée à la communication réseau côté serveur. –Il reçoit les messages qui arrivent par le réseau et les transmet aux entités qui vont les traiter. –Il s’occupe de la gestion des connexions (ouverture, fermeture…) et des processus serveur (démarrer, stopper,…). 22

Réseau / Réseau / Server Request Handler 23 Nous utilisons le serveur web Brazil de Sun pour la réception de requête http. Nous l’avons adapté pour qu’il puisse supporter des requêtes Bluetooth. La figure ci-dessus détaille l’architecture interne de ce serveur et montre comment les requêtes sont réceptionnées. Le serveur accepte les demandes client au format http ou Bluetooth. Un processus Server est démarré.. A chaque demande qui arrive, le serveur crée une instance de Connection qu’il maintient durant le traitement de la demande

Traitements / Traitements / Invocateur Problème –Une fois le contenu de la requête analysé, comment déterminer le dispatcher qui sera en mesure d’invoquer l’exécution du service ? Forces –Le client qui demande à utiliser un service ne connaît rien de la structure interne du fournisseur. –Les accès directes aux services lourds en termes de ressource machine peuvent épuiser les capacités de calcul du SE embarqué. 24

Traitements / Traitements / Invocateur Forces –Même s’il s’agit de services légers, laisser un client les adresser directement, obligera ce dernier à toujours connaître leur localisation et le moyen de les invoquer. –Par ailleurs, il se peut qu’un service ne soit pas actif tout le temps, ce qui nécessite des mécanismes de réactivation. Solution –L’Invocateur est une entité située en amont du SE et s’occupe de la réception des demandes de services. Les demandes sont analysées puis dirigées vers le service adéquat. 25

Traitements / Traitements / Invocateur 26 L’Invocateur est directement est fourni par Brazil via l’interface Handler. La figure ci-dessus schématise l’utilisation de ce modèle dans notre intergiciel. Une fois que le récepteur a déballé la requête, il la transmet à dispatcher qui, à son tour, va demander au service de s’exécuter.

Traitements / Traitements / Commande Problème –Comment ajouter de nouveaux services de manière transparente ? Forces –Il n’est pas possible au moment où nous créons l’intergiciel de connaître les services qui seront fournis par chaque système embarqué. Le processus d’exécution des demandes dépendra du type de service et des possibilités du système embarqué. L’exécution des demandes peut dans certains cas être différée ou dépendre d’une condition de garde. L’intergiciel doit faciliter l’ajout ou la modification d’un service aux différents systèmes embarqués. 27

Traitements / Traitements / Commande Solution –Le motif Commande offre la possibilité à chaque client d’encapsuler les requêtes comme des objets et de les transmettre à une entité qui va se charger de leur traitement. –Ce motif facilite le support de plusieurs types de requêtes. En outre, il permet l’ordonnancement de processus d’exécution des requêtes ainsi que la mise en œuvre des mécanismes d’annulation rétrospective des actions effectuées. –Il prévoit également que des opérations d’ordre technique comme la journalisation puissent être facilement ajoutés. 28

Traitements / Traitements / Commande 29 Dans l’intergiciel chaque service est implanté en tant que commande. L’intercepteur InvocateurDeService va d’abord encapsuler la demande de service dans un objet contexte. Par la suite, il détermine le nom du service à exécuter et finalement il va demander au service l’exécution de la requête et retourner le résultat au dispatcher qui le renverra à l’émetteur de la demande.

Configuration / Configuration / Intercepteur Problème –Comment ajouter de manière simple de nouvelles opérations à l’intergiciel ? Forces –L’ajout d’une nouvelle opération ne doit pas induire un changement de l’implémentation existante. –Les opérations doivent être indépendantes les unes des autres. 30

Configuration / Configuration / Intercepteur Solution –Le modèle Intercepteur décrit dans [3 p109, 37] est approprié pour l’ajout d’opérations sans casser le code existant. –Les opérations sont codées sous forme d’intercepteurs découplés qui peuvent être ajoutées dynamiquement au moment de l’initialisation de l’intergiciel. 31

Configuration / Configuration / Intercepteur 32 La figure ci-dessus montre la structure des classes pour l’utilisation du modèle Intercepteur. Avant d’invoquer le service, la demande est interceptée pour l’inscrire dans un journal et localiser le service demandé. Ce modèle nous a permis d’établir une séparation entre les fonctionnalités techniques liées au traçage et à la localisation du service et les services que peut rendre un SE.

Configuration / Chaine d’ Configuration / Chaine d’Intercepteurs Problème –Comment donner à une demande le plus de chances d’être traitée ? Forces –Le SE qui demande l’exécution d’un service ne connaît pas spécifiquement l’invocateur à déclencher. –Le demandeur et le fournisseur doivent être découplés. –La liste des invocateurs et des intercepteurs peut varier tout comme leur ordre d’exécution. 33

Configuration / Chaine d’ Configuration / Chaine d’Intercepteurs Solution –Le motif chaîne de responsabilités [1, 7] vise à découpler l’objet qui émet une requête de celui qui va l’exécuter en interposant une liste chainée d'objets entre les deux. –Chaque objet interposé a la possibilité soit de traiter la requête, soit de la transmettre au suivant ou encore de faire les deux. –Cela va permettre une plus grande flexibilité et donner plus de chance à une requête d’être satisfaite. –Ce modèle permet également d’ajouter dynamiquement des objets en interposition. 34

Configuration / Chaine d’ Configuration / Chaine d’Intercepteurs 35 Le motif chaîne de responsabilité est directement implémenté dans Brazil. L’invocateur ChaineHandler agrège tous les autres invocateurs. C’est lui qui est appelé en premier lors de la réception d’une requête. Nous l’avons également utilisé pour mettre en place une chaîne d’intercepteurs. La figure ci-dessus schématise l’utilisation dans modèle dans notre intergiciel

Configuration / Configurateur Problème –Comment découpler le comportement et les services de l’intergiciel entre le moment de la compilation et le moment où ils sont configurés pour une application ? Forces –On ne connait pas toujours à l’avance quels peuvent être les services que l’intergiciel doit fournir. –Il n’est pas aisé de déterminer à priori son comportement car il dépend souvent du contexte. 36

Configuration / Configurateur Forces –Aussi, il doit être possible de définir une configuration à tout moment : à la compilation, à l’intégration ou encore au moment de l’exécution. –On doit être en mesure de changer la configuration quand la situation l’exige. –Le fait de définir une configuration ne doit pas poser de difficultés particulières pour l’utilisateur.. 37

Configuration / Configurateur Solution –Afin d’obtenir plus de flexibilité, le modèle Configurateur [35, 3 p75] permet à des services d'évoluer indépendamment des problèmes de configuration. –Il permet d’ajouter ou de retirer des services à application à l’exécution sans être obligé de modifier, recompiler ou relancer l’édition de liens. –En centralisant en un seul endroit les services supportés par un système, il facilite l’administration, l’initialisation, le lancement et l'arrêt automatiques des services. 38

Configuration / Configurateur 39 Ce modèle est fourni de base dans le serveur web Brazil, Nous l’avons utilisé entre autre pour configurer : le type d’abstraction d’un système embarqué (SESimple ou SEComposite), la liste des protocoles qu’il supporte et les adresses réseau correspondantes, la liste des invocateurs, l’ensemble des intercepteurs ainsi que la liste des services qu’il peut fournir.