Está en la página 1de 12

Aplicaciones en Internet

 El desarrollo de aplicaciones en Internet es un ejemplo de desarrollo


de aplicaciones distribuidas

Desarrollo de aplicaciones para Internet  Soluciones y evolución


† Aplicaciones monolíticas: grandes ordenadores (mainframes) y
terminales
– toda la lógica de proceso (negocio), el acceso a datos y la lógica de
presentación están en el mainframe y los terminales sólo sirven para
acceder y comunicarse con él.
Baltasar Fernández Manjón
http://www.fdi.ucm.es/profesor/balta/ † Arquitectura de dos niveles
– Proceso distribuido entre una máquina que proporciona el acceso mediante
Dpto. de Sistemas Informáticos y Programación, una interfaz de usuario (cliente) y una máquina que centraliza el servicio y
Universidad Complutense de Madrid los datos (servidor)
Avda. Complutense s/n, 28040, Madrid, Spain,
† Arquitectura multinivel o multicapa
– Se añade un nivel intermedio entre la interfaz de usuario y el servidor de
datos. Este nivel se encarga de la lógica de negocio.

©Baltasar Fernández Manjón 2

Aplicaciones monolíticas Arquitectura de dos niveles

 El acceso a los datos, la presentación (interfaz) y la lógica de proceso  Se aprovecha la capacidad de proceso del cliente. El cliente es capaz de
está en una única aplicación monolítica procesar datos (fat client).
 La distribución de la lógica de negocio entre el cliente y el servidor dificulta
 Existe un alto grado de acoplamiento entre las distintas partes de la su actualización y mantenimiento
aplicación lo que dificulta la reutilización de código y su † Hay que instalar nuevas versiones en el cliente
mantenimiento.
 Dificultades de escalado y alto tráfico de datos
 No se puede distribuir el código entre diversas máquinas y no es
escalable Cliente Servidor
I. de datos
G. Lógica
U. de Negocio Servicios de
acceso/gestión
de datos

Cliente
PROCEDIMIENTOS
I. ALMACENADOS
G. Lógica
de Negocio
U.
©Baltasar Fernández Manjón 3 ©Baltasar Fernández Manjón 4
Arquitectura multinivel Particularidades de las aplicaciones web
 Cliente ligero que se ocupa únicamente de la interfaz gráfica de usuario  Las aplicaciones Web son aplicaciones distribuidas muy diferentes a las
clásicas, con nuevos problemas y particularidades
 Proporciona una alta escalabilidad y posibilidad de distribución entre varias
máquinas  Podemos tener millones en vez de cientos de clientes y por supuesto más
concurrencia que en un modelo cliente/servidor clásico. La escalabilidad es
un problema constante.

 El protocolo HTTP no esta orientado a sesión, hay que buscar formas de


simularla.
Cliente Servidor

I.G.U. Servidor  Todo el proceso se realiza on-line (transacciones, seguridad) y es crítico: si


Lógica de de datos falla perdemos al cliente
Negocio
Servicios
de  La interfaz de usuario es impersonal, debemos prestar mayor atención al
acceso
cliente, nuestra competencia es internacional no local.
Servidor

Navegador
Lógica PROCEDIMIENTOS  El tiempo de desarrollo de las aplicaciones debe ser rápido debido a la
ALMACENADOS
de Negocio competencia
I.G.U.

©Baltasar Fernández Manjón 5 ©Baltasar Fernández Manjón 6

Modelo de web estático Evolución del servidor web estático

 Modelo cliente servidor en el que un servidor web proporciona  Se ha evolucionado en los dos extremos
páginas estáticas a un navegador † Ampliación de las capacidades del cliente
– Permitiendo la ejecución de código en el cliente que proporcionan
tecnologías como:
‹ las applets – programas escritos en Java que se ejecutan dentro del navegador
que actúa como cliente
‹ los lenguajes de secuencias de órdenes o scripts (p.e. javascript) que son
interpretados por el navegador
† Ampliación de las capacidades del servidor
– El servidor como respuesta a una petición ya no sólo es capaz de devolver
un documento sino que también es capaz de ejecutar un programa
‹ Interfaz de pasarela común (CGI, Common Gateway Interface)
‹ Programas java que se ejecutan en el servidor (p.e. Servlets, JSP)

