Arquitectura de una Alicación Web basada en Java

ARQUITECTURA DE UNA
APLICACIÓN WEB
BASADA EN JAVA/J2EE
Documento realizado para Curso de Verano de Aplicaciones Java / j2ee en Oviedo
¿QST?, UP
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
Arquitectura de una Aplicación Web
Aspectos generales........................................................................................................ 3
• Escalabilidad ................................................................................................. 3
• Separación de responsabilidades.................................................................... 4
• Portabilidad ................................................................................................... 4
• Componentización de servicios de infraestructuras ........................................ 4
• Gestión de sesión de usuario.......................................................................... 5
• Aplicación de patrones de diseño................................................................... 5
Descomposición en microaplicaciones .......................................................................... 5
• Empleo de EJBs de sesión ............................................................................. 5
• Servicios Web ............................................................................................... 5
Separación lógica en capas............................................................................................ 5
Capa de presentación .................................................................................................... 6
El Patrón Model – View – Controller ........................................................................ 6
• El modelo ...................................................................................................... 6
• La vista ......................................................................................................... 6
• El controlador................................................................................................ 6
El Framework Struts ................................................................................................. 7
• ActionForms ................................................................................................. 7
• ActionServlet ................................................................................................ 7
• Actions.......................................................................................................... 7
El Framework STXX ................................................................................................ 7
Capa de negocio............................................................................................................ 7
Capa de acceso a datos.................................................................................................. 7
El SQLProvider ........................................................................................................ 8
Capa de infraestructura ................................................................................................. 8
Comunicación entre capas............................................................................................. 9
Página 2
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
Arquitectura de una Aplicación Web
Aspectos generales
A la hora de abordar el desarrollo de un proyecto Web debemos tener
presentes una serie de claves:
• Escalabilidad: El éxito o fracaso de un sitio Web orientado al usuario
común puede venir determinado por el dimensionado del sistema sobre
el que se instala y soporta el software. Uno de los requisitos
fundamentales de una aplicación Web es que sea completamente
escalable sin que un aumento de los recursos dedicados a la misma,
suponga un peor comportamiento. La escalabilidad puede ser de 3 tipos:
o Horizontal: Cuando literalmente clonamos el sistema a otra
máquina de características similares y movemos la carga con un
dispositivo externo. El balanceador de carga puede ser:
§ Balanceador Software: Este tipo de balanceadores
examinan el paquete http e identifican la sesión de usuario,
guardando un registro de la máquina que esta operando.
§ Balanceador Hardware: Respondiendo únicamente a
algoritmos de reparto de carga, redireccionan una petición
http del usuario a la máquina. Dependiendo del algoritmo
esa petición será o no será tramitada.
§ Balanceador Hardware http: Dispositivos hardware que si
examinan el paquete http y mantienen relación usuariomaquina.
o Vertical: La separación lógica de capas se implementa de tal
forma que se permita una separación física de las mismas.
Interponiendo elementos conectores es posible distribuir la
aplicación de forma vertical (una máquina por cada capa de
sistema) e incluso si esto no es suficiente, se puede distribuir los
elementos de una misma capa entre distintas máquinas.
o Cluster: Permite el despliegue de una aplicación Web corriente
de forma que su carga de trabajo vaya a ser distribuida entre la
conjunto de servidores que forman el cluster.
Página 3
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
Arquitectura de una Aplicación Web
• Separación de responsabilidades: Distintas responsabilidades no
deben ser delegadas en la misma clase. La tendencia más aceptada es
la aplicación de patrones de diseño de arquitectura, que dividen la
responsabilidad en distintas capas que interaccionan unas con otras a
través de sus interfaces. El modelo más básico es el de aplicaciones de
tres capas:
o Presentación: Se limita a la navegabilidad y a gestionar todos
aquellos aspectos relacionados con la lógica de presentación de
la aplicación.
o Negocio: El resultado del análisis funcional de la aplicación viene
a ser la identificación del conjunto de reglas de negocio que
abstraen el problema real a tratar. Son las que realmente
suponen el motor del sistema.
o Acceso a datos: Es la encargada de persistir las entidades que
se manejan en la capa negocio, al acceso a datos, etc. Aunque
puede ofrecer servicios más complejos.
Este modelo que hemos visto es el modelo básico. Distintos patrones
arquitectónicos han ido apareciendo como evolución del modelo. Casi todos se
basan en insertar más capas para conseguir una mayor independencia entre
las anteriores.
• Portabilidad: En la medida de lo posible, una aplicación Web debe
poder adaptarse a las distintas posibilidades arquitectónicas físicas
susceptibles de ser empleadas para el despliegue del paquete,
limitándose el impacto de la adaptación y evitándose así la necesidad de
modificar el código de la misma en anteriores situaciones.
• Componentización de servicios de infraestructuras: Aparecen
una serie de servicios que podríamos denominar infraestructuras y que
han de estar disponibles desde distintas partes del sistema. Casos
habituales de servicios de esta índole son:
o Servicio de log
o Pool de conexiones JDBC
o Sistema de configuración
o Gestor de accesos / permisos
o …
La arquitectura pretende tratar este conjunto de servicios como
componentes, servicios de la capa de infraestructura de forma que:
o Puedan ser sustituidos por nuevas versiones de necesidad de
parada ni recompilación.
o Puedan ser reutilizados por futuros proyectos.
o Sean accesibles desde todas las capas del sistema sin romper la
independencia entre las mismas.
Página 4
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
Arquitectura de una Aplicación Web
• Gestión de sesión de usuario: Con objeto de limitar los accesos
innecesarios a memoria secundaria, se propone un sistema que se
apoya en parte en el empleo de la sesión http para cachear ciertos datos
referentes a la sesión de usuario o bien comunes a todas las sesiones
de usuario.
• Aplicación de patrones de diseño: Facilita el entendimiento del
código y por tanto reduce considerablemente el coste de mantenimiento.
Descomposición en microaplicaciones
Si procuramos descomponer el producto identificando funcionalidades,
obtendríamos una aplicación final formada por una agrupación de lo que
podríamos denominar módulos o microaplicaciones.
Cuando surge la necesidad de colaborar con ciertos procesos desde una
microaplicación a otra, la primera cuestión es a que nivel de la arquitectura se
debe hacer, manteniendo la separación de responsabilidades y de máxima
independencia entre los distintos módulos de la aplicación. Se debe evitar el
acceso directo al repositorio de información. El punto adecuado para comunicar
dos microaplicaciones es la capa de negocio.
Para mantener la independencia entre microaplicaciones, debe
sustituirse el modelo habitual de colaboración entre módulos es decir, la
invocación directa de sus clases por otro que permita un mayor
desacoplamiento de los mismos. Las soluciones pueden ser:
• Empleo de EJBs de sesión: Tiene una gran ventaja y es que al ser
habitual el empleo de estos componentes a modo de façade, es posible
que no tenga impacto alguno en la microaplicación.
• Servicios Web: Cuentan con la ventaja de permitir invocaciones
remotas en formato XML y sobre el protocolo http. Esto posibilita la
distribución o colaboración de las microaplicaciones presentes en dichas
redes o a través de Internet.
Separación lógica en capas
A la hora de plantear el diseño de una aplicación Web, lo primero es
conseguir separar las tareas que el sistema debe desempeñar entre las
distintas capas lógicas y en base a la naturaleza de dichas tareas. Se parte de
una separación inicial en tres capas, diferenciando que proceso responde a las
tareas de presentación, negocio y datos.
Página 5
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
Arquitectura de una Aplicación Web
Capa de presentación
En esta capa se resuelven cuestiones como:
• Navegabilidad del sistema, mapa de navegación, etc.
• Formateo de los datos de salida.
• Internacionalización; textos, etiquetas, etc.
• Validación de los datos de entrada en cuanto a formato, longitud, etc.
• Multicanalidad de la aplicación; una misma aplicación puede contar con
diferentes presentaciones, determinándose la mas adecuada en función
del dispositivo del usuario.
El Patrón Model – View – Controller
El MVC es un patrón arquitectural aportado por SmallTalk muy difundido en
su uso en aplicaciones Web. Pese a que hay distintos puntos de vista acerca
de la forma de aplicar e implementar este patrón, en esencia las ideas
principales sobre su estructura y funcionalidad son las mismas. Tiene tres
piezas claves que se reparten la responsabilidad:
• El modelo: Responsable de toda la lógica y estado del dominio de
negocio. En base al tipo de arquitectura sobre el que se está
construyendo la aplicación puede seguir distintos patrones en su diseño.
• La vista: Responsable de la presentación del dominio de negocio. Esta
compuesta por aquellos elementos que aporten algo a la presentación,
como jsps, página html, etc.
• El controlador: Responsable del flujo de control, la navegabilidad y el
estado de la entrada del usuario. Habitualmente implementado por un
servlet. Es responsable de:
o Interceptar y recoger las peticiones http del cliente.
o Traducir la petición en una operación de negocio especifica.
o Invocar la operación o bien delegar en un manejador.
o Determinar la siguiente vista a mostrarle al cliente.
o Retornar el control a cliente.
Página 6
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
Arquitectura de una Aplicación Web
El Framework Struts
Craig R. en 2000 fue la persona que lanzó el proyecto Struts. Este
framework del proyecto Jakarta es la implementación java orientada a
aplicaciones Web más difundida del patrón MVC. Provee su propio controlador
(ActionServlet) y se integra con otras tecnologías para proveer el modelo y la
vista. La navegación se configura en ficheros XML externos a modo de AFD
con eventos. Struts organiza la lógica siguiendo la distribución del MVC entre
las siguientes clases:
• ActionForms: Son parte de la vista. Representan formularios html y su
uso facilita tareas como la validación de formatos, rellenado de
formularios, etc.
• ActionServlet: Es el elemento controlador, configurado por medio del
fichero struts-config.xml
• Actions: Una de las características más interesante es que induce a un
diseño que identifica las acciones susceptibles de ser invocadas desde
presentación y la mapea con un servlet a cada una.
El Framework STXX
El proyecto STXX es una extensión del frameswork de Struts para
soportar XML junto con tecnologías de transformación de XML, como XSL sin
alterar la funcionalidad de Struts.
STXX se coloca por encima de Struts extendiendo su funcionalidad para
permitir que las clases Action desarrolladas retornen documentos XML, que
serán empleados por tecnologías XSL o Velocity.
Capa de negocio
En esta capa es donde se deben implementar todas aquellas reglas
obtenidas a partir del análisis funcional del proyecto. Así mismo, debe ser
completamente independiente de cualquiera de los aspectos relacionados con
la presentación de la misma. De esta forma la propia capa de negocio puede
ser empleada como una aplicación Web común. Por otro lado, la capa de
negocio ha de ser totalmente independiente de mecanismos de persistencia
empleados en la capa de acceso a datos. Las responsabilidades que conviene
abordar en esta capa son:
• Implementación de los procesos de negocio identificados en el análisis
del proyecto.
• Control de acceso a los servicios de negocio.
• Publicación de servicios de negocio.
• Invocación a la capa de persistencia.
Capa de acceso a datos
Es la responsable de la gestión de la persistencia de la información
manejada en las anteriores capas. La interfaz de esta capa estaría compuesta
Página 7
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
Arquitectura de una Aplicación Web
por vistas de las entidades, pero a efectos prácticos, la interfaz muestra una
serie de servicios que pueden agrupar operaciones en lo que se puede
denominar (lógica de persistencia).
El SQLProvider
Es importante conocer donde la organización de la aplicación a la hora
de diseñar. Por este motivo es aconsejable cierta centralización de los
recursos, datos u objetos en general que compartan una tarea común. Este
principio nos da lugar al SQLProvider. Este elemento, agrupará todas las
sentencias SQL susceptibles de ser empleadas en la capa de acceso a datos.
De esta forma se facilita el mantenimiento de la aplicación. En definitiva lo que
se busca es una capa con las siguientes características:
• La capa de acceso a datos encapsula toda la lógica de almacenamiento,
independizando al resto del sistema del mecanismo de persistencia.
• El empleo de un objeto servidor de sentencias SQL que las tome de un
fichero XML externo para facilitar la migración de una base de datos a
otra.
Capa de infraestructura
Comprende todos aquellos servicios susceptibles de ser requeridos desde
cualquiera de las capas lógicas de la aplicación Web. La gestión se realizará
desde la concepción de un componente es decir, una clase totalmente
independiente de la aplicación que lo utiliza. En definitiva la capa de
infraestructura estará formada por componentes y por las clases gestoras
necesarias para su configuración y gestión.
La relación entre una interfaz que defina un servicio de infraestructura y la
clase que implementa el servicio se establece en un fichero externo XML. De
esta forma:
• la sustitución de un componente que implemente un servicio de la capa
de infraestructura por otro distinto que cumpla la misma interfaz sólo
requiere modificar el fichero de configuración.
• La configuración de cada uno de los componentes irá asimismo
externalizada en ficheros XML.
• Se consigue desacoplar totalmente la aplicación de su entorno de
despliegue.
• Las clases gestoras, en caso de que el comportamiento del componente
lo permitiera, puedan trabajar con pools de componentes para aquellos
cuyo uso no implique un mantenimiento de estado.
• Las clases gestoras de la capa de infraestructura deben permitir
establecer periodos de reconfiguración de forma que la alteración del
comportamiento del sistema a través de sus componentes se pueda
hacer en el instante, evitando una parada en el sistema de producción.
Página 8
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
Arquitectura de una Aplicación Web
Algunos casos comunes pertenecientes a la capa de infraestructura son:
• Servicio de log.
• Pool de conexiones JDBC.
• Sistema de configuración de la aplicación.
• Gestor de accesos / permisos de usuario.
• El SQLProvider descrito anteriormente.
• Otros específicos.
Comunicación entre capas
La evolución del modelo de 3 capas pasa por la incorporación de capas
intermedias que permitan desacoplar las capas originales y distribuirlas por
medio de algún tipo de middleware. No obstante este tipo de arquitectura
presenta un problema importante; cuando la aplicación no esta distribuida
verticalmente y se encuentra desplegada en una sola máquina, se están
realizando invocaciones RMI al localhost. Lógicamente esto presenta costes
innecesarios que provoca un descenso del rendimiento de la máquina ya que
es una tarea pesada.
Sun Microsystems decidió extender la especificación de EJBs aprovechando la
publicación de la versión 2.0 de la misma con la incorporación de los interfaces
locales. Con ellos se conserva la separación de responsabilidades pero con la
diferencia de que lo que se esta realizando es una simple invocación local de la
clase que implementa la interfaz. De este modo el problema del rendimiento
queda solucionado. No obstante el sistema seguirá dependiendo de la
presencia de EJBs. Esto incide negativamente en la portabilidad del producto.
Dado que esto no es factible, se ha de optar por una solución alternativa que,
limitándose a tareas de configuración del producto, permita ser desplegado en
sistemas no escalables verticalmente.
Página 9
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.