Siguiendo con la entrada “el batch en el mundo SOA” de hace unos meses, he querido indagar más sobre este tema que creo de especial importancia. El resultado de esta búsqueda ha sido bastante desalentador, un verdadero “mordisco de realidad” es lo que me he llevado llevado al intentar combinar dos características importantes y necesarias en los desarrollos de software: SOA y batch.

Parece que son como agua y aceite, no he encontrado ningún caso en el que alguien muestre un proceso batch que invoque a los servicios de negocio desplegados como servicios web en una arquitectura SOA. La razón, no es difícil de adivinar, el rendimiento que ofrece SOA no es suficiente para los altos requirimientos de un proceso batch.

Pero empecemos por el principio: ¿para qué necesitamos SOA en batch?:

La primera razón es la reutilización. Si ya tenemos la lógica de negocio para el online, ¿Por que no usar esa lógica ya implementada para el batch? Como decía en mi anterior entrada, la mayor parte de las veces lo que conocemos como un proceso batch masivo, puede descompondrás en la ejecución de una lógica unitaria que se ejecuta, quizás, cientos de miles de veces. Precisamente esta lógica unitaria ya la tenemos disponible y accesible, son los servicios de negocio del online.
¿cual es el problema entonces?

En una típica arquitectura SOA tenemos las siguientes capas:

  1. frontal
  2. integración
  3. lógica de negocio

A su vez, dentro de la capa de lógica de negocio podemos dividirlo en tres grandes subcapas:

  1. fachada
  2. lógica de negocio
  3. lógica de acceso a datos

Tradicionalmente el batch era visto como tratamiento por lotes o batch masivos. Sin embargo, la lógica online, por su propia naturaleza es unitaria. Por lo tanto, ¿hasta dónde podemos reutilizar del online para le batch?

Teniendo en cuentas las capas mencionadas antes, desde el punto de vista de la reutilización, tendríamos los siguientes escenarios:

Obviamente el frontal no se puede reutilizar.

Las posibilidades irían desde el reaprovechamiento total 1º, ya que se reutilizan totalmente los servicios de negocio, hasta el 5º, en el que no se reutiliza absolutamente nada.

Obviamente la reutilización de la capa de integración sería muy recomendable ya que en esta capa, realizada mediante un ESB y una herramienta de programación productiva se realiza la composición de las lógicas del backend, su ordenación en un flujo, bucle, etc. y el control de la transaccionalidad.

Si no se usa esta capa tendremos que implementar un programa (por ejemplo un EJB) que suple esta capa de integración. Por motivos de rendimiento y escalabilidad este EJB debería ser un MDB (los parámetros de entrada vendrían en una cola JMS, también la salida sería un JMS).

También por rendimiento, es posible que la lógica de acceso a datos unitaria pensada por el online no sirva para el batch. Pensemos por ejemplo que tenemos un batch para realizar las facturas mensuales que vencen ese día. Si por cada una de estas facturas se consultan los datos para un cliente y tenemos 100.000 facturas. Si utilizamos la lógica de datos del online seguramente ejecutaremos 100.000 consultas a la base de datos. En este caso, sería muy recomendable volver a programar está lógica de acceso a datos, y hacer por ejemplo, que en lugar de recuperar un cliente de la base de datos recupere los 100.000 (los que quepan en memoria) mediante una consulta cruzada entre los clientes y las facturas que venzan ese día. En este caso tendríamos un sólo acceso (o unos pocos) a la base de datos.

Por supuesto, la arquitectura debe de haber previsto la posibilidad de cambiar la lógica de datos por configuración sin tener que tocar la lógica de negocio. Ver patrón Abstract Factory. La lógica de negocio conocería el EAO de acceso a datos y su funcionalidad, podría invocarla, pero no sabría que instancia concreta está usando (la preparada para el online o la preparada para el batch).

Visto lo visto, queda un trecho importante por  andar en lo referente a integrar SOA en el batch.

Anuncios