Démonstrateur de ladaptation distribuée de documents multimédia par composition de web services

Démonstrateur de l'adaptation distribuée de documents multimédia par composition de web services Rapport de stage de fin d’études dans le cadre du Master en informatique à l’Institut

Démonstrateur de l'adaptation distribuée de documents multimédia par composition de

web services

Rapport de stage de fin d’études dans le cadre du Master en informatique à

l’Institut de la Francophonie pour l’Informatique

Réalisé par NGUYEN Cong Kinh

Encadrant : Jean-Claude MOISSINAC

Ce stage est effectué au sein de l’équipe MultiMédia du département Traitement du Signal et des Images

de la TELECOM-ParisTech

9 septembre 2008

1 Introduction 9

2 Etat de l’art 11

2.1 Classification des services 11

2.2 Architecture du système d’adaptation 11

2.3 PAAM 12

3 Web services du traitement de document multimédia 13

3.1 Web service 13

3.1.1 Comment peut-on créer un web service 13

3.1.2 Annuaire UDDI 14

3.2 Catégorie de web services du traitement 15

3.2.1 Transcodage 15

3.2.2 Transmodage 16

3.2.2.1 Texte en image 16

3.2.2.2 Image en texte 16

3.2.2.3 Texte en son 16

3.2.2.4 Son en texte 16

3.2.2.5 Vidéo en image 16

3.2.2.6 Vidéo en slideshow 16

3.2.3 Transformation 17

3.2.3.1 Traduction de texte 17

3.2.3.2 Rognage d’une image ou une vidéo 17

3.2.3.3 Changement d’échelle d’une image ou une vidéo 17

3.2.3.4 Changement de résolution d’une image 17

3.2.3.5 Passage en noir et blanc d’une image ou d’une vidéo 17

3.2.3.6 Changement de fréquence d’échantillonnage d’un audio 17

3.2.3.7 Changement de débit pour un son ou une vidéo 17

3.2.3.8 Diminution de poids en octet 17

3.2.3.9 Diminution du bruit 17

3.3 Réalisation 18

3.3.1 Méthode de réalisation 18

3.3.1.1 Utilisation du logiciel pour les web services 18

3.3.1.2 Transport de données 18

3.3.2 Conception des Web services de PAAM 19

3.3.2.1 Transcodage 19

3.3.2.2 Transmodage 19

3.3.2.3 Transformation 20

3.3.2.4 Diagramme de conception 22

4 Web service sémantique : WSDL-S 24

4.1 Ontologie PAAM 24

4.2 Annotation du document WSDL 25

4.2.1 Elément opération 25

4.2.2 Eléments d’entrée et de sortie 26

4.2.3 Précondition 27

4.2.4 Effet 28

4.3 Publication des informations sémantiques 29

5 Composition des web services 30

5.1 Concepts basics 30

5.1.1 Activité receive et reply 31

5.1.2 Activité partnerLink 32

5.1.3 Activité variable 32

5.1.4 Activité invoke 33

5.2 Expériences 33

5.2.1 BPEL simple : HelloWorld 34

5.2.2 Ajout du document WSDL 34

5.2.3 Variable 34

5.2.4 Fichier du déploiement 36

5.2.5 Bilan 37

6 Résultats 38

6.1 Web services de traitement du document multimédia 38

6.2 Web service sémantique 38

6.3 Composition des web services 38

6.4 Conclusion 41

7 Conclusion 42

Références 43

Annexe 1 : Abréviation 45

Annexe 2 : Rapport technique 46

1 Description du rôle du web service 46

1.1 TextService 46

1.2 ImageService 47

1.3 AudioService 49

1.4 VideoService 50

1.5 TextToImageService 52

2 Description de l’installation Tomcat 54

3 Description des logiciels nécessaires 54

3.1 ffmpeg 54

3.2 tesseract 54

3.3 Mplayer-1.0rc2 55

3.4 ImageMagick 55

4 Description de configuration des web services 55

Annexe 3 : Ontologie PAAM 57

Annexe 4 : WSDL-S 77

1 Audio 77

2 Image 79

3 Texte 83

4 Vidéo 85

Annexe 5 : Compositions de web services dans PAAM 90

1 Fichier de déploiement 90

2 BPEL 90

Je voudrais aussi remercier Brahim Elloumi qui m’a donné plusieurs conseils utiles pendant la réalisation

du stage ou ainsi la vie en France

D’ailleurs, je voudrais remercier NGUYEN Toan Linh Tam et Tieu Kim Cuong, qui m’ont donné des repas vietnamiens très délicieux ou ainsi l’air de vivre en France très cool

En fin, je tiens tout particulièrement à remercier M Jean-Claude Moissinac, responsable du stage, qui m’a permis de faire ce stage et m’a donné beaucoup de conseils pendant tout le temps du stage

Ce stage porte des web services du traitement de document multimédia, des web services sémantiques et

de composition des web services par l’utilisation du langage BPEL pour adaptation de document multimédia par contexte de l’utilisateur

Pour réalisation de stage, nous avons choisi des outils existants possibles pour faire des traitements de document multimédia au niveau du web service Concernant le web service sémantique, nous avons utilisé la version Submission de W3C (pas encore une norme) pour annoter des documents WSDL Concernant le dernier domaine, nous avons fait un scénario pour montrer la composition semi automatique des web services pour qu’on puisse faire l’adaptation de document multimédia par le contexte de l’utilisateur

Abstract

The objective of our internship is to give a demonstration of the possibilities afforded by the use of web services multimedia, specially the adaptation of multimedia documents The architecture PAAM is proposed in the thesis of Zakia Kazi Aoul She has proposed a prototype of PAAM However, it is not yet valid

This internship deals with web services processing multimedia document, semantic web services and composition of web services through the use of language BPEL to adapt multimedia document by context

of user

We have chosen existent possible tools for multimedia document processing at the level of web service

On the semantic Web service, we used the Submission of W3C (not yet a standard) to annotate documents WSDL Concerning the last domain, we made a scenario to show semi-automatic composition des web services to demonstrate the adaptation of multimedia document by user context.

Liste des figures

Fig 1.1 Un contexte d'adaptation de document multimédia 9

Fig 2.1 Architecture fonctionnelle de PAAM [KA07] 12

Fig 3.1 Configuration de web service asynchrone 14

Fig 3.2 Adaptation en catégories 15

Fig 3.3 Comment peut-on réaliser le transcodage 19

Fig 3.4 Comment peut-on réaliser le transmodage 20

Fig 3.5 Comment peut-on réaliser la transformation de Texte 20

Fig 3.6 Comment peut-on réaliser la transformation de Image 21

Fig 3.7 Comment peut-on réaliser la transformation de Vidéo 22

Fig 3.8 Comment peut-on réaliser la transformation de Audio 22

Fig 3.9 Diagramme de séquence du changement de débit d'un audio en synchrone 23

Fig 3.10 Diagramme de séquence du changement de débit d'un audio en asynchrone 23

Fig 4.1 Hiérarchie de concept dans l’ontologie PAAM 25

Fig 4.2 Annotation d'une opération 25

Fig 4.3 Annotation d'un type simple 26

Fig 4.4 Exemple du type complexe 26

Fig 4.5 Annotation du type complexe 26

Fig 4.6 Schéma de précondition 27

Fig 4.7 Exemple d'annotation avec précondition et effet 28

Fig 4.8 Schéma d'un effet 28

Fig 5.1 Un scénario de composition de web services 30

Fig 5.2 Deux activités de receiveInput et replyOutput 31

Fig 5.3 Activité partnerLink 32

Fig 5.4 Activité variable 32

Fig 5.5 Activité invoke 33

Fig 5.6 Ajout d'un document WSDL utilisant Bpel-designer 34

Fig 5.7 Initialisation d'une variable 35

Fig 5.8 Utilisation du Namespace d'une variable 36

Fig 5.9 Déploiement de BPEL 37

Fig 6.1 Un scénario d'adaptation de document multimédia par composition de web services 39

Fig 6.2 un exemple du fichier MetaDoc 40

Fig 6.3 un document multimédia de type SVG 40

Fig 0.1 Configuration de FTP 55

Fig 0.2 Exemple 1 de Configuration 56

Fig 0.3 Exemple 2 de Configuration 56

Liste des tableaux Tab 3-1 Un exemple du transcodage 15 Tab 3-2 Description des logiciels utilisés pour les web services 18 Tab 4-1 Namespace du document WSDL 25

1 Introduction

Dans les années récentes, l’échange de document multimédia composé en des éléments tel que l’audio, l’image, le texte et la vidéo est de plus en plus populaire, notamment depuis l’apparition des langages définissant le document multimédia comme SMIL1, SVG2, etc En plus, l’Internet haut débit est presque connecté dans tout le monde entier

Dans notre cas, l’utilisateur veut ou il peut travailler seulement dans un ou des contextes bien définis Un document multimédia général est peut-être quelconque Donc, tout le contenu du document multimédia est peut-être souvent inconvenable pour l’utilisateur Il veut personnaliser le document multimédia selon son contexte d’utilisation Ces exigences entraînent d’avoir un système d’adaptation de document multimédia Dans ce cas, on a deux approches : une approche concernant un logiciel local et l’autre approche concernant un système distribué Un logiciel local a des limites telles que la capacité de périphérique, la nouvelle version mise a jour, etc Avec un système distribué, on peut éviter ces problèmes

Fig 1.1 Un contexte d'adaptation de document multimédia

Ce stage est fait au sein de l’équipe MM (MultiMédia) du département « Traitement du signal et des images » à la TELECOM-ParisTech (ex ENST Paris) Il fait suite à la thèse de Z Kazi-Aoul [KA07] portant sur l'adaptation de documents multimédia par composition de services élémentaires Dans ce cadre, un moteur de prise de décision met en correspondance une description d'un document multimédia et un contexte d'utilisation de ce document et en déduit une description de l'adaptation à réaliser Cette description est un arbre de composition d'un ensemble de services élémentaires

1 Synchronized Multimedia Integration Language

2 Scalable Vector Graphics

Image en couleur et texte

en anglais

Image en noir et blanc et texte en français Then I stumbled upon Paris Hilton, I didn’t

even think about her before because I

wouldn’t even categorize her in the loosest for

of an “artist.”

Ensuite, je suis tombé sur Paris Hilton, je n'ai même pas penser à elle avant parce que je n'aurait même pas classer dans le son pour loosest d'un "artiste"

Au cours du stage, on s'efforcera de trouver un formalisme adéquat pour rendre exploitables ces descriptions de façon automatique; probablement, il faudra s'appuyer sur les travaux concernant les web services sémantiques, avec description de pré-conditions et de post-conditions

L'évolution de nos travaux nous a conduit à choisir BPEL1 comme langage de description de la composition des services élémentaires et d'utiliser principalement des web services pour les adaptations L'essentiel du stage portera sur la constitution d'un ensemble de web services exploitables dans ce contexte et sur des réalisations visant à une utilisation efficace et réaliste de moteurs d'exécution BPEL pour réaliser les adaptations

La contribution principale de ce stage est de donner un démonstrateur des possibilités offertes par l’utilisation de Web Services multimédias distribués, notamment pour l’adaptation de document multimédia

Dans ce document, le mémoire est organisé en trois parties La première concerne l’introduction et la revue de la bibliographie En suit, ce sont trois chapitres principaux du document : Adaptation de document multimédia par web service, Web service sémantique et Composition des web services Ces chapitres sont vraiment techniques Il n’est pas facile à comprendre D’ailleurs, le chapitre 4 concernant WSDL-S est en cours d’élaboration Ce stage réalisé se base sur seulement une proposition de W3C Il manque des outils pour valider le résultat La dernière partie est deux chapitres concernant Analyse des résultats et Conclusion

1 Business Process Execution Language

2 Etat de l’art

2.1 Classification des services

Dans sa thèse, M Kimiaei [KIMIAEI05] a proposé une classification des services Pour adapter le contenu multimédia, on va envisager les traitements tels que transcodage de ressource1, transmodage de ressource2 et transformation de ressource3

2.2 Architecture du système d’adaptation

La première approche concerne l’adaptation du côté du client Dans ce cas, le contexte de l’utilisateur (le profil de l’utilisateur telles que ses préférences, la capacité de son terminal) est enregistré au niveau client Le rôle du serveur est seulement l’envoi de document multimédia Dans [RAN06], les auteurs ont proposé un système d’adaptation du côté du client pour diminuer la consommation d’énergie lors de l’affichage

La deuxième approche concerne l’adaptation du côté du serveur (client/serveur) Comme ce que j’ai présenté dans la partie 1 Introduction , cette approche évite les limites de périphérique du terminal, etc Dans ce cas, le serveur peut avoir plusieurs versions de document multimédia à partir d’un document d’origine Chaque version concerne un contexte de l’utilisateur Cependant, il faut avoir une machine de grande capacité de disque dur pour cette approche Dans les années récentes, il existe des projets d’adaptation de contenu multimédia basée sur web service comme [PAN06] Dans [PAN06], les auteurs ont proposé une architecture de RMob4 Dans cette architecture, l’adaptation de contenu multimédia est basée sur seulement le transcodage du web service Donc, il existe encore des choses manquées comme transmodage et transformation Mais, cette architecture est très similaire de l’architecture proposée dans

la thèse de Z Kazi-Aoul

La troisième approche concernant l’adaptation de document multimédia est de type client/serveur Cependant, un module intermédiaire est ajouté entre le client et le serveur Dans ce cas, le nombre des nœuds pour chaque système d’adaptation est forcement défini Donc, le système n’est pas vraiment souple On doit calculer les charges dans chaque nœud intermédiaire pour avoir une configuration du système convenable

