Sistema de Nombrado en Java (JNDI) y II

Una aplicaci�n JNDI usa la propiedad de entorno Context.REFERRAL ("java.naming.referral") para indicar al proveedor de servicio c�mo manejar las remisiones. La siguiente tabla muestra los valores definidos para esta propiedad. Si no se configura, el valor por defecto es ignorar las remisiones.

Configuraci�n Descripci�n
ignore Ignora las remisiones
follow Sigue autom�ticamente las remisiones
throw Lanza una ReferralException por cada remision

Al contrario que los alias, que son siempre ignorados por operaciones LDAP que actualizan el directorio, la propiedad Context.REFERRAL afecta a todas las operaciones. Puedes ver una explicaci�n sobre c�mo actualizar remisiones en la lecci�n Crear y Actualizar Remisiones.

Esta referencia afecta tanto a las "referral" de respuestas de error como a las referencias de continuaci�n.

.�Interacci�n con el Control Manage Referral

El control Manage Referral (draft-ietf-ldapext-namedref-00.txt) le dice al servidor LDAP que devuelva las entradas de remisi�n como entradas ordinarias (en lugar de devolver "referral" de respuestas de error o referencias de continuaci�n). Si estamos usando el LDAP v3 y hemos configurado Context.REFERRAL como "ignore", el proveedor de servicio lDAP enviar� autom�ticamente este control junto con la solicitud. Si estamos usando el LDAP v2, el control no se enviar� porque no es aplicable en este protocolo. Cuando configuramos Context.REFERRAL a cualquier otro valor, el control no ser� env�ado sin importar la versi�n de protocolo. Cuando se actualizan entradas de remisi�n, siempre deber�amos suar "ignore".

Cuando el proveedor de servicio recibe una remisi�n sin importar que Context.REFERRAL est� seleccionado como "ignore", lanzar� una PartialResultException para indicar que se podr�an obtener m�s resultados si se siguiera la remisi�n. En este caso, el servidor no soporta el control Manage Referral y soporta las remisiones actualizadas de alguna otra forma.

.�Cu�ndo se Procesan las Remisiones

Las referencias de continuaci�n pueden mezclarse con resultados de b�squedas devueltos por una operaci�n "search" LDAP. Por ejemplo, cuando se busca un directorio, el servidor podr�a devolver varios resultados, adem�s de unas pocas referencias de continuaci�n que muestran donde obtener m�s resultados. Estos resultados y referencias podr�an estar mezclados a nivel de protocolo. Cuando la propiedad Context.REFERRAL se configura como "follow", el proveedor de servicio LDAP primero procesa todas las entradas normales, antes de seguir la referencias de continuaci�n. Cuando esta propiedad se configura como "throw", primero se devuelven en la enumeraci�n todas las entradas normales, antes de lanzar la ReferralException.

Por el contrario, una respuesta de error "referral" es procesada inmediatamente cuando Context.REFERRAL se configura como "follow" o como "throw".

.�Configuraci�n del Servidor para los Ejemplos

Los ejemplos de esta secci�n se comunican con un nuevo servidor cuyo directorio contiene remisiones al servidor original de este tutorial. Se asume que el servidor original se est� ejecutado en el puerto 389 de la m�quina local, y el nuevo servidor en el puerto 489 de la misma m�quina.

Se han configurado estas tres remisones desde el nuevo servidor (puerto 489) hasta el servidor original (puerto 389).

  • La entrada "ou=People, o=JNDITutorial" en el nuevo servidor es una remisi�n a la entrada con el mismo nombre en el servidor original.
  • La entrada "ou=People, ou=All, o=JNDITutorial" en el nuevo servidor es una remisi�n a la entrada "ou=People, o=JNDITutorial" en el servidor original.
  • La entrada "ou=NewHires, ou=All, o=JNDITutorial" es una remisi�n de la entrada "ou=NewHires, o=JNDITutorial" en el servidor original.

El contexto inicial usado en los ejemplos de esta lecci�n se inicializa usando las siguientes propiedades de entorno:

// Set up the environment for creating the initial context
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, 
    "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:489/o=JNDITutorial");

Al contrario que el resto de los ejemplos de este tutorial, el n�mero de puerto es 489 en lugar de 389.

Antes de continuar:

Los ejemplos de esta lecci�n requieren que configuremos un segundo servidor usando el fichero de configuraci�n refserver.ldif. El servidor debe soportar LDAP v3 y draft-ietf-ldapext-namedref-00.txt. Si el servidor no soporta remisiones de esta forma, estos ejemplos no funcionar�n como se muestra. El fichero de configuraci�n contiene remisiones que apuntan al servidor original que ya hemos configurado (usando tutorial.ldif y ldaptrail.ldif). Asume que el servidor est� en el puerto 389 de la m�quina local. Si hemos configurado el servidor sobre otra m�quina u otro puerto, entonces necesitamos editar las entrada "ref" del fichero refserver.ldif y reemplazar "localhost:389" con la configuraci�n apropiada. El segundo servidor est� configurado en el puerto 489 de la m�quina local. Si configuramos el segundo servidor en otra m�quina o en otro puerto, necesitamos ajustar adecuadamente las configuraciones de la propiedad de entorno Context.PROVIDER_URL.

La configuraci�nde un servidor de directorio normalmente la realiza el administrador del sistema o del directorio. Puedes encontrar m�s informaci�n en la lecci�n Preparaciones .

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR