Conversión de SOAP a JSON, utilizando Oracle Service Bus 11g

Algo que ya se volvió muy común es tener la necesidad de hacer conversiones de formatos entre SOAP y JSON/REST. Esto, dada la necesidad de disminuir un poco lo pesado que puede ser transportar mensajes a través del ensobretado de SOAP.

Sobre todo en escenarios de aplicaciones móviles que consumen Web Services, algo muy normal que recomiendan los desarrolladores y arquitectos de dichas plataformas, es que los Web Services sean presentados a través de JSON/REST.

Esto no es ningún reto, ni tampoco es un tema del que haya poca información publicada en la red. Al contrario, hay muchos artículos y software que hacen esa transformación.

En esencia, buscamos lo siguiente:

(Este diagrama lo tomé de un blog que habla de cómo realizar esta conversión utilizando un software libre llamado Membrane, pero la imagen me gustó por su simpleza y claridad.)

Este escenario es fácilmente reproducible utilizando Oracle Service Bus 11g. La intención de esta entrada es mostrarles cómo se puede llevar a cabo, y que tomen ideas para poder mejorar dicha conversión.

Oracle, en su sitio de ejemplos, ofrece un par de opciones para entender cómo el OSB realiza esta tarea. Los pueden encontrar aquí: http://java.net/projects/oraclesoasuite11g/pages/OSB

En el sitio de ejemplos, encontrarás un par que sirven como referencia para realizar la conversión:

1.  osb-205-SimpleREST
This sample shows how to use the Oracle Service Bus to create a REST service.

2. osb-206-JSONREST
This sample shows how to use the Oracle Service Bus to create a REST service that can accept and respond with JSON (JavaScript Object Notation) payloads.

El ejemplo osb-206 depende del osb-205, y es el  mas completo. El primero te ayudará, pero realmente no resuelve todo el escenario.

El osb-206 contiene una librería muy simple que te ayudará a transformar un mensaje JSON en XML, y un XML en JSON. Esto es muy útil y muy práctico.

A continuación se describen algunos pasos para llevar a cabo la traducción:

1. Lo primero a entender es que el OSB permite crear Business Services/Proxy Services de mensajería, y que a su vez no tengan un formato de entrada (body) en particular. Es decir, no dependen de que el mensaje venga ensobretado en SOAP. Por lo que esta opción es la ideal , pues el mensaje JSON se transportará por HTTP, pero su formato es texto. Por ejemplo:

Este Proxy se generó utilizando la opción de Messaging Service, y resaltando que el Request Message Type y el Response Message Type, no es mas que Texto.

Si dejáramos el Proxy así, sin message flow, podríamos enviarle cualquier texto, y nos regresaría lo mismo.

Evidentemente no queremos eso. Lo que buscamos es recibir un mensaje con formato JSON, posteriormente convertirolo en XML , y transmitirlo a un punto final que procesará la información, nos contestará en XML, y el Proxy convertirá en JSON para el consumidor final.

2. El Message flow luce de la siguiente manera:

Realmente es simple, solo hay un par de stages, que justamente tienen la lógica para transformar el mensaje de entrada para enrutarlo al punto final. Y en el Pipeline de salida, convertir el XML en JSON.

Este message flow es mejorable. Habrá quien diga: “y si pones un route , en vez el Service Call out adentro del stage”. Bien eso es válido, esto es solo un ejemplo, y sirve como base para desplegarlo.

3. Si vemos el stage_Json2xml, tendremos lo siguiente:

El primer paso es asignar el text() de la variable body, en un string llamado strMsgJSON.

Posteriormente, hacemos un Java Callout , que recibirá la variable strMsgJSON, así como un prefijo (dad), el nombre del Servicio, y el namespace.

Esto no es mas que una extensión de la utilería que tomamos del ejemplo 206, provisto por Oracle.

En pocas palabras, lo que estamos haciendo es crear un XML a partir del mensaje JSON que venía como entrada. Este XML saldrá de la utilería en formato de String, y estará almacenado en strMsgXML.

Los dos siguientes pasos pueden ser estructurados de otra manera, pero en este ejemplo se ha decido hacerlo de esta manera:

a) Primero lo vamos a transformar a una estructura XML, si bien ya tenemos el mensaje, está representado como String. Por lo que usamos la siguiente expresión:

fn-bea:inlinedXML($strMsgXML)

b) El resultado de la expresión previa, lo almacenaremos en la variable xmlMsgPre. Esta variable la calificaremos  con el formato que el punto final espera, y es lo que hacemos en el último assign, para finalmente almacenar el mensaje en xmlMsg

4. El último paso en el stage del request Pipeline, es:

Hacemos un Service Callout a un Servicio que originalmente fue declarado como un Business Service. El Business Service se declaró así:

Es una definición muy común. Es un Servicio basado en un WSDL.

Por lo que este paso ,  enviará el mensaje ya transformado a este Business Service. Y su respuesta , la almacenaremos en la variable xmlMsgOut.

5. Hasta aquí, hemos resuelto la mitad del problema. Ya tenemos forma de recibir un JSON, transformarlo en XML y enrutarlo a un Web Service. Por lo que los siguiente pasos son para la salida

Aquí lo que hacemos es hacer una transformación de la variable xmlMsgOut a un formato en particular que queremos contestar en nuestro JSON. Pero como es un XML, primero lo formateamos en mismo XML.

Posteriormente lo convertimos en String, y lo dejamos en strMsgXMLRespuesta. Esto lo hacemos, para volver a usar la utilería provista por el ejemplo 206 de Oracle, para que ese String nos los convierta en JSON. Solo que en este ejemplo, se ha extendido un poco dicha librería, para pasarle mas parámetros. Como el prefijo (dad), y el elemento padre del mensaje.

Finalmente, esto nos lo dejará en una variable llamada strMsgJSONRespuesta, que es lo que vamos a poner en la variable body, que finalmente contestaremos al cliente final.

Con esto, se lograría poder transformar un mensaje JSON a un XML/SOAP, poder cambiar su formato, y regresar una respuesta en JSON.