2.3 PAAM

Dans sa thèse, Z Kazi-Aoul a proposé une architecture fonctionnelle de PAAM (Peer-2-Peer Architecture for the provision of Adaptable Multimedia contents) On la trouvera en Fig 2.1

Fig 2.1 Architecture fonctionnelle de PAAM [KA07]

L’utilisation de PAAM peut être expliquée comme le comportement suivant : un utilisateur envoie une demande qui se compose des documents multimédia et un contexte d’utilisation au planificateur Donc, le planificateur obtient une description du document Après l’analyse conjointe de cette description et du contexte d’utilisation, il prépare un plan d’adaptation à communiquer au gestionnaire d’adaptation Le gestionnaire d’adaptation cherche sur le réseau des adaptateurs élémentaires capables d’exécuter les différentes étapes du plan d’adaptation Il en invoque pour réaliser la demande de l’utilisateur

L’architecture de PAAM est de type P2P1 Cela veut dire que le nombre des nœuds dans ce réseau n’est pas forcement défini Un nœud dans le réseau est peut-être un client ou un serveur Donc, il faut avoir un système de gestion de l’adaptation pour gérer les fonctionnalités des nœuds dans le réseau

Dans sa thèse, Z Kazi-Aoul a validé le fait que BPEL était une bonne technologie à utiliser pour faire cette composition En plus, elle a donné un prototype pour l’architecture PAAM Mais, son prototype utilise des méthodes très limitées qui lui ont permis d’un certain nombre de tests et de validations D’ailleurs, elle n’a pas encore utilisé le BPEL dans son prototype C’est la raison pour laquelle je réalise ce stage à la suite de

sa thèse

1 Peer-2-Peer

3 Web services du traitement de document

multimédia

Ce chapitre constitue une partie très importante pour ce stage Tout d’abord, on va décrire quelques informations en bref concernant le web service, surtout la méthode de construire un web service Ensuite, trois catégories des web services du traitement de document multimédia sont présentées Et en fin de ce chapitre, on décrit quelques choses concernant la réalisation des web services du traitement de document multimédia

3.1 Web service

Un web service est une technologie permettant à des applications de dialoguer à distance via l’Internet indépendant de tout langage de programmation et de toute plate-forme d’exécution [WS04] La communication du web service est basée sur le protocole HTTP1 et le principe de demandes et réponses, effectuée par message sous la forme XML2 (messages SOAP3) Donc, en général, les communications sont non filtrées par les pare-feux

Le web service est décrit par un fichier WSDL4 qui précise la description des interfaces (types de données, paramètres des fonctions) En fait, dans un document WSDL, il se compose de sept éléments [WS02] :

- Type : un conteneur pour définitions des types de données utilisant quelques types existants (string, int, float, date, etc.)

- Message : une définition abstraite pour les données échangées entre web services

- Operation : une description abstraite d’une action fournie par le web service

- Port Type : un ensemble abstrait d’opérations fournies par un ou des points d’accès

- Binding : un protocole concret et la spécification du format de données pour un port type

- Port : un seul point d’accès défini comme la combinaison d’un binding et une adresse du réseau

- Service : une collection de points d’accès reliés

De nos jours, dans des outils open source (Eclipse, Netbeans) ou des outils commerciaux (Websphere, JBuider, MyEclipse, etc.), on peut créer facilement un web service en JAVA en utilisant l’interface

1 HyperText Transfer Protocol

2 eXtensible Markup Language

3 Simple Object Access Protocol

4 Web Service Definition Language

graphique En fait, il y a deux façons pour construire un nouveau web service La première façon s’appelle

Top-down [WS15] C’est-à-dire l’utilisation d’un fichier WSDL pour générer des classes en JAVA Après ça,

on va implémenter le web service La deuxième façon s’appelle Bottom-up [WS15] Cela veut dire que depuis une classe en JAVA, on peut générer le web service C’est complet pour créer un web service selon

la méthode Bottom-up Les deux méthodes décrites sont vraiment concrètes et compréhensibles dans [WS15] On se référera à ce document pour plus de détails

Le web service synchrone (le service est fait comme dans la partie 3.1.2) est seulement convenable si le temps de traitement du service est petit car le web service synchrone utilise un même tube pour recevoir

la requête et envoyer le résultat Si le traitement du service est longtemps par exemple un ou deux jours, etc., la connexion entre le serveur et le client est rompue Dans ce cas, on ne peut pas recevoir le résultat Pour éviter ce problème, il faut utiliser le service asynchrone En fait, le service asynchrone utilise deux tubes différents : un tube pour recevoir la requête du client et l’autre pour envoyer le résultat au client Donc, le temps de connexion concerne seulement la période de la requête reçue ou la période du résultat envoyé

Le serveur de web service Axis2 [AXIS2] fournit le web service asynchrone On se référence à ASYNC] pour mieux comprendre comment on peut faire un web service asynchrone et comment on peut invoquer un service asynchrone à côté de client Cependant, il y a une petite peu différence de la configuration du serveur entre le guide à [WS-ASYNC] et la réalisation réelle pour que ça marche Donc,

