Fund a Mentos de Java Server Faces

iFUNDAMENTOS DEJAVA SERVER FACES

Mg. Abraham Esteban Gamarra MorenoIng. Jorge Alberto Vega FloresIng. Wilber Huamani Huamani

2011

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani iii

FUNDAMENTOS DE JAVA SERVER FACES

Mg. Abraham Esteban Gamarra MorenoMagster en Informtica

Docente de la Facultad de Ingeniera de Sistemas de la Universidad Nacional del Centro delPer

email: [email protected]

Ing. Jorge Alberto Vega FloresIngeniero de Sistemas

Jefe de la Oficina General de Informtica de la Universidad Nacional del Centro del [email protected]

Ing. Wilber Huamani HuamaniIngeniero de Sistemas

Analista de Sistemas de la Oficina General de Informtica de la Universidad Nacional delCentro del Per

[email protected].

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani iv

FUNDAMENTOS DE JAVA SERVER FACESMg. Abraham Esteban Gamarra MorenoIng. Jorge Alberto Vega FloresIng. Wilber Huamani Huamani

Derechos reservados.

Tiraje: 500 ejemplares.Explicacin de la tapa.La tapa muestra la abreviatura de Java Server Faces.

ISBN No.

Hecho el Depsito Legal en la Biblioteca Nacional del Per N 2011-146041ra edicin, Noviembre de 2011.Publicacin Electrnica editada por Abraham Esteban Gamarra Moreno. ResidencialCorona del Fraile, calle las Cigeas Mz D Lote 9, en la ciudad de Huancayo, Per.

Publicacin electrnica producida en INDUSTRIA GRFICA "CENTRO", Jr. PunoN796 - Huancayo.

Huancayo, 19 de Noviembre de 2011.

Diagramacin:Mg. Abraham Esteban Gamarra MorenoIng. Jorge Alberto Vega FloresIng. Wilber Huamani Huamani

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani v

DEDICATORIAA todas las personas que tieneninters por aprender a programar conherramientas libres.

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani vi

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani vii

NDICE

NDICE.............................................................................................................................................................. VIISOBRE LOS AUTORES .................................................................................................................................... XINTRODUCCIN................................................................................................................................................ 1CAPITULO I ........................................................................................................................................................ 3INTRODUCCIN A JEE.................................................................................................................................... 3

1.1. ARQUITECTURA DE UNA APLICACIN WEB JEE ............................................................................... 31.1.1. Qu es Java?................................................................................................................................. 31.1.2. Estndares ...................................................................................................................................... 51.1.3. Qu es lo nuevo en JEE 6? ........................................................................................................... 5

1.2. ARQUITECTURAN-TIER ................................................................................................................... 61.2.1. Plataforma JEE, El modelo de aplicacin...................................................................................... 61.2.2. Aplicaciones de mltiples capas distribuidas ................................................................................. 71.2.3. Beneficios de esta Arquitectura ...................................................................................................... 91.2.4. Componentes Java EE .................................................................................................................... 9

1.3. COMPONENTES DE LA CAPA CLIENTE (CLIENT-TIER COMPONENTS) .............................................. 101.3.1. Clientes Web:................................................................................................................................ 101.3.2. Aplicacin Cliente: ....................................................................................................................... 111.3.3. Comunicaciones del componente de la capa cliente con el servidor JEE. ................................. 12

1.4. COMPONENTES DE LA CAPAWEB.................................................................................................. 131.5. COMPONENTES DE LA CAPA DENEGOCIO...................................................................................... 141.6. CAPA EIS ...................................................................................................................................... 141.7. CONTENEDORES JEE ..................................................................................................................... 14

1.7.1. Tipos de contenedor...................................................................................................................... 161.8. ENSAMBLAJE Y DESPLIEGUE DE UNA APLICACIN JAVA JEE ......................................................... 171.9. EMPAQUETADO DE APLICACIONES................................................................................................. 171.10. SEGURIDAD ENAPLICACIONES JAVA EE ....................................................................................... 181.11. DISEANDO APLICACIONES JEE .................................................................................................... 191.12. PATRONES DE DISEO .................................................................................................................... 20

1.12.1. Patrones de diseo en Java EE ................................................................................................ 201.13. DISEANDO UN APLICACIN JAVA EE CON LOS PATRONES JAVA EE............................................ 21

1.13.1. Implementando un Patrn sesin Facade ................................................................................ 221.13.2. Definiendo la arquitectura MVC ............................................................................................. 221.13.3. Implementando la User Interface con JSF y patrones Java EE.............................................. 23

1.14. INSTALACIN DEL ENTORNO DE DESARROLLO ............................................................................... 24CAPITULO II ..................................................................................................................................................... 25API DE PERSISTENCIA DE JPA.................................................................................................................... 25

2.1. PERSISTENCIA EN JAVA.................................................................................................................. 252.2. QU ES UNA BASE DE DATOS? ...................................................................................................... 262.3. QU ES JPA?................................................................................................................................ 262.4. PROVEEDORES DE PERSISTENCIA ................................................................................................... 28

2.4.1. Eclipse Link .................................................................................................................................. 282.4.2. TopLink ......................................................................................................................................... 292.4.3. Top Link Essentials....................................................................................................................... 29

2.5. MAPEO .......................................................................................................................................... 292.6. CMO TRABAJA JPA? .................................................................................................................. 312.7. ENTITYMANAGER......................................................................................................................... 322.8. UNIDAD DE PERSISTENCIA............................................................................................................. 33

2.8.1. Customizado ................................................................................................................................. 34

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani viii

2.9. AADIENDO FUNCIONALIDADES.................................................................................................... 342.10. ANOTACIONES CALLBACK............................................................................................................. 352.11. ANOTACIONES CALLBACK, AADIR ANOTACIONES ...................................................................... 362.12. RELACINONE TOONE ................................................................................................................ 362.13. QUERYING OBJECTS ....................................................................................................................... 392.14. JPA VS JDBC .............................................................................................................................. 392.15. JDBC JAVA DATABASE CONECTIVITY ......................................................................................... 41

CAPITULO III ................................................................................................................................................... 45JAVA SERVER FACES .................................................................................................................................... 45

3.1. ESTRUCTURA DEDIRECTORIOS DE UNAPLICACIN JSF................................................................ 483.2. ELCICLO DEVIDA......................................................................................................................... 493.3. LOSMANAGED BEANS............................................................................................................ 513.4. CONFIGURACIN DE SERVLET PARA UTILIZAR JSF........................................................................ 523.5. SERVICIOS DEL FRAMEWORK JSF.................................................................................................. 54

3.5.1. Detrs de la Escena ...................................................................................................................... 553.6. RENDEREO DE PGINAS: ................................................................................................................ 563.7. DECODIFICANDO PETICIONES ........................................................................................................ 573.8. MANAGED BEANS ......................................................................................................................... 58

3.8.1. Definicin de un bean. .................................................................................................................. 583.8.2. Propiedades del Bean ................................................................................................................... 603.8.3. Value expressions: ........................................................................................................................ 62

3.9. BACKING BEANS ............................................................................................................................ 633.10. CDI BEANS (CONTEXT ANDDEPENDENCY INJECTION) ................................................................. 633.11. REPOSITORIOS DE MENSAJES: MESSAGEBUNDLES......................................................................... 643.12. MENSAJES CON PARTES VARIABLES............................................................................................... 663.13. CONFIGURANDO LA LOCALIZACIN PARA NUESTRA APLICACIN: ................................................. 663.14. APLICACIN DE EJEMPLO............................................................................................................... 683.15. MBITOS DE UN BEAN ................................................................................................................... 75

3.15.1. Session Scope ........................................................................................................................... 753.15.2. mbito de peticin (Request Scope) ......................................................................................... 763.15.3. Ambito de aplicacion (Aplication scope) ................................................................................. 77

3.16. MBITO DE CONVERSACIN CONVERSATION-SCOPE ..................................................................... 773.17. MBITO DE VISTA OVIEW SCOPE .................................................................................................. 783.18. MBITOS PERSONALIZADO O CUSTOM SCOPED.............................................................................. 793.19. CONFIGURANDO LOS BEANS.......................................................................................................... 803.20. INYECTANDO A LOS CDI BEANS .................................................................................................... 803.21. INYECTANDO MANAGED BEANS: ................................................................................................... 803.22. CICLO DE VIDA DE LAS ANOTACIONES DE UN BEAN ....................................................................... 813.23. CONFIGURANDO UNMANAGED BEAN CONXML.......................................................................... 813.24. LLAMANDO MTODOS EN JSF 2.0.................................................................................................. 823.25. LOSMETHOD EXPRESSIONS .......................................................................................................... 833.26. PARMETROS DE LOSMETHOD EXPRESSION EN JSF 2.0 ............................................................... 843.27. CONVERSIN Y VALIDACIN DE DATOS ......................................................................................... 843.28. CONVERSIN EN JSF ..................................................................................................................... 843.29. VALIDACIN.................................................................................................................................. 85

CAPITULO IV.................................................................................................................................................... 89JSF Y AJAX........................................................................................................................................................ 89

4.1. UN PRIMER ACERCAMIENTO AJAX CON JSF.................................................................................. 894.2. FRAMEWORKS AJAX PARA JAVA......................................................................................... 914.3. FRAMEWORKAJAX........................................................................................................................ 924.4. PRIMEFACES.............................................................................................................................. 93

CAPITULO V ..................................................................................................................................................... 95REPORTES Y GRFICOS............................................................................................................................... 95

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani ix

5.1. JASPERREPORTS, IREPORT ............................................................................................................. 955.2. ARMANDO UN REPORTE ................................................................................................................ 965.3. COMPILACIN.............................................................................................................................. 1015.4. GENERACIN ............................................................................................................................... 1025.5. VISUALIZACIN ........................................................................................................................... 1025.6. REPORTES EN PDF....................................................................................................................... 1045.7. REPORTES EN HOJA DE CALCULO XLS .......................................................................................... 1065.8. GRFICOS ESTADSTICOS ............................................................................................................ 108

