Programación en castellano. Sistema de Nombrado en Java (JNDI) y II

	Añadir una dirección \| Buscador \| Cursos \| Artículos \| Foros \| Formación

Sistema de Nombrado en Java (JNDI) y II
Autor: Sun
Traductor: Juan Antonio Palos (Ozito)

En esta página:

Añadir Soporte de Remisiones

ReferralException

Saltar Remisiones

Modos de Remisión

Añadir Soporte de Remisiones

Prerequisito:
Deberías estar familiarizado con las remisiones antes de leer esta página. Las remisiones se cubrieron en la lección Remisiones.

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.

Principio Página