java-ee
Arquitectura del conector de Java (JCA)
Buscar..
Observaciones
Aclaremos algunas terminologías primero:
- La mensajería de salida es donde el mensaje comienza desde el servidor (para ser más precisos, se inicia desde la aplicación que tiene en el servidor,
WebSphere Libertyen este caso) y finaliza en el EIS. - La mensajería entrante es donde el mensaje comienza desde el EIS y finaliza en el servidor.
- Punto final del mensaje en general, el lugar donde el mensaje termina sentado / recibiendo en una etapa específica de su ciclo de vida.
Así que con la conectividad de salida, nos referimos a la situación en la que una aplicación obtiene una conexión a un EIS externo y le lee o escribe datos. Con la conectividad de entrada, nos referimos a la situación en la que el Adaptador de recursos (RA) escucha los eventos del EIS externo y llama a su aplicación cuando ocurre tal evento.
Ilustración de un RA saliente
Ilustración de un RA entrante
¿Qué es un medio MessageEndPoint en JCA?
El servidor de aplicaciones (por ejemplo, WebSphere Liberty ) proporciona MBeans de punto final de mensaje para ayudarlo a administrar la entrega de un mensaje a sus beans controlados por mensajes que actúan como escuchas en puntos finales específicos, que son destinos, y en la administración de los recursos EIS que son Utilizado por estos frijoles impulsados por mensajes. Los beans controlados por mensajes que se implementan como puntos finales de mensajes no son lo mismo que los beans controlados por mensajes que se configuran en un puerto de escucha. Los beans controlados por mensajes que se utilizan como puntos finales de mensajes deben implementarse utilizando una ActivationSpecification que se define dentro de una configuración RA para JCA (Se encuentra en el archivo ra.xml ).
¿Qué significa activar un MessageEndPoint?
Con los MBeans de punto final de mensajes, puede activar y desactivar puntos finales específicos dentro de sus aplicaciones para asegurarse de que los mensajes se envíen solo a los frentes controlados por mensajes que interactúan con recursos de EIS en buen estado. Esta capacidad le permite optimizar el rendimiento de sus aplicaciones JMS en situaciones donde un recurso EIS no se comporta como se espera. La entrega de mensajes a un punto final generalmente falla cuando el bean controlado por mensajes que está escuchando invoca una operación contra un recurso que no está en buen estado. Por ejemplo, un proveedor de mensajería, que es un adaptador de recursos de entrada que cumple con JCA, puede fallar en la entrega de mensajes a un punto final cuando su bean subyacente impulsado por mensajes intenta confirmar transacciones contra un servidor de base de datos que no responde.
¿MessageEndPoint necesita ser un bean?
Debería. De lo contrario, terminará en un gran lío al crear su propia forma poco convencional de hacer cosas que cumplen con el propósito de seguir las especificaciones de Java EE en primer lugar. Diseñe sus beans controlados por mensajes para delegar el procesamiento empresarial a otros beans empresariales. No acceda a los recursos EIS directamente en el bean controlado por mensajes, sino hágalo indirectamente a través de un bean delegado.
¿Puede mostrar algún ejemplo simple sobre cómo trabajar / implementar un MessageEndPoint?
Revise el segundo recurso que menciono a continuación para un ejemplo útil.
Recursos de aprendizaje útiles:
Ejemplo de adaptador de recursos
class MyResourceAdapter
implements javax.resource.spi.ResourceAdapter {
public void start(BootstrapContext ctx){..}
public void stop(){..}
public void endpointActivation (MessageEndpoingFactory mf, ActivationSpec a){..}
public void endpointDeactivation (MessageEndpoingFactory mf, ActivationSpec a){..}
public void getXAResources(ActivationSpec[] activationSpecs){..}
}