[WS-je présente seulement cette configuration

En fait, pour créer un web service asynchrone, tout d’abord on crée un service synchrone comme dans la partie 3.1.1 en utilisant Axis2 Le web service généré par Axis2 a un fichier de définition de la méthode du transport services.xml , par exemple /code/mobic/WebContent/WEB-INF/services/Video/META- INF/services.xml On ajoute une ligne comme dans la Fig 3.1

Fig 3.1 Configuration de web service asynchrone

UDDI (Universal Description, Discovery and Intégration) est une spécification indiquant la manière de publier et découvrir des web services dans le réseau Pour publier un web service, on utilise le message XML sous la forme de ebXML1 Ce message contient des informations nécessaires comme suit : adresse

1 Electronic Business using eXtensible Markup Language

<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"

class="org.apache.axis2.rpc.receivers.RPCInOutAsyncMessageReceiver"/>

IP , noms de domaines, les informations sur les modalités d’usage du web service, etc Pour découvrir, la recherche se fait grâce à un moteur de recherche intégré au site de l’opérateur UDDI choisi Ce moteur de recherche nous permettra d’affiner notre recherche selon plusieurs critères : nom de web service, nom de l’entreprise, etc

3.2 Catégorie de web services du traitement

Dans notre architecture du système de l’adaptation de document multimédia, nous examinons de diviser l’adaptation en trois catégories : transcodage, transmodage et transformation Donc, on peut présenter les catégories comme le schéma en Fig 3.2

Fig 3.2 Adaptation en catégories

La catégorie transcodage permet de changer la méthode de codage d’un média élémentaire (texte, image, audio, vidéo) En fait, pour l’image, l’audio et la vidéo, le transcodage est de changer le type du format On montre un exemple dans Tab 3-1

Transcodage Média élémentaire

Format d’origine Format du résultat

Adaptation en

transcodage

Adaptation en transmodage

Adaptation en transformation

Documents d’entrée contenant le langage présent, le format, etc

Cependant, pour le texte, le transcodage concerne l’encodage du caractère Cela veut dire que le transcodage du texte est le changement d’encodage du caractère, par exemple entre l’encodage ASCII et l’encodage UTF-8, etc

La catégorie transmodage consiste à changer le type de média Par exemple, si un terminal ne dispose pas de la police de caractère lui permettant d'afficher convenablement un texte en cyrillique, on va lui préparer une image de ce texte ; on a alors un transmodage de texte en image Dans les sous-sections suivantes de cette section, on présente des possibilités du traitement de document multimédia en transmodage

La conversion de texte en son concerne le langage d’utilisation C’est très important Chaque langage a des caractéristiques différentes comme intonation, structure, etc Donc, on ne peut pas avoir un service pour les langages dans le monde entiers Mais, on essaie d’avoir une fourniture pour des langages possibles comme anglais, français, etc

1 Optical Character Recognition

3.2.3 Transformation

La catégorie transformation consiste à modifier un média sans en modifier le format de codage Par exemple, il s'agira de réduire la taille d'une image par changement d'échelle ou par rognage des bords Dans les sous-sections, on va discuter sur les services de transformation

Il s’agit de traduire un texte d’un langage en un autre langage, par exemple : un texte d’anglais en texte

de français, etc Pour cela, il est intéressant de profiter des outils existants, notamment la traduction de Google

Il s’agit de rogner une image ou une vidéo Cela signifie que les deux dimensions (largeur et hauteur) d’une image ou une vidéo sont rognées

Il s’agit de changer l’échelle d’une image ou d’une vidéo Le changement d’échelle consiste à changer une dimension selon l’autre dimension

Il s’agit de changer les dimensions d’une image C’est-à-dire qu’il y a une nouvelle largeur et une nouvelle hauteur, mais le contenu de l’image est inchangé

Il s’agit de passer en noir et blanc une image ou une vidéo Cela veut dire que depuis une image ou une vidéo en couleur, elles sont passées en noir et blanc

Il s’agit de changer la fréquence d’échantillonnage d’un audio

Il s’agit de changer le débit en octet pour jouer Il est important dans le cas ó la bande passante disponible du réseau est petite

Il s’agit de diminuer « le poids » en octet d’une image Le poids concerne le nombre des bits présentant

un pixel

Il s’agit de diminuer le bruit sur l’image, le son et la vidéo

On va montrer les logiciels utilisés (tous sont open source) pour l’adaptation dans Tab 3-2

mplayer Il passe en noir et blanc une vidéo

tesseract Il transfère l’image en texte (extraction du texte contenu dans une image)

Tab 3-2 Description des logiciels utilisés pour les web services

Concernant les données traitées, il y a deux approches La première approche enregistre des données sur

un dossier local Les avantages de cette approche sont les suivantes : simples à comprendre, faciles à faire, etc Cependant, cette approche a quelques inconvénients On ne peut pas enregistrer des données

à distance Cela amène qu’on doit avoir un disque dur de grand volume car la taille du document multimédia est souvent grande Il est peut-être difficile dans quelques cas ó on ne veut pas fournir un grand disque dur sur cette machine ou il existe peut-être des risques sur celle

Une autre approche concerne l’utilisation d’un des protocoles populaires comme HTTP, FTP1, etc pour envoyer des documents traités à un serveur distant Cette approche perd peut-être un peu de temps par rapport à la première approche Mais, on peut résoudre l’inconvénient de l’approche précédente Dans ce stage, j’ai choisi la deuxième approche pour envoyer des documents traités car il est facile d’envoyer de grands fichiers, de configurer le système PAAM et aussi de déployer PAAM par rapport au protocole HTTP

1 File Transfer Protocol

3.3.2 Conception des Web services de PAAM

Fig 3.3 Comment peut-on réaliser le transcodage

Le schéma dans Fig 3.3 nous montre comment on peut réaliser le transcodage En fait, pour faire le transcodage de Vidéo et Audio, on utilise le logiciel « ffmpeg » Pour faire le transcodage d’Image, on utilise le logiciel « ImageMagick » Cependant, pour faire le transcodage de Texte, on n’utilise pas de bibliothèques externes Le document multimédia traité va être envoyé par le bloc « transport de données » Dans des sections suivantes, on ne rappelle plus cela

Le schéma dans Fig 3.4 nous montre comment peut-on réaliser le transmodage En fait, pour faire le transmodage de Vidéo en Slideshow et Vidéo en Image , on utilise le logiciel « ffmpeg » Pour faire le transmodage de Texte en son (Texte en Audio), on utilise le logiciel « eSpeak » Pour faire le transmodage de Image en Texte , on utilise le logiciel « tesseract » Mais, pour faire le transmodage de

Texte en Image , on n’utilise pas de bibliothèques externes

Adaptation de document multimédia

Transcodage

Transport

de données

Fig 3.4 Comment peut-on réaliser le transmodage

a) Transformation de Texte

Fig 3.5 Comment peut-on réaliser la transformation de Texte

Adaptation de document multimédia

Transmodage

tesseract

Vidéo

Slideshow Texte

Le schéma dans la Fig 3.5 nous montre comment on peut réaliser la transformation de Texte En fait, la transformation de Texte se compose de seulement un service concernant la traduction de texte Pour faire la traduction de texte, on utilise l’outil Google Translate

b) Transformation de Image

Fig 3.6 Comment peut-on réaliser la transformation de Image

Le schéma dans la Fig 3.6 nous montre comment on peut réaliser la transformation de Image En fait, pour la catégorie Transformation en image, il y a six services Les six services sont exécutés en utilisant l’outil « ImageMagick »

c) Transformation de Vidéo

Le schéma dans la Fig 3.7 nous montre comment on peut réaliser la transformation de Vidéo En fait, pour la catégorie Transformation en vidéo, il y a cinq services Comme la transformation de Image utilisant un même l’outil « ImageMagick », les cinq services sont aussi exécutés en prenant l’outil

« ffmpeg »

Adaptation de document multimédia

Changement

de résolution d’une image

Passage en noir et blanc d’une image

Diminution

de poids en octet

Diminution

de bruit Transport

de données

Fig 3.7 Comment peut-on réaliser la transformation de Vidéo d) Transformation de Audio

Fig 3.8 Comment peut-on réaliser la transformation de Audio

Le schéma dans la Fig 3.8 nous montre comment peut-on réaliser la transformation de Audio En fait, pour le service de Transformation de Audio, il y a trois services Comme deux types précédents ( Transformation de Image et Transformation de Vidéo ) utilisant un même outil, la transformation de Audio est exécutée en prenant l’outil « ffmpeg »

