FR2879873A1 - Procede et dispositif de transfert de donnees numeriques - Google Patents

Abstract

Procédé de transfert de données numériques entre un dispositif client (100) et un dispositif serveur (102) sur un réseau de communication (104), ledit procédé étant mis en oeuvre au sein dudit dispositif serveur (102), caractérisé en ce qu'il comprend les étapes suivantes :i) en provenance du dispositif client (100), recevoir une requête (REQ) de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi, selon un format client et selon des préférences relatives à au moins la résolution et/ou la qualité numérique de l'objet ;ii) obtenir dans le réseau de communication (104) une représentation de l'objet demandé ;iii) vérifier si la représentation de l'objet ainsi obtenu correspond à un format prédéterminé de type progressif ;iv) en cas de vérification négative, obtenir dans le réseau de communication (104) une forme transcodée de l'objet (DOT) comprenant la résolution et la qualité les plus élevées de l'objet ;v) extraire l'objet ou la partie de l'objet numérique conforme aux préférences spécifiées dans la requête (REQ) à partir de la forme transcodée ainsi obtenue (ROT) ; etvi) envoyer à destination du dispositif client 100 l'objet ou la partie de l'objet numérique ainsi extrait (ROC), au format client.

Description

La présente invention se rapporte au transfert de données numériques entre

un dispositif client et un dispositif serveur sur un réseau de communication.

Elle trouve une application particulière dans la livraison de données numériques et, plus particulièrement, d'images numériques.

