Hace unas semanas asistimos a la caída de la plataforma en la nube de Amazon. La semana pasada se cayó la plataforma estrella de Google para alojar blogs: blogger

Está claro que no debemos pensar en si se cae nuestra aplicación, debemos pensar en ¿cuando se caerá?. ¿Y cómo afectará entonces a nuestras aplicaciones de negocio orientadas a servicios?

Las aplicaciones SOA están basadas en servicios independientes, sin estado, con un interfaz claramente definido. El cliente envía un mensaje acorde con el descriptor del servicio y recibe otro como respuesta. Aquí tenemos una gran ventaja, ya que podemos guardar estos mensajes de entrada  (los mensajes SOAP) para volver a lanzarlos cuando el sistema vuelve a estar online.

Si a esto añadimos que podemos tener un elemento de infraestructura, el bus de servicios (ESB), que actúa de “concentrador” de mensajes. Es decir, punto único por el que todos los mensajes de nuestra aplicación de negocio pasan, podemos dotarle de la inteligencia necesaria para que monitorice el resultado de la invocación al backend (por ejemplo un timeout o error de falta de conexión con la base de datos) para guardarlos en una cola temporal desde donde podrán ser relanzados.

Por supuesto, no todos los mensajes pueden volver a ser relanzados. Hay algunas transacciones en las que la secuencia o la hora en la que son lanzadas es importante para la operación de negocio. Para distinguir estos servicios del resto se puede usar el registro de servicios, que con unos pocos metadatos, podemos establecer una política respecto a los errores: qué servicios pueden ser relanzados, cual es el número de reintentos máximo, qué hacer cuando todos los reintentos fallan, etc. etc.

Evidentemente, con este mecanismo, estamos aportando un gran valor al negocio. Podemos garantizar que ninguno de los servicios que se invocan se van a perder, aunque el sistema esté caído. Se cambia una ejecución fallida por una ejecución diferida.

Qué se necesita para lograr esto:

  1. una normativa estrictica en cuanto al tratamiento de errores en los servicios. Y un seguimiento escrupuloso de la misma
  2. un repositorio alternativo para guardar temporalmente los mensajes (cola, base de datos, sistema de ficheros)
  3. un mecanismo a automático o manual que se lance los mensajes

En conclusión:
nunca ha sido tan fácil ni ha estado tan en nuestra mano el poder disponer de un sistema de gestión de errores “inteligente”.  Un sistema en el que  cuando la aplicación principal se caiga, podamos seguir prestando servicio (aunque sea muy reducido) sin perder ninguna operación de negocio. Con la seguridad de que serán ejecutadas tan pronto se vuelva a levantar la aplicación.

En este caso, la orientación a servicios marca realmente la diferencia.

Share

Anuncios