XML-binary Optimized Packaging
La spécification XOP (XML-binary Optimized Packaging) a été normalisée par W3C (World Wide Web) le 25 janvier 2005. SOAP MTOM (Message Transmission Optimization Mechanism) utilise XOP dans le contexte de SOAP et MIME sur HTTP.
XML est couramment utilisé pour le transfert de données. XML est un format courant permettant d'échanger des documents syntaxiquement corrects car il s'agit d'un format de texte en clair, lisible et structuré. Par exemple, la messagerie SOAP dans les services web est basée sur XML (ou sur l'ensemble d'informations XML avec SOAP 1.2). Les utilisateurs veulent tirer parti des formats existants tels que PDF, GIF, JPEG et d'autres formats similaires, tout en utilisant un modèle XML. Le souhait d'intégrer XML à des formats de données déjà existants pose depuis longtemps un problème pour la communauté XML. Les utilisateurs veulent généralement tirer parti des conventions de marquage extensibles structurées de XML sans abandonner les formats de données existants qui ne respectent pas aisément la syntaxe XML 1.0.
A mesure que la messagerie SOAP dans les services web se généralise, l'étape suivante consiste à déterminer la façon dont les données non texte, telles que les images et les données de workflow, sont envoyées avec votre message. Par exemple, vous pouvez être amené à envoyer un document scanné au format .jpeg d'une application à l'autre. La question se pose si ces données peuvent être comprises entre les diverses applications.
Le principal avantage des services XML et web réside dans la possibilité d'utiliser des outils XML génériques pour gérer du contenu. La plupart des outils et normes XML permettant la description et la manipulation de XML (par exemple, les analyseurs syntaxiques, XPath, XQuery, XSLT, le chiffrement XML et la signature numérique, ainsi que le schéma XML) ne sont pas conçus pour gérer des données non texte, telles que les images. Ces outils XML ne gèrent pas du contenu non XML ; ils requièrent du texte. La façon dont les données non texte (également appelées données binaires) peuvent être intégrées ou rattachés à XML constitue un défi. En d'autres termes, une méthode permettant de rattacher un fichier binaire à un message SOAP est requise.
Le codage est la seule façon dont les données binaires peuvent entrer directement dans un monde XML. En général, vous pouvez incorporer des données binaires dans un document XML en les codant sous forme de texte au format Base 64. Base 64 est une sérialisation qui existe depuis un certain temps, qui peut être implémentée directement et qui garantit l'interopérabilité d'une plateforme à l'autre. Le type de données xsi:base64binary prend en charge cette sérialisation dans le schéma XML. Base 64 encode vos données binaires en une représentation textuelle qui peut se glisser dans un document XML. Base 64 prend vos données binaires et les convertit en une série de caractères ASCII en encodant trois octets à la fois. Dans la mesure où chaque octet est constitué de huit bits, représentés sous forme de quatre caractères imprimables dans la norme ASCII, il utilise 64 caractères ASCII pour représenter le binaire. Toutes les plateformes effectuer du décodage et du codage à l'aide de cette convention. Le code ASCII 6 bits est généralement pris en charge et il n'est pas nécessaire de traiter des caractères spéciaux. Cependant, il y a une incidence sur les performances pour les messages de plus grande taille.
Pour les applications qui nécessitent un traitement rapide, Base 64 risque de ne pas être la solution. Si vous voulez analyser, transformer, chiffrer, signer ou décrire ce type de contenu ou y faire un indexage, vous devez utiliser un autre mécanisme.
La première spécification d'association appelée SOAP with Attachments (SwA) a été développée. L'idée de base de SwA est que la partie message binaire (pièce jointe) est considérée comme étant une pièce jointe MIME (Multipurpose Internet Mail Extensions). MIME est une spécification couramment implémentée qui permet la mise en forme des pièces jointes de messages électroniques non ASCII. SwA spécifie que le corps SOAP peut contenir un référence à la partie message MIME (la pièce jointe) simplement à l'aide d'un URI. La partie binaire est rattachée par une référence.
- SwA manque de convivialité ou d'interopérabilité. L'infrastructure SOAP a été créée autour de l'enveloppe SOAP qui ne fonctionnait pas bien pour les pièces jointes. Une pièce jointe utilisant SwA signifie que deux modèles de données sont utilisés dans un seul message. Ces deux modèles de données ne sont pas compatibles avec la technologie XML existante.
- SwA ne gère pas le caractère composable de SOAP. En principe, les normes telles que WS-Security n'ont pas été écrites pour gérer les pièces jointes. WS-Security a besoin de traiter toutes les données qui doivent faire l'objet d'une signature numérique ou d'un chiffrement, en d'autres termes, toutes les données de la pièce jointe également. Cependant, s'il ne peut pas y accéder, il ne fonctionnera pas et la signature n'est pas valide.
En général, les utilisateurs souhaitent conserver en l'état leurs formats non XML existants, pour qu'ils soient traités sous forme de séquences opaques d'octets par l'infrastructure et les outils XML. Une telle approche permet aux formats répandus tels que .jpeg et .wav de cohabiter en paix avec XML. XOP permet d'utiliser de façon un peu plus réaliste les données codées en base64. A l'heure actuelle, XOP permet uniquement d'optimiser les données codées en base64.
L'utilisation de XOP signifie que des instances de données base64Binary de type XML, si elles sont activées, sont transportées à l'aide de pièces jointes MIME. Si XOP est en cours d'utilisation, l'implémentation peut les coder automatiquement. XOP gère le modèle de données du message XML car la pièce jointe est traitée sous forme de données codées en base64. Si une pile XML comprend le codage XOP, il n'est pas du tout nécessaire de modifier votre application. Par exemple, quand elle veut accéder à une image .jpeg, elle peut obtenir la valeur alphanumérique du contenu sous la forme d'une chaîne codée en base64.
XOP permet aux utilisateurs de réfléchir aux messages MIME dans le cadre d'un échange de données avec lequel ils sont à l'aise et qu'il utilisent déjà pour beaucoup d'autres données. Le format XOP utilise le message MIME à plusieurs parties qui permet d'incorporer les données binaires brutes dans un document XML sans avoir recours au codage base64.
Une spécification associée, MTOM (SOAP Message Transmission Optimization Method) définit ensuite la façon dont ce format est connecté à SOAP. Les normes XOP et MTOM doivent améliorer les performances de SOAP 1.2. Ensemble, XOP et MTOM fournissent la méthode préférée qui consiste à mélanger des données binaires avec des données texte XML. L'association de MTOM et XOP permet de sélectionner les parties du message qui doivent être envoyées par câble sous forme de données binaires, tout en gérant l'Infoset. Ces normes permettent le rattachement des données binaires hors de l'enveloppe SOAP, sous la forme d'une partie de message. Cependant, contrairement à SwA, les données sont traitées comme dans l'enveloppe SOAP, en d'autres termes, sous forme d'Infoset.
XOP définit un mécanisme de sérialisation pour l'ensemble d'informations XML à l'aide d'un contenu binaire qui est non seulement applicable au packaging SOAP et MIME mais aussi à tout ensemble d'informations XML et à tout mécanisme de packaging. D'autre part, XML n'est pas un mécanisme de packaging général satisfaisant.
Un package XOP est créé via le placement d'une sérialisation de l'Infoset XML dans un format de packaging extensible (tel que MIME). Il est à noter que XOP réutilise MIME pour le packaging réel par câble. Des parties sélectionnées de son contenu qui sont des données binaires base64 sont ensuite extraites et re-codées, ce qui signifie que les données sont décodées à partir de base64 et placées dans le package. Les emplacements de ces parties sélectionnées sont marqués dans le XML à l'aide d'un élément spécial relié aux données du package à l'aide d'URI.
Le moteur de traitement SOAP exécute un codage Base 64 temporaire des données binaires, juste avant que le message atteigne le câble. Ce codage temporaire permet au processeur SOAP de traiter les données Base 64, par exemple, pour permettre la signature WS des données et son insertion dans l'en-tête. Un décodage coûteux n'est pas nécessaire à l'autre extrémité ; le processus fonctionne aussi dans l'autre sens.
Des implémentations de MTOM et XOP sont disponibles dans Java™ (JAX-WS).
<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>
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>
// octets binaires pour png
--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>
// octets binaires pour la signature
--MIME_boundary--