Coordinacion de aplicaciones en un sistema

Una situación muy común cuando se está desarrollando una aplicación es utilizar un fichero, un web service, etc que ofrece o proviene de otro sistema (otra aplicación). Cuando este recurso se ve desde el inicio o el fin del desarrollo de la aplicación que estamos desarrollando se sobre entiende que siempre está completamente definido. Veámoslo con un ejemplo:

Empieza el desarrollo de dos aplicaciones en un mismo sistema, una aplicación A se encarga de la gestión de clientes (alta, baja, modificación, alta datos económicos, etc..) y otra aplicación B que se encarga de la gestión de compras de esos clientes (alta compra, generación de datos de compras, etc..). La comunicación entre las aplicaciones se realiza por un fichero. La aplicación A deja un fichero en un directorio con los datos económicos de cada cliente una vez que estos se modifican y la aplicación B chequea continuamente este directorio para reflejar esos cambios en su sistema. Vale, ahora pensemos en ese fichero al principio y al final del desarrollo de ambas aplicaciones:

• Al principio: Se reúnen los analistas de ambas aplicaciones y deciden la estructura del fichero según piensen que es mejor. El analista de la aplicación A desde el punto de vista de la información que posee y el analista de la aplicación B desde el punto de vista de la información que necesita.

• Al final: el fichero habrá cambiado seguro ya que tanto la aplicación A como la aplicación B son desarrollos vivos que van evolucionando y van evolucionando. La estructura final del fichero es la definitiva y ambos equipos dicen “si es que es lógico esto y lo otro”.

Esto que parece tan lógico y tan fácil de entender es uno de los mayores “perdedores de tiempo” en el desarrollo normal de una aplicación. La cantidad de tiempo que pierde la aplicación B en adaptarse a los cambios del fichero que mantiene la aplicación A suele ser muy elevado y esto es un gran error si tenemos en cuenta que solo “al final” se puede ver la estructura final del fichero.

Es obligatorio utilizar una capa intermedia. Una capa de software que aísle a la aplicación B de los continuos cambios del fichero.

La capa tiene dos partes:

• Captura de datos del fichero: Esta parte realmente no tiene porque funcionar bien hasta el final. Es la parte de la capa intermedia que va a leer datos del fichero.
• Servicios: conjunto de funciones que proveen al resto de la aplicación de la información necesaria. Esta parte NO puede cambiar por que cambie el fichero.

La forma de integrar estas dos partes se consiste simplemente en ir resolviendo el problema de cómo los datos del fichero (captura de datos) pueden ser utilizados para que las funciones (servicios) puedan aportar la información al resto de la aplicación.