Jpa modelos de componentes

JPA Abimael Desales López

www.facebook.com/JavaDevelopersMexico

Modelos de Componentes de Aplicaciones

Componente es una unidad de software reutilizable, autocontenida que puede ser integrada en una aplicación. Los clientes interactúan con los componentes vía un contrato bien definido. En Java, la forma más simple de componente de software es el JavaBean, comúnmente referido sólo como un bean. Los beans son componentes son implementados en términos de una sola clase cuyo contrato está definido por los patrones de nombrado de los métodos en el bean. Los patrones de nombrados de JavaBean son tan comunes ahora que es fácil olvidar que fueron originalmente intentados para darle a los constructores de interfaces de usuario una forma estándar de tratar con componentes de terceras partes.


El modelo estándar de componentes para Java EE es el modelo EJB, el cual define formas para empaquetar, deployar, e interactuar con servicios de negocio autocontenidos. El tipo de EJB determina el contrato requerido para interactuar con él. Los beans de sesión utilizan interfaces Java estándar para definir el conjunto de métodos de negocio que pueden ser invocados en ellos, mientras que el comportamiento de un bean message-driven está determinado por el tipo y formato de los mensajes que el bean está diseñado para recibir.

Usar componentes requiere organizar la aplicación en capas, con servicios de negocio viviendo en el modelo del componente y servicios de presentación en la capa superior de él.


Beneficios que un conjunto de servicios de negocios bien definidos trae a una aplicación:

Débil acoplamiento. Usar componentes para implementar servicios fomenta el débil acoplamiento entre las capas de una aplicación. La implementación de un componente puede cambiar sin impacto alguno a los clientes u otros componentes que dependan de él.

Gestión de dependencias: Las dependencias para un componente pueden ser declaradas en metadatos y automáticamente resueltas por el contenedor.

Gestión del ciclo de vida: El ciclo de vida de un componente es bien definido y gestionado por el servidor de la aplicación. Implementaciones del componente pueden participar en operaciones del ciclo de vida para adquirir y liberar recursos, o ejecutar otro comportamiento de inicialización o shutdown.


Servicios del contenedor declarativos: Los métodos de negocio para componentes son interceptados por el servidor de la aplicación con el fin de aplicar servicios tales como concurrencia, gestión de transacciones, seguridad, y remoting.

Portabilidad: Los componentes que se apegan al estándar Java EE y que son deployados a servidores basados en estándares pueden ser más fácilmente portados de un servidor que cumpla a otro.

Escalabilidad y confiabilidad: Los servidores de aplicación están diseñados para asegurar que los componentes son gestionados eficientemente y con un ojo en la escalabilidad. Dependiendo del tipo de componente y configuración del servidor, las operaciones de negocio implementadas usando componentes pueden reintentar llamadas fallidas a métodos o aún conmutar a otro servidor en un clúster.


Beans de Sesión

Los beans de sesión son una tecnología de componentes diseñada para encapsular servicios de negocio. Las operaciones soportadas por el servicio usualmente son definidas usando una interface Java regular, a la que se le refiere como la interface de negocio del bean de sesión. La implementación del bean es un poco más que una clase Java regular que implementa la interface de negocio si una está presente. Y aún, por virtud de ser parte del modelo de componentes EJB, el bean tiene acceso a un amplio rango de servicios de contenedor que puede aprovechar para implementar el servicio de negocio. Una vez que un cliente adquiere una referencia a un bean de sesión del servidor, inicia una sesión con el bean y puede invocar operaciones de negocio en él.

Hay tres tipos de bean de sesión: stateless, stateful y singleton.


Beans de Sesión Stateless

Como lo mencionamos, un bean de sesión se establece para completar una operación en el tiempo de vida de un sólo método. Los beans stateless pueden implementar muchas operaciones de negocio, pero cada método no puede asumir que algún otro fue invocado antes de él.

Este es por mucho la forma más común de implementación de servicio de negocio. Los beans de sesión stateless están diseñados para llevar operaciones independientes de forma muy eficiente. Los beans de sesión estateless pueden escalar a grandes cantidades de clientes con mínimo impacto a recursos del servidor en general.


Definiendo un Bean de Sesión Stateless

Un bean de sesión es definido en dos partes:

