En esta oportunidad tocaré un punto importante que es el 'Control de TimeOut' aplicado en el desarrollo SOA, este tema rinde un papel muy importante ya que hace referencia al delimitante de tiempo aplicado a los BE (BackEnds).
(BE: "Hace referencia a toda Interface de comunicación reutilizada como: BD, WS, EJB, PLATAFORMA, etc, que no forma parte del desarrollo principal").
Explicándolo de una manera más detallada, cuando se desarrolla un servicio independientemente del tipo que sea: SOAP/REST o EJB, es importante que exista un 'Control de TimeOut' obligatoriamente con relación a todos los BE (Síncronos) que son parte del flujo del 'Servicio Principal'.
Resalto esto ya que en mi experiencia me he encontrado con todo tipo de servicios: Bien, Mal y Pésimamente construidos. Así mismo, en muchos de estos servicios mal construidos estaban usualmente enfocados en sus flujos a exponer una 'Lógica de Negocio', pero sin aplicar un control relacionado a los BE.
¿QUE IMPLICA QUE LOS BE, NO TENGAN TIMEOUT?.
El impacto es por ejemplo que ante un problema interno propio del BE, este demore más de lo normal incluso quedarse como se dice pegado y si no hay un 'Control TimeOut', el hilo de la ejecución se quedará ahí esperando hasta que el término de procesamiento del y eso está mal (ya que no puede durar eternamente).
El impacto va contra el tiempo de respuesta del 'Servicio Principal', el cual justamente como RNF (Requisito No Funcional), un servicio consumido debería cumplir con un tiempo de procesamiento máximo.
¿COMO SABER CUANTO TIEMPO DEBERÍA ASIGNAR?.
Así los servicios sean muy rápidos, el tiempo a aplicar se debe se estimar en segundos y es dependiendo el tamaño del flujo existente, así como de la cantidad de las iteraciones contra BE que se requiera. Pero analizando en si no es bueno que un servicio tenga internamente más de 10 BE dentro de su flujo, ya que si se tiene más lo mejor es segmentar en otro servicio. Sobre el tiempo se podría aplicar un tiempo máximo por BE entre 10 y 15 seg.
¿Y QUE HAY DE LOS REINTENTOS?.
Los reintentos son tratamientos que deben de ser considerados también para los BE, pero para los que analizando de alguna manera son inestables (se caen cada cierto tiempo), o también sus respuestas algunas veces demoran más de lo normal, etc. Los reintentos se debe activar ante alguna Exception de tipo Técnica de tipo: 'No Dispobilidad', 'Error en BE', 'TimeOut', etc.
En estos casos se recomienda aplicar un Máximo de Reintentos de 3 veces, luego de estos retornar el response con la falla. Así mismo, es importante considerar que el TimeOut debe ser es incremental, que por ejemplo ante cada reintento del mismo BE el TimeOut se debe duplicar:
Ejemplo:
- Reintento#1 => TimeOut => 5 seg.
- Reintento#2 => TimeOut => 5 seg.
- Reintento#3 => TimeOut => 5 seg.
Esto quiere decir que sí tenemos un 'Servicio Principal' que por ejemplo llama solo a 1 BE con 3 reintentos de 5 seg. La ‘aplicación consumidora’ debería considerar asignarle al consumir el: 'Servicio Principal', un mínimo de tiempo de: 16 seg.
¿Y QUE HAY DE LAS 'HUMAN INTERVENTIONS'?.
Lo conocido como 'Human Interventions’ son Políticas enfocadas a un control diferente (normalmente trabajadas de la mano con los 'Rententos'), por ejemplo para casos en que los servicios son de tipo Asíncronos y los flujos llaman a BE reutilizables. Así mismo, el manejo de 'Human Interventions’ normalmente son soportadas por servicios directamente relacionados a plataformas SOA de vendors como ORACLE / IBM.
Su aplicación se realiza con apoyo del negocio identificando los casos especiales con relación a BE que se requieren controlar de manera diferente. La política está enfoca a que ante alguna Exception de tipo Técnica como:
'No Dispobilidad', 'Error en BE', 'TimeOut', etc. El hilo del flujo se queda en un estado especial, hasta que un operario se conecte a la plataforma, identifique dicho estado, revise la excepción, mande a corregirla y luego de estabilizarla, procesa a desde donde se cayó manualmente relance el mensaje al BE y el hilo del flujo continúe.
Finalmente contra de la aplicación de 'Human Interventions', es justamente la necesidad de un operario, que producirá una demora considerable en el proceso, debido a ello su aplicación debe estar de la mano con la coordinación con el negocio.
Espero que este artículo les sirva para más adelante cuando se escuche la palabra Timeout se le considere con más seriedad de la que normalmente se le tiene.
