Sistema de Nombrado en Java (JNDI) y II

Normalmente un proveedor de servicio soporta controles y extensiones LDAP v3 s�lo cuando lo hace el servicio de nombres/directorio subyacente. S�lo el LDAP y los servicios del estilo LDAP soportan estas caracter�sticas.

Para soportar controles y extensiones, la implementaci�n de contexto debe implementar el iterface LdapContext. Adem�s, la forma en que se soportan los controles y extensiones est� muy relacionada con la forma en la aue nuestra implementaci�n procesa peticiones y respuestas LDAP. Esta secci�n ofrece algunos puntos generales sobre c�mo implementar estas caracter�sticas.

�Controles

En el LDAP v3, podemos enviar un control de petici�n junto con cualquier petici�n LDAP y recibir un control de respuesta junto con cualquier respuesta LDAP. Aunque estos controles de petici�n y respuesta normalmente est�n emparejados, no es necesaria una correspondencia uno a uno entre ellos. Por ejemplo, podemos recibir un control de respuesta con una respuesta LDAP sin haber enviado ningun control de petici�n con la petici�n correspondiente.

La implementaci�n de contexto debe poder codificar arbitrariamente los controles de petici�n (suministrado por el usuario del API) con cualquier petici�n LDAP y debe poder decodificar arbitrariamente los controles de respuesta que acompa�an a las respuestas LDAP. La codificaci�n de controles de petici�n la hacen realmente las implementaciones individuales del interface Control mediante Control.getEncodedValue(). La decodificaci�n de los controles de respuesta la hacen las implementaciones de los controles de respuesta, que la implementaci�n de contexto selecciona mediante ControlFactory.getControlInstance().

Hay disponibles dos tipos de controles de petici�n:

• Control de Petici�n de Conexi�n. Afecta a c�mo se crean las conexiones.
• Control de Petici�n de Contexto. Afecta a los m�todos de contexto.

Los controles de peticiones de conexi�n son inicializados por el argumento del usuario del API al constructor de InitialLdapContext o a LdapReferralException.getReferralContext() y modificados mediante LdapContext.reconnect(). La implementaci�n de contexto debe mantener un control de petici�n de conexi�n del contexto en la propiedad de entorno "java.naming.ldap.control.connect" y pasar esta propiedad a los ejemplares de Context que crea. De esta forma, los ejemplares Context derivados heredar�n los controles de conexi�n.

La implementaci�n de contexto deber�a mantener un control de petici�n de contexto para cada ejemplar de Context y no pasarlo a los contexto derivados. Los controles de petici�n de contexto son inicializados por el argumento del usuario del API a LdapContext.newInstance() y modificados mediante LdapContext.setRequestControls().

�Operaciones "Extendidas"

Un usuario del API invoca a una operaci�n "extendida" creando una ExtendedRequest y luego llamando a extendedOperation(). La implementaci�n de contexto es responsable de codificar las peticiones extendidas y enviarlas como una operaci�n "extendida" LDAP al servidor LDAP. La codificaci�n realmente la hacen las implementaciones individuales del interface ExtendedRequest mediante ExtendedRequest.getEncodedValue(). Cuando el servidor devuelve la correspondiente respuesta extendida, la implementaci�n de contexto pasa la respuesta a ExtendedRequest.createExtendedResponse() para generar un respuesta para el llamador inicial de extendedOperation().

De esta descripci�n, los �nicos que parecen manejar operaciones "extendidas" son los desarrolladores de ExtendedRequests. Sin embargo, esto es cierto s�lo para operaciones "extendidas" que no afectan a la implementaci�n de contexto. Es com�n que las operaciones "extendidas" afecten al estado de la implementaci�n de contexto. Por ejemplo, la operaci�n Start TLS permite el protocolo "Transport Layer Security" (TLS) sobre una conexi�n LDAP existente. A�adir soporte para dicha operaci�n requiere cambios en cualquier implementaci�n de contexto existente y depende de los interfaces internos de la implementaci�n de contexto. Por eso, normalmente es dificil definir un marco de trabajo general para manejar operaciones "extendidas" arbitrarias. Normalmente, la implementaci�n de contexto mantedr�a una lista de operaciones "extendidas" que soportar�a de forma nativa. Luego inspeccionar�a los identificadores de objetos de las respuestas extendidas para aquellas operaciones y modificar�a su comportamiento de la forma apropiada. Realmente no hay una buena forma de manejar operaciones "extendidas" que no conocen su causa y no puede decir si deber�a ignorarse o levantarse la operaci�n.