D'une manière générale, au sein d'un réseau de communication, certains ordinateurs serveurs offrent des services aux autres ordinateurs, dits clients, du réseau de communication. Autrefois, ces services étaient accessibles via des protocoles propriétaires, tels que CORBA ( Common Object Request Broker Architecture pour Architecture pour un Intermédiaire Commun dans les Requêtes d'Objets ), DCOM ( Distributed Component Object Model pour Modèle de Composant Objet Distribué ) ou JINI ( Java Image I/O ).

Aujourd'hui, ces services sont de plus en plus accessibles à l'aide de protocoles de communication non propriétaires ou normalisés, tels que SOAP.

Le protocole SOAP ( Simple Object Access Protocol pour Protocole d'Accès Objet Simple ) est une application du langage de balisage XML ( Extensible Markup Language ). Il permet à deux ordinateurs de s'échanger des informations sous forme de blocs. D'une manière générale, un message SOAP consiste en une enveloppe contenant des blocs d'en-tête et des blocs de corps. Par ailleurs, le langage SOAP ne fournissant pas de protocole de communication propre, un message SOAP, c'est-à-dire une enveloppe SOAP, est effectivement transmis(e) d'un ordinateur à un autre par un protocole de communication, tel que le protocole de transfert hypertexte dit HTTP ( HyperText Transfer Protocol ), ou par un protocole utilisé pour l'échange de courrier électronique tel que SMTP ( Simple Mail Transfer Protocol ), ou bien encore par un protocole de transfert de fichiers de type FTP ( File Transfer Protocol ).

En pratique, inclure des données binaires dans des données XML nécessite un encodage préalable des données binaires au format base 64. Or, l'encodage au format base 64 implique une augmentation d'un tiers du volume des données. Les protocoles SwA ( SOAP Messages with Attachments ) et MTOM ( Message Transmission Optimization Mechanism pour Mécanisme d'Optimisation de la Transmission de Message ) définissent, respectivement pour le langage SOAP versions 1.1 et 1.2, un moyen d'attacher au message les données binaires brutes, c'est-à-dire sans encodage en base 64. Ceci permet donc d'optimiser les messages en terme de bande passante, mais aussi en terme de temps de calcul à l'émission et à la réception des messages, puisque le codage en base 64 et le décodage en base 64 ne sont plus nécessaires.

En pratique, les protocoles SwA et MTOM s'appuient tous les deux sur le format MIME Multipart ( Multipurpose lnternet Mail Extensions ), qui est un protocole de communication qui permet d'inclure autre chose que du texte (image, par exemple) dans le courrier électronique. En particulier, SwA décrit une façon d'écrire un message SOAP 1.1 dans une partie d'un message MIME Multipart et une façon de référencer les autres parties MIME du message dans le message SOAP. Le protocole MTOM décrit une sérialisation de messages SOAP 1.2 au format MIME Multipart.

Un service SOAP est en général décrit par un document WSDL ( Web Service Description Language ). WSDL est un langage de description de service spécialement adapté à la description de services SOAP ou HTTP.

On connaît aussi le langage XOP ( XML-binary Optimised Packaging ), qui est une application du langage XML. Cette spécification fournit une méthode de sérialisation de messages XML dans un format d'empaquetage extensible (c'est-à-dire un format dans lequel on peut délimiter des parties). Elle décrit notamment la sérialisation XML au format MIME Multipartlrelated. Le message XML est alors la partie MIME racine du message et l'apport de XOP consiste à remplacer les données binaires encodées classiquement dans un message XML en base 64 par une référence sur une partie MIME. Ceci permet d'éviter la redondance et le temps de traitement introduits par la représentation en base 64 des données binaires.

Par ailleurs, la notion de scalabilité (ou progressivité) est liée à la notion de compression de données multimédia. Afin d'adresser plusieurs dispositifs clients avec un même fichier compressé, il est nécessaire de disposer des données audio, images et/ou vidéo dans un format progressif composé d'une version de base et d'une ou plusieurs versions de raffinement. De plus, ces formats permettent également à un dispositif serveur de transmettre les données de façon progressive ( streaming ) vers un ou plusieurs dispositifs clients. On peut citer comme exemple de format scalable, dans le cadre de la compression d'images, le standard JPEG2000 (acronyme de Joint Photographic Expert Group ), avec son protocole de transmission Internet JPIP ( JPEG 2000 Internet Protocol ) qui, dans le contexte d'une application client/serveur, consiste à échanger des données JPEG2000. Un tel protocole JPIP permet de transmettre uniquement les données encodées nécessaires correspondant à une requête d'un dispositif client. Par exemple, les données correspondantes à une zone donnée de l'image ou les données pour la basse résolution de l'image sont uniquement transmises après encodage. Les requêtes de données d'image, selon le protocole JPIP, sont constituées de trois types de champs.

Le premier type est relatif à la requête transmise, indiquant le type de 20 commande JPIP, le nom de l'image demandée, l'identifiant de l'image, l'identifiant de la requête, le niveau de priorité de la requête.

Le second type concerne les champs de fenêtre de visualisation pour indiquer au serveur la zone d'intérêt courante désirée par le client. Ces champs incluent notamment le niveau de résolution de l'image associée à la zone, la position de la fenêtre dans l'image, la taille de la fenêtre (hauteur et largeur), les composantes de l'image incluses dans la zone d'intérêt. Ces paramètres peuvent limiter le nombre maximum d'octets de données utiles à retourner pour la zone considérée, le nombre maximum de couches de qualité à retourner ou encore le facteur de qualité d'image à satisfaire pour la zone d'intérêt.

Le troisième type est relatif au cache du client pour fournir au serveur des informations relatives à l'état du cache du client émetteur de la requête et permet ainsi d'optimiser la transmission en évitant l'envoi de données déjà reçues.

L'utilisation du protocole JPIP permet ainsi une navigation interactive et efficace dans l'image.

En pratique, l'utilisateur effectue une opération de zoom avant ou arrière, de déplacement dans l'image ou de demande de qualité, par exemple via une interface graphique. L'application cliente traduit ensuite cette opération en une requête JPIP envoyée au serveur. Puis, le serveur analyse la requête JPIP, extrait les données correspondantes de l'image JPEG2000 et renvoie ces données au format JPIP. L'application cliente décode alors les données et affiche la zone de l'image demandée.

Le protocole JPIP permet ainsi de transférer et de décoder seulement les données utiles. On a donc une réduction de la bande passante nécessaire, une réduction de la mémoire nécessaire au client et un gain en vitesse de décodage. II en résulte que pour des images en très haute résolution ou pour des dispositifs légers au niveau du dispositif client, le protocole JPIP est donc très utile.

Ainsi, le protocole JPIP permet une navigation efficace dans des images haute résolution ou à partir de dispositifs clients légers.

Néanmoins, cette navigation n'est possible que si l'image est déjà disponible sur un serveur JPIP, ce qui n'est pas le cas actuellement pour la majorité des images accessibles via le réseau de communication de type Web.

On connaît des solutions qui mettent en oeuvre des ordinateurs de type proxies, c'est-à-dire des serveurs intermédiaires relayant les messages et effectuant éventuellement des traitements sur ces messages. Par exemple, le brevet US 6,563,517 décrit de telles solutions à base de proxies. Dans ce document, les proxies transcodent les images avant de les transmettre au client final et permettent donc une meilleure utilisation de la bande passante et un décodage plus rapide des images. Néanmoins, ces proxies n'utilisent pas de format d'image progressif et doivent donc estimer les paramètres de transcodage. Ils doivent, par exemple, estimer le pas de quantification pour répondre aux besoins du client. II en résulte que chaque nouvelle requête sur une même image nécessite un nouveau transcodage. Enfin, ces proxies ne sont valables que pour certains formats d'image en entrée et ne sont donc pas évolutifs.

De plus, dès qu'un des paramètres de la requête client change, l'objet, c'est-à-dire l'image, doit être à nouveau transcodé.

La présente invention remédie aux inconvénients des dispositifs et procédés de l'art antérieur mentionnés ci-avant.

Elle porte sur un procédé de transfert de données numériques entre un dispositif client et un dispositif serveur sur un réseau de communication, ledit procédé étant mis en oeuvre au sein dudit dispositif serveur.

Selon une définition générale de l'invention, le procédé comprend les étapes suivantes: i) en provenance du dispositif client, recevoir une requête de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi, selon un format client et selon des préférences relatives à au moins la résolution et/ou la qualité numérique de l'objet; ii) obtenir dans le réseau de communication une représentation de l'objet demandé ; iii) vérifier si la représentation de l'objet ainsi obtenu correspond à 20 un format prédéterminé de type progressif; iv) en cas de vérification négative, obtenir dans le réseau de communication une forme transcodée de l'objet comprenant la résolution et la qualité les plus élevées de l'objet; v) extraire l'objet ou la partie de l'objet numérique conforme aux préférences spécifiées dans la requête à partir de la forme transcodée ainsi obtenue; et vi) envoyer à destination du dispositif client l'objet ou la partie de l'objet numérique ainsi extrait, au format client.

