Servicios y Aplicaciones Telemáticas gsyc-profes@gsyc.escet.urjc.es 5 de noviembre de 2008 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
de las aplicaciones Web Es importante mantener tan separados como sea posible lógica y físicamente los siguientes niveles de la arquitectura a la hora de implementar cada uno de ellos: Cliente Nivel de Presentación APIs Servidor Flujo de interacción Lógica de la Aplicación Web Datos en almacenamiento estable 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ón suele ser pensar en qué datos almacenar, de dónde conseguirlos, cómo representarlos Lógica de la Aplicación Web Código que implementa la funcionalidad propia de la aplicación Web. Define qué puede hacer el usuario gracias a la aplicación. 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ás 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 única forma de acceder a los datos Programado en el lado del servidor (PHP, Perl, Ruby, Python, Java,.NET)
de las aplicaciones Web Flujo de interacción 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ágina con contenidos del carrito, al terminar pedir tarjeta de crédito,... 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ón / APIs La interfaz con el usuario se realiza a través del navegador Se mantienen separados, por un lado la estructura de la página (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ón y su propio flujo de interacción (Ej. mashups) Periódico electrónico 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ón, presentación: ver www.elpais.es, www.elmundo.es
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ás y más compleja: comunidades, certificaciones de confianza, modificación 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úmenes y recomendaciones, módulo de paso a PDF para impresión y/o conversión 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ónico 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ón: formularios y plantillas para acceso al sitio Flujo de interacción, presentación: ver www.amazon.com, optize.es
Aula virtual Datos administrativos (listados, horarios, tutorías, etc.) Datos: Streaming de clases grabadas Lógica de la aplicación: documentos en ĺı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 ĺınea, gestión de prácticas (entrega, corrección semiautomática, etc.) Flujo de interacción, presentación: 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ón con el campus físico (localización, control de acceso, etc.) Biblioteca virtual Gestión de compras y de inventario Obtención de informes de estado y estadísticos Flujo de interacción, presentación: ver www.campusvirtual.urjc.es
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ático de fotos, mandar a imprimir (con gestión de cobro) Flujo de interacción, presentación: 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ón, presentación: ver www.facebook.com, www.tuenti.com
Aplicaciones con geolocalización Datos: los usuarios añaden datos geolocalizados: fotos, reseñas 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ón con Red Social: chatear con amigos que estén cerca de mí Flujo de interacción, presentación: ver maps.google.com, maps.yahoo.com, rummble.com, www.life360.com Otros ejemplos Reservas e información turística Agencia de bolsa Sitio de alojamiento de listas y páginas personales Buscador de Internet...
En el cliente: En el cliente sólo cabe elegir entre un navegador web u otro (Firefox, MS Internet Explorer, Opera,...) La elección delimita el conjunto de tecnologías SW disponibles: CSS, XHTML, HTML, DOM, JavaScript, AJAX, Flash,... En el servidor: En el servidor hay más 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ón al servidor Web. Con FastCGI se deja arrancado el programa auxiliar, que crea un thread para cada nueva petición 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
Servidor Web Servlets: tecnología Java para generación de contenido dinámico. Los servlets se integran en un contenedor web que interactúa con el servidor Web. Los Java Servlets son clases Java que corren en el servidor, devolviendo código 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. Tecnologías de scripting en el lado del servidor En lugar de incluir directivas SSI en las páginas 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érprete Son más lentos, pero cada vez menos. Existen múltiples 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ódigo Java mezclado en las páginas HTML.
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 PHP: CakePHP, Zoop, Zend,
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) Conjunto de máquinas, con sus componentes HW y software de sistemas (SO, BD,...) Se necesitan varios tipos de máquinas, cada una de ellas corriendo diferente sw de sistemas Para comenzar se puede utilizar HW estándar (PCs con GNU/Linux p.ej.) Sitios como Google llevan esta solución al extremo: cientos de miles de PCs estándar 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ámetros del kernel, de la instalación de MySQL,... Al final de un proyecto para desarrollar una aplicación Web el coste del desarrollo del SW es grande, pero al principio hay una inversión importante: el HW
: ejemplo 1 N1 Internet N2 Router/ Cortafuegos Router/ Cortafuegos Equilibrado de carga Equilibrado de carga N3 Servidor HTTP Servidor HTTP Servidor HTTP N4 Servidor de Aplicaciones Servidor de Aplicaciones Servidor de Aplicaciones servidor de cache memcached servidor de cache memcached servidor de cache memcached N5 Base de Datos : 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
Dónde instalar el HW? Instalación 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ón (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ónde instalar el HW? Instalación 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ódigo de la aplicación 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). Pagos por uso (bytes almacenados, Arquitectura tiempo de Aplicaciones de CPU, Web bytes transferidos)
Dónde 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ón: Google (cientos de miles de máquinas). Edificio, operadores para monitorizar, conexiones redundantes a la red eléctrica, servicios de alimentación 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 de Wikipedia. http://meta.wikimedia.org/wiki/wikimedia servers