Modelos de Programación II: EJB y Java Persistence API, Ejercicios de Programación Java

¡Descarga Modelos de Programación II: EJB y Java Persistence API y más Ejercicios en PDF de Programación Java solo en Docsity!

EJE 3

Pongamos en práctica

Fuente: Shutterstock/

MODELOS DE

PROGRAMACIÓN II

Pedro Julián González

ÍNDICE

• Introducción
• Aspectos generales de EJB
  • Ventajas de EJB
    • Servicios (middleware)
    • División de trabajo
    • Diversos vendedores
  • EJB y sus desventajas
    • Tiempo de desarrollo
    • Amplio conocimiento de Java
  • Tipos de EJB
    • Session EJB
  • Introducción a Java Persistence API
    • Persistencia en el nivel web
    • Persistencia en el nivel EJB
    • Entornos de ejecución EJB
    • Servicios que brinda un contenedor EJB
    • Tipos de beans enterprise
    • Java Persistence Query Language
• Bibliografía

Aspectos generales de

EJB

Siglas de Enterprise Java Bean Es un componente que debe eje- cutarse en un contenedor de EJB y se diferencia bastante de uno tipo Java Bean Es decir, no se puede acceder a él directamente, sino a través de un objeto que haga las veces de intermediario

Principalmente se encarga de agrupar funcionalidades para determinada aplicación, aun así, si un Java Bean es comparado con este, un EJB, se puede definir como un deployable component , es decir, requiere que exista un escenario de ejecución como parte de un Java Application Server

Java Bean Es un componente que sue- le utilizarse en Java, el cual permite la agrupación de funcionalidades para hacer parte de una aplicación (Ós- mosis Latina, s f )

Ventajas de EJB

A través de un contenedor, un EJB brinda diferentes funcionalidades y servicios que no están disponibles normalmente en un Java Bean, las siguientes son algunas de ellas

Servicios ( middleware )

Cuando un componente de software es diseñado, deben definirse múltiples servicios para que funcionen correctamente, entre ellos se encuentran:

• Al generarse un error ¿cuál es el procedimiento adecuado que debería ejecutarse?
• ¿Cuál es la alternativa, en caso de que la base de datos definida y asignada se encuentre desactivada?
• En caso de no lograr cumplir con éxito los procedimientos establecidos, ¿se debe intentar nuevamente ejecutar las transacciones pendientes?

Es importante tener en cuenta que los servicios tienden a ser requeridos, al igual que la lógica que se encuentra inmersa en los principales componentes, aún así, los EJB se pueden ofrecer a través del uso de un contenedor del mismo tipo, en el cual se agrega la lógica de negocio, definiendo y generando componentes para ello

División de trabajo

Es posible dividir componentes principales (EJB) de servicios (EJB Container) ya que facilita la identificación de una división de trabajo, es decir, un diseñador de compo- nentes logra centrar su esfuerzo en la lógica de proceso, sin que el diseño de servicios o middleware le preocupe De igual forma, este último deberá estar pendiente y centrarse en su área

Sin embargo, dicha división de trabajo genera una pregunta: ¿cómo se alcanza la interoperabilidad? La operabilidad interna entre componentes y servicios se debe prin-

Tipos de EJB

Session EJB

Estos permiten realizar cierta lógica que ha sido solicitada por un cliente ya sea un JSPServlet, Applet o incluso otro EJB Pue- den mencionarse los dos tipos de Session EJB

Stateless (session) EJB

Como su nombre indica, no se encarga de mantener estados ( stateless ) en el con- tenedor EJB, estos son utilizados para la realización de actividades rutinarias que no necesitan rastrear o identificar al cliente Dentro de los EJB de este tipo puede men- cionarse: búsquedas generales y operacio- nes matemáticas complejas

Stateful (session) EJB

A diferencia de los EJB descritos ante- riormente, los stateful facilitan mantener la sesión del cliente en el contenedor EJB, de esta manera, puede trabajar con cierto grupo de datos específicos gestionados por el contenedor La aplicación apropiada para este tipo de EJB es uno cuyos compo- nentes son de tipo shopping cart o compra, los cuales facilitan la identificación de pro- ductos e información de índole personal del cliente mediante un lapso amplio ( session )

Entity EJB

Estos suelen trabajar en conjunto con un repositorio de información (por lo general una base de datos administrada bajo una arquitectura relacional), esto hace que el EJB administre la información que se encuentra almacenada en sistemas dife- rentes al contenedor EJB; en los stateful session , de ocurrir un inconveniente en el

contenedor, es probable que se pierda la información, en cambio, si se usa un Entity EJB los datos podrán permanecer en el sis- tema más cercano Dicho de otra forma, los Entity EJB administran una copia exacta de la información que se encuentra en un sistema diferente

De igual manera que Session EJB existen tres tipos de Entity EJB:

Bean Managed Persistence

Estos necesitan que la lógica requerida para ingresar al sistema de información (por lo general conectado a una base de datos), esté claramente definida de forma manual Casi siempre esta lógica se puede encontrar en JDBC en la que se define cuándo y cómo debe ser accesada, modi- ficada y resguardada la información entre la base de datos y el EJB

