 |
Añadir una dirección | Buscador | Cursos | Artículos | Foros | Formación |
 |
 |
Sistema de Nombrado en Java (JNDI) [Parte I] |
|
En esta página:
Interacciones entre Factorías de Estado y Proveedores de Servicio
Un proveedor de servicio actúa entre la aplicación y el directorio cuando la aplicación almacena o recupera objetos Java desde el directorio. Cuando escribimos un proveedor de servicios, necesitamos realizar este papel de ir-entre, siguiendo las reglas descritas en esta página para almacenar objetos en el directorio.
La siguiente descripción detallada está pensada para desarrolladores que escriban proveedores de servicio. Aunque también podría ser útil para los usuarios del API.
Métodos Relevantes
Cuando se aceptan objetos para unirlos dentro del servicio de nombres/directorio subyacente, el proveedor de servicio debería usar las guías descritas en esta página. Un objeto peude unirse usando uno de los siguientes métodos.
Conjunto Mínimo de Tipos Aceptables
Un proveedor de servicio deberia intentar soportar uniones y re-uniones de objetos que son o hacen alguna de las siguientes cosas.
- Ejemplares de Reference
- Implementan el interface Referenceable
- Implementan el interface java.io.Serializable
- Implementan el inteface DirContext
Debería chequear si un objeto pertence a una de estas cuatro categorías en el orden listado porque este orden es el orden pensado para el cliente. Por ejemplo, una Reference es Serializable, por eso si realizamos primero el chequeo Serializable, ningún objeto Reference será nunca almacenado en el formato referencia (todos serian serializados).
Soporte de Marco de Trabajo
Un proveedor de servicio debería usar factorías de estado configuradas con el proveedor y la aplicación. Esto permite personalizar el proveedor de servicio para soportar tipos de objeto arbitrarios (para los que haya disponible una factoría de estado).
El marco de trabajo JNDI proporciona métodos últiles que el proveedor de servicio puede utilizar para acceder a las factorías de estado. Un proveedor de servicio que sólo implemente el interface Context debería usar NamingManager.getStateToBind().
Un proveedor de servicio que implemente el interface DirContext debería usar DirectoryManager.getStateToBind().
Estos métodos atraviesa la lista de factorías de estado especificada en la propiedad de entorno Context.STATE_FACTORIES y el fichero de recursos de proveedor e intenta encontrar una factoría que devuelva una respuesta no-null.
Aquí tenemos un ejemplo de cómo una implementación de DirContext podría usar factorías de estado.
// First, use state factories to do a transformation
DirStateFactory.Result res = DirectoryManager.getStateToBind(
obj, name, ctx, env, inAttrs);
obj = res.getObject();
Attributes outAttrs = res.getAttributes();
// Check for Referenceable
if (obj instanceof Referenceable) {
obj = ((Referenceable)obj).getReference();
}
// Store different formats
if (obj instanceof Reference) {
// Store as ref and add outAttrs
} else if (obj instanceof Serializable) {
// Serialize and add outAttrs
} else if (obj instanceof DirContext) {
// Grab attributes and merge with outAttrs
} else {
...
}
Cuando el proveedor obtiene un objeto (obj) y unos atributos (inAttrs) del cliente para unirlos a un directorio, llama a getStateToBind() para obtener una pareja actualizada de objeto/atributos. Si ninguna factoría de estado devuelve una respuesta non-null, entonces getStateToBind() devuelve la pareja de original de objeto y atributos. En cualquier caso, el proveedor almacena el resultado en el directorio subyacente en un formato aceptable por éste.
|
|
|
| Principio Página |
|
© 1999-2002, Programación en castellano, s.l. Contacto - Datos legales ReD Internet: Hospedaje Web | envio sms gratis | Salvapantallas | Fondos de Escritorio, famosas | melodias moviles gratis| Gratis |