Le WIKI de PAAM
Un nouvel outil va nous permettre de poursuivre la réflexion sur PAAM et l'architecture évolutive d'adaptation de documents multimédia: le WIKI de PAAM.
On le trouve à l'adresse:
http://shadok.enst.fr/paam-wiki
PAAM et le Web sémantique
PAAM doit manipuler un ensemble de descriptions sémantiques. Nous avons besoin de descriptions des préférences de l'utilisateur, de son contexte, des actions offertes par les adaptateurs, de métadonnées concernant le document multimédia consulté.
Pour cela, de nombreux groupes travaillent sur la définition de formalismes permettant d'assurer ces descriptions d'une façon exploitable par des automatismes.
Par exemple, pour décrire un document multimédia, nous trouverons des formalismes de description dans MPEG-7 et MPEG-21. Pour décrire une service, nous trouverons des formalismes dans WSDL, OWL-S,...
Pour manipuler ces descriptions, des outils logiciels sont proposés.
Par exemple, IBM propose "
Semantic Tools for Web Services". Les outils fournis facilitent la découvertes de service, la composition de services et le mise en correspondance des interfaces de deux services.
Décrire les possibilités multimédia d'un terminal
Dans cet article, nous allons montrer qu'il est difficile, voir impossible, de décrire les possibilités multimédia d'un terminal relié au réseau. Nous allons cependant proposer une méthode de description qui permette de répondre à certains besoins.
Lecteurs multimédia disponibles
Une façon de connaitre certaines capacités multimédia d'un équipement est de lister les lecteurs multimédia disponibles sur cet équipement. A chaque lecteur peut être associé une liste de formats de fichiers et de protocoles de communication supportés.
Développer des Web Services multimédia pour PAAM
Nous décrivons ici quelques étapes qui permettent de développer rapidement et facilement des Web Services pour PAAM. L'essentiel des étapes décrites constitue un guide d'écriture rapide de Web Services à l'aide d'Eclipse.
Environnement de développement et de publication
Il nous faut
- un serveur d'application; nous avons choisi Tomcat 5.5,
- un IDE de développement Java; nous avons choisi Eclipse 3.2 (voir
http://www.eclipse.org/downloads/index.php)
Nous avons ajouté à Eclipse les extension du WTP -Web Tool Platform-, comprenant le module WST -Web Standard Tools- (voir
http://www.eclipse.org/webtools/ et
http://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.1-200609230508/). Ces extensions vont nous faciliter la création de description WSDL, la génération de code de Web Service et le test du résultat.
Créer et tester un Web Service
Nous allons partir de rien. Nous verrons dans une autre note comment créer un service PAAM à l'aide des classes de services définies dans l'ontologie.
Nous devons d'abord déclarer un serveur dans Eclipse. Il nous servira au déploiement et aux tests. pour cela, cliquer New/Project/Server.
- menu New, création d'un Dynamic Web Project (à compléter)
- menu New, création d'un WSDL ((à compléter)
- menu New, génération d'un web service et de fonctions de test (à compléter)
...
DéploiementLe service peut être trouvé dans un sous-directory du workspace Eclipse qui a servi pour le développement. Par exemple, pour le workspace eclipseTests, le directory adressé par le serveur de test était:
/eclipseTests/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/webapps/
et les webs services développés et les applications de test se trouvaient dans ce directory webapps.
Pour les installer sur un serveur, il faut créer une archive déployable. Pour cela, dans le webapps ci-dessus et pour le service ImageResize, il faut faire:
cd Imageresize
pour descendre dans le directory où est définit le Web Service, puis
jar -cvf ImageResize.war *
pour faire le package déployable.
Ensuite, il suffit de copier le fichier war dans le directory webapps du serveur d'application et de provoquer son déploiement.
Il peut cependant être nécessaire de modifier une ligne dans le fichier server-config.wsdd. Il s'agit de la ligne qui indique où doivent être stockés les attachements que sont succeptibles de manipulés les services. La valeur (value) de cet élément doit désigner un chemin d'accès à un directory qui existe sur la machine où on fait le déploiement.
Annuaires d'adaptateurs PAAM
Une des fonctions assurées dans PAAM est la recherche d'adaptateurs répondant à certaines spécifications. Pour l'instant, nous faisons appel à une liste localea u gestionnaire (PAAM-DME - Decision Making Engine). Cette liste est une sorte d'annuaire des adaptateurs connus du gestionnaire.
Nous proposons d'étendre cette notion et d'en faire un service à part entière de l'architecture PAAM.
Ce Web Service fournira les services suivants:
fournir une liste des adaptateurs qu'il connait et qui répondent à une interrogation qui comprend au moins une urn d'adaptateur PAAM et éventuellement d'autres critères (gratuité, certification par un tiers de confiance...),
fournir une liste des nouveaux adaptateurs référencés par cet annuaire depuis une certaine date (pour permettre la diffusion de listes d'adaptateurs entre annuaires),
- recevoir et enregistrer une déclaration d'existence d'un adaptateur indiquant au moins l'URN de cet adaptateur et l'URL de la description WSDL qui permet de l'utiliser.
Compte tenu de l'évolutivité nécessaire de ces annuaires et du fait qu'ils seront de relativement petite taille, nous proposons d'adopter un format XML. Cela n'empêchera pas qu'un annuaire particulier puisse ranger ses informations dans une base de donnée, mais cela précise le mode de structuration retenu pour les informations.
Si un annuaire ne référence pas d'adaptateurs correspondant à une demande, il peut relayer la demande vers d'autres annuaires. On utilisera probablement la technique des cheminements aléatoires pour optimiser la recherche d'adaptateurs sans inonder le réseau de messages de recherche.
Afin de gérer une certaine dynamicité des adaptateurs, à chaque adaptateur pourra être associé des informations complémentaires de périodes d'utilisabilité. Le calendrier de disponibilité pourra fonctionner de la façon suivante:
- si cette information n'est pas indiquée, l'adaptateur est supposé toujours disponible;
- si cette information est disponible, elle pourra prendre différentes formes telles que 'disponibilité tous les jours de 0h à 6h UTC', 'disponibilité du1/12/2006 au 3/2/2007'; la représentation exacte reste à déterminer, mais tirera probablement profit des formats de stockage d'agendas.
La dynamicité de cet agenda reste à étudier. Par exemple, si un adaptateur a une longue file de traitements en attente prévient-il les annuaires chez qui il se sait référencé qu'il ne va pas être disponible.
Le gestionnaire pourra considérer cette information comme le premier facteur de choix entre plusieurs adaptateurs équivalents.
Le gestionnaire passe à un annuaire une liste de types d'adaptateurs et reçoit en retour une liste d'adaptateurs. Si l'annauaire contacté ne connait pas d'instance d'un des adaptateurs demandé, il peut, optionnellement, relayer la demande à d'autres annuaires suivant une stratégie qui lui est propre. On lui demande donc soit une recherche simple (locale), soit une recherche étendue.
Implicitement, on voit que lorsqu'un adaptateur veut se rendre accessible dans PAAM, il doit se référencer auprès d'au moins un annuaire PAAM.
Messages SOAP et traitements dans PAAM
Nous avons choisi d'envoyer les demandes d'adaptation sous forme de messages SOAP.
Si l'on se réfère à l'article "XML Screamer: An Integrated Approach to Hich Performance XML Parsing, Validation and Deserialization", on peut atteindre le traitement de messages XML à un débit de l'ordre de 50 megaoctets par secondes et par GHz en utilisant Screamer et environ 10 fois moins avec Xerces (notre implémentation actuelle pour PAAM).
Si on considère qu'on utilise de l'ordre de 10% du CPU pour l'analyse des messages, on doit pouvoir traiter par seconde environ 300 messages de 1000 octets sur une machine à 1 GHz.
Supposons:
- que tous les messages correspondent à une demande de changement d'échelle pour une image,
- que les images originales occupent 100 Ko,
- que l'adaptateur est relié par un lien à 100 Mbits/s.
En consacrant 80% de la bande passante à la réception des images, on peut en récupérer 100 par seconde. Les ordres de grandeurs sont alors cohérents entre les messgaes de commande et la capacité à recevoir les images.
Le traitement proprement dit des images est alors clairement le facteur limitant. Dans l'implémentation actuelle, il nous faut entre 0,5 et 1,5s/image. On voit clairement que c'est sur ce point que notre architecture doit jouer: mécanisme de mise en file d'attente, mécanisme de délégation à un autre adaptateur, mécanisme de choix d'adaptateur non surchargé...
Ontologie de services d'adaptation multimédia
Dans le cadre du projet PAAM, nous avions besoin de disposer de descripteurs d'adaptateurs multimédia: transcodeurs entre formats d'audio, d'images ou de vidéo, transmodeurs qui assurent un changement de modalité, comme un passage d'une séquence sonore à sa transcription textuelle...
Pour une part, les adaptateurs dont nous avons besoin peuvent être décrits avec WSDL. Mais la description obtenue est en général suffisante en terme de définition des types des paramètres des adapteurs, mais très pauvre sémantiquement.
Nous avons donc entrepris d'établir une ontologie des adaptateurs utilisables dans PAAM. Une ontologie selon Gruber (1993) est une spécification explicite et formelle d'une conceptualisation partagée. Pour plus d'informations sur les ontologies, on se reportera au travail WebOnt du W3C (
http://www.w3.org/2001/sw/WebOnt/).
Notre idée est d'associer une URN à chaque catégorie définie dans l'ontologie.
Nous avons des URN telles que:
urn:paam:trancoder:video:video
L'adaptateur est donc un transcoder
Il prend en entrée une source de donnée vidéo
Il prend en entrée une source de donnée vidéo
et nous allons définir précisément ce qu'est un transcoder et une vidéo ainsi que les paramètres que peut recevoir l'adaptateur et la façon dont il doit les interpréter et les utiliser.
Si vous êtes intéressé par l'établissement d'une telle ontologie, merci de nous contacter.
Description WSDL étendue de services d'adaptation dans PAAM
PAAM propose de décrire les services d'adaptation utilisés dans PAAM à l'aide de descriptions WSDL augmentées de quelques informations dans un namespace spécifique à PAAM.
La description WSDL fournit l'information sur l'interface d'utilisation du service, tandis que les extensions ajoutent une information sémantique sur le type de service d'adaptation fournit.
On trouvera un exemple de telle description à l'adresse
http://shadok.enst.fr/jcm/article65.html et
http://shadok.enst.fr/jcm/article67.htmlLa spécification de ces extensions sera détaillée ultérieurement.