Ainsi, le procédé selon l'invention permet tout d'abord de déterminer et d'obtenir dans le réseau les paramètres de transcodage correspondants à la résolution et à la qualité les plus élevées de l'objet. Ensuite, l'objet est encodé une seule fois pour tous les niveaux de qualité et de résolution de l'objet, tous ces niveaux étant organisés de façon progressive. Alors, en réponse à une requête du client, on extrait les données conformes aux préférences spécifiées dans la requête client à partir de la forme transcodée obtenue. Il n'y a donc pas nécessité de transcoder à nouveau l'objet numérique pour chaque nouvelle configuration requise. Il en résulte notamment une réduction de la charge de calcul au niveau du dispositif serveur.

Selon un mode préféré de réalisation, le procédé comporte une étape préalable d'envoi au dispositif client d'un fichier de description d'un service disponible sur le dispositif serveur, la requête provenant du dispositif client étant alors conforme audit fichier de description de service.

En pratique, la requête client comprend l'URI de l'objet demandé. Selon une réalisation, le format prédéterminé de type progressif est le format de type JPEG2000.

Selon une autre réalisation, le format client est le format de type 15 JPEG2000.

Selon encore une autre réalisation, le format client est un format d'images appartenant au groupe formé par JPEG, TIFF ( Tag Image File Format ), BMP (fichier bitmap), GIF ( Graphics Interchange Format ) ou tout autre format descriptible par les types de données media prédéfinis et standardisés par l'IANA (Internet Assigned Numbers Authority).

Selon encore une autre réalisation, les paramètres de la requête sont définis par des structures de type XML échangées entre le dispositif client et le dispositif serveur par un protocole de transport de type SOAP.

En pratique, l'envoi à destination du dispositif client de l'objet ou de la partie de l'objet numérique, s'effectue par l'envoi d'un message comportant des structures de type XML et des données binaires, les données binaires étant formatées selon un format spécifique de type XOP.

Dans un mode particulier de réalisation, l'obtention dans le réseau d'une forme transcodée de l'objet s'effectue en plusieurs étapes de 30 transcodages successifs.

Avantageusement, la forme transcodée obtenue de l'objet est sauvegardée sur le dispositif serveur, de façon à en extraire des données conformes aux préférences spécifiées dans des requêtes client ultérieures.

La présente invention a également pour objet un dispositif serveur pour le transfert de données numériques avec un dispositif client sur un réseau de communication, caractérisé en ce qu'il comprend au sein dudit dispositif serveur: - des moyens de réception aptes, en provenance du dispositif client, à recevoir une requête de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi, selon un format client et selon des préférences relatives à au moins la résolution etlou la qualité numérique de l'objet; - des moyens pour obtenir dans le réseau de communication une représentation de l'objet demandé ; - des moyens de vérification pour vérifier si la représentation de l'objet ainsi obtenu correspond à un format prédéterminé de type progressif; - des moyens de traitement pour, en cas de vérification négative, obtenir dans le réseau de communication une forme transcodée de l'objet comprenant la résolution et la qualité les plus élevées de l'objet; - des moyens d'extraction pour extraire l'objet ou la partie de l'objet 20 numérique conforme aux préférences spécifiées dans la requête à partir de la forme transcodée ainsi obtenue; et - des moyens de communication pour envoyer à destination du dispositif client l'objet ou la partie de l'objet numérique ainsi extrait, au format client.

La présente invention a également pour objet un dispositif de transfert de données numériques entre un dispositif client et un dispositif serveur sur un réseau de communication, caractérisé en ce qu'il comprend un dispositif serveur adapté pour la mise en oeuvre du procédé selon l'invention.

La présente invention a également pour objet un support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en oeuvre du procédé de transfert selon l'invention, lorsque ce programme est chargé et exécuté par un système informatique.

La présente invention a enfin pour objet un programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre du procédé de transfert selon l'invention, lorsque ce programme est chargé et exécuté par un système informatique.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description et des dessins dans lesquels: - la figure 1 représente schématiquement l'architecture générale du dispositif de transfert de données entre un dispositif client et un dispositif serveur sur un réseau de communication selon l'invention; - la figure 2 représente schématiquement l'architecture générale d'un dispositif serveur selon l'invention; - la figure 3 représente un organigramme illustrant les étapes du procédé de transfert du côté du dispositif client selon l'invention; - la figure 4 représente schématiquement la structure logicielle du dispositif client mettant en oeuvre les étapes du procédé de la figure 3; - la figure 5 représente un organigramme illustrant les étapes du procédé de transfert du côté du dispositif serveur selon l'invention; et - la figure 6 représente schématiquement la structure logicielle du dispositif serveur mettant en oeuvre les étapes du procédé de la figure 5.

