L'architecture orientée service d'Apertium

In English

Dessin de diagramme de composant : Un serveur Apertium implémente une interface XML-RPC (et éventuellement d'autres), à laquelle on peut accéder en utilisant un client Apertium ou un service Web (on peut accéder au service Web en utilisant une interface REST ou SOAP). C'est facile alors, pour les applications externes écrites dans divers langages, d'accéder aux possibilités d'Apertium en utilisant un service Web (par exemple, pour intégrer la traduction dans une application Ajax, dans un client IM, dans un service de traduction d'un grand service orienté IT (??) et une infrastructure géographiquement distribuée (par exemple, pour collaborer facilement avec des ingénieurs d'un pays offshore), etc...).

Diagramme de séquence montrant comment un client IM peut utiliser les possibilités d'un serveur Apertium (accédé via une interface de service Web) pour implémenter la traduction en temps réel (à la fois en entrée et en sortie) de messages instantanés.

MISE A JOUR: A présent, ce projet a été déplacé de branches/gsoc2009/deadbeef/ à trunk/, et ses sources sont disponibles ici : https://svn.code.sf.net/p/apertium/svn/trunk/apertium-service/

Les sources peuvent être facilement examinés ici : http://apertium.svn.sourceforge.net/viewvc/apertium/trunk/apertium-service/

Une interface web rapide vers un prototype du service opérationnel est disponible ici : http://www.neuralnoise.com/ApertiumWeb2/

Des instructions d'installation simples sont dans Apertium-service.

Introduction

Le but de ce projet est de concevoir et d'implémenter un "service Apertium" qui peut être facilement intégré dans les systèmes IT implémentés en utilisant un modèle basé sur une Architecture Orientée Service (SOA).

Actuellement, pour traduire un gros corpus de document, plusieurs processus Apertium sont créés et chacun doit charger les transducteurs requis, les grammaires etc., causant un gaspillage de ressources et, donc, une réduction de la scalability (traçabilité ??).

Pour résoudre ce problème, une solution est d'implémenter un service Apertium qui n'a pas besoin de recharger toutes les ressources pour chaque tache de traduction. En plus, ce genre de service serait capable de supporter des requêtes multiples en même temps (utile, par exemple, dans un environnement orienté Web 2.0), améliorerait la scalability (??), et pourrait être facilement inclus dans les processus de business existants et intégré dans les infrastructures IT existantes avec l'effort minimum.

En plus, ce projet a aussi pour but d'implémenter un service Web fonctionnant comme une passerelle entre le service Apertium et les applications externes (charger Apertium dans le service Web lui-même serait un non sens, dans la mesure où un service Web est sans état et ça ne résoudrait pas le problème de scalability): le service Web offrira à la fois une interface SOAP et REST, pour le rendre plus simple aux applications/services externes (par exemple: les clients IM, les sites web, les gros processus de business IT...) pour inclure les capacités de traduction sans importer l'application Apertium complète.

Un cas d'utilisation possible : une organisation de santé

Cet exemple montre comment les possibilités des serveurs Apertium peuvent être exposées par un service de traduction dans in service existant orienté infrastructure IT; dans ce cas, l'acteur (un médecin non anglophone) interagit avec le responsable de documents cliniques en enregistrant des documents de santé: ces enregistrements comprennent souvent du texte en langage naturel qui nécessitent des outils externes comme MetaMap pour être cartographié en ontologie ou des concepts. Dans ce cas, le texte en langage naturel non anglais est d'abord traduit en anglais en utilisant un service de traduction faisant appel à un serveur Apertium, et le résultat est fourni à MetaMap, qui cartographie le texte à présent en anglais en concepts (alors stockés dans une base de connaissances pour des analyses ultérieures).

Dans les systèmes d'information de santé (HIS), pour améliorer les services externes l'accès et l'intégration, il y a une tendance générale à implémenter l'infrastructure IT basée sur un modèle d'architecture orientée service; dans ce cas d'utilisation, je montre comment une organisation de pays non anglophones peut grandement bénéficier de l'intégration d'un service de traduction implémenté en utilisant Apertium dans leur infrastructure IT.

MetaMap est une application en ligne qui permet de cartographier le texte sous forme de concepts Metathesaurus UML, ce qui donne une interopérabilité très utile entre différentes langues et systèmes dans le domaine biomédical. MetaMap Transfer (MMTx) est un programme Java qui rend MetaMap disponible pour les chercheurs du domaine biomédical. Actuellement MetaMap fonctionne seulement avec les textes écrits en anglais, ce qui rend difficile l'utilisation des Metathesaurus UML pour extraire des concepts à partir de textes biomédicaux non anglais.

Une solution possible à ce problème est de traduire les textes biomédicaux non anglais en anglais, afin que MetaMap (et d'autres outils texte (mining ??) similaires) puisse effectivement travailler dessus.

Fonctionnement interne du service

Une vue de haut niveau possible de l'intérieur d'un serveur Apertium.

Une implémentation efficace et scalable (??) possible d'un serveur Apertium peut être composée des composants suivants :

• Gestionnaire d'authentification : il est nécessaire d'authentifier les utilisateurs (en utilisant l'authentification HTTP de base) et ça peut être interfacé, par exemple, à un serveur OpenLDAP externe, un DBMS contenant des informations d'utilisateurs, etc.

• Thread Pooler : une implémentation du modèle de Thread Pool : http://en.wikipedia.org/wiki/Thread_pool

• Gestionnaire de modes : localise les fichiers mode et les analyse avec le jeu d'instructions correspondant

• Object Pooling Factory : une implémentation du modèle d'Object Pool : http://en.wikipedia.org/wiki/Object_pool

• Composant de traduction : en utilisant les instructions contenues dans un fichier mode (analysé par le composant Modes Manager), traduit un texte donné encodé dans une certaine langue dans une autre.

Interface du service

Une interface possible pour les fonctionnalités du service Apertium est basée sur XML-RPC, un protocole d'appel de procédure distant qui utilise XML pour encoder ses appels et HTTP comme mécanisme de transport. Le standard XML-RPC est décrit en détail ici : http://www.xmlrpc.com/spec

La liste de méthodes que le service RPC Apertium exposera sera probablement similaire à ce qui suit :

• array<string> GetAvailableModes();

• string Translate(string Message, string modeName, string inputEncoding);

A FAIRE : ajouter des méthodes pour obtenir les possibilités actuelles du serveur et charger (??); c'est utile pour implémenter une sorte de load balancing dans le cas d'un cluster de serveurs Apertium.

État du développement

La suite de ce document présente l'évolution du développement entre le 22/05/2009 et le 06/07/2009. Ce n'est pas forcément intéressant en 2012 (ou après). Aussi, ça n'a pas été traduit. La traduction de cette page a été réalisée essentiellement pour l'accès aux graphiques de conception. La suite de la page en anglais est accessible ici : Apertium_going_SOA#Development_status_-_22.2F05.2F2009