Framework orienté-service de médiation de données

Présentation au sujet: "Framework orienté-service de médiation de données"— Transcription de la présentation:

1 Framework orienté-service de médiation de données
ADELE Université Joseph Fourier – Grenoble 1 UFR IMAG Master 2e année Recherche Spécialité : Systèmes d’Information et Ingénierie Avancée des Logiciels Framework orienté-service de médiation de données Bonjour, Je vais vous présenté mon travail de master recherche au sein de l’équipe ADELE du laboratoire LIG. Intitulé «Framework orienté service de médiation de donnée». Mon stage est encadré par M. Philippe LALANDA. Projet de Master présentée par Bassem DEBBABI le 24 Juin Sous la direction de Philippe LALANDA

2 Plan de travail Introduction Etat de l’art : médiation
Cilia mediation framework Expérimentation Conclusion & Perspectives Voici donc le plan de ma présentation. Je commence par une petite introduction sur le contexte et la problématique de mon travail Puis je présente un état de l’art sur la médiation. J’enchaine après sur ma contribution, qui est un Framework orienté service de médiation de données. Je présente ainsi son architecture et les points importants de son implémentation Enfin, je termine par présenter un cas d’utilisation ou notre Framework a été utilisée. Et je termine bien sûr par une conclusion générale et des perspectives

3 L’informatique « everywhere »
Introduction Introduction L’informatique « everywhere »

4 Introduction Nouveaux services informatiques
Services web, domotiques, applications d’entreprises… Interaction entre ces services Un grand besoin d’intégration de données et d’applications Comme on le savait tous, l’informatique actuellement joue un rôle essentiel dans notre vie quotidienne. Désormais, des nouveaux services informatiques apparaissent régulièrement : des services web ou des sites web qui fournissent des services différents des passerelles domotiques qui fournissent des services à l’habitat des applications d’entreprise variés des capteurs reliés à des applications de surveillance des applications dans des dispositives mobiles … etc Généralement, ces services informatiques interagissent entre eux afin d’accomplir leurs tâches. D’où un grand besoin d’intégration de données et d’applications

5 Introduction Problématiques Solutions ? Hétérogénéité Données
Protocoles Passage à l’échelle Evolutivité Dynamicité Solutions ? médiation Cela engendre un certain nombres de problématiques liées principalement à: La hétérogénéité de donnée et de protocoles et à L’évolutivité des différents applications, ou chacune peut évolué indifféremment des autres. ainsi que la dynamicité, vue que des applications aujourd’hui (plus précisément des capteurs ou des mobiles) apparaissent et disparaissent dynamiquement. C’est ainsi que la médiation intervienne.

6 Etat de l’art C’est quoi la médiation? Médiation

7 Médiation Définition Médiateur Chaîne de médiation
une couche intergicielle intelligente de services dans des systèmes d’information, liant des ressources de données aux applications [Wiederhold 92] Couche d’applications Couche ressources de donnée Couche de médiation S1 S2 A2 A1 S3 Module logiciel qui exploite des connaissances sur certains ensembles ou sous-ensembles de données pour créer de l’information pour une couche supérieure d’applications M2 M1 M3 La définition couramment utilisé pour décrire la médiation est celle du chercheur Wiederhold. Il définie la médiation comme : « une couche …. applications ». Les sources de données peuvent être des services web, des capteurs, des bases de données etc. Et les application peuvent être d’autres services web, des outils de surveillances, des progiciels de gestion etc. La couche de médiation est constituée de plusieurs médiateurs. Un médiateur selon le même auteur est définie comme un : « Module logiciel …d’appplications ». Et généralement, un ou plusieurs médiateurs sont regroupés dans des chaines de médiation.

8 Importance de la médiation
Transformation de données Filtrage de données Intégration de différentes sources et applications Réutilisation Evolution du code M d1 d2 M d1 d2 M A S Protocole A Protocole B A Version 1 M Version 2 M Version 1 Version 2 S Version 1 L’importance d’avoir des médiateurs est donc, de pouvoir faire : Des transformations de données d’un format à un autre De faire des filtrages sur les données, plus particulièrement pour la remonté de données oû en prend que quelques données significatifs -D’intégrer différentes sources de données et applications, alors que au départ ces deux entités ont des protocoles différents de communication, un médiateur peut les faire communiquer. -la réutilisation des médiateurs afin de construire des chaines de médiation différents selon les cas. -Evolution de certaines applications n’influe pas les autres. Par exemple si le source de données S évolue de la version 1 vers la version 2, l’application A ne sera pas influencer par ce changement, mais c’est seulement le médiateur entre les deux.

9 Types de médiation Médiation de : données hétérogènes
Bases de données, fichiers, … Sémantique formelle données pervasives M2M RFID, Capteurs services (Intégration d’applications) JBI ESB Ensuite, il y a plusieurs types de médiation. On a par exemple : La médiation des données hétérogènes : Ce cas de médiation a reçu beaucoup d’attention … La médiation des données pervasives : celui-ci est un nouveau domaine de recherche, on s’interesse ici à la remonté de données des dispositifs

