Desarrollo de pginas Web Unidad 6 J2EE

Arquitectura J2EE

Introduccin
Las razones que empujan a la creacin de la plataforma JEE: Programacin eficiente. Para conseguir productividad es importante que los equipos de desarrollo tengan una forma estndar de construir mltiples aplicaciones en diversas capas (cliente, servidor web, etc.). En cada capa necesitaremos diversas herramientas, por ejemplo en la capa cliente tenemos applets, aplicaciones Java, etc. En la capa web tenemos servlets, pginas JSP, etc. Con JEE tenemos una tecnologa estndar, un nico modelo de aplicaciones, que incluye diversas herramientas; en contraposicin al desarrollo tradicional con HTML, Javascript, CGI, servidor web, etc. que implicaba numerosos modelos para la creacin de contenidos dinmicos, con los lgicos inconvenientes para la integracin. Extensibilidad frente a la demanda del negocio. En un contexto de crecimiento de nmero de usuarios es precisa la gestin de recursos, como conexiones a bases de datos, transacciones o balanceo de carga. Adems los equipos de desarrollo deben aplicar un estndar que les permita abstraerse de la implementacin del servidor, con aplicaciones que puedan ejecutarse en mltiples servidores, desde un simple servidor hasta una arquitectura de alta disponibilidad y balanceo de carga entre diversas mquinas. Integracin. Los equipos de ingeniera precisan estndares que favorezcan la integracin entre diversas capas de software.

La plataforma JEE implica una forma de implementar y desplegar aplicaciones empresariales. La plataforma se ha abierto a numerosos fabricantes de software para conseguir satisfacer una amplia variedad de requisitos empresariales. La arquitectura JEE implica un modelo de aplicaciones distribuidas en diversas capas o niveles (tier). La capa cliente admite diversas tipos de clientes (HTML, Applet, aplicaciones Java, etc.). la capa intermedia (middle tier) contiene subcapas (el contenedor web y el contenedor EJB). La tercera capa dentro de esta visin sinttica es la de de aplicaciones 'backend' como ERP, EIS, bases de datos, etc. Como se puede ver un concepto clave de la arquitectura es el de contenedor, que dicho de forma genrica no es ms que un entorno de ejecucin estandarizado que ofrece unos servicios por medio de componentes. Los componentes externos al contenedor tienen una forma estndar de acceder a los servicios de dicho contenedor, con independencia del fabricante.

Page 1 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Algunos tipos de contenedores: Contenedor Web, tambin denominado contenedor Servlet/JSP, maneja la ejecucin de los servlets y pginas JSP. Estos componentes se ejecutan sobre un servidor Enterprise Edition. Contenedor Enterprise JavaBeans, que gestiona la ejecucin de los EJB. Esta ejecucin requiere de un server EE.

Los contenedores incluyen descriptores de despliegue (deployment descriptors), que son archivos XML que nos sirven para configurar el entorno de ejecucin: rutas de acceso a aplicaciones, control de transacciones, parmetros de inicializacin, etc. La plataforma JEE incluye APIs para el acceso a sistemas empresariales: JDBC es el API para accceso a GBDR desde Java. Java Transaction API (JTA) es el API para manejo de transacciones a traves de sistemas heterogeneos. Java Naming and Directory Interface (JNDI) es el API para acceso a servicios de nombres y directorios. Java Message Service (JMS) es el API para el envio y recepcin de mensajes por medio de sistemas de mensajera empresarial como IBM MQ Series. JavaMail es el API para envio y recepcin de email. Java IDL es el API para llamar a servicios CORBA.

Page 2 of 28

Desarrollo de pginas Web Unidad 6 J2EE

DESCRIPCION DE ALGUNOS TERMINOS J2EE. (Java 2 Enterprise Edition). Define un estndar para el desarrollo de aplicaciones empresariales multicapa diseado por Sun Microsystems. J2EE simplifica las aplicaciones empresariales basndolas en componentes modulares y estandarizados, proveyendo un completo conjunto de servicios a estos componentes, y manejando muchos de las funciones de la aplicacin de forma automtica, sin necesidad de una programacin compleja. J2ME. (Java 2 Platform Micro Edition). Edicin Micro. Una ltima versin reducida de Java 2 orientada a aplicaciones para dispositivos electrnicos, como mviles, PDAs, etc. J2SE. (Java 2 Standard Edition). Edicin Estndar. La versin estndar es la ms comn y cuenta con todo lo necesario para para desarrollos de software y acceso a aplicaciones Java. JAR. (Java Archive). Formato de archivo usado para empaquetar todos los componentes requeridos por un Java applet. Los archivos JAR simplifican la descarga de applets de Java ya que todos los componentes (archivos, imgenes, sonidos, clases, etc.) son empaquetados en un archivos simple. Adems JAR soporta compresin de datos. Los archivos JAR utilizan una extensin de igual nombre. JAVA. Lenguaje de programacin orientado a objetos parecido al C++. Se utiliza mucho en la WWW para la carga y ejecucin de programas en el ordenador cliente. Desarrollado por Sun Microsystems como software abierto. JAVA APPLET. Programa Java que funciona a travs de un navegador. JAVA SCRIPT. Lenguaje de programacin de instrucciones desarrollado por Netscape que permite la creacin de sitios Web interactivos. Herramienta relativamente simple que se puede utilizar conjuntamente con los applets de Java (sin ser el mismo lenguaje). JAVAX. Paquete de java que heredado de la clase "java" que contiene los paquetes de la interfaz swing. JDBC. Java Data Base Connectivity. Aplicacin de la interfaz de un programa utilizado para conectar programas escritos en Java a los datos de las bases de datos comunes. JDK. (Java Development Kit). JSP. (Java Server Page). Pgina de Servidor Java. Se refiere a un tipo especial de pginas HTML, en las cuales se insertan pequeos programas que corren sobre Internet (comunmente denominados scripts), se procesan en lnea para finalmente desplegar un resultado final al usuario en forma de HTML. Por lo general dichos programas hacen consultas a bases de datos y dependiendo del resultado que se despliegue ser la informacin que se muestre a cada usuario de manera individual. Los archivos de este tipo llevan la extensin ".jsp".

Page 3 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Servidor de aplicaciones JEE

A continuacin vamos a entrar en ms detalle. Para ello, hemos subrayado en el siguiente grfico los elementos ms importantes y usuales. La arquitectura de un servidor de aplicaciones incluye una serie de subsistemas: Servidor HTTP (tambin denominado servidor Web o servidor de pginas). Un ejemplo, el servidor Apache. Contenedor de aplicaciones o contenedor Servlet/JSP. Un ejemplo, Tomcat (que incluye el servicio anterior sobre pginas) Contenedor Enterprise Java Beans, que contiene aplicativos Java de interaccin con bases de datos o sistemas empresariales. Un ejemplo es JBoss que contiene a los anteriores (servidor de pginas web y contenedor de aplicaciones web).

Pero conviene empezar por el principio, es decir, el lenguaje bsico de interconexin: el protocolo HTTP. Es un protocolo de aplicacin, generalmente implementado sobre TCP/IP. Es un protocolo sin estado basado en solicitudes (request) y respuestas (response), que usa por defecto el puerto 8080: "Basado en peticiones y respuestas": significa que el cliente (por ejemplo un navegador) inicia siempre la conexin (por ejemplo, para pedir una pgina). No hay posibilidad de que el servidor realice una llamada de respuesta al cliente (retrollamada). El servidor ofrece la respuesta (la pgina) y cierra la conexin. En la siguiente peticin del cliente se abre una conexin y el ciclo vuelve e empezar: el servidor devuelve el recurso y cierra conexin. "Sin estado": el servidor cierra la conexin una vez realizada la respuesta. No se mantienen los datos asociados a la conexin. Ms adelante veremos que hay una forma de persistencia de datos asociada a la "sesin".