©Baltasar Fernández Manjón 7 ©Baltasar Fernández Manjón 8


Common Gateway Interface (CGI) Aplicaciones a medida y soluciones propietarias

 Aplicaciones específicas que se ejecutan en el servidor y que  Aplicaciones creadas para cubrir unas necesidades específicas.
conectan el servidor web a las aplicaciones existentes.
 Gran esfuerzo. Pueden convertirse en muy complejas y largas si las
 A pesar de ser antiguas son predominantes hoy en día. empezamos desde cero

 Presenta varios problemas :  Hay que considerar todos los aspectos generales y que no son los centrales
de la aplicación:
† Problemas de escalabilidad, concurrencia y recursos
† Comunicación
† Mal manejo de sesiones, es responsabilidad del programador
† Seguridad
† Actualización del código difícil † Escalabilidad
† Etc

 Para simplificar toda esta parte de infraestructura surgen las soluciones


propietarias
† Se proporcionan API’s que simplifican el desarrollo de las aplicaciones
† Proporcionan un “middleware”

©Baltasar Fernández Manjón 9 ©Baltasar Fernández Manjón 10

Servidores de aplicaciones Servidores de aplicaciones


 Software de infraestructura o “Middleware” que permite desarrollar y Hay varios tipos de Servidores de aplicaciones como:
desplegar aplicaciones distribuidas en varias capas.
† Servidores CORBA
 Centraliza servicios de aplicación como funcionalidad de servidor web, † Vignette
componentes de negocio y acceso a sistemas empresariales de soporte † .NET (Microsoft)
(“backend”). † J2EE (Java to Enterprise Edition)

 Proporciona servicios de seguridad y facilidades de administración. Algunos servidores de aplicaciones son propietarios
(dependen de una única empresa) mientras que otros
siguen estándares abiertos

DBMS
J2EE
Servidor † Plataforma estándar para el desarrollo de aplicaciones empresariales multicapa
de basadas en Java.
DBMS † Promovido por Sun y otras empresas (IBM, BEA Systems, etc).
aplicaciones
† Se basa en la utilización de componentes modulares, y maneja parte de la
Internet
Base de funcionalidad de las aplicaciones de forma declarativa, sin necesidad de
datos programación.
† Incluye los siguientes APIs:
1ª Capa 2ª Capa 3ª Capa – JDBC, RMI, JNDI, JTA/JTS, EJB, JMS, Servlets, JSP
©Baltasar Fernández Manjón 11 ©Baltasar Fernández Manjón 12
Servidores de aplicaciones J2EE Arquitectura J2EE

©Baltasar Fernández Manjón 13 ©Baltasar Fernández Manjón 14

Aplicación Web Servlets

 Una aplicación web es una extensión dinámica a un servidor web  Programa que se ejecuta en el servidor, escrito en Java que gestiona
(Sun) mensajes entre un cliente y un servidor web
 Una aplicación web es un grupo de recursos en el servidor que  Objetos Java que se basan en el API servlet y permiten extender la
permite crear una aplicación interactiva (Bea Systems) funcionalidad de un servidor web
† Permiten generar contenido a partir de un programa como respuesta a
 Estos recursos son componentes Web (p.e. servlet, JSP), documentos
una petición HTTP
estáticos (p.e. html, imágenes), clases que se ejecutan en el servidor,
bibliotecas de clases, e información de configuración y despliegue.  Se ejecutan mediante una asignación con una URL

 Los componentes Web se ejecutan dentro de un entorno denominado  Son gestionados por un contenedor que tiene una arquitectura simple
contenedor web.
 Disponibles en la mayoría de los servidores de aplicaciones del
† Este contenedor proporciona los servicios de infraestructura básicos
mercado (y en todos los J2EE)
para la aplicación web (p.e. Seguridad, concurrencia o gestión del ciclo
de vida)  Independientes del servidor y de la plataforma

©Baltasar Fernández Manjón 15 ©Baltasar Fernández Manjón 16


Java Server Pages (JSP) HTTP

 JSP son documentos de texto que crean dinámicamente páginas web  Normalmente los clientes web utilizan el protocolo HTTP para
a partir de una petición de un cliente (navegador) comunicarse con un servidor de aplicaciones J2EE.
† Se ejecutan en el servidor
 Es un protocolo basado en petición y respuesta
 Un documento JSP contiene
 El protocolo HTTP define
