Beans asíncronos

Un bean asíncrono es un objeto Java™ o enterprise bean que una aplicación Java Platform, Enterprise Edition (Java EE) puede ejecutar asíncronamente, utilizando el contexto Java EE del creador del bean asíncrono.

Deprecated feature Deprecated feature: El gestor de trabajo y el temporizador de beans asíncronos y CommonJ son recursos de planificación asíncronos en desuso. Concurrency Utilities for Java EE sustituye estos recursos de planificación en desuso. La versión 9 continúa dando soporte al gestor de trabajo y el temporizador de beans asíncronos y CommonJ. Sin embargo, la documentación de la Versión 9 se centra en Concurrency Utilities for Java EE. Si no encuentra la información sobre los beans asíncronos que busca en la documentación de la Versión 9, consulte la documentación de la Versión 8.5.5.depfeat

Los beans asíncronos pueden mejorar el rendimiento, al permitir que un programa Java EE descomponga las operaciones en tareas paralelas. Los beans asíncronos permiten crear aplicaciones Java EE activas con estados. Estas aplicaciones se ocupan de un segmento del espacio de aplicación de las aplicaciones que requieren hebras de aplicación, agentes activos en una aplicación de servidor o prestaciones de supervisión distribuidas.

Los beans asíncronos pueden ejecutarse utilizando el contexto de seguridad Java EE del componente Java EE creador. Estos beans también pueden ejecutarse con copias de otros contextos Java EE, como por ejemplo:
  • Contexto de internacionalización
  • Perfiles de aplicación, que no se soportan para aplicaciones Java EE 1.4 y están en desuso para aplicaciones Java EE 1.3
  • Áreas de trabajo

Interfaces de beans asíncronos

Existen cuatro tipos de beans asíncronos:
Objeto de trabajo
Hay dos interfaces de trabajo que llevan a cabo fundamentalmente el mismo objetivo. La interfaz de trabajo Beans asíncronos heredada es com.ibm.websphere.asynchbeans.Work, y la interfaz de trabajo CommonJ es commonj.work.Work. Un objeto de trabajo se ejecuta paralelamente al emisor utilizando el método startWork o schedule de gestor de trabajo (startWork para Beans asíncronos y schedule para CommonJ). Las aplicaciones implementan objetos de trabajo para ejecutar bloques de código de forma asíncrona.
Escucha de temporizador
Esta interfaz es un objeto que implementa la interfaz commonj\timers\TimerListener. Las escuchas de temporizador se llaman cuando caduca un temporizador transitorio de alta velocidad.
Escucha de alarmas
Una escucha de alarmas es un objeto que implementa la interfaz com.ibm.websphere.asynchbeans.AlarmListener. Se llama a las escuchas de alarmas cuando caduca una alarma transitoria de alta velocidad.
Escucha de sucesos
Una escucha de sucesos puede implementar cualquier interfaz. Una escucha de sucesos es un mecanismo ligero de notificación asíncrona para los sucesos asíncronos dentro de una JVM (Java Virtual Machine). Un escucha de sucesos se utiliza normalmente para que los componentes Java EE contenidos en una aplicación puedan notificarse entre sí los diferentes sucesos asíncronos.

Soporte de interfaces

