JAXB 2.0 : Vista Rápida (II)

(Imagen: Rembrandt - El rapto de Europa)

Binding run-time framework
Es este framework el que implementa las operaciones de marshal y unmarshal.

Marshaling es el proceso de convertir instancias de clases anotadas en una representación XML (como un documento XML en un archivo o un DOM). Por otro lado, unmarshalling es el proceso de convertir una representación XML en un árbol de objetos.

Veamos como funciona este framework al invocar un Web Service:

1. La aplicación recibe un mensaje SOAP en el endpoint desplegado
2. JAX-WS prepara una instancia del contexto del mensaje (javax.xml.ws.handler.soap.SOAPMessageContext), que incluye la representación SAAJ (SOAP with Attachments API for Java) del mensaje.
3. JAX-WS invoca a los handlers.
4. Después que los handlers terminan, el runtime de JAXB ejecuta el unmarshal de los contenidos del mensaje SOAP dentro de un bean request.
5. Este bean request, construido por el runtime de JAXB, contiene los objetos Java que son pasados como parámetros al método Java que implementa el Web Service. JAX-WS invoca al método usando estos parámetros.
6. JAX-WS obtiene un objeto Java como resultado de la invocación del método, y lo utiliza para crear una instancia de un bean response.
7. JAXB ejecuta el marshalling del bean response.
8. Como en el paso 2, JAX-WS actualiza el contexto del mensaje para incluir la representación SAAJ del response.
9. JAX-WS invoca a los handlers de response.
10. JAX-WS envía el mensaje response a través de un protocolo de transporte.

Entonces, la deseralización ocurre en dos etapas. Un request SOAP comienza con su formato original (en el gráfico, un paquete MIME). La primera etapa convierte este formato a una representación XML y provee acceso SAAJ. Es en esta forma que llega al handler. La segunda etapa aplica unmarshalling a la representación XML y la convierte en objetos Java. Estos objetos se envían Web Service como parámetros para la invocación de métodos.



Validación:
Para implementar un Web Service, es indispensable controlar como se va a tratar XML inválido, respecto al esquema WSDL/XML que define al Web Service.

A diferencia de JAXB 1.0, el unmarshalling de XML inválido es permitido por JAXB 2.0 (por defecto, pero puede deshabilitarse). Si la validación está activada, el comportamiento por defecto es lanzar una excepción al primer error.

Portabilidad
La portabilidad es lograda mediante las anotaciones para mapping. El marshaller de cualquier implementación JAXB debe ser capaz de serializar una clase anotada de JAXB a una instancia de su esquema XML objetivo. Así, el unmarshaller debe ser capaz de deserializar una inastancia de un esquema a una instancia de una clase anotada JAXB.

Esto implica que uno puede desplegar un Web Service construido de clases anotadas JAXB cualquier plataforma JAXB 2.0 (como SAP Netweaver, JBoss, Glassfish) sin tener que recompilar el esquema y/o reestructurar el Web Service para usar clases de implementación propias del entorno.

Marshal event callback
Los callbacks permiten procesamiento específico de nuestra aplicación al momento de serializar. Estos procesos pueden ocurrir antes de serializar o después de la serialización. Esto es bastante útil cuando queremos asignar valores a propiedades fuera del proceso de serialización.

Binding parcial
La clase javax.xml.bind.Binder soporta el binding parcial de un documento XML. Esto nos permite crear un binding JAXB de una cabecera SOAP sin procesar el cuerpo.

Binary Data Encoding
El modelo de programación JWS soporta la optimización de la transmisión de data binaria dentro de mensajes SOAP. Esto implica codificar la data binaria (como un archivo de imagen como xsd:base64Binary), sacarla del sobre SOAP, adjuntar una versión comprimida al paquete MIME y colocar referencias a las partes codificadas en el sobre SOAP. JAXB nos brinda servicios que desempacan la data bianria antes del unmarshalling, y la empaquetan después del marshalling como parte de la serialización del mensaje SOAP. JAXB 2.0 soporta dos tipos de codificación de data binaria: MTOM/XOP y WSIAP.

MTOM es un estándar de la W3C y significa "SOAP Message Transmission Optimization Mechanism". Describe un proceso estándar para sacar el contenido de la representación XML, comprimirlo, empaquetarlo como un adjunto MIME y reemplazarlo por una referencia en la representación XML. La codificación en paquetes utilizada como MTOM es XOP (XML-binary Optimized Packaging).

WSIAP por otro lado significa WS-I Attachments Profile Version 1.0. Sin embargo, aparentemente MTOM/XOP se está convirtiendo en un estándar de la industria.

JAXB utiliza anotaciones para espedificar que propiedades Java de la clase deber ser serializadas usando MTOM o WSIAP. Para MTOM, la anotación @XmlMimeType nos permite especificar como una propiedad Java binaria (como java.awt.Image) está ligada a un elemento de esquema decorado como un atributo xmime:content-Type.

Basado en el capítulo 2 de SOA Using Java Web Services de Mark D. Hansen