Arquitectura de Aplicaciones Web

(1)

Arquitectura de Aplicaciones Web

Servicios y Aplicaciones Telem´aticas

Departamento de Sistemas Telem´aticos y Computaci´on (GSyC)

[email protected]

5 de noviembre de 2008

Departamento de Sistemas Telem´aticos y Computaci´on (GSyC) Arquitectura de Aplicaciones Web Arquitectura SW

Ejemplos de Aplicaciones Web Tecnolog´ıas SW Arquitectura HW

c

2008 Grupo de Sistemas y Comunicaciones. Algunos derechos reservados. Este trabajo se distribuye bajo la licencia Creative Commons Attribution Share-Alike disponible en http://creativecommons.org/licenses/by-sa/2.1/es

(2)

Arquitectura SW de las aplicaciones Web

Es importante mantener tan separados como sea posible l´ogica y

f´ısicamente los siguientes niveles de la arquitectura a la hora de implementar cada uno de ellos:

Datos en almacenamiento estable Lógica de la Aplicación Web Flujo de interacción

Nivel de Presentación APIs Cliente

Servidor

Arquitectura SW de las aplicaciones Web

Datos en almacenamiento estable

Datos almacenados en ficheros, pero normalmente usando una base de datos relacional en el lado del servidor

El primer paso en el desarrollo de la aplicaci´on suele ser pensar

en qué datos almacenar, de dónde conseguirlos, cómo

representarlos

L´ogica de la Aplicaci´on Web

Código que implementa la funcionalidad propia de la aplicación Web. Define qué puede hacer el usuario gracias a la

aplicaci´on. Ej. Acumular en el carrito de la compra productos

que quiere comprar, Realizar la orden de compra una vez que el usuario no quiere m´as productos

Si se cambia la lógica de la aplicación Web se altera la naturaleza de la aplicación: es otra aplicación

Es la ´unica forma de acceder a los datos

Programado en el lado del servidor (PHP, Perl, Ruby, Python, Java, .NET)

(3)

Arquitectura SW de las aplicaciones Web

Flujo de interacci´on

Define la navegación del usuario a través de páginas HTML. Ej. mostrar catálogo de productos como página

principal, si selecciona producto mostrar p´agina con contenidos del carrito, al terminar pedir tarjeta de cr´edito,...

Es posible intercambiar el flujo de interacción por otro, sin modificar la lógica de la aplicación Web

Programado en el lado del servidor (PHP, Perl, Ruby, Python, Java, .NET)

Nivel de Presentaci´on / APIs

La interfaz con el usuario se realiza a trav´es del navegador

Se mantienen separados, por un lado la estructura de la p´agina (marcado HTML), y por otro el aspecto visual (hojas de estilo CSS)

Proporcionando APIs se abre la posibilidad de que terceros definan su propio nivel de presentaci´on y su propio flujo de interacci´on (Ej. mashups)

Peri´

odico electr´

onico

Datos: art´ıculos, usuarios (presentes en casi todas las

aplicaciones) y permisos sobre el web (LDAP, base de datos, etc.)

Lógica de la Aplicación web: mecanismos para subir y editar información en la Web, gestión de estad´ısticas, gestión de publicidad

Nivel de Presentación: Maquetación automática usando plantillas

Flujo de interacci´on, presentaci´on: ver www.elpais.es, www.elmundo.es

(4)

Foro de noticias

Muy similar al periódico electrónico, pero añadiendo como datos de la aplicación los comentarios de los usuarios

Base de datos m´as y m´as compleja: comunidades,

certificaciones de confianza, modificaci´on de art´ıculos y comentarios, etc.

Lógica de la aplicación: mecanismos para puntuación y

selección de noticias, módulo de correo electrónico para enviar

res´umenes y recomendaciones, m´odulo de paso a PDF para

impresi´on y/o conversi´on en “documentos”, buscador (y buscador personalizado)

Nivel de Presentación: módulos XML para servir titulares Flujo de interacción, presentación: ver slashdot.org, meneame.net, barrapunto.com

Comercio electr´

onico

Datos: base de datos con productos, cuentas de clientes, proveedores, etc.

Lógica de la aplicación: seguridad para gestión de datos de facturación, integración con el sistema de correo electrónico (gestión de incidencias), módulo de acceso a entidades financieras (gestión de cobros), comentarios y cr´ıticas de clientes, recomendación automática de art´ıculos, estad´ısticas, programas de afiliados, etc.

Presentaci´on: formularios y plantillas para acceso al sitio

(5)

Aula virtual

Datos administrativos (listados, horarios, tutor´ıas, etc.)

Datos: Streaming de clases grabadas

Lógica de la aplicación: documentos en l´ınea (subida, edición, organización), incluyendo apuntes de alumnos, foros de

interacción, chats, integración con correo electrónico,

