Prerequisito: Deberías estar familiarizado con los controles y extensiones del LDAP v3 antes de leer esta sección. Estos tópicos se cubrieron en la lección Controles y Extensiones.

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.

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:

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().

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.