† Plantillas de texto conteniendo formatos de presentación (HTML, XML)
† las peticiones que puede enviar un cliente al servidor. Cada petición
† Acciones dinámicas bien sea
– mediante código o contiene una URL que identifica el componente u objeto estático
– mediante etiquetas JSP que permiten en acceso a directivas o a otros solicitado (e.g. página HTML)
componentes † Las respuestas que puede enviar el servidor a dichas peticiones

 Los JSP se compilan automáticamente produciendo los servlets  El servidor J2EE convierte la petición en un objeto de petición HTTP
correspondientes y lo envía al componente web identificado por la URL. El
componente web rellena un objeto de respuesta HTTP que el
 Buscan simplificar la autoría y programación de aplicaciones servidor convierte en una respuesta HTTP que se envía al cliente.

©Baltasar Fernández Manjón 17 ©Baltasar Fernández Manjón 18

HTTP peticiones y respuestas Modelo de petición HTTP

Una petición HTTP consta de un método de petición, de  La especificación describe HTTP como un protocolo de petición /
una URL, de campos de cabecera y de un cuerpo. respuesta sin estado cuya operación básica es la siguiente:
1. Una aplicación realizada por un cliente, por ejemplo un visualizador
Métodos de petición de HTTP 1.1 Web, abre un conector al puerto HTTP del servidor Web (el puerto
– GET – recupera el recurso identificado por la URL de la petición predeterminado es el 80).
– HEAD – devuelve las cabeceras identificadas por la URL de la petición
– POST – envía datos de longitud ilimitada al servidor Web 2. A través de la conexión el cliente escribe una línea de petición de texto
– PUT – almacena un recurso en la URL de la petición ASCII, seguida de ninguna, una o varias cabeceras HTTP , una línea en
– DELETE – elimina el recurso identificado por URL de la petición blanco, y cualquier dato que acompañe a la petición.
– OPTIONS – devuelve los métodos HTTP soportados por el servidor
3. El servidor Web analiza la petición y localiza el recurso especificado.
– TRACE – devuelve los campos de cabecera enviados con una petición TRACE
4. El servidor envía una copia del recurso al conector, donde es leído por
Una respuesta HTTP contiene un código de resultado, el cliente.
unos campos de cabecera y un cuerpo 5. El servidor cierra la conexión.
† Algunos códigos de resultado habituales son:
– 404 – indica que el recurso solicitado no está disponible
– 401 – indica que la petición requiere autenticación HTTP
– 500 – indica un error en el servidor HTTP que impide dar respuesta a la petición
– 503 – indica que el servidor HTTP está temporalmente sobrecargado y es incapaz de
gestionar la petición
©Baltasar Fernández Manjón 19 ©Baltasar Fernández Manjón 20
Petición y respuesta con servlets Carga y ejecución de un servlet
† Como respuesta a una petición que implica un servlet, el server lo
instancia (lo carga en memoria) y crea un hilo de ejecución. El servlet se
carga sólo una vez y permanece en memoria hasta que se desactiva
expresamente o se detiene el servidor

©Baltasar Fernández Manjón 21 ©Baltasar Fernández Manjón 22

Clases relacionadas con los servlets Métodos definidos en la interface servlet de java.servlet

 La API de servlet es un conjunto de clases e interfaces java que


definen una interfaz estándar entre un cliente web y un servlet Method Summary
† Paquetes javax.servlet y javax.servlet.http void
destroy()
 Todos los servlets deben implementar el inteface java Servlet que Called by the servlet container to indicate to a servlet that the servlet is being taken out of service.

define el ciclo de vida de los servlets ServletConfig

† init(), service(), destroy() getServletConfig()


Returns a ServletConfig object, which contains initialization and startup parameters for this servlet.

java.lang.String
getServletInfo()
Returns information about the servlet, such as author, version, and copyright.

void
init(ServletConfig config)
Called by the servlet container to indicate to a servlet that the servlet is being placed into service.

void
service(ServletRequest req, ServletResponse res)
Called by the servlet container to allow the servlet to respond to a request.

©Baltasar Fernández Manjón 23 ©Baltasar Fernández Manjón 24


