Construcció d'Aplicacions de Programari Lliure en J2EE/HTTP, HTML, Servlets i Java Server Pages
Servlets
[modifica]Què entenem per servlets?
[modifica]Un Servlet és una classe de java que s'executa al servidor (d'aquí ve el nom de servlet, en contraposició amb el de applet, que s'executa al client), i que típicament es crida des d'una aplicació web per obtindre un resultat. Es fan servir com a capa intermèdia entre la petició del client HTTP i la base de dades o aplicació resident al servidor HTTP.
Aquí podeu trobar la pàgina oficial de Java, en anglès, on trobar més informació.
La API dels servlets, que utilitzarem per escriure'ls, no té en compte com es carrega, ni l'entorn on aquest està funcionant, ni el protocol per transmetre les dades que s'està utilitzant. És independent de tot això i és el que permet fer-lo funcionar en qualsevol servidor web.
Servlets o CGI's
[modifica]Una de les primeres tecnologies que va sorgir per permetre la comunicació entre un programa client i un servidor van ser els CGI's, ó scripts CGI, anomenats així perquè normalment estan escrits en llenguatges interpretats com ara Perl. Les diferències entre ambdues tecnologies són les següents:
- Un Servlet no s'executa com un procés separat. Amb això ens estalviem el haver de crear un nou procés en cada petició.
- El Servlet es queda en memòria durant tota la petició. En canvi un CGI s'ha de cridar cada vegada que el necessitem.
- Una sola instància del Servlet s'encarrega de respondre a totes les peticions concurrentment, el que permet estalviar memòria i gestionar fàcilment dades persistents.
- Els Servlets estàn escrits en java i tenen una API ben estandarditzada, com a conseqüència d'això, són portables a qualsevol servidor web.
Arquitectura i Funcionament
[modifica]El comportament d'un Servlet és el que podem veure a l'esquema de la Figura 1 (cliqueu a sobre per ampliar-la).
Com podem veure, la pàgina HTML fa una petició al servidor. El Servlet és l'encarregat de gestionar aquesta petició (el Servlet es troba entre la capa de presentació i la capa de negoci de l'aplicació). El Servlet contesta la petició a la pàgina HTML amb la informació recuperada, en aquest cas, de la base de dades. Aquesta es la forma habitual de treballar d'un Servlet, que no deixa de ser una classe normal de Java però orientat a la comunicació amb peticions del protocol HTTP.
Per aconseguir aquesta comunicació amb el protocol HTTP, necessitarem uns paquets especifics que haurem d'importar quan construim el nostre Servlet. Aquestos paquets són javax.servlet i javax.servlet.http. Aquests paquets proporcionen les interficies i classes necessàries per a escriure un Servlet. Tots els Servlets han d'implementar la interfície Servlet, que defineix els mètodes del cicle de vida de tot Servlet.
Aquest cicle de vida consta de les següents estapes:
- Crida al Servlet, des del client.
- Càrrega, es carrega el Servlet.
- Creació de la instància, es crea una instància del Servlet a memòria
- Inicialització, s'inicialitza el Servlet mitjançant el mètode init()
- Crida al servei, si s'escau, es fan les crides als serveis definits
- Destrucció, es destrueix el Servlet un cop que ja no es requerit, amb el mètode destroy()
Exemple de Servlet
[modifica]Ara que ja sabem com funciona un Servlet, en construirem un de bàsic i després mirarem la part del client. Per tant, dividirem aquest apartat en dues subseccions més.
A la primera veurem el codi de la part del servidor, i a la segona montarem la part del client, un html amb formulari. La part de desplegament del nostre Servlet al contenidor de servlets (tomcat, per exemple) ja l'hem vist en un altre capítol anterior d'aquest curs.
Part del servidor
[modifica]El primer que necessitarem és importar els paquets per rebre i enviar dades amb el protocol HTTP.
import javax.servlet.*; import javax.servlet.http.*;
Aquestes classes no es troben a per defecte a les llibreries de java, i haurem d'indicar-li al nostre CLASSPATH on les podem trobar. A dins del paquet servlet.jar és on hem de buscar. Aquest paquet es troba al common/lib del nostre contenidor de servlets Tomcat. Potser el trobarem amb el nom de servlet-api.jar. Podem optar per renombar-lo o bé, de forma més elegant, crear un enllaç simbòlic amb el nom que volem cap a aquest jar.
ln -s servlet-api.jar servlet.jar
Com hem dit abans, el nostre Servlet ha d'implementar la interfície Servlet,així doncs, l'extendrem de la següent forma:
public class Hola extends HttpServlet {
Seguidament, escriurem els mètodes per inicialitzar i destruir el contexte del nostre Servlet.
public void init(ServletConfig config) throws ServletException
{
super.init(config);
}
public void destroy()
{
}
El mètode init() de la nostra classe crida al de la classe superior HttpServlet de la qual s'estén. El Servlet es comunica amb la plana HTML ó amb el JSP mitjançant HttpServletRequest (d'entrada) i HttpServletResponse (de sortida). Depenent del tipus de petició (Get o Post), el servidor redirecciona la petició al Servlet als mètodes doGet i doPost que veurem tot seguit, juntament amb tot el codi anterior. Aquests dos mètodes s'haurien de sobreescriure de la super classe HttpServlet.
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class Hola extends HttpServlet {
public void init(ServletConfig config) throws ServletException
{
super.init(config);
}
public void destroy()
{
}
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
processarPeticio(request,response);
}
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
processarPeticio(request,response);
}
protected void processarPeticio(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType("text/html");
PrintWriter out=response.getWriter(); //ens escriura a la sortida estandard, en aquest cas al navegador
out.println("<html><body>Hola "+ request.getParameter("nom")+"</body></html>");//recullirem un parametre
out.close();
}
}
En capítols anteriors d'aquest curs ja s'ha explicat la forma de desplegar els nostres servlets al contenidor de servlets, i com configurar-lo.
Part del client
[modifica]Ara escriurem un senzill formulari que enviarà un paràmetre al nostre Servlet i aquest ens retornarà una pàgina HTML amb aquest paràmetre.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Exemple Formulari amb POST</TITLE>
</HEAD>
<BODY>
<FORM ACTION="/servlet/Hola" METHOD="POST">
Com et dius?
<INPUT TYPE="TEXT" NAME="nom"><BR>
<CENTER>
<INPUT TYPE="SUBMIT" VALUE="Enviar">
</CENTER>
</FORM>
</BODY>
</HTML>
Desplegament al Tomcat
[modifica]Ara que ja tenim les dues parts, anem a ficar-les al contenidor de servlets i provar d'executar l'exemple. El nostre Servlet compilat el ficarem a webapps/prova-servlet/WEB-INF/classes. El nostre formulari de la part client el ficarem a webapps/prova-servlet/, i per tal que puguem accedir a la classe des d'aquest formulari, necessitarem indicar-li amb un fitxer de configuració anomenat web.xml, que situarem a dins del directori WEB-INF :
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>
Hola</display-name>
<servlet>
<description>
</description>
<display-name>
Hola</display-name>
<servlet-name>Hola</servlet-name>
<servlet-class>
Hola</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Hola</servlet-name>
<url-pattern>/Hola</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
</web-app>
Per automatitzar la part del desplegament i compilació del nostre projecte, aprofitarem els avantatges de l'eina ant que em vist anteriorment. Construirem el següent fitxer build.xml, molt ben documentat, i el deixarem a l'arrel del nostre projecte.
<!-- A "project" describes a set of targets that may be requested
when Ant is executed. The "default" attribute defines the
target which is executed if no specific target is requested,
and the "basedir" attribute defines the current working directory
from which Ant executes the requested task. This is normally
set to the current working directory.
-->
<project name="My Project" default="compile" basedir=".">
<!-- ===================== Property Definitions =========================== -->
<!--
Each of the following properties are used in the build script.
Values for these properties are set by the first place they are
defined, from the following list:
* Definitions on the "ant" command line (ant -Dcatalina.home=xyz compile)
* Definitions from a "build.properties" file in the top level
source directory
* Definitions from a "build.properties" file in the developer's
home directory
* Default definitions in this build.xml file
You will note below that property values can be composed based on the
contents of previously defined properties. This is a powerful technique
that helps you minimize the number of changes required when your development
environment is modified. Note that property composition is allowed within
"build.properties" files as well as in the "build.xml" script.
-->
<!-- ==================== File and Directory Names ======================== -->
<!--
These properties generally define file and directory names (or paths) that
affect where the build process stores its outputs.
app.name Base name of this application, used to
construct filenames and directories.
Defaults to "myapp".
app.version Version identifier for this application.
build.home The directory into which the "prepare" and
"compile" targets will generate their output.
Defaults to "build".
catalina.home The directory in which you have installed
a binary distribution of Tomcat 4. This will
be used by the "deploy" target.
deploy.home The name of the directory into which the
deployment hierarchy will be created, and into
which the build directory will be copied.
Defaults to "${catalina.home}/webapps/${app.name}".
dist.home The name of the base directory in which
distribution files are created.
Defaults to "dist".
-->
<!-- nrs: These are the only two properties you need to modify -->
<property name="app.name" value="demo-servlet"/>
<property name="app.version" value="1.0"/>
<property name="catalina.home" value="/usr/local/apache-tomcat-5.5.17"/>
<property name="build.home" value="build"/>
<property name="deploy.home" value="${catalina.base}/webapps/${app.name}"/>
<property name="dist.home" value="dist"/>
<!-- ==================== Compilation Control Options ==================== -->
<!--
These properties control option settings on the Javac compiler when it
is invoked using the <javac> task.
compile.debug Should compilation include the debug option?
compile.deprecation Should compilation include the deprecation option?
compile.optimize Should compilation include the optimize option?
-->
<property name="compile.debug" value="true"/>
<property name="compile.deprecation" value="false"/>
<property name="compile.optimize" value="true"/>
<!-- ==================== External Dependencies =========================== -->
<!--
Use property values to define the locations of external JAR files on which
your application will depend. In general, these values will be used for
two purposes:
* Inclusion on the classpath that is passed to the Javac compiler
* Being copied into the "/WEB-INF/lib" directory during execution
of the "deploy" target.
Because we will automatically include all of the Java classes that Tomcat 4
exposes to web applications, we will not need to explicitly list any of those
dependencies. You only need to worry about external dependencies for JAR
files that you are going to include inside your "/WEB-INF/lib" directory.
-->
<!-- Dummy external dependency -->
<!--
<property name="foo.jar"
value="/path/to/foo.jar"/>
-->
<!-- ==================== Compilation Classpath =========================== -->
<!--
Rather than relying on the CLASSPATH environment variable, Ant includes
features that makes it easy to dynamically construct the classpath you
need for each compilation. The example below constructs the compile
classpath to include the servlet.jar file, as well as the other components
that Tomcat makes available to web applications automatically, plus anything
that you explicitly added.
-->
<path id="compile.classpath">
<!-- Include all JAR files that will be included in /WEB-INF/lib -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
<!--
<pathelement location="${foo.jar}"/>
-->
<!-- Include all elements that Tomcat exposes to applications -->
<pathelement location="${catalina.home}/common/classes"/>
<fileset dir="${catalina.home}/common/lib">
<include name="*.jar"/>
</fileset>
<pathelement location="${catalina.home}/classes"/>
<!-- <fileset dir="${catalina.home}/lib">
<include name="*.jar"/>
</fileset>
-->
</path>
<!-- ==================== All Target ====================================== -->
<!--
The "all" target is a shortcut for running the "clean" target followed
by the "compile" target, to force a complete recompile.
-->
<target name="all" depends="clean,compile"
description="Clean build and dist, then compile"/>
<!-- ==================== Clean Target ==================================== -->
<!--
The "clean" target deletes any previous "build" and "dist" directory,
so that you can be ensured the application can be built from scratch.
-->
<target name="clean"
description="Delete old build and dist directories">
<delete dir="${build.home}"/>
<delete dir="${dist.home}"/>
</target>
<!-- ==================== Compile Target ================================== -->
<!--
The "compile" target transforms source files (from your "src" directory)
into object files in the appropriate location in the build directory.
This example assumes that you will be including your classes in an
unpacked directory hierarchy under "/WEB-INF/classes".
-->
<target name="compile" depends="prepare"
description="Compile Java sources">
<!-- Compile Java classes as necessary -->
<mkdir dir="${build.home}/WEB-INF/classes"/>
<javac srcdir="src"
destdir="${build.home}/WEB-INF/classes"
debug="${compile.debug}"
deprecation="${compile.deprecation}"
optimize="${compile.optimize}">
<classpath refid="compile.classpath"/>
</javac>
<!-- Copy associated resource files -->
<copy todir="${build.home}/library/classes">
<fileset dir="src" includes="**/*.properties"/>
</copy>
</target>
<!-- ==================== Deploy Target =================================== -->
<!--
The "deploy" target copies the contents of the build directory into a
location required by our servlet container, and picks up any external
dependencies along the way. AFter restarting the servlet container, you
can now test your web application.
-->
<target name="deploy" depends="compile"
description="Deploy application to servlet container">
<!-- Copy the contents of the build directory -->
<mkdir dir="${deploy.home}"/>
<copy todir="${deploy.home}">
<fileset dir="${build.home}"/>
</copy>
<!-- Copy external dependencies as required -->
<!-- *** CUSTOMIZE HERE AS REQUIRED BY YOUR APPLICATION *** -->
<mkdir dir="${deploy.home}/WEB-INF/lib"/>
<!--
<copy todir="${deploy.home}/WEB-INF/lib" file="${foo.jar}"/>
-->
<copy todir ="${deploy.home}" >
<fileset dir="." includes="*.jsp"/>
</copy>
</target>
<!-- ==================== Dist Target ===================================== -->
<!--
The "dist" target creates a binary distribution of your application
in a directory structure ready to be archived in a tar.gz or zip file.
Note that this target depends on two others:
* "deploy" so that the entire web application (including external
dependencies) will have been assembled
* "javadoc" so that the application Javadocs will have been created
-->
<target name="dist" depends="deploy,javadoc"
description="Create binary distribution">
<!-- Copy documentation subdirectory -->
<copy todir="${dist.home}/docs">
<fileset dir="docs"/>
</copy>
<!-- Create application JAR file -->
<jar jarfile="${dist.home}/${app.name}.war"
basedir="${deploy.home}"/>
<!-- Copy additional files to ${dist.home} as necessary -->
</target>
<!-- ==================== Javadoc Target ================================== -->
<!--
The "javadoc" target creates Javadoc API documentation for the Java
classes included in your application. Normally, this is only required
when preparing a distribution release, but is available as a separate
target in case the developer wants to create Javadocs independently.
-->
<target name="javadoc" depends="compile"
description="Create Javadoc API documentation">
<mkdir dir="${dist.home}/docs/api"/>
<javadoc sourcepath="src"
destdir="${dist.home}/docs/api"
packagenames="mypackage.*"/>
</target>
<!-- ==================== Prepare Target ================================== -->
<!--
The "prepare" target is used to create the "build" destination directory,
and copy the static contents of your web application to it. If you need
to copy static files from external dependencies, you can customize the
contents of this task.
Normally, this task is executed indirectly when needed.
-->
<target name="prepare">
<!-- Create build directory and copy static content -->
<mkdir dir="${build.home}"/>
<copy todir="${build.home}">
<fileset dir="web"/>
</copy>
<!-- Copy static files from external dependencies as needed -->
</target>
</project>
Ara només cal reiniciar el tomcat, i apuntar amb el nostre navegador a http://localhost:8080/prova-servlet/index.html
Java Server Pages (JSP)
[modifica]Definició de JSP
[modifica]JSP, o Java Server Pages, són el complement perfecte als Servlets. Els JSP's no són més que pagines HTML amb codi java inserit a dins, que permet una millor interacció amb el Servlet amb el qual es comunica. Dit d'una altra manera, el codi java al JSP s'encarrega de la part dinàmica de la pàgina, i la resta de contingut estatic és produïda pel codi html.
Com podeu veure, la forma de introduir codi java dins dels JSP's és mitjançant les etiquetes <% per marcar l'inici, i %> per marcar el final.
<%
Passatger p = (Passatger) session.getAttribute("passatger");
%>
<html>
<body>
Benvingut, senyor <span style="color:blue;"><%= passatger.getCognom1() %></span>.
</body>
</html>
Hem de distingir entre tres tipus d'etiquetes:
- <%! %>, les utilitzarem per introduir declaracions d'objectes: <%! int contador=0 %>
- <%= %>, expressions o assignacions de valors: <%=element[i]%>. Podem incloure qualsevol expressió de java, sense el punt i coma final.
- <% %>, scriptlet, hi podem ficar directament codi java, sense importar el nombre de línies.
Els tags de JSP
[modifica]Aquí teniu una descripció, en anglès, dels tags que podeu utilitzar en un JSP. Els tags són rutines escrites en java utilitzades dins dels JSP's referenciant-les amb un tag o etiqueta per identificar-les. D'aquesta manera, un programador de JSP's només s'hauria de preocupar d'utilitzar aquests tags en comptes d'inserir directament codi java (que també pot).
A l'hora de definir aquests tags, tenim el que s'en diu la JSP Standard Tag Library, o llibreria de tags estandard de JSP, JSTL.
El primer que hem de fer per poder utilitzar aquest conjunt de tags, és importar-los dins del nostre JSP, amb la següent línia, que situarem a la capçelera:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
La forma <%@ %>, ens indica que estem introduint una directiva al nostre JSP. Això ens permet importar classes (amb page), insertar un fitxer extern (amb include), o definir noves etiquetes (amb taglib, com acabem de veure).
A la línia anterior, li estem dient al nostre JSP que ha d'utilitzar els tags d'aquesta llibreria, i els identificarem amb el prefix c. Així podem incloure, per exemple, les següents sentències condicionals:
<c:choose>
<c:when test='${p.parametre=="Jose"}'>
Soc jo.
</c:when>
<c:otherwise>
No ho soc.
</c:otherwise>
</c:choose>
Hi ha molts altres tags que podeu utilitzar (mireu l'ellaç anterior), així com codi java de la vostra aplicació directament a dins del JSP.