Service Activator

A continuación se ofrece la descripción del patrón

Contexto

Los beans enterprise y otros servicios de negocio necesitan una forma de activarse asíncronamente.

Problema

Cuando un cliente necesita acceder a un bean enteprise, primero busca el objeto home del bean. Luego el cliente le pide a ese objeto home que le proporcione una referencia remota al bean enterprise requerido. Entonces el cliente invoca a los métodos de negocio sobre la referencia remota para acceder a los servicios del bean enterprise. Estas llamadas a métodos, así como las búsquedas y las llamadas a métodos remotos, son síncronos. El cliente tiene que esperar hasta que esos metodos retornan.

Otro factor a considerar es el ciclo de vida de un bean enterprise. La especificación EJB permite que el contenedor pasivice un bean enterprise a un almacenamiento intermedio. Como resultado, el contenedor EJB no tiene un mecanismo mediante el cual poder proporcionar un servicio estilo-proceso para mantener un bean enterprise constantemente activado y en estado listo. Como el cliente debe interactuar con el bean enterprise utilizando su interface remoto, incluso si el bean está en estado activado en el contenedor, el cliente aun necesita obtener su interface remoto mediante un proceso de búsqueda y todavía actúa con el bean de forma síncrona.

Si una aplicación necesita procesamiento síncrono para sus componentes de negocio del lado del servidor, entonces los beans enterprise son una opción apropiada. Algunas aplicaciones cliente podrían requerir este tipo de procesamiento porque los clientes no necesitan esperar o no tienen tiempo para esperar a que se complete el procesamiento. En caso donde la aplicación necesita una forma de procesamiento asíncrono, los beans enterpise no ofrecen esta capacidad en implementaciones anteriores a la especificación EJB 2.0.

La especificación EJB 2.0 proporciona integración introduciendo el bean dirigido-a-mensaje, que es un tipo especial de bean de sesión sin estado que ofrece capacidades de invocación asíncrona. Sin embargo, la nueva especificación no ofrece invocación asíncrona para otros tipos de beans enterprise, como los beans con estado o de entidad.

En general, un servicio de negocio como un bean de sesión o de entidad sólo proporciona procesamiento síncrono y esto representa un reto para implemenetar procesamiento asíncrono.

Solución

Utilizar un Service Activator para recibir peticiones y mensajes asíncronos de los clientes. Cuando se recibe un mensaje, el Service Activator localiza e invoca a los métodos de de los componentes de negocio necesarios para cumplir la petición de forma asíncrona.

El Service Activator es un oyente JMS y un servicio de delegación que requiere la implementación de un oyente de mensajes JMS. Se puede implementar como un servicio independiente. Los clientes actúan como generadores de mensajes, generando eventos basándose en su actividad.

Cualquier cliente que necesite invocar asíncronamente un servicio de negocio, como un bean enteprise, podría crear y enviar un mensaje al Service Activator. Éste recibe el mensaje y lo analiza para interpretar la petición del cliente. Una vez que se ha analizado y desempaquetado la petición del cliente, el Service Activator identifica y localiza los componentes de servicio de negocio necesarios e invoca a sus métodos de negocio para completar el procesamiento de la petición del cliente de forma asíncrona.

Service Activator opcionalmente podría enviar un reconocimiento al cliente después de que haya completado el procesamiento de la petición. También podría notificar al cliente o a otros servicios si ocurre un fallo durante el procesamiento de la petición. El Service Activator podría utilizar los servicios de un Service Locator.

Implementación y Participantes

A continuación se muestra el diagrama de secuencia del patrón

• Cliente. El cliente solicita una facilidad de procesamiento asíncrono de los objetos de negocio que participan en un flujo de trabajo. El cliente puede ser cualquier tipo de aplicación que tenga la capacidad de crear y enviar mensajes JMS. El cliente también puede ser un componente EJB que necesite invocar los métodos de negocio de otro componente EJB de forma asíncrona. El cliente puede utilizar los servicios ofrecidos por el patrón Service Locator para buscar o crear componentes EJB, servicios JMS, u objetos JMS, según necesite.
• Peticion. Peticion es el objeto message creado por el cliente y enviado al ServiceActivator mediante MOM. De acuerdo a la especificación JMS, Petición(Request) es un objeto que implementa el interface javax.jms.Message. El API JMS proporciona varios tipos de mesnajes, como TextMessage, ObjectMessage, etc.
• ServiceActivator. ServiceActivator es la clase principal del patrón. Implementa el interface javax.jms.MessageListener, definido por la especificación JMS. ServiceActivator implementa un método onMessage() que se invoca cuando llega un nuevo mensaje. ServiceActivator analiza el mensaje (la petición) para determinar qué debe hacer. El ServiceActivator podría utilizar los servicios de un patrón Service Locator para buscar o crear los componentes de servicio de negocio que necesita.
• BusinessObject. BusinessObject es el objeto destino al que el cliente necesita acceder de forma asíncrona. El objeto de negocio es un rol que pueden cumplir los beans de sesión o de entidad. También es posible que el BusinessObject sea un servicio externo en vez de un bean de entidad.