ESTRUCTURA DE DIRETORIOS DE UNA APLICACIN

WEB JAVA
Tradicionalmente, cuando hablamos de aplicacin web en entorno java, podemos decir que es una
coleccin de servlets, pginas dinmicas con JSP o estticas con HTML, XHTML, clases Java, archivos
de descripcin de la aplicacin, imgenes, etc. o ms modernamente utilizando framworks y otros
recursos que pueden ser empaquetados y ejecutados en distintos servidores de diferentes proveedores
(ISPs) o bien en nuestros servidores propios. Es decir, una aplicacin web se podra definir como la capa
web de cualquier aplicacin.
Una de las caractersticas principales de una aplicacin web java es que tiene necesitan un contenedor de
servlets (tambin llamado a veces servidores web) como seran Tomcat, Jetty, JBoss, Resin y su relacin
con el ServletContext. Esta relacin est controlada por el contenedor de servlets, que asocia un nico
ServletContext para cada aplicacin, garantizando que las aplicaciones no van a colisionar a la hora de
almacenar objetos en el ServletContext.
El contenedor que alberga una aplicacin web no es ms que la estructura de directorios donde estn
colocados todos los archivos necesarios para la ejecucin de la aplicacin web. Por tanto, en el desarrollo
de cualquier aplicacin web java tenemos que tener creada la estructura de directorios donde colocaremos
los componentes. A continuacin, se indican los directorios necesarios para una aplicacin llamada
ejemploWeb, que debe colgar del directorio raz del contenedor de servlets, que puede diferir de unos
servidores web a otros.
En el caso de Tomcat, el directorio a partir del cual se instala cualquier aplicacin web debe ser /webapps,
dentro del directorio de instalacin de Tomcat. Los directorios de la aplicacin ejemploWeb sern los
siguientes (a partir de la especificacin de Servlet 2.2, deben estructurarse segn la siguiente jerarqua de
subdirectorios:):
/ejemploWeb
Directorio raz de la aplicacin web, en el cual se colocan todos los archivos (JSP, HTML, imgenes,
hojas de estilo, etc.) que utiliza la aplicacin. Se pueden crear subdirectorios adicionales para mantener
cualquier otro recurso de tipo esttico que forme parte de la aplicacin web y constituyan la parte de
acceso pblico desde cualquier navegador.
/ejemploWeb/WEB-INF
Directorio que contiene todos los recursos relacionados con la aplicacin web que no se han colocado en
el directorio raz y que no deben servirse al cliente. Esto es importante, ya que este directorio no forma
parte del documento pblico, por lo que ninguno de los ficheros que contenga va a poder ser enviado
directamente a travs del servidor web. En este directorio se coloca el archivo web.xml, donde se
establece la configuracin de la aplicacin web.
/ejemploWeb/WEB-INF/classes
Directorio que contiene todos los servlets y cualquier otra clase de utilidad o complementaria que se
necesite para la ejecucin de la aplicacin web. Normalmente contiene solamente archivos .class.
/ejemploWeb/WEB-INF/lib
Directorio que contiene los archivos Java de los que depende la aplicacin web. Por ejemplo, si la
aplicacin web necesita acceso a base de datos a travs de JDBC, en este directorio es donde
deben colocarse los ficheros JAR que contengan el driver JDBC que proporcione el acceso a la base de
datos. Normalmente contiene solamente archivos .jar.
/ejemploWeb/WEB-INF/tlds

Directorio que contiene los archivos TLD, descriptor de la librera de etiquetas, en el caso de que la
aplicacin web utilice cualquier librera de etiquetas, o acciones personalizadas, en este caso contiene el
archivo ejemploWeb.tld. En esta estructura, el cargador de clases consulta en primer lugar el directorio
/ejemploWeb/WEB-INF/classes y posteriormente el directorio /ejemplo Web/WEB-INF/lib, de forma que
en el desarrollo se pueden colocar clases de usuario en el directorio classes y las clases ya probadas o
clases de terceros en el directorio lib; de este modo el cargador de clases resolver en primer lugar las
clases con las que se encuentran en desarrollo, y si no es capaz de encontrarlas en el directorio classes las
buscar en los archivos del directorio lib.
Una segunda parte muy importante de toda aplicacin web es su descriptor de configuracin. Este
descriptor no es ms que un archivo XML de nombre web.xml, localizado en el directorio WEB-INF, que
contiene la descripcin de la configuracin correspondiente a la aplicacin web. En el caso anterior el
archivo web.xml estar situado en el directorio /ejemploWeb/WEB-INF. La informacin que contiene este
descriptor puede incluir los siguientes elementos:

