Lycka Bonita

Como ejemplo utilizaré el fichero que viene en la aplicación struts-blank, que no puedo subir debido a las políticas de seguridad…, pero que se puede encontrar en las distribuciones de struts.

Este fichero consta de la declaración del fichero DTD que se va a utilizar, y a continuación la descripción de las propiedades que configuran el framework struts.

Respecto a la DTD, resaltar que puedes declarar un fichero local o uno que se encuentre en internet, por ejemplo éste. Si declaramos una DTD remota más moderna que la que viene por defecto con la distribución de struts que utilizamos, al iniciar la aplicación web tratará de realizar una conexión a internet… por lo que si el servidor no puede conectarse dará un error fatal ! Por lo que recomendamos utilizar la DTD contenida en la distribución de struts

Bien, pasemos a declarar las propiedades para configurar nuestro framework. Es importante declararlas en orden, que para eso utilizamos la DTD

• Data Source Configuration, opcional. Declaramos la configuración de los objetos que represenan fuentes de datos (data source objects) JDBC 2.0 Standard Extension. Un ejemplo para configurar un pool de conexiones JDBC. En otro post espero hablar más sobre este punto

<data-sources>
<data-source type=”org.apache.commons.dbcp.BasicDataSource”>
<set-property property=”driverClassName” value=”com.mysql.jdbc.Driver” />
<set-property property=”url” value=”jdbc:mysql://localhost/pde” />
<set-property property=”username” value=”root” />
<set-property property=”password” value=”" />
<set-property property=”validationQuery” value=”SELECT COUNT(*) FROM pdetiposprocesosgenericos” />
</data-source>
</data-sources>

• Form Bean Definitions, opcional pero bastante necesario. Declaramos los formularios que vamos a utilizar en nuestro framework, asociando un nombre a una clase de tipo ActionForm, o que extiende de esta clase. Un ejemplo:

<form-beans>
<!– 001 ADMINISTRACION –>
<form-bean name=”J001001_MenuAdministracionForm” type=”com.bne.pde.PDE001Administracion.form.J001001_MenuAdministracionForm” />
</form-beans>

• Global Exception Definitions, opcional. Declaramos las excepciones que nuestra aplicación utilizará en el ámbito global, es decir, las excepciones que nuestros Actions podrían lanzar.

<global-exceptions>
<exception key=”timeout.session.error”
path=”/sessionerror.do”
type=”javax.servlet.UnavailableException”
scope=”request”>
</exception>
</global-exceptions>

• Global Forward Definitions, opcional. Declaramos los destinos (forwards) que nuestra aplicación web utilizará en un ámbtio global.

<global-forwards>
<forward name=”inicioAdministracion”
path=”/identificacion.do?stDestino=administracion” />
</global-forwards>

• Action Mapping Definitions, muy recomendado declaramos las acciones de nuestra aplicación web, asociando una acción (clase que extiende de Action) y un formulario (nombre de ya declarado arriba) a una llamada, configurarla y declarar los posibles destinos de salida (forwards).

<action-mappings>
<!– 001 ADMINISTRACION –>
<action path=”/administracion” name=”J001001_MenuAdministracionForm” scope=”session”
type=”com.bne.pde.PDE001Administracion.action.J001001_MenuAdministracionAction”>
<forward name=”SUCCESS” path=”/WebContent/jsp001/JSP001001_Administracion.jsp” />
</action>
</action-mappings>

• Controller Configuration, opcional. Describe un bean ControllerConfig (org.apache.struts.config.ControllerConfig) que encapsula la configuración de un runtime

<controller processorClass = “fr.improve.struts.taglib.layout.workflow.LayoutRequestProcessor”/>

• Message Resources Definitions, declara los ficheros que contienen las claves y los mensajes de la aplicación web.

<message-resources parameter=”com.bne.pde.PDE000Arquitectura.util.Mensajes”/>

• Plug Ins Configuration, declara los plugins (org.apache.struts.action.PlugIn) que vamos a utilizar como las “tiles” o validadores.

<plug-in className=”org.apache.struts.validator.ValidatorPlugIn”>
<set-property
property=”pathnames”
value=”/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml”/>
</plug-in>

Protocolo LDAP (Lightweight Directory Access Protocol)

