Lycka Bonita

Los ficheros .war (Web ARchives) son los archivos que contienen una aplicación web, y no son más que los archivos de la aplicación web estructurado según el formato de las especficaciones de sun.

Esta estructura de directorios la podemos consultar en el capítulo 9.5 del documento Especificaciones Servlets 2.4 Sun de las especificaciones 2.4. Expondré un posible ejemplo, en negrita lo que es obligatorio:

/index.jsp
/WebContent/jsp/welcome.jsp
/WebContent/css/estilo.css
/WebContent/js/utils.js
/WebContent/img/welcome.jpg
/WEB-INF/web.xml
/WEB-INF/struts-config.xml
/WEB-INF/lib/struts.jar
/WEB-INF/src/com/empresa/proyecto/action/welcomeAction.java
/WEB-INF/classess/com/empresa/proyecto/action/welcomeAction.class

Como todos los ficheros xml de configuración, este archivo contiene una DTD (como por ejemplo ésta 2.2) que describe el contenido ordenado del fichero xml, y la descripción de las propiedades que va a utilizar. Este es el fichero que contiene la configuración de la aplicación web que estemos desarrollando, y su contenido es el siguiente:

• web-app, que es el elemento raíz del fichero xml.
• icon, especifica la ruta para las imágenes asociadas a los iconos pequeño y grande que representan a la aplicación.
• display-name, el nombre que representará a la aplicación dentro de las herramientas del servidor de aplicaciones, no es un nombre funcional.
• description, texto descriptivo de la aplicación, que al igual que las dos anteriores propiedades, sólo es representativo.
• context-param, nos permite configurar la inicialización del contexto de una servlet de nuestra aplicación web. Un ejemplo :

<context-param> <param-name>hostname</param-name> <param-value>localhost</param-value> <description> The name of the host on which recipned is running </description> </context-param>

• servlet, declaramos la configuración de nuestras servlets. Un ejemplo típico es la configuración de la servlet para utilizar struts:

<servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> <load-on-startup>2</load-on-startup> </servlet>

• servlet-mapping, relacionamos las servlets que hemos declarado con las url que van a escuchar. Por ejemplo para utilizar la servlet que hemos llamado anteriormente "action" cuando la url tiene la extensión ".do":

<servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>

• session-config, parámetros para configurar la sesión. El único, session-timeout que por defecto es 30 minutos.

<session-config> <session-timeout>30</session-timeout> </session-config>

• mime-mapping, para declarar una relación entre las extensiones y los tipos mime.

<mime-mapping> <extension>doc</extension> <mime-type>application/vnd.ms-word</mime-type> </mime-mapping> <mime-mapping> <extension>dsp</extension> <mime-type>text/html</mime-type> </mime-mapping>

• welcome-file-list, especifica los ficheros de bienvenida posibles.

<welcome-file-list> <welcome-file>index.jsp</welcome-file> <welcome-file>indexAdministracion.jsp</welcome-file> </welcome-file-list>

• tag-lib, para describir librerías de etiquetas (tab libs!!!) de los ficheros JSP. Por ejemplo, las típicas utilizadas con struts:

<taglib> <taglib-uri>/tags/struts-bean</taglib-uri> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location> </taglib>

• error-page, para asociar errores HTML y excepciones lanzadas a páginas de error personalizadas para la aplicación:

<error-page> <error-code>404</error-code> <location>/notfound.jsp</location> </error-page> <error-page> <exception-type>java.lang.Throwable</exception-type> <location>/error.jsp</location> </error-page>

• resource-ref, utilizado para declarar recursos externos que nuestra aplicación va a utilizar, como una conexión a una base de datos.

<resource-ref> <description>Conexion hacia Base de Datos SQL</description> <res-ref-name>jdbc/ConexionMySQL</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>

• security-constraint, para proteger áreas de la aplicación (o la aplicación completa como en el ejemplo), asonciándolas a roles que deben tener los usuarios para poder acceder. Estos usuarios y roles son los declarados en TOMCAT_ROOT/conf/tomcat-users.xml. Es útil cuando queremos proteger sin desarrollar código.

<security-constraint> <web-resource-collection> <web-resource-name>Área protegida</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>intranet</role-name> </auth-constraint> </security-constraint>

• login-config, para configurar el tipo de login que se requerirá al entrar en un área protegida previamente declarada. Dos valores posibles para los métodos de autenticación posibles son BASIC, FORM.

<login-config> <auth-method>BASIC</auth-method> <realm-name>Autentificación por formulario</realm-name> </login-config> <login-config> <auth-method>FORM</auth-method> <realm-name>default</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config>

• security-role, para declarar los roles de usuarios de tomcat que se van a utilizar en la aplicación:

