mercredi, juillet 26, 2006

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é...

jeudi, juillet 06, 2006

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.