INTRODUCTION
Contexte du travail
CELEBRATE ("ContExt eLEarning with BRoAdband TEchnologies") est un projet de 5 millions d’euros qui s’étend sur une période de 30 mois et qui entre dans le cadre du programme Technologies de la société de l’information de la Commission européenne [1]
L’objectif principal du projet est de créer un réseau européen d’apprentissage qui relie des établissements scholaires en assurant l’échange et la recherche des ressources pédagogiques entre eux Chaque établissement est considéré comme un dépôt contenant des ressources On adopte une approche distribuée : les ressources sont éparpillées dans un dépôt central ou dans les dépôts dans le réseau Au cœur du réseau est un système de courtage ( brokerage system ) auquel les clients se connectent Le système de courtage sert à acheminer les requêtes en provenance d’un client à des dépôts appropriés ou renvoyer les résultats
Toutefois, CELEBRATE n’est malheureusement pas le seul système de ce genre Il existe d’autres systèmes comme ARIADNE Knowledge Pool System, PROLEARN Repository Portal, EDUTELLA Smart Space for Learning, Il est nécessaire donc de se mettre d’accord sur une interface commune pour que ces systốmes ô parlent la mờme langue ằ et se fassent comprendre l’un par l’autre A cette fin, la spécification SQI est née
Ce stage se concentre sur l’analyse, la conception et l’implémentation d’une interface d’accès selon la spécification SQI De plus, sa réalisation aide à détecter les imperfections de SQI et alors contribue à l’améliorer parce que SQI est encore en phase de développement.
Définitions
Il convient d’aborder quelques notions de base concernant SQI
Selon la dộfinition de IEEE-LSTC [2], un objet d’apprentissage est ô entitộ numộrique ou non qui peut être utilisée, réutilisée ou référencée pendant des activités d’apprentissage assistées par ordinateur ằ Les objets d’apprentissage peuvent ờtre considộrộs comme des briques, et en combinant ces briques on arrive à construire une maison C’est de cette faỗon que les documents pédagogiques sont établis : ils sont une composition d’objets d’apprentissage La forme d’un objet d’apprentissage peut être très variée: un texte, une image, un questionnaire, une vidéo, Un objet d’apprentissage idéal se montre comme une entité autonome, ce qui n’empêche pas qu’il fonctionne bien en étant incorporé à un tout L’objectif principal de la conception des objets d’apprentissage est de faciliter leur migration entre différentes documents, différents contextes Par exemple une séquence vidéo de deux minutes peut aussi bien servir dans un cours d’informatique que dans le cadre d’un test, mais aussi cette séquence peut être insérée dans différentes plateformes [3]
En général, métadonnées sont des données sur des données En formation en ligne, les métadonées permettent de décrire la sémantique des diverses ressources pédagogiques et
Introduction donc favoriser leur découverte et recherche Un autre intérêt des métadonnées est de permettre à divers outils, divers systèmes de comprendre une ressource et de la réutiliser
Il nous faut aborder le standard LOM (Learning Object Metadata – Métadonnées d’objet d’apprentissage) qui concerne l’implémentation du gateway mentionné ci-dessus
Le Standard LOM (Learning Object Metadata)
Le standard LOM est une création du groupe LTSC (Learning Training System Committe) au sein de l’association IEEE (Institute of Electrical and Electronics Engineers) Il précise d’abord la syntaxe et la sémantique des métadonées éducatives et puis il spécifie les descripteurs, les attributs concrètes permettant la réalisation d’une fiche descriptive à partir d’une ressource pédagogique ( on dit un binding en anglais ) Les descripteurs sont classés en neuf catégories
Figure 1.1 Learning Object Metadata (Source: [4])
Voici une brève description des neuf catégories de descripteurs :
• General : détermine les caractéristiques générales à savoir l’identifiant, la langue, le titre,…
• Lifecycle : spécifie les caractéristiques du cycle de vie comme par exemple le numéro de version, la date de création, date d’expiration, …
• Meta-metadata : des indications sur les attributs
• Technical : définit les aspects techniques tel que le format, la taille, …
• Educational : concerne les spécificités pédagogiques d’un document, tel que son type, son niveau ou son public cible
• Rights : spécifie les droits de la propriété intellectuelle et les conditions d’utilisation tel que le copyright, le cỏt…
• Relation : précise les liens entre des documents
• Annotation : permet d’ajouter des annotations, des commentaires et des informations supplémentaires
• Classification : permet de localiser un document dans un système de classification
Par une vue générale, un dépôt d’objets est une collection des objets Normalement, ces objets sont identifiés et référencés à travers des métadonnées Les services de base d’un dépôt sont :le stockage, l’exposition et la livraison des objets
Ces objets peuvent aussi bien être stockés dans un seul endroit que dispersés dans un système distribué Dans le deuxième cas, le dépôt devrait se manifester comme un point d’accès unique même si les objets sont stockés sur des serveurs à divers endroits, ce qui donne à l’utilisateur un accès transparent au dépôt.
Problématique
Grâce à de nombreux dépôts d’objets d’apprentissage créés récemment, les utilisateurs ont accès à une ressource éducative énorme Toutefois, il n’est pas toujours facile de trouver les objets dont on a besoin car ils se cachent dans des systèmes fermés ou propriétaires Ces systèmes utilisent souvent des formats de données et des interfaces d’accès propriétaires Cela rend ces systèmes disparates : il manque l’interopérabilité entre eux
On peut citer cinq raisons principales qui rendent l’interopérabilité entre des dépôts d’objets d’apprentissage nécessaire [6]:
• La création des objets d’apprentissage est cỏteuse
• L’annotation des objets d’apprentissage est cỏteuse
• Une fois que les objets d’apprentissage sont créés, l’éditeur s’intéresse souvent à les disséminer
• Les dépôts d’objets d’apprentissage n’ont pas assez d’objets d’apprentissage
• Les utilisateurs veulent choisir les objets à partir d’un grand nombre de dépôts
Selon [5], l’interopérabilité est “ la capacité de deux ou plusieurs systèmes ou composantes d’ộchanger informations et d’utiliser les informations ộchangộes ằ Ainsi, l’interopộrabilitộ
Introduction concerne deux aspects : la réutilisation et l’échange des données Pour assurer la réutilisation des données, on a besoin une sémantique commune afin qu’un système puisse ô comprendre ằ les donnộes provenant de l’autre Le deuxiốme aspect est garanti en employant des protocoles communs qui rendent possible l’échange des données.
LA SPECIFICATION SQI
Travaux concernés
Digital Repository Interoperability (DRI) : Il s’agit d’une spécification de l’IMS Elle propose recommendations pour les fonctionnalités d’interopérabilité les plus communes d’un dộpụt qui sont ôrechercher/exposerằ, ôramasser/exposerằ, ôalerter/exposerằ, ôsoumettre/stockerằ, ôdemander/dộlivrerằ Elle laisse pourtant implộmenteurs trop d’options à choisir pour effectivement régler l’interopérabilité
Z39.50 : C’est un protocole principalement utilisé dans des systèmes de bibliothèques Il a son propre langage de requête qui se base sur un ensemble d’attributs prédéfinis ainsi que sur des syntaxes de jeu de données Les récentes technologies web comme XML ou XQUERY ne sont pas présentes dans Z39.50 Des efforts sont en cours pour y incorporer XML comme format commun des échanges de données
SRW (Search/Retrieve Web Service protocol) vise à promouvoir l’interopérabilité entre bases de données réparties et ressources par l’utilisation d’un framework commun SRW emploie le langage de requête assez puissant CQL SRW ne supporte que des requêtes synchones
Edutella est un réseau paire-à-paire pour le partage de ressources éducatives Les ressources dans les dépôts sont décrites en RDF Edutella emploie le langage de requête QEL approprié à ressources décrites en RDF Les requêtes asynchones sont supportées par un méchanisme ô ộcouteur de rộsultatsằ qui est aussi utilisộ dans SQI
EduSource est un projet qui suit IMS Digital Repository Specification Il emploie un langage de requête propriétaire ECL (EduSource Communication Language )
Ariadne propose une interface de requête basée sur service web Cette interface ne s’intéresse qu’à des requêtes synchrones.
Framework pour l’interopérabilité entre dépôts d’objets d’apprentissage
CEN/ISSS a proposé un framework pour l’interopérabilité entre dépôts d’objets d’apprentissage [5] Ce framework spécifie un ensemble d’interfaces fournissant les services pour construire un réseau de noeuds éducatifs Dans ce framework, les services sont divisés en deux couches : les services noyau et les services d’application Les services noyau s’impliquent dans l’identification des dépôts d’objets d’apprentissage, dans l’authentification des utilisateurs et des dépôts, ou dans la gestion des sessions En se situant au-dessus des services noyau, les services d’application sont ceux qui vraiment apportent l’interopérabilité
Quelques services dans cette couche sont service de fourniture, service de requête, service de contrat, service de livraison, …
Figure 2.1: framework pour l’interopérabilité entre dépôts d’objets d’apprentissage
Les services de deux couches fonctionnent en se reposant sur un service de messagerie comme XML-RPC, RMI, SOAP, … Le service de messagerie a recours lui-même aux protocoles réseau comme HTTP, TCP/IP, SMTP, … pour transférer les données.
Spécification SQI
La spécification SQI est née dans le cadre des travaux du framework pour l’interopérabilité entre dépôts d’objets d’apprentissage ci-dessus mentionné Elle introduit une interface
Messaging Service (e.g SOAP, XML RPCs, JRMI, …)
Network Architecture (e.g HTTP, SMTP; TCP/IP, …)
Service de messagerie (e.g SOAP, XML-RPC , JRMI, … )
Services noyau (Gestion des sessions, authentification, …)
Architecture Réseau (e.g HTTP, SMTP; TCP/IP, … )
La Spécification SQI couvrant trois services : authentification, gestion des sessions (service noyau) et requête ( service d’application )
SQI supporte aussi bien les requêtes synchrones que celles asynchrones car elle a comme but de faciliter l’interopérabilité entre des systèmes pouvant être extrêmement hétérogènes La mode de requête asynchrone se montre appropriée quand il s’agit de faire une requête à un réseau hétérogène paire-à-paire ó la possibilité que des systèmes concernés sont ô suspendus ằ est trốs forte La mode synchrone est utile lorsqu’on fait des requờtes de faỗon locale, c’est à dire des requêtes client-serveur simple
D’ailleurs, SQI est neutre en termes de langages de requête et de formats des résultats En réalité, les dépôts stockent les métadonnées utilisant divers types de support comme base de données, système de fichiers, avec les formats de métadonnées différents (eg X ML, RDF,…) Les deux systốmes impliquộs dans une requờte (le systốme ô source ằ et le systốme ô cible ằ) doivent avant tout se mettre d’accord sur les langages de requờte et sur les formats des rộsultats Ceci nous offre une faỗon trốs flexible de changer le langage de requờte et le format de résultats en cours d’exécution Il faut quand même que les dépôts possèdent des ô wrappers ằ pour traduire entre les formats
SQI est conỗu pour ờtre extensible Pour cela, les auteurs ont choisi l’approche de minimiser le nombre des paramètres dans les méthodes Par conséquent, le nombre des méthodes devient grand On n’a heureusement pas à appeler toutes les méthodes définises dans SQI pour achever une requête Dans ce cas, les valeurs défauts sont utilisées
Figure 3 montre les étapes d’une requête ó le dépơt A recherche des ressources au dépơt B
Dans ce scénario, on s’intéresse à l’échange des données plutôt qu’à la gestion des sessions
Tout d’abord, le dộpụt ô source ằ A formule une requờte en langage de requờte commun et l’envoie au dộpụt ô cible ằ B Ensuite, B traduit la requờte en langage de requờte local et l’exécute Lors que les résultats ( au format local ) sont produits, B les renvoie à A en les traduisant au format de rộsultats commun Les composants ô wrapper ằ servent de traducteurs entre les langages de requête et les formats de résultats
Local Query Language Simple Query
Local Query Language Simple Query
Figure 2.3 : Communication entre deux dépôts de SQI (Source : [7])
Implémentée à la cible et appelée par la source
Implémentée à la source et appelée par la cible
La Spécification SQI setResultsFormat X setMaxQueryResults X setMaxDuration X
Interface de requête synchrone setResultsSetSize X synchronousQuery X getTotalResultsCount X getAdditionalQueryResults X
Interface de requête asynchrone asynchronousQuery X setSourceLocation X queryResultsListener X
Gestion des sessions createSession X createAnonymousSession X destroySession X
Les méthodes sont catégorisées en 5 groupes : gestion des sessions ,configuration des requêtes, interface de requête synchrone, interface de requête asynchrone, et gestion des résultats
L’établissement d’une connexion entre la source et la cible se fait grâce à createSession ou createAnonymousSession qui créent une session La source doit fournir à la cible nom d’utilisateur et mot de passe ou d’autres crộdentiels en vue de crộer une session Cette faỗon d’identifier une source permet la cible, d’une part, de refuser les sources inconnues et d’autre part, d’établir une politique de requêtes Une fois créée, une session peut être utilisée dans plusieurs requêtes Lors que la source appelle destroySession la session est supprimée Si la source n’appelle pas destroySession, la session est supprimée après une durée de time-out La source peut préciser la durée de time-out, le défaut pour time-out est 30 minutes
Les méthodes du groupe configuration des requêtes servent à préciser la valeur de divers paramètres impliqués dans une session comme le langage de requêtes, le nombre des résultats dans un jeu de résultats, la durée maximale d’une requête, le format des résultats
Dans le cas d’une requête synchrone, la méthode synchronousQuery est invoquée Le nombre maximum des résultats dans un jeu de résultat est limité par setResultsSetSize La méthode getTotalResultsCount donne le nombre total des résultats tandis que le reste des résultats à la cible sont retirés lors que la source appele getAdditionalQueryResults
Les résultats d’une requête asynchrone sont retournés à la source quand la cible appele queryResultsListener La méthode setSourceLocation est utilisée afin que la cible connaisse la
La Spécification SQI localisation de la source
GATEWAY POUR CELEBRATE
Le réseau CELEBRATE
Comme mentionné dans chapitre 1, CELEBRATE est un réseau européen de nœuds éducatifs Un nœud éducatif ici est en fait un système de gestion de contenus pour l’apprentissage Au cœur du réseau se trouvent un serveur de messagerie (messaging server) et un système de courtage (brokerage system) dont le role est d’acheminer les requêtes vers de bons destinataires Chaque nœud se muni d’un ELN Client qui est une couche logiciele servant à connecter au système de courtage Les étapes d’une requête peuvent être résumées comme suit :
- Un nœud (on dit ô la source ằ ) soumet une requờte au serveur de messagerie
- Le serveur de messagerie transite la requête vers le système de courtage
- Le système de courtage valide cette requête et l’envoie ensuite aux nœuds appropriés
- Ces nœuds éxecutent la requête et envoient les résultats au système de courtage
- Le système de courtage passe ces résultats à la source
Figure 3.1: La recherche d’objets d’apprentissage dans le réseau CELEBRATE
Gateway pour CELEBRATE
Il existe actuellement en Europe ( et dans le monde ) plusieurs réseaux de nœuds éducatifs par
Gateway pour CELEBRATE exemple ADRIADNE, ELENA, EDUTELLA, CELEBRATE, … chacun ayant ses propres formats de ressources, sa propre faỗon d’ộchanger les mộtadonnộes et donnộes Le gateway du CELEBRATE a vu le jour avec comme l’objectif primaire d’offrir une interface entre CELEBRATE et ces dépôts Les fonctionnalités du gateway construit sont :
- exposer une interface conforme à la spécification SQI qui permet à d’autre dépôts d’objets d’apprentissage de chercher et récupérer des ressources éducatives de CELEBRATE
- chercher des objets d’apprentissage dans divers dépôts d’objets d’apprentissage lorsque une requête provient du CELEBRATE
- permettre à l’administrateur du gateway de configurer les paramètres de fonctionnement
On pourra arriver à établir un réseau énorme comportant plusieurs réseaux de nœuds éducatifs La figure 3.2 montre cette idée : ARIADNE, ELENA et CELEBRATE se connectent en possédant chacun une interface SQI
Figure 3.2: Un réseau d’hôtes SQI
Au point de vu de CELEBRATE, le gateway est considéré comme un membre de réseau qui utilise l’interface ELN client pour se connecter au système de courtage à travers le serveur de messagerie (fig.3.3)
Figure 3.3: Gateway est un client du réseau CELEBRATE
S S er e rv ve eu ur r d de e me m es ss sa ag ge er ri ie e
IMPLEMENTATION
Cas d’utilisation
Il y a trois types d’acteurs qui interagissent avec le gateway :
- Administrateur du gateway(Gateway Administrator)
- Système de courtage (Brokerage System)
- Un hôte SQI (An SQI Host)
L’administrateur se charge de configurer le gateway en précisant plusieurs paramètres qui affectent son fonctionnement, à savoir le nombre maximum de connexions simultanées au gateway, le nombre maximum de requêtes simultanées en provenance de CELEBRATE, la localisation du listener du gateway Il peut aussi ajouter ou supprimer un hôte SQI dans la liste de hôtes SQI à connecter L’ouverture, la clôture de connexion à CELEBRATE, le démarrage et l’arrêt du gateway doivent être réalisés manuellement par l’administrateur
Lorsqu’un membre du CELEBRATE envoie une requête au système de courtage, cette requête sera renvoyée à d’autres membres y compris le gateway Le gateway ensuite transite la requờte aux hụtes SQI qui apparaợssent dans une liste de hụtes disponibles à connecter
Le système de courtage peut aussi retourner les résultats d’une requête au gateway Ces résultats sera retournés par le gateway vers le bon hôte sousmettant la requête
Un hôte SQI interagit avec le gateway par les méthodes définies dans SQI telles que: créer une session, spécifier le format de résultats, spécifier le time-out d’une requête,…etc
Architecture générale et implémentation
Les modules du gateway correspondent bien aux cas d’utilisation On va examiner en détail les fonctionnalités de chacun de ces modules
Il s’agit d’un paquet ElnClient fourni par CELEBRATE Il sert à faciliter la connexion au système de courtage Les mécanismes de gestion de sessions, de formulation de messages, de traitement de messages, … sont cachés dans ce paquet Il est fourni sous forme des fichiers jar spécifiques de Java
Ce module permet à l’administrateur de configurer les paramètres du gateway en les stockant dans un fichier de configuration XML Il gère également la connexion au système de courtage ainsi que celle à des hôtes SQI L’administrateur administre le gateway à l’aide d’une interface web écrit en JSP et Servlet l’accès au fichier de configuration se fait à l’aide des packages JAXB (java architecture for XML binding), JAXP (java architecture for XML processing) fournis par Sun
Il s’agit d’un module qui s’occupe de l’établissement des connexions à des hôtes SQI en utilisant le protocole SOAP SOAP (Simple Object Access Protocol) est un protocole de messagerie dont les messages sont écrits en XML C’est un protocole simple pour éxecuter les appels de méthodes de type RPC( Remote Procedure Call) Dans le cas de SQI, chaque hôte possède un fichier WSDL (Webservice Description Language) qui définit ses méthodes SQI L’implémentation du gateway a recours au package JAX-RPC (Java API for XML- Based RPC) fourni par Sun pour générer le client SOAP
A noter que le fichier WSDL décrivant les méthodes SQI est actuellement propre à chaque hụte et il est souvent gộnộrộ de faỗon automatique par une plateforme Lorsqu’un nouveau hôte implémente SQI, les autres hôtes doivent récupérer le fichier WSDL et puis implémenter des classes pour pouvoir se connecter a ce nouveau hôte Cela ne semble pas raisonable et pratique au niveau de la réalisation Les auteurs de l’SQI, en souhaitant faciliter la programmation et l’extension des hôtes, envisagent à rédiger une description commune de l’interface SQI, c’est-à-dire un fichier wsdl commun
Ce module implémente toutes les méthodes de SQI qui seront déployées comme des services web avec un fichier de description Les classes de support, les classes ô runtime ằ ainsi que le fichier wsdl sont générées par l’outil de développement SUN ONE Application Server 7 Un autre hôte peut implémenter l’interface décrit dans ce fichier wsdl et se connecter au gateway
Web services (SOAP Server) SOAP
XML un hôte SQI CELEBRATE
Ce module a pour but de gérer les sessions et acheminer les messages On va voir le détail des classes ci-dessous
Classe ô TimeoutCollectableStorage ằ et classe ô TimeoutCollector ằ :
Ces classes implémentent un mécanisme pour détruire les objets qui dépassent une durée de ô timeout ằ TimeoutCollectableStorage stocke dans une liste les objets susceptibles d’ờtre dộtruits Chaque objet est attribuộ un marqueur de temps qui permet à connaợtre son ộtat de validitộ au niveau de temps TimeoutCollector examine cet ộtat de ô timeout ằ selon lequel elle décide de supprimer l’objet ou pas
Web services (SOAP Server) SOAP un hôte SQI CELEBRATE
Cette classe stocke les requêtes en provenance du système de courtage Elle implémente l’interface ôTimeoutCollectableStorage ằ Il s’agit d’une file d’attente ú les requờtes sont traitées l’une après l’autre Une fois que les résultats pour une requête sont récupérés au niveau du gateway, cette requête servira à identifier le client et sera libérée Si aucun résultat n’est retournộ aprốs un certain temps, la requờte se trouve dans l’ộtat de ô timeout ằ et sera détruit.
Comme la classe ô MessagesList ằ, cette classe implộmente l’interface ôTimeoutCollectableStorage ằ et stocke les sessions crộộes par plusieurs hụtes SQI en utilisant le mờme mộcanisme de dộtruire les sessions selon ô timeout ằ
C’est une implémentation concrète de l’interface IncomingMessageListener Elle a pour rôle de recevoir les messages du système de courtage dont le traitement est délégué à une instance de ôMessageHandler ằ
Cette classe s’occupe de traiter plusieurs types de messages arrivant au gateway
Classe ô QuerySenderằ : ôQuerySenderằ est utilisộ par ô MessageHandler ằ pour envoyer une requờte à des hụtes SQI en mode synchrone ou asynchrone selon les modes supportés à chaque hôte
Cette classe abstraite représente un hôte SQI avec les méthodes SQI
Les informations sur le gateway ainsi que les états du gateway sont gardés dans l’instance de cette classe Car elle est conỗue selon le design pattern ô Singleton ằ, elle n’a au plus qu’une instance à tout moment Le fonctionnement du gateway dépend des informations stockées dans l’instance de cette classe Par exemple, lorsque le nombre de messages dans ô MessagesList ằ atteint le nombre maximum de messages dộfini dans ô Gateway ằ, le gateway ne traitera plus les requêtes du système de courtage
Ce module se charge de transformer les requêtes et les résultats en utilisant des feuilles de transformation et des classes de support en Java
Dans la version actuelle, le format VSQL(Very Simple Query Interface) est utilisé comme le format de requêtes commun VSQL compose d’une liste de mots-clé qui pourra être appliqués dans la recherche Un exemple de VSQL :
Le format de requêtes de CELEBRATE (appelé “filter”) se montre plus compliqué Il s’agit d’une combination rộcursive des opộrateurs ô and ằ, ô or ằ, ô not ằ avec des indicateurs de champs dans la recherche [1]
Le modèle commun de LOM proposé par SQI est IEEE 1484.12.1 A CELEBRATE,
CELEBRATE Metadata Application Profile v1.1 est utilisé Chaque modèle s’accompagne d’un binding XML Ces deux modèles de LOM ont des différences qu’on doit régler dans la transformation Les différences se manifeste sur deux niveaux :
Au niveau de modèle de données
- les éléments obligatoires : dans LOM de CELEBRATe, il y a des éléments obligatoires Dans LOM de IEEE, il n’y a accun élément obligatoire
- nouveaux éléments dans le modèle LOM de CELEBRATE
Au niveau de binding XML
- définition de types : un élément peut être défini avec des types différents dans le binding xml de CELEBRATE et dans celui de IEEE
IEEE LOM Resultset (xml instance)
CONCLUSION
Dans ce mộmoire, la spộcification ô Simple Query Interface ằ est abordộe en gros et en mờme temps, une perception générale de la problématique de l’interopérabilité entre dépôts d’apprentissage est présentée Le travail du stage se porte sur deux grands axes : l’étude de l’SQI et la mise en œuvre du SQI gateway La réalisation du gateway se concentre principalement sur la rédaction des feuilles de transformation entre formats XML (des fichiers XSL), la conception et l’implémentation des classes Java, des pages JSP La version actuelle du gateway n’a été testée qu’avec un nombre très petit de dépôts parce que l’SQI est en cours de développement et sa l’implémentation n’est pas encore répandue
En premier lieu, SQI a ộtộ conỗue pour rộsoudre le problốme d’interopộrabilitộ entre établissement éducatifs Cependant, elle peut aussi bien servir dans d’autres domaines qui impliquent l’échange, la décourverte de métadonnées
SQI reste encore à améliorer au niveau de API et de modèle de contenu Les travaux de définir un modèle de contenu commun, de rédiger fichier de description d’interface service Web (wsdl) sont en cours
Les captures d’ộcran du module ô Admin ằ
Le schộma xml du fichier de configuration du module ô admin ằ
http://fireboy.eun.org:8082/GatewaySQIWS/GatewaySQIWS
SQI Hosts to which Gateway is connected
http://rubens.cs.kuleuven.ac.be:8989/AWS- 4.2/services/SQITarget
SOAP Stub for connection to SQI Host
-
http://fireboy.eun.org:8082/AnSQIHostWS/AnSQIHostWS
Le diagramme de classes du module ô translation ằ :