01. introducción al web

195 views
148 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
195
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

01. introducción al web

  1. 1. Introducción al desarrollo de aplicaciones Web
  2. 2. César F.AcebalDaniel F.LanvinIntroducción a Internet y el Web El Web es una vasta colección de documentos en Internet que estánenlazados a través de los hiperenlaces Internet: millones de ordenadores conectadosInternet: millones de ordenadores conectadosUn conjunto de redes heterogéneasconectadas entre sí mediante el protocoloTCP/IP Los hiperenlaces permiten a los usuarios acceder aLos hiperenlaces permiten a los usuarios acceder adocumentos situados en otros servidores Web, sindocumentos situados en otros servidores Web, sinpreocuparse de su ubicaciónpreocuparse de su ubicación
  3. 3. Tecnologías clave de Internet
  4. 4. César F.AcebalDaniel F.LanvinTecnologías claves de Internet La infraestructura de Internet es proporcionadafundamentalmente por tres tecnologías: La conmutación de paquetesconmutación de paquetes El protocolo TCP/IPTCP/IP La arquitectura cliente/servidorcliente/servidor
  5. 5. César F.AcebalDaniel F.LanvinConmutación de paquetes Es la tecnología que emplea la red Internet Los mensajes se dividen en paquetes A cada paquete se le añaden la dirección de origen y destino, el número desecuencia, información de control de errores… En vez de enviarse directamente a la dirección de destino, los paquetesviajan de una máquina a otra hasta alcanzar su destino Estas máquinas se denominan routersroutersOrdenadores que interconectan las diferentes subredes y que son capaces deencaminar los paquetes de una a otraPara asegurar que siguen la mejor ruta disponible, utilizan programas llamadosalgoritmos de encaminamientoalgoritmos de encaminamiento (“routing algorithms”)
  6. 6. César F.AcebalDaniel F.LanvinTCP/IP Si bien la conmutación de paquetes supuso un gran avanceen la capacidad de las redes de comunicaciones, era necesarioimplementar el modo de llevarla a cabo Eso es de lo que se encargan los protocolos TCP/IPTransmission Control Protocol (TCP)Transmission Control Protocol (TCP)Internet Protocol (IP)Internet Protocol (IP) Un protocolo es un conjunto de reglas para formatear, ordenar ycomprimir mensajes, comprobar errores, etc.Pueden ser implementados por hardware o por software
  7. 7. César F.AcebalDaniel F.LanvinDirecciones IP Cada ordenador conectado a Internet debe tener una dirección parapoder recibir los paquetes TCP. Ésta puede ser: Estática Fija, siempre la misma DinámicaPor ejemplo, cada vez que nos conectamos a Internet con un módem telefónico,nuestro proveedor de Internet (ISP, Internet Service Provider) nos asigna unadirección temporal Las direcciones IP son números de 32 bits separados en cuatro partes(por ejemplo, 156.35.94.5) Cada uno va de 0 a 255; esto nos da un total de 232direcciones (algo más decuatro mil millones)
  8. 8. César F.AcebalDaniel F.LanvinNombres de dominio y URL Para no tener que recordar direcciones IP tal cual, éstaspueden ser representadas mediante nombres de dominio (porejemplo, www.euitio.uniovi.es) El sistema de nombres de domino (DNS) permite que éstasse resuelvan a direcciones IP Ejemplo: ping www.euitio.uniovi.esping www.euitio.uniovi.es Los URL (Uniform Resource Locator) son las direccionesque escribimos en el navegador Como http://www.euitio.uniovi.es/http://www.euitio.uniovi.es/
  9. 9. César F.AcebalDaniel F.LanvinComputación Cliente/Servidor En este modelo de computación distribuida, un cliente solicita unaacción a un servidor, que le devuelve los resultados Puede haber diversos tipos de clientes, desde los más ligerosligeros (como unnavegador Web, que únicamente es capaz de mostrar documentos HTML)hasta clientes pesadosclientes pesados que también realizan procesamiento Surgen como respuesta a los mainframes de los 60 y 70 (con 128 KB deRAM y y discos duros de 10 MB) Despega este modelo con el advenimiento de los ordenadores personalesordenadores personales Toda Internet es una inmensa red cliente/servidor
  10. 10. Introducción al Web
  11. 11. César F.AcebalDaniel F.LanvinInternet ≠ Web Internet permite a cualquier ordenador del mundo compartirdatos con otro ordenador remoto Un programa cliente en un ordenador accede a un programa servidor enotro ordenador remoto El Web es el sistema de hipertexto que funciona sobre Internetcomo uno de sus serviciosEn este caso, el programa cliente es nuestro navegador, y el servidorel programa que hace de servidor Web que está ejecutándose en elordenador remoto y que se encarga de entregar el documento solicitadoa nuestro navegador
  12. 12. César F.AcebalDaniel F.LanvinNacimiento del World Wide Web En 1989, Tim Berners-Lee, en el laboratorioeuropeo de partículas (CERN), en Suiza, crea unlenguaje de etiquetas para representar y enlazardocumentosHTMLHTML —HyperText Markup Language—HyperText Markup LanguageLenguaje de Marcado de HipertextoLenguaje de Marcado de Hipertexto Berners-Lee creó las versiones iniciales de: HTMLHTML, HTTPHTTP, un servidor Webservidor Web y un navegadornavegador Los cuatro componentes esenciales del WebTim Berners-Lee
  13. 13. César F.AcebalDaniel F.Lanvin¿Cómo funciona?1. El usuario solicita un documento tecleando su dirección en el navegador:http://www.uniovi.es Es lo que se denomina un URL (localizador uniforme de recursos)2. El cliente busca en el DNS cuál es la IP de www.uniovi.es: 156.35.14.3 Cada ordenador en Internet está identificado por una dirección únicadenominada IP El DNS traduce de nombres lógicos a direcciones físicas.El DNS es un servicio de nombrado3. Navegador y servidor web comienzan un diálogo a través del protocoloHTTP (protocolo de transferencia de hipertexto)1. GET /HTTP/1.02. El servidor, si todo es correcto, devuelve el documento solicitado más informaciónadicional
  14. 14. César F.AcebalDaniel F.Lanvin¿Cómo funciona?4. El navegador mira el tipo de documento devuelto (MIME)5. Si es “text/html” es un documento HTML, lo visualiza el propio navegador6. Si es otro tipo de documento se ejecutará el programa que tenga asociado, onos preguntará si queremos guardar el documento en nuestro ordenador Nota: estos tipos MIME los podemos configurar en nuestro navegador
  15. 15. César F.AcebalDaniel F.LanvinConceptos Básicos de la WEB Un servidor Web es un ordenador en Internet que sirvepáginas Web y contenido estático en general a petición Para ello, debe tener un programa ejecutándose que haga de servidorWeb: Apache, IIS, etcétera El usuario accede al Web a través de un navegador(browser) Se encarga de solicitar las páginas Web al servidor y de mostrarlas
  16. 16. César F.AcebalDaniel F.LanvinEl Lenguaje HTML Es el lenguaje de creación de páginas Web Al menos, de las páginas “estáticas” Era imprescindible que la misma información se pudiese veren diferentes plataformas Por tanto, Berners-Lee diseñó un lenguaje de estructuraciónde documentos, no de presentación (ésta se dejaba alprograma cliente)
  17. 17. César F.AcebalDaniel F.LanvinHTML es un lenguaje Como tal, tiene unas reglas que deben ser cumplidas, esto es,una sintaxis, una gramática... igual que el español o cualquierotro lenguaje informático Es además un lenguaje informático, para ser procesado porordenadores; pero no es un lenguaje de programación
  18. 18. César F.AcebalDaniel F.LanvinHTML, lenguaje de hipertexto Por hipertexto designamos al texto al que se le añade unapropiedad: determinadas porciones de texto pueden serenlazadas a otros documentos De ahí surge el concepto de navegación: surcamos el Webyendo de unos enlaces a otros El hipertexto debe ser utilizado en los sitios web para facilitaral usuario la labor de búsqueda de la información
  19. 19. César F.AcebalDaniel F.LanvinEspecificación de HTML La especificación del lenguaje HTML y de la mayoría detecnologías relacionadas con el Web está definida por elWorld Wide Web Consortium (W3C) www.w3c.org
  20. 20. César F.AcebalDaniel F.LanvinEjemplo de documento HTML<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>Introducción a HTML</title></head><body><h1>Mi primera página Web</h1><p>Éste es el equivalente al típico <em>¡Hola, mundo!</em>pero en HTML (cuya <a href="http://www.w3.org/MarkUp/"title="Especificación de las distintas versiones deHTML y XHTML en el W3C">especificación</a> puede encontrarseen el sitio Web del<acronym title="World Wide Web Consortium">W3C</acronym>).</p></body></html>holaMundo.htmlholaMundo.html
  21. 21. César F.AcebalDaniel F.LanvinEl protocolo HTTP HTTP (HyperText Transform Protocol) es el protocolousado para transferir páginas Web Es el modo en que un navegador se comunica con un servidor Web(Apache, Internet Information Server…) Es un protocolo sin estado La sesión termina en cuanto se devuelve el objeto solicitadoIncluso, si una página contiene otros objetos (imágenes, frames, etc.)cada uno de ellos inicia una nueva petición HTTP
  22. 22. César F.AcebalDaniel F.LanvinEjemplo de mensaje HTTPGET / HTTP/1.0 >><HTTP/1.0 200 OK <Date: Wed, 18 Sep 1996 20:18:59 GMT <Server: Apache/1.0.0 <Content-type: text/html <Content-length: 1579 <Last-modified: Mon, 22 Jul 1996 22:23:34 GMT <<HTML documentRespuestaRespuestaPeticiónPetición
  23. 23. César F.AcebalDaniel F.LanvinLas URLs URI: Uniform Resource Identifier URL: Uniform Resource Locator Un URL es la dirección única de todo documentoen el Webhttp://www.eutio.uniovi.es/http://www.eutio.uniovi.es/
  24. 24. César F.AcebalDaniel F.LanvinSintaxis de un URL Ejemplos:http://www.princast.es/http://www.princast.es/http://195.55.30.17/http://195.55.30.17/http://www.cfacebal.com/http://www.cfacebal.com/http://www.cfacebal.com/index.htmlhttp://www.cfacebal.com/index.htmlhttp://web.uniovi.es/Vicerrectorados/Extension/http://web.uniovi.es/Vicerrectorados/Extension/http://localhost:8080/http://localhost:8080/http://petra.euitio.uniovi.es/http://petra.euitio.uniovi.es/protocolo://dirección[:puerto]/directorio/ficheroprotocolo://dirección[:puerto]/directorio/fichero
  25. 25. César F.AcebalDaniel F.LanvinSintaxis URL: Protocolo Un protocolo define el modo en que se comunican dosordenadores para llevar a cabo alguna tarea Protocolo del Web:HTTP (HyperText Transfer Protocol)HTTP (HyperText Transfer Protocol) Especifica cómo tiene lugar el diálogo entre el navegador y elservidor para conseguir el fichero especificado No se ocupa del transporte en sí: TCPTCP Cada vez que tecleamos una dirección o pulsamos un enlaceel navegador se comunica vía HTTP con el servidor Webindicado
  26. 26. César F.AcebalDaniel F.LanvinSintaxis URL: Ejemplos de protocolosfile Permite acceder a un fichero en el sistema de ficheros localftp File Transfer Protocolhttp Páginas WebLas URLs no son algo específico de internet o de la WEB. Ejemplo:Abrir el internet explorer y, en lugar de poner una url http en la barrade navegación, abrir el fichero local c:boot.ini mediante:file://C:boot.ini
  27. 27. César F.AcebalDaniel F.LanvinSintaxis URL: Dirección del sitio Suele ser un nombre simbólico: nombre de dominio www.uniovi.es especifica una máquina llamada “www” en el dominio“uniovi.es” El nombre de máquina puede ser cualquiera“www” no es más que un convenio para especificar aquellas máquinasque son servidores Webcomo “ftp” suele designar a los servidores de FTPincluso aunque muchas veces se trate de la misma máquina
  28. 28. César F.AcebalDaniel F.LanvinSintaxis URL: Dirección del sitio También podría ser directamente la dirección IP http://156.35.14.3/ Los nombres de dominio no distinguen entre mayúsculas yminúsculas http://www.uniovi.es/ http://WWW.UNIOVI.ES/ http://wWw.UniOvi.es/ Tampoco (para nuestra desgracia) tienen Ñs!. Ej:http://www.eldiariomontanes.eshttp://www.lanuevaespana.es
  29. 29. César F.AcebalDaniel F.LanvinSintaxis URL: Directorio Hay que indicar la ruta hasta el fichero deseado Como mínimo, debe ir la barra (“/”)http://www.uniovi.eshttp://www.uniovi.es// Si no la ponemos, la pone el navegador por nosotros También se puede indicar un subdirectorio:http://www.uniovi.es/Vicerrectorados/Postgrado_TitulosPropios/doctorado/http://www.uniovi.es/Vicerrectorados/Postgrado_TitulosPropios/doctorado/ Siempre se usa la barra “/”, no “” (incluso aunque el servidor Web sea unamáquina Windows: está definido por el estándar URI, no depende del SO) La ruta sí puede diferenciar entre mayúsculas y minúsculas (si el servidorWeb es, por ejemplo, una máquina Unix)
  30. 30. César F.AcebalDaniel F.LanvinSintaxis URL: Nombre del fichero Depende del SO del servidor Web Las páginas Web generalmente tienen como extensión .html o .htm Las extensiones son importantes para que el navegador sepa cómotratar un fichero un .html, lo interpreta y lo muestra un .jpg, trata de mostrar la imagen un .doc, abre el Word si lo tenemos instalado etcétera
  31. 31. César F.AcebalDaniel F.LanvinSintaxis URL: Nombre del fichero Si no se especifica, el servidor busca un fichero con unnombre determinado en el directorio especificado Normalmente, el index.htmlindex.html o el index.htmindex.htm Se puede configurar en el programa que utilicemos como servidorWeb (Apache, IIS...)
  32. 32. César F.AcebalDaniel F.LanvinSintaxis URL: Puerto Por omisión, una petición HTTP se dirige al puerto 80 Por eso casi nunca la especificamos Pero se podría configurar el servidor Web para que “escuchase”peticiones en otro puerto En ese caso, hay que indicarlo explícitamente:http://www.midominio.comhttp://www.midominio.com:8080:8080//En el Caso de OC4J: Puerto 8888.Ej:http://localhost:8888http://localhost:8888
  33. 33. César F.AcebalDaniel F.Lanvin¿Qué es un servidor Web? Un programa que atiende las peticiones HTTP llegadas a unpuerto determinado de la máquina También se denomina así, por extensión, a la máquina que cuentacon uno de tales programas Ejemplos de servidores Web: ApacheApache HTTP Server Project http://httpd.apache.org/ Internet Information Server (IIS)
  34. 34. César F.AcebalDaniel F.LanvinPáginas estáticas Al principio, el Web estaba poblado únicamente por páginasestáticas El servidor Web simplemente localizaba el documento solicitado enel URL y se lo entregaba al cliente Esto no permitiría, por ejemplo, crear un sitio de comercioelectrónico donde se pueda comprar, o el de un banco Es necesario acceder a datos en el servidor y crear una página apetición
  35. 35. César F.AcebalDaniel F.LanvinFuncionamiento de las páginas estáticas
  36. 36. César F.AcebalDaniel F.LanvinFuncionamiento de las páginas dinámicas
  37. 37. César F.AcebalDaniel F.LanvinModo de funcionamiento El esquema de funcionamiento de las páginas dinámicas essiempre similar independientemente de en qué se hayandesarrollado éstas CGI, ASP, Servlets/JSP… El servidor Web detecta una petición de una página dinámicay se la pasa al programa necesario Podría ser una extensión del servidor O bien un programa completamente independiente Éste programa es quien sabe cómo interpretar el código de lapágina para devolver el HTML apropiado
  38. 38. Mantenimiento de la sesión
  39. 39. César F.AcebalDaniel F.LanvinHTTP, protocolo sin estado HTTP es un protocolo sin estado Esto significa que para el servidor Web cada petición de unapágina es única No tendría forma de saber, por ejemplo, que ese usuario acaba deañadir un producto a su carrito, o si ya se validó o no, en qué puntodel proceso de compra se encuentra, etcétera Son necesarias alternativas software, por tanto, que permitansimular el estado
  40. 40. César F.AcebalDaniel F.LanvinAlternativas Aunque hay varias formas de hacerlo (dependiendo de si trabajamos enASP, en J2EE…) la mayoría pasan por el uso de “cookies” Algunas de las alternativas son: Almacenar toda la información de la sesión, a mano, en una cookie (porejemplo, mediante JavaScript) Una combinación de cookie (para guardar un ID de usuario) y bases de datos Usar el objeto SessionSession (o similar) provisto por los entornos deprogramación como ASP o J2EE (Servlets, JSP...)““URL rewriting”URL rewriting” Etcétera
  41. 41. César F.AcebalDaniel F.Lanvin¿Qué son las cookies? Las cookies son pequeñas porciones datos que sonalmacenados localmente por el navegador en forma depequeños ficheros de texto Cada vez que el cliente envía información al servidor, incluyeen la petición HTTP las cookies que previamente hayaguardado provenientes de ese servidor
  42. 42. César F.AcebalDaniel F.LanvinSintaxis Cada cookie presenta la siguiente sintaxis general: Lo único obligatorio es que tenga un nombre y un valorasociado; el resto de atributos son opcionales Aunque también se utiliza bastante el atributo expiresexpiresnombre=valor; [expires=fecha; path=directorio;domain=nombreDeDominio; secure]nombre=valor; [expires=fecha; path=directorio;domain=nombreDeDominio; secure]
  43. 43. César F.AcebalDaniel F.LanvinURL Rewriting Consiste en incluir la información del estado en el propioURL/…/comprar.asp?/…/comprar.asp?paso=3&producto1=01992CX&producto2=ZZ112230&producto3=Hpaso=3&producto1=01992CX&producto2=ZZ112230&producto3=HJ19X25…J19X25…No es de recibo en aplicaciones “serias” Un cliente puede iniciar dos o más sesiones simultáneas, páginastediosas de programar, sólo se puede usar el método GET, etc.
  44. 44. César F.AcebalDaniel F.LanvinVentajas del uso de cookies Menor uso de los recursos del servidor Los servidores “sin estado” no necesitan reservar y mantenerrecursos para guardar el estado de la sesión Fácil escalabilidad y uso de clusters Al no tener estado, cualquier servidor puede atender a cualquierclienteNo hace falta que un cliente siempre sea atendido por el mismoservidor, ni ningún tipo de distribución del estado entre servidores La sesión del cliente podría sobrevivir a una caída delservidor Un reintento por parte del cliente con el mismo URL suele funcionar
  45. 45. César F.AcebalDaniel F.LanvinInconvenientes del uso de cookies Privacidad Otros servidores podrían leer información almacenada en las cookiesdel clienteNo son válidas para guardar números de tarjeta, contraseñas y cosas porel estilo Los datos pueden ser alterados Un usuario podría modificar el fichero de una cookie Lo mismo ocurre con otros mecanismos de cliente: URL,formularios, etc. Aumenta el tráfico por la red El estado se transmite con cada petición al servidor
  46. 46. César F.AcebalDaniel F.LanvinInconvenientes del uso de cookies Implementación compleja Mantener “a mano” el estado en el cliente puede ser realmentecomplicado si queremos hacerlo de manera robusta Tamaño de datos limitado Tanto el tamaño máximo permitido por las cookies como la longitudmáxima de un URL pueden darnos problemas para almacenarsesiones complejas
  47. 47. Servidores de aplicaciones
  48. 48. César F.AcebalDaniel F.Lanvin¿Qué es un servidor de aplicaciones? Es un programa que provee la infraestructura necesaria paralas aplicaciones Web empresariales ¿Qué quiere decir esto? Que los programadores van a poder dedicarse casi en exclusiva aimplementar la lógica del dominio, ya que servicios de uso común,como transacciones, seguridad, persistencia, etc. ya sonproporcionados por el servidor Web Se ha convertido en una pieza de software clave para cualquierempresa dedicada al comercio electrónico Es una capa intermedia (middlewaremiddleware) que se sitúa entre el servidorWeb y las aplicaciones y bases de datos subyacentes
  49. 49. César F.AcebalDaniel F.LanvinVisión generalServidor de aplicaciones(Transacciones, mensajería, servicios Web…)CORBA J2EE .NETAplicaciónclienteAplicaciónclienteAplicaciónclienteSGBD
  50. 50. César F.AcebalDaniel F.LanvinMotivación Comienzan a surgir cuando queda claro las aplicacionescliente/servidor no iban a ser escalables a un gran número deusuarios Debido a las características de los clientes “pesados” Se hacía necesario mover las reglas de negocio a algún lugarintermedio entre los clientes y la base de datos Empezaron a surgir productos para hacer esa tarea Cada compañía los llamaba de una forma distintaServidores de transacciones, servidores de aplicaciones…
  51. 51. César F.AcebalDaniel F.LanvinObjetivo de los Servidores de Aplicaciones Los llamasen como los llamasen, estaban diseñados paragestionar de forma centralizada el modo en que losclientes debían conectarse a la base de datos o a los servicioscon los que tenían que interoperar
  52. 52. César F.AcebalDaniel F.LanvinServicios proporcionados Creación y gestión de los componentes del servidor Por aquel entonces, basados en CORBA o COM Clustering Equilibrado de carga Transacciones Seguridad Acceso a datos …
  53. 53. Servicios proporcionados
  54. 54. César F.AcebalDaniel F.LanvinGestión de la sesión Como sabemos, HTTP es un protocolo sin sesión No permite mantener una conexión abierta entre el cliente y el servidormás allá de lo que dura la transferencia del documento en cuestión En cualquier aplicación de comercio electrónico, es necesariopoder identificar al usuario a través de su navegación por elsitio Web Autenticación, adición de productos al carrito de la compra, etc.El servidor ha de conservar información entre peticiones del usuario a lo largo dela duración de una sesiónEl servidor ha de conservar información entre peticiones del usuario a lo largo dela duración de una sesión
  55. 55. César F.AcebalDaniel F.LanvinGestión de la sesión (2) La implementación “a mano” se complicaría enormementeen el caso de contar con varios servidores (equilibrado decarga) La petición de un usuario registrado en la máquina A puede serredirigida al servidor B Lo lógico es que sea el servidor de aplicaciones quien seencargue de gestionar la sesión Además, debería ser más eficiente que si lo programamos nosotrosmismos
  56. 56. César F.AcebalDaniel F.LanvinEquilibrado de carga Por equilibrado de carga (load balancing) se entiende la capacidad derepartir el procesamiento entre distintos servidores Las peticiones de los clientes se redirigen a la máquina que más desocupadase encuentre en ese momento Mejora de rendimiento de la aplicación No es tan sencillo como añadir una nueva máquina y ya está Además de la escalabilidad, se consigue una mayor tolerancia a fallosLos servidores de aplicaciones proporcionan mecanismos de equilibrado de carga(aspecto clave para la escalabilidad)Los servidores de aplicaciones proporcionan mecanismos de equilibrado de carga(aspecto clave para la escalabilidad)
  57. 57. César F.AcebalDaniel F.LanvinAcceso a datos Los servidores de aplicaciones proveen facilidades para administrarconexiones a bases de datos relacionales Oracle, SQL Server, DB2… Los componentes (las clases que implementan la lógica del negocio)acceden a ellas de forma estándar Independiente de la base de datos subyacente También suelen permitir acceder a otros tipos de fuentes de datos: Tales como distintos ERP (SAP, Vaan...), repositorios XML, etc. Los servidores de aplicaciones son también importantes, por tanto, comomecanismo de integración de sistemas heredados
  58. 58. César F.AcebalDaniel F.Lanvin“Pooling” de conexiones Abrir una conexión a una base de datos suele ser un procesocostoso No es viable abrir una nueva conexión por cada consulta a la base dedatosPenalizaría enormemente el rendimiento de la aplicación Los servidores de aplicaciones suelen contar con una serie deconexiones permanentemente abiertas que distribuye deforma transparente a los distintos procesos Se debería poder configurar el número de conexiones abiertas, eincluso la política de asignación
  59. 59. César F.AcebalDaniel F.LanvinGestión transaccional Son un elemento básico de cualquier aplicación comercial Evitan que haya información inconsistente Sería complejísimo implementarlas “a mano” Con un servidor de aplicaciones que tenga esta característica, bastaría conindicarle dónde empieza y termina la transacción Encargándose él de deshacer los pasos intermedios en caso de un error delsistemaTransacción: secuencia de pasos que, o se ejecutan todos, o si no el sistemaqueda en el estado originalTransacción: secuencia de pasos que, o se ejecutan todos, o si no el sistemaqueda en el estado original
  60. 60. César F.AcebalDaniel F.LanvinTecnologías actuales Actualmente, las dos plataformas más comunes son J2EE y,más recientemente, ha surgido .NET De hecho, hasta hace poco hablar de servidores de aplicaciones eraprácticamente hablar de J2EE(aunque no debemos hacer tal asociación)
  61. 61. César F.AcebalDaniel F.LanvinEjemplo: arquitectura J2EE

×