Parmetros de inicializacin del ServletContext

Configuracin de la sesin
Definiciones de Servlets/JSP
Mapeado de Servlets/JSP
Mapeado de tipos MIME
Configuracin de seguridad
Pginas de error
Pginas de bienvenida

Finalmente, la tercera parte importante de una aplicacin web es el archivo WAR (Web ARchive), que es
el mtodo estndar empleado para empaquetar una aplicacin web y dejarla lista para su distribucin y
acceso a travs de servidores web con soporte para servlets y pginas JSP. Utilizando el archivo WAR se
puede distribuir una aplicacin web completa, compuesta por cualquier nmero de recursos, en una nica
unidad de distribucin, en un nico archivo.
El archivo WAR se genera con la herramienta jar, desde el directorio inmediatamente anterior al
directorio que contiene la aplicacin web. En realidad, un archivo WAR es un archivo comprimido que
utiliza tecnologa zip que permite agrupar mltiples ficheros y directorios en un nico fichero,
manteniendo su estructura original y comprimiendo su contenido; por lo que cualquier herramienta que
permita comprimir en este formado puede ser utilizada, renombrando el archivo de salida de dicha
herramienta a un archivo con extensin WAR.
El archivo WAR es el que se proporciona al proveedor de Internet, que debe colocarlo en el directorio
adecuado del servidor web que utilice, dejando la aplicacin accesible al pblico a travs de cualquier
navegador.
Durante el desarrollo de una aplicacin web, si se estn construyendo constantemente archivos WAR, se
debe considerar la utilizacin de alguna herramienta que automatice este proceso, por ejemplo, ANT,
MAVEN, GRADLE.
El archivo WAR siempre incluye dos directorios especiales: META-INF y WEB-INF. Si el lector es
recin llegado al mundo de las pginas JSP seguramente se sorprender ante la presencia del primer
directorio; en l se almacena el archivo manifest e informacin til para las herramientas Java y no es de
especial inters para el desarrollador, el contenido del segundo espero que haya quedado ms claro.

LENGUAJE DE PROGRAMACION JSP

JSP

JSP: Es un lenguaje para la creacin de sitios web dinmicos, acrnimo de Java Server Pages. Est
orientado a desarrollar pginas web en Java. JSP es un lenguaje multiplataforma. Creado para ejecutarse
del lado del servidor. JSP fue desarrollado por Sun Microsystems. Comparte ventajas similares a las de
ASP.NET desarrollado para la creacin de aplicaciones web potentes.
La tecnologa de JSP permite a los desarrolladores y a los diseadores de web desarrollar rpidamente y
mantener fcilmente pginas dinmicas, ricas en informacin como son las que soportan a sistemas de
negociacin. La tecnologa de los JSP separa la interfaz del usuario de la parte lgica del contenido
permitiendo a los diseadores cambiar a su disposicin las plantillas de la interfaz sin alterar el contenido
dinmico subyacente.
JSP tambin permite introducir cdigo para la generacin dinmica de HTML dentro de una pgina web.
Esta surge por la necesidad de crear aplicaciones dinmicas para web de forma fcil, ya que la mejor
parte del resultado de un programa CGI es esttico. Se podra pensar entonces en JavaScript, pero este
genera HTML dinmicamente en el cliente y no puede accesar a los cursos del servidor.

CARACTERSTICAS

Conjunta el poder de Java en el servidor y la flexibilidad de HTML en el browser.

No slo se puede utilizar HTML, sino tambin XML o WML.
Hace ms fcil reusar componentes con JavaBeans los cuales realizan tareas ms
especficas.
Su funcin es saber cmo procesar una solicitud para crear una respuesta.
Soporta contenido dinmico que refleja las condiciones del mundo real.
Es ms rpido y fcil crear aplicaciones de web
Capaz de instanciar cualquier clase de Java

Cmo se accesa a Java Server Pages?

Para la realizar una peticin de una pgina JSP se sigue una forma similar al de una pgina
HTML esttica, aunque el dems proceso, el cual es transparente para el usuario es diferente.
Para una pgina no dinmica se teclea un URL en el browser y ste usando un protocolo HTTP
mandar una peticin del archivo con extensin HTML a un servidor web y dominio
determinado. Posteriormente el servidor extraer el archivo y lo mandar al browser, el cual
hace uso de las etiquetas de HTML del archivo para ser presentado al usuario final.

