Desarrollo Web: Intro a Arquitectura Web


Arquitectura Web

La forma de desarrollar aplicaciones en Arena trabaja con una arquitectura simple: la aplicación corre en forma local en una única VM que sirve como ambiente para todos los objetos de la aplicación: UI, controllers, modelo de la vista, repositorios, objetos de negocio, etc.

Para comenzar a entender la filosofía Web, tenemos que explicar primero cómo funciona su arquitectura porque de movida hay cosas que no son traducibles a lo que conocemos:
  • el cliente tiene un programa ejecutable (application client, el web browser es el más común)
  • y el servidor tiene otro programa ejecutable: en la materia será nuestro application server el que tendrá una VM donde vivan los objetos de negocio. 
El cliente hace pedidos a través de un puerto contra el servidor, el servidor responde.
El flujo de mensajes siempre comienza en el cliente:
  1. cliente pide servicio (request)
  2. servidor responde (response)
  

Algunas consecuencias:
  • Nuestra aplicación pasa a ser una aplicación distribuida: va a tener una parte corriendo en el servidor y otra parte corriendo en el cliente. Dependiendo de la arquitectura que elijamos
    • podemos tener la mayor parte de la lógica en el servidor y tener un cliente liviano (thin) o ZAC (Zero Administration Client). Entonces lo que le llega al cliente es sólo un documento HTML, y es fácil mantener la aplicación cuando tengo muchos clientes ubicados 
    • o bien podemos poner gran parte de la lógica en el cliente y utilizar la parte server solamente para sincronizar la información entre sesiones de usuario
  • de todas maneras, por más liviano que sea el cliente, los browsers no son uniformes, entonces si queremos que una aplicación ande en todos ellos muchas veces vamos a tener que manejar código específico para cada plataforma (browser, versión, sistema operativo y a veces hasta el hardware).
  • como el cliente es el que dispara los pedidos, todas las interacciones entre el usuario y la aplicación deben ser iniciadas por el usuario, la aplicación no puede tomar la iniciativa. Ej: si tengo una lista de tareas pendientes, para que aparezca una nueva tarea hay que obligar al cliente a que dispare el refresh.

Comunicación cliente - servidor

Antes de meternos más de lleno, nos preguntamos: la tecnología de objetos ¿es consistente con la metáfora "pedido-respuesta" (request/response)?


Sí, en definitiva es la representación de lo que es un mensaje.
Lo que pasa es que en un sistema con objetos no pongo restricciones: cualquiera puede ser emisor y cualquiera receptor. En cambio en la tecnología web siempre es el cliente el que pide y siempre el servidor el que responde.

Cómo se implementa la comunicación

El cliente dice: "necesito x". Esto se traduce en una dirección de una página en particular, esa dirección recibe el nombre de URL (Uniforme Resource Locator, o forma de encontrar un recurso en el servidor):

   http://localhost:8080/html-css/index.html

   donde
  • debemos definir el protocolo que el browser va a utilizar
    • http significa HyperText Transfer Protocol 
    • https es el protocolo que implementa secure http, donde los datos viajan encriptados
    • otros protocolos son ftp, gopher (deprecado), etc.
  • luego el servidor web hacia el que vamos a conectarnos
    • el servidor web puede ser una dirección IP o un nombre que luego es convertido a una dirección IP a través de un DNS (Domain Name Server)
    • localhost es el web server que está en la PC local, que equivale a la dirección IP 127.0.0.1
  • luego el puerto donde el servidor está "escuchando" pedidos
    • el port default es 8080
  • y finalmente la página que queremos cargar, que recibe el nombre de recurso
    • en el caso de Java es proyecto + nombre del "recurso"/página: html-css/index.html
    • los pedidos pueden resolverse mediante páginas html estáticas o dinámicas

Tipos de mensaje

Un cliente puede enviar un pedido al servidor utilizando diferentes métodos
  • OPTIONS
  • GET: asociada a una operación de lectura, sin efecto colateral
  • HEAD: es exactamente igual al pedido vía GET pero enviando únicamente el resultado de la operación en un header, sin el contenido o body
  • POST: se suele asociar a una operación que tiene efecto colateral, no repetible
  • PUT: está pensado para agregar información o modificar una entidad existente
  • DELETE: se asocia con la posibilidad de eliminar un recurso existente
  • TRACE
  • CONNECT
Más adelante volveremos sobre esto al estudiar REST. Ahora veremos la diferencia entre hacer un pedido mediante GET vs. POST

Envío mediante GET method

Aquí los parámetros viajan dentro de la URL como par clave=valor: 

http://localhost:8080/time-example.html/index.html?usuario=pepe&password=pepe

  el ? delimita el primer parámetro
  el & delimita los siguientes parámetros

