Spring Ldap: operaciones básicas haciendo uso del soporte de plantillas

0
9892

Spring Ldap: operaciones básicas haciendo uso del soporte de plantillas.

0. Índice de contenidos.


1. Introducción

Como de costumbre, ya habíamos empezado por los tests, exponiendo hace tiempo
cómo ejecutar tests de integración contra un servidor ldap embebido con el soporte de Apache DS
, y ahora, en este tutorial, vamos
a ponerlos en verde, implementando el soporte de los servicios necesarios para acceder al contenido de nuestro directorio
de información con el soporte de plantillas para ldap de Spring.

Spring Ldap es un proyecto de Spring Source que simplifica
la programación contra ldap, basándose en los mismos principios que la plantillas JDBC de Spring. Las principales características del proyecto son:

  • elimina la necesidad de preocuparnos por abrir/cerrar la conexión y los recursos,
  • elimina la necesidad de realizar las iteraciones de los resultados sobre NamingEnumeration,
  • proporciona una jerarquía de excepciones unchecked, basada en DataAccessException de Spring,
  • proporciona utilidades para generar de forma dinámica filtros y DNs y facilita la gestión de atributos,
  • proporciona una gestión de transacciones en el lado del cliente, y
  • permite configurar un pool de conexiones para reutilizar las conexiones físicas abiertas.

En este tutorial vamos a dar nuestros primeros pasos, viendo los beneficios de su uso en
comparación con el api de JNDI y realizando las primeras operaciones contra el directorio.


2. Entorno.

El tutorial, y el código que contiene, han sido escritos usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2.3 GHz Intel Core i7, 16GB DDR3).
  • Sistema Operativo: Mac OS Mavericks 10.9.2
  • Eclipse Kepler + m2e plugin
  • Spring Ldap 2.0.1


3. Comparación con el API de JNDI.

El soporte de ldap que nos proporciona Spring está basado en el uso del
patrón plantilla y la mejor forma de ver sus
beneficios es exponer primero todas aquellas operaciones que se encapsulan dentro de la plantilla.

Spring ldap template es a JNDI, lo que String JDBC template es a JDBC, si no tuviéramos el soporte de Spring, para
realizar una operación de consulta contra ldap podríamos hacer uso de JNDI con un código como el siguiente:

Los principales incovenientes de JNDI son:

  • Gestión de recursos explícita:
    • el desarrollador es responsable de cerrar todos los recursos,
    • es propenso a errores y puede dar lugar a pérdidas de memoria.
  • Boilerplate code:
    • todos los métodos basados en JNDI tendrán gran cantidad de «plumbing code» que se puede extraer y reutilizar fácilmente.
  • Checked Exceptions
    • obliga a manejar explícitamente NamingException

El código anterior, desde el punto de vista de Spring Ldap, se podría reducir al siguiente:

El patrón plantilla nos abstrae de las siguientes operaciones que son comunes para todas las conexiones:

  • obtener la conexión
  • participar de la transacción, si la hubiera
  • ejecutar la consulta
  • procesar el resultado de la búsqueda
  • manejar las excepciones
  • liberar la conexión

Claro que aquí estamos dando por supuesto que la configuración de la plantilla se realiza por inversión de control
con el soporte de la inyección de dependencias de Spring.

No obstante lo anterior, si no tuviesemos el soporte de Spring también podríamos
configurarla programáticamente y haciendo uso de los mismos patrones creacionales de Spring disponer de una instancia
única de nuestro servicio.


4. Implementando un CRUD.

Una vez vistos los beneficios y cómo configurar nuestra plantilla vamos a implementar nuestros primeros métodos
de acceso a ldap.


4.1. Consulta.

Para realizar una consulta solo tendremos que hacer uso de la plantilla programando el mapeo de los resultados implementando una interfaz.

El soporte de Spring ldap también nos permite ahorrar dicho mapeo añadiendo anotaciones con la metainformación en las
propiedades de nuestras clases de negocio sobre qué atributos mapean en los objetos ldap, de este modo es cómo si
trabajásemos con anotaciones de JPA.


4.2. Bind.

Si en el punto anterior, para realizar una consulta, implementábamos un mapper, ahora para realizar operaciones
de persistencia tendremos que implementar un método builder, aunque en este caso, no haya una interfaz que seguir:


4.3. Unbind.

La última operación que veremos en este tutorial será la de borrado, que es tan simple como implementar un código
como el siguiente:


5. Referencias.


6. Conclusiones.

Como con muchos otros aspectos de nuestras tareas de programación diarias, Spring está ahí, cerca, para hacernos
la vida más fácil, gracias a su arquitectura basada en patrones de diseño.

Un saludo.

Jose

jmsanchez@autentia.com

Dejar respuesta

Please enter your comment!
Please enter your name here