Cero o más interfaces de negocio que definen qué métodos un cliente puede invocar en el bean. Cuando ninguna interface es definida entonces el conjunto de métodos públicos en la clase de implementación del bean forman una interface lógica cliente.

Una clase que implementa estas interfaces, llamada la clase bean, la cual es marcada con la anotación @stateless.

La mayoría de los beans de sesión tienen una interface de negocio, pero no hay restricción en el número de interfaces que un bean de sesión puede exponer a sus clientes.


Cuando el servidor encuentra la anotación @Stateless, sabe tratar a la clase bean como un bean de sesión. Configurará el bean en el contenedor EJB y lo hará disponible para usar por otros componentes en la aplicación. La anotación @Stateless y otras anotaciones escritas aquí están definidas ya sea en el package javax.ejb o javax.annotation.

Veamos una implementación completa de un bean de sesión stateless. El lista 1 muestra la interface de negocio que será soportada por este bean de sesión. En este ejemplo el servicio consiste de un sólo método, sayHello(), que acepta un argumento String correspondiente al nombre de una persona y retorna una respuesta String. No hay anotación o interface padre para indicar que es una interface de negocio.


Cuando es implementada por el bean de sesión, será automáticamente tratada como una interface de negocio local, significando que es accesible sólo a clientes en el mismo servidor de aplicaciones. Para enfatizar que una interface es una interface de negocio local, la anotación @Local puede ser opcionalmente agregada a la interface.

Listado 1 La Interface de Negocio para un Bean de Sesion

public interface HelloService {

public String sayHello(String name);

}

Ahora vamos a considerar la implementación. la cual se muestra en el listado 2.


Esta es una clase Java regular que implementa la interface de negocio HelloService. La única cosa que es única sobre esta clase es la anotación @Stateless que la marca como un bean de sesión stateless. El método de negocio es implementado sin alguna restricción o requerimientos especiales.

Listado 3.1 La clase Bean implementando la Interface HelloService @Stateless

public class HelloServiceBean implements HelloService {

public String sayHello(String name) {

return "Hello, " + name;

}

}


Callbacks del Ciclo de Vida

A diferencia de las clase Java regular usadas en código de la aplicación, el servidor administra el ciclo de vida de un bean de sesión stateless (lo cual afecta la implementación en dos formas).

Primero, el servidor decide cuando crear y remover instancias del bean. La aplicación no tiene control sobre cuándo o cómo muchas instancias de un bean de sesión stateless particular son creadas o alrededor de cuánto ellas permanecerán.


Segundo, el servidor tiene que inicializar servicios para el bean después de que es construido, pero antes de que la lógica de negocios del bean sea invocada. De forma similar, el bean podría tener que adquirir un recurso cómo lo es una fuente de datos JDBC antes de que los métodos de negocio puedan ser usados. Sin embargo, para que el bean adquiera un recurso, el servidor debe primero haber completado de inicializar sus servicios para el bean. Esto limita la utilidad del constructor para la clase debido a que el bean no tendrá acceso a algunos recursos hasta que la inicialización del servidor se haya completado.

Para permitir que el servidor y el bean puedan llevar a cabo sus requerimientos de inicialización, los EJBs soportan


métodos callback de ciclo de vida que son invocados por el servidor en varios puntos en el ciclo de vida del bean. Para los beans de sesión stateless, hay dos callbacks de ciclo de vida: PostConstruct y PreDestroy. El servidor invocará la callback PostConstruct tan pronto como hayan completado la inicialización de todos los servicios del contenedor para el bean. En efecto, esto remplaza al constructor como el lugar para lógica de inicialización debido a que es sólo aquí que los servicios del contenedor garantizan su disponibilidad. El servidor invoca la callback PreDestroy inmediatamente antes de que el servidor libere la instancia del bean para ser recolectado. Algunos recursos adquiridos durante PostConstruct que requieren shutdown explícito deben ser liberados durante PreDestroy.


Listado 3. Usando la Callback PostConstruct para adquirir un Logger

@Stateless

public class LoggerBean implements Logger {

private Logger logger;

@PostConstruct

public void init() {

logger = Logger.getLogger("notification");

}

public void logMessage(String message) {

logger.info(message);

}

}


Interfaces de Negocio Remotas

Hasta aquí, sólo hemos discutido los beans de sesión que usan una interface de negocio local. Local en este caso significa que una dependencia en el bean de sesión puede ser declarada sólo por componentes Java EE que están corriendo juntos en la misma instancia del servidor de aplicación. No es posible usar un bean de sesión con una interface local desde un cliente remoto, por ejemplo.

Para acomodar los clientes remotos, los beans de sesión pueden marcar su interface de negocio con la anotación @Remote para declarar que debe ser usable remotamente. Marcar una interface como siendo remota es equivalente a tener que extender la interface java.rmi.Remote.


La referencia al bean que es adquirido por un cliente no es más una referencia local en el servidor sino un stub de Invocación Remota de Método (RMI) que invocará operaciones en el bean de sesión desde a través de la red. No se requiere soporte especial en la clase bean para usar interfaces remotas.

Listado 4. Una Interface de Negocio Remota

@Remote

public interface HelloServiceRemote {

public String sayHello(String name);

}


Hacer a una interface remota tiene sus consecuencias en términos de performance y cómo son manejados los argumentos a métodos de negocio. Las interfaces de negocio remotas pueden ser usadas localmente en un servidor corriendo, pero haciéndolo así podría resultar en sobrecarga de red si la llamada al método es enrutada a través de la capa RMI. Los argumentos a métodos en interfaces remotas son también pasados por valor en vez de pasados por referencia. Esto significa que el argumento es serializado aún cuando el cliente es local al bean de sesión. Las interfaces locales para clientes locales son generalmente un mejor approach. Las interfaces locales preservan las semánticas de las llamadas a métodos Java regulares y evitan los costos asociados con la red y RMI.


Beans Message-Driven


Servlets

Los servlets son una tecnología de componentes diseñada para servir las necesidades de los desarrollers web quienes necesitan responder a solicitudes HTTP y generar contenido dinámico en retorno. Los servlets son la tecnología más vieja y más popular introducida como parte de la plataforma Java EE. Ellos son la base para tecnologías como Java Server Pages (JSP) y la columna vertebral de frameworks web como Java Server Faces (JSF).

Debido a su cumplimiento en el protocolo HTTP, el web es inherentemente un estado medio. Al igual que los beans de sesión stateless, un cliente hace una request, el servidor dispara el método de servicio apropiado en el servlet, y se genera contenido y es retornado al cliente. Cada request es completamente independiente a la última.


Esto presenta un reto debido a que muchas aplicaciones web involucran alguna clase de conversación entre el cliente y el servidor en la cual las acciones previas del usuario influyen en los resultados retornados en las siguientes páginas.

Los servlets resuelven el problema del estado conversacional con la sesión. No nos confundamos con el bean de sesión, la sesión HTTP es un map de datos asociados con un id de sesión. Cuando la aplicación solicita que una sesión será creada, el servidor genera un nuevo id y retorna un objeto HTTPSesion que la aplicación puede usar para almacenar pares de datos clave/valor. Luego usa técnicas como cookies de navegador para ligar el id de sesión con el cliente, ligándolos en una conversación. Para las aplicaciones web, el cliente es completamente ignorante del estado conversacional que es rastreado por el servidor.


Usar la sesión HTTP de forma efectiva es un elemento importante del desarrollo de servlets. El listado 11 demuestra los pasos requeridos para solicitar una sesión y almacenar los datos conversacionales en ella. En este ejemplo, suponiendo que el usuario se ha logueado, el servidor almacena el id de usuario en la sesión, haciéndolo disponible para uso en todas las solicitudes siguientes por el mismo cliente. La llamada a getSession() en el objeto HttpServletRequest() retornará ya sea la sesión activa o creará una nueva si no existe una. Una vez creada, la sesión actúa como un map, con pares clave/valor asignados y retomados con los métodos setAttribute() y getAttribute(), respectivamente.


Listado 11. Manteniendo Estado Conversacional con un Servlet

public class LoginServlet extends HttpServlet {

protected void doPost(HttpServletRequest request,

HttpServletResponse response)

throws ServletException, IOException {

String userId = request.getParameter("user");

HttpSession session = request.getSession();

session.setAttribute("user", userId);

// ...

}

}


Gestión de Dependencias