Gestor de trabajo
Los gestores de trabajo son agrupaciones de hebras que crean los administradores para las aplicaciones Java EE. El administrador especifica las propiedades de la agrupación de hebras y una política que determina qué contextos Java EE heredará el bean asíncrono.
Gestor de trabajo CommonJ
El gestor de trabajo CommonJ es parecido al gestor de trabajo. La diferencia entre los dos estriba en que el gestor de trabajo CommonJ contiene un subconjunto de los métodos de gestor de trabajo de los beans asíncronos. Aunque el gestor de trabajo CommonJ funciona en un entorno Java EE 1.4, cada búsqueda de JNDI de un gestor de trabajo no devuelve una nueva instancia de gestor de trabajo. Toda la búsqueda de JNDI de gestores de trabajo dentro de un ámbito tienen la misma instancia.
Gestor de temporizador
Los gestores de temporizador implementan la interfaz commonj.timers.TimerManager, que permite aplicaciones Java EE, incluidos servlets, aplicaciones EJB y adaptadores de recursos JCA, para programar futuras notificaciones de temporizador y recibir notificaciones de temporizador. El gestor de temporizador para la especificación de servidores de aplicación proporciona una alternativa soportada de servidor de aplicación al uso de la clase java.util.Timer de J2SE, que no es apropiada para entornos gestionados.
Origen de suceso
Un origen de suceso implementa la interfaz com.ibm.websphere.asynchbeans.EventSource. Un origen de suceso es un objeto proporcionado por el sistema que da soporte a un servidor genérico de notificación asíncrona de tipo seguro dentro de una JVM. El origen del suceso permite registrar objetos de la escucha de sucesos, que implementan cualquier interfaz.
EventSourceEvents
Los orígenes de sucesos también pueden generar sus propios sucesos como, por ejemplo una cuenta de escucha modificada. Una aplicación puede registrar un objeto de escucha de sucesos que implemente la clase com.ibm.websphere.asynchbeans.EventSourceEvents. Esto permite a la aplicación detectar sucesos como, por ejemplo, si se añaden o suprimen escuchas, o si una escucha genera una excepción imprevista.

En el tema Desarrollo de ámbitos asíncronos, que describe algunas de las aplicaciones avanzadas de beans asíncronos, se presentan otras interfaces, incluidas las alarmas y los supervisores de subsistemas.

Transacciones

