Resum

Un servlet és un programa del costat del servidor que s’utilitza per generar pàgines web dinàmiques. Genera pàgines web com a resposta d’una petició rebuda des del client (navegador). El servlet implementa el costat servidor de la comunicació client-servidor i pot rebre la petició de dues maneres diferents, amb el mètode GET o amb el mètode POST d’HTTP. GET és el mètode habitual amb el qual un navegador accedeix a una pàgina web, mentre que POST és el mètode utilitzat en l’enviament de dades al servidor des d’un formulari web.

Per configurar un servlet existeixen dues formes. La primera és la que utilitza NetBeans per defecte. NetBeans posarà com a notacions dintre del mateix servlet la seva configuració i les llegirà en el moment de la compilació. La segona manera és utilitzant el fitxer de desplegament anomenat web.xml (en anglès, web deployment descriptor). El fitxer web.xml es troba dintre de la carpeta WEB-INF i conté la informació corresponent al nom i l’URL dels servlets. Però bàsicament aquest fitxer informa el Servlet Container de la classe que ha d’executar (servlet) per a un URL donat.

Tots els servlets definits en una mateixa aplicació web comparteixen recursos i la informació web de l’aplicació. Per poder accedir a tota aquesta informació s’ha d’accedir al ServletContext, que dóna un conjunt de mètodes als servlets perquè es puguin comunicar.

De fet, el ServletContext és un objecte que conté metainformació sobre l’aplicació. Els atributs emmagatzemats en el ServletContext estan disponibles a tots els servlets de l’aplicació, fins i tot entre diferents peticions i sessions.

L’objecte ServletConfig s’utilitza per obtenir informació de configuració del fitxer web.xml. Aquest objecte és creat pel contenidor web per a cada servlet. Si la informació de configuració es defineix a l’arxiu web.xml no cal canviar el servlet. Per tant, és més fàcil administrar l’aplicació web si els paràmetres del servlet només es modifiquen de tant en tant.

Els mètodes bàsics que ens proporcionen els servlets són tres. El mètode init, que s’executa quan s’inicia l’aplicació o la primera vegada que s’executa el servlet. El mètode service, que s’executa en un fil (thread) diferent cada vegada que el servlet rep una petició (request), i el mètode destroy, que s’executa quan s’elimina l’aplicació. Aquests tres mètodes constitueixen el cicle de vida d’un servlet.

Els usuaris poden enviar informació als servlets utilitzant formularis HTML. Tota la informació que s’envia des del navegador cap al servlet s’emmagatzema a l’objecte request (petició). Aquest objecte té un mètode anomenat .getParameter(name) per obtenir les dades que ha enviat l’usuari. El nom que s’ha d’utilitzar per obtenir les dades és el nom que s’ha configurat a la propietat name de l’input corresponent del formulari HTML.

Les dades que ens envien al servlet s’han de validar. S’ha de comprovar que les dades compleixen les restriccions demanades per l’aplicació. Per exemple, que una adreça de correu contingui una arrova i un domini vàlid. La validació de les dades les pot fer el mateix servlet o pot delegar a tercers.

Podem utilitzar l’arquitectura Enterprise Java Bean (EJB) per fer la validació. Aquesta arquitectura ens permet la reutilització dels seus components en aquesta o en altres aplicacions. Un EJB és una arquitectura de components de servidor que simplifica el procés de construcció d’aplicacions de components empresarials distribuïts en Java.

S’utilitza l’arquitectura EJB sempre que vulguem que l’aplicació sigui escalable, integritat de dades mitjançant transaccions i que tingui una gran varietat de clients. Els EJB no es poden utilitzar directament per interaccionar amb el protocol HTTP. Necessita d’un framework, com poden ser Spring, JSF o aplicacions basades en servlets, per tractar amb el protocol HTTP i després enviar la informació necessària a l’EJB.

Quan s’utilitza l’arquitectura EJB, el servlet només conté la part visual de la pàgina de resposta, i tota la lògica de l’aplicació està externalitzada a un component EJB.

