Tutorial Desarrollo de aplicaciones Web empleando el modelo J2EE

1
Tutorial Desarrollo de aplicaciones Web
empleando el modelo J2EE

• Dr. Gabriel López Morteo
• M.C. Jorge Ibarra Esquer
• Universidad Autónoma de Baja California
• Mexicali, B.C., México

8o Encuentro Internacional de Ciencias de la
Computación Morelia, Michoacán, septiembre del
2007
2
Arquitectura Cliente-Servidor

• 1 sola capa
• 1 cliente
• 1 servidor

Servidor
Cliente
3
Arquitecturas de sistemas distribuídos 2-tier

• Dos divisiones (2-tier)
• Usualmente dividido en presentación y datos
• El cliente realiza todo el trabajo de cómputo
  mientras el servidor provee los datos
• Emplea mucho ancho de banda
• Requiere múltiples llamadas al servidor para
  operaciones simples
• Corre el riesgo de saturar de conexiones al
  servidor
• El mantenimiento de la aplicación y su
  actualización es muy difícil

4
2 capas
5
2 capas con acceso de datos en capa lógica
6
Arquitecturas de sistemas distribuídos 3-tier

• Tres divisiones (3-tier)
• Cada capa está separada del resto
• La interacción se realiza mediante interfases
  bien denifidas
• Comunmente se compone de
• Despliegue (presentation layer)
• Lógica de la aplicación (bussiness layer)
• Datos (data layer)
• Facilita el mantenimiento al tener separados los
  componentes del sistema
• El origen de los datos es independiente del
  cliente

7
3 capas
8
3 capas y seguridad
9
Arquitecturas de sistemas distribuídos n-tier

• N divisiones (n-tier)
• No tiene un esquema único
• Se compone de
• Interfaz de usuarios
• Lógica de presentación
• Lógica del negocio
• Infraestructura de servicios
• Capa de datos
• La capa lógica se divide por funciones más que
  físicamente
• Pueden estar involucrados más de un servidor para
  cada componente

10
Optimización de recursos
11
Porqué usar componentes?

• Fomentan la reutilización de código
• Optimiza recursos.
• Accede a recursos distribuídos
• Facilita el acceso a sistemas legados.
• Permite desarrollar soluciones para una variedad
  grande de clientes

12
(No Transcript)
13
Componente en e-commerce
14
Relación entre un componente y su interfaz
15
Patrones de diseño

• Patrón de diseño Modelo-Vista-Controlador (MVC)
• Uno de los más socorridos en el modelo J2EE
• Separa la presentación, la manipulación de los
  datos y la introducción de información
• Modelo (Modelo). Se encarga de la lógica de la
  aplicación y la manipulación de datos
• Vista (View). Se encarga del despliegue y la
  actualización de los elementos que la componen
• Controlador (Controller). Se encarga de la
  introducción de datos a la aplicación, por lo
  general de parte del usuario

16
Modelo MVC
17
Espacios de ejecución de un sistema distribuído
18
Requerimientos del J2EE

• Independencia de la plataforma
• Especialmente del lado del cliente
• Reusabilidad
• Modularidad
• Escalabilidad
• Facilidad de administración y mantenimiento
• La idea detrás del J2EE es la de proveer un
  estandar simple y unificado para aplicaciones
  distribuídas a través de modelos de aplicación
  basado en componentes.

19
La plataforma J2EE

• Es en escencia un ambiente de servicios de
  aplicaciones distribuídas
• Se compone de
• Una infraestructura de ejecución para el
  hospedaje de aplicaciones (runtime hosting
  applications)
• Una familia de APIs para construir aplicaciones

20
J2EE APIs

• Java Database Connectivity (jdbc)
• Remote Method Invocation Inter-ORB protocol
  (RMI-IIOP)
• Enterprise Java Beans (EJB)
• Java Servlets 2.2
• Java Server Pages 1.1 (jsp)
• Java Message Service (JMS)
• Java Naming and Directory Interface (JNDI)
• Java Transaction API
• Java Mail
• Standard Java API

21
Arquitectura de J2EE

• Contenedores
• La arquitectura se compone de cuatro contenedores
• Un contenedor de WEB. Para hospedar Java servlets
  y páginas JSP.
