java-ee - @tag java
¿Cuál es la diferencia entre ActivationSpec y ConnectionFactory? (3)
@Jeffrey Knight: Déjame intentar aclarar sobre la base de mi experiencia.
Entendemos que los MDB son beans para consumir mensajes entrantes. Ahora es necesario especificar qué tipo de mensajes, desde qué destino quiere consumir un MDB en particular.
MDB es básicamente un punto final del mensaje.
Antes de los MDB compatibles con JCA:
El flujo en websphere era:
mensaje entrante -> escuchado por escucha de mensajes -> puertos de escucha -> entregar a MDB
Por lo general, un desarrollador creará un MDB y especificará los detalles del destino del mensaje en ejb-jar.xml de la siguiente manera:
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
<res-ref-name>jms/QCF</res-ref-name>
<resource-ref>
<res-type>javax.jms.QueueConnectionFactory</res-type>
<res-auth>Container</res-auth>
</resource-ref>
y un implementador necesitaría crear un puerto de escucha y asociar el MDB implementado al puerto de escucha. QueueConnectionFactory especificado anteriormente se hace para crear conexiones a la cola.
Post JCA compatibles MDBs:
Post JCA, MDB se trata como un recurso JCA. La especificación JCA incorporó también las API del marco de mensajería. Flujo en caso de JCA es: -
incoming message --> listened by Message listener --> Resource Adapter-->deliver to MDB
Ahora, desde que JCA se creó para trabajar con cualquier tipo de recurso, ya sea JDBC, JMS, EIS, etc., tiene una forma genérica de "Especificación de activación" para crear configuraciones para cualquier adaptador. En el archivo ra.xml, se menciona qué tipo de especificación de activación necesita ese adaptador en particular para funcionar. La especificación de activación no es una entidad de tiempo de ejecución, es solo una información de configuración utilizada por el adaptador de recursos. En el caso anterior, el adaptador JCA usará la conexión de la fábrica de conexiones de cola mencionada en las especificaciones de activación. Así que básicamente la fábrica de conexiones de cola en ambos casos anteriores son iguales.
En el caso de websphere, puede utilizar destinos SIB (Bus de integración de servicios) para mensajería O software externo como websphere MQ para mensajería.
En el caso de destinos SIB para mensajería : - SIB ha implementado un adaptador de recursos JCA. Por lo tanto, el MDB que usa el destino en SIB puede usar la especificación de activación para especificar los detalles del destino. y el módulo adaptador de recursos puede interactuar con el motor de mensajería y entregar los mensajes a MDB.
En el caso de un marco de mensajería externo como websphere MQ : - Dado que websphere MQ no ha implementado ningún adaptador JCA, debemos configurar el puerto de escucha para conectarse a los destinos que residen en websphere MQ. Es el puerto de escucha quien entregará los mensajes a MDB.
En resumen, ambos casos utilizan la fábrica de conexiones de cola para obtener la conexión de cola. En un caso, es un adaptador de recursos (con información de configuración en forma de especificación de activación) que se utiliza para entregar mensajes, mientras que en otro caso es el puerto de escucha (vinculado a la cola y la fábrica) que se utiliza para entregar mensajes.
Espero que esto se aclare ahora.
Mi entendimiento es que:
- MD B s (Message Driven Beans) se conecta a través de la Especificación de Activación.
- MD P s (Message Driven POJO) se conecta a través de Connection Factory.
Este diagrama de IBM es útil:
Para mí, esta explicación de IBM no arroja mucha luz sobre la diferencia:
- Conexión de fábrica : utilizada por la aplicación para obtener conexiones al bus de mensajería.
- Cola : utilizada por la aplicación para enviar y recibir mensajes.
- Especificación de activación : utilizada por el bean controlado por mensajes de la aplicación para conectarse a la cola y recibir mensajes.
Una diferencia real que he encontrado es que :
Los beans de sesión y los beans de entidad [aka MDP] le permiten enviar mensajes JMS y recibirlos de forma síncrona, pero no asíncrona . Para evitar atar los recursos del servidor, es posible que prefiera no usar el bloqueo de recepciones síncronas en un componente del lado del servidor. Para recibir mensajes de forma asíncrona, use un bean controlado por mensaje [MDB].
Así que la lista insatisfactoria que tengo hasta ahora es:
- Use ActivationSpec con un MDB y ConnectionFactory con un POJO (pero espere, ¿los POJO pueden usar ActivationSpec también ?)
- Los MDB operan de forma asíncrona. Los MBP funcionan sincrónicamente.
Mi pregunta es: ¿Hay otras diferencias? ¿Puedes aclarar la diferencia?
Referencias:
Ambas son configuraciones, pero la fábrica de conexiones se usa para mensajes salientes y las especificaciones de activación se usan para mensajes entrantes.
Esto es lo que tengo de IBM.
Las especificaciones de activación son parte de la especificación JCA 1.5. La aplicación MDB utiliza la especificación de activación para conectarse a un administrador de colas de WebSphere MQ para el procesamiento de los mensajes entrantes. La especificación de activación también proporciona otras opciones, como la configuración de seguridad.
Una fábrica de conexiones JMS contiene información sobre cómo crear una conexión. Cuando una aplicación necesita una conexión JMS, la fábrica crea una instancia de conexión. La fábrica de conexiones requiere la misma información de conexión que la especificación de activación que creó anteriormente, pero se usa para los mensajes salientes de la MDB, mientras que la especificación de activación se usa para los mensajes entrantes.
El cliente de un ConnectionFactory es la aplicación. La aplicación utiliza ConnectionFactory para enviar / extraer mensajes hacia / desde el motor de mensajería a través de una cola.
El cliente de una ActivationSpec es el contenedor EJB. El contenedor EJB obtiene una ActivationSpec para registrar un MessageEndpointFactory para el MDB o MDP con un ResourceAdapter. Cuando un cliente envía un mensaje al motor de mensajería, el motor de mensajería usará el MessageEndpointFactory registrado para reenviar el mensaje a la aplicación (por ejemplo, el MDB o MDP). Esto permite que la aplicación reciba mensajes "de forma asíncrona" en lugar de requerir que el cliente haga una encuesta o bloquee al intentar extraer un mensaje de la cola.