BIBLIOGRAFA .............................................................................................................................................. 113

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani x

Sobre los autores

Mg. Abraham Esteban Gamarra MorenoMagster en Informtica.Co-autor del libro PROGRAMACIN CON ASP .NET, ISBN: 9972-33-311-6 ydepsito legal en la Biblioteca Nacional del Per No. 2006-8398.Co-autor del libro ESTRUCTURA DE DATOS EN JAVA, ISBN: 978-9972-9796-3-7y depsito legal en la Biblioteca Nacional del Per No. 2007-06054.Autor del libro titulado Tpicos y Aplicaciones de la Inteligencia Artificial, ISBN:978-9972-9796-6-8 y depsito legal en la Biblioteca Nacional del Per No. 2008-10800.Co-autor del libro titulado Programacin de Aplicaciones con PHP, ISBN: 978-9972-9796-8-2 y depsito legal en la Biblioteca Nacional del Per No. 2009-01574Asesor y consultor en Informtica y Sistemas.

Ing. Jorge Alberto Vega FloresIngeniero de Sistemas.Jefe de la Oficina General de Informtica de la Universidad Nacional del Centro delPer.Asesor y consultor en Informtica y Sistemas

Ing. Wilber Huamani HuamaniIngeniero de Sistemas.Analista de Sistemas de la Oficina General de Informtica de la UniversidadNacional del Centro del Per.Asesor y consultor en Informtica y Sistemas

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani xi

Mg. Abraham Gamarra Ing. Jorge Vega Ing. Wilber Huamani 1

INTRODUCCIN

La tecnologa JavaServer Faces es un marco de trabajo deinterfaces de usuario del lado de servidor para aplicacionesWeb basadas en tecnologa Java.Este modelo de programacin bien definido y la librera deetiquetas para componentes UI facilita de forma significativala tarea de la construccin y mantenimiento de aplicacionesWeb con UIs del lado del servidor.Una de las grandes ventajas de la tecnologa Java Server Faceses que ofrece una clara separacin entre el comportamiento yla presentacin.La tecnologa Java Server Faces nos permite construiraplicaciones Web que implementan una separacin entre elcomportamiento y la presentacin tradicionalmente ofrecida porarquitectura UI del lado del cliente.El primer captulo muestra una Introduccin a JEE, el segundocaptulo describe el Api de persistencia de JPA, el captulotres describe el Java Server Faces. El captulo cuatrocontiene JSF y Ajax, el captulo cinco describe el uso dereportes y grficos.

Mg. Abraham Esteban Gamarra MorenoIng. Jorge Alberto Vega FloresIng. Wilber Huamani Huamani


CAPITULO IINTRODUCCIN A JEE

1.1. Arquitectura de una aplicacin web JEE1.1.1. Qu es Java?Java es un lenguaje de programacin orientado a objetos lanzado por primeravez por Sun Microsystems en 1995. Fusion conceptos de lenguajesexistentes como C++ y Smalltalk en un nuevo lenguaje de programacin yobtuvo mucha popularidad porque desde sus inicios fue de la mano conInternet.La edicin empresarial J2EE, la edicin anterior a JEE 5 no materializarontodas sus promesas. Los sistemas creados con esta versin fueron todavacomplicados, y el tiempo de desarrollo fue a menudo fuera de toda proporcinde la complejidad de los requerimientos de usuario. J2EE fue visto entoncescomo una plataforma con un modelo de componentes duro pesado porque:era dificultoso de testear, dificultoso de desplegar, dificultoso de correr. Es poreso que los frameworks as como Struts, Spring o Hibernate emergieron y nosmostraron una nueva forma de desarrollar aplicaciones empresariales.Afortunadamente, en la segundo cuatrimestre de 2006 , Java EE5 fue liberadotomando algunas caractersticas de los frameworks Open Source volviendopor ejemplo a usar el modelo de programacin con POJO (Plain Old JavaObject). La metadata fue definida con anotaciones y descriptores XML fueronopcionales. Desde un punto de vista del desarrollador, los EJB3 y la nuevaJPA fueron las principales medidas de evolucin de la plataforma empresarialJava. JSF fue introducido como el framework estndar de la capa depresentacin. Y JAX-WS 2.0 reemplazo a JAX-RPC como la API paraservicios Web SOAP.La edicin empresarial JEE 5 de java --que ser la que exploraremos en estetexto-- fue concebida para proporcionar un modelo abierto de aplicacin de


servidor portable entre varios proveedores de la plataforma JEE. El estndarJEE es bsicamente un compilado de otras especificaciones todos bajos unamisma nombre que tiene proveedores de este estndar como IBMWebsphere, RetHat JBoss, SunGlassfish, Oracle BEA y Oracle AS y muchosotros ms.La plataforma empresarial de java conocida como JEE es el estndar de laindustria para desarrollar aplicaciones portables, robustas, escalables yseguras. JEE est construido sobre una base slida como lo es la plataformaestndar de java JSE. JEE proporciona servicios Web, modelos decomponentes, APIS de gestin y comunicacin que lo convierten en elestndar de la industria para implementar aplicaciones empresariales conService Oriented Architecture(SOA) y aplicaciones Web 2.0El objetivo de la plataforma Java EE 5 es proporcionar a los desarrolladores unconjunto de APIS que reduzcan el tiempo de desarrollo y mejoren elrendimiento de las aplicaciones introduciendo un modelo de programacinsimplificado.Esta simplificacin se ve reflejada a diferencia de las versiones anteriores enlos siguientes aspectos: Con la tecnologa Java EE 5, los descriptores de despliegue utilizados en

tecnologas como Servlets y JSPs ya no son necesarios. En lugar de estoel desarrollador puede simplemente introducir la informacin como unaanotacin dentro del fichero fuente de cdigo java y el servidor deaplicaciones JEE configurar el componente en le momento del desplieguey en tiempo de ejecucin. Estas anotaciones son utilizadas para incrustaren un programa informacin que de otra manera deberan estar colocadosen un descriptor de despliegue (web.xml).

En la plataforma Java EE las inyecciones de dependencias permiten alcontenedor Java EE insertar automticamente referencias a otroscomponentes requeridos o recursos utilizando anotaciones xml.

La API de Persistencia de Java que es nueva en esta versin de JEE 5permite un mapeo de entidades relacionales (tablas de una BD) a beanempresariales, componentes Web y clientes de aplicacin. Esta APItambin puede ser usado en aplicaciones Java SE fuera del ambiente JEE.

Hoy en da java EE6 sigue el camino del desarrollo fcil y el concepto deanotaciones, programacin basada en POJO y el mecanismo de configuracinpor excepcin a travs de la plataforma, incluyendo la capa Web. Esto vieneen conjunto rico de innovaciones as como el nuevo JAX-RS 1.1, estosimplifica la madurez de las APIs como el EJB 3.1 y enriquece otros as comoJPA 2.0, pero lo mejor de JEE 6 es el tema de la portabilidad (a travs delestndar de nombrado para JNDI), la deprecacin de algunasespecificaciones y la creacin de subconjuntos de la plataforma a travs deperfiles.


1.1.2. EstndaresJava EE est basado en estndares, quiz la pregunta es porque losestndares son importantes, as como los ms exitosos frameworks no siguenestndares (as como Struts, Spring, etc. Y en PHP ocurre lo mismo consymfony por ejemplo) a travs de la historia la humanidad ha creadoestndares para hacer fcil sus comunicaciones y sus interacciones. Algunosejemplos notables son el lenguaje, la moneda, el tiempo, la navegacin, lasmedidas, las herramientas, la electricidad, los telfonos, protocolos, ylenguajes de programacin.En los tiempos previos a Java se haca algo para la Web o algn desarrolloempresarial se viva en un mundo propietario por la creacin de tu propioFramework o la adopcin de un Framework propietario comercial. Luegovinieron los das de los frameworks Open Source, los cuales no siempreestuvieron basados en estndares abiertos. Tu puedes usar un frameworkOpen Source y que sea limitado para su implementacin o puedes usar unframework Open Source que implemente estndares y sea portable. Java EEproporciona estndares abiertos que son implementados por muchosframeworks Open Source (Glassfish, Jboss, Hibernate, OpenJPA, Jersey, etc)o comerciales (Weblogic BEA, Wepshere, MqSeries, etc) para manejartransacciones, seguridad, componentes, persistencia de objetos y algunascosas ms.Hoy en da ms que nunca en la historia de Java EE, las aplicaciones sondesplegables en cualquier servidor de aplicacin compatible con muy pocoscambios, antes esto no era as, antes de desarrollar una solucin Web en JEEhaba que seleccionar el servidor especifico en el que iba a ser probado, ydesplegado para produccin y si queras cambiar de servidor pues haba quemodificar mucho en los descriptores principalmente o eliminarlos y luegohacer un built con ant o maven especificando el nuevo servidor en el que seiba desplegar nuestra solucin.Si bien es cierto aun por defecto al empezar una solucin con JEE 6 se debeespecificar con que servidor se va trabajar, el cambio de servidor requieremuy pocas modificaciones a comparacin de otra versiones de JEE.1.1.3. Qu es lo nuevo en JEE 6?Ya en Java 5 se introdujeron varios elementos sintcticos muy tiles como: Tipos Genricos. Bucle for mejorado Argumentos variables Boxing/Unboxing Enumeraciones seguras respecto a los tipos.