En fait, dans trois parties 3.3.2.1, 3.3.2.2 et 3.3.2.3, j’ai déjà présenté des schémas de réalisation des web services Donc, dans cette partie, je vais présenter deux seuls diagrammes de séquence pour montrer clairement la réalisation des web services basée sur des outils existants pas à pas Le travail présenté ici est le changement de débit d’un audio (voyez Fig 3.8 pour savoir le schéma de réalisation)

Ce diagramme est montré en Fig 3.9 et Fig 3.10

Adaptation de document multimédia

Changement de fréquence d’échantillonnage d’un

audio

Changement

de débit d’un audio

Passage en noir et blanc d’une vidéo

Changement

de débit d’une vidéo

Diminution

de bruit Transport

de données

Utilisateur AudioService Audio FFMPEG FTP Serveur

1 : changer le debit d'un audio()

2 : changer le debit d'un audio()

3 : changer le debit d'un audio()

4 : changer le debit d'un audio()

5 : retourner un nouvel audio()

6 : retourner un nouvel audio()

7 : envoyer un nouvel audio()

8 : retourner un nouvel URL()

Fig 3.9 Diagramme de séquence du changement de débit d'un audio en synchrone

Utilisateur AudioService Audio FFMPEG FTP Serveur

1 : changer le debit d'un audio()

2 : changer le debit d'un audio()

3 : changer le debit d'un audio()

4 : changer le debit d'un audio()

5 : retourner un nouvel audio()

6 : retourner un nouvel audio()

7 : envoyer un nouvel audio()

8 : envoyer un nouvel URL()

Fig 3.10 Diagramme de séquence du changement de débit d'un audio en asynchrone

4 Web service sémantique : WSDL-S

Le web service sémantique WSDL-S est la suite de OWL-S1 La spécification du web service sémantique WSDL-S est un W3C Member Submission2 Elle définit comment ajouter des informations sémantiques au document WSDL Des annotations sémantiques définissent le sens de l’entrée, de la sortie, de la précondition et de l’effet des opérations décrites dans une interface du service Ces annotations sont référencées avec des concepts dans une ontologie

Jusqu’à cet instant, il y a une norme de W3C pour annoter le document WSDL Elle est décrite dans [WS05] Mais, il y a des limitations pour cette norme car il existe des concepts manquants On ne peut pas ajouter des conditions comme précondition et effet pour chaque opération C’est-à-dire qu’on ne peut pas présenter la condition et l’effet de chaque opération En fait, ces deux choses sont très importantes car on a besoin de savoir quelles sont les conditions pour l’entrée d’une opération et quels sont les effets pour la sortie d’une opération C’est la raison pour laquelle dans notre choix, nous utilisons la version

Submission qui est décrite dans [SA07]

4.1 Ontologie PAAM

Pour construire l’ontologie de PAAM, on se base sur la thèse de G Hagos [HA06] car nous trouvons que le modèle de sa proposition est convenable avec le projet PAAM C’est pourquoi nous l’utilisons pour construire l’ontologie de PAAM Dans sa thèse, il a proposé une façon très simple pour construire l’ontologie concernant WSDL-S En fait, chaque opération de services est définie par un concept correspondant dans l’ontologie D’ailleurs, il a donné une manière de définir des conditions d’entrée et de sortie à partir du type d’entrée et de sortie On va montrer quelques concepts concernant des opérations

au document WSDL comme dans la Fig 4.1

Le schéma dans la Fig 4.1 nous montre le concept MultimediaAdaptationServices qui se compose de quatre sous-concepts : ImageAdaptationServices , AudioAdaptationServices , TextAdaptationServices ,

VideoAdaptationServices Les sous-concepts sont présentés par le message subClassOf ; par exemple

AudioTranscodingAdaptationServices est sous-concept de AudioAdaptationServices Dans le chapitre 3, on voit que le service du transcodage d’un élément Audio se compose de deux opérations illustrant deux sous-concepts de AudioTranscodingAdaptationServices Cependant, ce schéma ne nous montre pas suffisamment tous les concepts dans notre ontologie PAAM On liste tous les concepts de PAAM dans l’annexe 3

1 OWL-S is an ontology, within the OWL-based framework of the Semantic Web

2 Le processus de Member Submission permet de proposer la technologie ou d’autres idées pour l’équipe de W3C

Fig 4.1 Hiérarchie de concept dans l’ontologie PAAM

4.2 Annotation du document WSDL

Avant d’ajouter des annotations au document WSDL, on a besoin de définir le nom de Namespace1 On montre le Namespace dans Tab 4-1 En plus, il existe encore une attention pour annoter le document WSDL C’est que sa version est 2.0 Mais, la version du document WSDL généré par la section 3.1.1 est 1.1 Donc, on a besoin de convertir en version 2.0 un document WSDL avant de l’annoter C’est fait à partir de l’outil dans [WCON]

4.2.2 Eléments d’entrée et de sortie

En fait, chaque opération se compose de deux éléments : un pour l’entrée et l’autre pour la sortie Chaque élément est sous le type simple1 ou complexe2 Pour annoter l’entrée et la sortie d’une opération,

on annote sur des définitions du type

Pour annoter un type simple, on fait comme dans la section 4.2.1 Cela veut dire qu’on utilise le Namespace wssem et l’attribut modelReference On peut citer un exemple comme dans Fig 4.3

Fig 4.3 Annotation d'un type simple Avant de parler d’annotation du type complexe, on donne un exemple pour celui comme Fig 4.4

Fig 4.4 Exemple du type complexe Pour annoter cet élément, on a deux manières : une concernant l’annotation sur toutes les feuilles3, l’autre concernant l’annotation sur le type complexe Quant à la deuxième manière, on doit définir un schéma4 pour faire le mapping entre le contenu et le schéma Quant à la première manière, on ajoute les informations sur tous les sous-éléments Il semble que la deuxième manière est moins claire que la première pour une nouvelle personne de ce domaine Dans ce stage, nous utilisons la première manière

On va donner quelques lignes dans la Fig 4.5 pour traiter l’exemple dans Fig 4.4

Fig 4.5 Annotation du type complexe

1 Un type simple est composé par un des types fondamentaux du document WSDL comme la description dans la section 3.1

2 Un type complexe est composé par plus d’un type fondamental du document WSDL comme la description dans la section 3.1

3 Une feuille est un sous-élément dans le type complexe Dans Fig 4.4, on a deux feuilles avec les noms de « stUrl » et de « to_format »

4 Dans le domaine XML, un schéma pour définir une structure XML Autrement dit, le contenu de XML est défini par le schéma

<element name=”convert2BlackWhiteImageRequest” type=”xsd:string”

wssem:modelReference =”paam#URL”/>

<element name="convert2Base64">

<complexType>

<sequence>

<element name="stUrl" type="xsd:string"/>

