Sistema de Nombrado en Java (JNDI) y II

Un proveerdor de servicio normalmente s�lo soporta remisiones cuando un servicio de nombres/directorio proporciona dicha caracter�stica. S�lo el LDAP y servicios similares soportan remisiones.

C�mo se soportan las remisiones es parte integral de la implementaci�n del proveedor de servicio. Transciende cada aspecto de c�mo se procesan las respuestas del proveedor de servicio LDAP. Esta secci�n s�lo toca unos pocos t�picos relacionados con la implementaci�n de remisiones.

�ReferralException

Una remisi�n est� representada por la clase abstracta ReferralException o su subclase LdapReferralException. Esta �ltima debe usarse para proveedores de servicio que soporten controles LDAP.

Proporcionar una implementaci�n concreta para esta clase es la clave para proporcionar soporte de remisiones. La principal tarea de la implementaci�n es devolver un contexto de remisi�n para getReferralContext(). Este m�todo tiene un par de sobrecargas, incluyendo una declarada en LdapReferralException. Es responsable de la generaci�n de un ejemplar Context que representa la localizaci�n identificada por la remisi�n. Una remisi�n est� definida como una URL en el LDAP. Una forma de crear el contexto de remisi�n es usar el soporte JNDI para URLs, por ejemplo creando una Reference usando la URL y luego usando NamingManager.getObjectInstance() para obtener el contexto.

Una vez que el programa de usuario tiene un contexto de remisi�n, se supone que llama sobre el contexto al m�todo original que caus� que se lanzara la ReferralException usando los argumentos originales. Algunos de los argumentos originales podr�an estar afectados por los contenidos de la remisi�n, incluyendo el nombre, el �mbito de b�squeda, el filtro de b�squeda, y los atributos de retorno. (Puedes ver m�s detalles en la draft-ietf-ldapext-namedref-00.txt.) Nuestra implementaci�n del contexto de remisi�n es responsable de modificar y/o reemplazar los argumentos suministrados con los de la remisi�n. Aqu� tenemos un ejemplo de como podr�a implementarse el m�todo bind() en el contexto de remisi�n:

public void bind(Name name, Object obj) throws NamingException {
    // This referral has been skipped; throw a ReferralException
    if (skipThisReferral) {
	throw new ReferralExceptionImpl(untriedReferrals);
    }

    // Override the name from the referral URL if appropriate
    Name nm = (urlName == null ? name : urlName);

    // Invoke the method on the real referral context
    refCtx.bind(nm, obj);
}

�Saltar Remisiones

Una s�la entrada de remisi�n LDAP podr�a contener varias alternativas remisiones URLs pero todas equivalentes. Realmente una ReferralException representa una s�la remisi�n URL. Como resultado, el programa de usuario puede elegir entre las alternativas usando skipReferral(). La implementaci�n de ReferralException debe tener esto en cuenta y generar posiblemente m�ltiples ReferralExceptions desde una s�la entrada de remisi�n LDAP. Despu�s de que el programa de usuario llame a skipReferral(), debe llamar a getReferralContext() para obtener un contexto v�lido. El �nico prop�sito de ese contexto es proporcionar un contexto cuyos m�todos simplemente lancen una ReferralException para la siguiente remisi�n URL de la lista de alternativas.

Observa que si el programa de usuario sigue satisfactoriamene una alternaiva, deben descartarse todas las otras alternativas no probadas.

�Modos de Remisi�n

Un programa JNDI determina c�mo quiere manejar las remisiones usando la propiedad de entorno Context.REFERRAL ("java.naming.referral"). De esta forma, el programa usuario puede especificar si quiere que las remisones se siguen autom�tica o manualmente o que sean ignoradas. Como desarrolladores de proveedores de servicio debemos manejar estos tres casos.

Cuando las remisiones se siguen autom�ticamente, deber�amos poner un mecanismo para limitar el n�mero de remisiones seguidas y as� evitar que se siguan las remisiones indefinidamente debido a fallos en la configuraci�n de los servidores. Esto puede hacerse, por ejemplo, manteniendo un contador con las ReferralException y con los contextos de remisi�n y actualiz�ndolo cada vez que se procesa una de las excepciones.

Cuando se siguen las remisiones manualmente, debemos hacer un seguimiento para saber cual es la remisi�n "actual", como se explic� en la secci�n anterior.

Actualmene las remisiones LDAP est�n especificadas por el borrador draft-ietf-ldapext-namedref-00.txt. No todos los servidores soportan este borrador. Nuestro proveedor de servicio LDAP debe decidir c�mo soportar las remisiones. Si usa este borrador, podr�a no ser totalmente interoperable con servidores que no lo hacen. Esto podr�a hacer que los servidores siempre devuelvan remisiones en respuestas LDAP sin importar qu� proveedor lo haga. Una forma de manejar este error es que nuestro proveedor lance una PartialResultException para indicar que podr�a haber m�s resultados que aquellos que se han devuelto.