Carles Fragoso
Resumen
La patente evolución de la Internet y de las comunicaciones móviles nos está situando en un nuevo escenario en lo relacionado con el acceso a contenidos. La convergencia de ambos mundos se basa en un acceso itinerante y multidispositivo a los servicios de usuario.
El "Servicio Móvil de Correo" pretende ser una aplicación de acceso al correo electrónico para múltiples dispositivos. Su filosofía se basa en la separación entre lógica, interfaz y origen de datos. Gracias a una interfaz basada en la descripción de la información, se puede dar formato a la misma acorde al dispositivo en el momento de acceso. Mediante el uso de una librería genérica se consigue independizar la aplicación del protocolo de acceso al servidor de correo electrónico.
Palabras clave: móvil, multidispositivo, mensajería, email, interfaz, pasarela, java, xml, xslt.
Summary
Internet and Mobile Communications remarkable evolution leads us to a new content access scenario. Their convergence is based on a mobile and multiple device access to services.
`Servicio Móvil de Correo' intends to be an email access application to serve many different devices. The basic effort is the separation among logic, interface and data sources on the application. The information is formatted according to the device which asks for it because of an information-descriptive generic interface.
Another feature is the use of email generic libraries that allows the application to be protocol-independent.
Keywords: mobile, multidevice, messaging, email, interface, gateway, java, xml, xslt.
1.- Evolución de las interfaces web
La evolución de los servicios Internet se ha debido esencialmente a la aparición de nuevas necesidades por parte de los usuarios. Hasta el momento el método de acceso por excelencia es el navegador web y la información se encuentra formateada bajo lenguaje de contenidos HTML.
Ahora hay que dejar paso a la aparición de gran cantidad de nuevos dispositivos con limitaciones de formato y que utilizan otros lenguajes de contenidos. Para solucionar este problema de una forma eficaz se deben generalizar las interfaces para que describan la información en vez de preocuparse del formato. De esta manera incrementamos el tiempo de proceso y la complejidad del acceso a contenidos pero conseguimos minimizar el esfuerzo de adaptación a futuros dispositivos.
Existen dos tendencias claras en la adaptación de interfaces web: la creación de plantillas de formato rellenadas dinámicamente y la transformación de interfaces a lenguajes de contenido bajo demanda. También se pueden obtener soluciones híbridas fruto de ambas filosofías.
2.- Un nuevo webmail: Requisitos iniciales
No es nueva la idea del acceso al correo electrónico mediante interfaz web. Su gran éxito radica en la comodidad y facilidad de uso. A efectos prácticos nos permite un sistema personalizado y seguro para un acceso desde diferentes ubicaciones. Además hay que tener en cuenta que su implementación no es excesivamente costosa ni compleja.
Si existen ya infinidad de webmails creados, ¿por qué crear uno propio? El desarrollo de un webmail nos puede permitir una personalización completa según nuestras necesidades, cosa que sólo se puede conseguir parcialmente con aplicaciones ya creadas sean o no de libre distribución. También nos proporciona un nivel de seguridad adicional ya que al ser una aplicación propia no estará tan probada como otras de uso extendido.
Una vez justificada la creación de un webmail, cabe definir los requisitos a cumplir:
- Funcionalidades de cliente de correo básicas
- Acceso a buzones de correo bajo diferentes protocolos de acceso: POP3, IMAP4
- Personalización de la interfaz y del nivel de detalle por parte del usuario
- Implementación en múltiples idiomas
- Escalabilidad frente al incremento de usuarios
- Independencia del lenguaje de contenidos para permitir el uso a múltiples dispositivos
Para su implementación se optó por el lenguaje Java que, aparte de su conocida portabilidad entre sistemas, nos permitía ejecutar nuestra aplicación en un servidor de aplicaciones y disfrutar de la potencia de este lenguaje.
3.- Separación Modelo-Vista-Controlador: Jakarta Struts
El primer paso en el proceso de creación consiste en adquirir una arquitectura que nos permita implementar la aplicación separando lo máximo posible sus diferentes partes: modelo (abstracción de datos), vista (interfaz para el usuario) y controlador (funcionalidades). Es lo que se conoce como filosofía MVC (Modelo-Vista-Controlador) y que permite delimitar claramente las partes para que analistas, diseñadores y programadores puedan trabajar en un proyecto sin prácticamente interferir unos en el trabajo de los otros.
Para la creación de interfaces web que sigan esta filosofía, existe un framework de libre distribución llamado Jakarta Struts [1] implementado en lenguaje Java. Su estructura consta de:
- Un controlador que recibe la petición y la redirige al código de procesamiento que corresponda.
- Objetos de lado servidor para representar nuestras abstracciones de datos con funciones de validación automáticas y acceso a ellos desde vista y controlador (JavaBeans)
- Vistas elegidas dinámicamente y basadas en lenguaje de contenidos facilitando el acceso a los objetos de lado servidor mediante tags específicos (taglibs).
Una funcionalidad de gran utilidad incorporada es la generación de interfaces en múltiples idiomas de forma transparente mediante el lenguaje que el usuario tenga configurado como predeterminado en su navegador.
4.- Interfaz independiente del dispositivo: XML+XSLT
Para independizar la interfaz web se utiliza un lenguaje de marcas propio, basado en XML [2], que describe la información estructuralmente sin ningún tipo de parámetros de formato.
Cuando un dispositivo accede a la aplicación, se analizan las cabeceras de petición para estimar el tipo de dispositivo y el lenguaje de contenidos apropiado para la respuesta. Se realiza la acción de procesamiento correspondiente a la acción demandada por el usuario, por ejemplo listar el correo del buzón de entrada, generando la información correspondiente en el mencionado lenguaje. Por último, se realiza una transformación de la respuesta mediante la plantilla XSL del dispositivo de acceso utilizando el lenguaje XSLT [3].
Para el cliente el proceso es totalmente transparente ya que realiza una petición y todo el proceso funcional y de formato de la respuesta se realiza en el servidor. Esto puede ocasionar ciertos retardos que se puede considerar el punto más débil de la aplicación.
5.- Independencia del protocolo de correo: JavaMail API
Uno de los objetivos de la aplicación es conseguir crear un cliente de correo independiente del protocolo utilizado. Una clara solución es implementar una estructura de capas donde la última capa sea la dependiente del protocolo y la capa más alta nos dé unas primitivas de alto nivel para la comunicación.
JavaMail API de Sun [5] es una librería Java que nos proporciona objetos que son abstracciones del acceso a un buzón de correo: carpeta, mensaje, buzón, etc. Estos objetos trabajan sobre unos proveedores de protocolo, que no son más que intermediarios que realizan la comunicación de más bajo nivel contra el servidor de correo. De esta manera, si surge un nuevo protocolo de correo sólo se requiere implementar un proveedor de protocolo y la aplicación seguiría funcionando sin modificación alguna.
6.- Arquitectura web
La aplicación se ejecuta sobre uno o varios servidores de aplicaciones Java J2EE [6] [7] permitiéndose, con la configuración adecuada, el balanceo de carga entre ellos.
Los diferentes servidores de aplicación Java se pueden conectar a los servidores web de uso más extendido, como por ejemplo Apache, de forma sencilla. Esto nos da la posibilidad de montar la aplicación sobre una cierta ruta en nuestro sitio web ya existente sin tener que recurrir a redirecciones y, además, que éste nos sirva los contenidos estáticos.
7.- Conclusiones
La combinación de todos los elementos mencionados nos proporciona una aplicación fácilmente adaptable a nuevos dispositivos e independiente del protocolo de correo. Es un esquema más complejo de implementar pero más genérico y fácil de mantener en un futuro.
Parece ser que la evolución, en parte marcada por el W3C [8], tiende hacia un único lenguaje de contenidos (XHTML) pero con una personalización de los elementos a mostrar y de su nivel de detalle.
Para cumplir con este objetivo se requiere delimitar claramente la naturaleza del dispositivo y para ello el W3C está definiendo una nueva especificación a cumplir por los dispositivos indicando sus características gráficas, de procesamiento y otras (User Agent Attributes).
La adaptación de las interfaces es algo que se dará tarde o temprano aunque las tecnologías que nos lo posibilitan actualmente todavía deben madurar bastante.
8.- Referencias
[1] Jakarta Struts: an Open-Source MVC implementation - http://jakarta.apache.org/struts
[2] Professional XML Autores Varios (Wrox Press) - ISBN 1-861003-11-0
[3] W3C XSL Transformations v.1.0 - http://www.w3.org/TR/xslt
[4] W3C Xpath Language v.1.0 - http://www.w3.org/TR/xpath
[5] JavaMail API Design Specification - http://java.sun.com/products/javamail/JavaMail-1.2.pdf
[6] Jakarta Tomcat - http://jakarta.apache.org/tomcat
[7] Resin Java Application Server - http://www.caucho.com/products/Resin
[8] World Wide Web Consortium http://www.w3.org
(
cfragoso [at] cesca [dot] es)Dept. Comunicacions i Operacions
Centre de Supercomputació de Catalunya