La cara y la cruz de los servicios SOAP (WS-*) son su potencia y su complejidad. Podemos hacer prácticamente de todo, desde cifrar y firmar un servicio, garantizar su entrega, ejecutarlo en una transacción distribuida y también, por supuesto, enviar o recibir un documento binario anexado en el mensaje.

Pero por otra parte está su gran complejidad, desde simplemente entender cómo funciona, el uso de las herramientas asociadas y la implementación del servicio o del cliente que lo vaya a consumir. Y creo que esta complejidad viene derivada porque no se diseñó el estándar de WS desde un principio para hacer todas estas cosas. Si no, más bien, se fueron acumulando capas  y capas de especificaciones de la misma manera que se acumulan las capas de sedimento en una montaña.

Y la gestión de contenidos binarios va precisamente en esa línea, quizás porque SOAP se inventó como un protocolo de texto, al que se quiso añadir después, la gestión de binarios.

¿Qué hacemos con los binarios en SOAP?

De hecho, la primera solución consistió simplemente en convertir un binario en texto (en Base64) y añadirlo al mensaje simplemente como un campo más. Esto es bastante fácil de hacer, pero por desgracia, conlleva algunas desventajas serias. Por un lado que el mensaje ocupa más, entre un 20-40% más en base64 que en binario. Y este trabajo de transformación también se paga, con el uso de la CPU en los servidores, y también con la batería en los móviles.

Luego del base64 vino el SwA (SOAP with Attachments) que fue el que se incorporó al estándar WS-I Profile como forma oficial de gestionar los binarios en los servicios web. En su forma más común, sobre HTTP, esto se traduce en que se crea un mensaje multipart con varias secciones: en una va el texto (XML) del mensaje y en otra u otras los ficheros binarios que queramos incluir.

Este sería un mensaje para enviar una imagen tipo tiff.

swa

 

MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
        start="<claim061400a.xml@claiming-it.com>"
Content-Description: This is the optional message description.

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim061400a.xml@claiming-it.com>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/>
..
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>

...binary TIFF image...
--MIME_boundary--

En el body del mensaje, en lugar de incrustar todo el contenido del fichero, como se haría con Base64, lo que se hace es incluir un enlace a la parte del mensaje donde está realmente en el contenido binario (dentro de una sección del tipo MIME_boundary).

Después vino el MTOM

Después del SwA apareció una optimización en la forma de tratar los binarios, el MTOM (Message Transmission Optimization Mechanism) que además, menos mal, es compatible con el SwA.

Una vez que se define esto y se crea el servicio todavía no tenemos el trabajo hecho ni mucho menos. Nos queda ver cómo se las arreglan los clientes de estos servicios y aquí se nos puede abrir la caja de los truenos porque, obviamente, no sabemos quién va a consumir nuestros servicios. De hecho, ahí consiste una de las gracias de los servicios servicios web, cualquiera puede consumirlos y ni siquiera tenemos que saber quién ni con qué tecnología.

SwA y MTOM son especificaciones muy veteranas y abundan en el mercado herramientas y productos que los soportan, pero nunca podemos estar seguros al 100%. Y por la ley de Murphy aplicada a los servicios web, seguro que la herramienta que necesitamos no lo va a soportar o es muy difícil hacerlo porque hay que lidiar con cosas como librerías obsoletas o con el cargador de clases del servidor de aplicaciones.

Así pues, veo dos conclusiones claras: por un lado, es muy complicado ir añadiendo características a algo que en un principio no fue pensado para ello (la historia de todos los días de los informáticos) y por otro lado, no hay que fiarse de los estándares. Están bien, pero a veces un estándar es menos estándar de lo que pensamos.

Anuncios