En sistemas distribuidos se utiliza para abstraer
la utilización de JNDI y ocultar las complejidades asociadas a la creación del
contexto, búsquedas de objetos y creación de objetos tipo EJB.
Consiste en utilizar un objeto Service Locutor para
abstraer toda la utilización JNDI y para ocultar las complejidades de la
creación del contexto inicial, de búsqueda de objetos home EJB y recreación de
objetos EJB. Varios clientes pueden reutilizar el objeto Service Locutor para
reducir la complejidad del código, proporcionando un punto de control.
·
Contexto
La
búsqueda y creación de servicios implican interfaces complejos y operaciones de
red.
·
Problema
Los clientes interactúan con componentes de
servicio, que proporcionan servicios de negocio y capacidades de persistencia.
Para interactuar con estos componentes, los clientes deben localizar el componente
de servicio (referido como una operación de búsqueda) o crear un nuevo
componente.
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.
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.
La
búsqueda y creación de Beans Enterprise trata sobre lo siguiente:
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.
Entonces el servicio JNDI puede proporcionar al
cliente un contexto inicial que actúa como un almacén 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.
Encontrar
el objeto EJBHome utilizando el contexto de búsqueda inicial
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..
·
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, pueden 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 previamente,
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 objetos home EJB y de re-creación de objetos
EJB. Varios clientes pueden reutilizar el objeto Service Locator para reducir
la complejidad del código, proporcionando un punto de control, y mejorando el
rendimiento proporcionando facilidades de caché.
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.
·
Estructura (diagrama
de clases)
·
Diagrama de secuencias
-
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.
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 objetos context, 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).
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 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 vean} enterprise. El objetoBusinessService en el contexto de una aplicación JMS
puede ser un TopicConnection o
un QueueConnection. TopicConnection y QueueConnection se
pueden entonces utilizar para producir un objeto JMSSession,
como un TopicSession o
un QueueSession
No hay comentarios:
Publicar un comentario