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.