Importacin esttica. MetadatosAhora en Java 6 podemos apreciar que el principal logro de esta versin es lacontinuidad del desarrollo gil introducido con la versin 5. Java EE 6 seenfoca tambin en la simplicidad de portabilidad de la plataforma mediantela introduccin de los profiles y los pruning a los cuales se les han aadidoms caractersticas y tambin nuevas cosas. Ms que antes una aplicacinjava EE 6 es ms portable entre contenedores gracias al estndar JNDI y uncontenedor de EJB embebido especifico.1.2. Arquitectura N-tier1.2.1. Plataforma JEE, El modelo de aplicacinJava EE esta diseado para soportar aplicaciones que implementen serviciosempresariales para clientes, empleados, proveedores socios y otros quegeneran demanda o contribuyen a la empresa (figura I.1). Siendo as estasaplicaciones se vuelven cada vez mas complejas, potencialmente acceden adatos de muchas fuentes y distribuyen aplicaciones a una gran variedad declientes.

Figura I.1. Soporte de las aplicaciones JEE.

Java EE define una plataforma para el desarrollo, despliegue y ejecucin deaplicaciones en un modelo de aplicacin multicapa y distribuido.El modelo de aplicacin JEE define una arquitectura para implementarservicios como aplicaciones de capas mltiples que distribuyen laescalabilidad, accesibilidad y facilidad de manejo necesaria para aplicaciones


a nivel empresarial. Este modelo divide el trabajo necesario para implementarun servicio de mltiples capas en dos partes bien diferenciadas: la lgica denegocio y la lgica de presentacin.1.2.2. Aplicaciones de mltiples capas distribuidasYa hemos dicho que la Plataforma JEE utiliza un modelo de aplicaciones demltiples capas para aplicaciones empresariales. La lgica de aplicacin esdividida en componentes de acuerdo con su funcin y estos componentes queen su conjunto hacen al aplicacin JEE son instalados en diferentes maquinasdependiendo de la capa JEE al cual el componente de aplicacin pertenece.En otras palabras y para ser ms exactos la logia de la aplicacin JEE puedeser dividida en componentes basados en sus funciones y distribuidos a lacapa apropiada de una arquitectura multicapa (figura I.2): Capa cliente o client-tier son componentes que se ejecutan en la mquina

cliente as como un navegador web que nos muestra HTML. La lgica de presentacin est construida con componentes de la capa

Web o Web-tier, as como Java Server Faces (JSF), Servlets y JSPs quecorren sobre un servidor JEE.

La lgica de Negocio esta distribuida como componentes de la capa denegocio o la Bussines tier que tambin corren sobre un servidor JEE. loscomponentes de esta capa normalmente tiene acceso a todos losservicios de la empresa, es aqu donde el concepto de SOA cobra muchaimportancia. Un ejemplo de los componentes de esta capa son losEnterprise Java Beans (EJB), una regla de negocio que puede incluir uncomponente de software llamado Procesamiento de Pedidos que a lavez puede ser usado por mltiples aplicaciones que permitan a losclientes hacer pedidos de productos o servicios de la compaa, he aquun ejemplo de reusabilidad.

La capa de persistencia o la Peristence-tier se componen decomponentes que bsicamente mapean entidades relaciones de una BDo de otra ndole (sistemas heredados) en EJB de entidad que permiten alos componentes de la capas superiores poder hablar el mismo lenguajeJava orientado a objetos. Un ejemplo de componentes de esta capa sonlos EJB de entidad y las APIs directamente involucradas son JPA y JTA.

La capa de sistemas de informacin empresariales (EIS-tier), es en estacapa donde los datos son almacenados y corren sobre una base de datoscomo Mysql, Postgres, Oracle, Firebird o son sistemas heredados comoaplicaciones hechas en VisualFox por ejemplo.

A pesar de que una aplicacin JEE puede consistir de las tres, cuatro o cincocapas mostradas en la figura I.2, la aplicaciones JEE son consideradasgeneralmente de tres capas porque son distribuidas entre ubicaciones fsicasdiferentes: maquinas cliente, la maquina donde corre el servidor JEE, y la


maquina donde corre el gestor de base de datos o una aplicacin heredada(visual fox).

Figura I.2. Arquitectura multicapa.

Las aplicaciones JEE que se ejecutan de esta forma extienden el modeloCliente-Servidor de dos capas al colocar un servidor de aplicaciones entre elcliente y el almacenamiento.Cabe mencionar tambin que las aplicaciones JEE son desplegadas en ellenguaje de programacin Java, cuando la plataforma JKEE es usada , loscomponentes JEE son ensamblados en un aplicacin JEE, luego sonverificados de acuerdo con la especificacin estndar JEE y por ultimo sondesplegados sobre un servidor JEE. As la aplicacin JEE desplegada esejecutada y gestionada por un servidor de aplicaciones JEE como Glassfish,BEA, WebPshere, Jboss, etc.


1.2.3. Beneficios de esta ArquitecturaJava EE toma ventaja de muchas caractersticas de java SE (Java Platform,Estndar Edition), as como la portabilidad escrbelo una vez y crrelo dondequieras. Esta portabilidad esta asegurada porque varios proveedoressoportan la especificacin Java EE , haciendo que las aplicaciones sean defcil integracin y distribuidas puesto que tenemos muchas opciones para eldespliegue.La integracin con sistemas heredados esta facilitado gracias a las APIs queJEE utiliza.JEE proporciona as mltiples escenarios de diseo y desarrollo, separandolas tareas de desarrollo en reas especficas proporcionando unaespecializacin por tipo de componente y funcionalidad como: Web Component Developers: utilizan los componentes de la capa de

negocio para enfocarse en la presentacin de la data y la interfaz deusuario.

Enterprise Beandevelopers: crea lgica de negocio, enfocndose en lasreglas de negocio de la empresa

Application assembler: los components generados por los dos expertosanteriores son ensamblados aqu para su despliegue inicial.

Application Deployer: es la compaa o persona que configura y despliegala aplicacin JEE, dentro de este equipo existe un ApplicationAdministrator que es la persona que administra el hardware de servidorJEE, el computo la infraestructura de red y el networking donde corre unaaplicacion JEE.

La arquitectura de JEE tambin permite que una variedad de clientes puedancompartir la lgica de negocio.1.2.4. Componentes Java EELas aplicaciones JEE estaban hechas en base a componentes, uncomponente es una unidad de software funcional que es ensamblada en unaaplicacin JEE con sus clases relacionadas y posee capacidades decomunicacin con otros componentes asimismo puede ser fcilmenteactualizado de acuerdo a los cambios en las reglas de negocio y lo msimportante es reusable.La especificacin JEE define los siguientes componentes: Aplicaciones Clientes JSE: son componentes que se ejecutan en la

maquina cliente y por lo tanto son componentes de la capa cliente o client-tier, aqu esta considerado el browser como una aplicacin JSE queentrega HTML dinmico o ejecuta applets.


Los Servlets, JSF y laos JSP son componentes de la capa web o web tierque corren sobre un servidor JEE.

Los EJB (Beans empresariales) son componentes de la capa de negocio obussiness-tier y tambin se ejecutan en el servidor JEE.

Las clases de utilidad POJO as como los beans (ManagedBeans ybackingbeans usados con JSF) no forman parte de la especificacin JEEsiendo opcionales su uso.Los componentes JEE son escritos en el lenguaje de programacin Java yson compilados de la misma forma que un programa JSE.La diferencia entre los componentes JEE y las clases estndar JSE es que loscomponentes JEE son ensamblados dentro de una aplicacin JEE sonverificados para estar seguros de que estn bien formados conforme con laespecificacin JEE y son desplegados en produccin donde son ejecutadospor el servidor Java EE como Glassfish, Bea Weblogic, Jboss, Geronimo, etc.1.3. Componentes de la capa Cliente (Client-tier components)Un componente de la capa cliente puede ser un Cliente Web o unaAplicacin Cliente, examinemos cada uno de ellos:1.3.1. Clientes Web:Un cliente Web se compone de dos partes: Una pgina web dinmica que contiene un lenguaje de marcas cono

XHTML, XML y dems, estas paginas son generados dinmicamente porcomponentes que se ejecutan en la capa web como los JSP, Servlets o losJSF.

Un navegador Web que despliega las paginas recibidas del servidor JEE.Un cliente web es a menudo llamado thin client o cliente ligero a diferencia delas aplicaciones JSE llamadas rich client o cliente rico aunque con las nuevastecnologas basadas en ajax la tendencia es llevar una experiencia de richclient a la web.Los thin client en JEE usualmente no consultan bases de datos directamente,ellos ejecutan reglas de negocio complejas o se conectan aplicacioneslegadas.Cuando se utiliza un thin client estas operaciones pesadas son delegadas alos beans empresariales (EJB) que se ejecutan en el servidor JEE y puedensoportar la seguridad, velocidad, servicios y ofrecer el nivel de confianza de latecnologa JEE de lado de servidor.


1.3.2. Aplicacin Cliente:Una aplicacin cliente JSE se ejecuta en una PC cliente y proporciona a losusuarios una interfaz de usuario rica. Esta interfaz generalmente fue creadacon la API de Swing, aunque una interface de lnea de comandos ciertamentees posible.En una arquitectura de dos capas cliente servidor o una arquitecturastandalone una aplicacin cliente accede directamente a la base de datos y escomn encontrar este tipo de aplicaciones en el rea de ventas y facturacinde una empresa imprimiendo boletas de ventas, tickets, y registrando lasventas directamente n la base de datos.En una arquitectura JEE una aplicacin cliente JSE ya no accedendirectamente a la Base de datos sino acceden directamente a los BEANSempresariales (EJB) que se ejecutan en la capa de negocio, la conexin de uncliente JSE a los EJB empresariales se realiza mediante un protocolo llamadoRMI (Remote method Invocation). Si bien esto debera ser as por el bien de laarquitectura, nada impide a una aplicacin JSE acceder directamente ala BDutilizando un driver JDBC.Una aplicacin cliente JSE tambin puede comunicarse directamente con lacapa web si los requerimientos de un aplicacin as lo exigen, en tal caso secomunicara con un Servlet abriendo para ello una conexin va el protocoloHTTP.Las aplicaciones cliente escritos en otros lenguajes de programacindiferentes a Java, por ejemplo Visual Fox o C# pueden interactuar conservidores Java E, habilitando la plataforma JEE a interactuar con sistemasheredados, clientes y lenguajes que son Java utilizando un protocolo llamadoJCA (Java EE conector Architecture).Java BeansCabe mencionar el papel que juegan los java beans, en una aplicacin JSFestos beans son muy comunes y son llamados a menudo ManagedBeans obackingBeans estos no son mas que clases de utilidad que manejan loseventos, estados, y datos de una pagina JSF. En este caso estn incluidos enla capa de servidor JEE.Estas clases tambin pueden estar incluidas en una aplicacin Cliente JSEprincipalmente manejando datos, gestionando eventos, etc. de la aplicacinJSE.Estas clases Java Beans no son considerados componentes JEE por laespecificacin Java EE.Estos Java Beans o Beans a secas tiene propiedades o atributos privados ytiene mtodos get y set para acceder a sus propiedades.


