Directriz: Descripción de la arquitectura de tiempo de ejecución de aplicaciones J2EE
Esta directriz trata cómo modelar la arquitectura de tiempo de ejecución de una aplicación J2EE.
Relaciones
Descripción principal

Introducción

La arquitectura de tiempo de ejecución de una aplicación se describe en la Vista de proceso, una vista arquitectónica que describe los elementos concurrentes de un sistema. Estas directrices proporcionan ayuda específica sobre cómo modelar la Vista de proceso de una aplicación J2EE.

Consulte la sección Concepto: Vista de proceso para obtener más información.

Cómo modelar la Vista de proceso

Los componentes J2EE (consulte la sección Concepto: visión general de J2EE: componentes de J2EE) se despliegan en entornos denominados contenedores. Consulte la sección Concepto: visión general J2EE : contenedores de J2EE para obtener una descripción de cada uno de los tipos de contenedores que J2EE define.

Cada contenedor es un elemento concurrente y, por lo tanto, debería aparecer en la Vista de proceso de la arquitectura. Otros elementos concurrentes importantes que aparecen normalmente en la vista de proceso de alto nivel son los sistemas externos.

A continuación se muestra un diagrama típico de la vista de proceso de alto nivel de una aplicación J2EE.

Diagrama descrito en el texto adjunto.

En un ejemplo real, se vería también representado un middleware orientado a mensajes (MOM) de un proveedor específico, así como sistemas tradicionales y clientes de aplicación. Sin embargo, el contenedor web y el contenedor EJB son contenedores estándar que deberían aparecer en todas las vistas de proceso de J2EE.

Hay que tener en cuenta que en este diagrama no se muestra la distribución física de estos sistemas en nodos de hardware específicos. Esto se muestra en el modelo de despliegue (consulte la sección Técnica: descripción de la distribución para las aplicaciones J2EE para obtener más información).

En este ejemplo, se ven los mecanismos de comunicación entre procesos seleccionados y empleados entre los contenedores. J2EE proporciona mecanismos de comunicación entre procesos específicos. Son los siguientes:

  • RMI (Java Remote Method Invocation) para comunicaciones síncronas entre clases Java.
  • RMI-IIOP para operaciones con clientes CORBA (habitualmente aplicaciones tradicionales).
  • HTTP/HTTPS para comunicaciones con clientes basados en la web (a pesar de que se da soporte a otros protocolos, como cuando se interactúa con servicios web XML).
  • JMS (Java Message Service) para mensajes e interacciones con el middleware orientado a mensajes (MOM).

Al definir la vista de proceso, una decisión importante es decidir cuándo utilizar JMS frente a RMI o RMI-IIOP. En este ejemplo, el cliente de aplicación, el contenedor EJB y otros sistemas tradicionales utilizan mensajería para comunicarse. Sin embargo, no está claro qué elementos se comunican con qué otros. Para resolver esta ambigüedad, considere eliminar el sistema MOM del diagrama, y mostrar a JMS como la asociación entre los elementos que se comunican mediante mensajería.

Otra ambigüedad es saber si los EJB se comunican entre sí mediante mensajería. Esto se puede aclarar mostrando una asociación JMS del contenedor EJB consigo mismo. El diagrama final pasa a ser:

Diagrama descrito en el texto adjunto.

La vista de proceso, sin embargo, es algo más que tan sólo contenedores y sistemas de alto nivel. También trata sobre la concurrencia dentro de estos contenedores y sistemas.

La vista de proceso debería identificar y modelar los siguientes tipos de clases activas.

  • Hebras de Java.
  • Destinos de mensajes.
  • Beans controlados por mensajes (puesto que se invocan de forma asíncrona mediante mensajes). Consulte la sección Técnica: identificación de Enterprise JavaBeans para obtener información sobre estereotipos específicos utilizados para modelar beans controlados por mensajes.
  • Procesos adicionales que son parte del diseño global del sistema. Un proceso temporizador separado es un ejemplo de este tipo de proceso.

Al utilizar JMS, se puede elegir relacionar directamente consumidores y productores de mensajes, o modelar la relación de forma más precisa modelando temas y colas.

Los diagramas de interacciones sirven para mostrar tanto la comunicación síncrona como la comunicación síncrona entre elementos de diseño. También se pueden utilizar para analizar el comportamiento concurrente a efectos de problemas lógicos y de rendimiento. En concreto, un arquitecto de software puede buscar dónde se producen mensajes frecuentes o se dan elevados volúmenes de transferencia de datos en la red. Esto puede hacer que el arquitecto rediseñe interfaces, o reasigne elementos de diseño entre hebras de control, entre servidores o entre cliente y servidor.

Hay que observar que dentro de un contenedor EJB, es éste quien maneja las hebras y los procesos; los EJB no pueden crear o gestionar hebras. Por lo tanto, cada EJB se debería considerar como una clase activa, sin embargo, puesto que las llamadas a beans de sesión y beans de identidad son llamadas con bloqueo síncrono, normalmente no se modelan como clases activas. Normalmente, la vista de proceso de un contenedor EJB se limita a un mecanismo de concurrencia disponible: JMS con beans controlados por mensajes JMS.

A pesar de que los beans de sesión y los beans de entidad generalmente no se modelan como clases activas, haya problemas de concurrencia, como cuando hay un EJB leyendo de la base de datos mientras otro escribe en ella. Estos problemas se tratan mediante la utilización de transacciones. La aproximación para utilizar transacción se debería documentar en las directrices específicas del proyecto.

Asignación de elementos de diseño a clases activas

La sección Tarea: descripción de la arquitectura de tiempo de ejecución trata sobre la necesidad de asignar elementos de diseño a procesos y hebras. En una aplicación J2EE, todos los componentes web se asignan al contenedor web, y todos los EJB al contenedor EJB. Dada esta relación simple, no hay necesidad de modelar esta asignación.

Sin embargo, si el diseño incluye procesos concurrentes adicionales (como por ejemplo dos aplicaciones de cliente distintas) puede ser útil especificar qué elementos de diseño se ejecutan en cada aplicación.

Para las hebras de Java, los beans controlados por mensajes, las colas y temas JMS, los problemas están más en la forma en que se comunican, para evitar puntos muertos, datos no coherentes, etc. Estas situaciones se exploran mejor examinando guiones de uso realizados que incluyan estos elementos.

Otras alternativas de modelado

Debido a la afinidad entre la Vista de proceso y la Vista de despliegue, a menudo se combinan los diagramas de alto nivel de estas vistas.

Además, puesto que cada contenedor J2EE no es sólo un proceso, sino que también es un entorno de ejecución, se puede modelar como un "nodo lógico" en lugar de como una clase activa.