Qu ocurre cuando un navegador invoca una aplicacin? El cliente (el navegador) no invoca directamente el contenedor de aplicaciones, sino que llama al servidor web por medio de HTTP. El servidor web se interpone en la solicitud o invocacin; siendo el servidor web el responsable de trasladar la solicitud al contenedor de aplicaciones.

Page 4 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Aspectos a considerar de forma sncrona: El cliente (normalmente por medio de un navegador, aunque podra ser una aplicacin Swing) solicita un recurso por medio de HTTP. Para localizar el recurso al cliente especifica una URL (Uniform Resource Locator), como por ejemplo http://www.host.es/aplicacion/recurso.html. El URI (Uniform Resource Identifier) es el URL excluyendo protocolo y host. Existen diversos mtodos de invocacin, aunque los ms comunes son POST y GET. Los veremos ms adelante. Sobre una misma mquina podemos tener diversas instancias de un AS (Application Server), procurando que trabajen sobre puertos diferentes, para que no se produzcan colisiones (por defecto HTTP trabaja con 8080). Un servicio crucial es la capacidad de recibir peticiones HTTP, para lo cual tenemos un HTTP Listener (aunque puede tener listeners para otros protocolos como IIOP). La solicitud llega el servidor de pginas web, que tiene que descifrar si el recurso solicitado es un recurso esttico o una aplicacin. Si es una aplicacin delega la solicitud en el contenedor web (contenedor Servlet/JSP). El contenedor web gestiona la localizacin y ejecucin de Servlets y JSP, que no son ms que pequeos programas. El contenedor web o contenedor Servlet/JSp recibe la solicitud. Su mquina Java (JVM) invoca al objeto Servlet/JSP, por tanto nos encontramos ante un tipo de aplicaciones que se ejecutan en el servidor, no en el cliente. No conviene olvidar que un Servlet o un JSP no es ms que una clase Java. Lo ms interesante en este sentido es que: o La JVM (generalmente) no crea una instancia de la clase por cada solicitud, sino que con una nica instancia de un Servlet/JSP se da servicio a mltiples solicitudes HTTP. Esto hace que el consumo de recursos sea pequeo en comparacin con otras opciones, como el uso de CGIs, en donde cada solicitud se resuelve en un proceso. o Para cada solicitud se genera un hilo (thread) para resolverla (pero con una nica instancia de la clase, como hemos dicho). Un Application Server tendr un servidor de administracin (y normalmente un manager de las aplicacin).

Otros aspectos del contenedor web: El contenedor necesita conectores que sirven de intermediarios para comunicarse con elementos externos. Los conectores capacitan al AS para acceder a sistemas empresariales (backends). Por ejemplo:

Page 5 of 28

Desarrollo de pginas Web Unidad 6 J2EE

El Java Message Service ofrece conectividad con sistemas de mensajeria como MQSeries. o El API JDBC da la capacidad de gestionar bases de datos internas al AS, pero adems permite ofrecer servicios como un pool de conexiones. Es necesario una gestin de hilos, ya que ser necesario controlar la situacin en la que tenemos una instancia de un componente (por ejemplo, un servlet) que da respuesta a varias peticiones, donde cada peticin se resuelve en un hilo. o

Las capas de la arquitectura

En la arquitectura JEE se contemplan cuatro capas, en funcin del tipo de servicio y contenedores: Capa de cliente, tambin conocida como capa de presentacin o de aplicacin. Nos encontramos con componentes Java (applets o aplicaciones) y no-Java (HTML, JavaScript, etc.). Capa Web. Intermediario entre el cliente y otras capas. Sus componentes principales son los servlets y las JSP. Aunque componentes de capa cliente (applets o aplicaciones) pueden acceder directamente a la capa EJB, lo normal es que Los servlets/JSPs pueden llamar a los EJB. Capa Enterprise JavaBeans. Permite a mltiples aplicaciones tener acceso de forma concurrente a datos y lgica de negocio. Los EJB se encuentran en un servidor EJB, que no es ms que un servidor de objetos distribuidos. Un EJB puede conectarse a cualquier capa, aunque su misin esencial es conectarse con los sistemas de informacin empresarial (un gestor de base de datos, ERP, etc.) Capa de sistemas de informacin empresarial.

La visin de la arquitectura es un esquema lgico, no fsico. Cuando hablamos de capas nos referimos sobre todo a servicios diferentes (que pueden estar fsicamente dentro de la misma mquina e incluso compartir servidor de aplicaciones y JVM)

Page 6 of 28

Desarrollo de pginas Web Unidad 6 J2EE

A continuacin veremos algunos de los diversos escenarios de aplicacin de esta arquitectura

Escenario desde un navegador

Es el escenario cannico, donde aparecen todas las capas, empezando en un navegador HTML/XML. La generacin de contenidos dinmicos se realiza normalmente en pginas JSP. La capa EJB nos permite desacoplar el acceso a datos EIS de la interaccin final con el usuario que se produce en las pginas HTML y JSP:

XML utiliza HTTP como su soporte para el trasnporte. Una pregunta muy comn es cuando usar servlets y cuando usar pginas JSP. La pregunta es lgica, al fin y al cabo ambos mecanismos permiten generar contenidos dinmicos y adems las JSP son servlets generados por el servidor de aplicaciones. La norma es que la mayor parte de las interacciones con el usuario se realizarn en las JSP debido a su flexibilidad, ya que integran de forma natural etiquetas HTML, XML, JSF, etc. Los servlets sern la excepcin (un ejemplo tpico es usar un servlet como controlador (un controlador recibe peticiones o eventos desde el interfaz de cliente y "sabe" el componente que debe invocar).

Escenario desde una aplicacin

Podemos considerar que tenemos como cliente una aplicacin stand-alone, que puede ser una aplicacin Java o incluso un programa en Visual Basic. La aplicacin puede acceder directamente a la capa EJB o a la base de datos del EIS (esto ltimo por medio de JDBC):

Page 7 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Escenario basado en la web (web-centric application)

La plataforma JEE no obliga a usar en un sistema todas las capas. Lo esencial es escoger el mecanismo adecuado para el problema. En este sentido, en ocasiones no hay (ni prevemos que haya) la complejidad como para requerir una capa EJB. Se denomina escenario webcentric porque el contenedor web es el que realiza gran parte del trabajo del sistema:

En este tipo de escenario la capa web implica tanto lgica de presentacin como lgica de negocio. Pero lo deseable es no mezclar todas las cosas, planteando un diseo limpio y modular. Para ello las JSP y servlets no suelen acceder de forma directa a la base de datos, sino que lo hacen por medio de un servicio de acceso a datos:

Page 8 of 28

Desarrollo de pginas Web Unidad 6 J2EE

El escenario web-centric es el ms ampliamente utilizado actualmente.

Resumen Aplicacin distribuida Es una aplicacin con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a travs de una red. Las tpicas aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (clientemiddleware-servidor) y multinivel. Enterprise JavaBeans

Los Enterprise JavaBeans (EJBs) son aplicaciones. Si los servlets actan como despachadores centrales para nuestra aplicacin y manejan la lgica de presentacin. Los EJBs hacen el trabajo duro real con los datos de la aplicacin y regula el proceso pero sin proporcionar presentacin visible para el usuario. Los EJBs nos pemiten dividir la lgica de negocio, la reglas, y los objetos en unidades discretas, modulaes y escalables. Cada EJB encapsula una o ms tareas de la aplicacin o objetos de aplicacin, incluyendo estructuras de datos y mtodos que operan sobre ellas. Tpicamente, los EJBs tambin toman parmetros y envan valores de retorno. Los EJBs siempre funcionan dentro del contexto de un "contenedor", que sirve como un enlace entre los EJBs y los servidores que los hospedan. Como desarrollador de iPlanet Application Server, no necesitamos preocuparnos del contenedor de nuestros EJBs. El entorno software iPlanet Application Server proporciona el contenedor. Este contenedor proporciona todos los servicios estndards denotados en la especificacin EJB 1.1. Tambin proporciona servicios adicionales como control de fallos de beans de sesin con estado. De hecho, el contenedor puede manejar todos los accesos remotos, la seguridad, la concurrencia, el control de transacciones, y el acceso a bases de datos. Como los detalles de la implementacin real son parte del contenedor, y hay un estndard, prescribiendo un interface entre un contenedor y sus EJBs, el desarrollador de beans est liberado de tener que conocer o manejar los detalles de implementacin especficos de la plataforma. En su lugar, el desarrollador de beans enterprise puede crear EJBs genricos, enfocados al a tarea para usarlos con cualquier producto de otros vendedores que soporten el estndard EJB.

Beans de Sesin y de Entidad

Hay dos clases de EJBs: de entidad y de sesin. Cada uno de estos tipos de bean se usan de forma diferente en un servidor de aplicaciones. Un EJB puede ser un objeto que representa un servicio sin estado, u un objeto que representa una sesin con un cliente particular (y que mantiene automticamente el estado entre mltiples llamadas a mtodos del cliente), o puede ser un objeto de entidad persistente

Page 9 of 28

Desarrollo de pginas Web Unidad 6 J2EE

posiblemente compartido entre varios clientes. Un bean de sesin implementa lgica de negocio. Toda la funcionalidad de acceso remoto, seguridad, concurrencia, y transaciones la proporciona el contendor de EJBs. Un EJB de sesin es una fuente privada usada slo por el cliente que la crea.

Beans de Entidad
Los beans de entidad normalmente representan datos persistentes. Estos datos estn mantenidos directamente en una base de datos, o son accedidos a travs de aplicaciones finales como objetos. Un ejemplo simple de un bean de entidad sera uno que est definido para representar una fila en una tabla de base de datos, y donde cada ejemplar del Bean representa una fila especfica. Un ejemplo ms complejo sera un Bean de Entidad diseado para representar vistas complicadas de tablas unidas en una base de datos dode cada ejemplar del Bean representara los contenidos de una carta de compra de un cliente. Al contrario que los Beans de sesin, los ejemplares de beans de entidad pueden ser accedidos simultneamente por varios clientes. El contenedor es el responsable de sincronizar el estado del ejemplar usando transaciones. Esta delegacin de responsabiliades en el contenedor, significa que el desarrollador del bean no tiene que preocuparse sobre los accesos concurrentes a mtodos desde mltiples transaciones. La persistencia de un Bean de entidad puede ser manejada por el propio bean, o por el contenedor del Bean, Cuando un Bean de Entidad maneja su propia persistenia, se llama persistencia manejada por el Bean. Cuando un bean delega esta funcin al contendor, se llama persistencia manejada por el contenedor (CMP).

Persistencia Manejada por el Bean. El desarrollador del bean debe implementar directametne cdigo de persistencia (como llamadas JDBC) en los mtodos de la clase EJB, si el bean va a manejar sus propia persistencia. La posible inconveniencia de esta implementacin es la prdida de portabilidad, si se usa un interface propietario, y tambin puede existir el riesgo de atar el bean a una base de datos especfica. Persistencia Manejada por el Contenedor (CMP). El proveedor de contenedor usa iPlanet Application Server Deployment Tool (iASDT) para generar el cdigo del bean para implementar el proceso de persistencia de contenedor. El contenedor controla, de forma transparente para el bean, el estado de persistencia. El desarrollador del bean no necesita implementar ningn cdigo de acceso a datos en los mtodos del bean. Este mtodo no slo simplifica el desarrollo de la implementacin del bean, sino que lo hace totalmente portable, sin ataduras con ninguna base de datos. Finalmente, se puede instalar cualquier nmero de beans de entidad en un contenedor. El contenedor implementa un interface home por cada bean de entidad. Este interface permite a un cliente crear, buscar, y eliminar objetos entity. Un cliente puede buscar el interface home de un bean de entidad a travs de Java Naming and Directory Interface (JNDI).

Modelo de Programacin de J2EE

iPlanet Application Server 6.0 cumple la especificacin de Java 2 Platform, Enterprise Edition versin 1.2 (J2EE 1.2) y est basado en los estndards desarrollados por la comunidad Java, incluyendo servlets, JavaServer Pages, y Enterprise JavaBeans. El modelo de programacin de iPlanet Application Server 6.0 es slo para aplicaciones Java. Las aplicaciones C++ continan usando el modelo NAS 2.1. iPlanet Application Server 6.0 es compatible hacia atrs con aplicaciones NAS 2.1. Las aplicaciones NAS 2.1 se pueden ejecutar en iPlanet Application Server 6.0 sin ninguna modificacin del cdigo. Las aplicaciones NAS 4.0 son compatibles con la conversin al estndard J2EE y necesitan alguna conversin. Al flujo de la aplicacin es similar entre el modelo iPlanet Application Server 6.0 y los modelos de las versiones anteriores 4.0 y 2.1. Toda interaccin del usuario es manejada por uno (o ms) componentes de aplicacin que procesan las entradas, realizan las funciones de la lgica de negocios, interactan con una base de datos, y proporcionan una pgina de salida que responde a las entradas y configura la siguiente interaccin con el usuario. El nuevo modelo de programacin describe tres capas de lgica de aplicacin, cada una de las cuales est representada por un conjunto de componentes o APIs.

Page 10 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Lgica de Presentacin y Distribucin
La lgica de presentacin describe el flujo de una aplicacin desde la perspectiva de cada interaccin de usuario: procesa la solicitud, seguido por la generacin y entrega del contenido. El objetivo de la lgica de presentacin es crear una respuest lgica a una solicitud, y pedir otra solicitud. El objetivo de la distribucin de presentacin es mostrar el contenido de esta respuesta en un formato predeterminado. Las funciones de una aplicacin como las sesiones de usuario, la seguridad y autentificacin de usuarios, la validacin de entrada tambin son manejadas por la lgica de presentacin. En breve, la lgica de presentacin implica cualquier cosa relacionada con el interface de la aplicacin con el usuario. En el modelo de programacin NAS 2.1, la lgica de presentacin estaba controlada por un AppLogic, mientras que la distribucin era manejada por una plantilla HTML. En tiempo de ejecucin, el AppLogic proporcionaba la salida para rellenar la plantilla. En el modelo de programacin de iAS 6.0, la lgica de presentacin normalmente est manejada por un servlet. La distribucin es manjeada por una JSP. Durante la ejecucin, el servlet usa una JSP para formatear el contenido generado por la lgica de negocio. Aqu tenemos las dos principales alternativas a este modelo bsico:

Manejar toda la lgica de presentacin y de distribucin para una interaccin dada en una JSP. Esto puede ser una forma fcil de controlar una interaccin que no tiene lgica de negocio y poco porceso desde la interaccin anterior. Por ejemplo, la pgina inicial de una aplicacin normalmente no requiere procesar nada. Manajear todoa la lgica de presentacin y de distribucin en un servlet. Esto puede ser muy eficiente para interacciones que tienen muy poca distribucin. Por ejemplo, un simple informe de base de datos podra listar solo las filas recuperadas desde una consulta a la base de datos. No tiene sentido sobrecargar una llamada a una JSP cuando la pgina se podra mostrar simplemente desde el servlet.

Lgica de Negocios
La lgica de negocio describe las actividades que implican las generacin de contenido especfico: almacenamiento y recuperacin de datos, y realizar clculos con los datos. El objetivo de la lgica de negocios es realizar las actividades que generan o determinan las respuestas a preguntas poseidas por la lgica de presentacin. En breve, la lgica de negocio implica el contenido proporcionado a y generado por la aplicacin. En el modelo de programacin NAS 2.1, la lgica de negocio estaba controlada por el mismo AppLogic que manejaba la lgica de presentacin para una interaccin de usuario dada. En el modelo de programacin iAS 6.0, la lgica de negocio normalmente es manejada por uno o ms Enterprise JavaBeans (EJBs), que controlan las transaciones con bases de datos y encapsulan los resultados. Los EJBs son componentes poderosos, reutilizables que potencian las aplicaciones con una gran flexibilidad, ya que los EJB pueden ser llamados o inspeccioandos desde cualquier otro objeto y pueden hacerse persistentes. Una alternativa a este modelo es manejar la lgica de negocios en la lgica de presentacin (servlets y/o JSPs), de la misma forma en que lo haca AppLogics. Esto puede ser eficiente para pequeos eventos dirgidos a negocio como una peticin de directorio especfica, pero esta aproximacin pierde la flexibilidad y el poder que traen los EJBs al modelo de programacin.

Introduccin a JDBC
JDBC es un conjunto de clases y mtodos Java qe nos permiten embeber llamadas a bases de datos en nuestras aplicaciones de servidor. Esto es todo lo que necesitamos saber para empezar a usar JDBC en nuestras aplicaciones de servidor.

Page 11 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Ms especficamente, JDBC es un conjunto de interfaces que todo vendedor de servidores, como iPlanet, debe implementar de acuerdo a las especificaciones JDBC. iPlanet Application Server porporciona un driver JDBC del tipo 2 que soporta una gran variedad de bases de datos finales. Este driver procesa las sentencias JDBC de nuestras aplicaciones y enruta los argumentos SQL que contienen hacia nuestros motores de bases de datos. Ejercicio para desarrollar aplicacin con J2EE

http://www.programacion.com/articulo/eclipse__ix__construir_y_ejecutar_aplicaciones_web _con_wtp_333#3_1_proyecto

HTML
http://www.w3.org/MarkUp/

XML
http://www.w3schools.com/xml/

Desarrollo de cliente Web JavaScript

Qu es JavaScript? JavaScript, al igual que Java o VRML, es una de las mltiples maneras que han surgido para extender las capacidades del lenguaje HTML.Al ser la ms sencilla, es por el momento la ms extendida. Antes que nada conviene aclarar lo siguiente: JavaScript no es un lenguaje de programacin propiamente dicho. Es un lenguaje script u orientado a documento, como pueden ser los lenguajes de macros que tienen muchos procesadores de texto. Nunca podrs hacer un programa con JavaScript, tan slo podrs mejorar tu pgina Web con algunas cosas que veremos en apartados posteriores de este captulo. Para qu sirve JavaScript? JavaScript sirve principalmente para mejorar la gestin de la interfaz cliente/servidor. Un script JavaScript insertado en un documento HTML permite reconocer y tratar localmente, es decir, en el cliente, los eventos generados por el usuario. Estos eventos pueden ser el recorrido del propio documento HTML o la gestin de un formulario. Vemos un ejemplo: Cuando la pgina HTML es un formulario que permite acceder a una anuario telefnico, se puede insertar un script que verifique la validez de los parmetros proporcionados por el usuario. Esta prueba se efecta localmente y no necesita un acceso a la red. Por otro lado, tambin se podr utilizar JavaScript para efectuar varias opciones a la vez; por ejemplo, acompaar el acceso a un documento HTML de la visualizacin de un vdeo o la ejecucin de un applet de Java... Utilizacin de JavaScript en un documento HTML.

Page 12 of 28

Desarrollo de pginas Web Unidad 6 J2EE

La insercin de un documento HTML se realiza mediante la marca SCRIPT utilizando la sintaxis: <SCRIPT> Cdigo del script </SCRIPT>

Los atributos de esta marca son: LANGUAGE="JavaScript" Precisa el lenguaje del script. Este atributo es obligatorio en ausencia del atributo SRC. SRC=url El atributo SRC precisa el URL del script a insertar en el documento. Este atributo es opcional, porque el script puede insertarse directamente en un documento HTML. Estos dos atributos pueden especificarse simultneamente. Por ejemplo: <SCRIPT LANGUAGE="lenguaje" SCR=url> Cdigo del script </SCRIPT> podr especificarse para insertar en un documento un script de un lenguaje determinado y que cuyo cdigo fuente se encuentra en un acrhivo especificado en un determinado url. A continuacin enunciaremos algunos puntos a tener encuenta respecto a la introduccin de JavaScript en un documento HTML: El script insertado mediante la marca SCRIPT es evaluado por el cliente tras la visualizacin de la pgina HTML. Las funciones definidas no se ejecutan inmediatamente, dependen de los eventos asociados a la pgina. La insercin del script mediante la marca SCRIPT puede colocarse en cualquier lugar del documento HTML pero se recomienda colocarla en la cabecera, es decir, en la zona definida por el HEAD. De este modo, el script est definido desde el principio del documento, lo que garantiza que ste se visible en todo el documento. Si se definen, adems del script mediante el atributo SRC, scripts en el propio documento, el cliente evaluar en primer lugar el insertado mediante el atributo SRC y seguidamente los incluidos en el documento. Los URL correspondientes a un JavaScript poseen generalmente la extencin .js. Es preferible delimitar los scripts insertados en un documento por comentarios HTML para asegurarse de que el contenido del script no aparecer en los clientes que no reconozcan la marca SCRIPT. Por ejemplo:

<SCRIPT LANGUAGE="JavaScript"> <-- Disimula el contenido del script para navegadores no compatibles Cdigo del script //--> </SCRIPT> El lenguaje JavaScript no es case sensitive, es decir, no distinque maysculas de minsculas salvo en las cadanas de caracteres literales.

Page 13 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Por ltimo, comentar otra forma de introducir scripts en documentos HTML, y es incluir estos script como controladores de eventos de algunas marcas, como pueden ser la marcas de imgenes, anclas, links, botonoes, etc. Veamos a continuacin un ejemplo: <A HREF="index.htm" OnClick="alert('ir al ndice')"> Ir al ndice </A> Mas detalle http://www.ulpgc.es/otros/tutoriales/JavaScript/index.htm

Applets
Se hace un repaso de Applets, el cual es un tema que se ve en programacin avanzada. Ver Anexo A.

Ajax
Asynchronous JavaScript and XML (Ajax)

En cuanto a la implementacin, bsicamente tenemos componentes JavaScript en el navegador para interactuar con el usuario y en el servidor para recibir, procesar y responder solicitudes, que pueden implementarse en Java y actualmente contamos con numerosas libreras o frameworks como Prototype, Dojo, Yahoo UI (YUI) Toolkit o Google Web Toolkit. Dado que existen numerosas introducciones a esta tecnologa (ver Algunos links interesantes) no vamos a extendernos mucho ms en la descripcin tcnica de Ajax sino que nos centraremos en una implementacin concreta: Direct Web Remoting (DWR).

Introduccin a DWR
DWR es una librera open source para implementar rpidamente soluciones Ajax, permitindonos invocar objetos Java alojados en un servidor desde el JavaScript de un navegador como si fueran objetos locales. Esta librera cuenta con dos partes principales:

Javascritp ejecutndose en el navegador que enva solicitudes y recibe respuestas con las que actualiza el contenido de la pgina Un servlet que procesa las solicitudes y genera respuestas

DWR genera dinmicamente el JavaScript que actuar como proxy de las clases Java. Este cdigo har la magia para que desde el JavaScript del navegador se utilicen las clases Java del servidor como si fueran objetos locales. Java es fundamentalmente sncrono mientras que Ajax es asncrono, as que cuando se invoca un mtodo remoto se debe proporcionar una funcin JavaScript de callback que ser invocada cuando llegue la respuesta. El siguiente diagrama muestra como DWR puede cambiar el contenido de un combo como resultado de un evento (por ejemplo, onclick).
Page 14 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Fuente y ejempl o http:// www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=AjaxConJavaFacil Para un ejemplo de ajax http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=beginAjax

Accesibilidad y usabilidad
http://www.manuelrecena.com/docs/accesibilidad_usabilidad_w3c_041211.pdf http://www.programacion.com/articulo/master_j2ee_de_oracle:_paso_5_de_12:_construir_s oftware_mas_usable_318

Desarrollo del servidor web

Introduccin
Como se ha visto en el apartado Eleccin del lenguaje, el lenguaje que mejor rendimiento ofrece en el router es el Lua, por lo que el desarrollo de los scripts de configuracin se har en dicho lenguaje. Sin embargo, se ha querido dar un paso ms y desarrollar un servidor (tambin en Lua) que ofrezca un interfaz web para facilitar la labor de configuracin del router.
Qu es un servidor web?

Un servidor web es un programa que est diseado para transferir hipertextos, pginas web o pginas HTML (HyperText Markup Language): textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de msica. El programa implementa el protocolo HTTP (HyperText Transfer Protocol) que pertenece a la capa de aplicacin del modelo OSI. El trmino tambin se emplea para referirse al ordenador que ejecuta el programa.

Page 15 of 28

Desarrollo de pginas Web Unidad 6 J2EE

El Servidor web se ejecuta continuamente en un ordenador, mantenindose a la espera de peticiones por parte de un cliente (un navegador web) y que responde a estas peticiones adecuadamente, mediante una pgina web que se exhibir en el navegador o mostrando el respectivo mensaje si se detect algn error. A modo de ejemplo, al teclear www.wikipedia.org en nuestro navegador, ste realiza una peticin HTTP al servidor de dicha direccin. El servidor responde al cliente enviando el cdigo HTML de la pgina; el cliente, una vez recibido el cdigo, lo interpreta y lo exhibe en pantalla. Como vemos con este ejemplo, el cliente es el encargado de interpretar el cdigo HTML, es decir, de mostrar las fuentes, los colores y la disposicin de los textos y objetos de la pgina; el servidor tan slo se limita a transferir el cdigo de la pgina sin llevar a cabo ninguna interpretacin de la misma. 1)
Qu es el protocolo HTTP?

El protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol) es el protocolo usado en cada transaccin de la Web (WWW). Es un protocolo orientado a transacciones y sigue el esquema peticin-respuesta entre un cliente y un servidor. Al cliente que efecta la peticin (un navegador o un spider) se lo conoce como user agent (agente del usuario). A la informacin transmitida se la llama recurso y se la identifica mediante un URL. Los recursos pueden ser archivos, el resultado de la ejecucin de un programa, una consulta a una base de datos, la traduccin automtica de un documento, etc. HTTP es un protocolo sin estado, es decir, que no guarda ninguna informacin sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es informacin que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la nocin de sesin, y tambin permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado. 2)
Ejemplo de un dilogo HTTP

Para obtener un recurso con el URL http://www.example.com/index.html

1. Se abre una conexin al host www.example.com, puerto 80 que es el puerto por defecto para HTTP. 2. Se enva un mensaje en el estilo siguiente:
3. 4. 5. 6. GET /index.html HTTP/1.1 Host: www.example.com User-Agent: nombre-cliente [Lnea en blanco]

7. La respuesta del servidor est formada por encabezados seguidos del recurso solicitado, en el caso de una pgina web:
HTTP/1.1 200 OK Date: Fri, 31 Dec 2003 23:59:59 GMT Content-Type: text/html Content-Length: 1221 <html> <body> <h1>Pgina principal de tuHost</h1>