1.3.3. Comunicaciones del componente de la capa cliente con elservidor JEE.Se ha mencionado el tipo de comunicacin entre un componente de la capacliente con el servidor JEE, para resumir tenemos que una thin client o clientedelgado puede comunicarse con el servidor JEE(especficamente con losEJB) va protocolos HTTP/HTTPS y un cliente JSE puede hacerlo mediante elprotocolo RMI o si la aplicacin as lo requiera puede abrir una comunicacinva el protocolo HTTP pero ya no se comunicara con un EJB sino con unServlet (figura I.3).

Figura I.3. Comunicacin entre un componente de la capa cliente con el servidor JEE.

Seguramente que al explorar esta capa existe una disyuntiva de si laaplicacin JEE utilizara un navegador Web thin client o una aplicacin JSE richclient , para decidir cul utilizar se debe tener cuidado en llegar a un equilibrioentre mantener la funcionalidad en el cliente (rich client) y cargarle toda lafuncionalidad posible al servidor (thin client).Cargar la mayor funcionalidad posible al servidor facilita la distribucindespliegue y manejo de la aplicacin puesto que no hay que preocuparse porla instalacin de un rich client en la PC del usuario , configurar la JVM parauna determinada plataforma (Linux, Windows ,Macos, etc), y otras tareas deconfiguracin inicial, sino tan solamente habr que saber operar un navegadorWeb.Mantener la mayor funcionalidad en el cliente puede hacer que se percibauna mejor experiencia de usuario, pero siempre requerir una instalacin en laPC del usuario.


1.4. Componentes de la Capa WebLos componentes de la capa Web de la arquitectura JEE son los aquellos quese ejecutan en el servidor y producen paginas dinmicas en Html, WirelessMarkup Language (WML) o XML, en la arquitectura JEE estos componentesacceden a los componentes de la capa de negocios.Algunas de las ventajas de usar componentes web son: La interfaz HTML que es generada por un componente web es liviano

comparado con los applets o las aplicaciones JSE. La interfaz HTML generada no requiere una instalacin a priori en las

maquinas cliente, tan solo bastara un navegador. El protocolo HTTP sobre el cual los clientes realizan peticiones al

servidor pueden transitar sin problemas a travs de los firewalls.Estos componentes son los Servlets, los JSP y/o la tecnologa Java ServerFaces, esta ltima esta construido sobre la tecnologa Servlets/JSP yproporciona un marco de trabajo o comnmente llamado Framework paraaplicaciones Web. Entonces podemos concluir que JSF es un Framework parael desarrollo de aplicaciones basadas en la web. JSF proporciona unFramework para el uso de componentes de interfaz de usuario. JSFproporciona un entorno RAD para la construccin de aplicaciones Web. JSFes un verdadero Framework MVC (figura I.4).

Figura I.4. Componentes de la capa web y la capa de negocio.

Como se mencion antes las clases de utilidad en esta capa comnmentellamados ManagedBean o Backingbeans pueden ser empaquetadas con los


componentes web pero no son considerados componentes Web por laespecificacin JEE. Ya se dijo que la capa cliente y la capa web pueden incluirestas clases de utilidad o clases Java Beans para manejar las entradas delusuario, los eventos de la pgina ,etc. y enviar dichos datos a los EJBempresariales que se ejecutan en la capa de negocio.1.5. Componentes de la Capa de NegocioEl cdigo del negocio es la lgica que soluciona o cumple con las necesidadesde un dominio de negocio en particular como lo es un banco, una universidad,etc. En este caso las ventas, finanzas, Matriculas, son manejados por beansempresariales que se ejecutan en la capa de negocio.Un EJB o vean empresarial recibe datos de un programa cliente JSE o de unBean de la capa web, procesa esos datos (si es necesario) y lo enva a lacapa de informacin Empresarial para su almacenamiento. Un EJBempresarial tambin recupera datos del sistema de almacenamiento, loprocesa (si es necesario) y lo enva de regreso al programa cliente JSE (enrealidad lo enva tambin el vean de la aplicacin JSE) o al bean de la capaweb.Los EJB y los servicios web son componentes de la capa de negocios obussines tier ellos encapsulan la data y las reglas de negocio (figura I.4).Cabe sealar que normalmente el usuario de una aplicacin es una personasin embargo el usuario de una servicio web es una aplicacin, es decir elservicio web es una aplicacin para aplicaciones.1.6. Capa EISLa capa del sistema de informacin empresarial maneja el software EIS eincluye sistemas que son infraestructura como los ERPs, Mainframes,sistemas de bases de datos, y otros sistemas heredados (figura I.5).1.7. Contenedores JEELas aplicaciones web manejan transacciones, administran estados, hiladomltiple, recursos en comn y otros detalles de bajo nivel. Imagnese situvisemos que escribir cdigo para gestionar todas estas tareas, realizar unaaplicacin web sera muy difcil.El servidor JEE proporciona estas tareas como servicios en la forma decontenedores para cada tipo de componente de la arquitectura JEE. Dado queno se tienen que desarrollar estos servicios, por lo tanto se es libre deconcentrarse en desarrollar la lgica de negocio.Pero en si conceptualizando que es un contenedor: Un contenedor proporcionaun entorno de ejecucin para un componente JEE, este contenedorproporciona servicios de seguridad, concurrencia, gestin del ciclo de vida,procesamiento de transacciones, despliegue y otros servicios. Dentro de unservidor JEE vienen incluidos un contenedor web (para los componentes de la


capa web) y un contenedor EJB (para los componentes dela capa denegocio).

Figura I.5. Capa EIS.

Antes de que un componente web, ejb o cliente de aplicacin JSE pueda serejecutado, debe ser ensamblado en un mdulo JEE y desplegado dentro desu respectivo contenedor.El proceso de ensamblado involucra configuracin especificando loscontenedores para cada componente de la aplicacin JEE. Esta configuracinincluye soporte de capas bajas proporcionadas por el servidor JEE, queincluye servicios de seguridad (JAS),manejo de trasacciones(JTA), bsquedasen el sistema de nombrado Java Naming Directory Interfaces(JNDI) yconectividad remota(RMI).


El contenedor tambin maneja servicios que no son configurables como beansempresariales y ciclos de vida de servlets, conjunto de conexiones (pool deconexiones) persistencia y acceso a las Apis de la plataforma JEE.1.7.1. Tipos de contenedorEl proceso de despliegue instala los componentes como se ilustra en la figuraI.6: Servidor JEE un servidor JEE como Glassfish, BEA Web logic, Jboss,

Geronimo, OAS, proporciona un contenedor EJB y un contendor Web. Contendor EJB: Maneja la ejecucin delos EJB para aplicaciones java

JEE. Los EJB y su contenedor se ejecutan en el servidor java JEE. Contendor Web: maneja la ejecucin de pginas JSP, Servlets y JSF para

aplicaciones java JEE. De la misma manera estos componentes y sucontenedores se ejecutan en el servidor JEE. Cabe mencionar que Apachetomcat es un contenedor de este tipo.

Contenedor de la aplicacin cliente: maneja la ejecucin de loscomponentes de una aplicacin cliente JSE, la aplicacin cliente y sucontenedor se ejecutan en la pc cliente.

Figura I.6. Instalacin de los componentes para el proceso de despliegue.


1.8. Ensamblaje y despliegue de una aplicacin java JEEUna aplicacin JEE es empaquetada en una o ms unidades estndar paradespliegue en cualquier sistema compatible con la plataforma Java EE. Cadaunidad contiene: Un conjunto de componentes funcionales(EJB, JSP, JSF, Servlet segn

sea la capa) Un descriptor de despliegue que describe su contenido, este es un

documento XML que describe la configuracin de despliegue de unaaplicacin o de un componente. Dado que la informacin en este archivoes declarativa, esta puede ser cambiada sin la necesidad de modificar elcdigo fuente. En tiempo de ejecucin, el servidor Java EE lee eldescriptor de despliegue y acta sobre la aplicacin o componentecorrespondiente.

Una vez que una unidad Java EE ha sido producida esta lista para serdesplegada. El despliegue tpicamente involucra el uso de una herramienta dedespliegue. Una vez desplegado la aplicacin esta lista para ejecutarse.1.9. Empaquetado de aplicacionesUna aplicacin java EE generalmente se empaqueta tal como se muestra en lafigura I.7.

Figura I.7. Empaquetado de una aplicacin Java.


Describiendo la figura I.7, una aplicacin JEE es distribuida en un ficheroarchivo empresarial EAR, que no es ms que un archivo java estndar .jar conuna extensin .ear, el uso de archivos ear y mdulos base hace posibleensamblar una gran cantidad de aplicaciones java EE utilizando alguno de losmismos componentes. No se necesita codificacin extra, es solo un tema deensamble o empaquetado de varios mdulos Java EE en un fichero .ear.Como se ve en la figura 1.7 generalmente un archivo .ear puede contener dosmdulos ( en realidad pueden contener hasta cuatro) mdulos EJB y mdulosWeb.Los cuatro tipos de mdulos de Java EE (figura I.8) son los siguientes: Mdulos EJB, contiene a los EJB y un descriptor de despliegue, estos

