Imagen vía El Cedazo

Una de las necesidades más importantes que tiene un área de T.I, es la definición de la arquitectura Batch. Sobre el Batch se puede discutir largo y tendido, de si se considera que el batch tradicional ya no tiene razón de ser, que si tiene que dejar de ser un batch masivo que compite con el online, para pasar de ser una ejecución de lógicas unitarias a cualquier hora del día etc. etc…

Sin embargo, esto no debe apartar nuestra atención de lo más obvio y básico. No solo de la arquitectura online vive el hombre, se necesita además definir cómo se construyen las tareas asíncronas (que pueden ser consideradas online o no) y también los procesos batch (aunque sea en su definición más pura de “desatendidos” o “no interactivos”).

El primero de los requisitos que tendremos seguramente es que en el batch se pueda reutilizar la lógica online. Si tenemos una lógica (recubierta con un servicio) que da de alta un cliente. ¿no se puede utilizar esta misma lógica o servicio para dar de alta 100.000 clientes? Si es así sólo haremos la misma lógica una sola vez.

Con esta premisa de reutilización de la lógica de negocio debemos tener en mente por lo tanto dos cosas cuando definimos la arquitectura online:

Acceso a datos

Históricamente uno de los problemas que tienen los procesos batch es el uso masivo de los datos. Por lo tanto tenemos que tener básicamente dos cosas en cuenta:

  1. El traslado de estos datos por la red. Cuanto más “largo” sea el camino entre la base de datos y la lógica más impacto tendrá en el rendimiento total del batch. En el mercado existen productos que se ocupan de esto como el Xtreme Scale de IBM. Una alternativa a esto sería simplemente poner la lógica de negocio lo más cerca posible de dónde están los datos, incluso ejecutar el programa batch en la misma máquina donde está la base de datos.
  2. Tratamiento de estos datos. En una lógica unitaria, por ejemplo generar un recibo para un cliente, seguramente haremos una validación del dni o identificador de este cliente. Esta validación, en este caso una consulta SQL contra la base de datos, estará pensada en el online para validar únicamente un cliente. Por lo tanto, si esta misma lógica se utiliza para procesar 100.000 recibos tendríamos otros tantos accesos a la base de datos únicamente para hacer esto, lo que obviamente representará un problema grave de rendimiento.

La solución a estos requisitos se puede conseguir dividiendo perfectamente dos capas dentro de la aplicación. Por un lado tendremos la lógica de negocio pura, que no se preocupa de leer o escribir los datos y la lógica de datos, que no sabe de negocio, y que se ocupa de leer y escribir en la base de datos. Si está perfectamente separado, es posible entonces, hacer una implementación de la lógica de datos para el batch (con optimizaciones en el acceso a datos) y cambiar este componente por configuración.
De esta manera, podríamos tener una implementación de este DAO para el online, valida un único DNI, y otra implementación que podría seleccionar por ejemplo 50.000 DNI y guardarlos en memoria para que no hiciese falta acceder a la base de datos.

Ejecución en todos los sitios

Lo normal, al menos hasta hora, es pensar en un servidor de aplicaciones como el contenedor donde se ejecuta la lógica online, sin embargo, cada vez más se piensa en él para ejecutar aquella lógica que tradicionalmente se hacia en batch. Básicamente por dos motivos: reutilizar la lógica online para el batch y en segundo lugar lograr la convivencia entre ambos, evitando las clásicas ventanas batch (donde se cierra el online y dejan todos los recursos para el batch). En un mundo web con disponibilidad 24/7 no es posible mantener este tipo de ventanas exclusivas.

Quiere esto decir que hay muchos escenarios donde es mejor ejecutar estás lógicas en un servidor de aplicaciones, pero también hay otras, por ejemplo en batch sencillos, donde no hacen falta estos recursos. O quizás, simplemente, para ahorrarnos las licencias de estos servidores, podemos ejecutarlo en un standalone.

El modo de ejecución dependerá de cada caso y debemos poder elegir uno u otro.

Invocación a la lógica de negocio en batch

En una arquitectura SOA, aunque no es obligatorio, la lógica de negocio está expuesta normalmente mediante servicios web. La definición de un batch intensivo que invoca a estos servicios web es uno de las grandes incógnitas que se dan en SOA. Obviamente la introducción de los web services, los servicios compuestos, registros de servicios, buses, etc. etc. añade un retardo o “delay” en la llamada que sería difícil de asumir para el caso de que se quieren procesar por ejemplo 15 millones de recibos para los clientes de un operador móvil.

Conclusiones

  1. La lógica de negocio debe poder ejecutarse en todos los sitios: servidor de aplicaciones, standalone, etc.
  2. La subcapa de acceso a datos debe de poder cambiarse fácilmente por una implementación que cumpla las exigentes necesidades de acceso a datos
  3. Por motivos de rendimiento, ejecutar directamente la lógica de negocio sin recubrir con web services
  4. La ejecución de las lógicas online y batch deben convivir sin competir por los recursos de las máquinas y en la medida de lo posible, eliminar las ventanas batch

Comparte esta entrada…

Share

Anuncios