En référence à la figure 1, le transfert de données numériques selon l'invention s'effectue entre un dispositif client 100 et un dispositif serveur 102, à travers un réseau de communication 104. Le transfert peut s'effectuer via un dispositif de transcodage 106, qui peut être logé sur le dispositif serveur 102, ou à distance de celui-ci.

D'une manière générale, le procédé de transfert de données comprend les étapes suivantes: i) en provenance du dispositif client 100, recevoir une requête REQ de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi, selon un format client et selon des préférences relatives à au moins la résolution et/ou la qualité numérique de l'objet; ii) obtenir dans le réseau de communication 104 une représentation de l'objet demandé ; iii) vérifier si la représentation de l'objet ainsi obtenu correspond à un format prédéterminé de type progressif; iv) en cas de vérification négative, obtenir dans le réseau de 10 communication 104 une forme transcodée de l'objet ROT comprenant la résolution et la qualité les plus élevées de l'objet; v) extraire l'objet ou la partie de l'objet numérique conforme aux préférences spécifiées dans la requête REQ à partir de la forme transcodée ainsi obtenue ROT; et vi) envoyer à destination du dispositif client 100 l'objet ou la partie de l'objet numérique ainsi extrait ROC, au format client.

Ces étapes sont décrites en détails en référence aux figures 3 et 5.

En référence à la figure 2, on a décrit l'appareil programmable mettant en oeuvre le procédé selon l'invention. Cet appareil peut être le dispositif 100, 102 ou 106 décrit en référence à la figure 1.

L'appareil comporte un bus de communication 209 auquel sont reliés: - une unité centrale de traitement 202 (microprocesseur), qui commande les échanges entre les divers éléments de l'appareil, - une mémoire morte 201 pouvant comporter les programmes, - une mémoire vive 205 comportant des registres 208 adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes, - un disque dur 203 pouvant comporter les programmes précités, - un lecteur de disquette 211 adapté à recevoir une disquette 210 et à y lire ou à y écrire des documents traités ou à traiter selon l'invention, - une interface de communication 206 reliée à un réseau de communication 104, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des documents.

Le bus de communication 209 permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil directement ou par l'intermédiaire d'un autre élément de l'appareil.

Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké par exemple dans le disque dur 203 ou en mémoire morte 201.

Selon une variante de réalisation, la disquette 210 peut contenir des documents ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil, est stocké dans le disque dur 203.

Selon une autre variante de réalisation, le code exécutable des programmes peut être reçu par l'intermédiaire du réseau de communication 104, via l'interface 206, pour être stocké de façon identique à celle décrite précédemment.

Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention.

De manière plus générale, le ou les programmes peuvent être chargés dans un des moyens de stockage de l'appareil avant d'être exécutés.

L'unité centrale 202 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 203 ou la mémoire morte 201 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 203 ou la mémoire ROM 201, sont transférés dans la mémoire vive RAM 205 qui contiendra alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.

Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé.

Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).

La mise en oeuvre de l'invention côté dispositif client 100 est décrite en référence à la figure 3.

Une étape EO d'accès au service permet de récupérer la description du service (fichier WSDL selon un mode préféré).