componentes son empaquetados como ficheros JAR con una extensin.jar.

Mdulos Web, contiene a los servlets, jsp, y jsf, archivos de imgenes,archivos HTML, clases de utilidad (Managed beans o simplemente beans)y su respectivo descriptor de despliegue. Estos componentes sonempaquetados como ficheros JAR con una extensin .war.

Mdulos de aplicaciones cliente (JSE): contienen clases java con surespectivo descriptor, estos componentes son empaquetados comoficheros jar con una extensin .jar

Mdulos adaptadores de recursos, contiene todas la interfaces java,clases, libreras y otra documentacin junto con su descriptor dedespliegue. Juntos estos implementan la arquitectura Conector para unEIS en particular como una aplicacin heredada hecha en visual fox. Estoscomponentes son empaquetados como ficheros jar con una extensin .rar

1.10. Seguridad en Aplicaciones Java EELa seguridad para los componentes de aplicaciones JEE y servicios web sonproporcionadas por su respectivo contenedor, un contenedor proporciona dostipos de seguridad: declarativa y programtica. La seguridad declarativa expresa los requerimientos de seguridad de una

aplicacin usando descriptores de despliegue. Estos descriptores sonexternos a la aplicacin e incluyen informacin que especifica como losrequerimientos de roles seguros y de accesos requieren ser mapeadosen un entorno especifico seguro de roles, usuarios y polticas.

La seguridad programtica es embebida en una aplicacin y es usada parahacer decisiones de seguridad. La seguridad programtica es muy usadacuando la seguridad declarativa sola no es suficiente para expresar elmodelo de seguridad de una aplicacin.


Figura I.8. Mdulos de Java EE.

Las anotaciones (Tambin llamados metadata) habilita un estilo declarativo deprogramacin y por lo tanto ambos existen conceptos de seguridad declarativay programtica. Los usuarios pueden especificar informacin acerca de laseguridad dentro de un archivo de clase. Cuando la aplicacin es desplegada,esta informacin puede luego ser usada por o ser sobrescrito por el descriptorde despliegue de la aplicacin.Un descriptor de despliegue es un documento XML que describe laconfiguracin de despliegue de una aplicacin, un mdulo o un componente.Porque la informacin de despliegue es declarativa, este puede ser cambiadosin necesidad de modificar el cdigo fuente. En tiempo de ejecucin elservidor JEE como glassfish por ejemplo lee el descriptor de despliegue yacta en la aplicacin, modulo o componente.1.11. Diseando aplicaciones JEEAl disear una aplicacin deberamos tener en cuenta: Portable: La solucin se debera de desplegar en diferentes servidores,

bases de datos que implementen la especificacin JEE. Escalable: las aplicaciones web deberan ser manejada por un alto nmero

de usuarios. La aplicacin debera soportar balanceo de carga yaprovechar el incremento de recursos del hardware de servidor

Mantenible: una cantidad mnima de cdigo debera ser necesario parauna nueva regla de negocio. Y la localizacin de fallas debera ser msrpida.


Reusable: por ejemplo, una clase que procesa tarjetas de crditos deberaser reusada por mltiples aplicaciones. Evitar la duplicacin de cdigo o elcopy paste.

Simple: las necesidades de servicio debera ser resuelta con un mnimode complejidad, hacer uso de las APIs y no reinventar la rueda.

Adems de lo anterior es importante seguir guas seguras para el diseo ydesarrollo de cualquier tecnologa, esto puede lograrse: Implementando arquitecturas y patrones de diseo generalmente

aceptados Enfocndose mas en las necesidades reales de negocio. Empleando tecnologa sencilla para resolver problemas de negocio.1.12. Patrones de diseoLos patrones de diseo son un tema bastante tratado tanto as que la mayorade frameworks por no decir todos lo implementan de forma natural.Los patrones de diseo son soluciones recurrentes de software a problemasde diseo. Son procesos repetitivos de diseo que abordan una cuestinespecfica o problema en el desarrollo de un sistema.Podemos decir entonces que los patrones de diseo resuelven problemas delmundo real en trminos de desarrollo de software.1.12.1. Patrones de diseo en Java EELos patrones generalmente aceptados en Java EE (pero no son todos)incluyen: Patrones de la web tier:

o Intercepting filter: Facilita el preprocesamiento y el post procesamientode una peticin, aplicando servicios adicionales que son necesariospara procesar una peticin. Un servlet filter es un ejemplo de unaimplementacin de este patrn.

o Controller servlet: Es usado en la arquitectura MVC, proporciona uncontrol centralizado para manejar una peticin. Este es mascomprensivo que un enfoque intercepting filter porque todas lapeticiones son mantenidos en el mismo controlador.

Patrones de la business tier:o Service locator: Facilita la localizacin de componentes de negocio y

servicios de manera uniforme y transparente. Este centraliza y reusa laimplementacin de mecanismos de bsqueda para los clientes de unaaplicacin Java EE.


o Data transfer Object: Facilita el intercambio de data entre capasreduciendo la carga de la red.

o Session Facade: Encapsula los componentes de la capa de negocio yexpone un servicio de alta disponibilidad para los clientes de unaaplicacin Java EE.

1.13. Diseando un aplicacin Java EE con los Patrones Java EEUna aplicacin Java EE es una implementacin del lado de servidor q quecontiene componentes estndar as como servlets, JSPs y EJBs.Diseo de la web tier: la capa web tpicamente usa un patrn MVC, as comoADF de Oracle y JSF del estndar de java. Usando un patrn MVChabilitamos la separacin de la lgica de presentacin de la lgica denegocio. El controlador facilita el control de flujo de la aplicacin desde unapgina a otra.Diseo de la Lgica de negocio: Dependiendo de la complejidad de la lgicade negocios, las entidades pueden ser o no pueden ser expuestos en la webtier a travs de los beans. Aplicaciones ms complejas usan un Session beancomo un facade, por las siguientes razones: Para el control de la seguridad sobre la capa de negocio. Para acceso mediato a la los EJB de entidad y la capa de persistencia. Para el mejor manejo de las transacciones.La figura I.9 muestra el uso de los patrones de diseo MVC y Facade.

Figura I.9. Uso de los patrones de diseo MVC y Facade.


1.13.1. Implementando un Patrn sesin FacadeEl patrn Session Facade es muy usado por aplicaciones con complejosprocesos e interacciones. Como es descrito en la figura I.10, un patrn sessionfacade es implementado como un EJB de session que acta como el muroentre la web tier y la capa de persistencia.Los beneficios de implementar este patrn son: Proporciona una sola interfaz para los clientes. Define a un alto nivel los componentes de negocio que contiene lgica de

negocio de manera centralizada. Desacoplamiento de bajo nivel entre componentes, esto hace el diseo

ms flexible, fcil de mantener y fcil de implementar nuevos cambios enlas reglas de negocio.

Mejora la performance de la red a travs de la eliminacin de llamadas amltiples mtodos entre clientes y componentes individuales gestionadospor el Facade.

Abarca transacciones a travs de ms de una llamada a las entidades

Figura I.10. El patrn Session Facade.

1.13.2. Definiendo la arquitectura MVCComo ya se ha descrito el MVC es un patrn propio de la Web tier, el figuraI.11 muestra un MVC genrico recomendado para aplicaciones interactivas.El principal beneficio de este patrn es la separacin de la presentacin,control, persistencia y el comportamiento.


Figura I.11. Patrn MVC.

1.13.3. Implementando la User Interface con JSF y patrones JavaEELa figura I.12 muestra una arquitectura tpica de una aplicacinimplementada con JSF, esta aplicacin incluye: La vista: hecha por pginas JSF que hacen la capa de presentacin y que

interactan con el modelo. Los valores de la interfaz de usuario sonalmacenados en un backing vean.

El modelo: hechos por el backing vean llamado tambin beans, desacoplala interfaz de usuario de la lgica de negocio. Como se ve en la figura I.12,el modelo interacta con un EJB de sesin que implementa un sessionfacade que contiene la lgica de negocio

El controlador: hecho por el archivo de configuracin JSF faces-cpnfig.xmly el servlet FacesServlet que manejan el flujo de la aplicacin.

Figura I.12. Una aplicacin implementada con JSF.


1.14. Instalacin del entorno de desarrolloPara el proyecto que consiste en un Repositorio Digital de Documentos seutiliza las siguientes herramientas de desarrollo: Netbeans IDE. Glassfish servidor de aplicaciones. Postgres base de datos. Power Architect diseo de base de datos.Nuestro proyecto consiste bsicamente en el depsito, revisin, publicacin,preservacin y bsqueda de documentos digitales en formato PDF.La instalacin de estas herramientas de desarrollo pueden hacerse tanto en elSO Windows o Linux puesto que existen versiones para cada tipo de SO. Sinembrago el desarrollo de este proyecto y principalmente de este texto serealiza sobre un SO Linux de la rama Debian, aunque se puede usar, un Mint,Debian, Ubuntu, Linex, etc.Una observacin es que se debe de instalar el JDK y no el JRE para quepuedan funcionar adecuadamente, la versin de JDK disponible en la pginade ORACLE (ya que ahora Java es parte de ORACLE) y con la que vamos atrabajar es la JDK 6 Update 22.


CAPITULO IIAPI DE PERSISTENCIA DE JPA