encuestas, exámenes y pruebas en l´ınea, gestión de prácticas (entrega, corrección semiautomática, etc.)

Flujo de interacci´on, presentaci´on: ver gsyc.es/moodle

Campus virtual

Añade al aula virtual la siguiente lógica de aplicación: Matriculación y gestión de datos administrativos Gestión de información de proyectos

Servicios de comunicación: correo electrónico, foros, documentación, etc.

Relaci´on con el campus f´ısico (localizaci´on, control de acceso, etc.)

Biblioteca virtual

Gesti´on de compras y de inventario

Obtenci´on de informes de estado y estad´ısticos

(6)

Sitio de fotos

Datos: fotos

Lógica de la aplicación: mecanismos para retocar las fotos, clasificar las fotos en álbumes, buscar fotos, etiquetar las fotos con descripciones para facilitar la búsqueda, añadir

comentarios a las fotos, realizar pase autom´atico de fotos,

mandar a imprimir (con gesti´on de cobro)

Flujo de interacci´on, presentaci´on: ver www.flickr.com, picasaweb.google.es

Red social

Similar a foro de noticias + sitio de fotos

Lógica de la aplicación: mecanismos para gestión del grafo social: X se hace amigo de Y, Z pertenece al grupo de interés G, informe de actividades de un usuario a los miembros de su grafo social

Flujo de interacci´on, presentaci´on: ver www.facebook.com, www.tuenti.com

(7)

Aplicaciones con geolocalizaci´

on

Datos: los usuarios a˜naden datos geolocalizados: fotos, rese˜nas de lugares, ...

Lógica de la aplicación: búsqueda de direcciones, lugares en función de la localización del usuario (WIFI, GPS, GSM, manualmente)

Interconexi´on con Red Social: chatear con amigos que est´en cerca de m´ı

Flujo de interacci´on, presentaci´on: ver maps.google.com, maps.yahoo.com, rummble.com, www.life360.com

Otros ejemplos

Reservas e informaci´on tur´ıstica Agencia de bolsa

Sitio de alojamiento de listas y p´aginas personales Buscador de Internet

(8)

Tecnolog´ıas SW

En el cliente:

En el cliente s´olo cabe elegir entre un navegador web u otro (Firefox, MS Internet Explorer, Opera,...)

La elecci´on delimita el conjunto de tecnolog´ıas SW

disponibles: CSS, XHTML, HTML, DOM, JavaScript, AJAX, Flash,...

En el servidor:

En el servidor hay m´as grados de libertad en cuanto a las tecnolog´ıas a utilizar:

Servidor Web (CGI, FastCGI, Servlets, SSI) Tecnolog´ıas de scripting en el lado del servidor Base de datos

Frameworks

Servidor Web

Dos servidores principales: Apache HTTP Server de la Apache Software Foundation, Internet Information Services (IIS) de Microsoft

FastCGI: con CGI hay que arrancar el programa auxiliar cada vez que llega una nueva petici´on al servidor Web. Con FastCGI se deja arrancado el programa auxiliar, que crea un thread para cada nueva petici´on

Módulos de Apache compilados: usar CGI o FastCGI para arrancar scripts implica arrancar el intérprete. Los módulos de Apache

permiten integrar el código del intérprete con el código del servidor Web, acelerando la ejecución de programas auxiliares en scripts

(9)

Servidor Web

Servlets: tecnolog´ıa Java para generaci´on de contenido

din´amico. Los servlets se integran en un contenedor web que

interact´ua con el servidor Web.

Los Java Servlets son clases Java que corren en el servidor, devolviendo c´odigo HTML al servidor.

Contenedores: Java System Application Server, Apache Tomcat, IBM WebSphere, Oracle Application Server, Apple WebObjects

SSI: Server Side Include

Alternativa a CGI y FastCGI para generación de código dinámico

Primera aproximación a la inclusión de código mezclado con el marcado HTML.

En función de la extensión (.shtml) el servidor sab´ıa que deb´ıa analizar el fichero en busca de directivas que, tras ejecutarse, insertaban nuevo código HTML en el lugar en el que aparec´ıan. Departamento de Sistemas Telemáticos y Computación (GSyC) Arquitectura de Aplicaciones Web

Arquitectura SW Ejemplos de Aplicaciones Web Tecnolog´ıas SW Arquitectura HW

Tecnolog´ıas de

scripting

en el lado del servidor

En lugar de incluir directivas SSI en las p´aginas HTML se puede utilizar la potencia de un lenguaje de scripting

Los lenguajes de scripting aportan mayor portabilidad frente a

los compilados: los scripts no necesitan ser recompilados para otro SSOO o arquitectura, siempre que exista un int´erprete

Son m´as lentos, pero cada vez menos.

Existen m´ultiples alternativas.

ASP/ASP.NET (Mundo Microsoft IIS) PHP

Python Ruby