La lógica de negocio de un componente Java EE no siempre es autocontenida. La implementación depende de otros recursos hosteados por ser servidor de aplicaciones. Esto podría incluir recursos del servidor como fuentes de datos JDBC o colas de mensajes JMS, o recursos definidos por la aplicación como beans de sesión o entity manager para una unidad de persistencia específica.

Para manejar estas dependencias, los componentes Java EE soportan la noción de referencias a recursos que son definidas en metadatos para el componente. Una referencia es un link nombrado a un recurso que puede ser dinámicamente resuelto en tiempo de ejecución desde el código de la aplicación o resuelto automáticamente por el contenedor cuando la instancia del componente es creado.


Una referencia consiste de dos partes: un nombre y un destino. El nombre es usado por el código de la aplicación para resolver la referencia dinámicamente, mientras que el servidor usa la información destino para encontrar el recurso por el que la aplicación está buscando. El tipo de recurso a ser localizado determina el tipo de información requerida para hacer match con el destino. Cada referencia a recurso requiere un conjunto diferente de información específica al tipo de recurso al que se refiere.

Una referencia es declarada usando una de las anotaciones de referencia a recursos: @Resource, @EJB, @PersistenceContext, o @PersistenceUnit. Las anotaciones pueden ser puestas en una clase, campo, o método setter. La elección de la ubicación determina el nombre default de la referencia, y si el servidor resuelve o no automáticamente la referencia.


Búsqueda de Dependencias


Inyección de Dependencias


Declarando Dependencias

Las siguientes secciones describen algunas de las anotaciones definidas por las especificaciones Java EE y EJB. Cada anotación tiene un atributo name para especificar opcionalmente el nombre de la referencia para la dependencia. Otros atributos en la anotación son específicos al tipo de recurso que necesita ser adquirido.

Referenciando un Persistence Context

En el entorno Java EE, la anotación @PersistenceContext puede usarse para declarar una dependencia en un contexto de persistencia y tiene el entity manager para ese contexto de persistencia adquirido automáticamente.


El listado 16 demuestra el uso de la anotación @PersistenceContext para adquirir un entity manager a través de inyección de dependencias. El elemento unitName especifica el nombre de la unidad de persistencia en la cual el contexto de persistencia estará basado.

Listado 16. Inyectando la Instancia a un EntityManager

@Stateless

public class EmployeeServiceBean implements EmployeeService {

@PersistenceContext(unitName="EmployeeService")

EntityManager em;

// ...

}


Después de los warnings sobre usar un campo estático en un bean de sesión stateless, podrías estar preguntándote como es que este código es legal. Después de todo, los entity manager deben mantener su propio estado para ser capaces de gestionar un contexto de persistencia específico. Las buenas nuevas es que la especificación fue diseñada con la integración de Java EE en mente, de forma que lo que es inyectado en el Listado 16 no es la instancia a un entity manager. El valor inyectado en el bean es un proxy gestionado por el contenedor que adquiere y libera contextos de persistencia a mitad del código de la aplicación. Es seguro asumir que el valor inyectado “hará las cosas bien”.


Referenciando a una Persistence Unit

El EntityManagerFactory para una unidad de persistencia puede ser referenciado usando la anotación @PersistenceUnit. Al igual que la anotación @PersistenceContext, el elemento unitName identifica la unidad de persistencia para la instancia EntityManagerfactory que queremos accesar. Si el nombre de la unidad de persistencia no es especificado en la anotación, es específico del proveedor cómo será determinado.

El listado 17 demuestra la inyección de la instancia de una EntityManagerFactory en un bean de sesión stateful. El bean luego crea la instancia de un EntityManager de la factory usando la callback de ciclo de vida PostConstruct.


Listado 17. Inyectando una Instancia de EntityManagerFactory @Stateful

public class EmployeeServiceBean implements EmployeeService {

@PersistenceUnit(unitName="EmployeeService")

private EntityManagerFactory emf;

private EntityManager em;

@PostConstruct

public void init() {

em = emf.createEntityManager();

}

// ...

}

La EntityManagerFactory para una unidad de persistencia casi no es usada en el entorno Java EE debido a que los entity managers son más fáciles de adquirir y usar.


Referenciando Enterprise JavaBeans


Auditando Recursos del Servidor


Gestión de Transacciones