2.1. Persistencia en javaLa persistencia en java puede ser definida como el almacenamiento decualquier cosa usando cualquier almacn de persistencia en java.Este captulo est enfocado en el almacn de objetos java en una base dedatos, en particular usando la Java Persistence API JPA.Existen muchas formas para persistir datos en java, por nombrar unos pocos:JDBC, serializacion, IO de archivos,JCA, bases de datos orientadas a objetos,or Basese de datos XML. Sin embargo la mayora de la data es persistida enbases de datos relacionales, muchas de las cosas que se hace en unacomputadora o en un sitio web involucran acceso a bases de datos relacionesy almacenamiento de datos. Las bases de datos relacionales son el estndarpara el almacn de persistencia de muchas corporaciones que van desdebancos a industrias.Muchas cosas pueden ser almacenadas en una base de datos desde java, ladata en java incluye Strings, nmero, fechas y arreglos de bytes, imgenes,XML y objetos java.Muchas aplicaciones java utilizan objetos para modelar los datos de suaplicacin, debido a que java es un lenguaje orientado a objetos, almacenarobjetos java es una costumbre tan natural y muy comn para persistir datadesde java.Existen muchas formas para accesar a bases de datos relacionales desdejava. JPA es exactamente lo ltimo de muchas diferentes opciones peroparece ser que es la alternativa que se hace ms popular cuando hablamos depersistencia en java.


2.2. Qu es una base de datos?Una base de datos es un programa que almacena datos, existen muchos tiposde base de datos, de archivos planos, jerrquica, relacional, objeto-relacional,orientado a objetos, xml y otros. Las bases de datos originales songeneralmente propietarias y no estandarizadas.La base de datos relacional fue la primera base de datos que tuvo mucho xitoy logro cierta estandarizacin, una base de datos relacional se caracteriza porel SQL (structured query language) estndar que usa para consultar ymodificar datos en la base de datos, se caracteriza tambin por su arquitecturacliente-servidor, y la estructura de almacenamiento de las tablas relacionalesque maneja.Su arquitectura cliente servidor permite al lenguaje de programacin clientedesacoplarse del servidor, permitiendo al servidor de base de datos soportarinterfaces, APIs en mltiples diferentes lenguajes de programacin y clientes.Sin embargo las bases de datos relacionales son relativamente tecnologapasada pero ellos aun dominan la industria. Han existido muchos intentos parareemplazar el modelo relacional, primero con bases de datos orientadas aobjetos, luego con bases de datos objeto-relacional, y finalmente con bases dedatos xml, pero ninguno de estos nuevos modelos nuevos de bases de datoshan logrado muchos avances y las bases de datos relacionales permanecenal dominantes en el modelo de base de datos.Los principales bases de daros relacionales hoy en da son : Oracle, Mysql,PostgreSQL, DB2, Derby, sybase y SQL server.2.3. Qu es JPA?La arquitectura de persistencia java JPA es una especificacin java para elacceso , persistencia y gestin de datos entre objetos/clases java y la bases dedatos relacionales. JPA fue definido como parte de la especificacin EJB 3.0como un remplazo de EJB 2 CMP especificacin Entity Beans.JPA es ahora considerado el estndar en la industria para el acceso al mapeoobjeto-relacional (ORM) en la industria java.JPA es una especificacin no es un producto, y no puede realizar persistenciapor s mismo. JPA es un conjunto de interfaces que requieren de unaimplementacin. Es aqu donde entran las diferentes implementaciones de JPAde cdigo abierto y propietarios para escoger que servidor de aplicacindeber proporcionar soporte para su uso. JPA tambin requiere una base dedatos para realizar persistencia.JPA permite usar POJO (plain old java objects) para realizar la persistencia demanera sencilla sin necesidad de clases que implementen cualquier interfaceo mtodos como la especificacin EJB 2 CMP lo requera. JPA permite unmapeo objeto-relacional que son definidos a travs de anotaciones estndaro Xml que definen como las clases java mapea a una tabla relacional. JPA


tambin define un Runtime Entity Manager API para procesar consultas ytransacciones sobre los objetos contra la base de datos. JPA define unlenguaje de consultas a nivel de objetos llamado JPQL que permite consultar alos objetos desde la base de datos.JPA es lo ltimo muchas especificaciones de persistencia en java. El primerofue el servicio de persistencia OMG, el cual nunca fue exitoso yaparentemente no existe producto comercial que lo soporte. Lo siguiente vinocon EJB 1.o CMP entity Beans, el cual fue muy exitoso al ser adoptado porgrandes proveedores de java EE (Bea, IBM) pero era muy complejo deimplementar y tena una pobre performance, luego vino EJB 2.0 CMP queredujo algo la complejidad de les EJB's introduciendo interfaces locales, perola mayora de la complejidad aun persista adems no era portable puesto queno corra en todos los servidores de aplicacin.La reaccin frente a esto fue la creacin de otra especificacin de java JDO(java data objects). JDO obtuvo algo de xito con algunos proveedoresindependientes as como Kodo JDO, y muchas implementaciones opensource, pero nunca logro xito con los proveedores grandes de JEE.A pesar de los dos estndares para persistencia de java estaban encompetencia (EJB CMP y JDO), la mayora de usuarios continuaron usandosoluciones propietarias y open source como TopLink e hibernate . El productode toplink originalmente producido por WebGain fue tambin adquirido porOracle, incrementando su influencia en la comunidad java EE.Actualmente muchos de los proveedores de persistencia tienen versiones queimplementan JPA confirmando la adopcin de JPA por parte de la industria ylos usuarios. Es tos proveedores incluyen Hibernate, TopLink, kodo,Jpox , etc.Por qu usar JPA o un ORM?ORM es el nombre genrico de una especificacin como JPA, existen muchasrazones para usar un framework ORM y muchas razones para usar JPA enparticular.Razones para usar un ORM: Promueve la programacin orientada a objetos y el modelo de objetos. Proporciona un esquema independiente de la base de datos. Muchos de los productos ORM son open source. Muchas corporaciones proporcionan soporte y servicios para productos

ORM. Proporciona caractersticas finales de alta performance as como caching y

optimizacin de consultas.


Razones para usar JPA el estndar y es parte de EJB3 y JEE: Muchos productos libres y open source tienen soporte a nivel empresarial. Portabilidad entre servidores de aplicacin y proveedores de persistencia Una especificacin usable y funcional. Lo soporta JEE y JSE2.4. Proveedores de persistenciaExisten muchos proveedores de persistencia para escoger, muchosproveedores de persistencia ahora soportan JPA. Sin embargo existenalgunas excepciones. Que proveedor utilizar depende de las preferencias,pero mucha gente recomendara usar JPA estndar sin importar queproveedor de persistencia uses. Hacer esto proporcionara la flexibilidad paracambiar entre proveedores de persistencia, o portar tu aplicacin a otroplataforma de servidor el cual puede usar un proveedor de persistenciadiferente.Los proveedores de persistencia ms usados se muestran en la tabla II.1.

Tabla II.1. Proveedores de persistencia.Producto JPA Ao de

LiberacinOpen Source Servidores de

aplicacinHibernate Si 2008 Si JBossEclipse Link Si 2008 Si OracleAs, Oracle

Bea Weblogic,Glassfish v3

Toplink Si 2008 Si Oracle Beaweblogic

Open JPA Si 2008 Si GeronimoTop link Essentials Si 2007 Si Glassfish, Sun As,

OracleAS, BeaWeblogic.

2.4.1. Eclipse LinkEs un proyecto de servicios de persistencia open source de la fundacinEclipse. El producto proporciona un framework extensible que permite a losdesarrolladores java interactuar con varios servicios de datos, incluyendobases de datos, XML y Sistemas de informacin Empresaria EIS o sistemasheredados. Eclipse Link soporta un nmero de estndares de persistenciaincluyendo el API JPA, Ajava APPPI para XML Binding JAXB, Java ConectorArchitectura JAC, Java Transaccion API JTA y Service Data Objects SDO.Eclipse link est basado en Top link como producto, con el cual Oraclecontribuyo con el cdigo fuente para crear el proyecto EclipseLink. La


contribucin original fue a partir del cdigo base de TopLink 11g, cabe resaltarque TopLink Essentials es diferente de TopLink 11g al menos en cuestin delicencias y funcionalidad.2.4.2. TopLinkEs uno de los productos de persistencia ms dominante que implementa JPA.TopLink es producido por Oracle.As TopLink 11g soporta la especificacin JPA 1.0, proporcionando un mapeoobjeto relacional avanzado. Top link incluye tambin sofisticados cacheo deobjetos y caractersticas de performance.TopLink proporciona una rica interfaz de usuario. Que est integrado en el IDEJdeveloper.2.4.3. Top Link EssentialsEs un proyecto open source de la comunidad de Glassfish. Top LinkEssentials est basado en TopLink como producto , con la contribucin deOracle de algunas partes del cdigo fuente para crear el proyecto TopLinkEssentials.TopLink essentials ha sido un tanto desplazado por Eclipse Link, ahoraEclipseLink implementa JPA 2.0 y es parte de Sun Glasfish V3.2.5. MapeoLa primera cosa que se necesita para persistir algo en java es definir comoser persistido. Esto es llamado proceso de mapeo. Han existido muchasdiferentes soluciones para realizar el proceso de mapeo a lo largo de estosaos, incluyendo algunos bases de datos orientadas a objetos que norequieren mapeo alguno, mediante el cual tu persistes directamente.Las herramientas de mapeo objeto-relacional suelen generar un modelo deobjetos para un modelo de datos que incluye el mapeo y la lgica depersistencia en este mismo.Los productos ORM que proporcionan herramientas de mapeo que permiten elmapeo de un modelo de objetos a un modelo de datos y almacenan la metadata del mapeo en archivos planos, tablas de bases de datos, XML yanotaciones.En mapeo en JPA puede ser almacenado a travs de anotaciones java oarchivos XML.El requerimiento mnimo para mapear un objeto en JPA es definir que objetospueden ser persistidos. Esto se logra a travs del marcado de la clase con laanotacin @entity, o aadiendo un tag para la clase en el archivoXML de la unidad de persistencia del ORM.