Page 16 of 28

Desarrollo de pginas Web Unidad 6 J2EE

(Contenido) . . . </body> </html>

En la peticin del cliente, la primera lnea indica el mtodo, el recurso al que se quiere acceder y el protocolo. En el ejemplo anterior, estos son:

Mtodo: GET Recurso: /index.html Protocolo: HTTP/1.1

En la respuesta del servidor al cliente, la primera lnea indica el protocolo y el cdigo del estado (en este caso 200 indica que no hay errores). Otra cabecera importante es Content-Type, que indica el tipo MIME del recurso que se est enviando, pudiendo ser una pgina web, un tipo de imagen, sonido, etc. Despus de las cabeceras se enva una lnea en blanco y a continuacin el recurso.

Mtodos

HTTP define 8 mtodos: HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS y CONNECT. Sin embargo, en el servidor a desarrollar slo se implementarn GET y POST, ya que son los ms utilizados.

Herramientas de apoyo
Lua es un lenguaje muy rpido y potente, sin embargo, para desarrollar el servidor web es necesario hacer uso de multitud de llamadas al sistema de muy bajo nivel, de las cuales Lua carece. Por ello se ha investigado en varias ramas para poder ampliar la funcionalidad de este lenguaje. La primera aproximacin fue aadir funcionalidades desarrolladas por terceros, como es el caso de LuaSocket y ex API, descritas ya en Eleccin del lenguaje. Sin embargo, con estas extensiones no se cubran todas las necesidades, por lo que sera necesario continuar aadiendo libreras desarrolladas por terceros, con el inconveniente de incrementar cada vez ms las dependencias de la aplicacin con aplicaciones externas, por esto fue descartada esta opcin. Otra posibilidad consista en hacer una biblioteca wrapper (envoltura), de forma que se puedan integrar las llamadas al sistema en C con el lenguaje Lua. Lua cuenta con una interfaz que facilita esta labor, por lo que se vi como una posible solucin. Sin embargo, esta solucin tiene un lado negativo: la biblioteca interfaz entre Lua y C tiene que ser previamente compilada, por lo que por cada funcionalidad nueva que se quiera aadir, sera necesario recompilarla, perdiendo de algn modo los beneficios de trabajar con lenguajes de scripting. Posteriormente se investig una tercera opcin: desarrollar una biblioteca interfaz entre Lua y C (mismo principio del caso anterior), pero en lugar de disponer de una envoltura por cada funcin, se desarrollara una envoltura genrica capaz de ofrecer una interfaz
Page 17 of 28

Desarrollo de pginas Web Unidad 6 J2EE