Es un conjunto de protocolos abiertos a nivel de aplicación utilizado para acceder a información almacenada centralmente en una red de ordenadores, fuertemente optimizado para operaciones de lectura rápidas y de gran volumen donde las modificaciones no son frecuentes.

Se basa en el estándar X.500 para compartir directorios, simplificado y adaptado al objetivo. El estándar define un directorio como un contenedor de información categorizada y jerarquizada. Para consultar el listado de RFCs relacionadas con el LDAP pincha aquí.

Este protocolo utiliza un modelo basado en cliente/servidor, donde el servidor puede redirigir la consulta si no contiene la información solicitada a otro servidor de LDAP. Para realizar operaciones de modificación se comprueba que el usuario tiene el permiso necesario. También soporta conexiones TCP/IP, conexiones seguras (SSL, TSL).

LDAP es utilizado en la mayoría de organizaciones debido a que :

• permite consolidar la información de la organización de forma centralizada en un repositorio.
• es accesible desde la mayoría de aplicaciones debido a la simplicidad de su API.
• es libre, es decir, no debes pagar por cada conexión o licencia.
• la replicación de datos en servidores distribuidos de LDAP (oficinas) es simple y fácil de gestionar.

Directorio LDAP

Es el repositorio donde están físicamente almacenados los datos en directorios, como hemos visto, categorizados y jerarquizados.

El nombre de los directorios es conocido como Distinguished Name (dn), y en toda estructura de directorios existe una raíz o directorio base. Podemos formar el dn de varias formas:

• o=”FooBar, Inc.” c=US (formato X.500)
• o=foobar.com (formato internet)
• dc=foobar dc=com (formato DNS)

Los directorios contienen unidades lógicas, Organizational Units (ou), que a su vez pueden estar divididos en otras ou’s. Por ejemplo, clientes, grupos, impresoras, personas…

Finalmente se almacenarán elementos dentro de esta estructura de árbol, diferenciadas por un nombre (Common Name) cn, aunque en personas se suele utilizar también el uid (identificador de usuario, único en toda la organización y no modificable a lo largo del tiempo) para formar el DN.

Con todo, el DN de un elemento dentro de una estructura de árbol quedaría (igual que los nombres DNS se lee en orden inverso):

cn=AlejandroPerezMartin00000000T, ou=clientes, dc=foobar, dc=com

uid=perezalej, ou=employee, dc=foobar, dc=com

La manera de almacenar la información en cada registro es mediante pares, consistentes en un atributos y su valor. Por tanto, al definir atributos opcionales no gastan memoria si van vacíos. Y pueden también almacenar diferentes valores para el mismo atributo, por ejemplo, ingredientes:

  dn: cn=ComidaDeAvena Deluxe, ou=recipes, dc=foobar, dc=com
cn: Comida de avena instantánea Deluxe
recipeCuisine: desayuno
recipeIngredient: 1 paquete de comida de avena instantánea
recipeIngredient: 1 tazón de agua
recipeIngredient: 1 pizca de sal
recipeIngredient: 1 tsp de azúcar marrón
recipeIngredient: 1/4 de manzana, de cualquier tipo

Una entrada en un Directorio LDAP

Un ejemplo de una entrada sería el siguiente :

  dn: uid=fsmith, ou=employees, dc=foobar, dc=com
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: foobarPerson
uid: fsmith
givenname: Fran
sn: Smith
cn: Fran Smith
cn: Frances Smith
telephonenumber: 510-555-1234
roomnumber: 122G
o: Foobar, Inc.
mailRoutingAddress: fsmith@foobar.com
mailhost: mail.foobar.com
userpassword: {crypt}3x1231v76T89N
uidnumber: 1234
gidnumber: 1200
homedirectory: /home/fsmith
loginshell: /usr/local/bin/bash

Se compone como vemos de :

• El DN completo, referenciado por el uid
• Clases de objeto (tantas como se quiera). Definen una serie de atributos obligatorios y otros opcionales.
• Varios CN, para realizar las búsquedas por su nombre más formal o informal por ejemplo.

LDIF (LDAP Data Interchange Format)

Es una representación de entradas LDAP en formato texto ASCII. Se utiliza tanto en consulta como en modificaciones (Altas, Bajas incluidas)

Implementaciones

• Active Directory, de Microsoft.
• eDirectory, de Novell .
• iPlanet, de Netscape.
• OpenLDAP, código libre.