VENTAJAS

Contra los Servlets, JSP no nos da nada que no pudiramos hacer con un servlet, pero no es
mucho ms conveniente escribir y modificar HTML normal que tener un gran nmero de
sentencias "print" que generen HTML. Adems, es posible agregar cdigo Java una pgina que
fue anteriormente diseada con puro HTML.
Contra JavaScript puede generar HTML dinmicamente en el cliente; esta es una capacidad til,
pero slo maneja situaciones donde la informacin dinmica est basada en el entorno del
cliente. Con la excepcin de las cookies, el HTTP y el envo de formularios no estn disponibles
con JavaScript. Debido a que se ejecuta en el cliente, JavaScript no puede acceder a los
recursos en el lado del servidor, como bases de datos y catlogos.
Sin embargo, es posible aprovechar las ventajas de JSP y JavaScript si se utilizan
conjuntamente. Una de las principales ventajas de JavaScript es el manejo de entornos visuales;
y la mayor ventaja de JSP sobre JavaScript es la capacidad de comunicacin dentro de un
servidor; por lo cual se pueden mezclar para validar formularios que han de ser enviados al
servidor. Con esto, se logra una rpida y fcil validacin de los datos que el usuario del sistema
introduce.

LLAMADOS GET Y POST

El concepto GET es obtener informacin del servidor. Traer datos que estn en el servidor, ya sea en un
archivo o base de datos, al cliente. Independientemente de que para eso tengamos que enviar (request)
algn dato que ser procesado para luego devolver la respuesta (response) que esperamos, como por
ejemplo un identificador para obtener una noticia de la base de datos.
POST sin embargo es enviar informacin desde el cliente para que sea procesada y actualice o agregue
informacin en el servidor, como sera la carga o actualizacin en s de una noticia. Cuando enviamos
(Request) datos a travs de un formulario, estos son procesados y luego a travs de una redireccin por
ejemplo devolvemos (response) alguna pgina con informacin.
Ambos mtodos solicitan una respuesta del servidor y ah es donde parecen que los conceptos son iguales
ya que con ambos se podra lograr los mismos objetivos. Yo podra, aunque estara mal, enviar por GET
ciertos datos en la URL y actualizar o insertar informacin en mi base de datos, pero eso le
correspondera al mtodo POST. De la misma manera podra solicitar una pgina diferente por medio de
POST y simplemente mostrarla como respuesta, aunque eso debera ser a travs de una llamada GET.
Las llamadas GET pueden ser cacheadas (historial del navegador), indexadas por buscadores, agregar los
enlaces a nuestros favoritos o hasta pasar una url completa a otra persona para que directamente ingrese a
esa pgina. Con el mtodo POST sin embargo no se puede hacer esto.

ES MEJOR USAR EL MTODO GET O EL MTODO POST?

Tanto GET como POST son mtodos de envo de la informacin de los formularios vlidos y
ampliamente utilizados. Cada mtodo tiene sus ventajas y sus inconvenientes y no se puede decir que uno
sea mejor que otro.
Elegir entre un mtodo y otro depende de la aplicacin concreta que se est desarrollando y es algo que
dentro de las empresas de desarrollos web suelen decidir los encargados del diseo de las aplicaciones. A
nosotros en este curso bsico simplemente nos interesa conocer la existencia de ambos mtodos y sus
caractersticas.

Para terminar, en la siguiente tabla mostramos un resumen de las diferencias entre GET y POST :

MTODO

CONCEPTO

OBSERVACIONES

GET

GET lleva los datos de

forma "visible" al
cliente
(navegador
web). El medio de
envo es la URL. Los
datos los puede ver
cualquiera.

Los datos son visibles por la URL, por ejemplo:

www.aprenderaprogramar.com/
action.php?nombre=pedro&apellidos1= gomez

POST

POST consiste en
datos
"ocultos"
(porque el cliente no
los ve) enviados por un
formulario
cuyo
mtodo de envo es
post. Es adecuado para
formularios. Los datos
no son visibles.

La ventaja de usar POST es que estos datos no son

visibles al usuario de la web. En el caso de usar get,
el propio usuario podra modificar la URL
escribiendo diferentes parmetros a los reales en su
navegador, dando lugar a que la informacin tratada
no sea la prevista.