Saltar al contenido principal

1. Arquitecturas web

Cuando utilizamos una aplicación web vemos páginas, formularios, botones, datos y resultados. Detrás de esa interfaz hay distintos componentes que se reparten el trabajo y se comunican entre sí.

El término arquitectura web puede utilizarse en dos sentidos relacionados:

  • La organización de los contenidos y los mecanismos que permiten localizarlos y navegar por ellos.
  • La organización técnica de una aplicación web: cómo se reparten la presentación, el procesamiento y el acceso a los datos.

En este módulo nos centraremos principalmente en el segundo significado.

Idea clave

Una arquitectura define qué responsabilidades tiene cada parte de la aplicación y cómo se relacionan esas partes entre sí.

1.1. Las capas de una aplicación web​

Una forma habitual de estudiar una aplicación web consiste en separar sus responsabilidades en tres capas:

  • Capa de presentación.
  • Capa de negocio.
  • Capa de acceso a datos.

Esta división es conceptual. Las tres capas pueden ejecutarse en una misma máquina o distribuirse entre varios sistemas, pero cada una cumple una función diferente.

Capas de una aplicación web: presentación, negocio y acceso a datos

Capa de presentación​

Es la parte visible de la aplicación y aquella con la que interactúa directamente el usuario.

Entre sus funciones se encuentran:

  • Gestionar la navegación.
  • Recoger los datos introducidos por el usuario.
  • Realizar validaciones iniciales.
  • Dar formato a la información que se mostrará.
  • Presentar los resultados.

En una aplicación web actual, tecnologías como HTML, CSS y JavaScript participan habitualmente en esta capa.

Ejemplo

En una aplicación de reservas, el formulario en el que seleccionamos una actividad y una fecha pertenece a la capa de presentación.

Capa de negocio​

Recibe las operaciones solicitadas desde la capa de presentación y aplica las reglas necesarias para resolverlas.

Es donde reside la lógica que determina qué debe hacer la aplicación.

Por ejemplo, puede encargarse de:

  • Comprobar si quedan plazas disponibles.
  • Calcular el importe final de un pedido.
  • Verificar si un usuario tiene permiso para realizar una operación.
  • Decidir qué información es necesario consultar o modificar.
Ejemplo

Si intentamos reservar una actividad completa, la capa de negocio puede comprobar el número de plazas disponibles y decidir que la reserva no puede realizarse.

Capa de acceso a datos​

Está formada por los componentes encargados de almacenar, estructurar y recuperar los datos que necesita la aplicación.

Con frecuencia esta capa se comunica con un sistema gestor de bases de datos, aunque los datos también pueden proceder de archivos, servicios externos u otros sistemas.

Ejemplo

Cuando necesitamos conocer las plazas disponibles de una actividad, esta capa recupera de la base de datos la información necesaria para que la capa de negocio pueda tomar una decisión.

¿Cómo colaboran las tres capas?​

Supongamos que queremos consultar los datos de una actividad:

presentación → negocio → acceso a datos → negocio → presentación

  1. Desde la interfaz solicitamos la información.
  2. La capa de negocio determina qué datos necesita.
  3. La capa de acceso a datos recupera la información almacenada.
  4. La capa de negocio procesa el resultado.
  5. La capa de presentación muestra la respuesta al usuario.
Para recordar

Podemos asociar cada capa con una pregunta:

  • Presentación: ¿cómo interactúa el usuario con la aplicación?
  • Negocio: ¿qué reglas y operaciones debe realizar la aplicación?
  • Acceso a datos: ¿dónde y cómo obtenemos o almacenamos la información?

1.2. Evolución de los modelos de arquitectura web​

Las primeras aplicaciones web eran mucho más sencillas que las actuales. A medida que crecieron sus funcionalidades, también evolucionó la forma de organizar su código y repartir responsabilidades.

Una clasificación histórica muy utilizada en el entorno de las aplicaciones web Java distingue los siguientes modelos:

Modelo 1 → Modelo 1.5 → Modelo 2 → Modelo 2x

Esta clasificación nos ayuda a observar una tendencia importante: las aplicaciones fueron pasando de tener la presentación, la lógica y los datos muy unidos a separar cada vez mejor esas responsabilidades.

Evolución de los modelos de arquitectura web desde CGI hasta aplicaciones multicanal

1.3. Modelo 1: CGI​

En el Modelo 1, las aplicaciones web utilizaban habitualmente CGI (Common Gateway Interface).

CGI permite que un servidor web ejecute un programa externo para procesar una petición. La salida generada por ese programa se devuelve al cliente, por ejemplo en forma de una página HTML.

Una aplicación de este tipo podía reunir en un mismo programa o script:

  • La generación de la interfaz.
  • La lógica de negocio.
  • El acceso a los datos.

Era frecuente encontrar estos programas escritos en lenguajes como Perl.

El funcionamiento puede simplificarse así:

petición → servidor web → programa CGI → HTML generado → respuesta

El principal inconveniente aparece cuando la aplicación crece. Si presentación, negocio y acceso a datos están muy unidos, modificar una parte puede afectar fácilmente a las demás y el mantenimiento se vuelve más difícil.

Perspectiva actual

CGI sigue existiendo y algunos servidores todavía pueden utilizarlo, pero ya no es el enfoque habitual para desarrollar nuevas aplicaciones web.

Su interés en esta unidad es entender el punto de partida: las distintas responsabilidades de una aplicación podían estar fuertemente acopladas.