Clases y métodos habituales en los servlets Servlets HTTP
 Una forma simple de obtener un servlet es mediante extensión de las  Normalmente se extiende la clase abstracta HttpServlet
clases genéricas que se proporcionan en la API
† GenericServlet Clase de soporte genérico de servlets (con  Una petición de un cliente a un servlet se representa y encapsula
independencia del protocolo): mediante un objeto HttpServletRequest
† HttpServlet Clase para servlets que soportan el protocolo HTTP † Este objeto encapsula la comunicación entre el cliente y el servidor
 La especialización de estas clases debe sobreescribir por lo menos † Puede contener información sobre el cliente y cualquier dato enviado
uno de los métodos que proporcionan por el cliente al servidor

 La gestión de las peticiones al servlet se realizan invocando los  Una respuesta desde un servlet a un cliente se representa y encapsula
métodos: mediante un objeto HttpServletResponse
† Servlets genéricos † Habitualmente esta respuesta se genera dinámicamente en función de
– el método service() los datos de la petición
† Servlets HTTP
– métodos principales: doGet() , doPost()
– Otros métodos:
‹ doHead(), doDelete(), doOptions(), doTrace()

©Baltasar Fernández Manjón 25 ©Baltasar Fernández Manjón 26

Servlets HTTP Métodos de HttpServlet

 Para crear un servlet habitualmente se extiende la clase Method Summary


HttpServlet y se sobreescribe por lo menos uno de sus protected
void
doDelete(HttpServletRequest req, HttpServletResponse resp)
Called by the server (via the service method) to allow a servlet to handle a DELETE request.
métodos protected doGet(HttpServletRequest req, HttpServletResponse resp)
void Called by the server (via the service method) to allow a servlet to handle a GET request.
† doGet() protected doHead(HttpServletRequest req, HttpServletResponse resp)

† doPost()
void Receives an HTTP HEAD request from the protected service method and handles the request.
protected doOptions(HttpServletRequest req, HttpServletResponse resp)
void
 Una petición GET se genera cuando un usuario proporciona protected
Called by the server (via the service method) to allow a servlet to handle a OPTIONS request.

doPost(HttpServletRequest req, HttpServletResponse resp)


una URL o se selecciona un enlace void Called by the server (via the service method) to allow a servlet to handle a POST request.
protected doPut(HttpServletRequest req, HttpServletResponse resp)

 Una petición POST se produce cuando el usuario envía un


void Called by the server (via the service method) to allow a servlet to handle a PUT request.
protected doTrace(HttpServletRequest req, HttpServletResponse resp)
formulario HTML que especifica el método POST void Called by the server (via the service method) to allow a servlet to handle a TRACE request.
protected getLastModified(HttpServletRequest req)
† Permite al cliente enviar datos sin limitación de tamaño de una long Returns the time the HttpServletRequest object was last modified, in milliseconds since midnight January 1,
1970 GMT.
vez protected
void service(HttpServletRequest req, HttpServletResponse resp)

Receives standard HTTP requests from the public service method and dispatches them to the doXXX
methods defined in this class.

void service(ServletRequest req, ServletResponse res)


Dispatches client requests to the protected service method.

©Baltasar Fernández Manjón 27 ©Baltasar Fernández Manjón 28


Ejemplo de Servlet HTTP Servidor de aplicaciones WebLogic: ejemplos

HolaServlet.java
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;

public class HolaServlet extends HttpServlet {


public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<title>El primer servlet</title>");
out.println("<big>Hola Hola!</big>");
}
} // HolaServlet

©Baltasar Fernández Manjón 29 ©Baltasar Fernández Manjón 30

Ejemplos de servlets Ejemplo Hello World

©Baltasar Fernández Manjón 31 ©Baltasar Fernández Manjón 32


Modificación de los servlets de ejemplo de WebLogic Modificación de los servlets de ejemplo de WebLogic
3 Siguiendo las instrucciones
1 Se localiza el código del ejemplo del sistema se abre una
consola, se configura el
entorno
C:\bea\weblogic81\sampl
es\domains\examples>set
ExamplesEnv

4
Utilizando la utilidad ant se compila el servlet
C:\bea\weblogic81\samples\server\examples\src\examples\servlets>
ant HelloWorldServlet

Se edita, se modifica y 2
se salvan los cambios

©Baltasar Fernández Manjón 33 ©Baltasar Fernández Manjón 34

