Tema 1: Arquitecturas J2EE y patrones de diseño

1.1. El modelo de capas

En aplicaciones distribuidas es una práctica comúnmente aceptada que la arquitectura se estructure según un modelo de capas. Cada capa tiene responsabilidades distintas y constituye un módulo independiente, de manera que los cambios internos en una de ellas no deberían afectar a las otras. Por ejemplo, el cambio de la base de datos de MySQL a Oracle no debería afectar a la parte de la aplicación que se encarga de mostrar los datos en las páginas web. Asímismo, si se introduce la posibilidad de acceder a la aplicación a través de un cliente Swing además del acceso por web, el código que accede a la base de datos o el que implementa la lógica de negocio no debería requerir modificaciones.
En general, las aplicaciones J2EE se suelen dividir en las siguientes capas: De ellas, la primera y la última pueden considerarse como "factores externos" a la aplicación propiamente dicha, lo que nos deja como núcleo de la misma a las tres capas intermedias. Este es el clásico modelo de 3 capas, ampliamente utilizado en aplicaciones distribuidas, por supuesto no solo en entornos J2EE.

1.2. Modelos de arquitecturas para aplicaciones J2EE

Hay varios factores que influyen en la arquitectura básica que debe tener una aplicación J2EE, entre otros:
Así, podríamos distinguir cuatro modelos básicos de arquitectura:

1.2.1. Arquitectura local sin EJBs

Este es el modelo más sencillo (figura 1). Todos los componentes están situados en la misma máquina virtual Java. Si los clientes únicamente van a ser web no es necesario emplear EJBs. En su lugar se utilizan objetos Java comunes (lo que - humorísticamente - se suele llamar POJOs o Plain Old Java Objects).


Figura 1: Arquitectura local sin EJBs

La simplicidad de esta arquitectura aporta una serie de ventajas:
Por supuesto, también tiene una serie de problemas potenciales:

1.2.2. Arquitectura local con EJBs

En esta arquitectura todos los componentes siguen en la misma máquina virtual. Se utilizan únicamente EJBs locales (posibles a partir de la versión 2.0 de la especificación). El uso de EJBs en este caso se justifica por los servicios de gestión automática de transacciones, seguridad y multithreading.


Figura 2: Arquitectura local con EJBs

Como ventajas de esta arquitectura tenemos:
Sus limitaciones son:

1.2.3. Arquitectura distribuída con EJBs remotos

Esta se puede considerar la arquitectura J2EE "prototipo", cuyo esquema siempre figura en las introducciones a J2EE. Hay un contenedor web en el que reside la capa web y en otra máquina virtual Java está el contenedor EJB, donde se coloca la capa de negocio. El acceso desde la capa web a la de negocio se realiza mediante EJBs remotos. La capa de negocio será accesible también desde clientes no web a través de dichos EJBs.


Figura 3: Arquitectura distribuida con EJBs remotos

Las ventajas de este modelo son:
Por supuesto, esto es a cambio de ciertas contrapartidas:

1.2.4 Aplicación con interfaz añadido para servicios web

Este modelo no consiste tanto en una arquitectura distinta sino más bien en una capa adicional de comunicación con el cliente. Internamente, la arquitectura de la aplicación puede seguir uno de los tres modelos anteriores. En este caso el acceso de los clientes que no son navegadores se haría mediante protocolos de servicios web (típicamente SOAP) en lugar de RMI. Esto permite el acceso de clientes que ni siquiera están escritos en Java,  como por ejemplo clientes .NET.


Figura 4: Arquitectura con interfaz de servicios web

Las ventajas de este modelo son:
Finalmente, las contrapartidas:

1.3. Patrones de diseño

Aunque cada aplicación J2EE tiene peculiaridades que la hacen única, en el proceso de desarrollo de casi todas las aplicaciones es necesario solucionar una y otra vez los mismos problemas: autentificación del cliente, persistencia de datos, separación entre presentación, lógica y control,... En lugar de reinventar continuamente la rueda, es mucho más productivo aplicar estrategias que ya hayan funcionado con anterioridad. Esta idea es la que lleva a la definición de los patrones software.

1.3.1 Por qué patrones

En ingeniería del software, un patrón (pattern) es una solución ya probada y aplicable a un problema que se presenta una y otra vez en el desarrollo de distintas aplicaciones y en distintos contextos. Es importante destacar que un patrón no es en general una solución en forma de código directamente "listo para usar", sino más bien una descripción de cómo resolver el problema y de ante qué circunstancias es aplicable.

Los patrones software fueron popularizados en el libro Design Patterns: Elements of Reusable Object-Oriented Software, que trata de patrones genéricos, aplicables a una amplia gama de contextos y a cualquier lenguaje orientado a objetos. Este libro popularizó el "movimiento" de patrones y se ha convertido en un clásico, ampliamente referenciado y que muchos han tomado como base para añadir patrones nuevos. Los autores de Design Patterns... son  Erich Gamma, Richard Helm, Ralph Johnson y John Vissides, aunque de manera humorística son más conocidos como el Gang of Four. De hecho, en muchas publicaciones los patrones que aparecen en Design Patterns se referencian como procedentes del GoF (Gang of Four).

Los patrones J2EE están orientados específicamente a los problemas comunes a todas las aplicaciones J2EE. Los primeros fueron publicados en el libro Core J2EE Patterns, convertido también en un clásico dentro del mundillo J2EE. En la actualidad son muchos los libros y los sitios web dedicados íntegramente a patrones para aplicaciones J2EE o con algún apartado sobre ellos.

Ante todo este movimiento en torno a los patrones cabe preguntarse qué beneficios aportan. Se suele argumentar que los patrones ofrecen tres ventajas fundamentales:

Por supuesto, los patrones no pueden ser la solución a todos los problemas de diseño y desarrollo de aplicaciones J2EE. Como cualquier herramienta o metodología son susceptibles de abusos y de ser utilizados a toda costa simplemente "porque son buenos". La experiencia y el sentido común dictarán cuándo son apropiados y cómo utilizarlos.

1.3.2 Patrones J2EE

Como se ha comentado, en el libro Core J2EE Patterns se encuentra el catálogo de patrones que se suelen considerar como "patrones básicos" en el mundillo J2EE. Una versión resumida del catálogo está disponible en su sitio web. Siguiendo la idea de dividir la arquitectura de una aplicación en varias capas, los patrones se clasifican atendiendo a la capa a la que pertenecen. En la figura 5 aparece el esquema general en la que se muestra la situación de cada uno de los 21 patrones en el modelo de capas y las relaciones que existen entre ellos. Iremos viendo con detalle estos patrones y sus relaciones en los distintos temas del bloque.


catálogo de patrones
Figura 5: Catálogo de patrones de Core J2EE Patterns