Más que cualquier otro tipo de aplicación empresarial, las aplicaciones que usan persistencia requieren atención cuidadosa a temas de gestión de transacciones. Cuándo inician las transacciones, cuándo terminan, y cómo los entity managers participan en las transacciones gestionadas por el contenedor son todos los tópicos esenciales para desarrolladores que usan JPA.

Una transacción es una abstracción que es usada para agrupar una serie de operaciones. Una vez agrupadas, el conjunto de operaciones es tratada como una sola unidad, y todas las operaciones deben producirse o ninguna de ellas se producirá. La consecuencia de que sólo algunas de las


operaciones fueran exitosas produciría una vista inconsistente de los datos que sería perjudicial o indeseable a la aplicación. El término usado para describir si las operaciones proceden juntas o no en todo es llamado atomicidad y es argumentablemente la más importante de las cuatro propiedades básicas que son usadas para caracterizar como se comportan las transacciones. Es fundamental comprender estas cuatro propiedades para comprender las transacciones. La siguiente lista resume estas propiedades:

Atomicidad: Ya sea que todas las operaciones en una transacción sean exitosas o ninguna de ellas. El éxito de cada operación individual está atada al éxito del grupo completo


Consistencia: El estado resultante al final de una transacción se adhiere a un conjunto de reglas que definen aceptabilidad de los datos. Los datos en el sistema entero son legales o válidos con respecto al resto de los datos en el sistema.

Aislamiento: Los cambios hechos en una transacción son visibles sólo a la transacción que está haciendo los cambios. Una vez que una transacción emite los cambios, ellos son atómicamente visibles a otras transacciones.

Durabilidad: Los cambios hechos a una transacción perduran más allá de que se haya completado la transacción.

Una transacción que reúne todos estos requerimientos se dice que es una transacción ACID (el término familiar ACID es obtenido de combinar las primeras letras de cada una de las cuatro propiedades).


Transacciones empresariales en Java EE

Las transacciones realmente existen en diferentes niveles del servidor en el servidor de aplicación empresarial. La más baja y más básica transacción está en el nivel del recurso, el cual en nuestra discusión se asume que es base de datos relacional presentado por una DataSource. Esta es llamada una transacción de recurso-local y es equivalente a una transacción de base de datos. Estos tipos de transacciones son manipuladas interactuando directamente con la DataSource JDBC que es obtenida del servidor de aplicaciones. Las transacciones de recursos locales son usadas de forma mucho más infrecuente que las transacciones gestionadas por el contenedor.


Demarcación de Transacciones

Cada transacción tiene un inicio y un final. Iniciar una transacción permitirá subsecuentes operaciones para llegar a ser una parte de la misma transacción hasta que la transacción se haya completado. Las transacciones pueden ser completadas en una o dos formas. Ellas pueden ser emitidas, causando que todos los cambios sean persistidos al almacén de datos, o retraídas, indicando que los cambios deben ser descartados. El acto de causar que una transacción inicie o se complete es titulado demarcación de transacción. Esta es una parte crítica de escribir aplicaciones empresariales, debido a que hacer la demarcación de transacciones de forma incorrecta es una de las fuentes más comunes de degradación del performance.


Las transacciones de recursos locales son demarcadas explícitamente siempre por la aplicación, mientras que las transacciones de contenedor pueden ser demarcadas automáticamente por el contenedor o usar una interfaz JTA que soporte la demarcación controlada por la aplicación. En el primer caso, cuando el contenedor toma la responsabilidad de demarcación de transacción, la llamamos gestión de transacción manejada por el contenedor, pero cuando la aplicación es responsable para la demarcación, la llamamos gestión de transacción manejada por el bean.

Los EJBs pueden usar transacciones gestionadas por el contenedor o transacciones gestionadas por el bean. El estilo de gestión de transacción default para un componente EJB es gestionada por el contenedor.


Para configurar un EJB para tener un sus transacciones demarcadas de una forma a otra, la anotación @TransactionManagement debe ser especificada en la clase bean de sesión o message-driven. El tipo enumerado TransactionMangementType define BEAN para transacciones gestionadas por bean y CONTAINER para transacciones gestionadas por el contenedor. Transacciones Gestionadas por el Contenedor

La forma más común para demarcar transacciones es usar transacciones gestionadas por el contenedor (CMTs), las cuales le evitan a la aplicación el esfuerzo y código para iniciar y emitir transacciones explícitamente.