L'exemple 1, relatif au fichier WSDL 1.0 pour service Web de navigation d'image, est le suivant: 1<?xml version="1.0" ?> 2 < definitions xmins:http="http://schemas.xmisoap.orq/wsdl/http/" 3 xmins:soap="http://schemas.xmisoap.org/wsdl/soap/" 4 xmins:s="http://www. w3.org/2001/XMLSchema" xmins:sO="http://example.org/ImageBrowsing" 6 xmins:soapenc="http://schemas.xmisoap.org/soap/encodinq/" 7 targetNamespace=" http://example.org/ImageBrowsinq" 8 xmins="http://schemas.xmisoap.org/wsdl/"> 10<types> 11 < s:schema elementFormDefault="qualified" 12 targetNamespace=" http://example.org/ImageBrowsing"> 14<s:element name="Getlmage" type="GetlmageType"/> 16<s:complexType name="GetlmageType"> 17 <s:element name="image" type="xs:anyURI"/> 18 <s:element name="type" type="xmlmime:contentType"/> 19 <s:element name="returnType" minOccurs="O" maxOccurs="l" type="xmlmime:contentType" default="jpp-stream"/> <s:element name="scalability" minOccurs="O" maxOccurs="l" type="string"/> 21 <s:element name="rate" minOccurs="O" maxOccurs="l" type="float"/> 22 <s:element name="zone" minOccurs="0" maxOccurs="l" type="ZoneType"/> 23< s:complexType/> 24<s:complexType name="ZoneType"> <s:element name="x" type="integer"/> 26 <s:element name="y" type="integer"/> 27 <s:element name="h" type="integer"/> 28 <s:element name="w" type="integer"/> 29<s:complexType/> 30<s:element name="Enhancelmage" type="EnhancelmageType"/> 31<s:complexType narre="EnhancelmageType"> 32 <s:element name="scalability" type="string"/> 33 <s:element name="rate" type="float"/> 34 < s:element name="zone" type="ZoneType"/> 35<s:complexType/> 36< s:element name="Setlmage" type="SetlmageType"/> 37<s:complexType name="DataType"> 38 <s:element attribute="href" type="xs:anyUri"/> 39<s:complexType/> 40<s:complexType name="SetlmageType"> 41 <s:attribute name="image" type="xs:anyURI" use="required"/> 42 <s:element name="data-stream" type=" DataType" > 43<s:complexType/> 44</types> <message name="Getlmageln"> 46 <part name="parameters" element="sO:Getlmage"/> 47 </message> 48 <message name="Enhancelmageln"> 49 <part name="parameters" element="sO:Enhancelmage"/> </message> 51 <message name=" GetlmageOut"> 52 <part name="parameters" element="sO:Setlmage"/> 53 </message> 54<portType name="BrowselmageWS"> <operation name="Browselmage"> 56 <input message="sO:Getlmageln"/> 57 < output message="sO:GetlmageOut"/> 58 </operation> 59 < operation name="EnhanceBrowselmage"> <input message="sO:Enhancelmageln"/> 61 <output message="sO:GetlmageOut"/> 62 </operation> 63</portType> 64<binding name="BrowselmageWS" type="sO:BrowselmageWS"> < soap:binding transport="http://schemas.xmisoap.org/soap/http" style="document"/> 66 <operation name="Browselmage"> 67 < soap:operation soapAction="http://example.org/ImageBrowsinq/Getlmage" style="document"/> 68 <input> 69 <soap:body use="literal"/> </input> 71 <output> 72 <soap:body use="literal"/> 73 </output> 74 </operation> <operation name="EnhanceBrowselmage"> 76 <soap:operation soapAction="http://example.org/ImageBrowsing/Enhancelmage" style="document"/> 77 <input> 78 <soap:body use="literal"/> 79 </input> <output> 81 <soap:body use="literal"/> 82 </output> 83</operation> 84</binding> 85<service name="ImageWS"> 86 <port name="PopulationWSSoap" binding=" sO:BrowseImageWS"> 87 <soap:address location="http://example. org/ImageBrowsing/Browse"/> 88 </port> 89</service> 90< /definitions> La première partie de cet exemple (lignes 1 à 12) déclare les préfixes utilisés pour les différents espaces de nommage permettant d'éviter des conflits de nom dans le choix des éléments..

La deuxième partie (lignes 14 à 23) spécifie les paramètres d'une requête de type Get image .

La partie de la ligne 24 à la ligne 29 explicite le type zoneType definissant une zone dans une image.

La troisième partie (lignes 30 à 35) spécifie les valeurs à donner 10 pour une requête de type Enhance Image .

La partie suivante (lignes 36 à 43) spécifie le format de la réponse envoyée par le serveur.

Les lignes 45 à 53 décrivent les échanges de messages correspondant aux requêtes/réponses client-serveur ainsi que les types de 15 données manipulés par ces messages.

Enfin, dans sa dernière partie, l'exemple 1 spécifie le protocole de transport utilisé par le serveur et l'adresse du serveur.

Cette description est utilisée par le dispositif client 100 pour former des requêtes REQ et garantir leur interprétation ultérieure par le dispositif serveur 102. Elle est intégrée dans l'exemple ci-dessus.

Le type de format client peut être par exemple: JPEG, GIF, BMP, PNG, TIFF...

Lors de l'étape El, les données nécessaires pour la requête client REQ sont obtenues, par exemple, via une interface graphique.

Si c'est la première requête client REQ, l'utilisateur précise l'URI de l'image et éventuellement les autres paramètres (zone...).

L'utilisateur précise également un type de retour souhaité (par défaut et selon un mode préféré, il s'agit de données JPEG2000 représentées par un flux JPIP, indiqué par le type jpp-stream ).

Des paramètres par défaut peuvent aussi être définis en fonction, par exemple, du terminal utilisé et de la bande passante disponible. Ainsi, dans le cas d'un terminal léger avec un petit écran, un faible débit permet de limiter le temps de décodage de l'image et seule la basse résolution est nécessaire.

