Services de données

Il est bien connu qu’un adaptateur est une interface pour interroger les sources de données et transformer les données en un modèle de données utilisé par le système d’intégration (Levy, 1999). Puisque le but de PseudomonasDW est d’intégrer des bases de données

accessibles via le protocole web, il est complètement normal qu’un adaptateur est considéré comme le composant le plus important dans l’architecture du système. Nous avons développé cinq adaptateurs sémantiques chacun pour une base de données. Nous pouvons définir l’adaptateur sémantique comme un adaptateur qui peut gérer les connaissances du Web.

Nous avons proposé d’améliorer le processus de l’implémentation des adaptateurs en les publiant comme des services Web (service de données dans notre cas) qui peuvent être réutilisés par autres systèmes d’intégrations. Les services Web permettent l’invocation de fonctions distantes, présentes sur des systèmes distribués et hétérogènes, grâce au protocole HTTP et à XML. Selon (Kadima and Monfor, 2003), « les services Web sont des

103

applications auto-descriptives, modulaires et faiblement couplées qui fournissent un modèle de programmation et de déploiement d’applications, basé sur des normes, et s’exécutent au travers de l’infrastructure Web ». Et selon (Zimmermann, et al., 2006) « un service est un composant applicatif mis à la disposition sur un réseau et disposant de méthodes que l’on peut invoquer à distance via l’emploi de protocoles standard. Les services Web présentent l’avantage d’être faiblement couplés, indépendants des plateformes et réutilisables »

Le but des services de données est de permettre à PsudomonasDW d’accéder à la

fonctionnalité des adaptateurs. Dans ce contexte, nous avons conçu une architecture adaptative avec laquelle nous avons pu définir un service de données comme «un service Web qui offre des fonctionnalités d’interrogation par les adaptateurs en utilisant le protocole Web ».

3.2.1 Architecture du service de données dans PseudmonasDW

Dans cette section, nous présentons notre architecture du service de données (Figure 20). Elle inclut un ensemble d’outils qui nous a aidé à extraire les données de Pseudomonas sp de différentes sources de données.

Figure 20. Représentation schématique de l'architecture du service de données dans le système PseudmonesDW

Ce type de service utilise un processus bidimensionnel : (1) pour accéder aux sources de données en utilisant l’adaptateur qui traite une requête et retourne un document

104

XML ; (2) pour l’exportation de fonctionnalités d’interrogations par l’adaptateur et sa sémantique comme un service web. La sémantique du service Web inclut des informations sur le schéma de la source et la provenance de données. Cette dernière est nécessaire, dans le domaine de la bioinformatique, dont il est très important de savoir quelle source de données a été utilisée dans l’extraction d’une telle donnée. Dans ce contexte, en plus de service de requête de l’adaptateur, le service de données enveloppe une API (Application Programming Interface).

L’API constitue le point d’accès à la fonctionnalité du service Web. Elle publie trois méthodes : Query() qui soumit la requête XQuery à l’adaptateur et retourne un document XML. La structure du ce document doit satisfait les contraintes du schéma de la source. Les deux autres méthodes, getschema() et getDataprovenance(), permissent l’accès aux métadonnées stockées dans le service Web. La méthode getschema() retourne le schéma XML de la source de données et la méthode getDataprovenance() fournit des informations sur la base de données interrogées (par exemple le nom de la base de données).

Derrière le service Web, il y a une spéciale classe java qui traite l’appelle aux différentes méthodes. Cette classe s’appelle la classe Service ; qui est un composant générique conçu pour définir les trois différentes méthodes qui reçoivent l’appelle au service Web. La partie importante de la classe Service est de tenir la correspondance entre la requête XQuery (Hunter, 2003) et le langage de requête sous-jacent de la source de données. Autrement dit, la classe service est responsable de mettre des correspondances entre les paramètres de la requête XQuery et les paramètres de la source de données.

3.2.2 Implémentation du service de données dans PseudmonasDW

Pour publier nos services de données comme des services Web, nous avons utilisé Apache Tomcat78 _{comme un serveur d’application et Axis}79 _{comme une plateforme pour présenter}

le Web service. La première étape dans la publication du service web était la copie de tous les fichiers des classes java qui nous avons programmé, les bibliothèques utilisées et le fichier descripteur de déploiement dans le répertoire WEB-INF du répertoire racine du service de données (Figure 21). Le descripteur de déploiement est un fichier nommé web.xml qui contient tous les caractéristiques et les paramètres du web service.

78 _{http://tomcat.apache.org/} 79

105

Figure 21. Première étape de déploiment du service Web

La deuxième étape du déploiement du service web était la création du fichier deploy.wsdd dans le même dossier que le web.xml. Ce fichier contient l’ensemble des propriétés de déploiement du notre service Web qui ont été exprimées par l’élément <service> (Figure 22).

Figure 22. Deuxième étape de déploiement du service Web

Les attributs de l’élément <service> définissent les caractéristiques principales du service Web dont:

 L’attribut name indique le nom du service web.

 L’attribut provider définit le type de fournisseur de service qui était utilisé pour réaliser l’implémentation du service Web. Nous avons utilisé le provider

106

Java RPC qui permet d’exposer une classe Java quelconque en tant que service Web.

Le restant des propriétés du service Web a été défini par le biais d’éléments <parameter> qui définissent le nom et la valeur de différentes propriétés :

 Le paramètre className a été utilisé pour spécifier le nom complet de la classe d’implémentation Java du service. La valeur de ce paramètre est le chemin vers la classe java compilée associée au service Web (nous referons ici à la classe Service).

 Le paramètre allowedMethod a été utilisé pour définir la liste des méthodes exposées par le service Web. La valeur spéciale * indique que nous avons exposés toutes les méthodes du serveur Web.

La dernière étape de déploiement du service Web était la déclaration du service dans le fichier de configuration du serveur. Pour cela nous avons utilisé l’outil d’administration d’Axis AdminClient auquel nous avons fournis en paramètre le descripteur de déploiement du service via la commande suivante :

java -classpath %AXISCLASSPATH%

org.apache.axis.client.AdminClient deploy.wsdd

-http://hostname:portnumber/webServiceFolderName/services/AdminService

Cette opération nous a permis de mettre à jours le fichier Tomcat/webapps/Service Web/WEB-INF/server-config.wsdd. La vérification du bon déploiement du service Web a été effectuée par la saisie de la direction ‘http://hostname:portnumber/ webserviceName/Services’ dans la barre d’adresse du navigateur. Cela nous a permis d’obtenir les déférentes méthodes définies dans le service Web (Figure 23).

107