SERVICE LOCATOR

Este patrón reduce la complejidad del cliente que resulta de las dependencias del cliente y de la necesidad de realizar los procesos de búsqueda y creación, que consumen muchos recursos. Para eliminar estos problemas, este patrón proporciona un mecanismo para abstraer todas las dependencias y detalles de red dentro del Service Locator.

CONTEXTO

La búsqueda y creación de servicios implican interfaces complejos y operaciones de red.

PROBLEMA

Los clientes J2EE interactúan con componentes de servicio, como componentes JavaBeans Enterprise (EJB) y Java Message Service (JMS), que proporcionan servicios de negocio y capacidades de persistencia. Para interactúar con estos componentes, los clientes deben o lcalizar el componente de servicio (referido como una operación de búsqueda) o crear un nuevo componente. Por ejemplo, un cliente EJB debe localizar el objeto home del bean enterprise, que el cliente puede utilizar para encontrar un objeto o para crear uno o más beans enterprise. De forma similar, un cliente JMS primero debe localizar la Factoría de Conexiones JMS para obtener una Conexión JMS o una Sesión JMS.

Todos los clientes de aplicaciones J2EE utilizan la facilidad JNDI para buscar y crear componentes EJB o JMS. El API JNDI permite a los clientes obtener un objeto Contexto Inicial que contiene el nombre del componente a uniones de objetos. El cliente empieza obteniendo el contexto inicial para un objeto home de un bean. El contexto inicial permanece válido mientras sea válida la sesión del cliente. El cliente proporciona el nombre registrado en JNDI del objeto requerido para obtener una referencia a un objeto administrado. En el contexto de una aplicación EJB, un objeto administrado típico es un objeto home de un bean enterprise. Por eso, localizar un objeto servicio administrado JNDI es un tarea común para todos los clientes que necesiten acceder al objeto de servicio. Por ejemplo, es fácil ver que muchos tipos de clientes utilizan repetidamente el servicio JNDI, y que el código JNDI aparece varias veces en esos clientes. Esto resulta en una duplicación de código innecesaria en los clientes que necesitan buscar servicios.

También, crear un objeto de contexto JNDI inicial y realizar una búsqueda para objeto home EJB utiliza muchos recursos. Si varios clientes requieren de forma repetitiva el mismo objeto home de un bean, dicha duplicación de esfuerzos puede impactar de forma negativa en el rendimiento de la aplicación.

Examinemos el proceso de búsqueda y creación de varios componentes J2EE.

1.    La búsqueda y creación de Beans Enterprise trata sobre lo siguiente:

o    Una correcta configuración del entorno JNDI para que se conecte con el servicio de nombrado y directorio utilizado por la aplicación. Esta configuración proporciona la localización del servicio de nombrado y las credenciales de autentificaciones necesarias para acceder a ese servicio.

o    Entonces el servicio JNDI puede proporcionar al cliente un contexto inicial que actúa como un almacen para las uniones de componentes nombre-a-objeto. El cliente solicita a este contexto inicial que busque el objeto EJBHome del bean enterprise requerido proporcionando un nombre JNDI para ese objeto EJBHome.

o    Encontrar el objeto EJBHome utilizando el contexto de búsqueda inicial

o    Después de obtener el objeto EJBHome, crea, elimina o encuentra el bean enterprise utilizando los métodos create, move o find (solo para beans de entidad) del objeto EJBHome.

2.    La búsqueda y creación de componentes JMS (Topic, Queue, QueueConnection, QueueSession, TopicConnection, TopicSession, etc.) implica los siguientes pasos. Observa que en estos pasos, Topic se refiere al modelo de mensajería publica/subscribe y queQueue se refiere al modelo de mensajería punto-a-punto.

o    Una correcta configuración del entorno JNDI para que se conecte con el servicio de nombrado y directorio utilizado por la aplicación. Esta configuración proporciona la localización del servicio de nombrado y las credenciales de autentificaciones necesarias para acceder a ese servicio.

o    Obtener el contexto inicial para el proveedor de servicio JMS desde el servicio de nombrado JNDI.

o    Utilizar el contexto inicial para obtener un Topic o un Queue suministrando el nombre JNDI para ese Topic o Queue. Ambos son objetos JMSDestination.

o    Utilizar el contexto inicial para obtener un TopicConnectionFactory o unQueueConnectionFactory suministrando el nombre JNDI para la factoría adecuada.

o    Usar el TopicConnectionFactory para obtener un TopicConnection o elQueueConnectionFactory para obtener un QueueConnection.