Si ce n'est pas la première requête client REQ, l'utilisateur peut naviguer dans l'image via l'interface graphique (bouton de zoom, barre de défilement dans l'image...) et l'obtention des paramètres consiste en la traduction des actions de l'utilisateur.

Lors de l'étape E2, le message SOAP est généré et les données obtenues àl'étape El sont sérialisées, c'est-à-dire générées selon la syntaxe du fichier WSDL reçu à l'étape E0, pour former un message SOAP tel que décrit dans l'exemple 2.

L'exemple 2, relatif à une requête REQ envoyée par le dispositif client 100 selon le protocole SOAP, est le suivant: <?xml version="1. 0" ?> <soap:Envelope xmins:soap="http://www.w3.org/2003/05/soapenvelope" xmlns:xop="http://www.w3.org/2003/12/xop/include" xmins:xmlmime="http://www.w3.org/2004/06/xmlmime" xmnls:imageBrowsing="http://www.example.org/imageBrowsing"> < soap:Body> <imageBrowsing:GetImage> <imageBrowsing:image> "http://www.example.orq/myimage.jpg"</imageBrowsing:image> < imageBrowsing:type>image/jpeg</imageBrowsing:type> < imageBrowsing:scalability>resolution</imageBrowsing:scalability> <imageBrowsing:rate>1.0</imageBrowsing:rate> < imageBrowsing:zone> <x>0</x> <y>0</y> <w> 100</w> <h>100</h> </imageBrowsing:zone> < /imageBrowsing:Getlmage > </soap:Body> </soap:Envelope> Si c'est la première requête REQ de l'utilisateur, le message SOAP contient un élément Getlmage, sinon il contient un élément Enhancelmage. Cette différentiation permet au dispositif serveur 102 de déterminer si l'image demandée est déjà présente au format JPEG2000 sur le dispositif serveur 102.

Dans l'exemple ci-dessus, il s'agit d'une requête Getlmage dont une zone est spécifiée par les valeurs correspondantes décrit dans l'exemple 1. Dans l'exemple 2 de requête, le format de retour du client n'est pas spécifié. Cela signifie que le format du client est, par défaut, JPEG2000.

Lors de l'étape E3, la requête REQ est envoyée au service Web selon le transport ( binding ) précisé dans le fichier WSDL. Selon un mode préféré et, comme illustré dans l'exemple ci-dessus, le protocole de transport utilisé est le protocole SOAP sur http qui permet d'échanger des structures de type XML entre le dispositif client et le dispositif serveur.

Lors de l'étape E4, la réponse ROC en langage SOAP (figure 1) du dispositif serveur 102 est reçue au niveau du dispositif client 100.

L'exemple 3, relatif à un exemple de réponse ROC du serveur, est le suivant: MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_Boundary; type=text/xml Content-Description: Server Response with SwA.

- -MIME_Boundary Content-Type: text/xml; charset=UTF-8 ContentTransfer-Encoding: 8bit Content-Id: <mymainpart@example.org> < ?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3. org/2003/05/soap-envelope" xmins:xop="http://www.w3. org/2003/12/xop/include" xmins:xmlmime="http://www.w3. org/2004/06/xmlmime" xmnls:imageBrowsing="http://www.example. org/imageBrowsing" > <soap:Body> <imageBrowsing:SetImage image="http://www.example.org/myimage.jpg"> <data-stream href="cid:thismessage:/part0.jpip-stream"/> < /imageBrowsing:Setlmage> </soap:Body> </soap:Envelope> - MIME_Boundary Content-Type: image/jpp-Stream Content-Transfer-Encoding: 8bit Content-ID: <thismessage:/part0.jpip-stream> binary data here..

- -MIME_Boundary-- Dans cet exemple, un pointeur est donné (signalé par l'attribut href du type data-stream ) pour retrouver les données binaires envoyées en réponse à la requête.

Lors de l'étape E5, le message SOAP reçu (réponse ROC) est désérialisé, c'est-à-dire que les données sont extraites du message SOAP. On obtient alors l'URI de l'image et les données binaires (différent de JPIP, si le format de retour souhaité n'est pas JPEG2000) correspondantes à la requête.

Le type des données est indiqué par le champ Content-Type de la partie MIME du message.

Lors de l'étape E6, les données binaires ROC sont décodées.

Lors de l'étape E7, les données décodées sont affichées sur le dispositif client.

Lors de l'étape E8, une nouvelle requête de l'utilisateur REQ peut être détectée. Si c'est le cas, on boucle sur l'étape El, sinon on passe à l'étape E9, qui est la fin du traitement.

La structure au niveau du dispositif client 100, pour une application 306, peut donc être schématisée par la figure 4. Un niveau transport 300 est nécessaire pour l'échange des données (HTTP, SMTP, FTP.. .), ainsi qu'un niveau client SOAP 302 pour la génération et l'interprétation des messages. Le niveau client JPIP 304 n'est pas indispensable, du fait de la possibilité de spécifier un type de retour pour le décodage des données. L'invention tire parti des outils de visualisation installés sur le client. Il est à noter cependant, que le mode de fonctionnement optimal est obtenu pour un client disposant de ce niveau client JPIP 304 et d'un décodeur JPEG2000. Le niveau client SOAP 302 doit supporter les fonctionnalités SwA ou MTOM, selon que l'on travaille en SOAPI.1 /WSDL1.1 ou SOAP1.2/WSDL2.0.

Les étapes mises en oeuvre par le dispositif serveur 102 sont 25 décrites en référence à la figure 5.

Lors de l'étape E11, une requête client REQ est reçue. Lors de l'étape E12, cette requête (selon le format de l'exemple 2) est désérialisée, c'est-à-dire que les éléments du message sont analysés et les paramètres correspondants sont obtenus, essentiellement l'opération à invoquer (Getlmage ou EnhanceImage) avec ses paramètres éventuels. L'étape E13 détermine si le message est composé d'un élément Getzmage. Si oui, on passe à l'étape E14, sinon à l'étape E19.

L'étape E14 consiste en l'obtention de l'image identifiée dans la requête par une URI classique. L'étape E15 détermine, selon le type de l'image (élément imageBrowsing:type dans l'exemple 2), si une étape de transcodage est nécessaire. Si oui (c'est-à-dire si l'image n'est pas de type JPEG2000), on passe à l'étape E16, sinon on passe directement à l'étape E20. Le transcodage est jugé nécessaire, si l'image ne se trouve pas dans un format scalable permettant de servir à partir d'un même fichier toutes les requêtes possibles en terme de résolution, qualité, débit, zone... Dans notre cas et selon un mode préféré, le format scalable choisi est le format JPEG2000.

L'étape E16 consiste en la découverte d'un service Web permettant de transcoder l'image obtenue en image JPEG2000. La découverte de service peut prendre en compte la possibilité de composer les services Web pour obtenir le résultat souhaité. Par exemple, si l'image est au format PNG ( Portable Network Graphics ) et qu'aucun service Web ne propose de transcodage PNG vers JPEG2000, il est possible de composer un premier service Web de décodage d'images PNG vers PPM, avec un service Web d'encodage d'images PPM au format JPEG2000. On obtient donc un service Web évolutif, pouvant s'adapter à une multitude de formats.

Lors de l'étape E17, le ou les services Web sélectionné(s) sont 20 invoqués pour obtenir l'image JPEG2000.

Suite à l'étape E13, l'étape E18 détermine si le message est composé d'un élément EnhanceImage. Si l'élément n'est pas présent, le message ne peut être traité par le dispositif serveur 102 et on passe à l'étape E19, qui est la génération et l'envoi d'un message d'erreur, puis à l'étape E22, c'est-à-dire la fin du traitement. Si l'élément Enhancelmage est présent, cela signifie qu'une première requête client REQ sur la même image a déjà été effectuée et l'image de la requête est donc déjà présente au niveau du dispositif serveur 102 au format JPEG2000. On passe donc directement à l'étape E20.

Lors de l'étape E20 les données binaires correspondant aux préférences du client (résolution, débit final de l'image, etc...) sont extraites du fichier transcodé par un serveur JPIP présent sur le serveur. Cette étape peut comporter également un transcodage de JPEG2000 vers le type de retour souhaité, si celui-ci n'est pas, selon un mode préféré, JPEG2000.

Lors de l'étape E21 le message ROC de type SOAP contenant les données binaires est généré et envoyé à destination du dispositif client selon un mode préféré de l'invention suivant le format de l'exemple 3. Le format de réponse est basé sur le format XOP. Ce format permet de mixer à la fois des structures XML et des données binaires dans un message de réponse.

L'étape E22 est la fin du traitement.

Des variantes de l'invention peuvent être mises en oeuvre.

Par exemple, le dispositif serveur 102 peut implémenter un ou plusieurs transcodages pour les formats d'images les plus courants. La découverte et l'invocation de services Web n'est alors nécessaire que si le transcodage du type d'image n'est pas supporté par le dispositif serveur 102. On peut encore imaginer que le dispositif serveur 102 n'implémente pas la découverte de services et utilise seulement ses propres transcodeurs.

Dans une autre variante, le dispositif serveur 102 peut ne pas implémenter le dispositif serveur JPIP, mais seulement traduire les préférences du dispositif client contenues dans la requête SOAP en une requête JPIP, puis envoyer cette requête sur un dispositif serveur JPIP distant, en lui indiquant l'URI de l'image transcodée sur le serveur.

La structure au niveau du dispositif serveur 102 peut être schématisée par la figure 6, pour une application 410. Un niveau transport 400 est nécessaire pour l'échange des données (HTTP, SMTP, FTP.. .), ainsi qu'un niveau serveur SOAP 402 pour la génération et l'interprétation des messages SOAP et un niveau serveur JPIP 404 pour la génération des données d'images.

Pour une meilleure optimisation de la bande passante, le message transmis par le dispositif serveur Web peut utiliser les fonctionnalités d'attachement de SOAP, c'est-à-dire SwA (http:l/www.w3.orgITR/SOAPattachments) pour SOAP 1.1 et MTOM (http://www.w3.orq/TR/2004/CR- soapl2mtom-20040826/) pour SOAP 1.2.

Ainsi, le volume de données transféré est réellement optimisé, d'une part en utilisant le protocole JPIP et, d'autre part, en utilisant les fonctionnalités d'attachement de SOAP. Le serveur doit aussi contenir un système de découverte de services Web 405 et doit pouvoir interpréter les fichiers WSDL 406, invoquer les services Web correspondants et gérer la composition de services 407.

Claims (15)

REVENDICATIONS

1. Procédé de transfert de données numériques entre un dispositif client (100) et un dispositif serveur (102) sur un réseau de communication (104), ledit procédé étant mis en oeuvre au sein dudit dispositif serveur (102), caractérisé en ce qu'il comprend les étapes suivantes: i) en provenance du dispositif client (100), recevoir une requête (REQ) de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi, selon un format client et selon des préférences relatives à au moins la résolution et/ou la qualité numérique de l'objet; ii) obtenir dans le réseau de communication (104) une représentation de l'objet demandé ; iii) vérifier si la représentation de l'objet ainsi obtenu correspond à un format prédéterminé de type progressif; iv) en cas de vérification négative, obtenir dans le réseau de communication (104) une forme transcodée de l'objet (DOT) comprenant la résolution et la qualité les plus élevées de l'objet; v) extraire l'objet ou la partie de l'objet numérique conforme aux préférences spécifiées dans la requête (REQ) à partir de la forme transcodée ainsi obtenue (ROT) ; et vi) envoyer à destination du dispositif client (100) l'objet ou la partie de l'objet numérique ainsi extrait (ROC), au format client.

