César Francisco Castillo - Desarrollo de aplicaciones web con Jakarta EE

CriteriaBuilder criteriaBuilder =em .getCriteriaBuilder ();CriteriaQuery criteriaQuery =criteriaBuilder .createQuery ();Root raiz =criteriaQuery .from (Carrera .class);String texto =“pro” ;criteriaQuery .where (criteriaBuilder .like (criteriaBuilder .lower (raiz .get (“nombre” )),“%” +texto +“%” ));TypedQuery <Carrera >query =em .createQuery (criteriaQuery ); returnquery .getResultList ();

Para mayor detalle sobre Criteria API puede acceder a la siguiente dirección URL: https://wiki.eclipse.org/Main_Page

En este capítulo realizamos un recorrido general por la API de persistencia de Jakarta EE e intentamos cubrir los aspectos más básicos y esenciales para manipular los accesos a una base de datos desde nuestras aplicaciones.

Vimos que JPA es un estándar de ORM y que existen diversas implementaciones. Además, nos adentramos en su corazón mediante el estudio de algunos de sus elementos, como el archivo de configuración persistence.xml, su administrador de entidades y su contexto de persistencia.

Aprendimos cómo realizar mapeos y asociaciones entre clases y a utilizar el lenguaje JPQL, el cual nos permite realizar consultas a la base de datos. Por último, vimos la API de criterios para definir consultas dinámicas.

“Los Enterprise JavaBeans son componentes JEE diseñados para encapsular, resolver y ejecutar la lógica y las reglas del negocio de la aplicación” (Sznajdleder, 2015, pág. 91), por lo que actuarán dentro de la capa de negocio. Estos componentes necesitan residir dentro de un contenedor EJB, por ejemplo, Payara Server, que será el encargado de gestionar su ciclo de vida.

Dentro de estos componentes podemos encapsular el acceso a la base de datos definiendo diferentes operaciones, tales como: inserción, edición, eliminación y consulta de registros utilizando la API de persistencia (JPA).

La tecnología EJB comprende los session beans ( beans de sesión) para la comunicación sincrónica y los message-driven beans ( beans dirigidos por mensajes) para la comunicación asincrónica. En este libro nos centraremos en los session beans.

En este capítulo cubriremos los siguientes temas:

* Tipos de session beans

* Interfaces Local y Remote

* Eventos EJB

* Tareas programadas

* Desarrollo de módulo EJB con acceso a base de datos

Los session beans pueden ser de los siguientes tipos:

* Stateless

* Stateful

* Singleton

Un stateless session bean es un componente sin estado, el cual consiste en una clase java que incluye la anotación @Stateless y que cuenta con al menos un método, como se puede apreciar en el siguiente fragmento de código:

El contenedor mantiene un grupo de instancias de estos EJB (pool) para atender a los diversos clientes que pudieran solicitar alguna de ellas. Cabe destacar que dichas instancias no pueden distinguirse entre sí, ya que para el container son todas “iguales” y la cantidad del pool se puede ampliar o disminuir en función de las necesidades de cada aplicación. Por ejemplo, en Payara, este número se puede configurar en la sección “EJB Container ” que se encuentra dentro de “server-config” en el menú “Configurations”.

Por su parte, un stateful session bean es un componente que sí tiene estado, mantiene un vínculo con el cliente y puede contener variables de instancias. Se denota utilizando la anotación @Stateful, como se aprecia en el siguiente fragmento de código:

A diferencia de los stateless beans y su pool , el contenedor debe ser capaz de proveer instancias para cada cliente que las solicite.

Un singleton session bean es un componente similar a un stateless , pero con la diferencia de que incluye la anotación @Singleton y que en el contenedor solo puede existir una única instancia de él.

En lo que respecta a los clientes y a las invocaciones, diremos que un EJB puede tener como clientes a otro EJB, una aplicación en modo consola (standalone) o algún componente web como un servlet.

Las invocaciones pueden ser locales, desde componentes que residan en el mismo contenedor, o bien externas o remotas, desde procesos que no se encuentren en dicho contenedor.

Para profundizar en los conceptos relacionados con los EJB, puede acceder a las especificaciones disponibles en la siguiente dirección URL: https://jakarta.ee/specifications/enterprise-beans/

Una interface Java contiene los métodos de negocio que se han de implementar en una determinada clase o componente. En el caso de los componentes EJB, las interfaces que se implementen deben ser de tipo Local o Remote para accesos internos o externos, respectivamente. Si no se implementa ninguna interfaz, como en el caso de los anteriores ejemplos, el contenedor (servidor Payara) “entiende” o “interpreta” que las invocaciones a los métodos del EJB serán locales y no podrán ser accedidos desde otro contexto. Por el contrario, las invocaciones se realizan desde el exterior (una JVM distinta) y se debe implementar la interfaz Remote. Mediante la API JNDI (Java Naming and Directory Interface) podemos acceder a estos recursos remotos.

Los siguientes ejemplos muestran cómo implementar las interfaces con métodos CRUD:

Interface TestBeanRemote.java

EJB TestBean.java

Con la implementación de la interface TestBeanRemote, el EJB TestBean es accesible desde el exterior y cualquier cliente podrá invocar sus métodos. En caso de requerir una implementación local, se debe reemplazar la anotación @Remote por @Local.

Según una de las tres definiciones de la Real Academia Española, un evento es un suceso de importancia que se encuentra programado.