10 Frameworks de médiation
Niveaux de médiation Transformation de données Communication Coordination Aspects non fonctionnels

11 Frameworks de médiation (1)
Composite Probes Managed System B1 B2 B3 B4 C3 C4 C1 C2 Client Data Flow Control Flow Monitored Resource Basic Probe Composite Probe B C

12 Frameworks de médiation (2)
Apache Camel Route 3 Route 1 Content-based router JMS Endpoint HTTP Component JMS Component Route 2 FTP Component HTTP Endpoint FTP Endpoint CSV Translator XML Translator IncomingOrderQueue OrderQueue

13 Message Router Endpoint
Frameworks de médiation (3) Spring Integration HTTP Adapter Endpoint Input Messages Chanel Message Router Endpoint XML Messages Channel CSV Messages Channel Out Messages Channel XML Handler CSV Handler Router FTP Source HTTP Source FTP Adapter Endpoint Service Activator JMS Adapter Endpoint JMS Target

14 Médiation Synthèse Manque de flexibilité
Aspects non fonctionnels sont peu traités Traitement des erreurs Persistance Sécurité Complexité très élevée Recours à des experts

15 Cilia : Framework orienté- service de médiation de données
Contribution Cilia : Framework orienté- service de médiation de données

16 Chaîne de médiation XML Transformer Gateway CSV Transformer

17 Médiateur XML Transformer C S Processor XML Transformer C S C S
Scheduler Dispatcher S C S Gateway CSV Transformer

18 Comment ça marche? Mediator d2 Collector d2 d1 d3 Sender d3 Collector
metadata d2 Collector d2 metadata d1 metadata d3 Sender d3 Collector d1 Scheduler Processor Dispatcher metadata d3 metadata d1 metadata d3 metadata d2 metadata d1

19 Composants de médiation
Modèle de développement Composants à service (iPOJO) Collectors, Scheduler, Processor, Dispatcher et Sender Gestion des aspects non fonctionnels Handlers Bibliothèque de fabriques d’instances Handler POJO Handler Handler Handler

20 Mediation Chain Manager
Création des médiateurs <cilia> <mediators> <mediator> <collector ref=jms topic=T1> <Scheduler ref=periodic delay=1000> <processor component=fr.imag.MyProcessor/> <dispatcher ref=default/> <Sender ref=jms topic=T2/> </mediator> </mediators> </cilia> Mediators (instances) Mediation Chain Manager Mediation ADL Service Components (Factories)

21 Intégration d’applications
Expérimentation On arrive maintenant à la partie d’expérimentation de notre framework. Nous avons la testé dans le domaine d’intégration d’applications. Intégration d’applications

22 Système de facturation
Expérimentation Intégration d’applications Catalogue de produits HTTP SOAP JMS Application Web L’intégration d’applications est à la fois des processus et des progiciels permettant d’automatiser les échanges entre des applications différents. Nous avons ici par exemple trois applications différents : Une applications web de commande de produits Un catalogue de produit exporter sous forme de service web Et un système de facturation qui est une application patrimoine (ou legacy). Et nous voulons intégrer ces différents applications afin de mettre en place le processus métier suivant : Un client choisi un ensemble de produits avec l’interface web, les prix des produits commandés sont retrouvés depuis le catalogue de produits, puis la commande est passé au système de facturation pour valider la commande. On remarque déjà qu’il y a trois formats différents de données pour chaque application, et chacune utilise un protocole particulier. L’exemple que nous allons prendre est comme suit : Nous avons Système de facturation

23 Système de facturation
Expérimentation Intégration d’applications Intégration monolithique Catalogue de produits SOAP Nouveau Système Application Web HTTP JMS Système de facturation

24 Expérimentation Intégration d’applications Intégration avec Cilia
Catalogue de produits Calculer les prix Passer la commande Transformer Direct Collector JMS Sender Application Web Price Counter HTTP Collector Direct Sender Catalogue de produits B Système de facturation

25 Expérimentation Intégration d’applications Intégration avec Cilia
AggregatorScheduler DirectSender Direct Collector Aggregator Catalogue de produits Calculer les prix Application Web AGGREG SPLITER Calculer les prix B Le problème principale de l’utilisation de ce pattern est comment retrouver les même données découpés. Dans Cilia, on peut faire le suivant : Dans le SPLITTER, on a un DISPATCHER qui, en plus de dispatcher les données au différents médiateurs, il ajoute une information de correlation. De l’autre coté, l’AGGREGATOR a un scheduler qui attent que les bonnes données du meme requête ont été collectés. Passer la commande Spliter Dispatcher HTTP Collector Direct Sender Spliter Catalogue de produits B Système de facturation

26 Conclusion & Perspectives
On arrive enfin à la conclusion

27 Conclusion & Perspectives
Facilité de développement et création des médiateurs Composants à service ADL Modularité Chaines de médiation plus expressives scheduler / dispatcher Hautement flexible Utiliser dans plusieurs projets internes Perspectives Approche à conteneur Domain Specific Component Model Autonomic computing Mediator Collector Handler Sender Handler Scheduler Dispatcher Log Persistence IHM Alors, comme conclusion, le framework résultat

28 MERCI Question?