<security-role> <role-name>intranet</role-name> </security-role>

• env-entry, declara una posible entrada al entorno (environment) de la aplicación.

<env-entry> <description>welcome message</description> <env-entry-name>greetings</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>Welcome to the Inventory Control System</env-entry-value> </env-entry>

• ejb-ref, para declarar referencias a un enterprise bean:

<ejb-ref> <description>Cruise ship cabin</description> <ejb-ref-name>ejb/CabinHome</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <home>com.titan.cabin.CabinHome</home> <remote>com.titan.cabin.Cabin</remote> </ejb-ref>

Technorati Tags: web.xml

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.

Buenas,

llega la hora de prestar más atención al correo electrónico. A estas alturas todos deberíamos de saber qué es el correo electrónico: es el intercambio de mensajes entre dos direcciones de correo electrónicas mediante protocolos de transporte habitualmente a través de Internet. Hoy en día es habitual que cada persona posea varias cuentas de correo electrónico personales, la de la universidad, la del trabajo…

Protocolos de correo electrónico de transporte y acceso

Son los mecanismos que transportan un correo electrónico desde un servidor de correo saliente. Principalmente nos encontramos con:

• SMTP (Simple Mail Transfer Protocol) : Transferencia de correos

Se encarga de transportar mensajes entre dos servidores de correo de correo electrónico.

No requiere autenticación, y por tanto cualquiera en Internet puede enviar un correo a cualquier persona (o grupos de personas), haciendo posible el correo basura y otros correos fraudulentos (phising).

Los servidores modernos de SMTP permiten únicamente el envío a hosts conocidos (open relay)

• IMAP (Internet Message Access Protocol) : Acceso a Correos

Este protocolo descarga los correos electrónicos de un buzón de un servidor, pero manteniendo una copia de los correos en el propio servidor. Además permite crear, renombrar y borrar directorios en el buzón del servidor para organizar los mensajes.

Requiere autenticación.

Es posible añadir cifrado mediante SSL.

• POP (Post Office Protocol) : Acceso a Correos

Este protocolo descarga los correos electrónicos de un buzón de un servidor, permitiendo eliminar en el servidor los correos descargados correctamente.

Requiere autenticación.

La versión de este protocolo que actualmente se utiliza es la POP3, pero es posible añadir SSL, MD5, autenticación mediante Kerberos…

Lenguaje : MIME

Debido a la necesidad de que los mensajes contengan caracteres no US-ASCII (como nuestra ñ), y a la posibilidad de que contengan archivos muy heterogéneos adjuntos, se necesitaba utilizar un lenguaje más flexible para codificar los correos electrónicos.

Es lo que llevó al MIME (Multipurpose Internet Mail Extensions) que resuelve ambos problemas (RFC 2045-2049). Por tanto, todos los navegadores y clientes de correo entienden este lenguaje.

Gestores de correo electrónico

Debio a la enorme cantidad de información que recibimos, envíamos y almacenamos (mensajes antiguos y nuevos) , la numerosas entradas de información que tenemos (cuentas de correo antiguas, las nuevas, sindicación de contenidos Web ó RSS, correos basura o SPAM), es necesario utilizar un gestor de correo, bien sea un servicio de correo Web o los llamados clientes de correo electrónico. Las principales ventajas que proporcionan estos gestores de corrreos son:

> Gestión de los mensajes recibidos/envíados, permitiéndote organizarlos en carpetas.
> Escribir y almacenar borradores de mensajes.
> Componer y enviar mensajes.
> Filtro anti-spam.

• Correo Web

Los servicios de correo Web consisten en conectarse a través de Internet a tu servidor de correo web e identificarte mediante un nombre de usuario y una contraseña (OJO, la contraseña viaja en claro a través de la red, es decir sin cifrar, es decir que cualquier malintencionado la puede leer fácilmente).

De este modo accedes a tu buzón de correo donde se encuentran almacenados tus mensajes, normalmente organizados a tu gusto en carpetas.

Tienen la ventaja de que desde cualquier máquina puedes acceder a tu buzón de correo.

Los más populares y recomendables son gmail y yahoo. El menos recomendable, hotmail (mucha publicidad, el que menos ventajas da, te pueden borrar la cuenta por inactividad…).

• Clientes de correo

Son programas instalados en un dispositivo (ordenador en general), configurado para acceder a tu buzón personal y descargar tus mensajes. De esta forma tienes acceso a tus mensajes almacenados sin conexión a internet.

Los más extendidos son la familia Outlook (de pago, agenda, el más adecuado para el trabajo), Mozilla Thunderbird (libre, ligero, completo y moderno), Eudora…

Por ahora, me decanto por Mozilla Thunderbird.