Publicado el 3 de Julio del 2017
678 visualizaciones desde el 3 de Julio del 2017
242,1 KB
40 paginas
Creado hace 16a (14/04/2009)
Aplicaciones Web
Introducción
David Cabrero Souto
Grupo MADS (http://www.grupomads.org/)
Universidade da Coruña
Ingredientes principales
Arquitectura Cliente/Servidor
Protocolos y estándares Web
HTTP, W3C
Cliente/Servidor: Introducción
Tres componentes:
Cliente
Servidor
Middleware (límites difusos)
Comunicaciones (síncrono o asíncrono)
Integración
Transparencia (topología, representación datos, . . . )
Seguridad
Cardinalidad: 1 servidor, n clientes
Varios tipos y clasificaciones
ClienteServidorMiddlewareC/S: clasificación (cliente grueso vs. delgado)
Cliente grueso vs. Cliente delgado
C/S: clasificación (cliente grueso vs. delgado)
Cliente grueso vs. Cliente delgado
Ejemplo de cliente grueso:
loginpasswrdAlmacenamientoLógica de negocioBB.DD.C/S: clasificación (cliente grueso vs. delgado)
Cliente grueso vs. Cliente delgado
Cliente grueso. Ventajas e inconvenientes:
Menos carga en el servidor
Mayores requisitos hardware en cliente
Cliente menos portable
Más tráfico de red
Administración más compleja
C/S: clasificación (cliente grueso vs. delgado)
Cliente grueso vs. Cliente delgado
Ejemplo de cliente delgado:
loginpasswrdLógica de negocioAlmacenamientoC/S: clasificación (cliente grueso vs. delgado)
Cliente grueso vs. Cliente delgado
Cliente delgado. Ventajas e inconvenientes:
Servidor muy cargado
Mayores requisitos hardware en servidor (escalabilidad)
Cliente más portable
Menos tráfico de red
Administración menos compleja
C/S: clasificación (2,3,n-tier)
2 niveles (2-tier).
Ejemplos: Los vistos en cliente grueso/delgado.
3 niveles (3-tier).
La aplicación se divide en partes (niveles).
n niveles (n-tier).
Generalización de 3-tier.
Mejor aproximación a aplicaciones complejas.
Ventajas, inconvenientes:
C/S: clasificación (2,3,n-tier)
2 niveles (2-tier).
Ejemplos: Los vistos en cliente grueso/delgado.
3 niveles (3-tier).
La aplicación se divide en partes (niveles).
Ejemplo:
n niveles (n-tier).
Generalización de 3-tier.
Mejor aproximación a aplicaciones complejas.
Ventajas, inconvenientes:
loginpasswrdLógica de negocioAlmacenamientoBB.DD.ContabilidadFacturaciónC/S: clasificación (2,3,n-tier)
2 niveles (2-tier).
Ejemplos: Los vistos en cliente grueso/delgado.
3 niveles (3-tier).
La aplicación se divide en partes (niveles).
n niveles (n-tier).
Generalización de 3-tier.
Mejor aproximación a aplicaciones complejas.
Ventajas, inconvenientes:
Diseño, desarrollo más complejos, más infraestructura.
Flexibilidad (cambios, nueva funcionalidad, . . . ).
Escalabilidad.
C/S: clasificación (2,3,n-tier)
2 niveles (2-tier).
Ejemplos: Los vistos en cliente grueso/delgado.
3 niveles (3-tier).
La aplicación se divide en partes (niveles).
n niveles (n-tier).
Generalización de 3-tier.
Mejor aproximación a aplicaciones complejas.
Ventajas, inconvenientes:
y mantenimientoCoste de desarrolloarquitecturade 3 nivelesarquitecturade 2 nivelesy tiempo de vidaComplejidad de la aplicaciónAplicaciones Web
Originalmente pensada para intercambio de documentos
Arquitectura Cliente/Servidor
Cliente delgado
Protocolos y estándares Web
IETF: HTTP/1.0 (RFC 1945), HTTP/2.0 (RFC 2068)
W3C: HTML 4.0, XHTML, CSS
Protocolo HTTP
Modelo petición/respuesta (RPC)
Protocolo sin estado
Habitual, pero no obligatorio: TCP/IP (80, 443)
Se establece una conexión, y se intercambia petición de
recurso, respuesta
Protocolo HTTP. Peticiones
Texto ASCII, Human readable.
Varias líneas de texto (1..n).
Primera línea (obligatoria):
Petición URI
GET
/index.html HTTP/1.1
Versión
Existen varios tipos de petición: GET, POST, HEAD, . . .
Siguientes líneas: cabeceras
Una cabecera por línea. Formato: nombre: valor
En HTTP/1.0 las cabeceras son opcionales.
En HTTP/1.1 algunas cabeceras son obligatorias.
Ejemplo: host: www.grupomads.org
Las cabeceras terminan con una línea en blanco.
Opcionalmente puede haber un cuerpo de la petición con
datos arbitrarios.
Protocolo HTTP. Peticiones
Texto ASCII, Human readable.
Varias líneas de texto (1..n).
Primera línea (obligatoria):
Petición URI
GET
/index.html HTTP/1.1
Versión
Existen varios tipos de petición: GET, POST, HEAD, . . .
Siguientes líneas: cabeceras
Una cabecera por línea. Formato: nombre: valor
En HTTP/1.0 las cabeceras son opcionales.
En HTTP/1.1 algunas cabeceras son obligatorias.
Ejemplo: host: www.grupomads.org
Las cabeceras terminan con una línea en blanco.
Opcionalmente puede haber un cuerpo de la petición con
datos arbitrarios.
Protocolo HTTP. Peticiones
Texto ASCII, Human readable.
Varias líneas de texto (1..n).
Primera línea (obligatoria):
Petición URI
GET
/index.html HTTP/1.1
Versión
Existen varios tipos de petición: GET, POST, HEAD, . . .
Siguientes líneas: cabeceras
Una cabecera por línea. Formato: nombre: valor
En HTTP/1.0 las cabeceras son opcionales.
En HTTP/1.1 algunas cabeceras son obligatorias.
Ejemplo: host: www.grupomads.org
Las cabeceras terminan con una línea en blanco.
Opcionalmente puede haber un cuerpo de la petición con
datos arbitrarios.
Protocolo HTTP. Peticiones
Texto ASCII, Human readable.
Varias líneas de texto (1..n).
Primera línea (obligatoria):
Petición URI
GET
/index.html HTTP/1.1
Versión
Existen varios tipos de petición: GET, POST, HEAD, . . .
Siguientes líneas: cabeceras
Una cabecera por línea. Formato: nombre: valor
En HTTP/1.0 las cabeceras son opcionales.
En HTTP/1.1 algunas cabeceras son obligatorias.
Ejemplo: host: www.grupomads.org
Las cabeceras terminan con una línea en blanco.
Opcionalmente puede haber un cuerpo de la petición con
datos arbitrarios.
Protocolo HTTP. Respuestas
Similar a las peticiones.
Primera línea:
Versión
HTTP/1.0 200
Código Descripción
OK
Cabeceras. Importante, p.e. Content-type: text/html
Línea en blanco y a continuación el recurso solicitado.
Protocolo HTTP. Respuestas
Similar a las peticiones.
Primera línea:
Versión
HTTP/1.0 200
Código Descripción
OK
Cabeceras. Importante, p.e. Content-type: text/html
Línea en blanco y a continuación el recurso solicitado.
Protocolo HTTP. Respuestas
Similar a las peticiones.
Primera línea:
Versión
HTTP/1.0 200
Código Descripción
OK
Cabeceras. Importante, p.e. Content-type: text/html
Línea en blanco y a continuación el recurso solicitado.
Protocolo HTTP. Extensión
El protocolo HTTP se puede extender de varias formas.
Nuevos tipos de peticiones.
Ejemplo: DAV (PROPFIND, LOCK, WRITE, COPY, . . . )
Añadiendo información en las cabeceras.
Ejemplos: autenticación, cookies, . . .
Protocolo HTTP. Extensión
El protocolo HTTP se puede extender de varias formas.
Nuevos tipos de peticiones.
Ejemplo: DAV (PROPFIND, LOCK, WRITE, COPY, . . . )
Añadiendo información en las cabeceras.
Ejemplos: autenticación, cookies, . . .
Modelo de aplicaciones web
Servidor:
1 Recibir petición.
2 Procesar petición.
3 Generar respuesta (i.e. página web).
Cliente:
Muestra páginas.
Recibe entrada del usuario.
Modelo de aplicaciones web
Servidor:
1 Recibir petición.
2 Procesar petición.
3 Generar respuesta (i.e. página web).
Cliente:
Muestra páginas.
Recibe entrada del usuario.
Modelo de aplicaciones web (cont.)
Modelo de aplicaciones web (cont.)
Cuestiones adicionales:
Mapear URIs al API del servidor.
Paso de parámetros.
Implementar estado.
Relación con servidor web.
Es habitual que un servidor web reciba todas las peticiones.
Delega las peticiones correspondientes a la aplicación:
CGI
Integración con el servidor web (p.e. módulos apache)
Contenedor de aplicaciones (p.e. tomcat)
Evitamos implementar el protocolo HTTP.
Modelo de aplicaciones web (cont.)
Cuestiones adicionales:
Mapear URIs al API del servidor.
Paso de parámetros.
Implementar estado.
Relación con servidor web.
Es habitual que un servidor web reciba todas las peticiones.
Delega las peticiones correspondientes a la aplicación:
CGI
Integración con el servidor web (p.e. módulos apache)
Contenedor de aplicaciones (p.e. tomcat)
Evitamos implementar el protocolo HTTP.
CGI
CGI (Common Gateway Interface).
Protocolo para intercambio de información entre el servidor
web y una aplicación externa.
Paso 1: del servidor a la aplicación externa.
La aplicación se lanza en un proceso nuevo.
Parte de la información en las variables de entorno.
La especificación CGI define un conjunto de variables, tanto
obligatorias como opcionales.
Ejemplos: SERVER_SOFTWARE, PATH_INFO, . . .
Parte de la información en la entrada estándar de la aplicación.
El cuerpo de las peticiones POST y PUT.
Paso 2: de la aplicación externa al servidor.
La respuesta se escribe en la salida estándard.
La respuesta comenzará por una cabecera HTTP.
Content-type
Location
Status
CGI
CGI (Common Gateway Interface).
Protocolo para intercambio de información entre el servidor
web y una aplicación externa.
Paso 1: del servidor a la aplicación externa.
La aplicación se lanza en un proceso nuevo.
Parte de la información en las variables de entorno.
La especificación CGI define un conjunto de variables, tanto
obligatorias como opcionales.
Ejemplos: SERVER_SOFTWARE, PATH_INFO, . . .
Parte de la información en la entrada estándar de la aplicación.
El cuerpo de las peticiones POST y PUT.
Paso 2: de la aplicación externa al servidor.
La respuesta se escribe en la salida estándard.
La respuesta comenzará por una cabecera HTTP.
Content-type
Location
Status
CGI
CGI (Common Gateway Interface).
Protocolo para intercambio de información entre el servidor
web y una aplicación externa.
Paso 1: del servidor a la aplicación externa.
La aplicación se lanza en un proceso nuevo.
Parte de la información en las variables de entorno.
La especificación CGI define un conjunto de variables, tanto
obligatorias como opcionales.
Ejemplos: SERVER_SOFTWARE, PATH_INFO, . . .
Parte de la información en la entrada estándar de la aplicación.
El cuerpo de las peticiones POST y PUT.
Paso 2: de la aplicación externa al servidor.
La respuesta se escribe en la salida estándard.
La respuesta comenzará por una cabecera HTTP.
Content-type
Location
Status
Comentarios de: Aplicaciones Web - Introducción (0)
No hay comentarios