hacia Lua e invocar a cualquier funcion en C. Esta solucin (la cual fue llamada LuaFlexible) est explicada con ms detalle en LuaFlexible. Sin embargo, al finalizar el desarrollo de LuaFlexible se decidi compartirla con la comunidad Lua. En el momento en el que se dispona a colgar dicha biblioteca en el repositorio, se comprob que ya exista una solucin muy parecida, C/Invoke, con algunos aspectos mejorados respecto a la desarrollada en este proyecto. Se decidi por tanto abandonar LuaFlexible e incoporar C/Invoke, que proporcionaba toda la potencia necesitada para el servidor web.
C/Invoke

Como se ha comentado anteriormente, C/Invoke es una biblioteca capaz de proporcionar una interfaz comn desde Lua a cualquier funcin de C de forma dinmica. Dispone de un manual de refencia en su pgina web, as que no se describir su utilizacin en este apartado, sin embargo se mostrarn los pasos necesarios para su compilacin: Ha sido necesario cambiar algunos ficheros y crear dos nuevos para la arquitectura PowerPC del router. Estas modificaciones se pueden descargar aqu.
wget http://download.savannah.nongnu.org/releases/cinvoke/cinvoke1.0.tgz tar xvpf cinvoke-1.0.tgz cd cinvoke-1.0 mkdir local wget http://laurel.datsi.fi.upm.es/_media/proyectos/teldatsi/cinvoke.tar tar -xvpf cinvoke.tar ./configure.pl --prefix=/Scripting/lua/cinvoke-1.0/local/ CC="powerpc-linux-gcc -Wa,-mregnames" make cd bindings/lua CC="powerpc-linux-gcc" make sudo cp cinvoke_lua.so /NFSroot/usr/local/lib/lua/5.1/

Servidor Web
El servidor web se ha desarrollado completamente en Lua, haciendo uso nicamente de la biblioteca C/Invoke para ampliar las funcionalidades del lenguaje. El servidor web se ha divido en varios mdulos segn sus funcionalidades o servicios que ofrecen. Se puede ver cmo se relacionan los mdulos en el siguiente grfico:

Page 18 of 28

Desarrollo de pginas Web Unidad 6 J2EE

luaCWrapper

Este mdulo no es ms que una interfaz para utilizar de forma cmoda la biblioteca C/Invoke, exporta las siguientes funcionalidades, muy similares a desarrolladas para LuaFlexible:

CWrapper.newLib(nombre, ruta) Crea una nueva referencia para una biblioteca. El parmetro nombre utilizado, ser necesario para acceder a los servicios de esta biblioteca en adelante. As, por ejemplo, si se escribe
CWrapper.newLib("libc","/lib/libc.so.0")

la forma de registrar una funcin de esta biblioteca sera:

CWrapper.libc:registerFunction(Cint, "fork")

CWrapper.lib:registerFunction(ret, simbolo, *tipos+) Registra una funcin, donde lib corresponde al primer argumento de una llamada a newLib anterior. ret es el tipo de valor devuelto, simbolo el nombre de la funcion y tipos son los tipos de los argumentos que recibe la funcin. Tanto ret como tipos deben ser tipos soportados por C/Invoke. CWrapper.libc:registerValue(tipo, simbolo) Registra una variable, donde lib corresponde al primer argumento de una llamada a newLib anterior. tipo es el tipo de la variable y simbolo el nombre de la misma. Tanto tipo debe ser un tipo soportados por C/Invoke.

A continuacin se muestra un ejemplo de cmo se fija una variable de entorno haciendo uso de la llamada al sistema setenv.
require("luaCWrapper") CWrapper.newLib("libc","/lib/libc.so.0"); CWrapper.libc:registerFunction(Cint, "setenv", Cstring, Cstring, Cint);

Page 19 of 28

Desarrollo de pginas Web Unidad 6 J2EE

CWrapper.libc.setenv("SERVER_PROTOCOL","HTTP/1.1",1);

LuaWeb

Este mdulo est pensado para ser incorporado en las pginas webs que se desarrollen en Lua, proporciona un grado de abstraccin sobre el protocolo HTTP/1.1. Incorpora los siguientes servicios:

POST, GET y Cookie: Variables globales de tabla que almacenan los datos devueltos por ExtractPOST, ExtractGET y ExtractCookie respectivamente. Header: Variable global en forma de tabla utilizada en la funcin SetHeader. Puede completarse para enviar ms cabeceras HTTP al cliente, de forma Header[k]=v, donde k es la clave y v el valor. Por ejemplo:
Header["Cache-Control"]="max-age=3600"

ResponseCookies: Variable global en forma de tabla utilizada en la funcin SetHeader, mediante la cual se pueden aadir cookies que se enviarn al cliente. Por ejemplo:
ResponseCookies["CookieDePrueba"] = "ValorDeLaCookie"

EndResponse(): Finaliza la comunicacin con el cliente: enva los ltimos datos al cliente y cierra la entrada y salida estndar del proceso. Es recomendable utilizarla al finalizar una pgina web. ExtractPOST(), ExtractGET(), ExtractCookie(): Que extraen la informacin referente al mtodo POST, GET, y a las cookies, respectivamente, de la variable de entorno oportuna y la almacena en forma de tabla para facilitar su tratamiento. SetHeader(Mime): Enva una cabecera HTTP/1.1 con el tipo mime pasado como argumento. Adems, incorpora a la cabecera todas las cabeceras y cookies contenidas en las variables globales de tabla Header y ResponseCookies respectivamente. Adems, implementa funciones auxiliares como son: o EscapeChars(s): Devuelve una copia del string s, con los caracteres escapados segn las reglas de Lua (ver Patterns de Lua) o CheckIP(ip): Comprueba que ip sea una IP correcta. o CheckString(s): Se utiliza para evitar errores en el manejo de strings. Si s es un string, lo devuelve sin cambios, pero si es nil devuelve un string vaco ().

A la hora de incorporar este mdulo a una web, se puede especificar que automticamente extraiga la informacin del POST y/o que se habilite el manejo de sessions con las variables __EnablePOST y __EnableSession respectivamente. Por ejemplo:
__EnableSession=true; __EnablePOST=true; require("LuaWeb"); ...

Page 20 of 28

Desarrollo de pginas Web Unidad 6 J2EE ModGlobal

Este mdulo, como su nombre indica, es un mdulo global, comn a todos los dems mdulos que implementa funciones que pueden ser utilizadas por stos, tales como codificacin y decodificacin de URLs, funciones de manejo de rutas, entre otras.
Servidor

Este es el mdulo principal, junto con el explicado a continuacin. Implementa el servicio de escucha por un puerto (en nuestro caso el 80), y acepta las conexiones entrantes. Por cada una de las peticiones que llegan al servidor, ste crea un hijo que pasa a ejecutar el cdigo del mdulo ServidorHijo. A continuacin se muestra un diagrama de los distintos pasos que realiza el servidor para atender las peticiones de los clientes:

Pasos 1-10: Se crea un proceso servidor que va a actuar como demonio. El servidor crea un socket TCP que tiene como descriptor sd. A continuacin se asocia a un puerto TCP (en el ejemplo es el puerto 7, sin embargo, al tratarse de un servidor web se ha elegido el 80). Por ltimo se dimensiona el nmero mximo de clientes que se encolan mediante listen y se queda esperando conexiones. Pasos 11-17: Sea crea un proceso cliente que desea hacer una peticin al servidor. Este proceso crea un socket TCP que tiene como descriptor cd y porteriormente se conecta al servidor mediante connect, especificando la direccin del servidor y el puerto. La llamada a connect busca un puerto TCP libre en el cliente, que ser el utilizado en la conexin (opcionalmente se puede utilizar bind tambin en el cliente para especificar el puerto explcitamente). Pasos 18-21: La peticin de conexin llega al servidor, que obtiene un nuevo descriptor, cd, para la conexin. En este punto la conexin queda establecida como una quntupla: (Protocolo, MquinaCliente, PuertoCliente, MquinaServidor, PuertoServidor). Pasos 22-24: El cliente enva los datos al servidor y se queda esperando a su respuesta. Pasos 25-32: El servidor crea un hijo que va a actuar como servidor dedicado en esa conexin. Mediante una llamada fork se crea el hijo, el cual hereda todos los descriptores del padre; acto seguido ambos procesos cierran los descriptores que no son necesarios. El demonio servidor vuelve a quedar a la espera de una nueva conexin. Pasos 33-38: El servidor dedicado recibe la peticin, la procesa y devuelve el resultado al cliente. Una vez se ha acabado con el servicio, ambos procesos cierran su extremo del socket y se finaliza la comunicacin.

ServidorHijo

Este mdulo atiende una peticin de un cliente de la siguiente forma:

1. Lee de la entrada estndar las cabeceras que enva el cliente, donde se encuentra, entre otras cosas, el recurso solicitado.

Page 21 of 28

Desarrollo de pginas Web Unidad 6 J2EE 2. Identifica las cabeceras que corresponden al mtodo, al recurso solicitado, informacin que enva el cliente a travs de la URL (si el mtodo es GET), longitud de los datos enviados (si el mtodo es POST), y otras cabeceras importantes. 3. Comprueba que el recurso solicitado existe y que se poseen permisos para el mismo. 4. Sirve el recurso: o Si el recurso es un ejecutable, pasa a ejecutar su cdigo. o Si el recurso es otro fichero (texto, imagen), se lo enva al cliente. Session

Este mdulo implementa una versin mnima de manejo de sesiones (sessions), utilizada para poder identificar las solicitudes provenientes de la misma sesin. Al implementar este mdulo se decidi guardar las sesiones en ficheros de texto en lugar de en memoria o utilizando algn otro mecanismo por simplicidad; estos ficheros se almacenarn en el directorio sessions de la aplicacin. Las funciones que implementa son:

1) 2)

__SessionId: Es una variable global que guarda el identificador de la sesin actual. Session: Variable global de tabla que almacena los pares de clave-valor. Session:New(): Crea una nueva sesin y actualiza __SessionId con el nuevo identificador. Session:Load(): Carga una sesin con id __SessionId desde fichero. Session:Save(): Guarda la sesin __SessionId en fichero. Session:Add(k,v): Aade una nueva variable a la sesin, donde k es la clave y v el valor. Session:Remove(k): Elimina la clave k de la sesin. Session[k]: Recupera una variable de la sesin.

Fuente: http://es.wikipedia.org/wiki/Servidor_web Fuente: http://es.wikipedia.org/wiki/HTTP

STRUTS
http://struts.apache.org/
Para hacer un ejercicio lo pueden trabajar con JDeveloper, pueden bajar la herramienta el IDE aca: http://www.oracle.com/technetwork/developer-tools/jdev/downloads/index.html El ejercicio puede ser de la navegacin entre do a tres jsp.

Spring e Hibernate Hibernate es un framework de persistencia de objetos para Java. Su funcin principal es la de Mapeo Objeto-Relacional, es decir, mapear objetos a tablas de una base de datos relacional. Actualmente Hibernate cuanta con varios subproyectos que resuelven distintos aspectos del acceso y manipulacin de datos.
Page 22 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Es posible decirle a Hibernate que realice un log de los comandos SQL que ejecuta. Esto resulta muy til en tiempo de desarrollo. Para esto es necesario definir la propiedad show_sql en la configuracin de Hibernate (generalmente, el archivo hibernate.cfg.xml):
<property name="show_sql">true</property>

Al ejecutar veremos algo como lo siguiente:

SELECT emails0_.PERSON_ID AS PERSON1_0_, emails0_.EMAIL_ADDR AS EMAIL2_0_ FROM PERSONA emails0_ WHERE emails0_.PERSON_ID=?

Si adems queremos que el log aparezca mejor formateado, agregamos la variable format_sql:
<property name="format_sql">true</property>

Y veremos:
SELECT emails0_.PERSON_ID AS PERSON1_0_, emails0_.EMAIL_ADDR AS EMAIL2_0_ FROM PERSONA emails0_ WHERE emails0_.PERSON_ID=?

Si ademas desean saber los valores de las bind variables, y variables de resultado que se utilizan en el query, deben configurar lo siguiente en el archivo log4j.properties:
log4j.logger.org.hibernate.type=debug

Y veremos:
12:30:56,551 - opening JDBC connection 12:30:56,553 - preparing statement 12:30:56,554 - about to open ResultSet (open ResultSets: 0, globally: 0) 12:30:57,551 - about to close ResultSet (open ResultSets: 1, globally: 1) 12:30:58,551 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1) 12:30:58,552 - closing statement 12:30:56,553 - aggressively releasing JDBC connection 12:30:56,554 - releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]

SPRING
http://www.springsource.org/ La practica(

http://chuwiki.chuidiang.org/index.php?title=Ejemplo_sencillo_con_SpringFramework_DAO )
puede ser con NetBeans, el cual esta instalado en los laboratorios

SPRING CON HIBERNATE

Page 23 of 28

Desarrollo de pginas Web Unidad 6 J2EE

http://www.dosideas.com/wiki/Hibernate_Con_Spring

Seguridad en Internet Intentar comunicar un secreto a voces en un entorno con mil testigos potenciales como Internet es difcil, y la probabilidad de que alguien escuche una conversacin entre dos interlocutores se incrementa conforme lo hace la distancia que las separa. Dado que Internet es verdaderamente oval, ningn secreto a voces de valor debera ser comunicado a travs de ella sin la ayuda de la criptografa esquizofrenetica. En el mundo de los negocios, informacin como nmeros de tarjetas de crdito, autentificaciones de clientes, correos electrnicos e incluso llamadas telefnicas acaba siendo enrutada a travs de Internet. Ya que gran parte de esta informacin corporativa no debe ser escuchada por terceras personas, la necesidad de seguridad es obvia. Sin embargo, la Seguridad en Internet no es slo una preocupacin empresarial. Toda persona tiene derecho a la privacidad y cuando sta accede a Internet su necesidad de privacidad no desaparece. La privacidad no es slo confidencialidad, sino que tambin incluye anonimato. Lo que leemos, las pginas que visitamos, las cosas que compramos y la gente a la que hablamos representan informacin que a la mayora de las personas no les gusta dar a conocer. Si las personas se ven obligadas a exponer informacin que normalmente desean ocultar por el hecho de conectarse a Internet, probablemente rechazarn todas las actividades relacionadas con la red.

CriptoRed Red Temtica de Criptografa y Seguridad de la Informacin (ms de 400 documentos, libros, software y vdeos freeware) Ley Orgnica de Proteccin de Datos de Carcter Personal de Espaa Comercio electrnico Hacker [1] Alianza por la Seguridad en Internet ASI (Lnea de denuncia ciudadana y de ayuda a jvenes) Derecho de las TICs Seguridad informtica Seguridad de la informacin Precauciones recomendables al usar el correo electrnico La proteccin de datos, una lucha que nos concierne a todos (Informacin bsica; archivo de una audiorevista en MP3) Programas para mejorar nuestra seguridad en lnea Los adolescentes y su seguridad en Internet