Java. JSP (JavaServer Pages) es el equivalente en el mundo Java a ASP o PHP: c´odigo Java mezclado en las p´aginas

(10)

Base de datos

Normalmente se utilizan RDBMS (bases de datos relacionales), aunque hay otros modelos de BD (p.ej. orientadas a objetos, usada en Zope)

Oracle

Microsoft SQL Server IBM DB2

Open Source: MySQL, PostgreSQL

Frameworks

Facilitan la programación de Aplicaciones Web, simplificando la interfaz con la BD, la gestión de formularios, sesiones, Ajax, ... permitiendo al programador centrarse en los aspectos de la lógica de la Aplicación Web

.NET framework Ruby on Rails

Java: Struts, Spring, Tapestry,... Python: Django, Zope

(11)

Arquitectura LAMP

LAMP: Linux, Apache, MySQL, Perl (PHP, Python, Ruby,...)

Acrónimo utilizado para referirse a un conjunto de tecnolog´ıas comúnmente utilizadas en muchos sitios Web de éxito (en el propio Google)

Alternativa del mundo del software libre a las plataformas de Microsoft (ASP) y Sun (Java)

Arquitectura HW

Conjunto de m´aquinas, con sus componentes HW y software

de sistemas (SO, BD,...)

Se necesitan varios tipos de m´aquinas, cada una de ellas corriendo diferente sw de sistemas

Para comenzar se puede utilizar HW est´andar (PCs con

GNU/Linux p.ej.) Sitios como Google llevan esta soluci´on al

extremo: cientos de miles de PCs est´andar con GNU/Linux

En cuanto al SW de sistemas, cualquier distribución de GNU/Linux estándar, sin configuración especial, vale para arrancar. Luego se puede ir configurando ajustando

par´ametros del kernel, de la instalaci´on de MySQL,...

Al final de un proyecto para desarrollar una aplicaci´on Web el coste del desarrollo del SW es grande, pero al principio hay

(12)

Arquitectura HW: ejemplo 1

Internet Router/ Cortafuegos Equilibrado de carga

Servidor HTTP Servidor HTTP Servidor HTTP

Servidor de Aplicaciones Servidor de Aplicaciones Servidor de Aplicaciones Base de Datos Router/ Cortafuegos servidor de cache memcached servidor de cache memcached servidor de cache memcached Equilibrado de carga N1 N2 N3 N4 N5

Arquitectura HW: ejemplo 2

Wikipedia (2007) Más de 75000 editores 5.300.000 art´ıculos (2M en inglés) En más de 100 lenguas 100 servidores en varias localizaciones geográficas

(13)

¿D´

onde instalar el HW?

Instalaci´on tradicional en proveedor:

HW compartido: un proveedor de servicios de Internet o de hospedaje de sitios Web permite que se instale SW en una de sus máquinas (PC) junto al SW de otros. Solución buena y barata para prototipar y lanzar la aplicación Web.

HW dedicado: el proveedor dedica HW espec´ıfico para la aplicaci´on (ej. un PC). Puede dejarnos una cuenta (ellos instalan el SO) o dejarnos instalar el SO.

HW nuestro: nos dejan espacio, energ´ıa y conexión a la red. Nosotros ponemos el HW. Servicios: monitorizar la aplicación Web y diagnosticar el problema por teléfono vs. monitorizar sólo el acceso a la red y rearrancar máquinas.

¿D´

onde instalar el HW?

Instalaci´on en la nube (cloud computing): mediante APIs se hace transparente el uso del HW del proveedor, usando recursos

virtuales. Permite empezar con poco y luego hacer escalar

fácilmente gracias a que el proveedor tiene muy automatizada la configuración / instalación / cobro según recursos utilizados

Framework en la nube. Se ofrece una plataforma de

desarrollo de aplicaciones (Rails, Django) en la red. Mediante APIs se puede subir c´odigo de la aplicaci´on Web.

Transparencia: no se sabe en qué máquinas correrá:

gestionado por el proveedor, quien hace escalar. Ej. Google App Engine, Mosso.com, Force.com

Infraestructura en la nube. El proveedor ofrece servicios de más bajo nivel: host virtual en el que instalar uno u otro SO, capacidad de almacenamiento, ancho de banda. Ej. Amazon Web Services (Microsoft y otros están detrás de este negocio).

(14)

¿D´

onde instalar el HW?

En casa:

Solución para muy pequeñas (PC a través de ADSL) o muy grandes instalaciones.

Ej. de gran instalaci´on: Google (cientos de miles de m´aquinas).

Edificio, operadores para monitorizar, conexiones redundantes a la red el´ectrica, servicios de alimentaci´on ininterrumpida, sistemas antiincendios, contratos con varios proveedores de Internet,...

Referencias:

Cap´ıtulo 2 (Web Application Architecture) Building Scalable

Web Sites. Cal Henderson. O’Reilly 2006. http://proquest.safaribooksonline.com/0596102356