Todo método de bean asíncrono se invoca utilizando su propia transacción, de la misma forma que las transacciones gestionadas por contenedor en los enterprise beans típicos. Esta situación es muy parecida a cuando se llama a un método de EJB (Enterprise JavaBeans (EJB) con TX_NOT_SUPPORTED. El tiempo de ejecución inicia un contenedor de transacciones locales antes de invocar el método. El método de bean asíncrono es libre de iniciar su propia transacción global, si es posible para el componente Java EE que realiza la llamada. Por ejemplo, si un enterprise bean crea el componente, el método que crea el bean asíncrono debe ser TX_BEAN_MANAGED.

Cuando llama a un bean de entidad desde un bean asíncrono, por ejemplo, debe tener un contexto de transacción global en la hebra actual. Debido a que los objetos de bean asíncronos inician contextos de transacción local, puede encapsular toda la lógica del bean de entidad en un bean de sesión que tenga un método marcado como TX_REQUIRES o un valor equivalente. Este proceso establece un contexto de transacción global desde el que puede acceder a uno o más métodos de bean de entidad.

Si el método de bean asíncrono genera una excepción, las transacciones locales se retrotraen. Si el método se devuelve con normalidad, todas las transacciones locales incompletas se completarán de acuerdo con la política de acciones no resueltas configurada para el bean. Los métodos de EJB pueden configurar esta política utilizando su descriptor de despliegue. Si el método de bean asíncrono inicia su propia transacción global y no compromete esta transacción global, la transacción se retrotrae cuando se devuelve el método.

Acceso a metadatos del componente Java EE

Si un bean asíncrono es un componente Java EE, por ejemplo, un bean de sesión, sus propios metadatos se activan cuando se llama a un método. Si un bean asíncrono es un simple objeto Java, los metadatos del componente Java EE del componente creador están disponibles para el bean. Como su creador, el bean asíncrono puede realizar búsquedas en el espacio de nombres java:comp. Esta búsqueda permite al bean acceder a las fábricas de conexiones y a los enterprise beans, del mismo modo en que lo haría cualquier otro componente Java EE. Las propiedades de entorno del componente creador también están disponibles para el bean asíncrono.

El espacio de nombres java:comp es idéntico al que hay disponible para el componente creador y se aplican las mismas restricciones. Por ejemplo, si el enterprise bean o servlet tiene una referencia a EJB igual a java:comp/env/ejb/MyEJB, esta referencia a EJB estará disponible en el bean asíncrono. Asimismo, todas las fábricas de conexiones utilizan el mismo ámbito de compartimiento de recursos que el componente creador.

Gestión de conexiones

Un método de bean asíncrono puede utilizar las conexiones que ha obtenido el componente Java EE creador utilizando las referencias de recurso java:comp. (Para obtener más información sobre referencias de recursos, consulte el tema Referencias). No obstante, el método de bean debe acceder a esas conexiones utilizando un patrón get, use o close. Las conexiones no se guardan en memoria caché entre llamadas de método en un bean asíncrono. Las fábricas de conexiones o los datasources se pueden guardar en la memoria caché, pero las conexiones se deben recuperar, utilizar y cerrar finalmente cada vez que se llama al método. Aunque el método de bean asíncrono puede buscar fábricas de conexiones utilizando un nombre JNDI (Java Naming and Directory Interface) global, no se recomienda por los siguientes motivos:

  • El nombre JNDI está codificado en la aplicación (por ejemplo, como propiedad o literal de serie).
  • Las fábricas de conexiones no se comparten ya que no se puede especificar un ámbito de compartimiento.

Si desea ver ejemplos de código que muestren las formas correctas e incorrectas de acceder a conexiones desde métodos bean asíncronos, consulte el tema Ejemplo: gestión de conexiones de beans asíncronos.

Inicio diferido de los beans asíncronos

Es posible iniciar de forma diferida los beans asíncronos serializando la información del contexto de servicio Java EE. El método WorkWithExecutionContext createWorkWithExecutionContext(Work r) de la interfaz del gestor de trabajo creará una instantánea de los contextos de servicio Java EE habilitados en el gestor de trabajo. A continuación, se puede serializar el objeto WorkWithExecutionContext resultante y guardarlo en una base de datos o en un archivo. Esto es útil cuando es necesario almacenar contextos de servicio Java EE, tales como la identidad de seguridad actual o el entorno local y, posteriormente, inflarlos y ejecutar algún trabajo en este contexto. El objeto WorkWithExecutionContext se puede ejecutar utilizando los métodos startWork() y doWork() en la interfaz del gestor de trabajo.

Todos los objetos WorkWithExecutionContext los debe deserializar la misma aplicación que los ha serializado. Todos los EJB y las clases deben estar presentes para que Java pueda expandir correctamente los objetos que contienen.

Inicio diferido y seguridad

Es posible que el contexto del servicio de seguridad de los beans asíncronos requiera que esté habilitada la aserción de identidad de CSIv2 (Secure Interoperability Versión 2). La afirmación de identidad es necesaria cuando un objeto WorkWithExecutionContext se deserializa y se ejecuta en la asignación de credencial de identidad de asunto de JAAS (Java Authentication and Authorization Service). Consulte los temas siguientes para comprender mejor si necesita habilitar la aserción de identidad cuando se utiliza un objeto WorkWithExecutionContext:
  • Configuración del protocolo de autenticación Common Secure Interoperability Versión 2 y Security Authentication Service
  • Aserción de identidad

Hay otros aspectos relacionados con la interoperatividad de los objetos WorkWithExecutionContext con las diferentes versiones del producto. Consulte el tema Interoperatividad con beans asíncronos.

Limitaciones relacionadas con JPA

El uso de beans asíncronos en un contexto de persistencia ampliada JPA no está soportado.

Un contexto de persistencia ampliada JPA no es coherente con las posibilidades de planificación y multihebra de los beans asíncronos, y no será accesible desde una hebra de beans asíncronos.

De la misma forma, no debe crearse un bean asíncrono que tome javax.persistence.EntityManager (o una subclase) como parámetro, ya que las instancias EntityManager no están diseñadas para ser de hebra segura.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=casb_asbover
File name: casb_asbover.html