Visitar página

Para ampliar información visite la página:

Introducción a la tecnología EJB

Container Managed Persistence

Este Entity Bean es administrado por el contenedor EJB, diferente al que posee un Bean Managed EJB, donde es necesario definir una lógica puntual para el acceso manual En los Container Managed EJB el contenedor se encarga de generar toda la lógica necesaria para acceder al sistema de información

Messaging EJB

Este Entity Bean brinda un conjunto de funcionalidades de aplicaciones tipo messaging como Rendez-Vous de Tibco o MQSeries de IBM De forma general, un sis- tema messaging funciona como un inter- mediario para poder recibir y hacer parte de la publicación de mensajes Dentro de las ventajas de un sistema de mensajes es que su operación es de forma asincrónica también conocida como non-blocking

En otras palabras, JPA es un framework que forma parte de Java y ofrece un con- junto de interfaces y API para resolver el problema del almacenamiento de los obje- tos en una base de datos relacional JPA no es una implementación en sí misma, sino que brinda interfaces para ser luego implementadas por distintos proveedores De esta manera, en el código se usa el API de JPA, que luego será implementado por la librería que más convenga

De forma muy simple, una tabla (en base de datos) se debe mapear contra una clase y cada columna (atributo) contra un atributo de esa clase Usaremos anotacio- nes de JPA para indicar estas relaciones Por eso la implementación con JPA se deberá encargar del ocultamiento de la compleji- dad del acceso de datos y de exponer obje- tos Idealmente, una solución de software con JPA, no requiere generar Query SQL para interactuar con los datos (no tiene contacto directo con la base de datos)

JPA ofrece:

• Un conjunto de anotaciones (del pa- quete javax persistence) para ano- tar nuestros objetos e indicar cómo se realiza el mapeo a la base de da- tos
• Un lenguaje de consultas llamado JPQL (Java Persistence Query Lan- guage) que es utilizado para consul- tar los objetos de tipo Persistence

Instrucción

En este punto lo invitamos a realizar el control de lectura disponible en la página principal del eje

Introducción a Java Persistence

API

Java Persistence API o JPA es el estándar de Java que se encarga de automatizar la persistencia de los objetos contenidos en una base de datos Aun así, en un nivel básico, logra generar dudas a quienes lo desarrollan También puede definirse como un conjunto de clases y métodos que per- sistentemente almacenan gran cantidad de información en un repositorio de datos

Clases Es la definición de las características concretas de un determinado tipo de objetos Es decir, cuáles son los datos y los métodos de los que van a disponer todos los objetos de esa clase (devjoker com, s f )

Instrucción

Lo invitamos a la página principal del eje para realizar la actividad de emparejamiento

Servicios que brinda un contenedor EJB

Una persona que quiera desarrollar las interfaces y las clases a partir del uso de objetos bean enterprise , podrá acceder con facilidad a los servicios de bajo nivel que se describen a continuación

• Manejo de las transacciones
• Seguridad
• Persistencia
• Acceso remoto
• Control del correspondiente del ciclo de vida del componente
• Repositorio de conexiones a la base de datos
• Repositorio de ejemplares

Debido a que el contenedor EJB adminis- tra los paquetes de servicios en términos de los EJB y su infraestructura, un desarrolla- dor podría, simplemente concentrarse en crear la lógica de negocio de dicho objeto

• Beans de sesión
• Beans de entidad

Los beans de entidad y de sesión son llamados sincrónicamente a través de un cliente tipo BE (bean enterprise ) Los beans que se dirigen a través de mensajes (MDB) son llamados a través de contenedores de mensajes, como un común publicar/ subscribir

Beans orientados por mensaje

Estos hacen referencia a BE que admi- nistran de manera asincrónica los mensajes entrantes Por lo general, un componente de MDB se comporta como un oyente de los mensajes que se han enviado, desde la perspectiva publicar/subscribir Los MDB son capaces de recibir mensajes que son compatibles con JMS

Los contenedores EJB administran el ciclo de vida de los MDB pero a diferencia de los beans de entidad y sesión, las apli- caciones clientes no suelen direccionarse al MDB con el llamado de métodos En lugar de eso, el respectivo MDB recibe los mensajes de una fuente definida para ello mediante métodos de retrollamadas tipo Onmessage

Beans de sesión

Estos representan un solo cliente que no se ha de compartir entre ellos Por lo general un cliente se encarga de llamar a los métodos que corresponden al bean de sesión, los cuales se direccionan a través del contenedor EJB hacia el BE El encargado de realizar la lógica de negocio para el cliente es el bean de sesión Posteriormente el contenedor retorna el control al cliente

Instrucción

Lo invitamos a ver la infografía disponible en la página principal del eje

Tipos de beans enterprise

EJB ha definido los beans enterprise en tres tipos diferentes, estos son:

• Beans dirigidos a través de mensa- jes

Los beans de sesión no persisten entre diversas sesiones y se pueden encontrar tres tipos:

Beans de sesión con estado

Los beans de sesión con estado man- tienen estados conversacionales con los respectivos clientes durante el tiempo que dure la sesión Esto hace que estos pue- dan mantener diversos tipos de variables a través de llamadas desde un único cliente entorno a una sola sesión, en el momento en que el cliente finaliza su interacción con el contenedor EJB y el bean enterprise cul- mina la sesión del bean y elimina los datos de estado del respectivo bean

Beans de sesión sin estado

Este tipo de beans se caracterizan por no mantener estados conversacionales para cada cliente Cada vez que un bean de sesión sin estado es llamado, se considera como una solicitud a un elemento nuevo, ya que sin importar el estado que exista de las correspondientes variables, este se perderá

• El contenedor EJB no mantiene los beans de sesión sin estado en el al- macenamiento secundario; por esto un desarrollador debe tener claro que los datos son temporales entre las llamadas de un cliente La naturale- za temporal de los beans de sesión sin estado facilita que un contene- dor EB reutilice ejemplares de beans y, por ende, optimice su rendimiento

Beans de entidad

Estos componentes están pensados para que representen la lógica de negocio de una entidad existente en un almacena-

miento persistente, como una base de los datos Los beans de entidad pueden com- partir algunas cualidades que se podrían encontrar en una base de datos bajo un modelo relacional, por ejemplo:

• Los beans de entidad suelen ser per- sistentes: el estado de un compo- nente de este tipo existe más allá del ciclo de vida de la aplicación en la que se ha generado, incluso muchas veces, más allá del ciclo de vida del contenedor Esto se traduce en que el contenedor EJB tiene la capacidad de restaurar el bean de entidad a su correspondiente estado original
• Un bean de entidad permite com- partir accesos: podría compartirse entre varios clientes, haciendo que la concurrencia la maneje el contene- dor
• Un bean de entidad posee claves primarias: existen clases primary key para la identificación de un ejemplar de un bean de entidad La clave pri- maria suele contener toda la infor- mación requerida para ubicar uno almacenado
• De ser necesario, un bean de entidad podría participar en relaciones: exis- ten proyectos en los que se definen interfaces locales para el manejo de las relaciones entre múltiples beans
• Un bean de entidad puede partici- par en transacciones: debido a que varios clientes pueden acceder y cambiar los datos, es relevante para los beans de entidad definir los atri- butos transaccionales para su inte- racción Una propiedad de transac- ción se especifica en descriptores de

Funciones escalares y agregadas

Las funciones escalares devuelven valores resultantes basados en los valores de entrada Funciones de agregado devuelven los valores resultantes mediante el cálculo de los de entrada

Ejemplo

Por ejemplo, una consulta JPQL puede recuperar una entidad objeto en lugar del campo conjunto de resultados de una base de datos, al igual que con SQL El JPQL consulta se estructura como se muestra a continuación

Figura 1 Sentencia select Fuente: propia

Figura 2 Sentencia delete y update Fuente: propia

Figura 3 Ejemplo de funciones escalares y agregadas explicadas en clase Fuente: propia

Between and like: palabras clave

Between (entre), and (y) y like (como) son las palabras clave principales de JPQL Estas palabras clave se utilizan después de where, cláusula en una consulta

Figura 4 Ejemplo de palabras clave explicadas en una clase Fuente: propia

Figura 5 Ejemplo del uso de la cláusula ORDER BY explicada en una clase Fuente: propia

Ordenar

Para ordenar los registros en JPQL, se utiliza la cláusula ORDER BY El uso de esta cláusula es igual que en SQL, pero se trata de entidades El ejemplo siguiente muestra cómo utilizar la cláusula ORDER BY

Perezoso y ansioso por buscar

El concepto más importante de JPA es hacer una copia duplicada de la base de datos en la memoria caché Mientras se tramita con una base de datos, la JPA primero crea un duplicado de los datos y solo cuando se ha comprometido con una entidad, los cambios se realizan en la base de datos Allí existen dos maneras de obtener los registros de la base de datos

Fetch ansioso

Al buscar ansiosos relacionados con objetos secundarios estos se cargan automática- mente con el fin de encontrar un registro concreto

Lazy fetch

Al recuperar el perezoso, objetos relacionados no se cargan automáticamente a menos de que usted lo solicite específicamente para ellos En primer lugar, se comprueba la disponibilidad de objetos relacionados y notifica Más tarde, si se llama a cualquiera del método Getter de esa entidad, recupera todos los registros

Figura 7 Ejemplo de llamado a consultas explicado en una clase Fuente: propia

Un fetch perezoso es posible cuando se intentan buscar los registros por primera vez De esa manera, una copia del registro ya está almacenada en la memoria caché Para temas de rendimiento, es preferible este tipo de tarea Es allí donde se vislumbra la rea- lidad y la importancia de conocer algunas de las herramientas de desarrollo de software para brindar verdaderas soluciones web y móviles a las diferentes problemáticas que se presentan en las áreas del conocimiento, la industria y el hogar

Instrucción

Lo invitamos a la página principal del eje para revisar la galería