2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte une étape préalable d'envoi au dispositif client (100) d'un fichier de description d'un service disponible sur le dispositif serveur (102), la requête (REQ) provenant du dispositif client (100) étant alors conforme audit fichier de

description de service.

3. Procédé selon la revendication 1 ou 2, dans lequel la requête client comprend l'URI de l'objet demandé.

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce 5 que le format prédéterminé de type progressif est le format de type JPEG2000.

5. Procédé selon la revendication 4, caractérisé en ce que le format client est le format de type JPEG2000.

6. Procédé selon la revendication 4, caractérisé en ce que le format client est un format d'images appartenant au groupe formé par JPEG, TIFF, BMP, GIF, PNG ou analogue.

7. Procédé selon l'une des revendications 1 à 6, dans lequel les paramètres de la requête provenant du dispositif client sont définis par des structures de type XML échangées entre le dispositif client et le dispositif serveur par un protocole de transport de type SOAP.

8. Procédé selon l'une des revendications précédentes, dans lequel l'envoi à destination du dispositif client de l'objet ou de la partie de l'objet numérique, s'effectue par l'envoi d'un message comportant des structures de type XML et des données binaires, les données binaires étant formatées selon un format spécifique de type XOP.

9. Procédé selon l'une des revendications précédentes, dans lequel l'obtention dans le réseau de communication d'une forme transcodée de l'objet s'effectue en plusieurs étapes de transcodages successifs.