<element name="to_format" type="xsd:string"/>

4.2.3 Précondition

Une précondition définit un ensemble d'affirmations qui doivent être réunies pour un web service qui peut être invoqué Elle peut préciser les exigences qui doivent être respectées, telles que "doit avoir un compte existant avec cette société», ou des restrictions, telles que "seulement les clients vietnamiens peuvent être servis" Les préconditions sont spécifiées comme éléments d’enfant de cette opération Le schéma pour une précondition est indiqué dans la Fig 4.6

On va expliquer quelques mots pour ce schéma :

/precondition : Cet élément spécifie l’annotation sémantique pour l’opération

/precondition/@name : L’attribut name spécifie un identificateur unique dans l'ensemble des préconditions dans le document WSDL

/precondition/@modelReference : L’attribut modelReference spécifie l'URI1 de la part d'un modèle sémantique qui décrit la précondition L’attribut modelReference et expression sont mutuellement exclusifs

Fig 4.6 Schéma de précondition /precondition/@expression : C’est une expression qui définit la précondition Le format de l'expression est défini par le langage de représentation sémantique utilisé pour exprimer le modèle sémantique L’attribut modelReference et expression sont mutuellement exclusifs

On va donner un exemple pour illustrer l’application de précondition et d’effet à partir de la Fig 4.7 Le schéma d’effet sera expliqué dans la section 4.2.4

<xsd:attribute name="name" type="xsd:string" />

<xsd:attribute name="modelReference" type="xsd:anyURI" />

<xsd:attribute name="expression" type="xsd:string" />

</xsd:restriction>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

Fig 4.7 Exemple d'annotation avec précondition et effet Dans la Fig 4.7, l’opération « convert2Base64 » est annotée par le concept

« AudioBase64ConversionAdaptationService » dans l’ontologie PAAM La precondition

« Base64ConversionInputSubject » dans ce cas spécifie que l’entrée de l’opération doit être une ressource

de l’audio

4.2.4 Effet

Un effet définit le résultat de l'invocation d'une opération Il peut simplement affirmer que la sortie est retourné ou il peut faire des déclarations sur ce qui change dans l'état et sur ce qui est attendu en invoquant le service Par exemple, « le nouveau solde du compte sera disponible » ou « le compte de carte de crédit sera débité » Le schéma d’un effet est comme Fig 4.8

Comme pour la précondition, on a quelques descriptions pour le schéma d’effet :

/effect : Cet élément spécifie l’annotation sémantique pour l’opération

Fig 4.8 Schéma d'un effet /effect/@name : L’attribut name spécifie un identificateur unique dans l'ensemble des effets dans le document WSDL

/effect/@modelReference : L’attribut modelReference spécifie l'URI de la part d'un modèle sémantique qui décrit l’effet L’attribut modelReference et expression sont mutuellement exclusifs

<operation name="convert2Base64" pattern="http://www.w3.org/ns/wsdl/in-out

wssem:modelReference="paam#AudioBase64ConversionAdaptationService">

<xsd:attribute name="name" type="xsd:string" />

<xsd:attribute name="modelReference" type="xsd:anyURI" />

<xsd:attribute name="expression" type="xsd:string" />

</xsd:restriction>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

/effect/@expression : C’est une expression qui définit l’effet Le format de l'expression est défini par le langage de représentation sémantique utilisé pour exprimer le modèle sémantique L’attribut modelReference et expression sont mutuellement exclusifs

Dans la Fig 4.7, l’effet de l’opération est décrit par deux concepts « Base64ConversionOutputSubject » et

« AudioResource » Cette condition signifie que le résultat de l’opération « convert2Base64 » est une ressource de l’audio

4.3 Publication des informations sémantiques

En fait, bien qu’il y ait des outils de publication pour OWL-S, jusqu’à cet instant on n’a pas encore eu un outil fourni pour WSDL-S Donc, on ne peut pas vérifier automatiquement des annotations dans le document WSDL

5 Composition des web services

La composition des web services est une partie très importante dans la vie de développement de web services Grâce à elle, on peut composer des web services pour avoir un nouveau web service qui profite des web services existants Elle joue une partie indispensable dans ce stage pour qu’on puisse obtenir le but du stage « adaptation de document multimédia par composition de web services » Nous avons choisi

le langage BPEL pour composer semi-automatiquement des web services Ce chapitre se compose de deux parties : une partie donnant des concepts basiques et l’autre concernant l’expérience du développement BPEL pour surmonter des difficultés au début

5.1 Concepts basics

Fig 5.1 Un scénario de composition de web services

Business Process Execution Language (BPEL ou WS-BPEL ) est un langage pour spécifier le comportement des processus d'entreprise2 basé sur les web services Jusqu’à maintenant, le BPEL n’a pas encore été la norme

Le schéma Fig 5.1 nous donne le scénario d’un exemple de composition des services avec BPEL En fait,

ce scénario est décrit comme suit : dans le programme BPEL, deux services bien faits qui sont décrits dans le chapitre 3 sont invoqués Ce sont la Traduction de texte et Changement d’échelle d’une vidéo Pour le langage, il y a deux paramètres d’entrée qui sont le contenu de texte et le langage utilisé Si le langage d’entrée est différent avec le langage dans la base de profil3, le service Traduction de texte sera invoqué pour traduire ce texte au langage convenable Pour la vidéo, si la dimension de vidéo d’entrée est plus grande que la dimension d’affichage dans la base de profil, le service Changement d’échelle d’une vidéo sera invoqué Donc, la dimension de vidéo d’entrée sera changée pour qu’elle soit convenablement affichée au terminal de l’utilisateur

5.1.1 Activité receive et reply

Chaque programme BPEL a une opération au moins Chaque opération se compose d’une ou de deux activités : une pour l’opération d’un-chemin4 et deux pour l’opération de deux-chemin5 Ce sont < receive >

et < reply > L’activité < receive > est pour recevoir des paramètres d’entrée de l’opération du programme BPEL On peut redéfinir n’importe quel type de données pour l’entrée de cette opération L’activite

< reply > est pour retourner le résultat de l’opération Dans la Fig 5.1, elles s’appellent receiveInput et

replyOutput Au niveau du BPEL, elles sont définies dans la Fig 5.2

Fig 5.2 Deux activités de receiveInput et replyOutput

Le nom de l’opération du service en BPEL dans la Fig 5.2 s’appelle process Elle est composée par deux activités receive et reply L’activité receive reçoit le message d’entrée à partir de la variable (variable présentée par la partie 5.1.3) input L’activité reply retourne le résultat à partir de la variable output C’est

le message retourné en service BPEL

< bpws:receive createInstance= "yes" name= "receiveInput"

operation= "process" partnerLink= "client"

portType= "tns:WebServiceComposition" variable= "input" />

< bpws:reply name= "replyOutput" operation= "process"

partnerLink= "client" portType= "tns:WebServiceComposition"