o    Utilizar el TopicConnection para obtener un TopicSession o elQueueConnection para obtener un QueueSession.

o    Utilizar el TopicSession para obtener un TopicSubscriber o unTopicPublisher para el Topic Requerido. Utilizar el QueueSession para obtener un QueueReceiver o un QueueSender para el Queue requerido.

El proceso de búsqueda y creación de componentes implica una implementación de una factoria de contextos suministrada por un vendedor. Esto introduce dependencias del vendedor en los clientes de la aplicación que necesitan utilizar la facilidad de búsqueda JNDI para localizar beans enterprise y componentes JMS.

 

 

CAUSAS

·         Los clientes EJB necesitan utilizar el API JNDI para buscar objetos EJBHome utilizando el nombre registrado del bean enterprise.

·         Los clientes JMS necesitan utilizar el API JNDI para buscar componentes JMS utilizando los nombres registrados en JDNI para esos componentes JMS.

·         La factoría de contextos utilizada para la creación del contexto inicial JNDI la proporciona el vendedor del proveedor del servicio y por lo tanto es dependiente del vendedor. La factoría de contexto también es dependiente del tipo de objeto que se está buscando. El contexto para una JMS es diferente que el contexto para EJBs, con diferentes proveedores.

·         La búsqueda y creación de componentes de servicio podría ser compleja y se podría utilizar repetidamente en múltiples clientes en la aplicación.

·         La creación del contexto inicial y el servicio de búsqueda de objetos, si se utiliza frecuentemente, puede consumir muchos recursos e impactar en el rendimiento de la aplicación. Esto es especialmente cierto si los clientes y los servicios están localizados en diferentes capas.

·         Los clientes EJB podrían necesitar reestablecer conexiones a un ejemplar de bean enterprise al que se ha accedido préviamente, teniendo solamente su objeto Handle.

·          

SOLUCIÓN

Utilizar un objeto Service Locator para abstraer toda la utilización JNDI y para ocultar las complejidades de la creación del contexto inicial, de busqueda de objetoshome EJB y de re-creación de objetos EJB. Varios clientes pueden reutilizar el objetoService Locator para reducir la complejidad del código, proporcionando un punto de control, y mejorando el rendimiento proporcionando facilidades de caché.

ESTRUCTURA

muestra el diagrama de clases que representa las relaciones para el patrónService Locator.

 PARTICIPANTES Y RESPONSABILIDADES

La siguiente figura contiene el diagrama de secuencia que muestra la interacción entre los distintos participantes en el patrón Service Locator

Client

Este es el cliente del Service Locator. El cliente es un objeto que normalmente requiere acceder a objetos de negocio como un Business Delegate.

El Service Locator abstrae el API de los servicios de búsqueda (nombrado), las dependencias del vendedor, las complejidades de la búsqueda, y la creación de objetos de negocio, y proporciona un interface simple para los clientes. Esto reduce la complejidad del cliente. Además, el mismo cliente y otros clientes pueden reutilizar el Service Locator.

 InitialContext

El objeto InitialContext es el punto de inicio para los procesos de búsqueda y creación. Los proveedores de servicio proporcionan el objeto context, que varía dependiendeo del tipo de objetos de negocio proporcionados por el servicio de búsqueda y creación del Service Locator. Un Service Locator que proporciona los servicios para varios tipos de objetos de negocio (como beans enterprise, componentes JMS, etc.) utiliza varios tipos de objetoscontext, cada uno obtenido de un proveedor diferente (por ejemplo, el proveedor de contexto para un servidor de aplicaciones EJB podría ser diferente del proveedor de contexto para un servicio JMS).

 ServiceFactory

El objeto ServiceFactory representa un objeto que proporciona control del ciclo de vida para objetos BusinessService. El objeto ServiceFactory para beans enterprise es un objetoEJBHome. El ServiceFactory para componentes JMS puede ser un objetoConnectionFactory, como un TopicConnectionFactory o un QueueConnectionFactory.

BusinessService

BusinessService es un rol que cumple el servicio que el cliente ha solicitado. El objetoBusinessService se crea, se busca o se elimina mediante el objeto ServiceFactory. El objeto BusinessService en el contexto de una aplicación EJB es un bean enterprise. El objeto BusinessService en el contexto de una aplicación JMS puede ser unTopicConnection o un QueueConnection. TopicConnection y QueueConnection se pueden entonces utilizar para producir un objeto JMSSession, como un TopicSession o unQueueSession respectivamente.