El infierno

Como sabemos, SOA se caracteriza por poder implementar una funcionalidad de negocio mediante la composición de varios servicios (pueden ser decenas)   perfectamente desacoplados.

Esto nos da una flexibilidad máxima a la hora de crear nuevas funcionalidades de negocio al sustituir la programación tradicional de bajo nivel por la “unión” de varios servicios ya existentes.

Esto está muy bien, pero por desgracia, las cosas no son siempre (casi nunca) de color de rosa y un ejemplo claro es cuando tenemos un error en la ejecución. Este error puede deberse a las más diversas causas: a un error de programación, también a problemas con el Middleware, con el hardware y, hay quien dice, a los duendes que habitan los CPD…

Independientemente de la causa del error, hay que arreglarlo, o al menos, restaurar el servicio para que el usuario pueda seguir trabajando. Pues bien, aunque parezca mentira, el primer y muy arduo trabajo para arreglar un error es… encontrarlo. ¿Qué es lo que falla? ¿Cuál es el servicio o componente software que está fallando?… Y es que por experiencia, puedo decir que muchas veces es más difícil encontrar donde está el fallo que arreglarlo.

Evidentemente en producción no tenemos depurador para encontrar el error, e incluso, algunas veces, ni siquiera podemos reproducirlo. Sólo nos queda el mejor amigo de los cazadores de errores, los logs.

Pero los logs tienen un problema: sólo sacan aquellas trazas que hayamos puesto. A veces demasiado pocas, y muchas veces, demasiadas. Sólo son un montón de basura que no ofrecen nada útil. Pues bien, la mala noticia es que en SOA la localización de un error es mucho peor en una aplicación tradicional. 

Si tenemos una funcionalidad típica, como el alta de un producto, podemos pensar por ejemplo que desde la pantalla hasta la persistencia en base de datos, podemos pasar por 5 o 6 servicios diferentes, dependiendo de los parámetros de entrada, del flujo definido, o incluso de la hora y fecha en la que se ejecute, de quien sea el cliente, de qué tipo de producto se trate, etc. etc.

logs

Normalmente, cada servicio tendrá su propio fichero de logs (también es posible que el fichero de logs esté a nivel de aplicación web en la que se ejecutan los servicios). Si tenemos 5 servicios y cada uno de estos servicios se ejecuta en 4 nodos (para tener alta disponibilidad) y hay un fichero por nodo, tendremos que lidiar con 20 ficheros de logs. Si a eso añadimos los logs de la aplicación de frontend (también por 4) tendremos 24 ficheros de trazas que examinar para encontrar el problema.

¿que solución tenemos?

Creo que lo primero que tenemos que solucionar es la correlación entre los 24 ficheros de log (de este caso) con la invocación al servicio. No olvidemos que todo esto se ha desencadenado, por ejemplo, con la simple pulsación del usuario en un botón en una pantalla. Queremos saber que trazas se corresponden con esta única invocación.

Evidentemente no podemos coger los n fichero y filtrar por la misma hora para aislar aquellas trazas porque habrá varias simultáneas que superpongan. Lo primero que tenemos que tener es un identificador único de esa invocación en todos los ficheros de logs. Una manera de hacer esto es generar este identificador en el primer servicio por el que se pase (o el mismo frontend) e ir pasándolo como parte de la invocación de servicio en servicio. De esta manera, podremos grabarlo con el resto de la traza (además de la hora, el user name, etc.)

¿y como mandamos el identificador único a través de todos los servicios?

Este dato no se puede considerar como de negocio. Así que lo más elegante sería pasarlo como parámetro de control o técnico en la cabecera del mensaje (no el body). Y para ello, con los mensajes SOAP, lo mejor sería crear un SOAPHandler, un pequeño programa que se ejecuta cuando se invoca a un servicio (de salida) y cuando se entra en un servicio (de entrada).

Aquí tenéis un ejemplo de Oracle que hace algo parecido a lo que estoy diciendo aquí mediante los handlers.

En definitiva, si estás ahora abordando un proyecto de SOA en tu empresa, no te olvides de las trazas. Y por supuesto, que sea posible seguir la misma petición a través de todos los servicios por los que pase.

Cuando empiecen aparecer los errores, la cuestión  no es si aparecerán si no cuando lo harán, tener este identificador de la petición te ahorrará  horas y días de darte contra las paredes.