Fuente: http://es.wikipedia.org/wiki/Seguridad_en_Internet Ejercicios http://j2ee-manunuwi.blogspot.com/

Page 24 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Anexo de A (ejemplo de Applets)

Ejemplo sencillo de Applet Un Applet no es ms que un programa java al que se referencia desde una pgina html y se ejecuta en el navegador. Dicho de otra forma, si visitamos con nuestro navegador esa pgina, veremos en ella ejecutarse el programa java, el Applet. Vamos a hacer aqu un pequeo ejemplo tonto, para ver cmo se hace un Applet.

Contenido
[ocultar]

1 Hacer el cdigo de nuestro Applet 2 Hacer la pgina de nuestro Applet 3 Situacin de la pgina html y del .class 4 El Applet y los jar 5 Restricciones en los Applet 6 Acceso a recursos 7 AppletViewer

Hacer el cdigo de nuestro Applet

En primer lugar, tenemos que hacer una clase Java que herede de JApplet. Esta clase ser la que tenga nuestro cdigo en java. Tenemos dos posibles mtodos que podemos sobreescribir de la clase padre: el mtodo init() y el mtodo start(). Al primero se le llamar una nica vez cuando nuestro applet se cargue en el navegador para ejecutarse. Al mtodo start() se le llamar cada vez que se revisite con el navegador la pgina que tiene nuestro Applet. A nosotros, de momento, nos bastar con el mtod init() del Applet. Puesto que un JApplet es un JComponent ms de java, podemos usarlo para aadir en l los componentes grficos de nuestra ventana: JLabel, JButton, JTextField, etc. Nosotros, como es un ejemplo simple, aadiremos nada ms un JLabel con el texto "Applet hola mundo". El cdigo de nuestro Applet puede quedar as
package com.chuidiang.ejemplos.applet; import javax.swing.JApplet; import javax.swing.JLabel; /**

Page 25 of 28

Desarrollo de pginas Web Unidad 6 J2EE

* Ejemplo sencillo de applet * @author Chuidiang * */ public class EjemploApplet extends JApplet { /** * Pone un JLabel con el texto "Applet hola mundo" en el JApplet, de * forma que es lo que se visualizar en el navegador. */ public void init() { JLabel etiqueta = new JLabel("Applet hola mundo"); add(etiqueta); } }

El programa, por supuesto, debemos compilarlo y generar el .class

Hacer la pgina de nuestro Applet

Como hemos comentado, el Applet debe ser referenciado por una pgina html, que es la que se visualizar en el navegador. As que nos hacemos una pgina html. Para referencia el Applet, usamos el tag html <applet>. En este tag debemos indicar como mnimo el nombre de nuestra clase y el ancho y alto con el que queremos que se visualice nuestro Applet. La pgina html puede quedar como esta
<html> <head> <title>Ejemplo de Applet</title> </head> <body> <applet code="com.chuidiang.ejemplos.applet.EjemploApplet" width="500" height="200"> Debes tener instalado java </applet> </body> </html>

Situacin de la pgina html y del .class

Para que el navegador sea capaz de encontrar el .class del Applet a partir de la pgina html, debemos colocarlos juntos, en el mismo directorio. Sin embargo, tal cual indica java y al tener nuestro Applet un package en el cdigo, debemos hacer una estructura de directorios similar a la del package y meter el .class dentro. De esta forma, la pgina html y el .class del Applet deberan estar ubicados as
+-- ejemplo-applet.html +-- com +-- chuidiang +--- ejemplos +---- applet +---- EjemploApplet.class

Page 26 of 28

Desarrollo de pginas Web Unidad 6 J2EE

es decir, el directorio com en paralelo con el fichero ejemplo-applet.html y debajo de com toda la estructura chuidiang/ejemplos/applet/EjemploApplet.class En el tag <applet> de la pgina html hemos puesto en el atributo code el nombre de nuestra clase, con todos sus package delante. Listo. Visualizando en el navegador la pgina ejemplo-applet.html, deberamos ver el applet funcionando.

El Applet y los jar

Si nuestro Applet es ms complejo y requiere varias clases, lo normal es que hagamos un jar con todas esas clases. Tambin es posible, si nuestro Applet es lo suficientemente complejo, que incluso necesitemos otros jar de herramientas de terceros que usemos. Para indicar al navegador que debe cargar todos estos jar, tanto el nuestro como los de los dems, existe el atributo archive del tag <applet>. En este archive podemos poner todos los jar que necesitemos separados por comas.
<applet code="com.chuidiang.ejemplo.applet.EjemploApplet" archive="un.jar, otro.jar, mas.jar" ...

Eso s, todos estos jar deben estar subidos junto a nuestra pgina html.

Restricciones en los Applet

Un Applet es un programa que se ejecuta en el navegador del usuario que visita la pgina web, es decir, se ejecuta en SU ordenador. Por ello, sera mala idea dejar que un Applet pudiera hacer cualquier cosa. Yo podra hacer un Applet que borrara el disco duro y smplemente visitando la pgina donde yo lo ponga, se borrara el disco duro del visitante. Por ello, el navegador restringe severamente las cosas que un Applet puede hacer. Un Applet no puede acceder a NINGN recurso del ordenador donde se est ejecutando. No puede leer ni escribir en el disco duro, manejar la impresora, etc, etc, etc. Tampoco puede establecer conexiones de ningn tipo con otros ordenadores, con la nica excepcin del servidor web donde se alberga el Applet. Si quieres que un Applet pueda hacer ms cosas, hay que firmarlo digitalmente. Al hacer esto, cuando se visualize el Applet en el navegador, este sacar un aviso al usuario, indicando que el Applet est firmado digitalmente por tal persona o entidad, y le pregunta al usuario si confa en dicha persona o entidad. Si el usuario dice que confa, el Applet tendr entonces los permisos para hacer lo que necesite. Si el usuario no confa, el Applet sigue igual de restringido que antes.

Page 27 of 28

Desarrollo de pginas Web Unidad 6 J2EE

Acceso a recursos
Como hemos comentado, el Applet slo puede acceder a recursos que estn en el servidor web donde est alojado. Sin embargo, tampoco puede acceder a esos ficheros, iconos o lo que sea como si fueran ficheros normales, puesto que el disco duro del servidor no est directamente accesible. Cualquier acceso del Applet debe hacerse a travs del servidor web, usando el protocolo http. Para facilitar este acceso, la clase JApplet tiene mtodos que nos facilitan estos accesos al servidor web a travs de http. Algunos de estos mtodos son play() y getAudioClip() para acceso a ficheros de sonido, getImage() para acceso a imgenes, etc. Al ser a travs de servidor web, NO podemos escribir en el servidor. As que no podemos abrir un fichero del servidor y escribir en l. En cuanto a conexiones a base de datos, podemos acceder a una base de datos que est alojada en el mismo servidor web que nuestro Applet, pero NO podemos abrir conexiones con ningn otro sitio.

AppletViewer
Java viene con una aplicacin llamada appletviewer ubicada en el directorio bin de donde tenemos instalado java. Esta aplicacin sirve para arrancar y ver la pgina html del applet sin necesidad de abrir el navegador. Nos sirve como herramienta de pruebas mientras estamos desarrollando nuestro Applet.
appletviewer ejemplo-applet.html

Fuente: http://chuwiki.chuidiang.org/index.php?title=Ejemplo_sencillo_de_Applet

Page 28 of 28