variable= "output" />

5.1.2 Activité partnerLink

Pour qu’on puisse invoquer un service externe (par exemple le service bien fait en JAVA dans le chapitre 3), il faut utiliser l’activité partnerLink Dans Fig 5.1, on utilise quatre activités partnerLink qui sont détaillés dans Fig 5.3

Fig 5.3 Activité partnerLink Chaque activité partnerLink se compose de trois informations au moins Ces sont partnerLinkType , name, myRole ou partnerRole En fait, ces informations concernent des documents WSDL externes (les documents WSDL externes ont défini des informations partnerLinkType, myRole, partnerRole ) pour qu’on puisse invoquer des services externes

5.1.3 Activité variable

Les variables sont une partie indispensable pour un module BPEL comme dans n’importe quel langage de programmation On montre deux types de variable définis dans Fig 5.1 à partir de Fig 5.4

Fig 5.4 Activité variable

En fait, pour définir une variable , il y a trois manières basées sur messageType, element (dans Fig 5.4)

ou type Elles sont déclarées et déjà définies dans le document WSDL Avec trois types, une variable est toujours sous la structure XML Cela veut dire qu’on peut utiliser XPath1 pour les variables

1 XML Path language

< bpws:partnerLinks >

< bpws:partnerLink myRole= "WebServiceCompositionProvider"

name= "client" partnerLinkType= "tns:WebServiceComposition" />

< bpws:partnerLink name= "linkUserProfile"

partnerLinkType= "ns:partnerLinkUserProfile"

partnerRole= "roleUserProfile" />

< bpws:partnerLink name= "linkText"

partnerLinkType= "ns:partnerLinkText" partnerRole= "roleText" />

< bpws:partnerLink name= "linkVideo"

partnerLinkType= "ns:partnerLinkVideo" partnerRole= "roleVideo" />

5.1.4 Activité invoke

Pour invoquer un service externe, on doit utiliser l’activité invoke Dans Fig 5.1, il y a cinq invocations des services externes InvokeUserScreenWidth, InvokeUserScreenHeight, InvokeUserProfileLanguage, InvokeScale et InvokeTranslation Chaque activité invoke , on doit donner deux variables : une présentant

le message d’entrée de l’opération du service, l’autre contenant le message de retour de l’opération du service Bien qu’il y ait quelques cas ó l’opération du service est sans retour, on doit encore donner toujours deux variables dans l’activité invoke On va montrer l’invocation InvokeUserProfileLanguage dans Fig 5.5

Fig 5.5 Activité invoke

En fait, l’opération getUserLanguage dans Fig 5.5 ne demande rien pour l’entrée (seulement pour tester

le scénario dans la Fig 5.1 En fait, il faut utiliser l’identité de l’utilisateur) Mais, on voit la propriété

inputVariable S’il la manque, ça ne marche pas

5.2 Expériences

En pratique, il n’y a pas beaucoup de documents concernant BPEL ; il est difficile de maỵtriser BPEL Au début, j’ai eu toujours des questions « comment peut-on faire un programme BPEL complexe (invoquer des services existants) de bout en bout sur apache-ode ? Comment peut-on assigner des variables absolument exactes » C’est la raison pour laquelle j’écris cette partie basée sur mes expériences de développement BPEL déployé sur apache-ode Je souhaite que cette partie soit utile pour surmonter facilement les difficultés au début

Pour comprendre cette partie et pour suivre le développement BPEL Il faut savoir faire les web services présentés dans la partie 3.1.1 de ce document et il faut comprendre des concepts basics présentés dans

la partie 5.1 de ce chapitre

Dans la pratique, j’utilise la version 1.2 de apache-ode [ODE] sur web serveur Apache-tomcat de la version 6.0.16 [APA-TOM], la version 1.6.0_06-b02 du JDK [JDK], Eclipse 3.3.2 [ECLIPSE] et bpel- designer sur Eclipse 3.3.2 [BPEL-DESIGN] Cependant, je ne présente pas du tout sur comment on peut installer ces outils Pour pouvoir utiliser apache-ode et ainsi déployer un programme BPEL sur apache- ode, il faut regarder au site [ODE-GUIDE] D’ailleurs, pour utiliser le plug-in BPEL sur Eclipse, il faut aussi voir au site [BPEL-INSTALL] En fin, je rappelle que l’apache-ode est seulement un service sur Apache- tomcat

5.2.1 BPEL simple : HelloWorld

En fait, il manque des informations pour développer un exemple de BPEL complexe de bout en bout Mais,

il existe plusieurs sites qui parlent d’un exemple HelloWorld du BPEL, par exemple dans [BPEL-IBM] Il ne faut pas oublier qu’il y a des différences et difficultés entre un exemple de BPEL simple et un exemple complexe C’est vraiment difficile au niveau de développement d’un scénario de BPEL comme on veut Donc, je ne rappelle pas comment on peut faire un exemple de HelloWorld dans cette partie Cependant,

il est vraiment utile et nécessaire de réaliser un HelloWorld car on peut comprendre simplement la manière de réalisation d’un scénario BPEL

Dans le parcours de développement d’un scénario BPEL complexe (utilisant des web services existants), j’utilise le plug-in Bpel-designer d’Eclipse comme dis au début de ce chapitre pour ajouter des documents WSDL Pour faire comme ça, on peut voir la vidéo dans [ADD-WSDL]

Cependant, je veux parler du résultat généré par l’utilisation de Bpel-designer Je trouve que jusqu’à maintenant, il y a une erreur pour ajouter un document WSDL utilisant le plug-in Bpel-designer Dans ce cas, on montre dans Fig 5.6

Fig 5.6 Ajout d'un document WSDL utilisant Bpel-designer

En fait, il faut supprimer la ligne superflue dans la Fig 5.6 quand on utilise le plug-in Bpel-designer pour ajouter des documents WSDL externes Cela devient difficile pour une personne débutante car elle ne peut pas comprendre pourquoi ça ne marche pas malgré un travail conforme à la vidéo de guide dans [ADD-WSDL]

5.2.3 Variable

En pratique, je trouve que le problème le plus grand pour l’utilisation d’une variable est d’assigner deux variables

a) Définition d’un élément « Test »

b) initialisation d’une variable vraie

c) initialisation d’une variable faute Fig 5.7 Initialisation d'une variable Avant d’utiliser une variable, il faut initialiser cette variable Cependant, il faut assigner au début toutes les structures XML pour une variable Si on assigne la valeur pour une partie d’une variable au début, il y aura une erreur dans l’exécution ; par exemple dans la Fig 5.7.c, l’initialisation d’une variable est faute lors de l’exécution car le moteur de BPEL ne comprend pas réellement la structure de la variable

En plus, il existe encore une chose dûment respectée concernant le Namespace de l’utilisation d’une variable Le Namespace doit suivre la valeur initialisée (sans concerner le Namespace dans la définition)