Los requerimientos de transacción son determinados por metadatos en beans de sesión y message-driven y son configurables en la granularidad de ejecución de método. Por ejemplo, un bean de sesión puede declarar que siempre que cualquier método específico en ese bean sea invocado, el contenedor debe asegurar que una transacción haya iniciado antes de que el método inicie. El contenedor también sería responsable para emitir la transacción después de completado el método. Es común para un bean invocar a otro bean desde uno o más de sus métodos. En este caso, una transacción que puede haber sido iniciada llamando al método no habría sido emitida debido a que el método llamante no se habrá completado hasta que su llamada al segundo bean se haya completado. Esto es porque necesitamos configuraciones para definir como el contenedor debe comportarse cuando un método es invocado en un contexto transaccional específico.


Por ejemplo, si una transacción ya está en progreso cuando un método es llamado, podría esperarse que el contenedor sólo hiciera uso de esa transacción, mientras que podría ser dirigido para iniciar una transacción nueva si ninguna transacción está activa. Estas configuraciones son llamadas atributos de transacción, y ellas determinan exactamente cual es el comportamiento transaccional gestionado por el contenedor.

Los selecciones de atributos de transacción definidos son los siguientes:

MANDATORY: Si este atributo es especificado para un método, se espera que una transacción ya haya sido iniciada y esté activa cuando el método es llamado. Si ninguna transacción está activa, se lanza una excepción.


Este atributo es muy pocas veces usado, pero puede ser una herramienta de desarrollo para atrapar errores de demarcación de transacción cuando se espera que una transacción ya debe haber sido iniciada.

REQUIRED: Este atributo es el caso más común, en el cual un método se espera que esté en una transacción. El contenedor proporciona una garantía que una transacción esté activa para el método. Si una está activa, se usa; si no existe una, se crea una nueva transacción para la ejecución del método.

REQUIRES_NEW: Este atributo es usado cuando el método siempre necesita estar en su propia transacción; esto es, el método debe ser emitido o retraído independientemente de métodos más arriba de la pila de llamadas. Debe ser usado con precaución debido a que puede llevar a sobrecarga excesiva de transacciones.


SUPPORTS: Los métodos marcados con SUPPORTS no son dependientes de una transacción, pero tolerarán correr dentro de una si existe. Este es un indicador que no son accesados recursos transaccionales en el método.

NOT SUPPORTED: Un método marcado a transacciones not support causará que el contenedor suspenda la transacción actual si una está activa cuando el método es llamado. Implica que el método no ejecute operaciones transaccionales, pero podría fallar en otras formas que podrían afectar indeseablemente la salida de una transacción. Este es un atributo no muy usado comúnmente.


NEVER: Un método marcado a never soporta transacciones que causarán que el contenedor lance una excepción si una transacción está activa cuando el método es llamado. Este atributo es muy raramente usado, pero puede ser una herramienta de desarrollo para cachar errores de demarcación de transacciones cuando se espera que las transacciones ya deben haber sido completadas.

En cualquier momento que el contenedor inicie una transacción para un método, el contenedor asume también intentar emitir la transacción al final del método. Cada vez que la transacción actual deba ser suspendida, el contenedor es responsable para reanudar la transacción suspendida en la conclusión del método.


El atributo transaction para un método puede ser indicado anotando una clase bean de sesión o message-driven, o uno de sus métodos que es parte de la interface de negocio, con la anotación @TransactionAttribute. Esta anotación requiere un sólo argumento del tipo enumerado TransactionAttirbuteType, los valores del cual son definidos en la lista anterior. Anotar la clase bean causará que el atributo transaction aplique a todos los métodos de negocio en la clase, mientras que anotar un método aplica el atributo sólo al método. Si ambas anotaciones a nivel de clase y de método existen, la anotación a nivel de método toma precedencia. En ausencia de anotaciones @TransactionAttribute a nivel de clase o de método, el atributo default de REQUIRED será aplicado.


Usando Componentes JEE


GRACIAS

Dudas y comentarios a la página o al correo:

[email protected]

Es un placer escribir para ustedes

mailto:[email protected]

Jpa modelos de componentes

Documents

Transcript of Jpa modelos de componentes