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.