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.

Maven. Compilar varios proyectos

En la mayoría de proyectos medianamente grandes el código está dividido en varios subproyectos (varios directorios src). El siguiente articulo muestra como generar con maven 2 los ficheros binarios del proyecto.
La mejor forma de saber como se hace es con un ejemplo. Supongamos que se dispone de dos proyectos:

El proyecto1 tiene la siguiente clase:

package es;

public class Dependencia{

public void funcionDos (){}

}

El proyecto2 tiene la siguiente clase:

package es;

public class Main{

public void main (String [] arg){

new es.Dependencia().funcionDos ();

}

}

El proyecto2 es el subproyecto principal del proyecto (siempre hay un subproyecto que es el principal, o al menos el punto de entrada a todo el proyecto) y tiene una dependencia con el proyeto1.

La forma más elegante es generar el proyecto completo es crear 3 ficheros pom.xml: uno para la gestión de todo el proyecto y uno por cada subproyecto. El pom.xml de todo el proyecto se coloca a la altura en el raíz de los subproyectos y luego cada pom.xml en el subproyecto correspondiente. La estructura del proyecto general será:

• pom-todo.xml:

<project>

<name>Maven 2 Example</name>

<url>http://www.attainware.com/</url>

<modelVersion>4.0.0</modelVersion>

<groupId>es</groupId>

<version>1.0</version>

<artifactId>proyecto</artifactId>

<packaging>pom</packaging>

<modules>

<module>proyecto1</module>

<module>proyecto2</module>

</modules>

</project>

• Pom.xml del proyecto 1:

<project>

<modelVersion>4.0.0</modelVersion>

<groupId>es</groupId>

<artifactId>proyecto1</artifactId>

<version>1</version>

<build>

<sourceDirectory>src</sourceDirectory>

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

<configuration>

<source>1.6</source>

<target>1.6</target>

</configuration>

</plugin>

</plugins>

</build>

</project>

• Pom.xml del proyecto2:

<project>

<modelVersion>4.0.0</modelVersion>

<groupId>es</groupId>

<artifactId>proyecto2</artifactId>

<version>1</version>

<dependencies>

<dependency>

<groupId>es</groupId>

<artifactId>proyecto1</artifactId>

<version>1</version>

</dependency>

</dependencies>

<build>

<sourceDirectory>src</sourceDirectory>

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

<configuration>

<source>1.6</source>

<target>1.6</target>

</configuration>

</plugin>

</plugins>

</build>

</project>

Ahora solo resta ejecutar el comando mvn -f pom-todo.xml install a la altura del fichero pom-todo.xml. En cada subproyecto se habrá generado una carpeta “target” con todos los binarios.