App Web Java EE

DESARROLLO DE APLICACIONES WEB CON JAVA ENTERPRISE EDITION
Junta de Comunidades de Castilla-La Manc a Conse!e"#a de Educaci$n% Cultu"a & De'o"tes Sergio Tendero Zapero
Desarrollo de aplicaciones web con Java Enterprise Edition
ndice de contenido
1. Arquitectura Java EE....................................................................................................................................4 1.1. La platafor a Java................................................................................................................................4 1.1.1. El lengua!e Java............................................................................................................................4 1.1.". #erra ientas de desarrollo $ e!ecuci%n........................................................................................& 1.". Ediciones..............................................................................................................................................' 1.(. Java Enterprise Edition.......................................................................................................................11 1.(.1. )odelo de aplicaci%n..................................................................................................................11 1.(.". *apas en la arquitectura Java EE................................................................................................14 1.(.(. *ontenedores Java EE................................................................................................................1+ 1.(.4. E paquetando aplicaciones........................................................................................................", 1.(.-. Java EE A./................................................................................................................................"" ". Entorno de desarrollo.................................................................................................................................."" (. *apa 0eb...................................................................................................................................................."(.1. Aplicaciones web en Java EE............................................................................................................."(.1.1. /ntroducci%n................................................................................................................................"(.1.". *iclo de vida de una aplicaci%n web..........................................................................................."+ (.1.(. )%dulos web.............................................................................................................................."+ (.1.4. *onfigurando aplicaciones web.................................................................................................."' (.". Tecnolog1a Java Servlets.....................................................................................................................(, (.".1. 23u4 es un Servlet5....................................................................................................................(, (.".". *iclo de vida de un Servlet.........................................................................................................(1 (.".(. /niciali6aci%n de un Servlet.........................................................................................................(1 (.".4. Escribiendo 4todos de servicio.................................................................................................(" (.".-. *o partiendo infor aci%n.........................................................................................................(( (.".7. 8iltrando peticiones $ respuestas................................................................................................(4 (.".+. /nvocando otros recursos web.....................................................................................................(7 (.".&. )anteniendo el estado del cliente...............................................................................................(+ (.".'. 8inali6ando un Servlet................................................................................................................(& (.(. Tecnolog1a JavaServer .ages..............................................................................................................(' (.(.1. 23u4 es una p9gina JS.5............................................................................................................(' (.(.". *iclo de vida de una p9gina JS..................................................................................................4, (.(.(. *reando contenido est9tico.........................................................................................................4" (.(.4. *reando contenido din9 ico......................................................................................................4" (.(.-. :sando scripting en p9ginas JS.................................................................................................4(
"
(.(.7. :sando etiquetas en JS..............................................................................................................44 (.(.+. El lengua!e de e;presiones unificado..........................................................................................4(.(.&. *o ponentes Java<eans.............................................................................................................47 (.(.'. =eutili6aci%n de contenido en p9ginas JS..................................................................................4' (.(.1,. Transfiriendo el control a otro co ponente web.......................................................................4' (.4. Arquitectura de la capa web................................................................................................................-, (.4.1. /ntroducci%n................................................................................................................................-, (.4.". JS.> )odelo 1.............................................................................................................................-1 (.4.(. JS.> )odelo ".............................................................................................................................-" (.4.4. Apac?e Struts..............................................................................................................................-(.-. A!a; en Java EE..................................................................................................................................74 (.-.1. /ntroducci%n................................................................................................................................74 (.-.". A!a; $ tecnolog1as en el lado del servidor Java EE.....................................................................7+ 4. *apa de negocio..........................................................................................................................................7& 4.1. /ntroducci%n........................................................................................................................................7& 4.". Tecnolog1as $ estrategias....................................................................................................................7' 4.".1. Apro;i aci%n .@J@ A Java<eans..............................................................................................7' 4.".". Apro;i aci%n EJ<......................................................................................................................+1 -. *apa de persistencia...................................................................................................................................++ -.1. /ntroducci%n........................................................................................................................................++ -.". )odelos cl9sicos de persistencia........................................................................................................++ -.".1. .ersistencia en las clases del odelo..........................................................................................+& -.".". .ersistencia en clases au;iliares..................................................................................................+& -.(. )ecanis os $ tecnolog1as de persistencia..........................................................................................&1 -.(.1. Java Database *onnectivit$ BJD<*C...........................................................................................&1 -.(.". )apeo @b!etoD=elacional. Java .ersistence A./........................................................................&( 7. *o unicaci%n entre capas $ aplicaciones...................................................................................................', 7.1. /ntroducci%n........................................................................................................................................', 7.". =)/ A EJ<s........................................................................................................................................', 7.(. Servicios 0eb.....................................................................................................................................'" 7.(.1. /ntroducci%n................................................................................................................................'( 7.(.". A;is ............................................................................................................................................'7.(.(. JAED0S.....................................................................................................................................'7 +. <ibliograf1a $ referencias............................................................................................................................'+
Objetivo del curso

Sentar las bases para el desarrollo de aplicaciones web las capas. ulticapa con la tecnolog1a Java
Enterprise EditionF viendo qu4 co ponentes $ servicios proporciona la platafor a en cada una de
1. Arquitectura Java EE
1.1. La plataforma Java
La platafor a Java est9 confor ada por un con!unto de productos $ especificaciones software de @racle *orporation que co ponen un entorno para el desarrollo $ despliegue de aplicaciones software.
1.1.1.
El lenguaje Java
Java es un lengua!e de progra aci%n de prop%sito generalF original ente desarrollado por Ja es Gosling para la e presa Sun )icros$ste s $ liberado en 1''- co o el co ponente central de la platafor a Java.
La sinta;is del lengua!e deriva de * $ *HHF pero dispone de un anipulaci%n directa de punteros o e oria.
odelo de ob!etos
9s
si ple $ eli ina ?erra ientas de ba!o nivelF que suelen inducir a nu erosos erroresF co o la
La i ple entaci%n original $ de referencia del co piladorF la
9quina virtual $ las
bibliotecas de clases de Java ?an sido desarrolladas por Sun )icros$ste s desde su aparici%nF $ 4
continuadas tras su adquisici%n por parte de @racle *orporation. .ara elloF en 1''& se cre% el Java *o unit$ .rocess BJ*.C co o proceso for ali6ado que per ite a las diferentes partes interesadas involucrarse en la definici%n de nuevas versiones $ caracter1sticas de la platafor a Java. El proceso de definici%n est9 basado en el uso de los Java Specification =equest BJS=CF que son docu entos for ales que describen las especificaciones $ tecnolog1as propuestas para que sean aIadidas a la platafor a Java.
A nivel de licenciasF se ?an liberado la gran Licencia .Jblica General de GK: BGK: G.LC.
a$or1a de las tecnolog1as Java ba!o la
Los ob!etivos de diseIo del lengua!e de progra aci%n Java est9n dirigidos por la naturale6a de los entornos de traba!o en los que el software debe ser desplegado. En particularF el gran creci iento de /nternet $ la 0orldD0ide 0ebF !unto con el co ercio electr%nicoF ?a provocado la necesidad de desarrollar aplicaciones segurasF robustasF con un alto rendi iento $ con la capacidad de e!ecutarse en Jltiples platafor as sobre redes distribuidas $ ?eterog4neas.
De esta
aneraF entre los principios de diseIo del lengua!e Java pode os destacar>
Si ple $ orientado a ob!etos> las caracter1sticas del lengua!e lo ?acen f9cil de aprenderF per itiendo a los progra adores co en6ar a utili6arlo r9pida ente. Ade 9s es orientado a ob!etosF para aprovec?arse de las 9s odernas etodolog1as de desarrollo software $ para ensa!es t1picos del software per itir su uso en aplicaciones distribuidas de tipo clienteDservidorF cu$as necesidades coinciden con los paradig as de encapsulaci%n $ el paso de orientado a ob!etos. =obusto $ seguro> uno de los aspectos de e!ecuci%n. Se dispone de un progra ador es el que decide el e oriaF decide cuando la 9s i portantes es la alta fiabilidad del softwareF e oria u$ sencilloF en el cual el
para lo que se proporcionan co probaciones en tie po de co pilaci%n as1 co o en tie po odelo de gesti%n de o ento en el que se crea un ob!etoF $ por tanto se ocupa la ediante el recolector de basuraF el que
ientras que es el entorno de e!ecuci%nF
e oria debe ser liberada. Al estar dirigida a operar ba!o entornos
distribuidosF la tecnolog1a Java dispone de una serie de caracter1sticas de seguridad tanto en -
el lengua!e co o en el entorno de e!ecuci%n que per ite construir aplicaciones seguras frente a intrusiones de c%digo alicioso.
.ortable $ arquitect%nica ente neutral> al estar dirigido a un entorno e inente ente ?eterog4neoF es necesario que el software se aco ode a diversos siste as operativosF platafor as $ que sea capa6 de interoperar con transportar c%digo eficiente ente sobre Jltiples interfaces de progra aci%nL para elloF el co pilador de !ava genera bytecodeF que es un for ato inter edio que per ite Jltiples platafor as ?ardware $ software. Este 9quina 9quinas c%digo inter edio podr9 ser e!ecutado en una platafor a espec1fica a trav4s de una refle!adas en el b$tecode segJn la platafor a concretaF e;istiendo as1 diferentes virtuales para las diversas arquitecturas. Alto rendi iento> se dispone de diferentes ecanis os que per iten lograr este ob!etivoF Jltiples ?ilos Bt?readsC si ult9neosF de
virtual de Java o Java Mirtual )ac?ine BJM)CF que interpreta $ e!ecuta las instrucciones
entre ellos destaca la posibilidad de e!ecutar
anera que cada uno de ellos puede reali6ar una tarea de for a paralela Bdescargar un fic?eroF interaccionar con el usuarioF etc.CL ade 9s de 4steF en la interpretaci%n del c%digo no es necesario volver a co probar el entorno de e!ecuci%nF el recolector de basura se e!ecuta en un ?ilo de ba!a prioridadF etc. /nterpretado $ din9 ico> co o se co ent% anterior enteF Java utili6a una e!ecuci%n basada en la interpretaci%n de un c%digo inter edio Bb$tecodeCL esto conlleva algunos beneficios asociados co o una e!ora en la fase de enla6ado del progra aF que tiene un car9cter din9 icoF enla6ando s%lo las clases que se necesitan.
A la vista de estos principiosF un ciclo de desarrollo $ e!ecuci%n si ple en Java i plicar1a escribir el c%digo fuente del progra a en fic?eros con e;tensi%n .!avaF co pilarlosF obteniendo as1 una serie de fic?eros .class que contienen el bytecode o c%digo inter edio $ e!ecutarlos en una instancia de una 9quina virtual.
*o o se di!o anterior enteF es posible i ple entar diferentes platafor as e;istentesF per itiendo as1 e!ecutar el
9quinas virtuales de Java para las is o bytecode sobre diferentes
siste as operativosF $ alcan6ado as1 uno de los ob!etivos de JavaF el Nwrite onceF run an$w?ereOF es decirF se puede escribir un progra a $ e!ecutarlo en cualquier dispositivo para el que se ?a$a i ple entado una 9quina virtual.
Desafortunada enteF no todo son venta!asF $ la interpretaci%n del c%digo inter edio provoca un rendi iento en e!ecuci%n inferior a los progra as que se e!ecutan a trav4s de c%digo nativo. .ara ini i6ar este i pacto en el rendi iento se ?an introducido t4cnicas co o la co pilaci%n en tie po de e!ecuci%n o NJustDinDti e co pilationO BJ/TCF que convierte el c%digo inter edio en c%digo nativo durante su e!ecuci%n. Esta t4cnica suele estar incluida en las Jlti as 9quinas virtuales disponibles.
A nivel generalF puede decirse que los progra as escritos en Java $ e!ecutados con t4cnicas J/T son 9s lentos que los generados con lengua!es que utili6an co pilaci%n nativaF co o * o *HHF de un orden si ilar a otros que ta bi4n usan t4cnicas J/TF co o *P u otros de la platafor a .KETF +
9s r9pidos que los lengua!es que no utili6an co piladores nativos co o .#.F .erlF =ub$ o
.?$ton.
1.1.2.
Herramientas de desarrollo y ejecucin
Dos de los principales productos de la platafor a son el Java Develop ent Qit BJDQC $ el Java =unti e Environ ent BJ=EC.
El JDQ es la parte de la platafor a dirigida a los desarrolladoresF por lo que inclu$e tanto el propio lengua!e de progra aci%n JavaF co o un con!unto de ?erra ientas de desarrollo> el int4rprete B!avaCF el co pilador B!avacCF el e paquetador B!arCF el depurador B!dbCF el generador de docu entaci%n B!avadocCF etc. Ade 9s de todas estas ?erra ientasF una distribuci%n del JDQ inclu$e el con!unto de co ponentes del J=E.
El J=E proporciona el entorno de e!ecuci%n de aplicaciones JavaF para lo cual cuenta con una i ple entaci%n del con!unto de librer1as est9ndar BJava A./CF $ la Java Mirtual )ac?ine BJM)CF ade 9s de otros co ponentes adicionales. 9quina virtual de Java o
De for a an9loga a otras platafor as de progra aci%nF el con!unto de librer1as est9ndar proporciona un con!unto de funciones $ servicios al progra ador para la reali6aci%n de tareas co unes> ane!o de datosF seguridadF acceso a bases de datosF creaci%n de interfaces de usuarioF etc. Las clases se organi6an en la A./ en paquetesF conteniendo cada paquete un con!unto de interfacesF clases $ e;cepciones. La definici%n de la A./ est9 controlada por @racle a trav4s del progra a Java *o unit$ .rocess.
.or su parteF la JM)F es el ente que per ite la e!ecuci%n del c%digo inter edio generado por el co pilador de JavaF obteniendo as1 la independencia de la platafor aF que es uno de los principales ob!etivos de esta tecnolog1a. &
A continuaci%nF se
uestra un diagra a de la platafor a Java>
1.2. Ediciones
La platafor a Java est9 dividida actual ente en edicionesF estando cada una de ellas dirigida a un entorno diferente de aplicaciones $ contando con un con!unto de librer1as est9ndar que pueden variar en a$or o enor edida.
Java *ard> es la edici%n dirigida a la e!ecuci%n de aplicaciones Java BappletsC en tar!etas inteligentes o Rs art cardsR $ otros dispositivos si ilaresF siendo los principales ob!etivos de la tecnolog1a la portabilidad $ seguridad. Tiene su propia definici%n de bytecode $ de su 9quina virtual BJava *ard Mirtual )ac?ineCF as1 co o un con!unto S/). 1ni o de librer1asF todo ello opti i6ado para el entorno al que va dirigido. Su uso es frecuente en tar!etas tipo
'
Java )icro Edition BJava )EC> diseIada para su uso en dispositivos
%viles co o tel4fonos
o .DAs. Se caracteri6a por disponer de un con!unto reducido de las librer1as de clases de Java que per iten el desarrollo de aplicaciones para estos dispositivos de recursos reducidos. Actual ente se dispone de dos configuracionesF entendidas co o un con!unto de librer1as b9sicas $ una serie de capacidades de la 9quina virtual. La N*onected Li ited Device *onfiguration B*LD*CO para dispositivos pequeIos $ la configuraci%n N*onected Device *onfiguration B*D*CO para dispositivos con unas capacidades superiores. La pri era de ellas es la utili6ada co o est9ndar de facto para el desarrollo de !uegos para %vil. Java Standard Edition BJava SEC> es la edici%n central de la tecnolog1aF en la que se funda entan las de 9sF $ que posibilita el desarrollo de aplicaciones de prop%sito generalF e!ecutables en ordenadores personalesF servidores $ dispositivos si ilaresF $a sea en for a de appletsF aplicaciones de escritorio o de consola. Define un con!unto de librer1as que confor an su A./ $ que dan servicios de car9cter general a las aplicaciones Buso de siste as de arc?ivosF redesF interfaces gr9ficasF etc.C. Java Enterprise Edition BJava EEC> se trata de la edici%n dirigida al desarrollo de aplicaciones e presarialesF ulticapa $ distribuidas. .ara ello se basa en la A./ de la edici%n est9ndar a la que aIade un con!unto de librer1asF tales co o JD<*F =)/F eD ailF J)SF web servicesF E)LF etcL as1 co o una serie de especificaciones para co ponentes de la arquitectura Java EEF co o Enterprise Java <eansF *onnectorsF servletsF portletsF Java Server .agesF etc. .or Jlti oF aparece el concepto de servidor de aplicaciones Java EEF co o una entidad software con capacidad de ane!ar las transaccionesF la seguridadF la escalabilidadF la concurrencia $ la gesti%n de los co ponentes de la arquitectura que se despliegan sobre 4lF per itiendo as1 que el desarrollador se concentre en la i ple entaci%n de la l%gica de negocio en lugar de la infraestructura o las tareas de integraci%n.
1,
Java8E> es la edici%n
9s recienteF estando dirigida al desarrollo de aplicaciones del lado anipulaci%n de
cliente o =/A Bric? /nternet applicationsC. Dispone de un SDQ propio en el que se inclu$en ?erra ientas para la co pilaci%n $ e!ecuci%nF $ una A./ con soporte para contenidos ulti ediaF co ponentes de interfa6 de usuarioF etc.
1.3. Java Enterprise Edition
La edici%n e presarial de Java o Java EEF est9 dirigida al desarrollo de aplicaciones e presarialesF aplicaciones $ ulticapa $ distribuidas. .roporciona a los desarrolladores un con!unto potente e!orar el rendi iento de dic?as aplicaciones. co ponentes $ servicios que les per ite reducir el tie po de desarrolloF la co ple!idad de las
1.3.1.
Modelo de aplicacin
11
Java EE propone un
odelo de aplicaci%n que parte del lengua!e Java $ del concepto de
9quina virtual que proporcionan la portabilidad $ la seguridad.
El
odelo est9 diseIado para soportar aplicaciones que i ple enten los servicios
e presariales para clientesF e pleadosF proveedoresF u otros que realicen peticiones o contribuciones a la e presaF siendo por tanto dic?as aplicaciones in?erente ente co ple!as en su l%gicaF con necesidad de acceder a arquitectura Jltiples fuentes de datos $ de ser distribuidas a una gran variedad de clientes. .ara responder a estos servicios $ requeri ientosF Java EE define una ulticapa que proporciona la escalabilidadF accesibilidad $ gesti%n que este tipo de aplicaciones e presariales necesita.
Este
odelo divide el traba!o para i ple entar los servicios e presariales requeridos en
dos partes> la l%gica de negocio $ presentaci%nF que deber9 i ple entar el desarrollador $ los servicios est9ndares del siste a que son proporcionados por la propia platafor aF aportando as1 al desarrollador soluciones para los proble as de nivel de siste a que i plica un servicio i ple entado ba!o una arquitectura ulticapa.
En este
odelo
ulticapa $ distribuidoF la l%gica de la aplicaci%n est9 dividida en
co ponentesF que reali6an diferentes funciones $ que pueden estar desplegados en diferentes 9quinas dependiendo de la capa a la que el co ponente pertene6caF es decirF la platafor a Java EE define una arquitectura con una separaci%n de capasF cada una de ellas con un con!unto de responsabilidades $ unos co ponentes asociados puestos a disposici%n del desarrollador para i ple entar las funcionalidades de cada capa espec1fica.
1"
:n co ponente Java EE es una unidad funcional de software autocontenidaF que se ensa bla dentro de una aplicaci%n con sus clases $ fic?eros asociados. La especificaci%n de Java EE define los siguientes co ponentes> Aplicaciones cliente $ applets que se e!ecutan en el clienteF perteneciendo as1 a la capa cliente. Java ServletF JavaServer 8aces $ JavaServer .ages BJS.C son co ponentes web que se e!ecutan en el servidor Bcapa webC. Enterprise Java<eans BEJ<C son co ponentes de la capa de negocio que se e!ecutan en el servidor.
Los co ponentes Java EE est9n escritos en lengua!e Java $ se co pilan de la
is a
anera
que cualquier progra a del lengua!e. La diferencia entre las clases Java est9ndares $ los co ponentes radica en que estos Jlti os deben cu plir su correspondiente especificaci%nF lo cual garanti6a su correcta e!ecuci%n $ gesti%n en los servidores Java EE.
1(
1.3.2.
apas en la arquitectura Java EE
El capa.
odelo de aplicaci%n de la platafor a Java EE define una arquitectura
ulticapa. A
continuaci%n se e;ponen las responsabilidades $ co ponentes
9s i portantes asociados a cada
(i)
Capa cliente.
En la capa cliente est9n los co ponentes que interactJan directa ente con el usuarioF per iti4ndole introducir los datos $ enviar peticiones. .roporcionan la interfa6 gr9fica de presentaci%n al usuario $ ta bi4n pueden incluir introducidos por el usuario ecanis os de validaci%n de los datos ediante lengua!es de script. E;isten dos tipos de co ponentes>
*lientes web> consisten en dos partes diferenciadasF las p9ginas web din9 icas que contienen diferentes tipos de lengua!e de arcado $ que se generan a trav4s de los co ponentes web que se e!ecutan en la capa webF $ el navegador webF que renderi6a las p9ginas recibidas del servidor. A este tipo de clientes se le suele deno inar Rclientes ligerosRF $a que la carga de operaci%n se reali6a en el servidorF ientras que el cliente se li ita a presentar los contenidos. En ocasionesF una p9gina web recibida de la capa web puede incluir un appletF que es una pequeIa aplicaci%n cliente escrita en el lengua!e de progra aci%n Java $ que se e!ecuta en la 9quina virtual del cliente. 9quina
Aplicaciones cliente> se deno ina as1 a las aplicaciones que se e!ecutan en la cliente $ que per iten disponer de una interfa6 lengua!es de
9s rica que la que proporcionan los
arcado. Ade 9sF estas aplicaciones tienen la posibilidad de acceder
directa ente a la capa de negocio $ pueden i plicar procesa iento de datosF por tanto se les suele deno inar de tipo Rcliente pesadoRF estando nor al ente basadas en la platafor a Java SE.
14
A la ?ora de elegir un tipo de cliente u otroF se debe considerar la posibilidad de 9s funcionalidad en la parte del cliente Bcliente pesadoC o concentrarla ligeroC. )antener la aplicaci%nF sin e bargoF antenerla en el cliente per itir9
antener
9s en el servidor Bcliente
9s funcionalidad en el servidor facilitar9 la distribuci%nF despligue $ gesti%n de e!orar la e;periencia del usuario.
(ii)
Capa web
La capa web se encarga de recibir $ procesar las peticiones que provienen de la capa clienteF generando contenido din9 ico que puede requerir de la interacci%n con la capa de negocioF interconectandoF por tantoF la capa cliente con la l%gica de la aplicaci%n. Los co ponentes $ tecnolog1as 9s i portantes de esta capa son>
Servlets> son clases progra adas en lengua!e Java $ que son capaces de procesar din9 ica ente peticiones $ construir las respuestas. Se basan en el odelo requestA response del protocolo #TT.F disponiendo de todo el poder de la A./ de Java. .9ginas JS.> son docu entos que se e!ecutan co o servlets pero que per iten una apro;i aci%n 9s natural a la ?ora de crear contenido est9ticoF $a que per iten intercalar arcado. 1c%digo Java $ JS. con lengua!es de
JavaServer 8aces> es una tecnolog1a que proporciona un fra eworS de co ponentes de interfa6 de usuario a las aplicaciones web.
Al igual que en la capa de clienteF se pueden incluir co ponentes Java<eans para gestionar la entrada del usuario $ enviar esa entrada a los co ponentes que se e!ecutan en la capa de negocio para su procesa iento.
(iii)
Capa de negocio
Se ocupa de i ple entar la l%gica de negocio necesaria para dar respuesta a los requisitos del do inio de la aplicaci%nF lo que inclu$e recibir los datos de la capa cliente $ la capa web $ procesarlosF e itiendo as1 los resultados adecuadosF $ gestionandoF si es necesarioF la persistencia de la infor aci%nF co unic9ndose con la capa de siste as de infor aci%n e presarial.
17
(iv)
Capa de sistemas de informacin empresarial.
Esta capa per ite la cone;i%n de la arquitectura Java EE con los recursos e presariales co o siste as E=.F siste as transaccionalesF siste as de base de datosF u otros siste as de infor aci%n ?eredadosF con los que la aplicaci%n necesita co unicarseF por e!e plo para proporcionar conectividad con bases de datos.
1.3.3.
ontenedores Java EE
En las aplicaciones
ulticapa de cliente ligero cl9sicas se requieren
uc?as l1neas de c%digo
para la gesti%n de las transaccionesF del estadoF de la e!ecuci%n contenedor para cada tipo de co ponenteF de
ulti?iloF del pool de recursos $ de
otros detalles de ba!o nivel. Java EE proporciona una serie de servicios sub$acentes en for a de anera que el desarrollador puede utili6arlos $ centrarse en la resoluci%n del proble a de negocio concreto.
1+
:n contenedor es la interfa6 entre un co ponente $ la funcionalidad de ba!o nivel espec1fica de la platafor a que soporta el co ponente. Antes de poder e!ecutar un co ponente deber9 ser ensa blado en un %dulo Java EE $ desplegado en el contenedor correspondiente.
El proceso de ensa blado i plica especificar una serie de par9 etros del contenedor para los co ponentes de la aplicaci%n Java $ para la aplicaci%n en s1 is aF de anera que dic?os par9 etros per iten configurar el soporte sub$acente aportado por el servidor Java EEF inclu$endo servicios co o la seguridadF la gesti%n de las transaccionesF el servicio de bJsqueda Java Ka ing and Director$ /nterface BJKD/CF la conectividad re otaF etc. Es decirF en funci%n de los par9 etros especificados al ensa blar la aplicaci%nF pode os ?acer que 4sta var1e su co porta iento sin necesidad de ca biar el c%digo de los co ponentes. Aparte de estos servicios configurablesF los contenedores ta bi4n proporcionan servicios no configurables co o la gesti%n del ciclo de vida de los EJ<s $ ServletsF la gesti%n del pool de cone;iones a base de datosF la persistencia de datos $ el acceso a la A./ de la platafor a.
La platafor a Java EE define cinco tipos de contenedores> *ontenedor de applets> gestiona la e!ecuci%n de los applets. *onsiste en un navegador web $ un plugDin de Java e!ecut9ndose !untos en el cliente. *ontenedor de aplicaci%n cliente> gestiona la e!ecuci%n de los co ponentes de la aplicaci%n cliente. Tanto el contenedor co o la aplicaci%n se e!ecutan en cliente. *ontenedor web> gestiona la e!ecuci%n de las p9ginas JS. $ los servlets de las aplicaciones Java EEF controlando el ciclo de vida de los servlets $ el apeo entre una :=L $ un servlet deter inadoF garanti6ando que la petici%n dispone de los derec?os de acceso adecuados. Ta bi4n per iten gestionar algunos co ponentes EJ< para aplicaciones Java EE. Los co ponentes web $ su contenedor se e!ecutan en el servidor Java EE. *ontenedor de Enterprise Java <eans BEJ<C> gestiona la e!ecuci%n de los EJ<s en las aplicaciones Java EE. Al igual que los co ponentes webF se e!ecutan en el servidor Java EE. Servidor Java EE> es la parte de e!ecuci%n de un producto Java EEF proporcionando contenedores de EJ< $ web.
1&
Estos tipos de contenedores son i ple entados por diferentes fabricantesF de
anera que
garanticen la co patibilidad con la tecnolog1a que i ple entan. Esto i plica que deben ser capaces de proporcionar los servicios asociados al contenedor $ a los co ponentes que 4ste soporta.
Las i ple entaciones de servidores total ente co patibles con Java EE 7F pueden consultarse en> ?ttp>TTwww.oracle.co Ttec?networST!avaT!avaeeToverviewTco patibilit$D!spD1(7'&4.?t l Entre ellos se inclu$en> @racle Glass8is? Server (.; @racle 0ebLogic Server 1" J<oss Application Server +.; Apac?e Geroni o (.,DbetaD1
Estos servidores de aplicaciones Java EE disponen de contenedores de EJ<s $ webF pero
1'
ta bi4n se pueden encontrar servidores web que Jnica ente disponen del contenedor webF co o por e!e plo Apac?e To catF que es un contenedor web que i ple enta las especificaciones de Java Servlets $ JS. para generar un servidor web #TT. para Java.
1.3.!.
Empaquetando aplicaciones
Kor al enteF el desarrollador no
ane!a directa ente el servidor que se va a utili6ar en ecanis os de
producci%nF por lo queF una ve6 que se disponga de una versi%n de la aplicaci%n estableF 4sta deber1a publicarse en el servidor correspondiente. .ara elloF Java EE dispone de los servidores de producci%n. :na aplicaci%n Java EE se entrega a trav4s de un Enterprise Arc?ive BEA=CF que es un Java Arc?ive BJA=C est9ndar con la e;tensi%n .ear. :n fic?ero JA= supone la agregaci%n de uc?os fic?eros en uno. Se utili6a para distribuir etadatos $ los recursos asociados. .ara e paqueta iento $ despliegueF que nos per iten garanti6ar una correcta publicaci%n en los
aplicaciones Java o librer1asF inclu$endo las clasesF los for ato Z/.. :n fic?ero EA= contiene
crear el arc?ivo JA= se utili6a el co ando jar, incluido en el JDQF que genera un arc?ivo que usa el
%dulos Java EE $ descriptores de despliegue.
:n descriptor de despliegue es un docu ento E)L con e;tensi%n .; l que describe los par9 etros de despliegue de una aplicaci%nF %dulo o co ponente. La infor aci%n del descriptor odificar el c%digo fuente. En tie po de %dulo o es declarativaF pudiendo ser ca biada sin necesidad de
e!ecuci%nF el servidor Java EE lee el descriptor de despliegue $ actJa sobre la aplicaci%nF su c%digo.
co ponente en consecuenciaF por tanto per ite variar el co porta iento de la aplicaci%n sin variar
Se pueden diferenciar dos tipos de descriptores de despliegueF los que se definen a trav4s de la especificaci%n Java EEF que per iten la configuraci%n de cualquier i ple entaci%n que cu pla ",
con dic?a especificaci%nL $ los dependientes del del entorno de e!ecuci%nF que per iten configurar par9 etros espec1ficos de la i ple entaci%n Java EE que da el servidor de aplicaciones utili6ado. .or e!e plo puede per itir configurar el Rconte;t rootR de la aplicaci%nF el apeo entre los no bres portables de los recursos de la aplicaci%n $ los recursos del servidorF as1 co o otros par9 etros espec1ficos del servidor de aplicaciones co o las directivas de cac?eo. Los descriptores se inclu$en en el directorio )ETAD/K8 del e paquetado. :n %dulos> )%dulos EJ<F que contienen fic?eros de clases B.classC de EJ<s $ el descriptor correspondienteF en el que se pueden incluir aspectos co o los atributos de seguridad $ transacci%n para los beans. Se e paquetan en fic?eros JA= con la e;tensi%n .!ar. )%dulos webF que contienen fic?eros de clases de ServletsF fic?eros JS.F otras clases de soporteF fic?eros #T)LF otros recursos est9ticosF $ un descriptor de despliegue de aplicaci%n web. Los %dulos web se e paquetan con la e;tensi%n .war B0eb A=c?iveC. )%dulos de aplicaciones clienteF que contienen fic?eros de clases $ un descriptor de despliegue de la aplicaci%n cliente. Se e paquetan con la e;tensi%n .!ar. )%dulos adaptadores de recursosF que contienen todas las interfacesF clasesF librer1as $ docu entaci%nF !unto con el descriptor de despliegue del adaptador del recursoF i ple entando as1 la arquitectura de conector para un E/S particular. Se e paquetan co o fic?eros JA= con la e;tensi%n .rar Bresource adapter arc?iveC. %dulo Java EE consiste en uno o 9s co ponentes Java EE para el is o tipo de
contenedor $ un descriptor de despliegue asociado. La especificaci%n define cuatro tipos de
"1
1.3.".
Java EE A#$
El Jlti o co ponente clave de la platafor a Java EE es la A./F $a queF co o se co ent% anterior enteF inclu$e todas las bibliotecas de Java SE 9s algunas adicionales que per iten proporcionar los servicios requeridos por las aplicaciones Java EE.
Mea os una ilustraci%n con las A./s
9s i portantes $ su relaci%n con los contenedores>
2. Entorno de desarrollo
El entorno de desarrollo de aplicaciones Java EE tiene dos ele entos principalesF una ?erra ienta /DE B/ntegration Develop ent Environ entC para el desarrollo $ un servidor Java EE ""
para el despliegue $ e!ecuci%n. <9sica enteF un /DE es una aplicaci%n software que proporciona utilidades a los desarrolladores para la construcci%n de aplicacionesF tales co oF editores de c%digo fuenteF co piladoresF depuradoresF ?erra ientas de construcci%n auto 9ticas BbuildCF diagra as de clasesF etc. Ade 9s suelen incluir la posibilidad de au entar sus prestaciones a trav4s de plugDins u otros ecanis os de e;tensi%n. .ara la platafor a Java EEF los /DEs 9s conocidos son Ket<eans $ EclipseF siendo este
Jlti o es el que se utili6ar9 en el curso en su versi%n REclipse /DE for Java EE DevelopersRF que se puede descargar desde ?ttp>TTwww.eclipse.orgTdownloadsT Eclipse es un /DE escrito principal ente en JavaF lo que i plica que para e!ecutarse necesitar9 tener acceso a un J=EF esto per ite que la ?erra ienta sea independiente de la platafor a en la que se e!ecuta. Al ser una ?erra ienta de desarrolloF necesita proveer de una serie de utilidades co o co piladorF depuradorF etc. lo cual podr1a ?acerse enla6ando con el JDQ oficial. Sin e bargoF Eclipse inclu$e el Java Develop ent Tools BJDTC que proporciona una serie de utilidades entre las que destaca> :n co pilador incre ental de JavaF que i ple enta la especificaci%n del lengua!e Java. El ?ec?o de ser incre ental per ite que una ve6 reali6ada la pri era construcci%n en las siguientes s%lo se reconstru$e la parte que ?a ca biado. El co pilador clasifica los proble as encontrados en errores $ advertencias. La e;istencia de una advertencia no afecta a la e!ecuci%n $ depuraci%n del progra a. Los errores de co pilaci%n respecto a la especificaci%n del lengua!e Java sie pre se reportan co o erroresF advertenciasF errores o que directa ente se ignoren. :n asistente de c%digo. :na infraestructura de bJsqueda inde;ada que se usa en la bJsquedaF asistencia de c%digo $ refactori6aci%n. "( ientras que para el resto de proble as el desarrollador puede especificar si desea que se reporten co o
8or ateador de c%digo fuente.
El co pilador de Java de Eclipse cu ple con las especificaciones de los distintos JDQ disponibles. El desarrollador deber9 seleccionar para cada aplicaci%n el nivel de confor idad desea utili6ar. Esto provocar9 que las clases generadas por el co pilador deber9n ser e!ecutadas por un J=E del is o o superior nivel.
Si se desea co pilar en Eclipse utili6ando el co pilador oficialF se podr1a ?acer a trav4s de la ?erra ienta Ant.
:n servidor Java EE es aquel que es co patible con alguna de las especificaciones de Java EE. En este curso se va a utili6ar el Apac?e To cat +.,.; co o servidor web Java EE $ J<oss Application Server +.1.; co o servidor de aplicaciones Java EE.
"4
A'ac e Tomcat es un servidor web #TT. de c%digo abierto que i ple enta las especificaciones de Java Servlet $ JavaServer .ages BJS.CF por tanto se le puede considerar un contenedor web Java EE. En su versi%n +.,.; soporta las especificaciones Servlet (.,F JS. "." $ EL "."F por tanto es un contenedor web Java EE 7. JBoss A'lication Se"(e" o J<oss AS es un servidor de aplicaciones Java EE de tipo open source desarrollado por J<ossF que es una divisi%n de =ed #at. / ple enta las especificaciones $ servicios de un servidor de aplicaciones Java EE co pleto> EJ<F J.AF JAASF J)SF JKD/F JTAF etc.F disponiendo de J<oss0eb co o contenedor webF estando 4ste basado en Apac?e To cat. J<oss AS en su versi%n +.1.; ?a sido certificado co o i ple entaci%n co pleta de Java EE 7.
3.
apa %e&
3.1. Aplicaciones web en Java EE
3.1.1.
$ntroduccin
En la arquitectura Java EEF la capa web se encarga de recibir $ procesar las peticiones que provienen de la capa clienteF generando contenido din9 ico que puede requerir de la interacci%n con la capa de negocioF interconectandoF por tantoF la capa cliente con la l%gica de la aplicaci%n.
T1pica enteF el cliente env1a una petici%n #TT. al servidor webF que en el caso de la platafor a Java EE dispondr9 de un contenedor web. El servidor web se encarga de convertir la petici%n a un ob!eto #TT.Servlet=equestF que contendr9 toda la infor aci%n de la petici%nF $ pasarlo al co ponente web responsable de tratarlaF por e!e plo un servlet o una p9gina JS.. El co ponente web puede generar un ob!eto #TT.Servlet=esponse o pasarle la petici%n a otro co ponente web. En cualquier caso se generar9 dic?o ob!etoF que ser9 convertido por el servidor "-
web en la respuesta #TT. que se devuelve al cliente.
Entre los co ponentes web nos encontra os a los Servlets $ las p9ginas JS.. Los Servlets son clases del lengua!e de progra aci%n Java que din9 ica ente procesan peticiones $ generan respuestasL por su parteF las p9ginas JS. son docu entos basados en te;to que se e!ecutan co o Servlets pero con una apro;i aci%n Los Servlets se aco odan 9s natural para crear contenido est9tico. Aunque servlets $ p9ginas JS. pueden utili6arse de for a interca biableF cada tipo de co ponente tiene sus venta!as. e!or a las aplicaciones orientadas a serviciosF por e!e plo los puntos de 9s adecuados para la acceso o RendpointsR de los servicios web se pueden i ple entar co o servletsF $ a las funciones de control de una aplicaci%n orientada a la presentaci%n. Los JS. son generaci%n de contenido basado en lengua!es de arcado co o #T)L o E)L.
La Jlti a tecnolog1a de co ponentes web incluida en la especificaci%n de Java EE son los JavaServer 8acesF cu$o prop%sito es el de construir aplicaciones alta ente interactivas $ orientadas a la presentaci%nF para lo que generan contenido basado en lengua!es de arcado co o E#T)L.
Los co ponentes web son soportados por los servicios del contenedor webF co o gesti%n de las peticionesF concurrenciaF seguridadF $ gesti%n del ciclo de vida.
"7
3.1.2.
iclo de vida de una aplicacin 'e&
:na aplicaci%n web consta de co ponentes webF fic?eros de recursos est9ticos Bco o i 9genesCF clases de a$uda $ librer1as. El contenedor web proporciona servicios de soporte que e!oran las capacidades de los co ponentes web $ facilitan su desarrollo. Sin e bargoF para poder obtener estos serviciosF el proceso de creaci%n $ e!ecuci%n de una aplicaci%n web var1a de otras aplicaciones con clases convencionales.
El proceso de creaci%nF despliegue $ e!ecuci%n de una aplicaci%n web puede resu irse de la siguiente anera>
1. Desarrollar el c%digo de los co ponentes web ". Desarrollar el descriptor de despliegue de la aplicaci%n web. (. *o pilar los co ponentes web $ las clases de soporte referenciadas por los co ponentes. 4. @pcional ente> e paquetar la aplicaci%n en una unidad desplegable. -. Desplegar la aplicaci%n en un contenedor web. 7. Acceder a la :=L que referencia la aplicaci%n web.
3.1.3.
Mdulos 'e&
En la arquitectura Java EEF los co ponentes web $ los contenidos web est9ticos co o i 9genes se deno inan recursos web. :n recursos web. :n en la especificaci%n de Java Servlet. %dulo web es la unidad 9s pequeIa de despliegue para %dulo web Java EE se corresponde con una aplicaci%n web tal co o se define
Ade 9s de los co ponentes web $ los recursos webF un
%dulo web puede contener otros "+
fic?eros> *lases de utilidad que se e!ecutan en serverDside> para acceso a base de datosF confor es a la arquitectura de co ponentes Java<eansF etc. *lases de clientDside> applets $ otras clases de utilidad.
:n etc.
%dulo web tiene una estructura espec1fica. El directorio ra16 se deno ina Rdocu ent
rootRF en 4l es donde se sitJan las p9ginas JS.F las clases de clientDsideF los recursos web est9ticosF
El directorio ra16 contiene un subdirectorio lla ado web-inf, en el se pueden encontrar los siguientes fic?eros $ directorios> classes> es el directorio que contiene las clases de serverDside> servletsF clases de utilidad $ Java<eans. tags> un directorio que contiene fic?eros de tagF que son la i ple entaci%n de las librer1as de tags. lib> el directorio que contiene los arc?ivos JA= con las librer1as invocadas desde las clases de serverDside. Descriptores de despliegueF co o el web.; lF que es el descriptor de despliegue de la aplicaci%n webF u otros descriptores propios de tecnolog1as o servidores.
A continuaci%n se
uestra una ilustraci%n con la estructura de un
%dulo web>
"&
Si el
%dulo web no contiene ni servletsF ni filtros ni co pontentes tipo RlistenerRF entonces %dulo web s%lo
no es necesario un descriptor de despliegue de la aplicaci%n. Es decirF si el
contiene p9ginas JS. $ fic?eros est9ticos no ser9 necesario incluir un fic?ero web.; l.
:n
%dulo web puede ser desplegado co o una estructura de fic?eros sin e paquetarF lo %dulo web descrito es portableF
que es conocido co o un Re;ploded arc?iveRF o e paquetarse en un fic?ero JA= conocido co o fic?ero 0A= B0eb A=c?iveC utili6ando la e;tensi%n .war. El pudiendo ser desplegado en cualquier contenedor confor e a la especificaci%n de Java Servlet.
3.1.!.
on(igurando aplicaciones 'e&
Las aplicaciones web se configuran a trav4s de anotaciones $ de los ele entos definidos en el descriptor de despliegue de la aplicaci%n. A continuaci%n se e;ponen algunos de las principales tareas a reali6ar al configurar la aplicaci%n>
)apear las :=Ls a co ponentes web> dada una petici%n recibida por el contenedor webF "'
indicar que co ponente web debe
ane!ar la petici%n.
Declarar los fic?eros de bienvenida> son los fic?eros a utili6ar en caso de que una petici%n no apee directa ente a un co ponente web. Si no se especifica nadaF se utili6ar9 el inde;.;;; co o p9gina de bienvenida por defecto. *onfigurar par9 etros de iniciali6aci%n> se pueden configurar par9 etros a co partir entre todos los co ponentes web a trav4s de un ob!eto que representa el conte;to de la aplicaci%n. Ta bi4n se pueden indicar par9 etros para un co ponente web espec1fico. )apear errores a p9ginas de error> Se puede especificar un apeo entre el c%digo de estado
devuelto por una respuesta #TT. Bp.e!>error -,,CF o una e;cepci%n del lengua!e !ava a cualquier co ponente web. Las p9ginas JS. ta bi4n per iten especificar una p9gina en caso de error. Si se ?a definido tanto en el web.; l co o en la !spF esta Jlti a tiene precedencia. Declarar referencias a recursos> si un co ponente web usa ob!etos co o enterprise beansF data sources o web servicesF se pueden utili6ar las anotaciones de Java EE para in$ectar esos recursos en la aplicaci%n.
Ver ejemplo: hola
3.2. ecnolog!a Java "ervlets
3.2.1.
)*u+ es un ,ervlet-
La tecnolog1a Java Servlets supone la respuesta de la platafor a Java a la necesidad de generar contenido din9 ico en el servidor ante una petici%n de un cliente. :n Servlet es una clase del lengua!e de progra aci%n Java que e;tiende las capacidades de los servidores que ?ospedan aplicaciones accedidas por edio del odelo de progra aci%n (,
petici%nDrespuesta. Aunque los servlets pueden responder a cualquier tipo de respuestaF nor al ente se usan para las aplicaciones ubicadas en servidores web. .ara estas aplicaciones la tecnolog1a Java Servlet define una clases servlets especificas para #TT.. Los paquetes javax.servlet $ javax.servlet.http proporcionan las interfaces $ clases para escribir servlets. Todos los servlets deben i ple entar la interfa6 Servlet que define los GenericServletF 4todos del ciclo de vida. .ara i ple entar servicios gen4ricos se puede usar o e;tender la clase ientras que para servicios espec1ficos de tipo #TT. se puede utili6ar la clase 4todos co o doGet o doPost para ane!ar las peticiones #TT.. HttpServlet que proporciona
3.2.2.
iclo de vida de un ,ervlet
El ciclo de vida de un servlet es controlado por el contenedorF de petici%n se apea a un servletF el contenedor reali6a los siguientes pasos>
anera que cuando una
1. Si no e;iste una instancia del servletF entonces carga la clase del servletF crea una instancia e iniciali6a el servlet lla ando al ". /nvoca el 4todo init.
4todo service pas9ndole los ob!etos de petici%n $ respuesta.
Si el contenedor necesita eli inar el servlet lo finali6ar9 invocando al
4todo destroy.
3.2.3.
$niciali.acin de un ,ervlet
Despu4s de que el contenedor web cargue $ cree la instancia de la clase del servletF $ antes de que co ience a atender peticionesF es necesario iniciali6arlo. En la iniciali6aci%n se suelen leer datos de configuraci%n persistentesF se iniciali6an recursosF o reali6an actividades inicialesL para ello se puede sobreescribir el en la iniciali6aci%n. 4todo init de la interfa6 ServletF sabiendo que este 4todo ser9 invocado
(1
3.2.!.
Escri&iendo m+todos de servicio
Los servicios proporcionados por un Servlet se i ple entan a trav4s del la clase GenericServlet o los espec1ficas de otros protocolos.
4todo service de
4todo tipo do BdoGetF doPostF etc.C de la clase HttpServletF u otras
El patr%n general de un
4todo de servicio es e;traer la infor aci%n de la petici%nF acceder
a los recursos $ l%gica e;terna $ co poner la respuesta en base a la infor aci%n obtenida.
/i0
1&teniendo in(ormacin de las peticiones
:na petici%n contiene datos pasados entre un cliente $ el servlet. Todas las peticiones i ple entan la interfa6 ServletRequestF en particularF las peticiones #TT. i ple entan la interfa6 H PServletRequest que e;tiende a la anterior. Estas interfaces definen 4todos para acceder a la siguiente infor aci%n> .ar9 etros> se usan para trans itir infor aci%n entre clientes $ servlets. Atributos de tipo ob!eto> se utili6an para pasar infor aci%n entre el contenedor de servlets $ un servlet o entre servlets que colaboran. /nfor aci%n sobre el protocolo utili6ado para co unicar la petici%n $ sobre el cliente $ servidor involucrados en la petici%n. /nfor aci%n sobre locali6aci%n.
Ta bi4n se puede obtener el flu!o de entrada Binput strea C de la petici%n $ obtener los datos anual ente.
En una petici%n #TT. se pueden obtener las cabecerasF la consulta reali6adaF etc.
("
/ii0
onstruyendo respuestas
:na respuesta contiene los datos pasados del servidor al cliente. Las respuestas i ple entan la interfa6 ServletResponse que define 4todos que per iten>
:tili6ar un flu!o de salida Boutput strea C en el que enviar los datos al clienteF $a sean caracteres o datos binarios. /ndicar el tipo de contenido devuelto. .or e!e plo> set!ontent ype"#text$ht%l&'. Gestionar el buffer de respuesta al cliente. /ndicar infor aci%n de locali6aci%n co o por e!e plo la codificaci%n de caracteres.
Las respuestas a peticiones #TT. usan el ob!eto #TT.Servlet=esponse que dispone de ca pos para representar cabeceras co o el c%digo de estado Bpara indicar la ra6%n de una petici%n no satisfec?a o redirigidaC o las cooSiesF que se utili6an para al acenar infor aci%n en el clienteF co o el identificador de cliente que per ite el segui iento de su sesi%n.
Ver ejemplo: hola
3.2.".
ompartiendo in(ormacin
Los co ponentes web a veces necesitan co partir infor aci%n para reali6ar sus tareas. .ara elloF la tecnolog1a Java Servlets dispone de cuatro ob!etos de diferente alcance>
Alcance *onte;to 0eb
Clase !ava;.servlet.Servlet*onte;t
Accesi)le desde *o ponentes web dentro del conte;to web
((
Desarrollo de aplicaciones web con Java Enterprise Edition Sesi%n .etici%n .9gina !ava;.servlet.?ttp.#ttpSession Subtipo de !ava;.servlet.Servlet=equest !ava;.servlet.!sp.Jsp*onte;t .9gina JS. que crea el ob!eto *o ponentes web sesi%n *o ponentes web ane!ando la petici%n ane!ando una petici%n que pertenece a la
*o o cualquier otro ob!eto o recurso co partido es necesario controlar el acceso a estos ob!etosF 9s aJn al encontrarnos en un entorno ulti?iloF $a queF nor al enteF un contenedor web crea un ?ilo para ane!ar cada petici%n. Si se quiere garanti6ar que cada instancia de un Servlet ie bros de la instancia. Esta arca
ane!a una Jnica petici%n cada ve6F este Servlet deber1a i ple entar la interfa6 Sin(le hread)odelF asegurando as1 un acceso e;clusivo a los una soluci%n puede tener un aspecto negativo en el rendi ientoF $a que las peticiones que gestionase is a instancia se procesar1an secuencial enteL ade 9s la especificaci%n de Sevlet ".4 esta interfa6 co o RdeprecatedR.
Si real ente se necesita gestionar el acceso concurrente a los recursosF sean o no de un ServletF lo gesti%n de transacciones para datos alo!ados en siste as gestores de bases de datos.
ie bros
e!or es utili6ar las t4cnicas generales de sincroni6aci%n del lengua!e JavaF o la
3.2.2.
3iltrando peticiones y respuestas
:n filtro es un ob!eto que puede transfor ar la cabecera $ el contenido de una petici%n o una respuesta. Los filtros difieren de los co ponentes web en que 4stos nor al ente no crear una respuestaF sino que proporcionan una funcionalidad que se puede aIadir a cualquier tipo de recurso web. De esta aneraF un filtro no deber1a tener dependencias de ningJn recurso web para el cual est9 actuando co o filtro. Las principales tareas que puede reali6ar un filtro son> *onsultar la petici%n $ actuar en consecuencia. <loquear el par petici%nDrespuesta. )odificar las cabeceras $ datos de la petici%n $To la respuesta. .ara ello proporciona una
(4
versi%n personali6ada de la petici%n o la respuesta. /nteractuar con recursos e;ternos.
Las aplicaciones de los filtros inclu$en> autenticaci%nF loggingF conversi%n de i 9genesF co presi%n de datosF encriptaci%nF transfor aci%n de E)LF etc.
Se puede configurar un recurso web para ser filtrado por una cadena de ceroF uno o instancia cuando el contenedor carga el co ponente.
9s
filtros en un orden espec1fico. Esta cadena se especifica cuando la aplicaci%n se despliega $ se
Las tareas involucradas para el uso de filtros son> .rogra ar el filtro> un filtro es una clase que i ple enta la interfa6 *ilterF cu$o principal es do*ilter en el que se deben e!ecutar las tareas del filtro. .rogra ar la petici%n o respuesta personali6ada> e;isten la respuesta. .ara uc?as for as de odificar una 4todo
petici%n o una respuestaF por e!e plo aIadiendo atributos a la petici%n o insertando datos en odificar los flu!os de entrada o salidaF se suele utili6ar un ob!eto tipo RwrapperR o envoltorio siguiendo el patr%n R0rapperR o el RDecoratorR. Especificar la cadena de filtros para cada recurso web> un contenedor web utili6a el no bre o un patr%n :=L. Los filtros se invocan en el orden en el que el lista de apeo
de filtros para decidir qu4 filtros aplicar a cada recurso webF para lo que puede utili6ar un apeo aparece en la apeos del 0A=F dentro del descriptor del despliegue. Ade 9sF es necesario
especificar c% o se aplica a las peticiones> s%lo cuando viene de una petici%n directaF s%lo cuando proviene de un RforwardRF s%lo cuando se utili6a un RincludeRF o s%lo cuando se est9 utili6ando un filtro. ecanis o de errorF pudiendo indicarse varios tipos de aplicaci%n al is o
Ver ejemplo: holaFiltros
(-
3.2.4.
$nvocando otros recursos 'e&
:n co ponente web puede invocar otros recursos web de dos for as> directa e indirecta ente. :n co ponente web invoca a otro indirecta ente cuando inclu$e su :=L dentro de la respuesta devuelta al cliente.
La invocaci%n directa se produce
ientras que el co ponente web se est9 e!ecutandoF
e;istiendo dos posibilidadesF que el co ponente web inclu$a el contenido del otro recursoF o que le trans ita el flu!o e infor aci%n de la petici%n.
.ara invocar a otro recurso disponible en el servidor pri ero se debe obtener un ob!eto Request+ispatcherF $a sea de la petici%n o del conte;to web. Dependiendo de donde se ?a$a obtenido ser9 necesario indicar el ca ino de acceso al recurso de for a relativa Bsi se obtiene de la petici%nC o de for a absoluta Bsi se obtiene del conte;to webC.
/i0
$ncluyendo otros recursos en la respuesta
#abitual ente es Jtil incluir otro recurso web en la respuestaF por e!e plo partes est9ticas a incluir co o un anuncioF infor aci%n de cop$rig?tF etc. .ara ello es necesario invocar al include "request, response' del ob!eto Request+ispatcher. 4todo
Si el recurso es un co ponente webF el efecto de la inclusi%n es enviar la petici%n al co ponente $ e!ecutarloF per itiendo que escriba infor aci%n en el cuerpo de la respuestaF pero no que ca bie infor aci%n referente a las cabeceras.
(7
/ii0
5rans(iriendo el control a otro componente 'e&
En algunas aplicaciones es necesario procesar una petici%n en
9s de un pasoF de
anera
que un co ponente puede ?acer un procesa iento preli inar $ otro subsiguiente para generar la respuestaF cu$a invocaci%n puede depender de ese procesa iento preli inar.
.ara transferir el control a otro co ponente web se debe invocar el
4todo forward
"request, response' del Request+ispatcher. Es necesario reseIar que al ?acer estoF la :=L de la petici%n ca biar9 a la del recurso invocado. Ade 9s este tipo de transferencia solo puede ?acerse si no se ?a accedido previa ente a los ob!etos Servlet,utputStrea% o Print-riterF es decirF si no se a e pe6ado a co poner una respuestaF $a que esta deber1a ser construida por el co ponente al que se transfiere.
Ver ejemplo: holaServlets
3.2.6.
Manteniendo el estado del cliente
)uc?as aplicaciones requieren que una serie de peticiones de un cliente est9n asociadas entre s1F de anera que e;ista un estado asociado al clienteF que se deno ina sesi%n. Debido a queF antiene infor aci%n de la sesi%nF nor al enteF las peticiones utili6an el protocolo #TT.F que no ecanis os para i ple entarlas.
la tecnolog1as Java Servlet ?a tenido que proporcionar una A./ para gestionar las sesiones $
Las sesiones se representan por el ob!eto HttpSessionF que est9 accesible (etSession de un ob!eto petici%n. Este sino crea una nueva.
ediante el
4todo
4todo per ite acceder a la sesi%n asociada a la petici%n o
(+
:na ve6 que se dispone de la sesi%nF se le pueden asociar atributos de tipo ob!eto por no breF de $a sea en la anera que se ?ar9n accesibles a todos los co ponentes web que accedan a esa sesi%nF is a petici%n o en peticiones sucesivas dentro de la is a sesi%n.
Debido a que no ?a$
anera de que un cliente indique por #TT. que no necesita
9s la
sesi%nF cada sesi%n tendr9 un tie po de vida asociado Bti eoutC que puede ser accedido $ configurado en el propio ob!eto o ta bi4n a trav4s del descriptor de despliegue para indicar un tie po por defecto. Ta bi4n se dispone de un liberando cualquier dato asociado. 4todo invalidate que per ite ter inar la sesi%n
:n contenedor web puede utili6ar diferentes identificador puede estar
ecanis os para asociar una sesi%n con un
usuario. Todos ellos se basan en pasar un identificador entre el cliente $ el servidor. Este antenido en el cliente co o cooSie o puede ser incluido por el co ponente web en cada :=L que se devuelve al cliente Breescritura de :=LC.
Ver ejemplo: holaSesion
3.2.7.
3inali.ando un ,ervlet
*uando un contenedor de servlet deter ina que un servlet debe ser eli inado Bpor e!e plo cuando el contenedor requiere e oria o se est9 apagandoCF el contenedor invoca el 4todo destroy de la interfa6 Servlet. En ese 4todo el progra ador deber9 liberar los recursos asociados al
servlet $ dar persistencia a cualquier dato que se requiera.
En principioF la invocaci%n a destroy deber1a ?acerse cuando todas las peticiones de servicio se ?a$an co pletadoF pero podr1a ?aber circunstancias en las que esto podr1a no cu plirse Bpor e!e ploF por requerir un tie po superior al esperado o Rde graciaRCF en ese caso es necesario (&
asegurarse que todos los ?ilos que todav1a est9n de diferentes ecanis os para asegurarlo>
ane!ando peticiones se co pletenF disponi4ndose
)antener un registro de los ?ilos que est9n e!ecutando el
4todo service en cada
o ento.
.roporcionar un s?utdown li pioF para lo que se deber9 notificar a los duraci%n el s?utdown $ esperar a que ter inen. Tener un pool de
4todos de larga
4todos de larga duraci%nF que pregunten por el s?utdown $ si es
necesario paren $ ter inen.
3.3. 5ecnolog8a Java,erver #ages
La tecnolog1a JavaServer .ages BJS.C per ite crear contenido webF tanto con co ponentes est9ticos co o din9 icosF de una apro;i aci%n anera sencilla. .ara elloF esta tecnolog1a pone a disposici%n del desarrollador todas las capacidades de la tecnolog1a Java Servlet pero proporcionando una 9s natural para crear el contenido est9tico.
Las principales caracter1sticas de esta tecnolog1a son> :n lengua!e para desarrollar p9ginas JS.F que son docu entos de te;to que describen c% o procesar una petici%n $ construir una respuesta. :n lengua!e de e;presiones para acceder a ob!etos del lado del servidor. )ecanis os para definir e;tensiones al lengua!e JS..
3.3.1.
)*u+ es una p9gina J,#-
:na p9gina JS. es un docu ento que contiene dos tipos de te;to> datos est9ticosF que pueden ser e;presados en cualquier for ato basado en te;to B#T)LF SMGF 0)L $ E)LCF $ ele entos JS. que per iten construir el contenido din9 ico. ('
La e;tensi%n reco endada para un fic?ero de una p9gina JS. es .!sp. La p9gina puede estar co puesta de un fic?ero que inclu$a otros fic?eros que pueden contener una p9gina JS. co pleta o un frag ento de una p9gina JS.. La e;tensi%n reco endada para un fic?ero de un frag ento es .!spf.
3.3.2.
iclo de vida de una p9gina J,#
:na p9gina JS. atiende peticiones co o un servletF por tantoF el ciclo de vida $ las capacidades est9n deter inadas por la tecnolog1a Java Servlet.
uc?as de
*uando una petici%n se
apea a una p9gina JS.F el contenedor web co prueba si el servlet
de la p9gina JS. est9 obsoleto respecto a la p9gina JS.. En caso afir ativoF el contenedor traduce la p9gina JS. a una clase Servlet $ co pila la clase. .or tantoF una de las venta!as de las p9ginas JS. sobre los servlets es queF durante el proceso de desarrolloF el proceso de construcci%n se reali6a auto 9tica ente.
Durante la fase de traducci%nF cada tipo de dato de la p9gina JS. se trata de for a diferente. Los datos est9ticos se traducen en c%digo que per ite incluir los datos en el flu!o de respuestaF ientras que los ele entos JS. se tratan de la siguiente anera>
Las directivas se utili6an para controlar co o el contenedor web traduce $ e!ecuta la p9gina JS.. Los ele entos de scripting se insertan en la clase servlet de la p9gina JS.. Si se utili6a el lengua!e de e;presiones se generan los par9 etros para lla ar al evaluador de e;presiones JS.. Los ele entos tipo jsp./set0(et1Property se convierten en lla adas a co ponentes Java<eans. 4todos de los
4,
Los ele entos jsp./include0forward1 se convierten en invocaciones a la A./ de Servlet. El ele ento jsp.plu(in se convierte en lengua!e de activaci%n de un applet. Las etiquetas personali6adas se convierten en lla adas al i ple ente cada etiqueta.
Java
arcado espec1fico del navegador para la
ane!ador de etiquetas que
Las fases de traducci%n $ co pilaci%n pueden producir errores que se observan s%lo cuando la p9gina es solicitada la pri era ve6F en este casoF el servidor devolver9 una JasperE;ception $ un ensa!e de la p9gina JS. $ la l1nea en la que ocurri% el error.
:na ve6 que la p9gina ?a sido traducida $ co piladaF el servlet generado sigue el ciclo de vida nor al de esta tecnolog1a> 1. Si no e;iste una instancia del servlet de la p9gina JS.F el contenedor carga la claseF crea una instancia $ la iniciali6a lla ando al ". Se invoca el 4todo !sp/nit.
4todo U!spServiceF al que se le pasan los ob!etos de petici%n $ respuesta.
Se pueden controlar diferentes par9 etros en la e!ecuci%n de una p9gina JS. utili6ando las directivas de p9ginaF co o las de control del buffer de salida o el ane!o de los errores. Este control de errores tiene precedencia sobre el indicado en el descriptor de despliegue de la aplicaci%n $ per ite indicar una p9gina de error a la que redirigir en caso de ocurra una e;cepci%n durante la e!ecuci%n.
En las p9ginas utili6adas co o p9ginas de error es ?abitual incluir la directiva> 234 pa(e is5rrorPa(e67true7 38. 3ue ?ace disponible un ob!eto de tipo javax.servlet.jsp.5rror+ata a la p9gina de anera que se pueda obtener $ ostrar infor aci%n sobre el error ocurrido.
41
3.3.3.
reando contenido est9tico
*rear contenido est9tico en una p9gina JS. es tan si ple co o escribirlo en una p9gina que consistiese Jnica ente en ese tipo de contenido. Este contenido est9tico puede ser e;presado en cualquier for ato de te;to> #T)LF 0)L $ E)L. Al principio de la p9gina se inclu$e una directiva con el atributo contentT$pe para indicar al navegador el tipo de contenido est9tico que debe interpretar. Ta bi4n se puede indicar la codificaci%n de la respuesta ?aciendo uso de esa is a directiva>
<%@ page contentType="text/html; charset= TF!"" %#
3.3.!.
reando contenido din9mico
Se puede crear contenido din9 ico accediendo a las propiedades de los ob!etos. Estos ob!etos pueden ser> / pl1citos> son los que crea el contenedor web $ contienen infor aci%n sobre la petici%nF p9ginaF sesi%n o aplicaci%n. Espec1ficos de la aplicaci%n> en uc?as ocasionesF el co porta iento de la aplicaci%n se ediante etiquetas
encapsula en ob!etos de negocio. Estos ob!etos pueden ser accedidos est9ndar de JS. o ?aciendo uso de scriptlets incrustados en la p9gina JS..
*o partidos> debido a que las p9ginas JS. se e!ecutan co o servlets en
ulti?iloF es
necesario garanti6ar un acceso concurrente correcto a los ob!etos co partidosF de for a an9loga a co o se indic% con los propios servlets. La directiva is hreadSafe per ite indicar si las peticiones a un is o !sp pueden atenderse de for a concurrente Bvalor trueF que es el co porta iento por defectoC o secuencial Bvalor falseF que i plicar1a generar un servlet que i ple entase la interfa6 Sin(le hread)odelC.
El siguiente diagra a indica los distintos alcances que pueden ser aplicados a cualquier ob!eto creado> 4"
En los siguientes apartados de esta secci%n se ver9n los diferentes a los ob!etos $ co ponentesF generando as1 el contenido din9 ico.
ecanis os para acceder
3.3.#.
$sando scripting en p%ginas J"&
Los ele entos de scripting per iten utili6ar sentencias del lengua!e de progra aci%n Java en las p9ginas JS.. .or tantoF se podr9n reali6ar tareas co o acceder a ob!etosF definir gestionar el flu!o de control de la anera convencional en el lengua!e Java. 4todos $
En teor1aF el uso de scripting en las p9ginas JS. deber1a ser sustituido por el uso de etiquetas de librer1asF en particular la JSTLF pero en ocasiones se ?ace necesario utili6ar esta alternativa. AJn as1F se proporciona un ecanis o que pro?1be el uso de scripting en un grupo de JS. a trav4s de la inclusi%n de un ele ento scriptin(-invalid en el descriptor de despligue.
El lengua!e de scripting por defecto es JavaL aJn as1 se podr1a utili6ar otro lengua!eF para lo cual ?abr1a que incluir una directiva infor ando de esta circunstancia> 4(

<%@ page lang$age="scripting!lang$age" %#
Debido a que los ele entos de scripting i plican el uso de sentencias JavaF puede ser necesario i portar clases $ paquetes usados en la p9gina. .ara ello se dispone de una directiva de i portaci%n>
<%@ page import="%$lly!&$ali%ie'!classname( pac)agename*+" %#
Se pueden incluir tres bloques o ele entos para el uso de scripting> Declaraciones JS.> se usan para declarar variables $ sobreescribir los 4todos. Estas declaraciones se
incluir9n en la clase servlet generada a partir de la p9gina JS.F per itiendoF por e!e ploF 4todos jsp9nit $ jsp+estroy. Su sinta;is es>
<%, scripting!lang$age!'eclaration %#
Scriptlets JS.> per iten incluir cualquier frag ento de c%digo con sentencias Java v9lidasF que ser9n insertadas en el 4todo del servicio en el servlet de la p9gina JS.F segJn la ubicaci%n en la que se ?a$an definido en la propia p9gina. Su sinta;is es>
<% scripting!lang$age!expression %#
E;presiones JS.> se utili6an para insertar el valor de una e;presi%n basada en el lengua!e de scripting en el flu!o de datos que se devuelve al clienteF para lo que el valor de la e;presi%n se convierte a String. Su sinta;is es>
<%= scripting!lang$age!expression %#
3.3.2.
:sando etiquetas en J,#
Las etiquetas son ele entos que pueden incrustarse en una p9gina JS. $ que per iten encapsular tareas recurrentes de todo tipo. Estas etiquetas est9n agrupadas en librer1as que pueden ser definidas por el usuario.
44
JavaServer .ages Standard Tag Librar$ BJSTLC es un con!unto de librer1as que inclu$en funcionalidades co unes a condicionales para uc?as aplicaciones JS.. JSTL inclu$e etiquetas para iteraci%nF anipulaci%n de docu entos E)LF ane!ar el flu!o de controlF
internacionali6aci%nF acceso a bases de datos usando S3L $ otras funciones co unes.
Las etiquetas pueden tener dos for atos distintos>
<pre%ix:tag attr-="val$e" *** attr.="val$e" /#
<pre%ix:tag attr-="val$e" *** attr.="val$e" # /o'y </pre%ix:tag#
Antes de utili6ar un con!unto de etiquetas es necesario indicar en la p9gina JS. que se va a utili6ar una librer1a de etiquetas a trav4s de la directiva correspondiente.
<%@ tagli/ pre%ix="tt" 0tag'ir=/123!4.F/tags/'ir 5 $ri= 64 7 %#
Si se utili6a una :=/ absoluta no ser9 necesario incluir un ele ento taglib en el web.; l. EstoF por e!e ploF se suele ?acer con las JSTL est9ndares. Ade 9sF es necesario ?acer accesibles a la aplicaci%n web las clases que i ple entan la librer1a deter inada. Esto puede ?acerse inclu$4ndolas en el 0A= o estando disponibles en un directorio co Jn del servidor de aplicaciones en el que se desplegar9 la aplicaci%n. En el caso de las librer1as JSTL suelen estar presentes en el servidor.
3.3.4.
El lenguaje de e;presiones uni(icado
A partir de la especificaci%n de JS. ".1 se dispone del lengua!e de e;presiones unificadoF
4-
que representa la uni%n del lengua!e de e;presiones ofrecido por JS. "., $ el creado para la tecnolog1a JavaServer 8aces.
Este lengua!e per ite incluir e;presiones que se evalJan de for a in ediata o apla6adaF acceder a ob!etos i pl1citos que apean los distintos alcances de una aplicaci%n webF utili6ar operadores $ palabras reservadas para definir el valor de la e;presi%nF etc.
Estas e;presiones pueden utili6arse directa ente en el cuerpo del docu ento o en tags que acepten e;presiones en sus atributos.
:;,empty param*$sername< :;page=ontext*re&$est*context9ath< :;sessionScope*cart*n$m/er>%4tems<
Ver ejemplo: hola8S9
3.3.6.
omponentes Java<eans
Los co ponentes Java<eans son clases Java que pueden ser f9cil ente reutili6adas entre aplicaciones. *ualquier clase Java que siga unas ciertas convenciones de diseIo ser9 un co ponente Java<ean.
La tecnolog1as JS. soporta directa ente este tipo de co ponentes a trav4s de sus ele entos del lengua!eF per itiendo acceder a los beans definidos a trav4s de estas clases de una sencilla. anera
Las convenciones de diseIo i plican que> 47
Las propiedades pueden ser de lectura $ escrituraF de s%lo lectura o de s%lo escritura. .ueden ser si plesF es decirF contienen un valor si pleF o inde;adasF representando un arra$ de valores. Las propiedades deben ser accesibles a trav4s de unos sinta;is>
9roperty=lass get9roperty?@ ; *** < set9roperty?9roperty=lass pc@ ; *** <
4todos de acceso con la siguiente
Se debe definir un constructor sin par9 etros.
.ara indicar que la p9gina va a utili6ar un co ponente Java<ean se debe utili6ar un ele ento jsp.use:ean co o sigue>
<jsp:$se3ean i'="/ean.ame" class="%$lly!&$ali%ie'!classname" scope="scope"/#
Se debe indicar el alcance del ob!eto que puede ser> applicationF sessionF request o pa(eF si no e;istiese el bean se crear1a.
:na ve6 instanciado el beanF se puede acceder a sus propiedades utili6ando el ele ento jsp.setProperty para asignarles valor $ jsp.(etProperty para consultarlo. .ara consultar ta bi4n es posible utili6ar una e;presi%n EL.
*uando se est9n desarrollando beans para procesar datos de un for ularioF se puede seguir un patr%n de diseIo ?aciendo coincidir los no bres de las propiedades de los beans $ de los ele entos input del for ulario. Esto per ite que el si ple ente inclu$endo una sentencia del tipo> otor de JS. asigne todos los valores entrantes del for ulario que son parte del ob!eto de la petici%nF a las propiedades correspondientes en el bean
<jsp:set9roperty name="$ser" property="+"/#
4+
Esto se consigue gracias a un proceso deno inado introspecci%nF que per ite a una clase e;poner sus propiedades ba!o petici%n. Esta introspecci%n es gestionada por el i ple enta a trav4s del no bresF se podr1a conseguir el apeo indicando individual ente cada propiedad> otor de JS. $ se ecanis o de refle;i%n de Java. Si no e;istiese una correspondencia de
<jsp:set9roperty name="$ser" property="a''ress" param="parameter.ame" /#
Esta caracter1stica de creaci%n de beans por introspecci%n puede ser procesar for ularios #T)L>
u$ Jtil a la ?ora de
La p9gina JS. inicial per ite crear un bean a partir de un for ularioF en ocasiones se les suele deno inar R8or <eanRF $ lo coloca en la petici%nF que es enviada a un servletF este Jlti o puede recuperar el bean $ por tanto la infor aci%n del for ulario de una anera 9s sencilla.
El servletF dentro de sus responsabilidades de procesa ientoF puede JS. a la que se redirige el flu!o $ que per ite obtener la respuesta devuelta al cliente.
odificar las
propiedades del bean $ crear otros beans adicionales. Todos ellos podr1an ser pasados a una p9gina
4&
Ver ejemplo: hola san'o3eans
3.3.7.
=eutili.acin de contenido en p9ginas J,#
E;isten diferentes
ecanis os para reutili6ar contenido JS. en una p9gina>
La directiva include> es procesada cuando la p9gina JS. se traduce al servletF por lo que su efecto es insertar el te;to contenido en otro fic?eroF $a sea est9tico o din9 icoF en la p9gina JS. con el include. La sinta;is de la directiva es>
<%@ incl$'e %ile="%ilename" %#
Definir includes en el descriptor de despliegue para un grupo de p9ginas JS.. S%lo pueden colocarse al principio de la p9gina include-prelude o al final include-coda.
:tili6ar el ele ento jsp.includeF el cual es procesado cuando la p9gina se e!ecuta. Si inclu$e un recurso est9ticoF si ple ente se inserta su contenido en la p9gina JS. lla anteF incluido en la respuesta de la p9gina lla ante. ientras que si es din9 icoF la petici%n se env1a al recurso incluido que se e!ecutaF siendo el resultado
<jsp:incl$'e page="incl$'e'9age" /#
3.3.1>.
5rans(iriendo el control a otro componente 'e&
Al igual que en los servletsF ta bi4n se per ite transferir el control a otro co ponente a
4'
trav4s del ele ento> jsp.forward. Es necesario que no se ?a$a enviado ningJn dato al cliente antes del forwardF $a que de otro odo se obtendr9 una e;cepci%n.
<jsp:%orAar' page="/main*jsp" /#
Tanto en el caso de usar jsp.forwardF co o jsp.include, el contenido de la petici%n se pasa al !sp al que se redirige. Ade 9s es posible pasar nuevos par9 etros utili6ando el ele ento jsp.para%.
Ver ejemplo: hola8S9
3.'. Ar()itect)ra de la capa web
3.!.1.
$ntroduccin
:na ve6 vistas las principales caracter1sticas de las tecnolog1as Java Servlets $ JavaServer .agesF se est9 en disposici%n de plantear la arquitectura correspondiente a la capa web dentro de una aplicaci%n web co pleta.
En los co ien6os de la platafor a Java EEF al s%lo disponer de la tecnolog1a ServletF era a trav4s de esta tecnolog1a con la que se defin1an los servlets capaces de atender las peticiones llegadas desde la capa cliente. Al aparecer JS.F esta tecnolog1a se convirti% en la predo inante a la ?ora de i ple entar la capa webF principal enteF por el ?ec?o de proporcionar un enfoque natural para la creaci%n del contenido devuelto al cliente. 9s
Las arquitecturas basadas en la tecnolog1a JS. pueden dividirse en dos apro;i acionesF -,
lla adas arquitectura JS. )odelo 1 $ )odelo "F que difieren esencial ente en el lugar donde se reali6a la a$or parte del procesa iento de las peticiones.
3.!.2.
J,#? Modelo 1
En la arquitectura )odelo 1F la p9gina JS. por s1 solaF es responsable de procesar las peticiones entrantes $ responder al cliente. Todav1a e;iste separaci%n entre la presentaci%n $ el contenidoF porque todos los accesos a los datos son llevados a cabo ediante Java <eans.
Aunque el )odelo 1 deber1a ser perfecta ente apropiado para aplicaciones si plesF puede que no sea deseable para aplicaciones co ple!as. El uso indiscri inado de esta arquitectura nor al ente dirige al progra ador a escribir una cantidad u$ i portante de scriptlets de JS. de c%digo Java dentro de las p9ginas JS.F especial ente si ?a$ una cantidad significante de procesa iento de peticiones dentro de la i ple entaci%n. A pesar de que esto no podr1a parecer un proble a para los desarrolladores JavaF es real ente un aspecto i portante si las p9ginas JS. son creadas $ antenidas por diseIadores Blo cual es lo nor al en grandes pro$ectosC.
Ver ejemplo: mo'elo-
-1
3.!.3.
J,#? Modelo 2
La arquitectura )odelo " es una apro;i aci%n ?1brida para servir contenido din9 icoF $a que co bina el uso tanto de JS. co o de servlets. .or lo tantoF coge las venta!as de a bas tecnolog1asF usando JS. para generar la capa de presentaci%n $ los servlets para llevar a cabo las tareas de procesa iento. En esta arquitecturaF el servlet actJa co o controlador $ est9 encargado del procesa iento de las peticiones $ la creaci%n de los beans u ob!etos usados por el JS.F as1 co o de to ar las decisiones acerca de la pr%;i a p9gina JS. que se va a ostrar.
Es i portante darse cuenta de que no e;iste procesa iento en las p9ginas JS.. Ellas s%lo son responsables de e;traer los ob!etos o los beans que deber1an ?aber sido previa ente creados por el servletF $ de e;traer la infor aci%n din9 ica que estos ob!etos traen e insertarla en sus plantillas est9ticas. Esta apro;i aci%n reali6a una separaci%n 9s li pia entre la presentaci%n $ el contenidoF deli itando los roles $ las responsabilidades de los desarrolladores $ de los diseIadores 0eb.
@tra de las venta!as de esta apro;i aci%n es que la capa de control presenta un punto de entrada Jnico a la aplicaci%nF per itiendo una gesti%n del estadoF seguridad $ presentaci%n unifor e $ f9cil de antener. 9s
Aunque el )odelo " no no bra e;pl1cita ente los ele entos del )odeloDMistaD *ontroladorF en realidad se apro;i a uc?o a esta arquitectura. De ?ec?oF en uc?os 9 bitosF se
-"
usa )M* o )odelo " indistinta ente.
Desde un punto de vista te%ricoF la arquitectura )odeloDMistaD*ontrolador B)M*C se basa en aislar la l%gica de do inio de la entrada $ la presentaci%n. .ara conseguir esto la aplicaci%n se divide en tres capasF cada una con unas responsabilidades $ tareas espec1ficas> El odelo representa los datos de negocioF con la l%gica de negocio u operaciones que odificaci%n de estos datos de negocio. El odelo notifica a los odelo. Ade 9sF odelo.
gestionan el acceso $ la
visores cuando ca bia $ per ite a estos visores consultar el estado del
per ite al controlador acceder a la funcionalidad de la aplicaci%n encapsulada en el La vista presenta el contenido del odelo. @btiene datos del
odelo $ especifica co o se odelo. :na
presentan los datos. Actuali6a la presentaci%n de los datos cuando ca bia el vista puede trans itir la entrada de un usuario al controlador.
El controlador define el co porta iento de la aplicaci%n. Atiende las peticiones de usuario $ selecciona las vistas para la presentaci%n. /nterpreta las entradas del usuario $ las en acciones a ser reali6adas por el son peticiones #TT. GET $ .@ST. :n controlador selecciona la vista a las interacciones del usuario $ el resultado de las operaciones del odelo. apea odelo. En una aplicaci%n webF las entradas del usuario ostrar basado en
(i)
*mplementando el controlador
En la platafor a Java EEF el controlador suele i ple entarse a trav4s de un clase servlet. Este servlet puede ser JnicoF de anera que se define un punto de entrada co Jn para todas las peticiones de la aplicaci%nF siguiendo as1 el patr%n 8ront *ontroller.
Este enfoque per ite concentrar la gesti%n de la seguridadF los errores $ la asignaci%n de recursos a las peticiones Bpor e!e ploF cone;iones a bases de datosCF sin e bargoF concentrar todas las peticiones en una Jnica clase i plica incluir una gran cantidad de procesa iento dependiente de la petici%n a tratarF gener9ndose un c%digo con una ba!a co?esi%n $ poco escalable $ antenible.
-(
.ara evitar estos proble asF pueden adoptarse diferentes soluciones que controlador.
e!oran la calidad del
10
,'itc@ A case
Si se tiene un nJ ero de tipos de peticiones relativa ente ba!oF cuatro o cincoF es posible i ple entar el controlador con una Jnica clase que dispone de un bloque switc?Dcase en el que en funci%n de un valorF se selecciona el tipo de petici%n a tratar.
El valor que identifica la petici%n puede ser pasado co o par9 etro a trav4s de un ca po oculto del for ulario que genera la petici%nF o puede venir codificado en la propia url de la petici%n.
En cualquier casoF se podr9 obtener un valor que indique el bloque case a e!ecutar que no deber1a i plicar una gran cantidad de l%gica.
Ver ejemplo: mo'eloB
20
#atrn
omando
Si el nJ ero de tipos de peticiones es alto o requieren de una gran cantidad de l%gicaF se suele utili6ar el patr%n *o ando. Este patr%n i plica la definici%n de una clase espec1fica para cada petici%n o acci%nF que presenta una interfa6 unifor e a trav4s de la i ple entaci%n de un el co ponente de la vista a cargar. 4todo cu$a invocaci%n da co o resultado la e!ecuci%n de la l%gica de negocioF $ cu$o resultado deter ina
-4
Al igual que en el enfoque switc?DcaseF es necesario indicar al controlador que co ando es el que debe e!ecutarse a consecuencia de una petici%n deter inada. .ara elloF siguen siendo v9lidos los ecanis os de paso de par9 etros o codificaci%n en la url de la petici%n. En funci%n del valor de la acci%n a reali6arF se instanciar9 la clase del co ando a e!ecutarF nor al ente ?aciendo uso de una 89brica.
La siguiente ilustraci%n
uestra un resu en de la arquitectura )odelo " T )odeloDMistaD and.
*ontrolador enriquecida con el uso de los patrones de diseIo 8ront *ontroller $ *o
3.!.!.
Apac@e ,truts
Apac?e Struts es un fra eworS de c%digo abierto para el desarrollo de aplicaciones web Java EE.
Su ob!etivo es crear un entorno de desarrollo de aplicaciones con un alto grado de escalabilidad $ antenibilidad. .ara elloF i ple enta el patr%n de diseIo )odeloDMistaD --
*ontrolador a trav4s del uso de tecnolog1as est9ndarF co o ServletsF Java<eansF =esource<undlesF E)LF librer1as de etiquetasF entre otrasF proporcionando al desarrollador un arco de traba!o con un con!unto de clases $ utilidades que per iten $ facilitan la creaci%n de aplicaciones web.
A continuaci%n se ver9n los aspectos $ co ponentes
9s i portantes que aporta Struts. *on
fines did9cticos se ?a utili6ado la versi%n Struts 1.( co o base de la e;plicaci%n.
(i)
Action"ervlet
Struts proporciona un controlador a trav4s de la clase ;ctionServletF que ?ereda de HttpServlet. Esta clase se instancia al iniciar la aplicaci%n $ carga toda la infor aci%n sobre los apeos B;ction)appin(C que deter inan el control de flu!o. De esta de aneraF todas las peticiones que llegan desde el cliente son recibidas por el controlador ;ctionServletF $ en base a la infor aci%n apeos reali6a una serie de actividades pasando el flu!o de control al co ponente adecuado Bnor al ente un ;ctionC.
-7
(ii)
Action+apping
La infor aci%n sobre el
apeo o control de flu!o est9 representada a trav4s de la clase
;ction)appin(. Esta clase encapsula infor aci%n de configuraci%n que nor al ente es obtenida a trav4s del procesa iento de un E)L.
Los ele entos
9s i portantes que se inclu$en en el arc?ivo de configuraci%n son>
Vfor DbeansW> contiene la definici%n de los beans de for ulario B ;ction*or%C que podr9n ser instanciados en la aplicaci%n. VglobalDforwardsW> define instancias de la clase ;ction*orward que pueden utili6arse a nivel global para dirigir el flu!o de la aplicaci%nF identific9ndolas a trav4s de un no bre l%gico. VactionD appingsW> per ite definir las acciones del siste a en base a un con!unto de propiedades> t$pe> no bre co pleto de la clase que i ple enta la acci%n. na e> no bre del bean de for ulario que se va a usar en esta acci%n. pat?> define la ruta de la petici%n que i plica e!ecutar la acci%n. validate> per ite indicar si se deben reali6ar las validaciones previas a la e!ecuci%n. forward> para cada acci%n se pueden definir posibles ca inos de flu!o.
Si ple ente se ?an descrito las propiedades
9s relevantes. .ara la relaci%n co pletaF se
puede consultar el DTD que debe cu plir el arc?ivo de configuraci%n.
El arc?ivo E)L suele lla arse strutsDconfig.; lF aunque es posible utili6ar variosF que pueden definir %dulos o do inios distintos dentro de la aplicaci%n.
-+
(iii)
Action,orm
:na de las principales tareas en el desarrollo de una aplicaci%n web es ser capa6 de gestionar la entrada del usuarioF ?ec?a nor al ente utili6ando etiquetas de for ularios #T)L. Struts proporciona la clase ;ction*or% co o ecanis o de captura $ validaci%n de la entradaF 9s p9ginas. representando cada clase que e;tienda de ;ction*or% un for ulario de una o
Las clases ;ction*or% no requieren de la i ple entaci%n de ningJn definen propiedades $ sus 4todos de acceso. De esta
4todo espec1ficoF
pero suelen seguir las convenciones de codificaci%n de los co ponentes Java<eansF es decirF aneraF el fra eworS de Struts es capa6 de asignar los par9 etros de la petici%n a las propiedades del bean de for ularioF a trav4s de introspecci%nF validarlos $ si todo es correctoF pasarlos a la acci%n Bclase ;ctionC que debe tratar la petici%n.
:n ;ction*or% puede ser utili6ado por una o
9s acciones. .ara elloF si ple ente es
necesario indicarlo en la definici%n del ;ction)appin( de la acci%n. *uando el flu!o de control pase a la acci%nF 4sta tendr9 disponible una instancia del ;ction*or% indicado con la infor aci%n de los par9 etros introducida por el usuario. La acci%n puede recuperar esta infor aci%n para interaccionar con el odelo e incluso puede odificarla co o consecuencia de su e!ecuci%nF $a ecanis os $ etiquetas ?abituales de queF al seguir nor al ente las convenciones Java<eansF el ;ction*or% puede ser utili6ado para pasar infor aci%n a la vistaF la cual acceder9 a trav4s de los los beans.
En cuanto a la validaci%nF la clase ;ction*or% inclu$e el flu!o de control a la acci%n. Este
4todo validate, que es invocado
por el controlador despu4s de que se ?a$an rellenado las propiedades del bean $ antes de pasar el 4todo tiene una i ple entaci%n por defecto que devuelve nullF que indica que no se ?an producido errores de validaci%n $ que se puede invocar a la acci%nL el desarrollador puede sobreescribirlo reali6ando las validaciones que considere apropiadas $ devolviendo un listado de ;ction5rrors en caso de que se encuentren proble as.
-&
:na apro;i aci%n co Jn es reali6ar validaciones iniciales usando el luego ane!ar la validaci%n de la l%gica de negocio desde el ob!eto ;ction.
4todo validate, $
Struts proporciona el plugDin Struts Malidator que contiene un con!unto de reglas de validaci%n b9sicas $ que puede ser a pliadas con facilidad.
/iv0
Action
La clase ;ction es la encargada de procesar las solicitudes. El controlador deber9 evaluar la infor aci%n sobre la petici%n $ en base a la infor aci%n sobre los es la que debe tratarlaF invocando al apeosF decidir qu4 clase ;ction 4todo recibe tanto los 4todo execute de la clase. Este
ob!etos que representan la petici%n $ la respuesta BHttpServletRequest $ HttpServletResponse para una petici%n ?ttpCF co o un ob!eto ;ction*or% con la infor aci%n de los par9 etros pasados por el usuario $ el ob!eto ;ction)appin( que le facilitar9 la tarea de reenv1o del control a otra acci%n o a un co ponente de la vista.
T1pica enteF en el
4todo execute se reali6an las siguientes tareas>
Se valida el estado actual de la sesi%n del usuarioF co probando si se ?a autenticado correcta enteL sinoF podr1a redirigirse a una p9gina que le per ita introducir sus credenciales u otra infor aci%n de autenticaci%n. Esto podr1a ocurrir porque un usuario intente entrar Xen el edioX de una aplicaci%nF o porque la sesi%n ?a e;pirado $ el ediante filtros Binterfa6 contenedor de servlet cre% una nueva. En otras ocasionesF la responsabilidad sobre la autenticaci%n $ autori6aci%n de la aplicaci%n se lleva a cabo !ava;.servlet.8ilterC que pueden apo$arse en alguna A./ o fra eworS de seguridad. Se pueden reali6ar validaciones sobre la infor aci%n que viene en la petici%nF $a sean co ple entarias o no a las que se ?acen a trav4s del ;ction*or%. Si se encuentra un proble aF se pueden al acenar las claves de los puedan corregir los errores. -' ensa!es de error apropiados co o un atributo de la petici%nF $ reenv1ar el control de vuelta al for ulario de entrada para que se
:na ve6 ?ec?as todas la validacionesF se reali6a el procesa iento requerido por la acci%nF lo cual suele i plicar co unicarse con la capa de aplicaci%n. A partir de la infor aci%n recuperada del odeloF se pueden actuali6ar los ob!etosF odelo que i ple enta la l%gica de la
nor al ente de tipo Java<eanF que ser9n utili6ados por el co ponente de la vista para ostrar el resultado al usuario. Estos ob!etos pueden tener un 9 bito de solicitud o de sesi%nF dependiendo de cu9nto tie po se necesite antener estos 1te s disponibles.
8inal enteF $ ta bi4n en base al resultado obtenido en el procesa ientoF la acci%n devuelve un ob!eto ;ction*orward que identifica el co ponente de la vista al que se le debe pasar el control. .ara facilitar la deter inaci%n del ;ction*orward a devolver se puede ?acer uso de la infor aci%n de apeo disponible en el ;ction)appin( pasado al 4todo execute.
Es necesario tener en cuenta algunas consideraciones a la ?ora de codificar clases de acci%n> El servlet controlador crea un s%lo e!e plar de cada clase ;ctionF $ la usa para todas las solicitudes. .or tantoF deber9 estar codificada para operar correcta ente en un entorno ultiDt?read B ulti?iloCF al igual que si se estuviese codificando un servlet. #a$ dos principios funda entales> :tili6ar sola ente variables locales a los 4todosF $ no variables de instancia en la clase
;ctionF $a que las variables locales se crean en una pila que es asignada por la JM) a cada ?ilo individual B?a$ un ?ilo por cada petici%nC. Si es necesario pasar infor aci%n entre los 4todos de la claseF se deber1an pasar c% o par9 etros. Si se utili6an variables de instancia ?abr9 que prever un posible acceso concurrente. *o o regla generalF asignar recursos Bco o las cone;iones a una base de datosC $ antenerlos a trav4s de las solicitudes del is o usuario Bguard9ndolos en la sesi%nC puede causar proble as de escalabilidad. Es conveniente liberar esos recursos antes de reenviar el control al co ponente de la vista apropiado $ si vuelven a ser necesariosF se reasignar9n en la siguiente solicitud. Durante las tareas reali6adas en la acci%n se pueden obtener e;cepcionesL es i portante capturarlas $ tratarlas adecuada enteF $a que si se lan6asen podr1an llegarle al usuario de la
7,
aplicaci%n directa ente. Ade 9sF en el trata iento es i portante liberar cualquier recurso que pueda ?aber quedado asignado.
/v0
Aportaciones a la vista
El fra eworS de Struts utili6a las tecnolog1as b9sicas de Java EE para la vistaF tanto JavaServer .ages co o librer1as de etiquetasF a las que aIade un con!unto de utilidades $ co ponentes que van dirigidos a facilitar el desarrollo de esta capaF entre los que destacan> )ensa!es internacionali6ados> to ando co o base las clases de internacionali6aci%n $ locali6aci%n de la platafor a Java B<ocaleF Resource:undleF PropertyResource:undleF )essa(eResourceCF Struts per ite definir arc?ivos de los co ponentes de la vista para ensa!es pueden ser utili6ados desde ostrar al usuario la infor aci%n en el lengua!e escogido.
Librer1a de etiquetas> Struts inclu$e un con!unto de etiquetas personali6adas para JS. que a$udan a los desarrolladores tanto en la gesti%n $ acceso a los beans Binclu$endo los ;ction*or%sCF la creaci%n de for ularios basados en etiquetas #T)L o E#T)L Ben los que se pueden incluir ensa!es internacionali6adosCF $ la gesti%n del flu!o a trav4s de etiquetas de l%gica e iteraci%n. *o posici%n de p9ginas con Tiles> Struts proporciona un siste a de plantillas que per ite construir la vista co binando varios ele entos o RtilesR.
(vi)
-e()est &rocessor
.ara finali6arF es conveniente recordar el flu!o de control que i plica el uso del patr%n )odeloDMistaD*ontrolador $ su i ple entaci%n presentando el co ponente Request Processor. ediante Struts. .ara elloF la e!or anera es
El Request Processor se encarga de controlar los pasos de procesa iento que atraviesa una 71
petici%n entrante. .ara ello sigue el patr%n de diseIo *?ain of =esponsabilit$ que le da una gran fle;ibilidad $ capacidad de ser personali6adoF aIadiendo nuevos pasosF $ eli inando o el orden de los e;istentes. A continuaci%nF se ?an e;cluido algunos para si plificar la e;posici%nC> Seleccionar la infor aci%n sobre locali6aci%n de la petici%n. Al acenar la :=/ de la petici%n. /ncluir cabeceras en la respuesta Bprag aF cac?eDcontrolF e;piresF etc.C. Seleccionar el tipo de contenido $ la codificaci%n de la respuesta BcontentDt$peF c?aracterD encodingC. Deter inar el ;ction)appin( asociado con la ruta de la petici%n. Si el apeo tiene infor aci%n de roles que lo pueden e!ecutarF co probar que el usuario odificando uestra la secuencia de pasos por defecto Ben la que se
actual dispone de esos roles. /nstanciar o recuperar el ;ction*or% asociado a la acci%n seleccionada. =ellenar las propiedades del ;ction*or% con los par9 etros que vienen en la petici%n. =eali6ar la validaci%n del ;ction*or%. Si la validaci%n fallaF se vuelve a la p9gina de entrada infor ada en el apeo. 4todo de e!ecuci%nF pasando la infor aci%n de
/nstanciar la clase de la acci%n e invocar su petici%n $ respuestaF ;ction*or% $
apeo B;ction)appin('.
La acci%n devuelve un ;ction*orward que per ite al RequetProcessor redirigir el flu!o al co ponente adecuadoF nor al ente de la vista.
:n posible paso a aIadir ser1a el procesador de ilesF que es necesario e!ecutar si esta os utili6ando este co ponente en nuestra aplicaci%n.
(vii)
.escriptor de desplieg)e de la aplicacin
7"
En los arc?ivos de configuraci%n tipo strutsDconfig.; l se le indica al controlador de Struts c% o debe procesar cada una de las peticiones que le llegan. .ara definir qu4 peticiones le van a llegar al controlador es necesario incluir en el descriptor de despliegue de la aplicaci%n Bweb.; lC su declaraci%n co o servlet.
En la declaraci%n se indica la clase que i ple enta el controlador de Struts B ;ctionServletC $ los fic?eros de configuraci%nL ade 9sF se indica que este servlet debe cargarse al iniciar la aplicaci%nF o ento en el que recupera toda la infor aci%n del apeo de dic?os fic?eros.
En cuanto a las peticiones que ser9n procesadas por el controlador de StrutsF se inclu$e una declaraci%n con el patr%n de urls a asignarF t1pica ente Y.doF aunque podr1a ser cualquier otro.
Ver ejemplo: str$ts
/viii0
,truts 2
Struts 1 consigui% convertirse en el est9ndar de facto para el desarrollo de aplicaciones web Java EEF sin e bargoF con el tie po surgi% la necesidad de crear una nueva generaci%n del fra eworS cu$o principal ob!etivo era b9sicas de Struts 1F e!orar su facilidad de uso. As1F a partir del pro$ecto 0eb0orS !unto con la versi%n inicial del fra eworS se desarrolla Struts "F que sigue las directrices e!orando su i ple entaci%n del patr%n )M*.
Entre las caracter1sticas
9s novedosas destacan las
e!oras en el diseIo con el ob!etivo de
que las clases desarrolladas sean lo
9s independientes posibles tanto del propio fra eworS de 4todo execute que reciba la
Struts co o de la A./ de Servlet. Esto se traduce a queF por e!e ploF las clases de acci%n $a no est9n obligadas a ?eredar de ;ctionF ni ta poco deben incluir un infor aci%n de la petici%n $ la respuesta ?ttpF ni un Action8or F $a que la captura de la entrada puede ?acerse a trav4s de las propiedades de la propia clase que actJa co o acci%nL por tantoF 7(
cualquier
4todo incluido en la acci%n puede actuar co o
ane!ador de la petici%nF aunque
?abitual ente se inclu$e un execute sin par9 etros. Ade 9sF para el interca bio de infor aci%n con la vistaF en lugar de los ?abituales espacios de ob!etos de la A./ Servlet BapplicationF sessionF requestF pageCF Struts " reco ienda el uso de MalueStacS para independi6ar as1 las acciones de la tecnolog1as Servlet $ facilitar el acceso a la infor aci%nL en cualquier casoF los alcances ?abituales siguen estando disponibles para su uso en el conte;to de la acci%n BAction*onte;tC.
@tras aspectos a reseIar son la inclusi%n del lengua!e de e;presiones X@b!ect Grap? Kotation LanguageX B@GKLCF con el prop%sito de facilitar el acceso a la infor aci%n desde la vistaF as1 co o la conversi%n de tiposF o un nuevo fra eworS de validaci%n EworSF aunque se sigue conservando la posibilidad de ?acer una validaci%n tradicional a trav4s de la i ple entaci%n de un 4todo validate en la acci%n.
.ara ver una lista co pleta de
e!oras $ diferencias con struts 1 puede consultarse el enlace
oficial> ?ttp>TTstruts.apac?e.orgT".1.7TdocsTco paringDstrutsD1DandD".?t l
Ver ejemplo: str$tsB
3.#. A/a0 en Java EE
3.".1.
$ntroduccin
A!a; es el acr%ni o de ;synchronous =avaScript ;nd >)<, constitu$endo una t4cnica o
odelo interacci%n que e plea diferentes tecnolog1as de la 0eb con el ob!etivo de interactividad $ usabilidad de las aplicaciones.
e!orar la
A!a; per ite reali6ar una petici%n desde el navegador al servidor en segundo planoF es decirF
74
de for a as1ncrona $ sin interferir en la visuali6aci%n $ el co porta iento de la p9gina que se est9 ostrando. Esta petici%n nor al ente i plica un interca bio de datos con el servidorF cu$a respuesta recibida en el navegador suele causar ca bios en la infor aci%n que tendr9 co o resultado una odificaci%n en el estado del cliente. ostrada al usuario. .or tantoF una acci%n en el cliente provoca una co unicaci%n con el servidorF transparente al usuarioF
A continuaci%n se indican las tecnolog1as que ?abitual ente se utili6an para i ple entar la t4cnica A!a;> Lengua!es de infor aci%n. El Docu ent @b!ect )odel BD@)C accedido ediante el lengua!e de scripting para ostrar arcado co o #T)L o E#T)LF $ *SS para la presentaci%n de la
e interactuar din9 ica ente con la infor aci%n presentada. :n ob!eto E)L#ttp@b!ect co o ve?1culo de la co unicaci%n entre cliente $ servidor. E)L o JS@K BJavaScript @b!ect KotationC co o est9ndar para el interca bio de datos. JavaScript co o lengua!e de scripting que per ite la colaboraci%n del resto de las tecnolog1as utili6adas.
El E)L#ttp@b!ect es uno de los ele entos clave en A!a;F siendo una interfa6 que per ite la reali6aci%n de peticiones #TT. desde un navegador. Esta interfa6 es i ple entada de for a integrada por los principales navegadores del ercadoF peroF aunque se ?a desarrollado una especificaci%n est9ndarF pueden e;istir diferencias en la i ple entaci%n concreta de cada uno.
La clase que i ple enta E)L#ttp@b!ect contiene un con!unto de atributosF petici%nF al segui iento de su estado $ a la recuperaci%n del resultado devuelto.
4todos $
eventos que per iten gestionar el di9logo con el servidorL dando soporte a la creaci%n $ env1o de la
La siguiente ilustraci%n
uestra un cl9sico escenario de interacci%n
ediante A!a;>
7-
1. :n usuario genera un evento en el clienteF provocando la invocaci%n de una funci%n Javascript. ". La funci%n Javascript crea $ configura un ob!eto E)L#ttp=equestF especificando la funci%n que recoger9 el resultado BcallbacSC. (. Se reali6a una petici%n as1ncrona al servidor a trav4s del ob!eto E)L#ttp=equest. 4. El servidor web procesa la petici%n $ devuelve el resultadoF en este caso en E)L. -. Al recibir la respuestaF el ob!eto E)L#ttp=equest invoca a la funci%n Javascript encargada de procesar el resultado. 7. La funci%n de procesa iento anali6a la respuesta recibida $ nor al ente infor aci%n ostrada al usuario a trav4s del D@). odifica la
Entre los posibles usos de A!a; se pueden citar> la validaci%n de datos en servidor en tie po realF el autoco pletado de ca posF la carga de datos ba!o de andaF la recarga auto 9tica de infor aci%n de la p9ginaF etc.
77
3.".2.
Aja; y tecnolog8as en el lado del servidor Java EE.
SegJn lo visto ?asta el o entoF todas las tecnolog1as que utili6a A!a; pertenecen al lado cliente o son for atos de interca bio de infor aci%n entre cliente $ servidor. Sin e bargoF queda claro que uno de los aspectos 9s i portantes es el procesa iento en servidor de la petici%n #TT. que se genera a trav4s del ob!eto E)L#ttp=equest. .ara un servidorF el ane!o de una petici%n A!a; no es diferente al de cualquier otra petici%n. .or tantoF en un entorno Java EE se pueden utili6ar las tecnolog1as de procesa iento de peticiones convencionalesF co o son Java ServletsF JavaServer .ages o JavaServer 8aces. A partir del uso de las tecnolog1as de servidor Java EE disponiblesF pueden identificarse diferentes estrategias de diseIo puestas a disposici%n del desarrolladorF de anera que pueda elegir la que considere 9s adecuada. A continuaci%n se e;ponen tres de las 9s ?abituales> Tecnolog1as base> en la que el desarrollador utili6a directa ente las tecnolog1as de A!a;F encarg9ndose de la codificaci%n de las funciones JavascriptF el ane!o del ob!eto E)L#ttp=equestF teniendo en cuenta sus peculiaridades en funci%n del navegadorF $ los aspectos de presentaci%n de la infor aci%nF accediendo al D@). En el lado servidorF codifica el co ponente webF que ?abitual ente ser9 un ServletF para que reciba la petici%n $ genere la respuesta. :so de una biblioteca Javascript> en lugar de escribir todo el c%digo del lado clienteF es posible apo$arse en alguna biblioteca Javascript co o j?uery, Prototype o @ahooA Bser 9nterface <ibrary "@B9'F que per iten liberar al desarrollador de las tareas de ba!o nivelF co o la gesti%n del ob!eto E)L#ttp=equest $ su co patibilidad con el navegadorF o el procesa iento de la respuesta recibidaF reduciendo as1 el c%digo necesario para i ple entar una funcionalidad A!a; en la aplicaci%n. :so de un fra eworS de co ponentes preparados para A!a;> en particularF en la platafor a Java EE se dispone de la tecnolog1a de co ponentes JavaServer 8acesF que puede ser e;tendida de anera que se creen co ponentes que inclu$an funcionalidades A!a;F co o los que proporciona el fra eworS /*Efaces o el =ic?8aces. Estos co ponentes ;jaxenabled inclu$en todo el c%digo necesario para i ple entar la funcionalidad A!a;F presentando una interfa6 li pia $ reutili6able al desarrollador final que puede usarlos sin necesidad de conocer los detalles.
Ver ejemplo: str$tsCjax
7+
!.
apa de negocio
'.1. *ntrod)ccin
En la capa de negocio o
odelo se encuentran los co ponentes que proporcionan la l%gica
de negocio de la aplicaci%n. Esta l%gica de negocio es la que representa la funcionalidad espec1fica de un do inio particularF co o un siste a bancarioF un sitio de co ercio electr%nicoF un gestor de inventario $ fabricaci%nF etc. .or tantoF supone la capa 9s espec1fica del siste a a desarrollar.
La l%gica de negocio debe per itir representar tanto el estado del siste a co o su co porta iento. As1F en las etodolog1as de an9lisis $ diseIo orientado a ob!etos el siste a se odela a trav4s de un con!unto de ob!etos que interaccionan entre s1 $ que se caracteri6an por su claseF su estado Bele entos de datosC $ su co porta iento. Aunque el paradig a de orientaci%n a ob!etos aboga por encapsular en la clase tanto el estado co o el co porta ientoF es ?abitual que al ob!etos o co porta iento del is o. is a entidad o
odelar un siste a e;istan unos
9s enfocados a representar el estado de la aplicaci%n $ otros que se encarguen de la l%gica
Estado del siste a> nor al ente se utili6an un con!unto de clases $ sus propiedadesF de anera que los valores de las propiedades son los que representan el estado del siste a en un o ento dado. .or e!e ploF en un siste a de co pra por internetF el estado se podr1a o ento. )ientras que puede e;istir infor aci%n de estado que no es antenga por un periodo de tie po largoF es ?abitual encontrar siste as representar por un carro de la co pra con unos art1culosF unas cantidades $ unos precios en un deter inado necesario que se
que necesitan ?acer persistente esta infor aci%nL en este Jlti o casoF ser9 necesario co unicar los ob!etos de estado con el siste a de al acena iento a trav4s de la capa de persistencia. *o porta iento del siste a> la l%gica funcional $ las reglas de negocio del siste a se representan a trav4s de invocaciones a 4todosF que pueden ubicarse en las is as clases utili6adas para representar el estado del siste aF o co o se indic% anterior enteF en un 7&
con!unto de clases dedicadas a reali6ar esta l%gica. En este Jlti o casoF suele ser necesario pasar los ob!etos de estado del siste aF que van a negocioF co o argu entos de dic?os o anipularse en los 4todos de la l%gica de a$or 4todos. Los ob!etos de estado contendr9n una
enor cantidad de l%gica dependiendo del do inio $ alcance del siste a espec1fico.
La
is a l%gica de negocio debe poder ser utili6ada con independencia de que la capa de
presentaci%n se base en un cliente ligero BnavegadorC o pesado Baplicaci%n de escritorioCF o del siste a o tecnolog1a que proporcione la persistencia. .or tantoF debe ser diseIada siguiendo criterios de alta co?esi%n $ ba!o acopla iento respecto del resto de capas de la aplicaci%n. Ade 9sF suele ser ?abitual encontrar siste as cu$a l%gica de negocio puede requerir de cierta fle;ibilidad en su configuraci%n o la capacidad de ser a pliados sin perder sus calidades de servicio BescalabilidadC. .ara cu plir estas posibles e;pectativasF se suele ?acer uso de los patrones de diseIoF tanto en la capa de odelo co o en el resto de capas de la aplicaci%n. 9s ?abitual ente en la i ple entaci%n de la l%gica de
:no de los patrones utili6ados
negocio es el Service <ayer o capa de servicio. Este patr%n i plica el estableci iento de una capa de negocio que presenta el con!unto de operaciones disponibles en la aplicaci%nF coordinando su respuesta $ co porta iento transaccionalL actuando as1 co o una interfa6 de acceso a las funcionalidades de la aplicaci%n con independencia del cliente. La capa de servicio suele estar co puesta por ;pplication Services o servicios de aplicaci%nF que son co ponentes que encapsulan en sus operaciones la l%gica de negocio de la aplicaci%n. Estos co ponentes interaccionar9n con el resto de co ponentes de la capa de negocio para i ple entar la funcionalidad requerida.
'.2. ecnolog!as 1 estrategias
!.2.1.
Apro;imacin #1J1 B Java<eans
7'
.@J@ es el acr%ni o de .lain @ld Java @b!ect. Este no bre se utili6a para enfati6ar que se trata de un ob!eto Java ordinarioF es decirF no est9 ligado a dependencias de ningJn fra eworS o co ponente deter inadoF especial enteF no es un Enterprise Java<ean.
.or tantoF en su c%digo no nos encontrare os>
p$/lic class =lase9>8> exten's javax*servlet*http*DttpServlet ; E p$/lic class =lase9>8> implements javax*ej/*2ntity3ean ; E
:n Java<ean es un .@J@ que sigue una serie de convenciones de codificaci%nF $a e;plicadas al e;poner la arquitectura de co ponentes Java<eansF $ que son> Disponer de un constructor pJblico por defectoF que facilita la instanciaci%n del ob!eto. *ontener propiedades que deben ser accesibles a trav4s de que siguen una est9ndar de no brado. Deben ser seriali6ables. 4todos de lectura $ escrituraF $
Estas convenciones ?acen que los Java<eans tengan una serie de caracter1sticas esperablesF pero no los ?acen dependientes de ningJn fra eworS o tecnolog1a espec1fica.
En consecuenciaF se trata de clases que presentan una codificaci%n sencilla $ un alto grado de reutili6aci%nF $a que no dependen de fra eworSs espec1ficos. Ade 9sF per iten acceder a la l%gica de negocio de la aplicaci%n en un entorno local $ con un alto rendi iento de e!ecuci%nF $a que se consideran ob!etos ligerosF por no i plicar su procesa iento la necesidad de e!ecutar servicios adicionales.
:na ve6 e;puestos a bos conceptosF es el la capa de
o ento de definir c% o se puede i ple entar
odelo de un siste a siguiendo la apro;i aci%n de .@J@ A Java<eans.
+,
A partir de la definici%n de estado del siste aF e;puesta en la introducci%nF es f9cil inferir que la arquitectura de co ponentes Java<eans es una clara candidata a representarloF pues se basa en ob!etos con un con!unto de propiedades $ sus 4todos de acceso Blectura $ odificaci%nC.
.or su parteF la l%gica de negocio podr9 alo!arse bien !unto con la infor aci%n del estado en los Java<eansF o ta bi4n en clases .@J@ adicionales. Estar9 en uno u otro lado dependiendo en gran edida del do inio espec1fico del proble a. .or e!e ploF si es una l%gica que tiene que ver ientras que si afecta a 9s de un ob!eto de estado o no es intr1nseca a la naturale6a de directa ente con la naturale6a de una entidad o beanF estar9 en el propio Java<ean que lo i ple enteF un bean sino nor al. Si la aplicaci%n utili6a el patr%n Service <ayer los co ponentes de la capa de servicio ser9n nor al ente clases .@J@F cu$os 4todos representar9n las operaciones del siste a. 9s bien a la aplicaci%n o funcionalidad generalF se encontrar9 en una clase .@J@
Ver ejemplo: str$tsService
!.2.2.
Apro;imacin EJ<
:n Enterprise bean o bean e presarial es un co ponente Java EE que i ple enta la tecnolog1a Enterprise Java<eans BEJ<C. Estos beans se despliegan en el contenedor de EJ<F dentro del servidor e presarialF que proporciona servicios a nivel de siste aF co o seguridad $ transacciones a estos beansF facilitando su r9pida construcci%n $ despliegue.
Estos beans son co ponentes de la capa de negocioF por tanto en su codificaci%nF ?ec?a en lengua!e JavaF encapsulan la l%gica de negocio de la aplicaci%n.
Lo que diferencia a esta apro;i aci%n de la .@J@DJava<eansF es el con!unto de servicios que aporta el contenedor EJ<F que facilitan que el desarrollador se centre en la i ple entaci%n de +1
la l%gica de negocio de!ando otras cuestiones ?ori6ontales al contenedorF $ sobre todoF proporcionan un ecanis o de acceso re oto a la l%gica de negocio.
A pesar de estas venta!as a la ?ora de desarrollar la l%gica de negocio con esta apro;i aci%nF el uso de la tecnolog1a EJ< puede tener efectos negativos en el rendi iento respecto a la basada en .@J@DJava<eansF $a que estos Jlti os se consideran co ponentes tantoF es necesario especificar una serie de necesidades o a optar por esta apro;i aci%n> La aplicaci%n debe ser escalable. La tecnolog1a EJ< per ite la distribuci%n de sus co ponentes en Jltiples 9quinas de for a transparente al usuarioF por lo que si se incre enta el nJ ero de co ponentes o de usuarios es factible incre entar el nJ ero de servidores utili6ados. La l%gica de negocio debe poder ser accesible desde Jltiples ubicaciones re otas $ 9s ligeros en su e!ecuci%n. .or otivos que pueden llevar al desarrollador
garanti6ando la seguridad $ transaccionalidad de las operaciones.
.or tantoF la tecnolog1a EJ< per ite co partir la l%gica de negocio de for a re otaF segura $ con independencia del nJ ero $ tipo de usuarios o clientes.
(i)
ipos de Enterprise 2eans (EJ2 3.1)
10
,ession <ean
:n Session <ean o bean de sesi%n encapsula l%gica de negocio que puede ser utili6ada por un cliente a trav4s de la invocaci%n de los referencia local o re otaF o por 4todos del beanF a los que tendr9 acceso a trav4s de una edio de un servicio web.
E;isten tres tipos de beans de sesi%n> +"
State*ul Session Beans> son beans de sesi%n con estadoF siendo este estado el con!unto de valores de las variables de la instancia utili6ada. El estado est9 asociado a un Jnico clienteF es decirF por cada cliente que acceda a un bean de sesi%n con estado se tendr9 una instancia dedicadaF por lo que a veces se le deno ina estado conversacional. *uando el cliente ter ina su sesi%nF el bean ter ina su asociaci%n $ se libera la infor aci%n de sesi%n. )antener el estado conversacional per ite que un bean de sesi%n se pueda utili6ar para reali6ar un flu!o de traba!o o escenario. Stateless Session Beans> un bean de sesi%n sin estado no con el clienteF por tantoF cuando se invoca un s%lo se pueden ser utili6adas por antiene un estado conversacional
4todo la infor aci%n del cliente espec1fico e!or escalabilidad
antiene durante dic?a invocaci%n. Las instancias de beans de sesi%n sin estado Jltiples clientesF por lo que presentan una
cuando se incre enta el nJ ero de usuarios. Ade 9sF al ser sin estado pueden i ple entar un servicio webF lo cual no es posible en un bean con estado. Sin+leton Session Beans> este tipo de beans de sesi%n i ple entan el patr%n SingletonF lo que significa que s%lo se instancian una ve6 por aplicaci%n. Es decirF es si ilar a un bean sin estadoF pero en lugar de e;istir varias instanciasF probable ente en un poolF que atienden a los clientesF en este caso e;iste una Jnica instancia para todos los clientesF cu$o estado es antenido entre las invocaciones de sus 4todosF por lo que es co partido por todos. Se crear9 la instancia al iniciarse la aplicaci%n $ se eli inar9 cuando 4sta ter ineF por lo que puede ser utili6ado para reali6ar tareas de iniciali6aci%n $ finali6aci%n de la aplicaci%n. Al igual que los bean sin estadoF puede i ple entar un servicio web.
En cualquier casoF un bean de sesi%n no es persistenteF es decirF sus datos no se al acenan en una base de datos.
20
MessageACriven <ean
:n bean dirigido por
ensa!es per ite a las aplicaciones Java EE procesar
ensa!es de
for a as1ncrona. .ara elloF actJa co o un RlistenerR de
ensa!es tipo Java )essage Service BJ)SC. +(
Estos
ensa!es pueden ser enviados desde cualquier co ponente Java EE> una aplicaci%n clienteF ensa!es ensa!es.
otro enterprise beanF un co ponente webF etc.F o ta bi4n desde un siste a que genere J)S u otro tipo de
:n bean dirigido por sus interfacesF de
ensa!es es
u$ si ilar a un bean de sesi%n sin estadoF aunque se ensa!es se le env1a un ensa!e a un cola ensa!es
diferencian en la for a en la que son accedidosF $a que un bean de sesi%n es accedido a trav4s de ientras que a un bean dirigido por antenida en el servidor. Ade 9sF los bean de sesi%n reparten la l%gica de negocio en un con!unto 4todos que se pueden invocar individual enteF ientras que los bean dirigidos por reciben los ensa!es de la cola en un Jnico punto de entradaF que se encarga de procesarlos en base
a la l%gica i ple entada.
(ii)
Accediendo a los Enterprise 2eans
En esta secci%n Jnica ente se bean dirigidos por
ostrar9 la for a de acceder a los beans de sesi%nF $a que los
ensa!e no definen interfaces ni vistas sin interfa6 para el acceso de los clientes.
*o o se publica todos los
encion% anterior enteF la l%gica de negocio est9 disponible a trav4s de los 4todos se publican al cliente a trav4s de una vista sin interfa6F que 4todos deter inados. En cualquier casoF a bos ecanis os 4todos pJblicos de la clase que i ple enta el beanF o a trav4s de una interfa6 de
4todos del bean. Estos
negocioF que publica un con!unto de
per iten definir la visi%n que tiene el cliente de un bean.
.ara ?acer uso de los una referencia al
4todos de negocio de un beanF el cliente debe previa ente obtener
is oF lo que puede conseguir ?aciendo uso de la in$ecci%n de dependencias Ba
trav4s de anotacionesC o de bJsquedas JKD/.
A la ?ora de i ple entar un beanF es necesario indicar el tipo de acceso per itidoF que +4
puede ser localF re oto o a trav4s de un servicio web.
10
Acceso Docal
Si el bean puede ser utili6ado por otro bean o co ponente que se encuentra en la aplicaci%n que el accedidoF ser9 necesario proveer de acceso local. Esto puede ?acerse vista sin interfa6 del beanF o proporcionando una interfa6 de negocio que contenga los negocio $ del ciclo de vida del beanF $ negocio puede ser local o re ota.
is a
ediante la 4todos de
arc9ndola co o local 4<ocalF $a que una interfa6 de
El cliente podr9 acceder a la vista sin interfa6 o a la interfa6 de negocio local por in$ecci%n de dependencias o por JKD/.
20
Acceso =emoto
Si el cliente se e!ecuta en otra
9quina $ con una
9quina virtual diferente al bean
accedidoF es necesario disponer de un acceso re oto. En este caso no es posible ?acer uso de una vista sin interfa6F sino que debe utili6arse una interfa6 de negocio re ota 4Re%oteF en la queF de anera an9loga al acceso localF puede obtenerse una referencia a trav4s de in$ecci%n de dependencias o JKD/.
30
Acceso con ,ervicio %e&
En ocasiones es necesario que la l%gica de negocio est4 disponible re ota enteF con independencia del tipo de cliente utili6ado. En este casoF es necesario utili6ar los Servicios web. :n bean de sesi%n sin estado puede ser utili6ado co o servicio webF de for a que sus 4todos de negocio ser9n utili6ados co o puntos de acceso o RendpointsR del servicio. El cliente utili6ar9 el +-
servicio web sin necesidad de conocer si est9 i ple entado a trav4s de un bean de sesi%n sin estadoF o de otras opciones co o servicios web con JAED0SF con el fra eworS A;isF etc.
(iii)
Empa()etado de )n Enterprise 2ean
:n bean e presarial estar9 for ado por un clase que i ple enta los de negocio accesiblesF $ opcional ente un con!unto de clases de apo$o.
4todos de negocio 4todos
as1 co o los del ciclo de vida del beanF unas posibles interfaces de negocio que definen los
El bean podr9 e paquetarse $ distribuirse de dos for as> A trav4s de un fic?ero EJ< JA=> presenta una unidad de encapsula iento autocontenidaF que per ite utili6ar el bean para co poner diferentes aplicacionesF por e!e plo inclu$4ndolo en un fic?ero EA=. El arc?ivo incluir9 las clases del beanF $ un posible e!bD !ar.; l en el directorio /ncluido en un etaDinf. odela con beans
%dulo 0A=> si la l%gica de una aplicaci%n web se
e presarialesF se pueden incluir sus clases en las ubicaciones ?abituales para las clases del %dulo BwebDinfTclasses o en webDinfTlib co o un fic?ero JA=C $ el fic?ero e!bD!ar.; l en el is o directorio que los descriptores de despliegue de la aplicaci%n web.
Ver ejemplo: co'igo283
Ver ejemplo: str$ts283
+7
".
apa de persistencia.
#.1. *ntrod)ccin
:na de las posibles necesidades de la l%gica de negocio es que deter inada infor aci%n del estado del siste a sea persistente. .ara elloF se utili6a la capa de persistencia o de datosF que gestiona la persistencia de los beans de estado de la capa de do inio. Las clases cu$as instancias se guardan en algJn siste a de al acena iento persistente se deno inan Nclases persistentesO. .or lo generalF lo instancias del discoL B:pdateC 1ni o que se ?ar9 con las clases persistentes de la capa de do inio ser9> B*reateC crear instancias nuevas $ guardarlas en discoL B=eadC leer odificar el estado de las instancias $ actuali6arlo en discoL $ 1ni o de operaciones se conoce co o BDeleteC eli inar instancias del disco. Este con!unto
Noperaciones *=:DOF por las siglas de *reateF =eadF :pdate $ Delete. En el conte;to de un SG<D relacionalF la operaci%n *reate corresponder9 a una operaci%n 9nsert de S3LF la operaci%n =ead a un Select de S3LF corresponder9n con las operaciones del is o no bre en S3L. ientras que :pdate $ Delete se
.or tantoF la capa de persistencia tiene co o principales responsabilidades $ ob!etivos> / ple entar las operaciones de persistencia B*=:DC. Aislar a la l%gica de negocio de la tecnolog1a de al acena iento Bnor al ente un SG<DC. .resentar una interfa6 co Jn de acceso a datos.
#.2. +odelos cl%sicos de persistencia
E;isten
Jltiples for as de gestionar la persistencia. A continuaci%nF se e;pondr9n algunos
patrones cl9sicos> ++
".2.1.
#ersistencia en las clases del modelo
:na posibilidad es que las propias clases del
odeloF que ser9n beans de estadoF sean las 4todos de
que gestionen su propia persistencia. .or tantoF deber9n i ple entarF ade 9s de sus que ?ace a la capa de do inio de asiado dependiente del instancias.
negocioF los correspondientes a las operaciones *=:D. Esta soluci%n se considera proble 9ticaF $a ecanis o de al acena iento de las
".2.2.
#ersistencia en clases au;iliares
@tra posibilidad es dar la i ple entaci%n a las operaciones *=:D en clases asociadas que se encarguen Jnica ente de gestionar la persistencia de las instancias de las clases de do inio. De este odoF las clases de do inio se olvidan de las responsabilidades de persistencia $ se centran en ecanis o o tecnolog1a de i ple entar la resoluci%n del proble a. :n ca bio en el al acena iento no afectar1a a las clases de do inio.
(i)
&atrn ,abricacin &)ra
+&
El patr%n fabricaci%n pura i plica la creaci%n de una clase au;iliar a la que la clase principal delega las operaciones que no son de negocio. En este casoF lo que se delega es la responsabilidad de i ple entar las operaciones de persistencia.
<9sica enteF se crear9 una clase total ente dependiente de la clase del al acena iento. *uando la clase del correspondiente clase au;iliar.
odelo que sabe
co o dar persistencia a dic?a clase $ que inclu$e el c%digo dependiente de la tecnolog1a de odelo necesite una operaci%n de persistencia ?ar9 uso de su
E;isten diferentes posibilidades a la ?ora de i ple entar el patr%n fabricaci%n pura para la persistenciaF variando en la for a en la que se relaciona la clase de do inio con la clase au;iliarF en todo casoF la clase de do inio tiene los 4todos *=:DF pero en su cuerpo lo que se ?ace es lla ar 4todo> directa ente a la clase au;iliar que i ple enta dic?o
p$/lic voi' insert?@ throAs 2xception ; 9ersist2mplea'o*insert?this@; <
En los
4todos de la clase au;iliar es en los que se encontrar9 el c%digo dependiente del
siste a de al acena ientoF por e!e ploF si se trata de una base de datos relacionalF se tendr1a la gesti%n de la cone;i%n $ las sentencias S3L.
+'
(ii)
&atrn .ata Access 3b/ect (.A3)
El patr%n DA@ proporciona una soluci%n
u$ si ilar a la anteriorF $a que define una clase
DA@ encargada de abstraer $ encapsular el acceso a la fuente de datos.
La principal diferencia es que la clase que necesita persistencia puede no tener ninguna relaci%n con la clase DA@F con lo que se incre enta el grado de independencia. De esta ser9 una tercera clase la encargada de gestionar las operaciones de persistencia. aneraF
El cliente puede ser una clase de negocioF co o un bean de sesi%nF o una clase R#elperRF que per itan i ple entar una funcionalidad que de anda el acceso a los datos.
El ob!eto de transferencia de datos 22 ransfer,bject88 podr1a ser un bean de estadoF aunque ta bi4n podr1an definirse ob!etos espec1ficos para la co unicaci%n de datos entre capas.
El ob!eto DA@ i ple enta las operaciones de persistenciaF utili6ando un ob!eto de transferencia para devolver los datos al cliente en caso de lecturas $ recibi4ndolo para el caso de escrituras. Se co unica con una fuente de datos para reali6ar las operaciones. &,
#.3. +ecanismos 1 tecnolog!as de persistencia
".3.1.
Java Cata&ase onnectivity /JC< 0
(i)
*ntrod)ccin
Java Database *onnectivi$ BJD<*C es la A./ que ofrece la platafor a Java en su edici%n est9ndarF $ por tanto ta bi4n disponible desde las aplicaciones e presarialesF para el acceso a datos desde aplicaciones Java. Est9 dirigida al acceso a bases de datos relacionales basadas en S3LF aunque ta bi4n per ite acceder a otras fuentes de datos. Desde el punto de vista del desarrollador de aplicacionesF el uso de JD<* i plica tres operaciones b9sicas> establecer una cone;i%n con una fuente de datosF enviar sentencias S3L $ procesar los resultados devueltos. .ara dar soporte a estas operaciones es necesario disponer de un D"i(e" JDBCF que es un co ponente software que per ite interaccionar a la aplicaci%n Java con la base de datosF traduciendo las lla adas a la A./ JD<* a co andos entendibles por Siste a Gestor de <ase de DatosF de anera que se ?aga posible el interca bio de infor aci%n. El estableci iento de la cone;i%n requiere que est4 disponible el Driver de la base de datos que se va a utili6arF de for a que el +river)ana(er pueda obtener una cone;i%n indicando la :=L asociada a dic?a base de datos. :na ve6 establecida la cone;i%n "!onnection'F se puede co en6ar a crear $ e!ecutar sentencias que per itan i ple entar las operaciones de persistencia requeridasF para lo que puede ?acerse uso de las interfaces State%ent, PreparedState%ent $ !allableState%entF esta Jlti a per ite la invocaci%n de procedi ientos al acenados en la base de datos. La e!ecuci%n de las sentencias provocar9 la devoluci%n de unos resultados a procesarF espec1fica ente en el caso de las consultas se suele obtener un con!unto de registros con la infor aci%n devueltaF encapsulados en un ob!eto ResultSet que per ite recorrer los datos devueltos $ acceder a los etadatos asociadosF co o por e!e plo el nJ ero de registros obtenidos $ sus tipos de datos. Es i portante gestionar el ciclo de vida tanto de las cone;iones co o de otros recursos utili6ados en el acceso a datosF de for a que una ve6 que se ?a$an ter inado las operaciones a reali6ar se liberen estos recursos. Ade 9sF ta bi4n es necesario reali6ar un trata iento de las &1
posibles e;cepciones que se puedan producirF co o la S?<5xception, de la que es co plicado recuperarseF por lo que se reco ienda traducirla a una e;cepci%n de tipo unchecCed que provoque des?acer las posibles operaciones reali6adas BroolbacC' $ la notificaci%n al usuario.
Ver ejemplo: mo'elo-
(ii)
.ataso)rces
En el apartado anterior se e;puso la anera convencional de establecer una cone;i%n JD<* a trav4s del uso del +river)ana(er. Sin e bargoF desde Java 1.4F el ecanis o reco endado para gestionar las cone;iones en JD<* es el uso de la interfa6 +atasource. La interfa6 +atasource representa una factor1a de cone;iones a una fuente de datos previa ente configurada. E;iste diferentes i ple entaciones de la interfa6> de proveedores de bases de datosF de servidores Java o de bibliotecas de tercerosF co o c(p, o D<*. de Apac?e. En cualquier casoF el uso de +atasource per ite aislar los aspectos de configuraci%n de la cone;i%n del c%digo que la utili6aF por lo que se obtiene un c%digo 9s portable $ f9cil de antener. Ade 9sF ?abilita la reali6aci%n de transacciones distribuidas $ el uso de un pool de cone;ionesF que per ite la gesti%n de la cone;iones activas ?aciendo posible su reutili6aci%nF e!orando as1 el rendi iento $ la seguridad de la aplicaci%n.
Ver ejemplo: mo'eloB
/iii0
5@eadDocal en JC<
La clase hread<ocal per ite la definici%n de variables locales a un ?ilo de e!ecuci%n. En el 9 bito de las aplicaciones web Java EE to a especial ente relevancia su usoF $a queF al estar cada petici%n asociada a un ?ilo de e!ecuci%nF esta clase proporciona un ecanis o para co partir variables entre todos los co ponentes $ clases que intervienen en el procesa iento de una petici%n. En el caso de la persistencia con JD<*F se puede utili6ar hread<ocal para al acenar la instancia de la cone;i%n asociada a la petici%nF de anera que $a no ser9 necesario pasarla co o argu ento a cada uno de los 4todos utili6ados. #a$ que tener especial cuidado al utili6ar la clase hread<ocal $a que puede provocar un incre ento del acopla iento en el diseIo de la aplicaci%n. &"
Ver ejemplo: str$tsServiceTF
".3.2.
Mapeo 1&jetoA=elacional. Java #ersistence A#$
(i)
*ntrod)ccin
El
apeo ob!etoDrelacional es una t4cnica de progra aci%n que se basa en convertir datos
entre el siste a de tipos utili6ado en un lengua!e de progra aci%n orientado a ob!etos $ el utili6ado en una base de datos relacional. En la pr9cticaF esto se traduce a definir un con!unto de relaciones o apeos entre los ob!etos de negocio $ las tablas de base de datos que per iten su persistencia.
E;isten
ultitud de fra eworSs $ ?erra ientas que i ple entan el
apeo ob!etoD
relacionalF que suelen variar en el lengua!e de orientaci%n a ob!etos al que est9n dirigidasF en la for a en la que se definen las asociaciones o etc.CF en el lengua!e de consultas definidoF etc. apeos Bcon fic?eros de configuraci%nF anotacionesF
Dentro de los fra eworSs de
apeoF el
9s e;tendido ?a sido el de #ibernateF disponible etadatos
tanto para la platafor a Java co o para .Ket. A partir de #ibernateF Java EE ?a definido una especificaci%nF deno inada J.A o Java .ersistence A./F que estandari6a la A./ $ los necesarios para i ple entar un ecanis o de persistencia ob!etoDrelacional.
(ii)
Java &ersistence A&*.
La Ja(a Pe"sistence API o J.A proporciona una utilidad de
apeo ob!etoDrelacional para la
gesti%n de datos relacionales en aplicaciones Java. La especificaci%n J.A puede dividirse en tres
&(
9reas principales> La A./ de persistencia. El lengua!e de consultas. La A./ *riteria. Los etadatos de apeo ob!etoDrelacional.
10
Entidades
:na entidad es un ob!eto de do inio persistenteF que t1pica ente representa una tabla en una base de datos relacional. De esta for aF cada instancia de la entidad se corresponde con un registro de la tabla.
:na clase de entidad debe cu plir los siguientes requisitos> Debe estar anotada con 45ntity. Debe tener un constructor sin argu entos pJblico o protegido. Ko puede ser declarada co o final, ni ta poco sus variables o persistentes. Si sus instancias van a ser pasadas co o valorF por e!e plo a trav4s de la interfa6 re ota de un bean de sesi%nF deber9n i ple entar la interfa6 SerialiDable. Las variables de instancia persistentes deben ser declaradas co o protegidas o privadas $ s%lo pueden ser accedidas por sus 4todos de la clase. 4todos arcados co o
.ara indicar los datos que deben ser persistentes se pueden utili6ar los ca pos de la clase o los 4todos de accesoF si es que se ?an seguido las convenciones Java<ean para definici%n de propiedades. En cualquier casoF ser9n persistentes salvo que se indique e;pl1cita ente que deben considerarse transitorios 4 ransient.
&4
*ada entidad debe tener un identificador Jnico de ob!eto o clave principalF que per itir9 identificar el ob!etoF pudiendo ser si ple o co puesta. Si es si ple se utili6ar9 la anotaci%n 49dF ientras que si es co puesta se deber9 definir en una clase de clave pri aria.
Las entidades pueden estar relacionadas entre s1 a trav4s de cuatro tipos de relaciones> uno a unoF uno a uc?osF uc?os a uno $ uc?os a uc?osF teniendo cada tipo de ultiplicidad su anotaci%n correspondiente. Las relaciones pueden ser unidireccionales o bidireccionales. En este Jlti o caso ?abr9 que indicar que parte de la relaci%n es la esclava en la anotaci%n Bse corresponder1a se 9ntica ente con la clave a!enaCF a lo que ade 9s se puede aIadir si la relaci%n i plica dependencia en e;istenciaF pudiendo provocar un borrado en cascada.
El lengua!e de consultas de J.A a s%lo.
enudo navega entre relacionesF por lo que si la relaci%n ientras que si es unidireccional lo ?ar9 en uno
es bidireccional podr9 navegar en los dos sentidosF
Las entidades soportan ?erencia de clasesF asociaciones poli %rficas $ consultas poli %rficas. .ueden e;tender de clases que sean o no de entidadF $ cada clase de entidad puede ser concreta o abstracta. .or tantoF es posible establecer Jltiples tipos de !erarqu1as de ?erencia con entidadesF que podr9n ser i ple entadas a trav4s de tres estrategias b9sicas> una Jnica tabla para toda la !erarqu1a de clasesF una tabla para la ra16 $ otra para cada subclase con una clave a!ena a la ra16F $ por Jlti oF una tabla para cada clase concreta.
20
Eestionando Entidades
La especificaci%n J.A define la interfa6 5ntity)ana(er para gestionar las entidades. *ada instancia del gestor de entidades est9 asociada a un conte;to de persistenciaF que define el con!unto particular de entidades gestionadas $ el alcance ba!o el que las instancias de una entidad particular son creadasF guardadas $ eli inadas. &-
La interfa6 5ntity)ana(er define los
4todos que interactJan con el conte;to de
persistencia para llevar a cabo las operaciones de creaci%n $ eli inaci%n de instancias de entidadesF la bJsquedas de entidades $ otras posibles consultas personali6adas.
.or tantoF el gestor 5ntity)ana(er tendr9 asociadasF a trav4s del conte;to de persistenciaF un con!unto de instancias de las entidades que representan los ob!etos de negocio del siste aF sobre los que e!ecutar9 operaciones de persistencia.
E;isten dos tipos de gestores de entidades> Gestionados por el contenedor> en este casoF es el contenedor el responsable de la gesti%n del ciclo de vida del 5ntity)ana(erF ocup9ndose de abrir $ cerrar el gestor. El conte;to de persistencia se propaga auto 9tica ente a todos los co ponentes que utili6an la instancia del 5ntity)ana(er dentro de una transacci%n Java Transaction Arc?itecture BJTACF con lo que no es necesario pasar una referencia de la instancia entre los co ponentes. Gestionados por la aplicaci%n> el ciclo de vida del gestor se debe ane!ar anual ente en el anual ente. .ara
c%digo de la aplicaci%n. El conte;to de persistencia no se propaga de for a auto 9tica entre co ponentesF por lo que si se quiere utili6ar en varios se deber9 pasar obtener una instancia de 5ntity)ana(er gestionado por la aplicaci%n es necesario ?acer uso de 5ntity)ana(er*actoryF que per itir9 obtener gestores asociados a una unidad de persistencia.
@tro de los co ponentes clave dentro de la arquitectura de persistencia de J.A son las unidades de persistencia B.ersistence :nitCF que definen un con!unto de tipos de entidades que pueden ser ane!ados por un 5ntity)ana(er. La infor aci%n de una unidad de persistencia se refle!a en el arc?ivo persistence.x%lF en el que ade 9s se inclu$e infor aci%n sobre el tipo de transacci%n a utili6arF la fuente de datosF el proveedor que i ple enta J.AF $ otros par9 etros espec1ficos del proveedor.
&7
Las transacciones definen cuando se sincroni6an las entidades con la base de datos. J.A soporta dos tipos de gesti%n de las transacciones> JTA $ =esourceDLocal. Los 5ntity)ana(er gestionados por el contenedor utili6an sie pre JTAF cada unidad de persistencia. JTA> el ciclo de vida de la transacci%n est9 controlado por el contenedor que puede co partirla entre co ponentes. =esourceDlocal> son las transacciones nativas de los drivers JD<* que se referencian en las unidades de persistencia. .or tantoF el control del ciclo de vida se ?ar9 e;pl1cita ente en la aplicaci%n a trav4s de la A./ de 5ntity ransaction. ientras que los gestionados por la aplicaci%n pueden utili6ar a bas. El tipo de transacci%n utili6ada se define en el fic?ero persistence.x%l para
*o o se indic% inicial enteF J.A es una especificaci%n que proporciona una interfa6 para la i ple entaci%n del ecanis o de persistencia ob!etoDrelacional en Java EE. En tie po de e!ecuci%nF ser9 necesario un proveedor de persistencia que proporcione dic?a i ple entaci%n.
La
a$or1a de los fra eworSs de persistencia $a proporcionan una i ple entaci%n para uestra una tabla con
J.AF algunos de ellos con una alta integraci%n con los servidores Java EE en los que se despliegan las aplicaciones que requieren de la persistencia. A continuaci%nF se infor aci%n referente a productos de persistencia>
&+
30
1peraciones de persistencia
Las operaciones de persistencia se reali6an a trav4s del 5ntity)ana(er sobre las instancias del conte;to de persistencia asociado.
*ada operaci%n *=:D se reali6a a trav4s de un
4todo del 5ntity)ana(er>
=reate: 6ea': p'ate: Ielete:
entityGanager*persist ?>/ject entity@ entityGanager*%in' ?2ntity*=lass( >/ject primaryHey@ entityGanager*merge ?>/ject entity@ entityGanager*remove ?>/ject entity@
Ade 9s de las operaciones b9sicasF J.A proporciona dos A./ *riteria. A continuaci%n se e;pondr9 breve ente J.3L.
ecanis os para la consulta de 9s reciente ente la
entidades> el lengua!e de consultas J.3L BJava .ersistence quer$ langua!eC $
El len+ua!e de consultas JP,L es un lengua!e basado en cadenas de te;to si ilar a S3LF pero orientado a la consulta de entidades $ sus relaciones. .or tantoF per ite la definici%n de consultas personali6adas pero en lugar de utili6ar tablas $ sus colu nas utili6a las entidadesF sus propiedades $ las relaciones entre entidades.
Estas consultas pueden ser din9 icasF si se definen directa ente dentro de la l%gica de negocio de la aplicaci%nF utili6ando el 4todo create?uery>
p$/lic Fist %in'1ith.ame?String name@ ; ret$rn em*createJ$ery? "S2F2=T c F6>G =$stomer c 1D262 c*name F4H2 :c$st.ame"@ *set9arameter?"c$st.ame"( name@ *setGax6es$lts?-K@ *get6es$ltFist?@; <
@ est9ticasF para lo que se usa el
4todo createEa%ed?uery. En este casoF la consulta se &&
define a trav4s de
etadatos.
@.ame'J$ery? name="%in'Cll=$stomers1ith.ame"( &$ery="S2F2=T c F6>G =$stomer c 1D262 c*name F4H2 :c$st.ame" @ LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL c$stomers = em*create.ame'J$ery?"%in'Cll=$stomers1ith.ame"@ *set9arameter?"c$st.ame"( "Smith"@ *get6es$ltFist?@;
A bos tipos de consultas ad iten incluir par9 etrosF tanto por no bre co o por posici%n>
em*createJ$ery? "S2F2=T c F6>G =$stomer c 1D262 c*name F4H2 :c$st.ame"@ *set9arameter?"c$st.ame"( name@ *get6es$ltFist?@; LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL em*createJ$ery? MS2F2=T c F6>G =$stomer c 1D262 c*name F4H2 N-O@ *set9arameter?-( name@ *get6es$ltFist?@;
Ver ejemplo: str$ts89C
Ver ejemplo: str$ts89CB
&'
2.
omunicacin entre capas y aplicaciones.
4.1. *ntrod)ccin
La arquitectura Java EE per ite el desarrollo de aplicaciones tantoF ser9n necesarios ta bi4n con otras aplicaciones.
ulticapa distribuidas. .or
ecanis os $ tecnolog1as para reali6ar la co unicaci%n entre capasF $
En realidadF de lo que se dispone es de un con!unto de tecnolog1as $ especificaciones para proveer acceso re oto a los co ponentes u ob!etos de la arquitectura Java EEF principal ente de la capa de negocioF $a que para acceder a la capa web se suele utili6ar el protocolo est9ndar #TT..
4.2. -+* 5 EJ2s
La tecnolog1a Java =e ote )et?od /nvocation o Java =)/ es una interfa6 de progra aci%n que per ite la co unicaci%n entre aplicaciones Java SE de una for a si ilar a las lla adas a procedi ientos re otos.
=)/ se basa en que un ob!eto AF para co unicarse con otro <F necesita conocer Jnica ente un subcon!unto del con!unto de operaciones pJblicas de <. As1F < recoge este subcon!unto de operaciones en una interfa6F que ofrece de for a re ota. De este odoF la interfa6 re ota ser9 una 4todo $ que esF por tantoF especiali6aci%n de la interfa6 java.r%i.Re%oteF que no define ningJn
una interfa6 de no bradoL la clase que i ple enta la interfa6 re ota ser9 una especiali6aci%n de alguna de las clases diseIadas espec1fica ente para este tipo de co unicacionesF co o java.r%i.server.BnicastRe%ote,bject.
',
La aplicaci%n cliente deber9 obtener una referencia a la interfa6 re ota. .ara elloF previa ente deber9 ?aberse publicado en algJn puerto de la utili6ando un servidor =)/. 9quina de la aplicaci%n servidoraF
:n ob!eto re oto se publica utili6ando el
4todo bind"Strin(, Re%ote' de la clase
java.r%i.Ea%in(. el pri er par9 etro es la :=L en la que se publica el ob!etoF al que ade 9s se asigna un no breL el segundo representa la instancia del ob!eto re oto que se publica.
.aming*/in'?"rmi://-BP*K*K*-:BKKQ/servi'orejemplo"( instanciaServi'or@;
.revia enteF ?abr9 sido preciso lan6ar el servidor =)/>
Focate6egistry*create6egistry?BKKQ@;
La clase que desee acceder de for a re ota al ob!eto publicado debe locali6arloF lo que consigue utili6ando el 4todo Ea%in(.looCup"Strin('F que devuelve una referencia a un ob!eto Re%ote $ al que debe ?acerse un cast para transfor arlo al ob!eto deseadoF que debe estar en la for a de una interfa6 re ota. Es decir>
'1
4Servi'or servi'or=?4Servi'or@ .aming*loo)$p?"rmi:// -BP*K*K*-:BKKQ/servi'orejemplo"@;
:na ve6 obtenida la referenciaF se pueden reali6ar las lla adas que se deseen a las operaciones ofrecidas en la interfa6 re otaF co o si se tratara de un ob!eto local.
=)/ es una interfa6 para co unicaciones re otasF que requiere de un protocolo de transporte sub$acente. E;isten dos opciones principales> Java =e ote )et?od .rotocol BJ=).C> es el protocolo espec1fico de Java para buscar $ referenciar ob!etos re otos. *onsigue una alta eficiencia $a que la co unicaci%n se ?ace a nivel de 9quinas virtuales de Java BJM)CF lo que i plica que tanto el cliente co o el servidor deben ser aplicaciones Java. =)/D//@.> El protocolo =)/ sobre //@. surge con el ob!etivo de integrar la co unicaci%n =)/ de Java con la arquitectura *@=<A B*o esta arquitectura. on @b!ect =equest <roSer Arc?itectureCF per itiendo as1 la co unicaci%n con otras aplicaciones que no sean Java pero que ad itan
La tecnolog1a EJ< per ite acceder a la l%gica de negocio de for a re otaF a partir de una arquitectura de co ponentes de servidor. El servidor dispone de un contenedor de EJ< $ utili6a =)/ co o base para proporcionar el acceso a los co ponentes desde las aplicaciones clienteF en particular a trav4s de =)/D//@.. .or tantoF =)/ per ite la co unicaci%n con ob!etos re otos distribuidos que podr1an ser co ponentes EJ<.
Ver ejemplo: rmiServer / rmi=lient
4.3. "ervicios 6eb
'"
2.3.1.
$ntroduccin
Los servicios web proporcionan una
anera est9ndar de interoperar entre diferentes
aplicaciones softwareF e!ecut9ndose en una variedad de platafor as $ fra eworSs. Est9n caracteri6ados por su gran interoperabilidad $ e;tensibilidadF as1 co o por su descripci%n independiente de la 9quina gracias al uso de E)L. Los servicios web ofrecen un ecanis o de ba!o acopla iento que per ite a las aplicaciones interaccionar entre s1 para ofrecer servicios sofisticados de valor aIadido.
A nivel conceptualF un servicio es un co ponente software proporcionado a trav4s de un punto de acceso o RendpointR disponible a trav4s de red. El cliente del servicio $ el proveedor utili6an ensa!es para interca biar peticiones $ respuestas. Estos ensa!es son autocontenidos $ ?acen pocas asunciones sobre las capacidades tecnol%gicas de a bos e;tre os.
A nivel t4cnicoF los servicios web pueden i ple entarse de diferentes el pri ero por ser el i ple entaci%n. 9s e;tendidoF para a continuaci%n
aneras. Los dos
tipos principales son los Servicios 0eb E)L $ los Servicios 0eb =ESTful. Se describir9 en detalle ostrar dos alternativas de
Los Servicios 0eb E)L utili6an for ato de
ensa!es basados en este lengua!e de
arcado que siguen
el est9ndar Si ple @b!ect Access .rotocol BS@A.CF un lengua!e E)L que define una arquitectura $ ensa!es. Las operaciones ofrecidas por el servicio est9n descritas en el lengua!e 0eb Services Description Langua!e B0SDLCF que ta bi4n es un lengua!e E)LF en este caso para la definici%n de interfaces de servicios web. Ade 9s de las operacionesF un docu ento 0SDL suele incluir los tipos de datos interca biadosF los co unicaci%n utili6ado. En principioF los cualquier protocolo est9ndarF pero lo ensa!esF los puntos de acceso $ el protocolo de ensa!es S@A. pueden ser interca biados a trav4s de
9s ?abitual es el uso de #TT..
La siguiente figura representa un posible esque a de funciona iento de un Servicio 0eb '(
E)L>
:na aplicaci%n Java puede actuar co o cliente o co o proveedora del servicio. A continuaci%nF se uestran los principales requisitos o tareas a i ple entarF segJn el rol>
*o o .roveedor> Es necesario ?abilitar un punto de acceso o RendpointR que sea capa6 de aceptar peticiones #TT.. Dentro de la tecnolog1a JavaF los Java Servlets per iten recibir $ procesar peticiones de este tipo. Los ensa!es S@A. inclu$en la infor aci%n de la operaci%n con los datos asociadosF ecanis o de
que suelen estar definidos con E)L Sc?e a. Las aplicaciones Java solo pueden traba!ar con datos en for a de ob!etos JavaF por lo que ser9 necesario un transfor aci%n entre tipos Java $ E)L Sc?e a. Las operaciones ofrecidas deber9n tener una i ple entaci%n. En principioF cualquier clase Java puede contener 4todos que i ple enten las operaciones de un Servicio 4todos de 0eb. .articular enteF un EJ< de sesi%n sin estado puede publicar sus negocio a trav4s de un Servicio 0eb. Debe generar el docu ento 0SDL que actJa co o interfa6 $ NcontratoO del Servicio 0eb ofrecido. .or tantoF una aplicaci%n Java que actJe co o proveedora de un servicio web deber9 '4
aceptar peticiones #TT.F procesar su contenido siendo capa6 de transfor ar los datos a ob!etos Java $ generar la invocaci%n al Sc?e a $ ser incluido en un #TT.. 4todo que i ple enta la operaci%n. El 4todo devolver9 un valor de un tipo Java que deber9 transfor arse en su correspondiente E)L ensa!e S@A. que se devolver9 a trav4s de una respuesta
*o o *liente> De for a an9loga al servidorF necesitar9 una traducci%n entre los tipos E)L Sc?e aF definidos en el docu ento 0SDL generado por el servidorF $ los tipos de Java que son los que ane!ar9 el cliente para ?acer la invocaci%n. ensa!e S@A. que define la invocaci%n del
Deber9 generar un petici%n #TT. con el
servicio. Ade 9sF recibir9 la correspondiente respuesta #TT. que puede contener un valor de retorno en un tipo E)L Sc?e a a transfor ar. .ara lla ar al servicio webF nor al ente se invoca un si ple ente deber9 reali6ar la lla ada al 4todo definido en alguna clase
de tipo RStubR que suelen generarse a partir del 0SDL. .or tantoF la aplicaci%n cliente 4todo utili6ando los tipos adecuados para los argu entos $ recogiendo la respuesta si es necesario.
La platafor a Java dispone de fra eworSs $ especificaciones que se ocupan de las tareas 9s tediosas a la ?ora de crear servicios webF per itiendo que el desarrollador se centre en la i ple entaci%n de la l%gica del servicio web o de la lla ada al e;pondr9n las 9s relevantes. is o. A continuaci%n se
2.3.2.
A;is
Apac?e A;is es un fra eworS de tipo open source que constitu$e el est9ndar de facto para el uso de Servicios 0eb E)L en Java. A;is i ple enta un servidor S@A. para el procesa iento de ensa!esF as1 co o un con!unto de utilidades $ A./s para la generaci%n $ despliegue de '-
aplicaciones con Servicios 0eb.
A;is per ite la definici%n de servicios a trav4s de un contenedor Apac?e To cat o con un invocaci%n a la clase Java que
4todo nativo que requiere el uso del
4todo general independiente del contenedor. En cualquier 4todo que i ple enta la operaci%n del servicio.
casoF provoca la configuraci%n de un Servlet que captura la petici%n $ la procesaF generando la antiene el Ade 9sF per ite generar el docu ento 0SDL asociado al servicio web.
Desde el punto de vista del clienteF A;is per iteF a partir de un docu ento 0SDLF generar las clases RStubR para la invocaci%n del servicio web.
Est9 disponible la versi%n A;is" que supone un rediseIo co pleto del fra eworSF $ que ade 9s proporciona la capacidad de actuar co o una aplicaci%n servidora de sus propios servicios web.
A;is dispone de una arquitectura
odular que le per ite aIadir funcionalidades $ capas a %dulo Apac?e =a part que aIade
los servicios web desplegados. Destaca especial ente el
caracter1sticas de seguridad confor es a la especificaci%n 0SDSecurit$.
Ver ejemplo: Ae/ServiceCxisB / str$tsCxisB
2.3.3.
JAFA%,
JAED0S o Java A./ for E)L 0eb Services es la especificaci%n de la platafor a Java EE para la construcci%n de servicios web $ clientes que se co unican utili6ando E)L. JAED0S utili6a anotaciones para establecer las clases que i ple entan el servicio web '7
4-ebService, as1 co o los
4todos que representan las operaciones 4-eb)ethod.
Ade 9sF se define la especificaci%n de un entorno de e!ecuci%n que pueden i ple entar los servidores Java EEF ocup9ndose de la generaci%n $ trata iento de los infor aci%n e;presada con las anotaciones. El servidor J<oss AS i ple enta la especificaci%n JAED0S ofreciendo utilidades para la generaci%n de servicios web a partir de unas clases con las anotaciones correspondientesF $ ta bi4n la generaci%n de las clases RStubR del cliente a partir de un docu ento 0SDL. ensa!es S@A. a partir de la
Ver ejemplo: Ae/Service8CR1S / str$ts8CR1S
4. <i&liogra(8a y re(erencias
Apac?e Software 8oundation B",,&C. Struts Bser Guide. Accesible en ?ttp>TTstruts.apac?e.orgT1.;TuserGuideTinde;.?t l
Apac?e Software 8oundation B",1"C. ;pache ;xisF BserGs Guide. Accesible en ?ttp>TTa;is.apac?e.orgTa;is"T!avaTcoreTdocsTuserguide.?t l
J<oss *o
unit$ B",1"C. =:oss;S H. Gettin( Started Guide. Accesible en
?ttps>TTdocs.!boss.orgTaut?orTdispla$TAS+TGettingHStartedHGuide
@racle *orporation B",,7C. A!a; Design Strategies. Accesible en ?ttp>TT!ava.sun.co TdeveloperTtec?nicalArticlesTJ"EETAJAETDesignStrategiesTinde;.?t l
@racle *orporation B",1,C. !ore =F55 Patterns - *ront !ontroller. Accesible en
'+
?ttp>TT!ava.sun.co TblueprintsTcore!"eepatternsT.atternsT8ront*ontroller.?t l.
@racle *orporation B",1,C. !ore =F55 Patterns - +ata ;ccess ,bject. Accesible en ?ttp>TT!ava.sun.co TblueprintsTcore!"eepatternsT.atternsTDataAccess@b!ect.?t l.
@racle *orporation B",1,C. he =ava 55 I utorial. Accesible en ?ttp>TTdocs.oracle.co T!avaeeT-TtutorialTdocT
@racle *orporation B",1"C. he =ava 55 J utorial. Accesible en ?ttp>TTdocs.oracle.co T!avaeeT7TtutorialTdocT
@racle *orporation B",1"C. =ava 55 !o%patibility. Accesible en ?ttp>TTwww.oracle.co Ttec?networST!avaT!avaeeToverviewTco patibilit$D!spD1(7'&4.?t l
.4re6F J.). B",,&C. !urso de herra%ientas de desarrollo web actualiDado.
.4re6F J.). B",,'C. +esarrollo de aplicaciones con tecnolo(Ka =ava.
.oloF ). B",,+C. ;puntes de 9n(enierKa de Software 99. Accesible en ?ttp>TTwww.infD cr.ucl .esTwwwT poloTasigT,+,&Tiso-.?t l.
=ed #at /nc. B",,-C. 9ntroducin( =P; Persistence. Accesible en ?ttp>TTdocs.!boss.orgT?ibernateTstableTentit$ anagerTreferenceTenT?t lTpr,1.?t l.
0iSibooSs B",1,C. =ava Persistence$Persistence Products. Accesible en ?ttp>TTen.wiSibooSs.orgTwiSiTJavaU.ersistenceT.ersistenceU.roducts.
'&

App Web Java EE

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

App Web Java EE

Cargado por

Copyright:

Formatos disponibles

DESARROLLO DE APLICACIONES WEB CON JAVA ENTERPRISE EDITION

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Objetivo del curso

1.1. La plataforma Java

La i ple entaci%n original $ de referencia del co piladorF la

9quina virtual $ las

Desarrollo de aplicaciones web con Java Enterprise Edition

a$or1a de las tecnolog1as Java ba!o la

ientras que es el entorno de e!ecuci%nF

e oria debe ser liberada. Al estar dirigida a operar ba!o entornos

distribuidosF la tecnolog1a Java dispone de una serie de caracter1sticas de seguridad tanto en -

Desarrollo de aplicaciones web con Java Enterprise Edition

entre ellos destaca la posibilidad de e!ecutar

Desarrollo de aplicaciones web con Java Enterprise Edition

9quinas virtuales de Java para las is o bytecode sobre diferentes

Desarrollo de aplicaciones web con Java Enterprise Edition

Herramientas de desarrollo y ejecucin

Desarrollo de aplicaciones web con Java Enterprise Edition

uestra un diagra a de la platafor a Java>

Desarrollo de aplicaciones web con Java Enterprise Edition

Java )icro Edition BJava )EC> diseIada para su uso en dispositivos