Un EJB és un component que ha d’executar-se en un contenidor d’EJB, i es diferencia molt d’un JavaBean normal. Un Java Bean és un objecte al qual accedim de manera directa des de la nostra aplicació, i en canvi un EJB és un component al qual no podem accedir d’una manera tan directa, atès que sempre hi accedim a traves d’algun tipus d’intermediari. Aquest intermediari ens aportarà una sèrie de serveis definits pels estàndards en els quals l’EJB es pot recolzar. Existeixen dos tipus d’intermediaris: l’intermediari local i l’intermediari remot. L’intermediari local és aquell que s’executa a la mateixa màquina virtual de Java que l’EJB. En canvi, el remot és aquell intermediari que s’executa en una màquina virtual de Java diferent de la màquina on s’executa l’EJB.

Cadascuna d’aquestes interfícies intermediàries s’encarreguen de definir els mètodes que estaran a la disposició dels clients que els invoquen. Aquestes interfícies són les encarregades de donar accés als EJB a tots els serveis addicionals que suporta el contenidor EJB. Un contenidor EJB (EJB Container) és l’encarregat d’administrar l’execució dels components EJB. Controla totes les funcionalitats d’un EJB dintre del servidor actuant com a intermediari entre el servidor i l’aplicació.

Un contenidor d’EJB pot administrar dos tipus de components EJB: els beans de sessió (session beans) o els beans dirigits per missatges (message-driven beans). Els beans de tipus message-driven són beans que processen missatges asíncrons. Els missatges es reben i s’envien mitjançant el servei de missatges de Java (JMS, Java Message Service). Els beans de sessió encapsulen la lògica de l’aplicació i poden ser invocats per un client local, un client remot o un client d’un servei web (web service).

Els EJB de sessió es poden utilitzar per validar la informació rebuda des d’un formulari HTML. Per fer la validació s’utilitza el model JavaBeans Validation, que és un model de validació basat en restriccions (constraints). Les restriccions es posen com a notacions en una propietat, un mètode o una classe JavaBean, i les pot definir l’usuari (custom constraint) o bé utilitzar les que porta per defecte el model (built-in constraints). Un exemple de restriccions que porta el model de validació son les notacions següents: @Min, @NotNull, @Size i @Pattern.

L’arquitectura EJB també s’utilitza per autenticar i autoritzar usuaris dintre de l’aplicació. Per poder utilitzar aquesta funcionalitat s’han de definir els rols dels usuaris que poden executar els diferents mètodes dels EJB. Aquest rols han de coincidir amb els rols definits a l’arxiu web.xml del servidor web. L’autorització es fa a nivell d’EJB utilitzant anotacions directament en els mètodes i en les classes. Les anotacions que podem fer servir són les següents: DeclareRoles, RolesAllowed, PermitAll i DenyAll, entre d’altres.

A part de rebre informació de l’usuari mitjançant formularis HTML també ens pot interessar reconèixer un usuari que ha entrat anteriorment al programa. El navegador pot guardar la informació en forma d’arxiu de text al disc dur del visitant de la pàgina web per tal que certes informacions puguin ser recuperades en posteriors visites. Una galeta (cookie) és el fragment d’informació enviat des d’un servidor de pàgines web a un navegador que pot ésser retornada per aquest en posteriors accessos a aquest servidor. La galeta, però, pot ser de tipus persistent (no s’esborra quan l’usuari tanca el navegador, sinó que té un temps màxim de vida i s’esborra quan arriba el moment) i no persistent (la galeta s’esborra quan l’usuari tanca el navegador).

Una altra tècnica que es pot utilitzar és fer ús de les sessions. Una sessió serveix per emmagatzemar informació entre diferents peticions HTTP i, a diferència de les galetes, la sessió es guarda en el costat del servidor. Una vegada s’ha creat la sessió s’envia al navegador de l’usuari una galeta que serveix per identificar-lo i associar-li el HashMap que s’acaba de construir perquè pugui emmagatzemar-hi informació. Es pot accedir a aquest HashMap des de qualsevol altra pàgina de la mateixa aplicació, i ens permet compartir informació.