Le World Wide Web Consortium (W3C), chargé de la définition
et de la promotion des standards du Web, a annoncé en janvier
2005 trois nouvelles recommandations d'importance pour le
monde des services Web : XML-binary Optimized Packaging (XOP),
SOAP Message Transmission Optimization Mechanism (MOTM) et
Resource Representation SOAP Header Block. Ensemble,
ces recommandations visent à améliorer les performances de
services Web en standardisant les transmissions de données
binaires volumineuses. Nous allons voir en quoi par l'examen de
l'apport de la principale, XOP.
Le problème lors de l'échange de
données binaires par XML
Cette spécification, pour résumer, définit une convention
d'encodage d'éléments binaires, permettant de sortir les données
binaires d'un message de type XML Infoset et de les placer
dans un autre segment au moyen de MIME-Multipart.
Les données binaires sont difficiles à transporter via XML,
car ces fichiers utilisent un jeu de caractères plus large
que celui défini pour XML. L'une des solutions est de placer
le fichier en question sur un serveur, et de lier le fichier
à partir du conteneur SOAP (à la manière d'une image affichée
en HTML, mais extérieure au fichier) :
<?xml version='1.0' ?>
<soap:Envelope xmlns:soap=" http://www.w3.org/2003/05/soap-envelope
">
<soap:Body>
<Person name="Xavier">
<Picture>http://www.example.biz/heroes/xavier.jpg</Picture>
</Person>
</soap:Body>
</soap:Envelope>
Cette méthode n'est cependant efficace qu'avec les données
statiques et définitives (dans leur contenu comme dans leur
emplacement). C'est la sérialisation en base 64 qui est donc
utilisée aujourd'hui pour inclure des données binaires à un
flux de données SOAP :
<?xml version='1.0' ?>
<soap:Envelope xmlns:soap=" http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<Person name="Xavier">
<Picture>Y2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=</Picture>
</Person>
</soap:Body>
</soap:Envelope>
Cependant,
un fichier décrit en base64 peut prendre jusqu'à 33% de place
en plus que le fichier original, sans compter que le système
doit l'encoder/le décoder à chaque échange. Là
encore, la solution n'est guère efficace pour les échanges
volumineux
Une solution a été trouvé avec SOAP Message with
Attachement (SwA), ajoutant une paquetage MIME/Multipart au
message XML, mais celle-ci ne résolvait pas tous les problèmes,
notamment le fait que cela rendait le message inutilisable
par les outils XML existant (Xpatch, Xquery, XSLT
), ainsi
que certains problèmes d'interopérabilité.
La solution apportée par XOP
XML-Binary Optimized Packaging vise donc à résoudre les problèmes
liés à l'échange de données binaires via XML. Pour ce faire,
cette spécification propose une manière alternative de sérialiser
du XML, tout élément indiqué comme étant en base64 (donc contenant
des documents binaires) étant encodé en tant qu'attachement
MIME.
La différence avec SwA réside dans le fait que le lien entre
le fichier et les données binaires est différent : SwA laissait
l'application s'en occuper, XOP prend ce lien en compte directement.
Le fait de pouvoir expédier les données binaires via MIME
signifie qu'il ne serait plus nécessaire de réaliser un encode
en base 64, et que ces données profitent des en-têtes MIME
existantes. Ainsi, plutôt qu'une révolution, XOP est une évolution
de SwA dans la bonne direction.
Les
exemples fournis dans la spécification permettent de se
faire une idée de l'évolution des données lors du passage
d'un format à l'autre :
<soap:Envelope
xmlns:soap='http://www.w3.org/2003/05/soap-envelope' xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<soap:Body>
<m:data xmlns:m='http://example.org/stuff'>
<m:photo xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
<m:sig xmlmime:contentType='application/pkcs7-signature'>Faa7vROi2VQ=</m:sig>
</m:data>
</soap:Body>
</soap:Envelope>
...devient...
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
type="application/xop+xml";
start="<mymessage.xml@example.org>";
startinfo="application/soap+xml; action=\"ProcessData\""
Content-Description: A SOAP message with my pic and sig in
it
--MIME_boundary
Content-Type: application/xop+xml;
charset=UTF-8;
type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>
<soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<soap:Body>
<m:data xmlns:m='http://example.org/stuff'>
<m:photo xmlmime:contentType='image/png'><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/me.png'/></m:photo>
<m:sig xmlmime:contentType='application/pkcs7-signature'><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/my.hsh'/></m:sig>
</m:data>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>
// binary octets for png
--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>
// binary octets for signature
--MIME_boundary--
Certes, au premier abord, une quarantaine de lignes se sont
ajoutées au message SOAP original, ce qui semble aller à contre-courant
du gain de place annoncé par la méthode. Seulement, il faut
prendre en compte que les données binaires ne sont plus encodées
en base64 (comme c'est le cas dans le message original), mais
directement incluses dans la partie MIME du message. De là
vient le gain de place (invisible dans l'exemple), ainsi que
le peu de charge imposée au processeur pour l'étape d'encodage/décodage
|
Forum |
|
Réagissez
dans les forums
de JDN Développeurs
|
Cette méthode apporte un gain de place, et donc un gain en
performances lors des transferts. Les développeurs disposent
maintenant d'une méthode standard et basée sur XML pour créer
des messages SOAP incluant des données binaires.
|