Desarrollo de aplicaciones web con Java Enterprise Edition

9s recienteF estando dirigida al desarrollo de aplicaciones del lado anipulaci%n de

1.3. Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

odelo de aplicaci%n que parte del lengua!e Java $ del concepto de

9quina virtual que proporcionan la portabilidad $ la seguridad.

ulticapa $ distribuidoF la l%gica de la aplicaci%n est9 dividida en

Desarrollo de aplicaciones web con Java Enterprise Edition

Los co ponentes Java EE est9n escritos en lengua!e Java $ se co pilan de la

Desarrollo de aplicaciones web con Java Enterprise Edition

apas en la arquitectura Java EE

odelo de aplicaci%n de la platafor a Java EE define una arquitectura

continuaci%n se e;ponen las responsabilidades $ co ponentes

9s i portantes asociados a cada

9s rica que la que proporcionan los

arcado. Ade 9sF estas aplicaciones tienen la posibilidad de acceder

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Capa de sistemas de informacin empresarial.

ulticapa de cliente ligero cl9sicas se requieren

uc?as l1neas de c%digo

ulti?iloF del pool de recursos $ de

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

Estos tipos de contenedores son i ple entados por diferentes fabricantesF de

Estos servidores de aplicaciones Java EE disponen de contenedores de EJ<s $ webF pero

Desarrollo de aplicaciones web con Java Enterprise Edition

Kor al enteF el desarrollador no

ane!a directa ente el servidor que se va a utili6ar en ecanis os de

%dulos Java EE $ descriptores de despliegue.

Desarrollo de aplicaciones web con Java Enterprise Edition

contenedor $ un descriptor de despliegue asociado. La especificaci%n define cuatro tipos de

Desarrollo de aplicaciones web con Java Enterprise Edition

Mea os una ilustraci%n con las A./s

9s i portantes $ su relaci%n con los contenedores>

Desarrollo de aplicaciones web con Java Enterprise Edition

Desarrollo de aplicaciones web con Java Enterprise Edition

8or ateador de c%digo fuente.

Desarrollo de aplicaciones web con Java Enterprise Edition