1.4. Modelo 1.5: JSP, Servlets y JavaBeans​

El Modelo 1.5 supuso una mayor separación de responsabilidades en las aplicaciones web desarrolladas con Java.

Para entenderlo necesitamos distinguir tres tecnologías:

  • JSP (JavaServer Pages): páginas que permiten generar contenido web dinámico desde el servidor.
  • Servlets: componentes Java preparados para recibir y procesar peticiones web.
  • JavaBeans: componentes Java reutilizables que pueden encapsular datos y comportamiento.

En este modelo, las páginas JSP se ocupaban principalmente de la presentación, mientras que los JavaBeans utilizados desde ellas podían asumir tareas relacionadas con la lógica de negocio y el acceso a datos.

La separación era mayor que en el Modelo 1, aunque la presentación todavía podía quedar bastante ligada a los componentes que realizaban el procesamiento.

Perspectiva actual

JSP y Servlets no son simplemente tecnologías desaparecidas. El ecosistema Java empresarial evolucionó desde Java EE hacia Jakarta EE, y actualmente existen las especificaciones Jakarta Server Pages y Jakarta Servlet.

Más adelante trabajaremos con Apache Tomcat, un contenedor capaz de ejecutar aplicaciones basadas en estas tecnologías web de Java.

1.5. Modelo 2: MVC​

El Modelo 2 mejora la separación de responsabilidades mediante el patrón MVC (Modelo-Vista-Controlador).

La principal novedad es la incorporación de un controlador que recibe las peticiones y coordina el flujo de la aplicación.

Podemos distinguir tres responsabilidades:

  • Modelo: representa los datos y la lógica asociada a la aplicación.
  • Vista: presenta la información al usuario.
  • Controlador: recibe las peticiones y decide qué acciones deben realizarse.

Una representación simplificada sería:

Relación entre Modelo, Vista y Controlador en una arquitectura MVC
Ejemplo

Si solicitamos consultar una actividad:

  1. El controlador recibe la petición.
  2. Solicita al modelo la operación necesaria.
  3. El modelo obtiene o procesa la información.
  4. La vista presenta el resultado al usuario.
Idea clave

Las tres capas estudiadas al comienzo y el patrón MVC no son exactamente lo mismo.

Ambos buscan separar responsabilidades, pero describen la organización desde perspectivas distintas y pueden utilizarse conjuntamente en una misma aplicación.

1.6. Modelo 2x: aplicaciones multicanal​

El denominado Modelo 2x aparece para responder a la necesidad de desarrollar aplicaciones multicanal, es decir, aplicaciones capaces de ofrecer la misma información o funcionalidad a distintos tipos de cliente.

En el contexto en el que surgió este modelo podían encontrarse clientes como:

  • Navegadores web convencionales.
  • Terminales de telefonía móvil.
  • PDA (Personal Digital Assistant).

Una solución utilizada consistía en mantener los datos en XML y utilizar hojas de transformación XSL para generar una salida diferente según el dispositivo.

La idea puede resumirse así:

mismos datos → transformación según el cliente → distintas presentaciones

Perspectiva actual

Las PDA y el uso de XML + XSL como solución general para aplicaciones multicanal pertenecen a una etapa anterior del desarrollo web. Además, la denominación Modelo 2x no es una clasificación habitual en las arquitecturas web actuales.

La necesidad que intentaba resolver, sin embargo, sigue plenamente vigente: una misma aplicación puede ser utilizada desde una web, una aplicación móvil u otros sistemas.

Hoy es habitual separar el cliente del servidor mediante una API. El servidor ofrece datos y operaciones, mientras que cada cliente construye su propia interfaz. En muchas aplicaciones web actuales los datos se intercambian en formatos como JSON.

Podemos representarlo de forma simplificada así:

navegador / app móvil / otro sistema → API → lógica de aplicación → datos

Arquitectura actual con varios clientes conectados a un backend mediante una API

1.7. Qué debemos entender de esta evolución​

Las tecnologías concretas han cambiado, pero la evolución de estos modelos muestra una idea que continúa siendo fundamental: separar responsabilidades facilita el desarrollo y el mantenimiento de una aplicación.

El recorrido puede resumirse así:

responsabilidades mezcladas → separación parcial → MVC → aplicaciones para distintos clientes

Cuando analicemos una arquitectura web nos interesará identificar:

  • Qué componente presenta la información al usuario.
  • Dónde se ejecuta la lógica de la aplicación.
  • Cómo se almacenan y recuperan los datos.
  • Cómo se comunican los distintos componentes.
  • Qué tipos de cliente pueden utilizar la aplicación.
Comprueba que lo has entendido

Antes de continuar, deberíamos ser capaces de responder estas preguntas:

  1. ¿Qué responsabilidad tiene cada una de las tres capas de una aplicación web?
  2. ¿Qué problema aparece cuando presentación, negocio y acceso a datos están demasiado unidos?
  3. ¿Qué papel incorpora el controlador en el Modelo 2?
  4. ¿Qué necesidad trataba de resolver el Modelo 2x?
  5. ¿Cómo suele resolverse actualmente la necesidad de ofrecer una aplicación a distintos tipos de cliente?

1.8. Para saber más​

Para saber más

Si quieres ampliar algunos de los conceptos de este apartado, puedes consultar:

Estos recursos son complementarios y no es necesario estudiarlos en profundidad para seguir la unidad.