Ventaja: de esta manera es fácil navegar hacia atrás o adelante (incluso si quiero ir 4 páginas para atrás). Limitaciones: en viejas versiones de browsers imponen un límite a la cantidad de caracteres que forman una URL, no es conveniente para pasar información sensible (como password o ciertos identificadores) y necesita codificar los caracteres especiales (p. ej. el espacio lo debe transformar a %20) dado que el request solamente trabaja con el conjunto de caracteres ASCII

Envío mediante POST method

Los parámetros viajan en el BODY del mensaje HTML, no se ven en la URL del browser. Aquí no hay restricciones de tamaño para pasaje de información y tampoco se visualizan los parámetros en la URL del browser. 

Resumen

La recomendación W3C (World Wide Web Consortium) dice que deberíamos usar 
  • GET cuando sepamos que se trata de consultas que no van a tener efecto colateral (no habrá modificación en el estado del sistema)
  • POST cuando sepamos que el procesamiento de la página causará una alteración del estado del sistema (al registrar el alquiler de una película, al modificar los datos de un socio o al eliminar un producto de la venta)

Qué ocurre cuando hay un pedido http

A partir de aquí se definen 4 etapas:
  1. el browser se conecta con el servidor a partir del dominio o IP (localhost = 127.0.0.1) y puerto
  2. se envía la petición al servidor en base a dirección, método, parámetros, etc.
  3. el servidor responde a ese pedido: esa respuesta es una nueva página con un código de estado HTTP: 
    • 200 OK 
    • 401 Unauthorized
    • 403 Forbidden
    • 404 Not found
    • 405 Method not allowed
    • 500 Internal server error, etc. 
    • El lector puede buscar la lista de códigos de error HTTP (la especificación RFC 2616) y formas de resolverlos.
  4. el browser se desconecta del servidor una vez procesada la respuesta
La página es la mínima unidad de información entre cliente y servidor, lo que implica:
  • problemas en la performance: no siempre debería refrescar toda la página si sólo necesito actualizar parcialmente la información de dicha página 
  • problemas en el diseño: tengo dificultades para poder particionar una pantalla en componentes visuales
  • problemas de usabilidad: ejemplos
    • atrapar eventos de usuario requiere trabajo de programación
    • la sensación de parpadeo cada vez que el cliente dispara una acción que debe impactar en el servidor

Cómo recibe la respuesta el browser

El servidor contesta con un string que tiene 
  • un header donde indica el resultado del pedido 
  • un contenido, que forma parte del body, que contiene 
    • tags o etiquetas HTML que el browser puede parsear 
Además de entender el HTML el browser puede 
  • procesar archivos css, o de definición de estilos, que veremos más adelante
  • interpretar código javascript, ya que cuenta con una Virtual Machine propia

Ejemplo

Al buscar "cuarteto de nos" se redirige a la siguiente URL: 

La respuesta se visualiza en formato HTML en el mismo browser:

Presionamos la tecla F12 y activamos así la modalidad de desarrollo. En la solapa Network vemos cada uno de los requests involucrados: con qué método se hizo (GET), la respuesta del server (200), el tipo de archivo, el tamaño del contenido y el tiempo de respuesta, entre otros datos.


Aquí se puede apreciar que la aplicación cliente no solamente baja la respuesta y el contenido html sino que hace varios pedidos de diferentes tipos de archivo (la cuarta columna con encabezado Type):
  • imágenes: image/gif, image/png, image/jpeg, etc.
  • hojas de estilos: text/css, que veremos más adelante
  • código javascript: text/javascript, cuyo lenguaje aprenderemos en breve
  • y otros tipos de archivo que el browser soporta. 
Esta es una herramienta útil para hacer un seguimiento de los pedidos que el cliente va realizando al servidor. 

Consecuencias de la comunicación entre cliente y servidor

String Oriented Programming

Los parámetros recibidos en el servidor vía GET o POST, son siempre strings. Tengo que adaptar no sólo números, fechas y booleanos, también todos los objetos de negocio (socios de un videoclub, alumnos, materias, vehículos de una flota, etc.) incluido las colecciones.

HTTP no tiene estado

Http es un protocolo no orientado a conexión, por este motivo se lo denomina también stateless: cada pedido no guarda ninguna información sobre pedidos anteriores. Como en la película Memento, donde el protagonista tiene pérdida de memoria reciente y se tatúa información importante en la piel, algo así nos termina pasando en los desarrollos web: lo importante lo tenemos que guardar en un lugar accesible ya que de otra forma cada página solamente conoce la información que la página anterior le pasó.

Otros links útiles