• Un contenedor de EJB. Para hospedar componentes
  JavaBeans
• Un contenedor de Applets. Para ejecutar applets.
• Un contenedor de aplicaciones clientes. Para
  ejecutar aplicaciones clientes de consola.
• Un contenedor es un ejecutor (runtime) Java 1.2
  Standar Edition para componentes de aplicaciones

22
Arquitectura de un contenedor

• Componentes de aplicaciones (application
  components).
• Incluye servlets, jsp, ejb, etc. Pueden ser
  empaquetados en archivos.
• Definidores del despliegue e iniciación
  (deployment descriptors).
• Un archivo en XML que describe los componentes de
  la aplicación.
• Incluye también información adicional para la
  administración efectiva de componentes de la
  aplicación.

23
Partes de la arquitectura de un contenedor

• Contratos de componentes
• Definidos por la JVM
• Para el contenedor WEB el contrato es para seguir
  los APIs de Servlets y JSP
• APIs de servicios del contenedor
• Un contenedor provee una vista global a varios
  APIs corporativos especificados en la plataforma
  J2EE
• Accesibles via JNDI
• Servicios declarativos
• Son servicios o aciones que se llevan a cabo por
  el contenedor en el que se encuentra una
  aplicación via una invocación específica en los
  deployment descriptors
• Otros servicios del contenedor
• Recolección de basura
• Colecciones de recursos (resource pooling)

24
Tecnologías en J2EE

• Tecnologías de componentes
• Contienen la lógica de la aplicación
• Servlets, JSP, EJB
• Tecnologías de servicio
• Servicios de soporte para los componentes de
  aplicaciones
• JDBC, JNDI, JTA
• Tecnologías de comunicación
• Proveen los mecanismos de comunicación entre las
  diferentes partes de la aplicación, ya sean
  locales o remotas
• HTTP, TCP/IP, SSL, RMI, RMI-IIOP,JMS,JavaMail

25
(No Transcript)
26
Desarrollando aplicaciones J2EE

• Desarrollo del componente de la aplicación
• Se modelas las lógica del sistema en la forma de
  componentes de aplicaciones
• Composición de los componentes de la aplicación
  en módulos
• Los componentes de la aplicación se empaquetan en
  módulos. Se proveen deployment descriptors para
  cada módulo
• Composición de módulos en la aplicación
• Integración de múltiples módulos en aplicaciones
  J2EE proveyendo sus deployment descriptors
• Despliegue de la aplicación
• Se despliega e instala la aplicación empaquetada
  en un servidor J2EE

27
Estructura de despliegue de una aplicación J2EE

• Se distribuye en un solo archivo .WAR
• Cada directorio a nivel raíz del servidor se
  considera un contenedor de aplicaciones
• Cada aplicación WEB debe contener
• Directorio WEB-INF en donde se coloca el material
  no visible para el cliente
• Archivo web.xml, que es el deployment descriptor
  para cada aplicación WEB
• Directorio lib, se colocan todas las librerias en
  archivos .jar (opcional)
• Directorio classes, se colocan todas las clases
  en java manteniendo la estructura jerarquica de
  sus paquetes

28
SERVLETS
29
Qué es un Servlet?

• Es un programa JAVA que se ejecuta en el marco de
  un servicio de red, como por ejemplo un servidor
  web, y que recibe peticiones de un cliente y
  responde a ellas.
• Los servlets son a los servidores lo que los
  applets son a los browsers
• El Ciclo de Vida
• Los Servlets al igual que los Applets poseen un
  Ciclo de Vida perfectamente definido controlado
  por un contenedor.
• La interfaz que se utiliza para implementarlos
  define una serie de métodos para cada una de sus
  etapas. Es el contenedor el que se encarga de
  invocarlos.

30
Servlets

• Extienden la funcionalidad de un servidor
• Se hospedan en un contenedor de servlets
• Reciben solicitudes de un cliente y generan una
  respuesta HTML o XML
• El API indica como
• Inicializar y finalizar un servlet
• Acceder al entorno del contenedor
• Recibir solicitudes y enviar respuestas
• Mantener información sobre la sesión
• Interactuar con otros servidores