Este archivo se encuentra dentro de la carpeta META-INF folder. Este archivoes usado para especificar el nombre del proveedor de persistencia, losnombres de las clases de entidad, y propiedades as como la URL de conexina la Base de Datos, el driver, usuario, password y algunas cosas ms.Un ejemplo de un PU(unidad de persistencia) es:

org.apache.openjpa.persistence.PersistenceProviderImpl

entity.Customer

Un archivo ms sencillo sera algo as como:

jdbc/galileo

La implementacin JPA por defecto contendr otras informaciones de mapeoas como el nombre de la tabla, nombres de las columnas traducidos encampos o propiedades, cardinalidad y mapeo de relaciones, todo el SQL y lalgica de persistencia para accesar a los objetos. Muchas implementacionesJPA tambin proporcionan la opcin de generar las tablas de bases de datosen tiempo de ejecucin, as se requiere menos trabajo por parte deldesarrollador para desarrollar rpidamente una aplicacin de persistenciaJPA.En pocas palabras JPA, usa el modelo de programacin POJO para lapersistencia. A pesar de que este modelo est incluido en la especificacinEJB 3 , JPA puede ser usado fuera de un contenedor EJB , Plain Old JavaObjects ( POJO ) ejecutndose en una aplicacin Java SE.


2.6. Cmo trabaja JPA?Como ya dijimos JPA inspirado en los frameworks como Hibernate, JPA usaanotaciones para mapear objetos a la base de datos relacional. Estos objetos,usualmente llamados entidades, no tienen nada en comn con los EntityBeans 2.x. Las entidades JPA son clases POJOs, no extienden de ningunaclase y no implementan ninguna interface.Usted no necesita archivos descriptores XML para hacer los mapeos. Si unose fija en el API (javadoc) uno observara que est compuesto de pocas clasese interfaces.La mayora del contenido del paquete javax.persitence son anotaciones. Acontinuacin se ve el siguiente ejemplo de cdigo:@Entitypublic class Customer {@Idprivate Long id;private String firstname;private String lastname;private String telephone;private String email;private Integer age;// constuctors, getters,setters}

Esta parte de cdigo que vimos (constructores, getter y setter no sonmostrados para hacer esto ms fcil de leer) muestra una clase Customersimple. Esta tiene un identificador (id) , un nombre ( firstname) , apellido(lastname) un nmero de telfono (telef) , mail ( mail ) y edad del cliente(edad). La figura II.1 muestra la representacin de la clase Customer.

Figura II.1. La clase Customer.

Para ser persistente esta clase tiene que seguir algunas reglas JPA simples: La clase tiene que ser identificada como una entidad usando la anotacin

@javax.persistence.Entity


Una propiedad de la clase tiene que tener un identificador anota do [email protected]

Tiene que haber un constructor sin argumentosEl cdigo que sigue muestra lo mnimo requerido para definir un "persistenceobject". Ahora vamos a manipular este objeto, deseo persistir mi objetocustomer, actualizar alguna de sus propiedades y borrarlo de la base dedatos. Estas operaciones sern echas a travs de la interfacejavax.persistence.EntityManager de JPA.Para esto, quienes estn familiarizados con el patrn DAO , el EntityManagerpuede ser visto como una clase DAO que nos provee un set de mtodosclsicos (persist , remove) y buscadores ( find ).// mtodos CRUDpublic void createCustomer() {// Gets an entity managerEntityManagerFactory emf = Persisten-ce.createEntityManagerFactory("watermelonPU");EntityManager em = emf.createEntityManager();EntityTransaction trans = em.getTransaction();// Instantiates a customer objectCustomer customer = new Customer(1L, "John","Lennon", "441909", "[email protected]", 66);// Persists the customertrans.begin();em.persist(customer);trans.commit();// Finds the customer by primary keycustomer = em.find(Customer.class, 1L);System.out.println(customer.getEmail());// Updates the customer email addresstrans.begin();customer.setEmail("[email protected]");trans.commit();// Deletes the customertrans.begin();em.remove(customer);trans.commit();}// Closes the entity manager and the factoryem.close();emf.close();}

2.7. Entity ManagerDespus de crear el EntityManager usando un factory (Entity ManagerFactory),se instancia el objeto Customer (usando el operador new como cualquier otroobjeto JAVA) y le pasa algo de data como el "id" , "last name" , "email" , etc. Seusa el mtodo EntityManager.persist() para insertar este objeto en la base dedatos. Se puede luego buscar este objeto por su identificador usando elmtodo EntityManger.find() y actualizar el mail usando los mtodos "set". La


interface EntityManger no tiene un mtodo update. Los updates se hacen atravs de las propiedades "setters". Luego se borra el objeto usandoEntityManager.remove() , notar que este cdigo usa transacciones explicitas .Es por eso que los mtodos persist, update, y remove son llamados entretransacion.begin() y transaction.commit(). Vea los mtodos CRUD Que basede datos usamos ? ,La respuesta est en EntityManagerFactory, esta toma un parmetro que serefiere a una especfica unidad de persistencia (watermelonPU en este caso).Una unidad de persistencia es declarada en el archivo persistence.xml ycontiene informacin como la base de datos a usar y el driver JDBC.

2.8. Unidad de PersistenciaEn el cdigo anterior, hay solo una unidad de persistencia, llamadawatermelonPU (el archivo persistence.xml puede contener muchas unidadesde persistencia). Se puede pensar en una unidad de persistencia como unconjunto de entidades (el elemento class) que comparten propiedadescomunes. En este caso, estas propiedades son: url de la base de datos, driverJDBC, credenciales. Bajo el elemento "properties" se encuentra laspropiedades especficas para Top-link por ejemplo toplink.ddl-generation. Estapropiedad es usada por TopLink para generar las tablas automticamente siestas no existen an. Esto significa que una vez ejecutado el cdigo TopLinkha creado una tabla para guardar la informacin de customers. La tabla II.2muestra la informacin DDL (data definition lenguaje) de la tabla customer.

Tabla II.2. Informacin DDL de la tabla customer.

Este es el DDL que JPA genera automticamente de la clase anotadaCustomer. Gracias a la codificacin por defecto que gua JPA (y en generalJava EE 5) no se tiene que hacer mucho para generar este DDL, lacodificacin por defecto hace ms fcil la programacin para el desarrollador.


2.8.1. CustomizadoUsted solo necesita aadir cdigo customizado cuando el cdigo por defectoes inadecuado. En este caso, porque no se especifica el nombre de la tabla ocolumnas en la clase Customer JPA asume que el nombre de la tablas esigual al nombre de la clase y que el nombre de la columna tiene el mismonombre de las propiedades. Los tipos de datos son tambin mapeados pordefecto (ejemplo String es mapeado a varchar(255) ).2.9. Aadiendo funcionalidadesEn este punto se mejora algunas cosas. Primero que todo, no se quiere setearun identificador (primary key) del objeto pero en lugar de esto se quiere queJPA lo incremente automticamente. Gracias a las anotaciones, esto es fcilde hacer. Solo necesito anotar mi atributo [email protected]. Esta anotacin genera un primary Key encuatro posibles modos: AUTO (default) permite al proveedor de persistencia (TopLink en este

caso) decidir cul de las tres posibilidades usar. SEQUENCE usar un SQL sequence para obtener el prximo primary key. TABLE requiere una tabla con dos columnas : el nombre de la secuencia y

su valor ( esta es la estrategia por defecto de TopLink). IDENTITY usa un "identity generator", ejemplo: una columna definida como

auto_increment en MySQL.Ahora se desea mejorar el mapeo. Primero se debe cambiar el nombre de latabla a "t_customer" en lugar de "customer". Luego se hace el nombre (firstname) y el apellido (last name) obligatorios. El mximo largo de un nmero detelfono (telephone) tiene que ser 15 caracteres y la columna email tiene queser renombrada a e_mail con un "underscore" .Todos estos pequeos cambios pueden ser hechos con las anotaciones. Paracambiar el nombre (name) de la tabla anote la clase [email protected]. La anotacin @javax.persistence.Column es usadapara definir las columnas y tienen una serie de atributos listados en la tablaII.3.

Tabla II.3.


2.10. Anotaciones CallbackAhora con el mapeo entre la clase Customer y la tabla t_customer queda mejorgracias a que las anotaciones @Column y @Table tienen muchos atributos.Hay otras dos cosas que se debe hacer. Primero asegurar que todo telfonoes ingresado usando cdigos internacionales.Comenzando con el smbolo '+. Segundo, calcular la edad del customer apartir de la fecha de nacimiento. Hay muchas alternativas de cmo hacer estastareas, pero se va a usar "callback annotations".Durante su ciclo de vida, una entidad es cargada, persistida, actualizada oremovida. Una aplicacin puede ser notificada antes o despus de ocurridosestos eventos usando anotaciones. JPA tiene un conjunto de "callbackannotations" que pueden ser usadas en mtodos y permiten al desarrolladoraadir cualquier regla de negocios que desee. Esto es como usar un trigger enuna Base de datos. JPA llamara al mtodo anotado antes o despus de estoseventos. La tabla II.4 muestra las "callback anotations".

Tabla II.4. Callback anotations.

Para usar los callback annotations, primero se revisa el formato del nmerode telfono.Se verifica que el primer carcter del telfono es "+, se hace esto antes quela entidad sea persistida o actualizada. Se tiene que crear un mtodo(validatePhoneNumber en el ejemplo , pero el nombre es irrelevante ) con algode lgica de negocios y con las anotaciones @PrePersist y @PreUpdate, JPAhace el resto.El cdigo de ejemplo es:@PrePersist@PreUpdateprivate void validatePhoneNumber() {if (telephone.charAt(0) != '+')throw new IllegalArgumentException("Invalid phone number");}}

Para la edad del cliente, se hace algo similar, se calcula la edad del clienteantes que la fecha de nacimiento sea insertada (@PostPersist) o actualizada


(@PostUpdate), y claro cada vez que el cliente es cargado de la base de datos(@PostLoad).@PostLoad@PostPersist@PostUpdatepublic void calculateAge() {Calendar birth = new GregorianCalendar();birth.setTime(dateOfBirth);Calendar now = new GregorianCalendar();now.setTime(new Date());int adjust = 0;if (now.get(Calendar.DAY_OF_YEAR) - birth.get(Calendar.DAY_OF_YEAR) < 0){adjust = -1;}age = now.get(Calendar.YEAR) - birth.get(Calendar.YEAR) + adjust;}

2.11. Anotaciones Callback, Aadir anotacionesPara hacer que esto funcione se necesita aadir un nuevo atributo a la claseCustomer: date of birth . Para notificar a JPA que mapee este atributo a unafecha, se usa la anotacin @Temporal con el atributo TemporalType.DATE(las opciones son DATE , TIME ,TIMESTAMP). Ahora existe la capacidad decalcular la edad del cliente, pero se necesita persistir esa informacin?, NO ,conociendo que el valor cambia todos los aos .Para hacer que esta propiedad (age) edad no sea persistente, se usa laanotacin @Transient (La tabla no tendr una columna edad ms) veamos latabla II.5.

Tabla II.5. Propiedad (age) edad no persistente.

2.12. Relacin One To OneAhora que se tiene mapeada la clase Customer y se tiene anotacionescallback para validar y calcular data, se necesita aadir una direccin. Un


Customer tiene una y solo una address (direccin) entonces se puede enviaral cliente un regalo por su cumpleaos. Se representa como una claseseparada (ver tabla II-6), clase Address con un id, una calle (Street), unaciudad (city), un cdigo postal (zip code), y un pas (country) .

Tabla II.6. Clase Customer y clase address

Como se puede ver en la tabla anterior, la clase Address usa la anotacin@Entity para notificar a JPA que es una clase persistente y @Column paracustomizar el mapeo. Creando la relacin entre Customer y Address es simple.Simplemente se aade una propiedad Address en la clase Customer. Parapersistir la direccin de los "customer's" y se usa el cdigo que sigue:public void createCustomerWithAddress() {Customer customer = new Customer("John", "Garcia","+441909", "[email protected]", dateOfBirth);Address homeAddress = new Address("calle las galias","Huancayo", "SW14", "PE");customer.setHomeAddress(homeAddress);trans.begin();em.persist(homeAddress);em.persist(customer);trans.commit();trans.begin();em.remove(customer);em.remove(homeAddress);trans.commit();}Como este cdigo muestra, primero se instancia un objeto Customer y unAdress, para linkear los dos, se usa un mtodo setter ( set HomeAddress ) yluego persistido cada objeto, cada uno en la misma transaccin. Porque notiene sentido tener un adress en el sistema que no este linkeado a uncustomer, cuando se remueve el customer tambin se remueve el address.Pero persistiendo y removiendo ambos objetos parece que se hace mstrabajo que el que se necesita. Seria mejor si se pudiera persistir o removerjusto el objeto raz ( el Customer ) y permitir las dependencias que se persistano remuevan automticamente, TopLink y la codificacin por defecto har lasasociaciones opcionales y basadas en los requerimientos, es decir al persistiro remover customer tambin se hace con su address.


Si se quiere que un Customer tenga exactamente un Address, significa que unvalor null no es permitido y se puede lograr todo eso usando la anotacin@OneToOne junto con @JoinColumn.@OneToOne es usada para anotar una relacin. Este tiene muchaspropiedades incluyendo un cascade usado para "cascading" de cualquier tipode accin. En este ejemplo, se quiere "cascade" a la accin de persistir yremover. De esta forma, cuando se hace remove o persist de un objetocustomer este automticamente lleva acabo esta accin para el "address". Elatributo fetch dice a JPA que poltica usar cuando cargamos una relacin.Esta puede ser una asociacin de carga tarda (lazy loading LAZY), o "eagerly"(EAGER) porque se quiere cargar la direccin de la casa "homeAddress" tanpronto como el objeto Customer es cargado.

@Entity@Table(name = "t_customer")public class Customer {@Id@GeneratedValueprivate Long id;(...)@Transientprivate Integer age;@OneToOne(fetch = FetchType.EAGER, cascade ={CascadeType.PERSIST, CascadeType.REMOVE})@JoinColumn(name = "address_fk", nullable = false)private Address homeAddress;// constuctors, getters, setters}

La anotacin @JoinColumn tiene los mismos atributos como @Column,excepto que es usado para asociar atributos, en este ejemplo, se renombra lallave fornea en un address_fk y no se permite ningn valor null(nullable=false) JPA entonces creara los siguientes DDLs con una constraintde integridad, para la relacin entre tablas t_customer y t_adress (ver la tablaII-7).

Tabla II.7. Relacin entre tablas t_customer y t_adress.


2.13. Querying objectsHasta ahora se esta usando JPA para mapear los objetos a una base de datosrelacional y usar el entity manager para hacer algunas operaciones CRUD(Create, read, update and delete); pero JPA tambin permite que hagas queryssobre los objetos.Esto usa "Java Persistence Query Language" (JPQL), el cual es similar a SQLy es tambin independiente de la base de datos, este es un lenguaje rico quenos permite hacer querys complejos sobre objetos (asociaciones, herencia,clases abstractas). Los querys usan las palabras SELECT, FROM y WHERE,mas un conjunto de operadores para filtrar la data (IN, NOT IN, EXIST, LIKE,IS NULL, IS NOT NULL) o para controlar las colecciones (IS EMPTY, IS NOTEMPTY, MEMBER OF), tambin hay funciones para manejar Strings (LOWER,UPPER, TRIM,CONCAT, LENGTH, SUBSTRING), nmeros (ABS, SQRT,MOD), o colecciones (COUNT, MIN, MAX, SUM). Como SQL, se puedeordenar los resultados (ORDER BY) o agruparlos (GROUP BY).Para hacer querys sobre los objetos se necesita EntityManager para crear unobjeto Query. Luego se tiene el resultado del query llamando el getResultList ogenSingleResult cuando hay solo un objeto retornado. En el ejemplo quesigue, se busca todos los Customers quienes tienen el primer nombre "John",se puede hacer esto de dos formas. De cualquiera de las dos formas el string"John" es buscado: puede ser parte del query JPQL o puede ser pasado comoparmetro, en este ltimo caso necesito usar el mtodo setParameter.2.14. JPA VS JDBCPor ltimo se ve algunas diferencias con el mtodo ms clsico de persistenciade datos en java: JDBC.Desde los primeros das de java la API JDBC ha proporcionado un conjuntode clases e interfaces estandar con sus respectivos mtodos para ejecutarsentencias SQL sobre una base de datos relacional, JDBC fue la tecnologamas ampliamente usada para persistir datos bajo la plataforma java. Mientrasjava fue evolucionando tuvo muchas versiones de JDBC, desde la primeraversin JDBC 1.0 a a la mas reciente JDBC 4.0 (en jdk 6), accesando a labase de datos usando la API JDBC se crea muchos cuota alta de movimientodel cabezal del disco; y el desarrollo de software tiene mucho cdigo pararealizar el mapeo objeto relacional.Sin embargo, algunas de las aplicaciones web n-tier an usan un programaque almacena con sentencias SQL o con llamadas a procedimientosalmacenados para persitir objetos y para crear, leer, actualizar, y borraroperaciones (CRUD).Finalmente en aras de mejorar la performance de la respuesta especialmenteen aplicaciones web, la cache tiene que ser implementada en la capa de laaplicacin.


En muchos de los casos el camino ms a rapido para obtener data de unabase de datos no es ejecutar una consulta compleja; la respuesta es noaccesar frecuentemente a la base de datos, es aqui donde accesamos alacache (la cache es una implementacion de un objeto que ocupa un par clave-valor en la memoria, por ejemplo ID-1, nombre-edison, ID-2,nombre-Daniel,reduciendo el numero de accesos a la base de datos).cuando una consulta es ejecutada por el cliente al valor retornado esalmacenado como un valor de una clave (es cacheado), si en memoria o enun disco duro, si localmente o en un servidor secundario; la principal idea esde reducir directamente el acceso al data source en lo mas posible, asi ,siempre que el navegador (o cuaquier otro cliente) necesita accesar a lainformacion del servidor , la cache es revisada primero por la claveproporcionada , si la informacin fue cacheada, luego el valor es recuperadodesde la cache, consecuentemente, auna visita adicional a el servidor no esnecesaria.Excepto el cache de la aplicacin, algunas bases de datos manejan suspropias implementaciones de cache, un ejemplo de esto es MYSQL, el cualhabilita un query cache en un camino fcil; adems, esto es automticamentemanejado por MYSQL y clientes no cachean la informacin mas de lonecesario; en adiciona esta cache y en orden para mejorar la performance,la aplicacin y el cache del cliente es esencia; desafortunadamente , al cachede la aplicacin no esta presente en una implementacin tradicional de JdbC,y debe ser implementado con el uso de alguna libreria extra y cdigoadicional sobre la otro lado, Hibernate por ejemplo puede usar ehcache (uncache proporcionado por hibernate 2 y 3.x) por medio de un sencilla archivode configuracion y algunas anotaciones (una anotacin es una caractersticadel lenguage que permite atachar cdigo fuente con metadata estructurada ytipada por ejemplo: @Secure22, @ViewScoped).Otra caracterstica del cache es el cache pool de conexiones, el cual gestionaun numero de conexiones a la base de datos sin la necesidad de abrir unaconexin cada vez que una consulta sql es ejecutada, este tipo de cachepuede ser gestionada indistintamente por JDBC o JPA (Java PersistenceAPI). Con el aim de solucionar los problemas mencionados antes (cache eimpl

Fund a Mentos de Java Server Faces

Documents

Transcript of Fund a Mentos de Java Server Faces