Il faut faire attention à ce problème Par exemple, dans la Fig 5.7.b, bien que la variable $var1 soit déclarée par le Namespace ns1 , la variable réellement initialisée ne contient pas le Namespace Donc, après avoir initialisé la valeur de cette variable comme dans la Fig 5.7.b, on ne peut pas utiliser le

Namespace (dans la requête XPath ) pour accéder aux parties de cette variable On va illustrer ça dans la Fig 5.8

Fig 5.8 Utilisation du Namespace d'une variable

5.2.4 Fichier du déploiement

Chaque serveur BPEL utilise un type du fichier de déploiement Le plug-in Bpel-designer sur Eclipse 3.3.2

ne fournit pas l’interface pour créer le fichier de déploiement C’est vraiment difficile lors de développement d’un BPEL pour ODE car il existe de différences importantes entre un scénario HelloWorld

et un autre scénario plus complexe pour le fichier de déploiement

a) Fichier de déploiement d’un scénario complexe

1 XML Path Language, en XPath, on peut utiliser “/” pour accéder aux sous-éléments d’un élément

<?xml version="1.0" encoding="UTF-8"?>

<provide partnerLink="client">

<service name="wns:WsComposition4ElementsService" port="WsComposition4ElementsPort"/> </provide>

<invoke partnerLink="linkVideo">

<service name="vns:VideoService" port="Video"/>

</invoke>

<invoke partnerLink="linkText">

<service name="vns:TextService" port="Text"/>

</invoke>

<invoke partnerLink="linkImage">

<service name="vns:ImageService" port="Image"/>

</invoke>

<invoke partnerLink="linkAudio">

<service name="vns:AudioService" port="Audio"/>

</invoke>

<invoke partnerLink="linkUserProfile">

<service name="vns:ParsingUserProfileService" port="ParsingUserProfile"/>

</invoke>

<invoke partnerLink="linkParsing">

<service name="vns:ParsingToBPELService" port="ParsingToBPEL"/>

</invoke>

</process>

</deploy>

b) Fichier de déploiement de HelloWorld

Fig 5.9 Déploiement de BPEL Voyons dans la Fig 5.9.a et la Fig 5.9.b, pour qu’on puisse invoquer un web service externe, il faut déclarer des partnerLinks et des services comme Fig 5.9.a Il faut faire attention à ce problème

< process name= "pns:HelloWorld" >

< active > true </ active >

< provide partnerLink= "client" >

< service name= "wns:HelloWorldService" port= "HelloWorldPort" />

6 Résultats

6.1 Web services de traitement du document multimédia

Dans l’implémentation des web services, j’ai choisi la méthode utilisant des programmes externes pour réaliser l’entreprise (elle est décrite dans 3.3.1 ) Cependant, je n’ai pas encore fait toutes les possibilités envisagées dans 3.2 Les possibilités faites sont présentées dans l’annexe 2 Deux possibilités texte en son

et son en texte (décrite par la partie 3.2.2.3 et 3.2.2.4) ne sont pas encore implémentées D’ailleurs, il y a

un outil qui s’appelle tesseract [TESS] Cet outil est pour faire le transmodage d’ image en texte Le résultat des cet outil n’est pas vraiment bon (je ne rappelle pas le résultat testé par leurs développeurs ici) Donc, il y a un peu de limitation pour deux services image en texte

Concernant le transport de données, j’ai utilisé le protocole FTP pour envoyer des documents multimédias traités D’ailleurs, j’ai aussi développé le web service concernant la consultation des préférences de l’utilisateur Cependant, c’est une partie simple Donc, elle n’est pas présentée dans ce rapport

6.2 Web service sémantique

Comme j’ai présenté dans le chapitre 4, c’est un sujet en cours d’élaboration Il manque des outils pour publier et découvrir les informations sémantiques contenues dans le document WSDL

6.3 Composition des web services

Tout d’abord, on présente quelques lignes sur la base de profil de l’utilisateur En fait, c’est une base contenant des informations des préférences de l’utilisateur comme l’identité, le langage de l’utilisateur, la taille du terminal de l’utilisateur, etc

Dans cette partie, nous avons implémenté un scénario BPEL pour montrer la composition de web services

et pour obtenir le but de l’adaptation de document multimédia par composition des web services On suppose qu’il y a une scène multimédia contenant des éléments médias tels que des textes et des vidéos

Ce scénario est pour personnaliser quelques éléments dans cette scène à partir du contexte de l’utilisateur Si le langage d’un élément « texte » personnalisé est différent avec celui dans la base de profil de l’utilisateur, le contenu de ce texte sera traduit au langage dans la base de profil Si la dimension d’un élément « video » personnalisé est plus grande que celui dans la base de profil, la dimension de cette vidéo sera changée en utilisant le service de changement d’échelle d’une vidéo

Fig 6.1 Un scénario d'adaptation de document multimédia par composition de web services

Le schéma de ce scénario est illustré dans Fig 6.1 Dans ce scénario, nous avons défini un nouveau service en utilisant des web services existants (service concernant texte et service concernant vidéo) L’entrée du nouveau service est un URL1 de fichier MetaDoc La sortie du nouveau service est un nouveau document multimédia personnalisé En fait, le fichier MetaDoc sera généré par un moteur de consultation

de personnalisation dans l’avenir (c’est une partie concernant une thèse parallèlement faite avec mon stage ; mais jusqu’à cet instance ce module n’a pas encore été fait) Chaque fichier MetaDoc contient l’emplacement du document multimédia d’origine En plus, il contient des éléments définissant ceux qu’on veut personnaliser à partir du document multimédia D’autres éléments sans décription dans le fichier

MetaDoc sont inchangés

1 Uniform Resource Locator

Le fichier MetaDoc est décrit dans Fig 6.2 Le contenu du fichier MetaDoc est sous la structure XML La

Fig 6.2 un exemple du fichier MetaDoc

ressource de document multimédia est présentée par l’attribut « sceneLocation » dans l’élément

« metaDoc » Dans cet exemple, on veut personnaliser deux éléments de texte définis par « text » et un élément de vidéo défini par « video » Chaque élément a un attribut « pathInScene » définissant le chemin XPath dans le document multimédia que nous voulons faire cette personnalisation

La scène utilisée dans ce teste est un document multimédia de type SVG On montre le contenu de la scène dans Fig 6.3

Fig 6.3 un document multimédia de type SVG Dans le test de ce scénario, nous utilisons un document multimédia de type SVG Toutefois, on peut utiliser d’autres types comme SMIL, etc

<? xml version = 1.0 " encoding = UTF-8 " ?>

< metaDoc version = 0.1 " contentType = image/svg+xml "

< medias >

xmlns:xlink="http://www.w3.org/1999/xlink" baseProfile="tiny" id="svg"

version="1.2" viewBox="0 0 400 400" height="400" width="500">