31
Ciclo de vida de un Servlet
32
Ciclo de vida de un Servlet

• Cuando el servidor carga el Servlet, invoca el
  método init. Todas las peticiones que lleguen
  antes de que este método finalice su ejecución,
  deberán esperar para ser atendidas.
• Al finalizar la ejecución del método init, las
  peticiones son atendidas por el método service.
  Normalmente el servidor puede manejar varias
  peticiones simultáneamente y asigna un hilo de
  ejecución a cada petición.
• Cuando el servidor quiere descargar el Servlet
  invoca el método destroy.

33
Ejemplo de un Servlet

• Página HTML con un campo de entrada y botones
  Submit y Reset
• Código HTML
• lthtmlgt
• ltheadgt
• lttitlegtEjemplo "Mi Primer Servlet"lt/titlegt
  
• lt/headgt
• ltbodygt
• ltform actionhttp//servidor8080/servlet/MiPri
  merServlet methodPOSTgt
• ltBRgt
• ltBRgtIntroduzca un texto en el cuadro y
  presione "Submit"ltBRgt
• ltBRgt
• ltinput typetext nameTEXTOgt
• ltBRgt
• ltBRgtltinput typesubmitgtltinput
  typeresetgtlt/formgt
• lt/bodygt
• lt/htmlgt

34
Ejemplo

• En el código HTML destacan dos partes.
• La cabecera del form, que indica la acción a
  desencadenar en el servidor al presionar el botón
  Submit.
• La parte en que se define la forma.

35
Código del Servlet

• // MiPrimerServlet.java
• import javax.servlet.
• import javax.servlet.http.
• import java.io.
• public class MiPrimerServlet extends
  HttpServlet
• public void service(HttpServletRequest
  req, HttpServletResponse res)
• throws ServletException,
  IOException
• PrintStream out new PrintStream(res.get
  OutputStream())