Modificación de los servlets de ejemplo de WebLogic: resultado Obtención de información sobre el servidor

 Los servlets pueden obtener información sobre el servidor


† Nombre
– Método String request.getServerName()
– e.g. “eaula.sip.ucm.es"
† Número de puerto
– Método int request.getServerPort()
– e.g. Número de puerto "8080"
 Los servlet también pueden obtener información general sobre el
servidor:
† Software del servidor:
– String getServletContext().getServerInfo()

©Baltasar Fernández Manjón 35 ©Baltasar Fernández Manjón 36


Obtener información sobre la petición Obtener información sobre la petición

El servlet puede obtener información del cliente sobre la  String[] getParameterValues("paraName")
petición † Devuelve un array de valores para todas las ocurrencias del
† Obtener la dirección IP del cliente nombreParámetro en la cadena de petición y null si no aparece
– String request.getRemoteAddr()
† Obtener el nombre del cliente  Enumeration getParameterNames( )
– String request.getRemoteHost() † Devuelve una enumeración de los parámetros de petición (sin orden
preestablecido)
Una petición puede estar acompañada de un número
arbitrario de parámetros
† Los parámetros se pueden enviar desde formularios HTML
– GET como una cadena añadida a la URL
– POST como datos que no aparecen en la URL
El método String getParameter(“nombreParámetro")
† devuelve el valor asociado a la primera aparición de nombreParámetro en la
petición (diferencia entre mayúsculas y minúsculas)
† Devuelve null si no aparece dicho parámetro en la petición
† Funciona igual para peticiones GET y POST

©Baltasar Fernández Manjón 37 ©Baltasar Fernández Manjón 38

Respuesta Otras operaciones

 Operaciónes comunes en la respuesta  Devolver como respuesta un mensaje de error como un documento
HTML que incluye un código de error y un mensaje
 Establecer el tipo MIME del contenido de la respuesta
† public void sendError(int códigoErrror, String mensaje)
† P.e. respuesta.setContentType(“text/html”);
† Ej respuesta.sendError(500, “paramétro no especificado”);
 Escribir el cuerpo de la respuesta  Hacer que el servlet redirija la petición a otra URL
† Mediante un PrintWriter para enviar caracteres
† public void sendRedirect(String URL)
– response.getWriter()
† Ej respuesta.sendRedirect(“http://www.fdi.ucm.es”);
† Mediante un ServletOutputStream para datos binarios (p.e. imágenes)
† La URL de la redirección debe ser una dirección absoluta y completa
– response.getOutputStream()
(http://...)

©Baltasar Fernández Manjón 39 ©Baltasar Fernández Manjón 40


Despliegue de los servlets Mas información
† Después, dependiendo del motor de servlets, podría ser necesario  Documentación de BEA Systems sobre el desarrollo de servlets en el
describir el servlet en el descriptor de despliegue de la aplicación Web entorno de WebLogic 8.1
/WEB-INF/ web.xml.
† http://e-docs.bea.com/wls/docs81/servlet/index.html
† Para un servlet sencillo, esto podría consistir únicamente en una etiqueta
<servlet> con su descendiente <servlet-name> y elementos <servlet-  Tutoriales de IBM
class>. † www.ibm.com/developerWorks
† Atención. Las entradas<servlet> en el fichero web.xml deben ser † “Building Java HTTP servlets”
codificadas de acuerdo con la DTD web –app_ 2.2.dtd http://www2.tw.ibm.com/developerWorks/tutorial/pdf/j-servlets-a4.pdf

<?xml versión=”1.0” ?>  Transparencias sobre servlets en español


<web-app> † http://www.tic.udc.es/~fbellas/teaching/is/Tema4Apartado4.1.pdf
...
<servlet>
<servlet-name>nombreServlet</servlet-name>
<servlet-class>nombreCualificadoClasedelServlet </servlet–class>
</ servlet >
...
</web – app>

©Baltasar Fernández Manjón 41 ©Baltasar Fernández Manjón 42

Servidor de aplicaciones Tomcat Ejemplos incluidos con Tomcat

©Baltasar Fernández Manjón 43 ©Baltasar Fernández Manjón 44


Estructura de directorios de Tomcat

©Baltasar Fernández Manjón 45

También podría gustarte