10. Procédé selon l'une des revendications précédentes, dans lequel la forme transcodée obtenue de l'objet est sauvegardée sur le dispositif serveur, de façon à en extraire des données conformes aux préférences spécifiées dans des requêtes ultérieures.

11. Dispositif serveur pour le transfert de données numériques avec un dispositif client (100) sur un réseau de communication (104), caractérisé en ce qu'il comprend au sein dudit dispositif serveur (102) : - des moyens de réception aptes, en provenance du dispositif client (100), à recevoir une requête (REQ) de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi, selon un format client et selon des préférences relatives à au moins la résolution et/ou la qualité numérique de l'objet; - des moyens pour obtenir dans le réseau de communication (104) une représentation de l'objet demandé ; - des moyens de vérification pour vérifier si la représentation de l'objet ainsi obtenu correspond à un format prédéterminé de type progressif; - des moyens de traitement pour, en cas de vérification négative, obtenir dans le réseau de communication (104) une forme transcodée de l'objet (DOT) comprenant la résolution et la qualité les plus élevées de l'objet; - des moyens d'extraction pour extraire l'objet ou la partie de l'objet numérique conforme aux préférences spécifiées dans la requête (REQ) à partir de la forme transcodée ainsi obtenue (ROT) ; et - des moyens de communication pour envoyer à destination du dispositif client 100 l'objet ou la partie de l'objet numérique ainsi extrait (ROC), au format client.

12. Dispositif de transfert de données numériques entre un dispositif client (100) et un dispositif serveur (102) sur un réseau de communication (104), caractérisé en ce qu'il comprend un dispositif serveur adapté pour la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 10.

13. Support d'informations lisible par un système informatique, 30 caractérisé en ce qu'il comporte des instructions d'un programme informatique permettant la mise en oeuvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 10, lorsque ce programme est chargé et exécuté par un système informatique.

14. Support d'informations amovible, partiellement ou totalement, lisible par un système informatique, caractérisé en ce qu'il comporte des instructions d'un programme informatique permettant la mise en oeuvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 10, lorsque ce programme est chargé et exécuté par un système informatique.

15. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 10, lorsque ce programme est chargé et exécuté par un système informatique.