• res.setContentType("text/html")
• String TEXTO req.getParameter("TEXTO
  ")
• out.println("ltpgtUsted ha escrito
  "TEXTO"lt/pgt")

36
Ejemplo

• El ejemplo da muestra del potencial y simplicidad
  que se deriva de la utilización de los Servlets.
• El archivo que contiene el Servlet
  MiPrimerServlet.java. Después de compilarlo con
  javac, se debe almacenar en el directorio
  /servlets dentro del directorio donde se haya
  instalado el servidor de Web.
• Para ejecutar y comprobar que funciona bien el
  Servlet, solo se tiene que introducir en el
  navegador una dirección como http//nombre_servi
  dor_DNS8080/MiPrimerServlet.html

37
Java Server Pages
38
Introducción

• El objetivo de la especificación de JSP es la de
  simplificar la creación y administración del
  páginas dinámicas mediante la separación del
  contenino y su presentación.
• Son archivos que combinan HTML estandar y
  etiquetas de script.
• Simplifican la capa de presentación dinámica en
  una arquitectura multi-capas.

1
39
Desarrollo de un JSP

• Se edita un archivo de texto con HTML y etiquetas
  de script.
• Se despliega en el servidor de aplicaciones con
  la extensión .jsp en el área de contenido visible
  por el cliente.
• Al solicitarlo, el contenedor WEB lo compila y lo
  convierte en un servlet.
• Cuando se realizan modificaciones al archivo
  original, el contenedor recompila el JSP.

1
40
Ciclo de vida de un JSP

• public void jspInit()
• Similar al método init de los servlets.
• public void jspDestroy()
• Similar al método destroy de los servlets
• public void _jspService(HttpSerlvetRequest req,
  HttpServletResponse res) throws ServletException,
  IOException
• Corresponde al cuerpo de la página jsp.
• Nunca debe de ser provista por el desarrollador
• No es indispensable que el programador
  proporcione los dos primeros métodos

1
41
Proceso de solicitud de un jsp
Uses
Translated
Uses
1
42
Etiquetas en JSP

• Caen dentro de tres categorías
• Directrices
• Afectan la estructura completa del servlet
  resultante de la transportación del jsp.
• Elementos de script
• Permiten insertar código en java en la página jsp
• Acciones
• Etiquetas especiales disponibles para modificar
  el comportamiento durante la ejecución
• Etiquetas creadas por el desarrollador (custom
  tags)
• Sirven para insertar código reutilizable definido
  por el desarrollador. Funcionan como macros.

1
43
Directrices de JSP

• Sirven como mensajes enviados al contenedor
• Se emplean como valores globales como
• Declaraciones de clases
• Métodos a implementar
• Especificación del tipo de contenido
• Sentencias import

1
44
Directrices de JSP tipos

• Existen tres tipos principales de directrices
• Page
• Include
• Taglib
• Sintaxis
• lt_at_ directivename attributevalue gt

1
45
Elementos de script

• Permite incluir código en java en la jsp.
• Declaración de variables
• Declaración de métodos
• Scriptlets (código en java arbitrario)
• Expresiones

1
46
Declaraciones (ejemplo)

• lt!
• Int numTimes3
• Public String diHola(String name)
• return Hola name manito
• gt
• lthtmlgtltheadgtlttitlegtUn titulolt/titleltbodygt
• lth1gtPagina de prueba de directivaslt/h1gt
• ltpgtEl valor de numTimes es lt numTimes gtlt/pgt
• ltpgtDiciendo hola al visitante lt diHola(Mani)
  gtlt/pgt
• lt/bodygt
• lt/htmlgt
• lt/headgt

1
47
Scriptlets

• Es un bloque de código en java que se ejecuta
  durante la solicitud-procesamiento y se encierra
  entre etiquetas lt gt
• En Tomcat, todo el código entre estas etiquetas
  es puesta en el método service() tal y como se
  escribe y en el orden en el que aparece en el jsp.

1
48
Scriptlets ejemplo

• lthtmlgtltheadgtlttitlegtUn titulolt/titlegtlt/headgt
• ltbodygt
• lth1gtPagina de prueba de scriptletslt/h1gt
• lt
• For (int i-0 i lt 10 i)
• out.println(ltbgtHola Mundolt/bgt i)
• System.out.println(Esto va al flujo de salida
  System.out i)
• gt
• lt/bodygt
• lt/htmlgt

1
49
Expresiones

• La expresión es una notación para un scriptlet
  que envía el valor de la expresión en java de
  vuelta al cliente.
• Se evalua en la solicitud HTTP y el resultado se
  convierte a String y desplegada.
• La expresión se encierra entre etiquetas lt gt

1
50
Expresiones ejemplo

• lt_at_ page language"Java" gt
• lthtmlgtltheadgtlttitlegtUn titulolt/titlegtlt/headgt
• ltbodygt
• lth1gtPagina de prueba de expresioneslt/h1gt
• lt! int i0 gt
• lt i gt
• Hola Mundo
• lt "Esta pagina se ha accesado " i " veces"
  gt
• lt/bodygt
• lt/htmlgt

1
51
Servidor de AplicacionesTOMCAT
52
Arquitectura
53
Elementos de la arquitectura. Conectores

• Conectan las aplicaciones a los clientes
• Tienen asignados un puerto único en el servidor
• El puerto por defecto para aplicaciones no
  seguras es el 8080
• Puede ser cambiado al 80 si no existe otro
  servidor WEB
• El Conector por defecto es COYOTE, el cual
  atiende las solicitudes HTTP/1.1
• Otros conectores son Jserv (Apache Jserv), SSL y
  HTTP/1.0 (para ligar otros servidores web)

54
Directorio conf

• Archivo server.xml
• Archivo primario de configuración.
• Archivo web.xml
• Archivo genérico de configuración de
  aplicaciones. Se utiliza para aquellas
  aplicaciones que no lo tienen definido.
• Conocido como el deployment descriptor.
• Si está definido en la aplicación, sus
  propiedades siempre sobreescriben las
  configuraciones generales.

55
Archivo web.xml

• Contenido mínimo del archivo
• lt?xml version"1.0" encoding"ISO-8859-1"?gt
• lt!DOCTYPE web-app
• PUBLIC "-//Sun Microsystems, Inc.//DTD Web
  Application 2.3//EN"
• "http//java.sun.com/dtd/web-app_2_3.dtd"gt
• ltweb-appgt
• lt/web-appgt

56
Variable CATALINA_BASE

• La variable CATALINA_BASE define el directorio
  base en donde el servidor busca el directorio
  conf.
• Es posible tener varios servidores TOMCAT en un
  solo sistema, definiendo esta variable para cada
  uno de ellos.
• Si no está definida entonces se emplea el valor
  de la variable de ambiente

57
Scripts de inicialización
58
Variables de ambiente
59
Ejemplo de uso de variables de ambiente

• Para limitar la memoria que va a ocupar la
  aplicación
• export CATALINA_OPTSXmx64M
• Para definir el directorio hogar de Tomcat
• export CATALINA_HOMEdirectorio1
• Para definir otro directorio de trabajo
• export CATALINA_BASEdirectorio2
• Para definir la ubicación del JDK
• Export JAVA_HOME/usr/java/jdk1.XX

60
Integrando Tomcat y Apache

• Se realiza a través de un connector
• Apache JServ Protocol
• JK13 para el protocolo JK-1.3
• JK12 para el protocolo JK-1.2
• Se emplea para conectar servidores WEB y Tomcat
• Básicamente, lo que hace es redireccionar la
  solicitud recibida por Apache hacia Tomcat a
  través de un puerto bien conocido

61
JK12 connector

• Se descarga del sitio de Tomcat
• http//tomcat.apache.org/connectors-doc/index.html
  
• Es necesario descargar el binario adecuado a la
  versión de Apache
• Apache Web Server 1.3xx
• Apache Web Server 2.xxx
• Se distribuye como un módulo de Apache
  (mod_jk.so)
• El Apache debe haber sido compilado con soporte a
  módulos (SO)

62
Arquitectura del JK12

• Se compone de workers
• El conector puede ser compartido por varios
  contextos, pero cada uno de ellos tendrá asociado
  un worker distinto.
• Un worker es una instancia de Tomcat esperando
  para ejecutar servlets a solicitud de un servidor
  WWW.
• Pueden asociarse a servidores virtuales.
• Pueden proveer balanceo de carga teniendo
  múltiples workers en su propio equipo y
  distribuyendo las solicitudes entre ellos.

63
Workers.properties

• Archivo de definición de los workers
• Sintaxis
• worker.ltworker namegt.ltdirectivegtltvaluegt
• El nombre puede ser cualquier cadena alfanumérica
  y no es sensible a las mayúsculas y minúsculas
• Worker.listajp13,localhost

64
Directivas workers.properties

• worker.listajp13,localhost
• Lista de workers que se instancian al momento de
  iniciar Tomcat
• worker.maintain60
• Tiempo para mantener el pool de workers en
  segundos.
• En este tiempo el Tomcat revisa si las conexiones
  requieren ciclarse.

65
Directivas workers.properties

• worker.listlocalhost
• Lista de workers
• worker.localhost.port8009
• Puerto de escucha del worker
• worker.localhost.hostlocalhost
• Nombre o IP del servidor Tomcat
• Puede ser local o remoto
• worker.localhost.typeajp13
• ajp13, ajp14, jni, lb, status
• El tipo define las directrices aplicables a cada
  uno de ellos
• Worker.localhost.socket_timeout0
• Tiempo de vencimiento para esperar la conexión
  del socket. El valor de 0 implica una espera
  infinita.

66
Directivas workers.properties

• Workers.localhost. socket_keepalivefalse
• Útil para firewalls. Un valor positivo implica
  que el Tomcat va a enviar un mensaje KEEP_ALIVE
  en conexiones inactivas.
• Evita que el firewall deseche las conexiones
  inactivas
• Workers.localhost.recycle_timeout0
• Tiempo en segundos para que Tomcat recicle una
  conexión inactiva.
• Si es 0, no realiza el reciclaje.
• Workers.localhost.retries3
• Número de intentos de reconexión cuando éstas
  fueron fallidas.
• Workers.localhost.cachesize1
• Tamaño del pool de conexiones con servidores
  basados en hilos (Apache 2.0, IIS)
• Workers.localhost.cachetimeout0
• Tiempo para mantener abierto una conexión del
  pool.
• Workers.localhost.lbfactor1
• Indica la cuota de trabajo que va a tener este
  worker con respecto a otros.
• Por ejemplo, si es 5, se espera que trabaje 5
  veces más que otro con valor 1.

67
Directivas workers.propertiesload balancing

• Este worker es virtual y se encarga de
  administrar workers reales.
• Tipo de worker lb
• Las directivas definen los parámetros necesarios
  para crear workers que se conectan a un cluster
  remoto de servidores Tomcat. Cada nodo del
  cluster debe tener un worker definido.
• El manejo incluye
• Instanciar los workers en el servidor.
• Mediante el factor de balanceo, realiza un
  balanceo por round-robin balanceado.
• Mantiene las solicitudes pertenecientes a la
  misma sesión ejecutandose en el mismo worker de
  Tomcat.
• Identifica workers fallidos, evitando enviarles
  solicitudes nuevas.

68
Directivas para balanceo de carga

• balance_workers
• Lista separada por comas de workers reales que va
  a administrar.
• sticky_sessiontrue
• Relaciona al JID con un solo worker para
  asegurarse que siempre es atendido por el mismo.
• sticky_session_forcefalse
• Se asegura que una sesión asociada a un worker
  fallido no sea atendido por otro worker. El
  usuario recibe un error 500.
• MethodRequest,Traffic
• Especifica el método para calcular el balanceo de
  carga, ya sea por número de solicitudes o por
  tráfico.
• LockOptimistic,Pesimistic
• Especifica si se realiza un bloqueo optimista o
  pesimista para sincronizar la memoria compartida
  durante el runtime.
• Secret
• Palabra secreta compartida entre servidores
  Tomcat. Solamente se realiza la conexión si los
  servidores comparten la misma palabra secreta.

69
Configuración de Apache

• JkWorkersFile /etc/httpd/conf/workers.properti
  es
• JkLogFile /var/log/httpd/mod_jk.log
• JkLogLevel info,warn,debug,error,trace
• JkLogStampFormat "a b d HMS Y
• Jkoptions
• Opciones de reenvío de la solicitud.
• ForwardURICompat, ForwardDirectories,
  ForwardLocalAddress

70
Asignando URL a Tomcat

• JkMount URL prefix Worker name
• send all requests ending in .jsp to worker1
• JkMount /.jsp worker1
• send all requests ending /servlet to worker1
• JkMount //servlet/ worker1
• send all requests jsp requests to files
  located in /otherworker will go worker2
• JkMount /otherworker/.jsp worker2
• JkUnmount
• do not send requests ending with .gif to
  worker1
• JkUnMount /.gif worker1
• The .gif files will not be mounted cause
  JkUnMount takes
• precedence over JkMount directive
• JkMount /servlet/.gif worker1

71
Asignando URL a Tomcat

• JkAutoAlias
• Ejemplo en donde Tomcat sirve el contenido
  dinámico y Apache el dinámico
• enter the full path to the tomcat webapps
  directory
• JkAutoAlias /opt/tomtact/webapps
• Mount 'servlets-examples' directory. It's
  physical location
• is assumed to be in the /opt/tomtact/webapps/s
  ervlets-examples
• ajp13w is a worker defined in the
  workers.properties
• JkMount /servlets-examples/ ajp13w
• Unmount desired static content from
  servlets-examples webapp.
• This content will be served by the httpd
  directly.
• JkUnMount /servlets-examples/.gif ajp13w
• JkUnMount /servlets-examples/.jpg ajp13w

72
Ejemplo en Apache

• Workers.properties
• worker.listlocalhost
• worker.localhost.port8009
• worker.localhost.hostlocalhost
• worker.localhost.typeajp13
• httpd.conf
• LoadModule jk_module modules/mod_jk.so
• ltIfModule mod_jk.cgt
• JkWorkersFile /etc/httpd/conf/workers.properties
• JkLogFile /var/log/httpd/mod_jk.log
• JkLogLevel warn
• JkMount /supersabios/ localhost
• JkMount /supersabios localhost
• JkMount /supersabios/.jsp localhost
• lt/IfModulegt

73
(No Transcript)