Servicios sin estado

por

Principio SOA 6 – Los Servicios minimizan el consumo de recursos, aplazando la gestion de la informacion sobre el estado cuando sea necesario

 

 

Servicios sin estado.

Turno para el sexto principio SOA: Servicios sin estado.

 

Los servicios SOA no deben guardar información alguna sobre datos de sesión, ni sobre eventos previos, ni sobre resultados de servicios invocados previamente. Es decir, los servicios no deben tener estado.

 

Los servicios deben ofrecer el comportamiento que corresponda a la entrada recibida y a las reglas de negocio implicadas, únicamente.

 

En mi opinión este servicio guarda de nuevo una relación muy estrecha con otros principios SOA. Por ejemplo, el de autonomía, el de reusabilidad y el de bajo acoplamiento.

 

No es posible mantener un nivel de autonomía adecuado si la ejecución del servicio necesita de información de estado para dar un resultado. Por el mismo motivo, el índice de reutilización también se ve seriamente mermado ya que el servicio requiere de un cierto contexto de estados que tiene previstos en su diseño. Y en cuanto hablamos de dependencia estamos hablando de algún nivel de acoplamiento, claramente desaconsejable.

 

Por lo tanto, tan solo por la existencia de estos otros principios SOA este principio ya está justificado.

 

Pero no solo por eso.

 

La necesidad de que el servicio no guarde estado es más evidente que todo eso en un enfoque orientado por eventos de negocio, que atiende a procesos de negocio y que persigue el patrón asíncrono de proveedores y consumidores de eventos. ¿Qué necesidad hay de recoger ninguna información sobre eventos previos o sesión, ni nada parecido, cuando es el propio negocio quien va dictando los flujos de información a través del catálogo de servicios desplegado en los ESB?.

 

En mi opinión este principio no tiene mucho sentido en un enfoque EDA. Sí lo tendría en un patrón de consulta – respuesta, con mensajería síncrona. En este contexto un sistema espera la respuesta de otro, y por tanto el acoplamiento transaccional está presente. Las sesiones de usuario abarcan más allá de la frontera de su propia aplicación, y el dedicar más o menos recursos a mantener el estado o cierta información de cada llamada puede resultar determinante para el rendimiento del servicio, y por extensión (y acoplamiento), de la propia transacción.

 

Pero en una arquitectura conducida por eventos no debe surgir esta necesidad.

 

Los sistemas identificados en los modelados BPMN como proveedores de eventos de negocio se limitan a disparar dichos eventos al ESB, y terminan su cometido.

 

Los sistemas identificados como interesados en conocer dicho evento, o ciertos eventos derivados de él, simplemente están suscritos en el ESB a ciertos servicios que se ejecutan como consecuencia de la orquestación del evento recibido. Estos consumidores se limitan a recibir la información a la que están suscritos, y nada más.

 

No necesitan (ni deben) conocer quién disparó qué evento ni cuándo ni dónde.

 

Otro aspecto interesante que justifica la importancia de este principio, se refiere a otro de los principios SOA que aún no hemos comentado: la composición de servicios. Si queremos que nuestros servicios puedan combinarse y componer otros servicios de orden jerárquico superior, es imprescindible que los servicios no tengan estado.

 

Es una cuestión de autonomía y desacoplamiento.

 

Es una cuestión de reusabilidad.

 

Es una cuestión de sentido común.

 

Te puede interesar

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This