Sunteți pe pagina 1din 127

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA TÉCNICA SUPERIOR


DE INGENIEROS DE TELECOMUNICACIÓN

Departamento de Ingeniería de Sistemas Telemáticos

PROYECTO FIN DE CARRERA

Desarrollo e Implementación de un
Sistema de Colaboración Web con
Metodología Ágil

RAFAEL GARCÍA MARÍN


Noviembre de 2008
Proyecto Fin de Carrera

Título: Desarrollo e Implementación de un Sistema de


Colaboración Web con Metodología Ágil

Autor: Rafael García Marín

Tutor: Joaquín Salvachúa Rodríguez

Departamento: Departamento de Ingeniería de Sistemas


Telemáticos

Miembros del Tribunal Calificador

Presidente: Juan Quemada Vives Fdo.

Vocal: Joaquín Salvachúa Rodríguez Fdo.

Secretario: Gabriel Huecas Fdo.

Suplente: Santiago Pavón Gómez Fdo.

Fecha de lectura y defensa ..... de ....................... de 2008

Calificación
Resumen

En el marco de la nueva Internet, nos encontramos con el paradigma de lo que se


conoce como Web 2.0. Este concepto engloba a todas aquellas aplicaciones y servicios de
internet que se sustentan sobre una base de datos, modificable por los usuarios del
servicio, tanto en su contenido como en la forma de presentarlos. Ésta característica
fundamental de la Web 2.0 es lo que ha propiciado una revolución en lo que a la sociedad
y su uso de internet se refiere.

El mayor protagonista de la Web es ahora mismo el usuario y eso se explica en el


uso masivo de las aplicaciones llamadas “redes sociales”. Basándose en este concepto de
compartición del conocimiento y de la interactividad total entre usuarios y aplicaciones, el
mundo empresarial ha empezado a percibir este movimiento como una potente
herramienta de trabajo.

Este proyecto se sustenta sobre estos conceptos, con el uso de tecnologías


altamente relacionadas con este nuevo movimiento en Internet como es el caso de Ruby
on Rails, y la necesidad de interfaces de usuario mucho más potentes y usables. Por ello,
surge Flex como evolución de Flash y lenguaje de programación web. Para unir una
aplicación cliente en Flex y su servidor en Rails, se usará Atom Syndication Format y Atom
Publishing Protocol como máximos exponentes de lo que debe ser un interfaz de
aplicación basado en RESTful Web Services.

Palabras Clave
Internet, Web 2.0, Ruby on Rails, Atom, REST, CMS, SIR, Modelo-Vista-
Controlador, Ágil, Flex

v
Abstract

Alongside the new Internet, we find the paradigm of what it is being called Web
2.0. This concept relates to all applications and Internet services sustained on a database,
which can be modified by users of the service not only in its content but in the way they
are presented. This main characteristic of Web 2.0 is what has developed a social
revolution regarding the user of internet.

The main subject in the Web is the user, and this explains the massive user of
applications called “social networks”. Based in knowledge sharing and total interactivity
between users and applications, the business world is beginning to regard this movement
as a great working tool.

This project sustains over this concepts. The most important are the use of
technologies highly related to this new movement in internet such as Ruby on Rails, and
the necessity of user interfaces much more powerful and useful. This is way Flex is
developed as a Flash evolution and a programming language. Connecting a Flex client
application and a Rails server will be done by using Atom Syndication Format and Atom
Publishing Protocol as main standards of what an application interface should be when
based on RESTful Web Services.

Key Words
Internet, Web 2.0, Ruby on Rails, Atom, REST, CMS, SIR, Model-View-
Controller, Agile, Flex

vii
Agradecimientos

Y es que no podía ser de otra manera. Mi proyecto debe comenzar con una sección
interminable de agradecimientos, como viene siendo habitual en los PFCs de los
isabelinos. Seguramente sea la única parte que se vaya a leer de este pedazo de PFC, y por
ello es el texto más trabajado y pensado de todo el libro.

En un principio había pensando en coger y copiar directamente los


agradecimientos del proyecto de Pabluto. ¿Podría haber algo más ruin y pernicioso? Pues
sí, hacer que un becario nuevo te haga tu proyecto en dos semanas y luego leerlo diciendo
que lo hiciste tú. Pero bueno, decidí que lo mejor era escribirme unos propios.

En primer lugar, quiero agradecérselo a mi familia, a mi padre, a mi madre y a mi


hermano, que son los que realmente han hecho posible que puedas estar leyendo estas
líneas en este momento. A mi padre, que todavía tiene mucho que enseñarme a pesar de
que nunca llegará a ser ingeniero como yo, a mi madre, que me enseñó que lo importante
en la vida es ser feliz y hacer tartas, y a mi hermano, que es un claro ejemplo de que lo que
importa en la vida es irse de fiesta.

Después, que no menos importante, mi mayor agradecimiento para Bea, la que


siempre me ha apoyado y siempre lo hará y porque sin ella nada sería posible. Cierto es
que ni siquiera ella se leerá el tomo, pero no le voy a guardar rencor, yo tampoco lo haría.

También quiero agradecer a mis amigos que han estado conmigo siempre, a todos,
a los más golfos y a los más raspuros.

No me puedo olvidar tampoco de todos los amigos que me he encontrado a lo


largo de la carrera, que son muchos y variopintos, y que en gran medida también han
contribuido a pasar estos 5 años en la escuela. No quiero poner nombres porque son
muchos y luego claro, te olvidas de alguien y ya se sabe.

Sin embargo, sí que puedo nombrar uno a uno cada uno de los isabelinos, porque
son los que más han tenido que ver en el proyecto, porque han estado ahí conmigo en
este sprint final, y porque sé cuántos son y no se me va a olvidar ninguno. Secáos las
lagrimillas porque ahora viene lo bueno.

ix
Primero quiero nombrar a los que ya no están en la beca. Alfredo por ser el más
modernito y el que más partido saca a su pelo, y porque hackear la coctelera nunca fue tan
fácil. Jubun, porque los screencasts ya no son lo mismo sin David Jubunemeier. A J. Ágora,
porque nunca vi persona que hablara menos. Al gran Fonta, porque no tengo palabras
para describir tanta genialidad junta, y probablemente se quedaría dormido mientras las
busco. Y por supuesto, no me voy a olvidar de él, a Pabluto, iniciador de este trabajo y
maestro del “cómo ser ingeniero con un proyecto de proyecto”, al cual si le buscáis y no le
encontráis, ya sabéis por qué es. Es que está con Estefi. Por cierto, ¿dónde está Estefi?
Pabluto… ¿dónde está Estefi?

Después agradecer a los que están en activo, primero al grandísimo Quique, el


señor DonKi, porque aunque el Philo se vaya a la mierda y el SIR no valga para nada,
siempre te quedará la Coctelera, eres el tío más grande y este PFC es medio tuyo. Al mítico
Dieguto, porque sin él las investigaciones nunca serán lo mismo, te dejo este pedazo de
PFC para que guíes tu investigación de los próximos 3 años. Y porque Dungeons no es nada
sin Dragons, al gran David, maestro del futbolín y lurker entre lurkers, para demostrarte
que se puede leer el PFC en 2008. Siguiendo en el neoCBR, a Iván, compañero de fatigas en
el SIR y el mejor jugador de pádel sobre la tierra, o al menos el que más partidos juega. Al
legendario Antonio Tapiador, que redefinió el concepto de CMS para llevarlo a un nuevo
paradigma interestelar, además de ser mi oráculo particular y el primer friki de Rails que
no usa Mac. Al maestro del Kongregate y salvador de Fonta, Álvaro, porque nunca nadie
bebió tanto y sufrió las borracheras de otro. Al entrañable Pedro, con pelo largo o sin él,
nuevo modernito en potencia, y porque el día que lea su proyecto Emilio acabará su Tesis.
Al supermaster Javi, maestro de todo lo que toca y líder intrainterno, porque descubriré el
fallo del algoritmo que hace que siempre quedes primero. Al ladrón de Antoñito, porque
se quedó con mi silla y con Cinquillo, y porque gracias a él cualquier día seremos
millonarios con Isabel. A Marina porque sin ella el SIR sería mucho más feo, y por aguantar
a Dani, que ya es bastante. Al otro Iván, porque eso de ser el otro es una mierda, y encima
se parece a Ronaldo hasta en las lesiones. A Gabo, porque es la hora de comer, y si no es la
hora de comer, ya te lo recordará él. A Isabel, a la que realmente no debería agradecer
nada por robarnos a Carletes pero valgan estas líneas para quedar bien. A Waldo y Faldo…
digo… Aldo y Alberto, porque después de Dungeons and Dragons son la mejor pareja
dentro de los isabelinos.

x
Y a los que se creen mejores porque están dentro del cubículo del que siempre se
olvidan la llave. A Emilio, porque siempre siga en modo juguetón, porque el rabo está muy
bueno (el de toro) y porque el cine doblado es una mierda. A Fernando, porque nunca
deberé cruzarme con él en una reunión si quiero seguir con vida. A Barce, porque gracias a
él ya casi sé pilotar aviones comerciales (casi). A Jaime porque da gusto verle, siempre con
una sonrisa. A Vicen, el revolucionario, porque gracias a él hacer una tesis y ser isabelino
ya no será incompatible (¿o lo seguirá siendo?). A Sandra, para que nunca se quede sin
agua en la nevera. Y también por supuesto, al gran vegano, enmarronador de
enmarronadores, Abel, porque nunca pensé que no comer carne fuera tan divertido (para
los demás, claro). Y no se me olvida, a Enjuto Heinemeier, por ser el más grande de todos
los screencasts, y porque nunca se hará uno mejor.

Y un rincón especial para el concilio; a Carletes, el segundo mayor freak que


conozco, vicepresidente del club de los zumos y sufridor en silencio de Isabel, ya sea en
modo aplicación o en modo novia mandona, tipo curioso donde los haya que te lo dice
todo sin hablar; y a Dani, el mayor de los freaks que conozco, señor del club de los zumos y
sufridor en silencio del interfaz de la mayor cagarruta de las aplicaciones, espero que no te
acuerdes mucho de mí cuando tengas que acabar tu proyecto.

Y también quiero dar las gracias a los jefes, a Joaquín, a Santi, a Gabriel y a Juan,
principalmente por haber juntado a tan gran elenco de becarios. Lo que JQ unió, que no lo
separe La Coctelera.

Muchas gracias a todos.

PD: Pabluto, si tú me aburrías y tu proyecto aún más… imáginate cómo de aburrido


será lo que viene ahora… efectivamente, vas a flipar.

xi
Índice de Contenido

1 INTRODUCCIÓN ............................................................................................... 21

1.1 Introducción .............................................................................................. 23

1.1.1 Contexto del Proyecto ........................................................................ 23

1.1.2 Objetivos ............................................................................................ 24

1.1.3 Estructura del documento .................................................................. 26

2 ESTADO DEL ARTE ........................................................................................... 27

2.1 Estado del arte .......................................................................................... 29

2.1.1 Servicios de colaboración ................................................................... 29

2.1.2 La aplicación SIR ................................................................................. 35

2.2 Tecnologías utilizadas para el desarrollo ................................................... 40

2.2.1 Ruby on Rails ...................................................................................... 40

2.2.2 RESTful Web Services ......................................................................... 44

2.2.3 Atom .................................................................................................. 46

2.2.4 Flex .................................................................................................... 49

3 MEMORIA ....................................................................................................... 51

3.1 Análisis del problema ................................................................................ 53

3.1.1 Metodología Ágil ................................................................................ 55

3.1.2 Viabilidad ........................................................................................... 57

3.2 Arquitectura del sistema ........................................................................... 57

3.2.1 La arquitectura MVC .......................................................................... 57

3.2.2 Recursos del sistema .......................................................................... 61

xiii
3.3 Diseño e Implementación .......................................................................... 63

3.3.1 Refactoring ......................................................................................... 63

3.3.2 El interfaz Atom.................................................................................. 66

3.3.3 Nuevas funcionalidades...................................................................... 70

3.4 Pruebas ..................................................................................................... 72

3.5 Despliegue ................................................................................................ 74

3.5.1 Passenger ........................................................................................... 75

3.5.2 Apache ............................................................................................... 75

3.5.3 Capistrano .......................................................................................... 76

3.6 Documentación ......................................................................................... 76

4 CONCLUSIONES ............................................................................................... 78

4.1 Problemas Encontrados ............................................................................. 79

4.2 Conclusiones ............................................................................................. 80

4.3 Trabajos futuros ........................................................................................ 81

4.4 Bibliografía ................................................................................................ 85

5 APÉNDICES ...................................................................................................... 87

5.1 The SIR Application Interface ..................................................................... 89

5.1.1 Introduction ....................................................................................... 89

5.1.2 How to use this document.................................................................. 89

5.1.3 The REST Interface ............................................................................. 90

5.1.4 The Interface Format .......................................................................... 92

5.1.5 Resources ........................................................................................... 96

xiv
Índice de Imágenes

Figura 1: Captura de Isabel ......................................................................................... 31


Figura 2: Captura de Marte ......................................................................................... 32
Figura 3 : Logotipo de Lotus Notes .............................................................................. 33
Figura 4: Logotipo de Lotus Connections ..................................................................... 33
Figura 5: Logo de BSCW .............................................................................................. 34
Figura 6: Logo de Open-Xchange ................................................................................. 34
Figura 7 :Logo de eGroupWare.................................................................................... 35
Figura 8: Captura de pantalla de la aplicación MIR ..................................................... 36
Figura 9: Captura de pantalla de la aplicación SIR ....................................................... 39
Figura 10: Logo de Ruby .............................................................................................. 40
Figura 11 : Logo de Rails ............................................................................................. 41
Figura 12: Icono no oficial que indica existencia de feeds en la web ............................ 47
Figura 13: Logo de Adobe Flex ..................................................................................... 49
Figura 14: Ciclo de vida en cascada ............................................................................. 54
Figura 15: Ciclo de vida en espiral ............................................................................... 54
Figura 16: Esquema de relaciones entre modelo, vista y controlador ........................... 58
Figura 17: Esquema de una arquitectura Web con Rails y Flex .................................... 59
Figura 18: Arquitectura de una aplicación Web con Rails y Flex con un interfaz Atom . 61
Figura 19: Esquema de secuencia de peticiones para los métodos de lectura index y
show ........................................................................................................................... 67
Figura 20: Esquema de secuencia de peticiones para los métodos de escritura, create y
update ........................................................................................................................ 68

15
Índice de tablas

Tabla 1: REST Resources .............................................................................................. 90


Tabla 2: Nested resources in REST ............................................................................... 91
Tabla 3: Single Resource in REST ................................................................................. 92
Tabla 4: Formatted Resources in REST ......................................................................... 93
Tabla 5: XML Interface ................................................................................................ 93
Tabla 6: Atom Interface............................................................................................... 96
Tabla 7: Spaces Interface ............................................................................................ 97
Tabla 8: Users Interface ............................................................................................ 100
Tabla 9: Nested Users Interface ................................................................................. 101
Tabla 10: Events Interface ......................................................................................... 105
Tabla 11: Articles Interface........................................................................................ 109
Tabla 12: Attachments Interface ............................................................................... 113
Tabla 13: Machines Interface .................................................................................... 116
Tabla 14: Groups Interface ........................................................................................ 119
Tabla 15: Profile Interface ......................................................................................... 122

17
Glosario

AJAX Asynchronous JavaScript And XML

CSS Cascading Style Sheet

CRUD Create Read Update Delete

DRY Don’t Repeat Yourself

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol. Protocolo de Trasnferencia de


HiperTexto

IDE Integrated Development Environment. Entorno de desarrollo


integrado.

J2EE Java 2 Platform Enterprise Edition

JSP Java Server Page

LDAP Lightweight Directory Access Protocol

MCU Multipoint Control Unit. Unidad de control multipunto. Parte de


los programas de videoconferencia que se encarga de la gestión
de flujos multimedia.

MIME Multipurpose Internet Mail Extensions

MIR Management of Isabel Reservations

MVC Modelo Vista Controlador

MXML Macromedia XML

REST Representational State Transfer

xix
RFC Request For Comments

RIA Rich Internet Applications

RSS Really Simple Syndication

SIP Session Initiation Protocol

SMTP Simple Mail Transfer Protocol

SOAP Simple Object Access Protocol

SWF Shockwave Flash

URL Uniform Resource Locutor

VNC Virtual Network Computing

YAML YAML Ain’t a Markup Language

XEDL XML Event Definition Language

XML Extensible Markup Language

xx
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

1 INTRODUCCIÓN

21
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

1.1 Introducción

Este primer capítulo está dedicado a explicar el marco que engloba al presente
Proyecto Fin de Carrera, con el objetivo de situar a éste en su contexto, permitiendo al
lector comprender mejor su alcance y envergadura. Para ello se hará una breve explicación
del estado actual de las aplicaciones existentes sobre trabajo colaborativo y los
procedimientos de la metodología ágil. Así mismo en este capítulo se detallarán los
objetivos del proyecto y la estructura del documento.

1.1.1 Contexto del Proyecto

El trabajo colaborativo entre grupos de personas es fundamental en la realización


de proyectos en las organizaciones. En el mundo en el que vivimos, cada vez más
globalizado, se hace más frecuente el trabajo en grupo entre personas de diferentes
localizaciones geográficas. Por ello cobran gran importancia las aplicaciones que sirven
como herramientas para la coordinación y la comunicación a distancia, así como el
almacenamiento de información, gestión y compartición.

En el marco actual de la internet de nueva generación, están muy en alza las


herramientas que potencian las redes sociales. Es el llamado “software social”. Este tipo
de aplicaciones operan en tres ámbitos: comunicación, cooperación y comunidad. De esta
forma, el software social se convierte en una excelente herramienta para el trabajo
colaborativo.

En el mundo de lo que se ha denominado como Web 2.0, estas redes sociales


avanzan a pasos agigantados. Encontramos numerosos ejemplos de este tipo de
aplicaciones que han alcanzado un gran éxito actualmente, algunos de los más conocidos
son MySpace, Facebook, Friendster, Twitter o Tuenti. Las características principales de
este tipo de portales son interfaces muy intuitivos, diseños gráficos atractivos y sobretodo,
y lo que es más importante, las posibilidades de desarrollo que ofrecen a los usuarios.
Algunas aplicaciones como es el caso de Facebook, tienen APIs liberadas que permiten que
los usuarios puedan crear sus propias aplicaciones para ser usadas dentro del interfaz de la
propia aplicación. Estas mini aplicaciones reciben el nombre de widgets.

23
1. INTRODUCCIÓN Rafael García Marín

Para el desarrollo de este tipo de aplicaciones, que se basan en un esqueleto sobre


el que se van enganchando los diferentes widgets, es muy apropiada la programación
mediante metodología ágil que se escapa del ciclo de vida tradicional en cascada. Como
lenguaje de programación estandarte de este tipo de metodología encontramos a Ruby el
cual tiene un framework para crear aplicaciones web llamado Rails.

Ruby on Rails sigue el paradigma de la arquitectura Modelo Vista Controlador


(MVC). Combina la simplicidad con la posibilidad de desarrollar potentes aplicaciones
escribiendo menos código que con otros frameworks. Rails sigue dos principios
fundamentales. El de “convención sobre configuración” significa que el programador sólo
tiene que definir aquella configuración que no es convencional lo que acelera
sobremanera el desarrollo de aplicaciones con configuraciones típicas. El otro principio es
el de “Don’t Repeat Yourself” (No te repitas) que significa que las definiciones deberían
hacerse sólo una vez, y dado que Rails es un framework de pila completa los componentes
están integrados de manera que no hace falta establecer puentes entre ellos.

Es por ello que Ruby on Rails es muy adecuado para el desarrollo de aplicaciones
Web 2.0.

1.1.2 Objetivos

El objetivo de este Proyecto Fin de Carrera es la realización de una plataforma Web


para entornos colaborativos en empresa, que aglutine las diferentes aplicaciones y
herramientas que son necesarias para la correcta interrelación entre sus miembros:
videoconferencia, gestión de documentos, espacios de proyecto, grupos de trabajo,
agenda, foro, etc.

Como requisito de comienzo, se parte de una aplicación web ya existente. Esta


aplicación se denomina SIR. Ésta aplicación está desarrollada en el lenguaje de
programación Ruby on Rails. Se trata de una aplicación Web de reserva de sesiones y
manejo de recursos para un programa de videoconferencias. Este programa de
videoconferencias es ISABEL. Posteriormente al SIR se añadieron las herramientas

24
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

necesarias para transformar la aplicación al paradigma de la red social. De esta forma,


además de la funcionalidad de levantar sesiones de ISABEL, se añaden espacios de
proyecto y trabajo colaborativo, grupos de usuarios, agenda y foros.

Esta nueva versión de SIR sirve como núcleo de la plataforma que vamos a
desarrollar. La funcionalidad que necesitamos en cuanto a herramientas para trabajo
colaborativo nos las da el SIR. Se recubrirá este núcleo SIR con un interfaz de usuario
acorde con el paradigma de las RIA. Las RIA, son una evolución o nuevo concepto de las
aplicaciones Web más tradicionales que aporta un gran número de ventajas tanto a la hora
de desarrollar la aplicación en si, como a la hora de utilizarla.

Mientras que una aplicación Web más tradicional se basa en la recarga continua de
páginas cada vez que el usuario desea acceder a una nueva vista o información,
produciendo por tanto un tráfico muy alto entre cliente y servidor; las aplicaciones RIA no
usan la recarga de páginas, pues en la primera conexión entre cliente y servidor se carga
toda la aplicación en el lado cliente, produciéndose sólo comunicación con el servidor
cuando se necesita conexión a una Base de Datos o acceso a información externa a la
aplicación.

De esta manera, logramos un mayor rendimiento y aprovechamos en mayor


medida el ancho de banda disponible al no ser necesaria una recarga tras cada cambio
mínimo en la página. Esto conlleva una mayor usabilidad para el usuario, el interfaz es
mucho más agradable y dinámico. Para lograr este interfaz RIA se utiliza el lenguaje de
programación Flex. Para ello es imprescindible que el SIR tenga un interfaz de aplicación
que permita interconectar otras aplicaciones o herramientas de forma modular y
escalable.

El objetivo de este proyecto fin de carrera es construir un interfaz de aplicación


para el SIR de forma que se pueda acometer con éxito la integración del núcleo de la
plataforma con el interfaz Flex.

El diseño e implementación del interfaz Flex es el objetivo de otro proyecto fin de


carrera, que se desarrolla paralelamente a éste.

25
1. INTRODUCCIÓN Rafael García Marín

1.1.3 Estructura del documento

Este documento es la memoria del proyecto que lleva como título “Desarrollo e
Implementación de un Sistema de Colaboración Web con Metodología Ágil”.

El objetivo de este documento es, en primer lugar, servir como memoria de


finalización de dicho proyecto, en segundo servir como manual de usuario de la
plataforma SIR en su versión actual y en último lugar servir como guía para que cualquier
desarrollador que vaya a utilizar SIR como núcleo de una plataforma CMS comprenda
cómo se debe utilizar el interfaz desarrollado.

El documento se divide en tres partes bien diferenciadas:

La primera parte es la denominada Estado del Arte en la que se explican


brevemente algunas de las aplicaciones que existen comercialmente y que
tienen funcionalidades parecidas a las del SIR, así como una breve introducción
a cada una de las tecnologías utilizadas en el desarrollo del proyecto.

La segunda parte contiene la memoria en sí del proyecto, explicando primero


las metodologías de desarrollo utilizadas, después la arquitectura de la
aplicación, y luego las tres principales fases del proyecto, la refactorización
REST, el interfaz Atom y las nuevas funcionalidades. Además se habla del
despliegue de la aplicación y las pruebas realizadas.

La tercera parte contiene las conclusiones extraídas del proyecto y posibles


trabajos futuros.

Además, se incluye un apéndice con el documento que describe específicamente el


interfaz del SIR y sus parámetros. Por razones de internacionalización de la aplicación, este
documento se encuentra en inglés.

26
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

2 ESTADO DEL ARTE

27
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

2.1 Estado del arte

En esta parte de la memoria y antes de entrar en el desarrollo del proyecto


propiamente dicho vamos a entrar a describir con cierto detalle la situación actual del
sector en el momento en el que se escriben estas líneas. Mediante el estudio de otros
servicios de colaboración existentes podremos llegar a comprender muchas de las
decisiones tomadas a lo largo del proyecto.

2.1.1 Servicios de colaboración

Las herramientas que sirven como servicios de colaboración y de ayuda al trabajo


en equipo reciben el nombre de Groupware. Son servicios que ofrecen la posibilidad de
integrar el trabajo en un sólo proyecto con muchos usuarios concurrentes que se
encuentran en diversas estaciones de trabajo, conectadas a través de una red (internet o
intranet).

Podemos distinguir entre dos tipos de servicios de colaboración atendiendo a si la


comunicación entre los integrantes es de tipo síncrono o asíncrono.

2.1.1.1 Groupware asíncrono

Los servicios de colaboración asíncronos se basan en la comunicación no


simultánea entre sus miembros. El emisor se comunica con un receptor enviándole un
mensaje, en el caso asíncrono, la respuesta por parte del receptor no se produce de forma
inmediata sino que pasa un tiempo determinado hasta que se produce esta respuesta.

Las implicaciones que este tipo de comunicación tiene sobre el servicio de


colaboración son importantes. La interacción y concurrencia se ven limitadas por su
carácter asíncrono. La comunicación entre usuarios mediante este tipo de sistemas no es
inmediata y por tanto es más lenta, sin embargo, a cambio ofrece una mayor flexibilidad
en cuanto a presencia que la que ofrecen los sistemas síncronos.

29
2. ESTADO DEL ARTE Rafael García Marín

Sistemas asíncronos de colaboración pueden ser workspaces online (que permiten


compartir por ejemplo documentos, archivos, planificaciones de proyecto o calendarios),
herramientas de control de versiones (para proyectos en los que varias personas tienen
que manejar los mismos archivos) o incluso el e-mail.

2.1.1.2 Groupware síncrono

Al contrario que en el caso asíncrono, la comunicación se produce de forma


instantánea y concurrente. Las aplicaciones más utilizadas en este campo son las
herramientas de videoconferencia o mensajería instantánea.

Estas herramientas introducen un nuevo grado de colaboración: la interactividad


en tiempo real, gracias a ellas se consigue una mayor fluidez en el intercambio de
mensajes entre los participantes, que al ser síncrono, se adapta mucho mejor al lenguaje
natural que utilizamos los seres humanos.

Existen numerosas herramientas de videoconferencia o mensajería instantánea y


muchas de ellas forman ya parte de la vida cotidiana de las personas. Nombres de
aplicaciones como MSN Messenger, Skype o Google Talk son algunos de los más utilizados
hoy en día. En el caso concreto que nos ocupa, merece la pena detenerse ante dos
aplicaciones de videoconferencia y mensajería instantánea desarrolladas dentro del propio
Departamento de Ingeniería Telemática por su relación intrínseca con el presente
proyecto. Son las aplicaciones Isabel y Marte.

Isabel

ISABEL es una plataforma orientada al mundo empresarial y educativo optimizada


para interconectar grandes auditorios pero igualmente funcional para pequeñas
reuniones. Su gran ventaja competitiva es que funciona en ordenadores convencionales y
cualquier terminal ISABEL puede funcionar como cliente o servidor, lo que elimina la
necesidad de costosas MCU hardware.

30
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

Entre sus funciones, la más importante es la de montar reuniones, conferencias o


clases con participantes remotos. Soporta una gran cantidad de modos de interacción, lo
que permite cubrir exactamente las necesidades de cada momento, videochat entre
participantes, modos de presentaciones, cuestiones remotas, resaltar algún participante,
modos pregunta-respuesta…

Figura 1: Captura de Isabel

La aplicación SIR permite desde su primera versión definir una sesión de Isabel
cualquiera vía Web, reservando además las máquinas adecuadas, arrancando Isabel en
esas máquinas automáticamente cuando llega la hora de la sesión y parándola cuando
acaba dicha sesión.

Marte

Marte es un cliente avanzado SIP desarrollado por el Departamento de Ingeniería


de Sistemas Telemáticos. Permite crear multiconferencias con chat, audio, video, VNC y
pizarra. Además, posibilita tener un servicio de presencia con lista de contactos, de tal
manera que se pueda saber si otro usuario está registrado en el servidor Marte y se pueda
establecer una conferencia con él.

31
2. ESTADO DEL ARTE Rafael García Marín

Figura 2: Captura de Marte

La última versión de esta aplicación está hecha usando un cliente Flex. Esto
permite la integración junto con otras aplicaciones y forma parte del contexto de reunión
de distintas herramientas bajo el mismo marco.

2.1.1.3 Suites de Groupware integrado

Un tercer tipo de Groupware son las aplicaciones de gestión del trabajo


colaborativo. Con frecuencia este tipo de herramientas contienen tanto aplicaciones para
comunicación síncrona como asíncrona, y además permiten gestionar las actividades del
grupo, calendarios electrónicos, sistemas de gestión de proyectos, control de flujo de
actividad, gestión del conocimiento o sistemas de soporte a las redes sociales.

Lotus

Lotus es una herramienta integrada de Lotus Software (filial de IBM) que está
compuesta por varias aplicaciones para gestión del trabajo colaborativo. Es una aplicación
muy utilizada por empresas de todo el mundo. Se trata de un sistema cliente – servidor (la

32
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

parte servidor recibe el nombre de Domino, la parte cliente es Notes). Permite enviar
correos electrónicos, manejar calendarios y agendas, compartir bases de datos de
información ya sean documentos, manuales o foros de discusión, y también sirve de
plataforma de coordinación con flujos de trabajo (workflows).

Figura 3 : Logotipo de Lotus Notes

Las aplicaciones de Domino pueden ser accedidas mediante Notes o también


mediante un navegador web.

Figura 4: Logotipo de Lotus Connections

Para actualizar Lotus al nuevo contexto de redes sociales y a la vez hacerlas


compatibles con los entornos de empresa corporativos, en IBM se ha desarrollado un
nuevo producto, Lotus Connections. Aúna todas las funcionalidades que ofrece el resto de
programas de la suite de Lotus, pero a la vez añade características de las redes sociales,
especialmente buscando una eficiente gestión del conocimiento de los empleados de las
empresas. Ofrece soporte para la creación de Blogs y un sistema de compartición de
enlaces (bookmarks).

33
2. ESTADO DEL ARTE Rafael García Marín

BSCW

BSCW es un entorno telemático para la colaboración basado en espacios


compartidos de trabajo. Está desarrollado por la Fraunhofer Society. Las siglas
corresponden a Basic Support for Cooperative Work (Soporte básico para trabajo
cooperativo). Es comercial pero proporcionan licencias gratuitas para fines educativos.

Figura 5: Logo de BSCW

El cliente tan sólo necesita un navegador web para poder utilizarlo.

Open-Xchange

Open-Xchange Server es un sistema de mensajeria y trabajo colaborativo. Existen


dos versiones de este producto: la versión comercial (software propietario) y la versión
open-source. (1)

Figura 6: Logo de Open-Xchange

Está diseñado para pequeñas organizaciones. La Express Edition (open source)


incluye sistema operativo Ubuntu, middleware open source, sistemas de trabajo
colaborativo, e-mail, software para compartición de documentos, anti-virus, anti-spam y
un sistema de backup y recuperación.

34
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

La versión propietaria (Open-Xchange Server 5) ofrece funciones criticas de


colaboración, además del email, ofrece calendario, contactos, gestión de tareas -
totalmente integrado con opciones como base de datos documental, enlaces, gestión de
permisos, proyectos, foros y base de datos de conocimiento.

EGroupWare

EGroupware es una suite de programas libres que permiten la gestión de


contactos, citasy tareas. También es un servidor de trabajo en grupo.

Figura 7 :Logo de eGroupWare

EGroupware es un servidor de trabajo en grupo. Viene con una interfaz web nativa
que permite el acceso a los datos desde varias plataformas. También permite elegir un
cliente para acceder a los datos del servidor (Kontact, Evolution, Outlook) y también
mediante teléfono móvil o PDA mediante SyncML.

2.1.2 La aplicación SIR

2.1.2.1 El precursor: MIR

La aplicación MIR es la primera versión de la aplicación SIR, el cual es la base de


este proyecto fin de carrera. MIR es una aplicación creada por Enrique Barra Arias como su
proyecto fin de carrera. (2)

35
2. ESTADO DEL ARTE Rafael García Marín

MIR quiere decir Management of Isabel Reservations. Su primera misión (para la


que la aplicación fue creada inicialmente) es levantar automáticamente sesiones de la
aplicación de videoconferencias ISABEL. Para ello, en su primera versión, SIR consistía en
un interfaz web mediante el cual un usuario podía registrarse y accedía a un calendario
donde podía ver cuáles eran los próximos eventos en ISABEL y reservar los suyos propios.
Para ello, el SIR gestiona las máquinas disponibles con software ISABEL y un usuario con
acceso a ellas podía reservarlas en un horario determinado siempre cuando las máquinas
estuvieran libres en ese intervalo de tiempo. Además, el usuario puede especificar cuáles
son los parámetros relevantes de la sesión (ancho de banda, tipo de sesión ya sea clase,
reunión o conferencia, número de sitios conectados) y también definir la topología de
conexión.

Con esta información, la aplicación generaba un fichero XEDL con la definición


completa de la sesión y con ese archivo, el servicio StartConference de Isabel arrancaba la
sesión en todas las máquinas participantes especificadas.

Figura 8: Captura de pantalla de la aplicación MIR

La aplicación se creó siguiendo una infraestructura MVC (modelo-vista-


controlador) con el lenguaje Ruby on Rails. Más adelante explicaremos más
detalladamente en qué consisten estos conceptos.

La aplicación MIR como se puede ver no es más que una herramienta para
gestionar las sesiones de la aplicación ISABEL. Sin embargo, su versión posterior, la

36
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

llamada SIR, introduce una serie de cambios en su filosofía y funcionalidad que


transforman por completo el paradigma contextual de la aplicación.

2.1.2.2 El nuevo concepto: SIR

Con el objetivo de actualizar la aplicación MIR al nuevo paradigma existente


basado en redes sociales y también para dotarlo de funciones de Groupware para gestión
de trabajo colaborativo, surge SIR.

SIR conserva la funcionalidad original de MIR consistente en levantar sesiones de


ISABEL. A esta funcionalidad se le añaden los siguientes conceptos:

Usuario: El usuario pasa de crear sesiones de ISABEL a formar parte de una


comunidad en la que no sólo se gestionan eventos, sino que se trabaja
colaborativamente siguiendo la visión del Groupware, se comparte
información, se intercambian mensajes, se clasifican los contenidos o se
forman grupos de trabajo, listas de correo…

Espacio: Se crean lugares virtuales que funcionan como contenedores de


información. Estos espacios aglutinan todo lo referente a un determinado tema
escogido por un usuario. De esta forma, un usuario que trabaja en un
determinado proyecto o tarea concreta puede crear un espacio en el que
invitar a otros usuarios, y dentro de ese espacio compartir toda la información
referente al trabajo en común, comunicarse, administrar eventos, llevar una
agenda con fechas relevantes sobre el tema…

Artículos: En cada espacio existen contenidos, en primera aproximación estos


contenidos son de tipo texto. Un usuario con los permisos adecuados puede
escribir un mensaje en un determinado espacio al que pertenezca y los
usuarios pertenecientes a dicho espacio pueden ver el contenido de este
artículo. Además, otro usuario puede contestar este mensaje y formar un árbol
de mensajes, dando lugar a lo que denominamos “foro”.

37
2. ESTADO DEL ARTE Rafael García Marín

Attachments: Junto a los mensajes textuales, un usuario puede añadir


documentos. Estos documentos adheridos a un texto concreto reciben el
nombre de Attachments. Un usuario que añada un attachment a su mensaje,
está añadiendo una información en forma de bytes que se guardan en la base
de datos del SIR y será accesible a los demás usuarios en función de los
permisos que éstos tengan.

Documentos: Además de los attachments asociados a un mensaje o hilo de


mensajes concreto, tiene sentido que exista un repositorio de documentos
entendido como un lugar virtual en el que se guardan distintos tipos de
archivos que son comunes al espacio y a los miembros que pertenecen a él.
Estos archivos se organizarán de forma jerárquica y atendiendo a un sistema de
etiquetado de la información categorizando cada archivo con una serie de
palabras clave relacionadas.

Tags: Cada contenido en el SIR tendrá unas palabras clave asociadas. Éstas
reciben el nombre de tags. Con una filosofía muy característica del movimiento
de las redes sociales, los tags se enlazan con la información que los contiene, y
se pueden crear las llamadas nubes de tags, que son simplemente numerosos
tags que aparecen en la pantalla con un tamaño variable que depende del
número de veces que cada tag aparece en la aplicación. De esta manera, un tag
que aparece muchas veces en contenidos a lo largo de la aplicación, tendrá un
tamaño mayor en la nube de tags que otro tag que no aparezca tanto. Hay que
tener en cuenta que estos tags no son los mismos que las palabras clave que
categorizan a los archivos dentro del repositorio.

Agenda: Aunque el concepto de evento como tal ya existe en el MIR, la


aplicación SIR extiende este concepto no sólo para eventos de ISABEL sino para
eventos genéricos, y de esta forma se puede gestionar un calendario con
eventos que son relativos al espacio en el que el usuario se mueve en cada
momento.

38
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

Máquina: La aplicación MIR también incluye el concepto de Máquina


entendido como dispositivo capaz de participar en una sesión de ISABEL.
Puesto que la aplicación SIR mantiene la funcionalidad de su antecesor, este
concepto es extensible a esta nueva versión.

Figura 9: Captura de pantalla de la aplicación SIR

Para la consecución de estos objetivos de convertir el SIR en red social se usaron


gran variedad de plugins y gemas de Rails. El más importante de ellos es el CMS Plugin,
desarrollado conjuntamente con el SIR, y que pretende ser un módulo open source para
Rails con capacidad para crear aplicaciones de contenidos como el nuevo SIR.

39
2. ESTADO DEL ARTE Rafael García Marín

2.2 Tecnologías utilizadas para el desarrollo

2.2.1 Ruby on Rails

Ruby on Rails es un framework opensource para la creación de aplicaciones web.


Normalmente nos referimos a él simplemente como “Rails” o “RoR”. Su existencia va
unida al uso de la Metodología Ágil como forma de desarrollo y programación. Su
importancia radica en la gran capacidad y rapidez que ofrece para la creación de proyectos
basados en aplicaciones cliente.

2.2.1.1 El lenguaje de programación Ruby

Ruby es un lenguaje de programación orientado a objetos. Combina la sintaxis


inspirada en Perl con características de SmallTalk. Se creó en Japón a mediados de los
noventa y fue inicialmente diseñado y desarrollado por Yukihiro Matsumoto.

Figura 10: Logo de Ruby

Es un lenguaje que nos podemos encontrar en múltiples paradigmas de


programación. En su implementación oficial está escrita en C, Ruby es un lenguaje
interpretado (es decir, no se compila). Ahora mismo existen numerosas alternativas a la
implementación original de Ruby, algunas de ellas son JRuby, Rubinius, IronRuby, YARV…

En propias palabras de su creador, Ruby está diseñado para conseguir mayor


productividad y a la vez diversión siguiendo los principios de un buen diseño de interfaz de

40
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

usuario. Se enfatiza el hecho de que los sistemas deberían hacer hincapié en las
necesidades del hombre más que en las de la máquina. De hecho Matsumoto afirma que
su primer objetivo en cuanto al diseño de Ruby era crear un lenguaje que él mismo
disfrutara usando, minimizando el trabajo del programador y las confusiones posibles.

Entre las grandes ventajas del lenguaje, destacar su flexibilidad para funcionar en
múltiples paradigmas. Actualmente su gran difusión se debe a la creación del framework
Rails para la creación de aplicaciones web.

Ruby utiliza un sistema propio para gestionar paquetes que provee un formato
estándar para distribuir programas escritos en Ruby y librerías. El formato en el que se los
programas son contenidos recibe el nombre de “gema” (gem). La herramienta que
gestiona estas gemas es RubyGems. Actualmente, es parte de la versión estándar 1.9 de
Ruby. El framework Rails se instala como una gema, al igual que muchas otras
herramientas utilizadas en el desarrollo del presente proyecto.

2.2.1.2 El framework Rails

Rails se extrajo del trabajo de David Heinemeier Hansson sobre una herramienta
de gestión de proyectos, actualmente una aplicación web llamada 37signals. David lanzó
Rails como opensource en Julio de 2004.

Figura 11 : Logo de Rails

Está basado en la arquitectura MVC (Modelo-Vista-Controlador), muy utilizada


actualmente para organizar la programación de aplicaciones. Provee varias herramientas

41
2. ESTADO DEL ARTE Rafael García Marín

con la intención de conseguir un desarrollo de aplicaciones de la forma más sencilla


posible. Tiene una herramienta de scaffolding (andamiaje) que construye de forma
automática tanto modelos como vistas o controladores para un sitio web básico. El
paquete básico también incluye un servidor Ruby muy simple llamado Webrick y un
sistema “make” llamado Rake. Con la inclusión de estas herramientas, se provee un
entorno básico de desarrollo que viene con todas las versiones del software.

En las primeras versiones de Rails, se utilizaba SOAP como web services ligero. Con
la llegada de la versión 2.0 (en el momento de la escritura de estas líneas la última versión
de Rails es la 2.1.1) se reemplazaron estos servicios SOAP por los RESTful Web Services.
También se ofrece desde esta versión 2.0 salidas de la aplicación tanto HTML como XML
por defecto. Esto implica gran facilidad para la creación de servicios web con REST.

Rails necesita un servidor web para funcionar. Como hemos dicho, viene de serie
con un servidor básico llamado Webrick, sin embargo es preferible usar otros para
entornos de producción. Los más utilizados son Mongrel, Lighttpd y Apache (con CGI,
FastCGI o mod_ruby).

El framework se compone principalmente de varios paquetes. Éstos son los que


forman Rails en sí mismo. Son ActiveRecord, ActiveResource, ActionPack, ActiveSupport y
ActionMailer. Además de estos paquetes estándar, se favorece especialmente el uso de
plugins por parte de los desarrolladores, así como la creación de plugins propios. Esta
metodología de creación y uso de módulos ya desarrollados es parte de la filosofía
intrínseca de Rails.

Rails usa dos de los principios principales de la metodología ágil de programación.


Estos son “Convención sobre Configuración” (Convention Over Configuration, CoC) y “No
te repitas” (Don’t Repeat Yourself, DRY).

El primero de ellos (Coc) significa que un programador sólo debería especificar


aspectos no convencionales de una aplicación, es decir, que debería seguir las
convenciones ya escritas para evitar tener que hacer código que de otra forma ya está
hecho para él. Por ejemplo, Rails usa un sistema de convenciones para nombres de clases
de modelos y controladores. Si se sigue este convenio, las relaciones entre Base de Datos-
Modelo-Controlador-Vista ya están automáticamente implementadas gracias al
framework. Si no se sigue este convenio, el programador deberá escribir código para

42
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

describir estas relaciones que de otra manera no tendría que haber hecho. Todo el
framework Rails se basa en este hecho. Por lo tanto, un programador experimentado y
conocedor de todos los convenios de Rails es capaz de programar aplicaciones con gran
rapidez y agilidad. Esto puede ser un impedimento al principio para un desarrollador
nuevo en el lenguaje, pero es una gran recompensa para los programadores que aprenden
el framework.

El segundo de los principios (DRY) implica que la información debería localizarse en


un único lugar evitando cualquier tipo de ambigüedades. Este principio es fundamental
para evitar repetir código de forma inútil. Rails aboga por la reutilización y por la
convención. Por ejemplo, usando el módulo ActiveRecord de Rails, un programador no
necesita especificar columnas de una base de datos en las definiciones de una clase, en vez
de ello, Rails obtiene la información directamente de la base de datos. El hacer lo contrario
sólo llevaría a ambigüedades y a repetir código, aumentando el trabajo realizado y el
tiempo invertido.

Otra ventaja de Rails es que permite definir el entorno de desarrollo en el que nos
encontramos. Estos entornos son desarrollo, producción y pruebas. En el primer entorno,
pensado para las tareas de desarrollo de la aplicación propiamente dichas, todas las clases
se recargan con cada petición para reflejar cualquier cambio que se acabe de realizar y así
no tener que abrir un servidor nuevo para probar cada cambio del código. Además, si la
aplicación falla por alguna razón, se renderiza una pantalla con el error ocurrido, la línea
donde ha saltado y varios parámetros de interés. En el modo de producción, pensado para
cuando la aplicación se está usando una vez terminado el desarrollo, las clases no se
recargan con cada petición, y si hay algún error no se renderizan los parámetros en claro,
si no que se lanza una pantalla por defecto en la que se insta al usuario a esperar
pacientemente porque algún error ha ocurrido. Para encontrar el error en ese caso habría
que mirar los logs de la aplicación. El último entorno está pensando para correr los tests
que se realicen en la aplicación. Para cada entorno de la aplicación se utiliza una base de
datos diferente, con un nombre que se pone siguiendo las convenciones de Rails.

En la actualidad Rails parece una gran alternativa de futuro para el desarrollo de


aplicaciones web. Además, cuenta con una comunidad muy activa que actualiza el
framework y que aporta nuevas funcionalidades con gran regularidad y frecuencia.

43
2. ESTADO DEL ARTE Rafael García Marín

2.2.2 RESTful Web Services

El término REST aparece por primera vez en la tesis doctoral de Roy Fielding
describiendo un nuevo estilo de arquitectura para sistemas en red. REST es un acrónimo
que quiere decir Transferencia de Estado Representacional (Representational State
Transfer).

Esto es lo que Roy Fielding explicaba sobre el significado de Representational State


Transfer:

“REST debería evocar una imagen de cómo las aplicaciones web bien diseñadas se
comportan: una red de páginas web (una máquina virtual de estados) donde el usuario
progresa a través de una aplicación mediante la selección de hipervínculos (transiciones de
estado) resultando en la página siguiente (que representa el siguiente estado de la
aplicación) siendo éste transferido al usuario y renderizado para su uso.” (3)

La web está compuesta de recursos. Un recurso es un objeto de interés para el


usuario. Por ejemplo, REST podría ser usado por un administrador para publicar contenido
sindicado. Periodicamente este administrador preparará una página web que tendrá
contenido y términos en XML que describirán dicho contenido. La gente que se suscriba a
dicho contenido sindicado sólo necesitarán conocer el URL (Uniform Resource Locator) de
la página donde el XML está localizado, leerlo con un navegador web, interpretar el
contenido usando la información del XML y reformatearlo para poder usarlo
apropiadamente (quizás en alguna forma de publicación online). El contenido sindicado
del que estamos hablando sería en este caso el recurso.

Para el acceso a los recursos, REST promulga la necesidad de tener URLs claros que
los identifiquen. Por ejemplo, si tuviéramos un avión Boeing 747 y quisiéramos acceder a
él, la compañía puede haber definido el recurso con la siguiente URL:

http://www.boeing.com/aircraft/747

Accediendo a este URL se nos devuelve una representación del recurso avión
Boeing 747 (por ejemplo, la página Boeing747.html). El resultado de pulsar en algún link
dentro de esta página es que vamos a acceder a otro recurso. Esta nueva representación

44
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

sitúa a la aplicación en un nuevo estado. De esta forma, la aplicación cliente cambia de


estado con cada representación de un recurso.

2.2.2.1 Motivación de REST

La motivación que llevó a la creación de REST es capturar las características de la


Web que hacen exitosa a la propia Web. De esta forma, REST es de alguna manera una
guía de estilo de cómo deberían ser las aplicaciones web “bien hechas”. Por lo tanto, las
características de REST se están usando para guiar la evolución de la Web.

Las características más importantes de REST son:

1. La clave para crear servicios web en una red REST (como el Web) es identificar
todas las entidades conceptuales que se quieran exponer como servicios.

2. Crear un URL para cada recurso. Los recursos deberían ser sustantivos, nunca
verbos. Por ejemplo, no se debería usar:
http://www.parts-depot.com/parts/getPart?id=00345
Hay que notar el verdo, getPart. En lugar de eso se debe usar un nombre:
http://www.parts-depot.com/parts/00345

3. Hay que categorizar los recursos de acuerdo a si los clientes quieren recibir una
representación del recurso, o si deben poder modificar o añadir un recurso. Para el
primer caso, los recursos deben ser accesibles por HTTP GET. Para el segundo caso,
los recursos deben ser accesibles por HTTP POST, PUT o DELETE.

4. Las representaciones de los recursos no deberían ser objetos aislados del exterior.
Es decir, hay que poner enlaces dentro de los recursos para acceder a otros
recursos de forma que los clientes puedan acceder a más información o para
obtener información relacionada con el recurso.

5. Todos los recursos accedidos por HTTP GET deberían evitar ser modificados en
cualquier caso. Esto es, mediante HTTP GET sólo se debe acceder a una

45
2. ESTADO DEL ARTE Rafael García Marín

representación del recurso, para modificar un recurso tenemos que usar los otros
métodos HTTP.

6. Se debe diseñar para revelar datos de forma gradual. No se debería entregar toda
la información dentro de un mismo documento de respuesta. Es mejor proveer
enlaces dentro del recurso para acceder a más detalles.

7. Se debe especificar el formato de los datos accedidos usando algún esquema. Para
aquellos servicios que requieran un POST o un PUT, además hay que proveer un
esquema para especificar el formato de la respuesta.

8. Hay que describir cómo se invocan los servicios ya sea usando un documento
WSDL o simplemente un documento HTML.

REST no es un estándar, es simplemente un estilo de arquitecturas web. Uno no


puede ceñirse a él de forma normativa ni usarlo como una regla. REST es más bien una
filosofía, se puede entender y diseñar servicios web con ese estilo. Sin embargo, a pesar de
no ser un estándar, sí que utiliza estándares, como HTTP, URL, representaciones de un
recurso (XML/HTML/GIF/JPEG), etc.

2.2.3 Atom

El nombre Atom aplica a un par de estándares que están relacionados entre sí. Son
el Atom Syndication Format y el Atom Publishing Protocol. El primero de ellos es un
lenguaje XML especialmente diseñado para ser usado en feeds web. El otro es un procolo
sencillo basado en HTTP para crear y actualizar recursos web.

2.2.3.1 Historia de Atom

Los sitios Web usan feeds para permitir que programas externos puedan
comprobar automáticamente si hay actualizaciones publicadas dentro del sitio web. Para

46
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

proveer un web feed, el dueño de un sitio debe usar un software especializado que
publique una lista (o “feed”) de artículos recientes o contenidos en un formato
estandarizado y legible por una máquina. Los feeds pueden ser descargados por sitios web
que sindiquen contenido desde el feed o por lectores de feeds que permiten a los usuarios
de internet suscribirse a los feeds y leer su contenido. Un feed puede contener entradas
(entries), que pueden ser títulos, textos completos, descripciones, resúmenes o enlaces al
contenido en un sitio web, así como metadatos asociados a las entradas o recursos.

Figura 12: Icono no oficial que indica existencia de feeds en la web

El formato Atom como formato para sindicación web se creó como alternativa a
RSS. Ben Trott fue uno de los creadores del formato que finalmente acabó siendo Atom. Él
pensaba que RSS debía arreglar algunos problemas que tenía. Puesto que el desarrollo de
RSS estaba congelado y en ningún caso habría compatibilidad retroactiva, habría muchas
ventajas en hacer un nuevo diseño desde cero. Se formó entonces el IETF Atom Publishing
Format and Protocol Workgroup con los fundadores del nuevo formato. El Atom
Syndication Format se publicó como un estándar propuesto por el IETF en la RFC 4287 (4)
(y el Atom Publishing Protocol en la RFC 5023). (5)

2.2.3.2 The Atom Syndication Format

Existirán dos tipos de documentos Atom: los Atom Feed Documents y los Atom
Entry Documents. Un Atom Feed Document es una representación de un Atom Feed,
incluyendo metadata sobre el feed y sobre algunas o todas las entradas que están
asociadas a él. Un Atom Feed Entry representa exactamente un único Atom Entry, fuera
del contexto de un Atom Feed.

47
2. ESTADO DEL ARTE Rafael García Marín

Cada una de las dos estructuras tiene un esquema parecido. Contienen una serie
de elementos obligatorios y opcionales. Tanto el Feed como el Entry tendrá una cabecera
que indicará el idioma del documento y varios namespaces asociados. Por defecto, el
namespace a utilizar en cualquier documento será el de Atom,
“http://www.w3.org/2005/Atom”. Este namespace contiene las reglas para todas las
construcciones que se utilizan en el Atom Syndication Format de forma básica. Sin
embargo, Atom es extensible y se pueden utilizar otros namespaces para ampliar las
definiciones de las construcciones y usar otras nuevas.

Concretamente en el SIR se utilizan varios namespaces además del básico de Atom.


Éstos son:

Atom Threading Extensions (6):


Es una extensión de Atom que permite expresar discusiones en forma de “threads” o
hilos de conversación dentro del contexto de Atom. De esta forma, con campos
como “in-reply-to” o “replies” podemos enlazar el entry que representa a un artículo
dentro del SIR con sus comentarios, y dichos comentarios con los artículos a los que
se refieren.

Google Data APIs (7):


Todos los campos básicos en cuanto a la implementación de mensajes, usuarios y
eventos principalmente se intentan mapear a los campos provistos por el
namespace de Atom. Aquellos que no tienen un equivalente en dicho namespace se
mapean en el SIR con los campos extraídos de los APIs de Google. Estas APIs se
conocen como GData. Su uso permite utilizar etiquetas equivalentes a las de
servicios como GMail o GCalendar y hará que datos del SIR extraídos mediante el
interfaz Atom sean compatibles con datos extraídos de las aplicaciones de Google.

SIR namespace:
Aún utilizando los namespaces de Atom y las extensiones de Threading y GData,
algunos de los campos de los recursos de SIR, debido a su peculiaridad programática
y a que cuando se escribió la aplicación no se pensó en integrarla con Atom, no se
pueden mapear. Esto implica que durante el diseño del interfaz Atom se tuvo que
tomar la decisión de crear un namespace propio para todos esos campos. El
namespace es “http://sir.dit.upm.es/schema”.

48
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

2.2.3.3 The Atom Publishing Protocol

A la vez que el Atom Syndication Protocol, se creó el Atom Publishing Protocol,


vulgarmente conocido como AtomPub. El protocolo soporta la creación de recursos web y
provee facilidades para uso de colecciones (conjuntos de recursos que se pueden manejar
como un todo en sí mismo o separando sus partes), servicios (descripción de colecciones) y
ediciones (creación, edición y borrado de recursos). De esta forma, si el Atom Syndication
Protocol nos permite hacer las operaciones de lectura de recursos dentro del contexto de
la web con RESTful Web Services, AtomPub nos permite hacer todas las operaciones de
escritura.

Realmente es un protocolo complementario a Atom Syndication Format. Mientras


que el primero se centra en describir cuáles son los campos obligatorios de un feed o un
entry y cuáles son opcionales, la RFC de AtomPub (RFC 5023) se centra más en describir a
nivel de red cuáles son los recursos y mensajes intercambiados entre un cliente y un
servidor utilizando Atom. De hecho, especifica concretamente cuáles son los mensajes que
se deben intercambiar en cada uno de los casos (ya sea edición, creación, borrado o
incluso lectura de un recurso, a pesar de que ésta última se define en el Atom Syndication
Protocol).

2.2.4 Flex

Aunque realmente no se use Flex en la realización de este proyecto fin de carrera,


el objetivo es crear un interfaz de aplicación tal que una arquitectura de vistas en Flex
pueda acceder a los recursos del SIR. Puesto que es Flex quien va a acceder a ese interfaz y
por tanto a los recursos, conviene también introducir brevemente esta tecnología.

Figura 13: Logo de Adobe Flex

49
2. ESTADO DEL ARTE Rafael García Marín

Flex es una colección de tecnologías desarrolladas por Adobe Systems para el


desarrollo y el despliegue de aplicaciones multiplataforma enriquecidas de internet (Rich
Internet Applications) basadas en Adobe Flash. Su principal característica es su gran
capacidad y facilidad que ofrece para desarrollar interfaces gráficos de usuario muy
potentes gracias al lenguaje ActionScript (núcleo de Flash Player) y los MXML (un lenguaje
basado en XML).

Los programadores tradicionales de aplicaciones ven como un desafío adaptar la


metáfora de la animación sobre la plataforma con la cual fue originalmente construido
Flash. Flex minimiza elegantemente este problema proveyendo un flujo de trabajo y un
modelo de programación que es familiar a los desarrolladores de aplicaciones.

Flex fue inicialmente liberado como una aplicación de la J2EE o librería de


etiquetas JSP que compilara el lenguaje de marcas Flex (MXML) y ejecutara mediante
ActionScript aplicaciones Flash (archivos SWF binarios). Versiones posteriores de Flex
soportan la creación de archivos estáticos que son compilados, y que pueden ser
distribuidos en línea sin la necesidad de tener una licencia de servidor.

En un modelo multicapa como es el caso que nos ocupa, la aplicación Flex servirá
de capa de presentación. Al contrario que las páginas basadas en HTML, las aplicaciones
en Flex proveen un cliente basado en estados que no requiere recargar nuevas páginas.
Flex utilizará HTTPRequests para acceder a los recursos del SIR usando el paradigma de los
RESTful Web Services.

50
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

3 MEMORIA

51
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

3.1 Análisis del problema

Antes de abordar un proyecto de programación, es fundamental decidir qué tipo


de metodología de programación se va a seguir. Normalmente se suelen escoger modelos
clásicos y teóricos, como el ciclo de vida en cascada, que se basa es la consecución de una
serie de fases. A priori, suele ser una opción válida, pues la lógica nos dice que es un
modelo en cierto modo ideal. En primer lugar se hace un análisis exhaustivo de los
requisitos, es decir, se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir. Tras esta fase se afronta el diseño del sistema, se
descompone y organiza la arquitectura en elementos que puedan elaborarse por separado
para poder afrontar el proyecto en equipo. Después está la fase de implementación, que
es la fase de programación propiamente dicha. Una vez finalizado el proceso de
implementación, viene la fase de pruebas, en la que se comprueba que funcionan todos
los sistemas correctamente, y si todo es correcto se pasa a la fase de mantenimiento, que
es aquella en la que el software ya se encuentra en producción, y se realizan tareas de
mantenimiento sobre el sistema.

Efectivamente es un modelo válido para proyectos clásicos de ingeniería del


software. En este caso sin embargo es un modelo que no nos sirve. En primer lugar, al
comienzo del proyecto nos encontramos con un software que está hecho a medias, y
sobre el cual vamos a realizar un refactoring exhaustivo para mantener la funcionalidad
pero cambiando la arquitectura de los métodos y los interfaces siguiendo un modelo de
RESTful Web Services. Después, sobre este nuevo esquema de métodos, se va a construir
un interfaz en Atom. Finalmente se van a introducir nuevas funcionalidades conforme los
requisitos de los usuarios finales van cambiando, y todo ello debe ir acompañado de las
pruebas correspondientes para comprobar que todo el código funciona y prevenir que
cualquier cambio en el código por parte de cualquiera de los miembros del equipo de
programación no destruye funcionalidades ya implementadas y en funcionamiento.

53
3. MEMORIA Rafael García Marín

Figura 14: Ciclo de vida en cascada

En esta situación se hace evidente que los modelos clásicos de programación no


son válidos. Existen otros modelos basados en el ciclo de vida en cascada, que se acercan
algo más a lo que podríamos necesitar. Es interesante en este caso el ciclo de vida en
espiral, que se caracteriza porque sus actividades se pueden representar como una espiral
en la que cada bucle representa el ciclo de vida completo (lineal) de un proyecto de menor
envergadura, en el que al final de cada bucle se obtiene un prototipo y en la siguiente
iteración se empieza a desarrollar sobre ese prototipo.

Figura 15: Ciclo de vida en espiral

54
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

Debido a que los requisitos son muy cambiantes y a veces incluso pueden llegar a
ser contradictorios entre sí, la metodología en espiral sigue siendo demasiado rígida para
este caso concreto. Finalmente se decidió usar un modelo que es idóneo para nuestras
necesidades gracias a lo flexible y permisivo que es. Se trata de la Metodología Ágil de
Programación.

3.1.1 Metodología Ágil

La Metodología Ágil es un nuevo paradigma de desarrollo software basado en


procesos ágiles. Estos procesos ágiles (conocidos anteriormente como metodologías
livianas) intentan evitar los problemas de rigidez y excesiva burocracia de las metodologías
tradiciones enfocándose más en las personas y en los resultados de su trabajo.

En este marco conceptual, se promueven iteraciones a lo largo de todo el ciclo de


vida del proyecto. Estas iteraciones consisten en desarrollar pequeñas partes del software,
que responden a funcionalidades concretas, en cortos lapsos de tiempo (con duraciones
en torno a una a cuatro semanas). Cada iteración concreta constituye todo un ciclo de vida
en sí misma, incluyendo planificación, análisis de requerimientos, diseño, codificación,
revisión y documentación. Cada una de estas iteraciones no debe añadir demasiada
funcionalidad como para justificar el lanzamiento del software al mercado. El objetivo es
poder hacer demostraciones al cliente al final de cada iteración. De hecho cada iteración
debería ser una funcionalidad concreta del producto final, integrada en él, y la
demostración sería una visión del producto con la nueva funcionalidad integrada, para que
el cliente o el usuario final pueda hacerse una visión global de hacia dónde se encamina el
proyecto. Así, al final de cada iteración, el equipo evalúa de nuevo las prioridades del
proyecto, teniendo en cuenta especialmente los comentarios del cliente, que
generalmente no tiene muy claros cuáles son los requisitos concretos ni la funcionalidad
específica que está buscando.

En la metodología ágil se pone especial énfasis en la importancia de las


comunicaciones directas en vez de la documentación con procesos predefinidos. Para ello
generalmente los equipos de programación que utilizan estas metodologías se encuentran
localizados en un mismo lugar. Además, se enfatiza que el software funcional es la primera
medida de que todo va bien. Con frecuencia, este hecho unido a la falta de documentación
técnica hace que los métodos ágiles sean tachados de “indisciplinados”.

55
3. MEMORIA Rafael García Marín

En marzo de 2001 diecisiete críticos de los modelos de mejora del desarrollo de


software basados en procesos se reunieron para tratar sobre técnicas y procesos para
desarrollar software. Los integrantes de la reunión resumieron los principios sobre los que
se basan los métodos alternativos en cuatro postulados, lo que ha quedado denominado
como Manifiesto Ágil. Este manifiesto se basa en cuatro valores:

Valorar más a los individuos y su interacción que a los procesos y las herramientas

Valorar más el software que funciona que la documentación exhaustiva

Valorar más la colaboración con el cliente que la negociación contractual

Valorar más la respuesta al cambio que el seguimiento de un plan

Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los
principios que de ellos se derivan: (8)

Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana


y continua de software de valor.
Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los
procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
Entregar con frecuencia software que funcione, en periodos de un par de semanas
hasta un par de meses, con preferencia en los periodos breves.
Las personas del negocio y los desarrolladores deben trabajar juntos de forma
cotidiana a través del proyecto.
Construcción de proyectos en torno a individuos motivados, dándoles la
oportunidad y el respaldo que necesitan y procurándoles confianza para que
realicen la tarea.
La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro
de un equipo de desarrollo es mediante la conversación cara a cara.
El software que funciona es la principal medida del progreso.
Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,
desarrolladores y usuarios deben mantener un ritmo constante de forma
indefinida.
La atención continua a la excelencia técnica enaltece la agilidad.

56
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es


esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-
organizan.
En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y
ajusta su conducta en consecuencia.

3.1.2 Viabilidad

Con estas prerrogativas, la metodología ágil se antoja idónea para el desarrollo del
proyecto. De hecho, uno de los requisitos de entrada es la imposición sobre la utilización
de Ruby on Rails como lenguaje de programación puesto que la aplicación sobre la que
trabajamos está realizada en dicho lenguaje. Este hecho encaja perfectamente con la
decisión ya que la filosofía de Ruby on Rails se basa en el uso de metodologías ágiles, y por
eso es uno de los lenguajes preferidos por los desarrolladores de aplicaciones web que se
adscriben a estas metodologías de desarrollo.

Como se ha visto además a lo largo del proyecto, los requisitos han ido cambiando
en el tiempo. Incluso, la aplicación se destina a varios propósitos distintos y la intención es
hacer converger todas las situaciones y conseguir unos requisitos comunes a todos los
escenarios de forma que la misma aplicación pueda funcionar como solución en todos los
casos. Esto efectivamente es un gran problema a la hora de diseñar e implementar y en
gran medida, la adopción de la metodología ágil ha servido positivamente para afrontar
este complejo problema.

3.2 Arquitectura del sistema

3.2.1 La arquitectura MVC

La arquitectura de la aplicación en cuanto al modelo de datos y la lógica de sus


componentes sigue la estructura conocida como MVC (Modelo Vista Controlador). Rails
está preparado para que todas las aplicaciones creadas con el framework sigan esta

57
3. MEMORIA Rafael García Marín

estructura de forma prácticamente automática. Esta estructura, como su nombre indica,


se basa en tres componentes principales.

El Modelo es el responsable de mantener el estado de la aplicación. En ocasiones


este estado es transitorio, siendo válido solamente durante pocas interacciones con el
usuario. Otras veces este estado es permanente y debe ser guardado fuera de la
aplicación, en una base de datos. En cierto sentido es el modelo el que describe cómo son
los datos en la base de datos, pero no solamente eso. También está encargado de describir
todas las reglas que definen esos datos, así como validaciones o métodos concretos
inherentes a los datos que representa.

La Vista se encarga de generar el interfaz de usuario, normalmente basado en


datos del modelo. En una aplicación Rails convencional, estas vistas serán archivos en
formato HTML. Es la vista por tanto la que se encarga de presentar los datos al usuario, así
como interaccionar con él en el caso de que sea el usuario el que debe entregar datos a la
aplicación, como en el caso de los formularios.

El Controlador es la pieza que se encuentra entre el Modelo y la Vista. Se encarga


de recibir las llamadas del usuario, llamar al Modelo correspondiente, recoger los datos
que envía y llevarlos a la Vista para su presentación.

Figura 16: Esquema de relaciones entre modelo, vista y controlador

58
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

El framework de Rails provee automáticamente la estructura MVC para la


aplicación, generando todos los componentes y conectándolos adecuadamente entre sí.
Sin embargo, el caso que nos ocupa es un poco distinto. Como requisito de entrada, el
componente de la Vista va a ser sustituido por una aplicación en Flex. De esta forma, el
Controlador debe ser capaz de enviar los datos que recibe del Modelo no sólo hacia los
componentes en HTML, sino a la aplicación Flex.

Figura 17: Esquema de una arquitectura Web con Rails y Flex

59
3. MEMORIA Rafael García Marín

La conexión entre los lados Flex y Rails se hace mediante los métodos del interfaz
de aplicación siguiendo la filosofía de los RESTful Web Services. Las vistas en Flex harán
peticiones a la aplicación Rails, que devolverá un resultado, y la parte Flex se encargará de
su presentación al usuario, al igual que hacían las vistas en HTML, pero con mayor
complejidad. Flex permite hacer aplicaciones web de gran complejidad, no solo la simple
presentación de datos con un interfaz de usuario. Es por ello que realmente, el lado Flex es
una aplicación en sí misma que utiliza el lado Rails como un recubrimiento de la base de
datos. Así, las dos partes se pueden considerar como una sola aplicación en sí mismas por
separado, y a la vez una aplicación completa cuando interactúan.

Normalmente, esta comunicación de recursos entre la parte Flex y la parte Rails


se hace mediante objetos en XML. Como parte del proyecto y para ir más allá en la
funcionalidad de la aplicación, se decidió utilizar Atom (que es un caso concreto de
XML) en vez del XML básico. Así, escogiendo adecuadamente los espacios de nombres
utilizados por Atom, la aplicación será compatible con otras aplicaciones de internet
que usan dicho interfaz y dichos espacios de nombres. Éste es el caso de las
aplicaciones de Google.

Con esta arquitectura, las comunicaciones entre ambos lados se basan en un


intercambio de paquetes HTTP con contenido en Atom. Por ejemplo, cuando el cliente en
Flex quiere información sobre un recurso, realiza una petición HTTP GET con la URL del
recurso en concreto a la parte Rails, y ésta devuelve un documento en Atom con todos los
datos sobre el recurso.

60
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

Figura 18: Arquitectura de una aplicación Web con Rails y Flex con un interfaz Atom

3.2.2 Recursos del sistema

Antes de comenzar el desarrollo del proyecto en sí, es importante describir


exactamente la estructura de recursos de la aplicación y cómo se relacionan entre ellos. Es
fundamental saber cuáles son los recursos que tiene el SIR pues es la información concreta
a la que el cliente Flex va a acceder.

61
3. MEMORIA Rafael García Marín

Los recursos que existen actualmente en el SIR son los siguientes:

Usuarios (users)
Espacios (spaces)
Grupos (groups)
Entradas (entries)
Artículos (articles)
Attachments (attachments)
Eventos (events)
Roles (roles)
Performances (performances)
Máquinas (machines)
Tags (tags)

Según la filosofía REST, todos los recursos son accesibles mediante URLs únicos que
los identifican. Mediante estas URLs se podrán leer, crear, editar o borrar los recursos. Lo
importante teniendo en cuenta esto, es la lógica que existe entre los distintos recursos.

En un primer plano, y como centro de toda la aplicación están los usuarios. Los
usuarios tendrán acceso a una serie de espacios de los que serán miembros, y tendrán
unos roles asociados a ellos. Los espacios son lugares donde se lleva a cabo la actividad
propiamente dicha, en ellos están contenidas las entradas. Las entradas son una clase
general de contenidos, que, de forma más concreta, pueden tomar la forma de artículos
(artículos padre o comentarios), attachments o eventos. Los roles son conjuntos de
permisos sobre las entradas. De esta forma, se crean ternas relacionando usuarios,
espacios y roles. Son las llamadas performances. Explicándolo de forma sencilla, las
performances indican quién puede hacer qué, dónde.

En un segundo plano tendremos los recursos máquinas, tags y grupos. Las


máquinas representan a los ordenadores que forman la red de una sesión de
videoconferencia en Isabel. Cada usuario tiene una serie de máquinas asignadas y sólo
podrá crear un evento de Isabel si tiene asignadas las máquinas suficientes y éstas están
disponibles en toda la duración del evento. Los tags son palabras clave que se asignan a
cada entrada (ya sea evento, artículo o attachment). Estas palabras clave sirven para
categorizar las distintas entradas y proporcionar una búsqueda rápida basada en estas
palabras clave. Aparecerá en la aplicación una “nube de tags” con distintas palabras clave

62
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

que aparecen en función del número de veces que las hayan utilizado. Por último, los
grupos son conjuntos de usuarios dentro de un espacio. Estos grupos sirven como listas de
correo.

Cada uno de los recursos tendrá un interfaz CRUD asociado (Create, Read, Update,
Delete) tal y como manda el paradigma de los RESTful Web Services. Para el correcto
funcionamiento de la aplicación, estos interfaces ofrecen una serie de parámetros
concretos sobre cada recurso que son necesarios, tanto para operaciones de lectura como
de escritura, y que si no se manipulan adecuadamente, la comunicación entre los distintos
agentes (Rails y Flex en este caso) no es posible. La documentación exacta y exhaustiva de
los interfaces es también objeto del presente proyecto fin de carrera y se puede encontrar
en los Apéndices, ya que la información es demasiado técnica y densa como para incluirla
dentro de la memoria del proyecto.

3.3 Diseño e Implementación

En cuanto a la parte del proyecto dedicada estrictamente a la implementación,


podemos distinguir tres partes, una dedicada al refactoring para la consecución de un
interfaz de aplicación REST, una sobre el interfaz Atom, y una tercera dedicada a las
nuevas funcionalidades implementadas sobre el SIR.

3.3.1 Refactoring

Como primera parte de la implementación, se hizo un profundo estudio del código


del SIR tal y como se encontraba en ese momento. El propósito era reorganizar el código
de forma que no se perdiera ninguna funcionalidad, pero a la vez se pudiera afrontar el
diseño de un interfaz REST. El objetivo final era conseguir una serie de controladores que
ofrecieran de forma pública únicamente los métodos propios de un interfaz CRUD, estos
son: index, create, update, destroy y los preparadores de formularios new (para create) y
edit (para update). Para ayudar en lo posible a la lectura de esta parte de la memoria, se

63
3. MEMORIA Rafael García Marín

contará el proceso de forma resumida y se omitirán los nombres concretos de los métodos
tal y como estaban antiguamente, puesto que no tienen mucha relevancia.

Lo primero fue cambiar las rutas anidadas a espacios de toda la aplicación, que
antes se hacían de la forma /:container_type/:container_id/…, con parámetros (lo que van
con un prefijo formado por dos puntos) y esas ya no servían. Esto es principalmente
porque el CMSPlugin utilizaba antes rutas anidadas a contenedores de forma genérica. A la
vez que se hacía el refactoring del SIR, el plugin cambió estas rutas puesto que era
demasiado complicado tener rutas tan genéricas cuando al final realmente sobre lo único
que se anidaba como primer contenedor era sobre espacios. Por ello, se cambiaron a la
forma /spaces/:space_id/…. Con estas nuevas rutas no es necesario especificar el tipo de
contenedor, puesto que siempre es un espacio, y el parámetro id del contenedor pasa a
ser un id del espacio. Al principio como id se usó un parámetro numérico (id en la base de
datos) como identificador de los espacios. Más tarde esto se sustituyó por nombres de los
espacios completos. De esta forma, las rutas se hicieron inteligibles.

En segundo lugar, el controlador que se encarga de los espacios contenía toda la


lógica acerca de la administración de usuarios dentro del contexto de un espacio. Estos
métodos permitían añadir y quitar usuarios, que ya existían dentro de la aplicación, a un
espacio concreto. En una aplicación Rails con un interfaz REST, la gestión de todo lo
relativo a un usuario tiene lugar en el controlador de usuarios. Este controlador permite
añadir o borrar usuarios a la aplicación. Normalmente al hacer un create o un destroy,
crearemos o destruiremos un usuario en el contexto global de la aplicación. Para añadir un
usuario a un espacio, el controlador de usuarios debe reconocer por el URL, mediante el
cual se ha invocado el método concreto, que nos estamos refiriendo a la manipulación de
un usuario dentro del espacio. Por ejemplo, si hacemos un HTTP POST a la URL /users,
estamos creando un usuario dentro de la aplicación. Sin embargo, mediante un POST a la
URL /spaces/space_id/users estamos añadiendo el usuario al espacio concreto identificado
por el space_id. De esta forma, los métodos que antes estaban en el controlador de
espacios, se movieron al de usuarios, incluyéndolos dentro de los correspondientes (index,
create, update…) a su funcionalidad.

Después, el controlador de eventos (EventsController) contenía la lógica de


búsqueda de eventos. Esta lógica es trasladada a otro controlador, uno nuevo y específico
para las búsquedas, será el controlador SearchController. Además, en el controlador de
eventos existían varios métodos que no seguían la filosofía REST. Éstos básicamente

64
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

servían para realizar acciones con AJAX de forma que se enseñara información sobre cada
evento, pero sin llegar a recargar la página. Antes se llamaban directamente con la ruta y
cada método. Ahora, y siguiendo la arquitectura REST, esta lógica está incluida dentro de
los métodos correspondientes (por ejemplo, si se trata de leer información sobre un
evento concreto, se incluyó dentro del método show) y mediante el mecanismo de
respuesta al formato (el método respond_to) se llama a las vistas correspondientes de
AJAX. Esto quiere decir, por ejemplo, que si se hace una llamada a un método que
renderiza una vista con componentes javascript, en vez de llamar a ese método, la lógica
de renderizar esa vista concreta se incluye dentro del método REST correspondiente y la
llamada del método se traduce a una URL de REST añadiento el formato “.js”. El
respond_to se encarga de comprobar que efectivamente se trata de una llamada
javascript y renderiza la vista concreta. Esto no sólo sucede para las llamadas a métodos
de javascript, se produce también para llamadas a archivos con formatos como “.txt”,
“.ical” o “.xedl”. Algunos de ellos son formatos MIME estándar, otros se usan en la
aplicación ISABEL para gestión de sesiones de videoconferencia. En todos los casos se
procede de la misma forma, añadiendo el formato al respond_to y renderizando el
documento correspondiente en cada caso. Otros métodos del controlador de eventos que
no siguen la filosofía REST, no se han modificado puesto que sólo se usan para
funcionalidades muy concretas dentro de las vistas en HTML y no tiene sentido ofrecer su
funcionalidad en un interfaz para integración con otras aplicaciones. Estos son en su
mayoría, métodos de ayuda en formularios, como en el caso de los eventos, para
seleccionar varias fechas a la hora de crear un nuevo evento, para copiar la fecha de un
evento para la semana siguiente o funcionalidades similares.

En cuanto al controlador de usuarios, aparte de los métodos que se refieren a


información sobre usuarios anidados en un espacio que ya hemos comentado, también
existían métodos de búsquedas que se han trasladado al nuevo controlador de búsquedas.
Asociado al tema de los usuarios tenemos el controlador de perfiles (ProfileController). Las
acciones de este controlador no seguían en ningún caso la filosofía REST y se reescribió el
controlador usando los métodos de un interfaz en REST. Además, los perfiles se pueden
mostrar con microformatos como vcard y hcard. Estos métodos corresponden a llamadas a
show con el formato correspondiente (usando el respond_to como en el caso del
controlador de eventos).

El controlador que se encarga del recurso máquina (MachinesController) se


reescribió completamente por la misma razón, los métodos no seguían en ningún caso la

65
3. MEMORIA Rafael García Marín

filosofía REST. Además, el controlador incluía métodos que contenían lógica para el envío
de emails para pedir recursos al administrador del sistema. Estos métodos se movieron al
controlador que se encarga del envío de emails en el SIR.

Finalmente, el controlador de roles (RolesController) antiguamente se encargaba


de la funcionalidad sobre los grupos. Esto se borró completamente de dicho controlador y
se creó uno nuevo, GroupsController, con un interfaz CRUD completamente REST y
añadiendo la nueva lógica sobre grupos adscrita a nuevas funcionalidades sobre estos
recursos que se añadió al SIR.

3.3.2 El interfaz Atom

Una vez que el interfaz REST estaba completado, se procedió a construir las
terminaciones Atom de los métodos.

La base de la construcción del interfaz Atom nos la ofrece el CMSPlugin. Este plugin
es un módulo para Rails desarrollado por Antonio Tapiador del Dujo, dentro del
Departamento de Ingeniería Telemática, y que sirve de estructura principal para el SIR. El
plugin ofrece toda la funcionalidad necesaria para construir una aplicación CMS (Content
Management System o Sistema de Gestión de Contenido) incluyendo clases para
autenticación, creación y organización de tags, filtros de autorización o gestión de
contenidos y contenedores entre otras cosas. El plugin además incluye dentro de sí mismo
librerías de Ruby que son útiles en el desarrollo del SIR, la más importante y que nos ocupa
en este momento es la librería de atom-tools. Esta librería provee clases y métodos para
manipular objetos mapeando estructuras en Atom. Con estos métodos podemos construir
los feeds de Atom, y también podemos extraer parámetros de un feed de Atom que
recibamos en SIR (lo que vulgarmente se conoce como “parsear”).

Como hemos explicado previamente, hay dos partes funcionales del interfaz Atom,
una de lectura y otra de escritura. El interfaz de lectura es el que se refiere a los métodos
que se relacionan directamente con los métodos GET de HTTP. Éstos son el index y el show
en Rails. El index es un HTTP GET sobre la colección, nos da información sobre todos los
recursos. El show es un HTTP GET sobre el miembro, es decir, sólo nos da información
sobre un miembro concreto, por lo que se debe pasar un parámetro que identifica al

66
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

recurso o miembro concreto del que queremos información. Llamando a estos métodos
añadiendo “.atom” al URL, invocamos al interfaz en Atom, por lo que las respuestas que se
consiguen son documentos en formato Atom, en este caso y por ser de lectura, basados en
el protocolo Atom Syndication Format.

index show

Cliente Servidor Cliente Servidor

GET /resources.atom GET /resources/1.atom

resources.atom resources/1.atom

Figura 19: Esquema de secuencia de peticiones para los métodos de lectura index y show

Para construir un documento Atom, se crean unos archivos constructores,


similares a los que utiliza Rails para construir las vistas en HTML, pero constructores de
documentos Atom. Estos archivos constructores en Rails llevan una terminación específica
dependiendo de lo que construyan, incluyendo primero el nombre del formato que
construyen y después el nombre del constructor que utilizan para construirlo. Por ejemplo,
en el caso del constructor de HTML, la extensión del constructor es “.html.erb”, por lo que
la vista HTML de cada método será un archivo con el nombre del método y esa extensión
(para el método index, la vista será index.html.erb). En el caso del constructor de vistas
Atom, se utiliza la terminación “.atom.builder”. Estos constructores contienen lógica en
Ruby que construye los feeds o entries de Atom pero no de forma automática, sino que se
debe especificar exactamente su contenido.

De esta forma para cada recurso y cada método, se mapean todos los atributos de
los recursos y sus campos en la base de datos y con ellos se construye cada vista. Es
responsabilidad del programador el incluir los campos y tags XML concretos para
conseguir que los feeds y entries de Atom sean válidos siguiendo las especificaciones del
protocolo Atom Syndication Protocol. Por lo tanto, con estas prerrogativas se construyen
los archivos index.atom.builder y show.atom.builder para cada recurso, constructores de
feeds en el primer caso y entries en el segundo, teniendo cuidado que se cumple el
protocolo y comprobando en cada caso que el contenido sindicado entregado es válido

67
3. MEMORIA Rafael García Marín

según la RFC. Para ello se utilizó un servicio del W3C de validación de feeds de Atom
mediante web, introduciendo el resultado de cada llamada a métodos de lectura
directamente en dicha página. (9)

La otra parte del interfaz, la de escritura, es la que se refiere a los métodos “de
entrada” al SIR. Éstos son los métodos que se mapean con las llamadas POST, PUT y
DELETE de HTTP, es decir, los métodos create, update y destroy respectivamente. El
método create es un POST sobre la colección mientras que los métodos update y destroy
son un PUT y un DELETE respectivamente pero sobre un miembro concreto de la
colección. Además, los métodos create y update esperan un documento en Atom
conteniendo los parámetros de creación específicos de un recurso. El método destroy no
necesita ningún parámetro específico más que el parámetro identificativo del miembro al
que se refiere, pero en ningún caso hace falta incluir un documento en Atom junto con la
llamada. De hecho, el paquete HTTP con método DELETE no acepta contenido dentro de
su cuerpo.

create update

Cliente Servidor Cliente Servidor

POST /resources.atom PUT /resources/1.atom

resource/1.atom resources/1.atom

Figura 20: Esquema de secuencia de peticiones para los métodos de escritura, create y update

Para la parte funcional de escritura hay que construir la lógica que extrae
parámetros útiles de los documentos Atom que recibe el SIR. Esta funcionalidad nos la
ofrece el CMSPlugin, con métodos que proveen una arquitectura lógica entre clases para
poder recibir los datos de un documento en Atom y extraer su contenido. De esta forma,
en la clase correspondiente al modelo de cada recurso se debe añadir al comienzo el
comando set_params_from_atom. Esto llama a un método del plugin de forma que
cuando llega una llamada con contenido Atom, la aplicación lo detecta y manda
directamente el contenido del documento a un método de la clase del modelo
correspondiente. Este método es el atom_parser. Dentro de ese método se recogen los

68
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

datos que devuelve el plugin en forma de objeto REXML (objeto que recubre estructuras
en XML en lenguaje Ruby) . Estos objetos REXML contienen métodos para sacar los datos,
dependiendo del tag que los recubre y el namespace que contiene a cada tag. Al final de
ese método, se devuelve un array de parámetros (params[]) que es lo que recibe el
método correspondiente (create o update) con los datos necesarios. Este array de
parámetros es exactamente igual que los que generan los formularios en HTML. De hecho,
para definir cuáles son los parámetros que se debían enviar dentro de cada Atom, se
observó qué es lo que se enviaba en cada formulario de los métodos create y update para
cada tipo de recurso. Estos parámetros concretos están detallados dentro de la
documentación sobre el interfaz Atom que se incluye en los Apéndices de este libro.

Un caso especialmente interesante de cómo se crean recursos con Atom en el SIR


es el de un artículo que contiene un attachment. El interfaz HTML permite la creación de
un artículo que contiene un archivo adjuntado con una sola llamada HTTP. Puesto que
estamos hablando de dos recursos distintos, se contradice la filosofía REST. Puesto que el
interfaz Atom es completamente REST se siguen los siguientes pasos:

Primero el cliente crea el artículo enviando un POST a la dirección /articles.atom


con el documento en Atom que contiene todos los parámetros necesarios para su
creación.
La aplicación devuelve un documento en Atom con la descripción del artículo que
se acaba de crear, es importante en este caso que el cliente se haga con el id del
artículo pues será necesario más adelante.
Después, el cliente crea el attachment enviando un POST a la dirección
/attachments.atom con los datos del archivo en crudo.
La aplicación responde con un documento en Atom que representa al nuevo
attachment y con información sobre sus metadatos, además de un link con la
dirección a la que hay que enviar un PUT para editar los metadatos del
attachment.
El cliente debe entonces hacer un PUT a la dirección indicada en el link anterior,
con la información sobre los metadatos del attachment e indicando en el
parámetro parent_id el id del artículo.
Finalmente, la aplicación responde con un Atom renderizado del attachment
completo con sus metadatos ya actualizados.

69
3. MEMORIA Rafael García Marín

Artículos con
Attachments Servidor
Cliente

POST /articles.atom

article/1.atom

POST /attachments.atom (raw)

attachment/1.atom

POST /attachments.atom (metadata)

attachment/1.atom

Figura 21: Creación de Artículos con Attachments asociados

Por lo tanto, es responsabilidad de la aplicación cliente el proporcionar la lógica


adecuada para interaccionar correctamente con los servicios que ofrece el SIR y su
interfaz.

3.3.3 Nuevas funcionalidades

A la vez que se efectuaba la creación del interfaz REST y el interfaz Atom, se


implementaron algunas nuevas funcionalidades para el SIR.

Los grupos en el SIR se han implementado como nueva funcionalidad. Son


agrupaciones de usuarios dentro de un espacio. Además, funcionan como listas de correo
que contienen las direcciones de los usuarios adscritos al grupo. Cuando un nuevo espacio
se crea, a la vez se genera un nuevo grupo con el mismo nombre del espacio, y cada nuevo
miembro que entra al espacio se incluye automáticamente en este grupo por defecto. De
esta forma, se crea una lista de correo que existe siempre en cada espacio y que incluye a

70
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

todos sus miembros. Además de esto se pueden crear otros grupos con nuevas conjuntos
de usuarios del espacio.

Para desarrollar esta funcionalidad de listas de correo se utiliza el sistema del


servidor jungla del DIT. Este servidor tiene montado un mailman que mantiene todas las
listas de correo del departamento. Se ha implementado por tanto un sistema automático
que hace que el SIR cree listas de correo cada vez que se crea un grupo. Este sistema se
basa en callbacks de Rails dentro del modelo de grupos, de forma que después de cada
método de escritura (create, update, destroy) la aplicación se conecta al servidor jungla
mediante ssh y crea unos archivos de texto con las direcciones de todos los miembros del
grupo. A la vez, se crea un archivo con el nombre “vcc-ACTUALIZAR” que es el que utiliza el
proceso interno del servidor para reiniciar el sistema y actualizar las listas de correo y sus
miembros. Por lo tanto, la actualización de cambios en las listas no es automática, sino que
es un proceso síncrono del servidor y que es configurable por los administradores del
sistema de correo, externo al SIR.

En el siguiente diagrama vemos cómo se produciría este proceso, en el caso


concreto de un POST (create).

CUD sobre Grupos

Cliente Servidor de la Aplicación Servidor Jungla

POST /groups.atom
ssh touch vcc-ACTUALIZAR
group/1.atom
ssh touch vcc-groupname

Figura 22: Proceso de actualización de Grupos

Siempre que se llame a uno de los métodos Create, Update y Delete (CUD) sobre
Grupos, se producirán cambios en el servidor de jungla. Esta funcionalidad, debido a lo
delicado que resulta estar modificando un servidor externo que está dedicado a la
administración de listas de correo de todo el departamento, únicamente funciona cuando
la aplicación está en modo producción, de forma que crear grupos en desarrollo no
produce llamadas al servidor jungla.

71
3. MEMORIA Rafael García Marín

3.4 Pruebas

Hablaremos ahora de las pruebas que se realizaron sobre los cambios en el interfaz
de aplicación del SIR y las nuevas funcionalidades añadidas.

Antes del desarrollo del presente proyecto fin de carrera, el SIR contaba con
numerosos tests para probar el funcionamiento del código implementado a nivel de
clases, tanto de controladores como de modelos. Estos tests pasaban perfectamente y
aseguraban el buen funcionamiento de dichas clases antes de afrontar todos los cambios.
Una vez que empezaron a modificarse todas las rutas de la aplicación y creando el interfaz
REST, todos estos tests se rompieron y tuvieron que rehacerse de nuevo. Esto implicó
reescribir todas líneas de código de los tests para arreglar todas las llamadas y rutas que
habían quedado desactualizadas.

Estos tests incluyen varios tipos de pruebas, unitarias para probar los modelos y
funcionales para los controladores. Las unitarias están situadas dentro del directorio unit,
las funcionales se encuentran dentro del directorio functional. Existe un directorio fixtures
donde se especifican datos de prueba para la base de datos que se utilizarán en los tests.
Estos archivos tienen un formato especial, el YAML. Cada vez que se ejecutan los tests, el
framework carga sobre la base de datos de test toda la información contenida dentro de
los archivos YAML, de forma que cada ejecución es independiente y se prueba con
seguridad.

Las nuevas funcionalidades, sin embargo, se desarrollaron con las nuevas rutas ya
en un funcionamiento y esto permitió experimentar con una forma de implementación
que está siendo muy utilizada por la comunidad de programación que defiende a las
metodologías ágiles de programación. Son las llamadas TDD y BDD.

La primera, TDD (Test Driven Development), se centra en la implementación de los


tests antes de pasar a programar la lógica en sí. Es decir, cualquier nuevo código que
vayamos a implementar, debe tener escritos antes los tests, lo que nos permite tener más
clara la finalidad de las nuevas líneas, y nos permite tener una métrica para saber cuándo

72
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

hemos terminado de programar esa nueva funcionalidad. Con esta metodología de


programación se consigue un código mucho más robusto y seguro, además ayuda a tener
muy claro qué es lo que se quiere conseguir a la hora de escribir nuevas funcionalidades.

La segunda, BDD (Behaviour Driven Development), se basa en TDD pero intenta ir


aún más allá. La idea es unir en cierto modo la fase de análisis de requisitos convencional,
con la fase de implementación y la de pruebas. BDD consiste en escribir los tests al tiempo
que se recogen los requisitos que demanda el cliente. De esta forma, los requisitos
concretos que debe cumplir la aplicación se convierten en los nombres de los métodos de
los tests. Una vez se han recogido todos estos requisitos y se han plasmado en un conjunto
de métodos para hacer testing, se pasa a escribir los cuerpos de los tests y después se
escribe el código. Finalmente, no se termina de implementar el código hasta que no pasan
todos los tests correctamente. Por lo tanto, BDD realmente es un TDD pero añadiendo una
fase de análisis de requisitos previos al proceso de implementación y pruebas, todo a la
vez.

Debido a lo interesantes que son estas metodologías, se utilizaron para la creación


de las nuevas funcionalidades, concretamente en la de las listas de correo para los grupos
del SIR. Primero efectivamente se recogieron los requisitos de la nueva funcionalidad en
forma de nombres de los métodos de una clase de test. Una vez recogidos se
implementaron los cuerpos de los tests y después se escribió la lógica en sí hasta que
finalmente se consiguió hacer que los tests validaran correctamente. Esta práctica ha
resultado ser muy satisfactoria y enormemente productiva, el código se implementa más
lentamente que de la forma convencional, sin embargo, la robustez que se consigue con
esta metodología hace que el código sea muy fuerte y esté probado previamente a
siquiera estar escrito. Esto permite evitar que se produzcan roturas funcionales que de
otra forma pasan inadvertidas hasta una fase de pruebas previa a la fase de producción o
incluso en ocasiones es el mismo usuario final el que las descubre.

También se ha usado la herramienta Rcov. Es una gema de Ruby que se utiliza para
ejecutar los tests y que indica qué porcentaje del código se ha cubierto con los test, y
muestra en HTML el código de las clases probadas, con colores, verde si la línea se ejecutó
y rojo si no. Sin embargo, los resultados no son realmente definitivos, puesto que en
muchos casos se puede crear un test que simplemente recorra el código pero no pruebe
su funcionalidad. Esto no serviría de nada y además invalidaría el valor de medida. De

73
3. MEMORIA Rafael García Marín

todas formas, es una herramienta bastante estimativa, que ayuda a tener más o menos
claro qué partes del código se han cubierto con test y cuáles no.

Además de los tests, puesto que la funcionalidad de la aplicación es complicada y la


casuística de pruebas puede llegar a ser infinita, se puso al SIR en una fase de pruebas
previa a la fase de producción en la cual distintos usuarios ajenos al equipo de desarrollo
de la aplicación la utilizaron reportando todos los errores que fueran ocurriendo. Esta
forma de testear la aplicación es muy común entre la comunidad de desarrollo de
aplicaciones web, puesto que es una forma sencilla de testear y que arroja buenos
resultados. Coloquialmente se la conoce como “Monkey Testing”. Este tipo de pruebas se
repitieron varias veces a lo largo de todo el proceso de desarrollo.

3.5 Despliegue

La fase de producción supone el despliegue de la aplicación en un entorno distinto


al de desarrollo. Como ya hemos comentado, el entorno en el que se mueve una
aplicación Rails es configurable de forma sencilla de tal manera que podemos tener la
aplicación en modo desarrollo, producción o pruebas. Prácticamente todo el tiempo de
duración del proyecto, la aplicación se encuentra en modo desarrollo. Sin embargo, una
versión de producción y para pruebas se desplegó en la máquina sir.dit.upm.es. Éste es el
lugar en el que finalmente va a quedar instalada la aplicación SIR como aplicación HTML.

Para el despliegue de aplicaciones Rails, existen numerosas opciones. Hasta la


aparición de Rails 2.0, la tarea de desplegar aplicaciones Rails en producción era muy
compleja y complicada. Actualmente existe un módulo de Rails llamado Passenger (o
mod_rails) que se usa junto con el servidor Apache. Esta opción facilita mucho esta tarea
siguiendo la filosofía ágil del framework. Es por lo tanto muy utilizada debido a su sencillez.
Sin embargo, existen otras opciones también muy interesantes. La que ofrece un mayor
rendimiento y robustez a la aplicación en producción es la de nginx con mongrel. Nginx es
un servidor muy sencillo para servir páginas estáticas que debido a que está muy bien
implementado para la tarea que se diseñó, ofrece gran rendimiento. Mongrel es otro
servidor que balancea cargas dinámicas y que es muy utilizado para aplicaciones Rails
desde sus inicios. La combinación de ambos es muy buena pero no es tan sencilla como la
opción de Apache y Passenger.

74
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

Puesto que la aplicación se encuentra actualmente en un estado inicial de


despliegue, la mejor opción es la de Apache y Passenger, que es la que efectivamente se
ha utilizado. En un estado más avanzado del ciclo de vida de la aplicación, sería interesante
utilizar Nginx con Mongrel puesto que se adapta mejor a las necesidades de escalabilidad y
rendimiento que podría necesitar la aplicación en el futuro.

3.5.1 Passenger

Passenger es una gema de Ruby que permite desplegar aplicaciones Rails de forma
sencilla y guiada. Hasta su aparición en el último año, el despliegue de aplicaciones Rails
era una tarea bastante complicada y uno de los grandes problemas del uso de Rails como
framework de desarrollo. Passenger es una pequeña utilidad que detecta en el sistema de
despliegue cuáles son las aplicaciones y paquetes necesarios para ello, avisa de cuáles son
los que están instalados y cuáles necesitan estarlo, y para éstos últimos ofrece una guía
para su instalación. El principal de ellos y el más importante es el servidor Apache.
También instala diversos componentes necesarios para el despliegue y ofrece ayuda sobre
cómo configurarlos.

3.5.2 Apache

El servidor Apache es un servidor HTTP de código abierto altamente configurable,


con una base de datos de autenticación y negociado de contenido y con amplia aceptación
a lo largo de toda la red. Es el servidor de aplicaciones web más utilizado. Es un servidor
muy potente y seguro, y esto unido a que su código es libre es la principal razón de su
éxito. Sin embargo, no dispone de una interfaz gráfica de configuración y su utilización por
usuarios no expertos en bastante complicada.

La arquitectura de un servidor Apache es muy modular. El servidor consta de un


núcleo y a él se unen diversos módulos que aportan muchas de las funcionalidades para
Apache. Algunos de los módulos necesarios para el correcto funcionamiento del SIR son el
módulo Rewrite o el mod_ruby.

75
3. MEMORIA Rafael García Marín

Passenger provee la configuración de los virtual hosts necesaria para desplegar la


aplicación con Apache.

3.5.3 Capistrano

Capistrano es una aplicación para automatizar tareas que se usa principalmente


para despliegues automáticos de aplicaciones Rails desde máquinas en desarrollo a
servidores en producción. Se instala como una gema de Ruby. Para su utilización, se
ejectua el comando capify sobre el directorio raíz de la aplicación Rails en una máquina de
desarrollo. Esto crea un archivo llamado capfile, que utiliza capistrano para configuración
propia, y otro llamado deploy.rb donde se debe indicar con código Ruby diversos
parámetros. Estos parámetros son variables dependiendo del tipo de despliegue que se
quiera hacer y del escenario concreto en cada situación. Normalmente se especifica el
nombre de la máquina donde se va a desplegar la aplicación, la ruta donde se va a alojar el
código, login de usuario en la máquina servidor y la dirección del repositorio si es que se
utiliza uno. Además, se pueden especificar otras muchas cosas, y permite operaciones
complejas de despliegue en varios servidores con funciones distintas, ejecución remota de
comandos y preparación de tareas automatizadas.

A pesar de ser un programa complejo, la utilización de Capistrano es muy


interesante debido a que permite hacer despliegues desde máquinas en desarrollo con un
solo comando. Esto agiliza mucho el paso a producción, y encaja perfectamente con la
filosofía iterativa de resultados que promulga la metodología ágil de programación. Por
estas razones Capistrano fue la herramienta utilizada para el despliegue durante todo el
desarrollo del proyecto.

3.6 Documentación

Todo el trabajo realizado durante el proyecto se ha llevado a cabo paralelamente a


una labor exhaustiva de documentación de la aplicación. Tanto las nuevas funcionalidades
como el interfaz REST y Atom del SIR están perfectamente documentadas para permitir el
desarrollo de trabajos futuros sobre el SIR así como la integración de otras aplicaciones
mediante el uso del interfaz.

76
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

Esto se ve reflejado principalmente en dos documentos, en primer lugar, existe


un manual de instalación de la aplicación y otro de usuario que están guardados en la
wiki del grupo de desarrolladores, que sirve por un lado para los propios
desarrolladores que comiencen a desarrollar nuevo código para la aplicación, y por
otro como guía de instalación de la aplicación para clientes. En segundo lugar, existe
un extenso manual del interfaz Atom que sirve como API, ya no sólo de cara a la capa
Flex de la futura aplicación integrada, sino para otras aplicaciones que quieran usar
funcionalidades de SIR. Este manual se incluye en este libro, en los apéndices.

77
4. CONCLUSIONES Rafael García Marín

4 CONCLUSIONES

78
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

4.1 Problemas Encontrados

Durante la realización del proyecto nos hemos encontrado con algunos problemas
más o menos importantes que han dificultado en distinta medida su finalización.

En primer lugar, el principal problema es la estructura del código encontrado antes


de empezar el desarrollo de este proyecto. Debido a que el SIR surge como una aplicación
cuya primera función era la de levantar sesiones de la aplicación de videoconferencias
ISABEL (entonces recibía el nombre de MIR), el hecho de introducir una funcionalidad y
una estructura completamente distintas a su filosofía inicial hace que la implementación
del código fuera difícil y trabajosa. Esto unido a que este desarrollo se llevó a cabo con
versiones inciales de Rails que distan mucho cualitativamente de la versión actual llevó a
una baja calidad del código, alejado en muchas ocasiones de las convenciones usuales que
promulga Rails. Conseguir que el nuevo código refactorizado siguiera estas convenciones
de Rails ha supuesto mucho esfuerzo especialmente de aprendizaje de Ruby y Rails.

Otro problema ha sido la falta de estabilidad de la aplicación durante todo el


proceso. Ya desde el principio, la aplicación tenía muchas funcionalidades, complejas y
distintas, y los tests implementados con anterioridad no cubrían la mayor parte de los
casos a probar. Esto tuvo como consecuencia una aplicación muy inestable que nos
sorprendía con nuevos fallos prácticamente a diario, y gran parte del tiempo dedicado al
desarrollo del refactoring y el interfaz Atom se tuvo que dedicar al arreglo de los
numerosos bugs.

Un obstáculo considerable han sido los requisitos de base, poco claros y


cambiantes, problema que el uso de metodología ágil ha ayudado a paliar en gran medida.

El uso del CMSPlugin como núcleo de la funcionalidad CMS de la aplicación resulta


tanto una gran ayuda como un serio problema. Efectivamente el CMSPlugin ahorró mucho
trabajo debido a su funcionalidad perfectamente diseñada y creada para el SIR, encajando
perfectamente con sus requisitos y necesidades. Sin embargo, este hecho también lleva
consigo el problema de que el mismo desarrollo del CMSPlugin se ha llevado a cabo a la
vez que se desarrollaba el SIR. El código que se desarrollaba en el SIR iba enormemente
ligado a la versión del plugin en cada momento, y debido a los constantes cambios en él,
se ha tenido que volver sobre el código implementado en el SIR una y otra vez.

79
4. CONCLUSIONES Rafael García Marín

Por último, el problema fundamental para el buen desarrollo del interfaz Atom ha
sido el hecho de que el lado Flex de la aplicación final se ha llevado a cabo en un momento
distinto al desarrollo de este proyecto y por lo tanto, se ha echado en falta la
realimentación vital que hubiera arrojado el desarrollo de la capa Flex para una mejor
definición de los parámetros y los interfaces Atom desarrollados.

4.2 Conclusiones

A continuación se realizará una valoración final de lo que ha sido el desarrollo de


este proyecto, los objetivos conseguidos y los conocimientos adquiridos.

El desarrollo del proyecto ha sido una gran experiencia a nivel personal puesto que
ha significado una primera aproximación en lo que se refiere a ejecución de proyectos
complejos trabajando en equipo. Hemos usado herramientas de control de versiones
como Subversion, muy utilizadas en desarrollos software, y probablemente esto será de
gran utilidad en el futuro. Además, hemos trabajado con objetivos y con fechas de
finalización que suponen un adelanto de lo que se experimentará en la vida laboral en el
futuro.

Los objetivos fijados inicialmente se han conseguido ya que en el momento de


finalización del proyecto la aplicación SIR tiene ya un interfaz Atom completo y sigue la
filosofía de los RESTful Web Services para el manejo de todos sus recursos, además, la
aplicación se encuentra en producción en la dirección http://sir.dit.upm.es.

Los conocimientos adquiridos han sido muchos y muy variados. En primer lugar, he
profundizado mucho en el área de la programación orientada a objetos, además de
aprender el lenguaje Ruby y su framework Rails, desconocidos para mí antes del comienzo
del proyecto. En segundo lugar he aprendido otras tecnologías y conceptos como Atom,
REST, Apache y he usado herramientas y entornos de programación como Eclipse y
RadRails. A esto hay que unir que todo el trabajo se ha desarrollado sobre sistemas UNIX,
concretamente distribuciones de Linux (Ubuntu Debian), y esto también ha sido muy
interesante como aprendizaje del sistema operativo y de muchos comandos básicos y
avanzados que se utilizan. Además, hemos utilizado bases de datos como MySQL, que

80
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

también supone una primera aproximación en cuanto al aprendizaje sobre bases de datos
se refiere.

Por otra parte, el hecho de haber trabajado con código escrito previamente por
otros desarrolladores ha hecho que entienda la importancia de mantener una
documentación de calidad y actualizada sobre el código escrito para permitir a otros
desarrolladores su reutilización con el mínimo esfuerzo posible. Esto y el enfrentamiento a
los problemas que han ido apareciendo durante todo el desarrollo suponen una gran
experiencia para poder evitar en el futuro que se produzcan otros parecidos. Como
conclusión de este hecho se aprende lo fundamental que es tener un código robusto y
probado continuamente mediante tests de calidad.

En resumen, el desarrollo del Proyecto Fin de Carrea ha sido un éxito ya que se han
cumplido los objetivos, tanto a nivel del proyecto como a nivel personal, y se han
adquirido conocimientos muy útiles que suponen una primera experiencia profesional
para el alumno.

Por último y no menos importante, todo el trabajo se ha realizado rodeado de un


grupo excepcional de compañeros. A pesar de todo el esfuerzo, ha sido una gran
experiencia de la que me llevo multitud de buenos momentos y un gran grupo de amigos.

4.3 Trabajos futuros

A continuación vamos a sugerir algunas líneas de trabajo futuras, algunas de ellas


ya se han planteado y se van a realizar dentro de poco, otras se plantean como posibles
funcionalidades y trabajos que aportarían valor a la aplicación SIR actual.

Repositorio de documentos

Esta es una de las funcionalidades que ya se han planteado para el futuro a corto
plazo. Se trata de hacer que el SIR tenga un lugar virtual donde se almacenen documentos,
ya no sólo a nivel de posts con attachments como se realiza actualmente, sino con una
estructura virtual de directorios con permisos y roles asociados a los espacios en los que se
encuentra cada repositorio. De esta forma, cada espacio tendría un repositorio de
documentos asociado, y únicamente los usuarios miembros de dicho espacio tendrían

81
4. CONCLUSIONES Rafael García Marín

acceso a los documentos contenidos en el espacio. Además, dependiendo del rol de cada
usuario y de sus permisos, cada uno podría crear un directorio nuevo, leer, editar o borrar
archivos ya existentes o añadir otros nuevos.

Todo esto debería ser implementado con la misma filosofía de recursos REST que
tiene la aplicación SIR. Por ello, su creación requeriría la construcción de dos nuevos
recursos, uno llamado Document o similar, y otro llamado Directory. El primero de ellos y
como su nombre indica se referiría a los documentos, el otro, a los directorios. En primera
aproximación, cada recurso Document estaría contenido en un Directory, y se crearían
rutas anidadas del tipo /space/space_id/directory/directory_id/document.

Además, deberían crearse unas vistas HTML asociadas a dicha funcionalidad,


bastante complejas debido al tema de los permisos y las autorizaciones. El interfaz Atom
de dichos recursos proveería a la capa Flex del uso de esta nueva funcionalidad, cuyo
interfaz gráfico debería implementarse también en dicha capa.

Subespacios

Otra funcionalidad ya planteada es la creación de Subespacios sobre los Espacios


ya existentes. Estos subespacios serían exactamente igual en cuanto a funcionalidad que
los espacios superiores, con la salvedad de que únicamente los miembros del espacio
superior podrían ser miembros de cualquier subespacio contenido.

En una primera aproximación, su implementación parece sencilla dado que los


subespacios serían simplemente espacios con un espacio padre asociado. Esto implicaría
crear una columna en la tabla de la base de datos sobre los espacios que fuera un
parámetro referente al id del espacio padre. Sin embargo, esto no es tan sencillo debido a
que tiene unas implicaciones muy fuertes a nivel de permisos y autorizaciones. Por ello,
además de añadir la columna ya mencionada, habría que tener en cuenta la arquitectura
de filtros de autorización para espacios y subespacios. De esta forma, habría que definir
muy bien cuáles son los requisitos en cuanto a los roles con los que los usuarios en un
espacio padre acceden a los subespacios contenidos en él.

82
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

Historial de acciones

Otra funcionalidad interesante es el desarrollo de un historial de forma que cada


acción que se realiza en la aplicación queda registrada. Cualquier espacio podría indicar
entonces cuáles son las últimas actividades llevadas a cabo dentro de él, tanto a nivel de
posts como de eventos.

Su implementación sería relativamente sencilla. En primer lugar habría que crear


callbacks para cada método de cada recurso, de forma que cualquier acción suponga la
creación de una entrada en una nueva tabla de la base de datos. Cada entrada contendría
la acción concreta realizada, autor y fecha de realización. Después habría que crear las
vistas concretas en las páginas principales de los espacios donde se incluya la información
más reciente de esta nueva tabla de la base de datos

Integración con LDAP

Un requisito fundamental para la integración del SIR y de la nueva plataforma que


aúna SIR con la capa Flex como interfaz de usuario con el resto de aplicaciones del
departamento, es la integración del sistema de autenticación y autorización que ahora
tiene SIR con la arquitectura LDAP que va a gestionar todo el sistema de usuarios.

Esta integración sí que es una línea de trabajo complicada. Actualmente el SIR


tiene toda la información sobre usuarios, roles y permisos dentro de su base de datos, en
las tablas de usuarios, roles y performances (que asocian usuarios a roles, espacios y
contenidos). Una solución de integración sería crear un elemento intermedio entre el SIR y
el LDAP que se encargara de sincronizar ambos elementos, de forma que cualquier usuario
creado en el SIR sea creado de forma automática en el LDAP, y viceversa.

Además de este elemento de sincronización, la estructura de filtros de autorización


de la aplicación también tendría que ser modificada, por lo que llevar a cabo esta
integración con LDAP es una tarea considerablemente compleja.

Integración con la aplicación Marte

Una de las posibilidades interesantes que ofrece el hecho de integrar SIR junto con
el resto de aplicaciones del departamento así como la estructura del LDAP es el hecho de
poder integrar la aplicación de videoconferencias Marte dentro del SIR. Esta tarea es

83
4. CONCLUSIONES Rafael García Marín

complicada, sin embargo, una vez que la integración con LDAP se lleve a cabo, el hecho de
que el sistema de usuarios y autorizaciones que usan ambas aplicaciones sea el mismo
hará mucho más sencilla su integración.

La idea es que cada espacio tenga salas asociadas de la aplicación Marte. Así, los
usuarios dentro del mismo espacio podrán entablar conversaciones en tiempo real. Esto
añade funcionalidades síncronas al SIR que ahora mismo no tiene puesto que es una
aplicación Groupware de tipo asíncrono. Además, añadiría la funcionalidad de presencia,
cada usuario sabría en cada momento quién está conectado al mismo tiempo.

Internacionalización

Otra de las tareas pendientes del SIR es la internacionalización. Actualmente todos


los mensajes de la aplicación están en inglés. Sería interesante usar algún mecanismo para
lograr que todos los mensajes estén en varios idiomas, y que puedan ser escogidos por los
usuarios a voluntad.

Para lograrlo se puede usar un plugin que tiene Rails llamado globalize.

Reescritura de los tests con rspec

Una posible opción de mejora es reescribir todos los tests usando rspec. Rspec
cumple las mismas funciones que la suite de testing que viene de base con Rails, pero
además ofrece otras opciones para aumentar la calidad del testing. La forma de escribir los
tests con rspec es más natural e intuitiva, y permite el uso de cucumber, un plugin que
permite escribir los tests como si fueran casos de uso directamente (user stories). Este
hecho va en sintonía con la filosofía BDD y aumenta la experiencia y la calidad del uso de
metodologías ágiles de programación. De hecho, los tests de integración son mucho
mejores que los tests de integración básicos que vienen de base con Rails.

84
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil

4.4 Bibliografía
1. Open-Xchange. Open-Xchange: Community Area. [En línea] http://www.open-
xchange.com/header/community_area.html.

2. Barra Arias, Enrique. Implementación de una Plataforma de Gestión de Eventos de


la Herramienta Isabel basada en lenguaje XML. Madrid : ETSIT, 2006.

3. Costello, Roger L. Building Web Services the REST Way. [En línea]
http://www.xfront.com/REST-Web-Services.html.

4. Group, Network Working. Request for Comments 4287. [En línea]

5. —. Request for Comments: 5023. [En línea]

6. —. Request for Comments: 4685. [En línea]

7. Google Data APIs. Common Elements. [En línea]


http://code.google.com/apis/gdata/elements.html.

8. Ágil, Manifiesto. http://agilemanifesto.org/principles.html. [En línea]

9. W3C. Feed Validation Service. [En línea] http://validator.w3.org/feed.

10. MSN. MSN Messenger / Windows Live. [En línea] http://get.live.com/.

11. Skype. Herramienta de videoconferencia Skype. [En línea] http://www.skype.com.

12. Wikipedia. Wikipedia, la enciclopedia libre. [En línea] http://es.wikipedia.org/.

13. Isabel. Web de la aplicación Isabel. [En línea] http://isabel.dit.upm.es.

14. BSCW. BSCW: Be Smart. [En línea] http://public.bscw.de/.

15. Polycom. Productos de la herramienta de videoconferencia Polycom. [En línea]


http://www.polycom.com.

16. eGroupWare. eGroupWare. [En línea] http://www.egroupware.org/.

85
4. CONCLUSIONES Rafael García Marín

17. AGWS. Ágora GroupWare System. [En línea] http://www.agora-


2000.com/products/agws.

18. O´Reilly. O'Reilly -- What Is Web 2.0. [En línea]


http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.

19. ldapman.org. An introduction of LDAP. [En línea]


http://ldapman.org/articles/sp_intro.html.

20. Hasson, David Heinemier. Agile Web Development With Ruby on Rails. s.l. :
Pragmatic Proggramer. ISBN 097669400X.

21. Wiki RoR. Wiki de Ruby on Rails. [En línea] http://wiki.rubyonrails.org/.

22. Aptana. Aptana IDE para el desarrollo de RoR. [En línea] http://www.aptana.com/.

23. SER. Sip Express Router. [En línea] www.iptel.org/ser/.

86
5 APÉNDICES
Diseño e Implementación de Servicios de Colaboración Basados en Web

5.1 The SIR Application Interface

5.1.1 Introduction

The SIR application is designed using the REST approach. This means that
everything in the application is a “resource”.

REST (representational state transfer) is an approach for getting information


content from a Web site by reading a designated Web page that contains an (Extensible
Markup Language) file that describes and includes the desired content. For example, REST
could be used by an online publisher to make syndicated content available. Periodically,
the publisher would prepare and activate a Web page that included content and XML
statements that described the content. Subscribers would need only to know the URL
(Uniform Resource Locator) for the page where the XML file was located, read it with a
Web browser, interpret the content data using the XML information, and reformat and use
it appropriately (perhaps in some form of online publication).

SIR uses this approach by using URIs to represent all the resources in the
application. There are 4 main resources in SIR: Spaces, Users, Posts and Events.

5.1.2 How to use this document

This document explains how to manage resources from SIR. Each type of resource
is explained on its own, includes a list of its REST methods and how to call them, and also
the parameters which define the attributes of the resource.

These parameters are needed when performing a write action (create or update).
Also, when calling to a read action (index or show) the resource is returned with all its
parameters. There are fewer parameters needed when performing a write action than
those returned by a read action. This is because some of these parameters are determined
automatically when the write action is done (usually depending on the date or the order of
creation).

89
5. APÉNDICES Rafael García Marín

5.1.3 The REST Interface

A RESTful application has an API very well determined and almost standard for
every application. There are 7 methods to manage resources:

HTTP
URI RAILS METHOD
METHOD
GET /resources index List of all resources
POST /resources create Adds a new resource
GET /resources/new new Form for create
GET /resources/:id/edit edit Form for update
GET /resources/:id show Shows details of the resource with
the determined id.
PUT /resources/:id update Changes details of the resource
with the determined id.
DELETE /resources/:id destroy Eliminates the resource with the
determined id.
Tabla 1: REST Resources

The main 4 actions are show, create, update and destroy. These 4 actions are the
main methods of a CRUD interface (Create, Read, Update, Delete). The index action is a
“show” call but instead of only one resource, a list of all of them. The remaining 2
methods, new and edit, are calls to forms which gather the parameters needed by the
create and update methods.

When a GET or a DELETE HTTP message is sent, there are no parameters needed,
but when the method is a POST or a PUT, because we are creating or updating certain
resource, we need to include the information related to the resource attributes. If any
parameter is to be sent in a GET message, it would be included in the URI, because a HTTP
packet for a GET message doesn't have any body containing information.

When the information is required in a specific format, the URI needs to include the
extension of this format. This way, if we wanted a list of all the resources in XML, we
should perform a GET method to the URI /resources.xml

90
Diseño e Implementación de Servicios de Colaboración Basados en Web

Resources can also be nested. This way, if we had a resource called “message”
which is contained into a “space” resource, the URIs for the REST methods will nest too,
and the table would be:

HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/messages index List of all messages
contained in the space
POST /spaces/:space_id/messages create Adds a new message to the
space
GET /spaces/:space_id/messages/new new Form for create
GET /spaces/:space_id/messages/:id/edit edit Form for update
GET /spaces/:space_id/messages/:id show Shows details of the
message with the
determined id in the
determined space
PUT /spaces/:space_id/messages/:id update Changes details of the
message with the
determined id in the
determined space
DELETE /spaces/:space_id/messages/:id destroy Eliminates the message
with the determined id in
the determined space
Tabla 2: Nested resources in REST

In this particular case, :space_id indicates the id number to identify a certain space.

There is also a particular type of resource which is always singular. This means that
certain methods don't make sense for this type of resource. The index method, which
returns a list of all resources, is eliminated from the list, in the case of a singular resource,
the only read option we will have is the show method. Also, its important to know that the
URI is composed of the name of the resource but this time in singular, not in plural as done
before. The table this time is:

91
5. APÉNDICES Rafael García Marín

HTTP
URI RAILS METHOD
METHOD
POST /resource create Adds a new resource
GET /resource/new new Form for create
GET /resource/edit edit Form for update
GET /resource show Shows details of the resource
PUT /resource update Changes details of the resource
DELETE /resource destroy Eliminates the resource
Tabla 3: Single Resource in REST

5.1.4 The Interface Format

The Rest Interface can also be managed in a format different than html. In order to
summon the different resources in other formats, an extension string has to be added to
each URI.

Every method described before can be summoned in a formatted interface, with


the exception of new and edit. These two methods are used to create the form for create
and update (because data has to be sent alongside with the HTTP petition). Using a format
different that html, we send data directly in the format given, and therefore there is no
need to use these two methods.

The generic table for the “formatted” interface is:

HTTP RAILS
URI
METHOD METHOD
GET /resources.:format index List of all resources in the format
specified
POST /resources.:format create Adds a new resource by sending
the resource description in the
format specified
GET /resources/:id.:format show Shows details of the resource
with the determined id in the
format specified.
PUT /resources/:id.:format update Changes details of the resource
with the determined id in the
format specified.
DELETE /resources/:id.:format destroy Eliminates the resource with the

92
Diseño e Implementación de Servicios de Colaboración Basados en Web

determined id returning the


results of the process in the
format specified.
Tabla 4: Formatted Resources in REST

In the table, just replace the :format structure with the desired format.

Rules for nested and singular resources also apply for these “formatted” interfaces.
Just add the :format to each URI.

5.1.4.1 The XML Interface

One of the formatted interfaces provided by the SIR application is XML. This is a
very simple interface. Gives descriptions of every resource by merely putting tags to the
values of the columns in the database.

Therefore, if we make a GET petition to the application and adding “.xml” to the
URI, it returns a XML object mapped to that particular resource. Also, for create and
update, XML objects have to be send to the particular URI's by adding “.xml” to them.

HTTP
URI RAILS METHOD
METHOD
GET /resources.xml index List of all resources in XML
POST /resources.xml create Adds a new resource by sending the
resource description in XML
GET /resources/:id.xml show Shows details of the resource with
the determined id in XML.
PUT /resources/:id.xml update Changes details of the resource
with the determined id in XML.
DELETE /resources/:id.xml destroy Eliminates the resource with the
determined id returning the results
of the process in XML.
Tabla 5: XML Interface

93
5. APÉNDICES Rafael García Marín

5.1.4.2 The Atom Interface

The most important interface in SIR is the Atom one. The Atom Syndication Format
(RFC 4287) is an XML language used for web feeds, while the Atom Publishing Protocol
(AtomPub or APP, RFC 5023) is a simple HTTP-based protocol for creating and updating
web resources. SIR uses both specifications for its interface. Atom is a standard which can
be extended for new features. SIR also uses some extensions from Atom.

Unlike XML, Atom does not map the columns of the tables for each type of
resource. Atom has its standard tags described in the Atom and AtomPub RFCs. SIR uses
them and some others to describe the resources. The other tags are described in
extensions for Atom. One of them is Gdata, the API provided from Google for its internet
applications using Atom. The other is an extension for thread-type structures, this is called
Atom Threading Extensions (RFC 4685). Finally, some resource attributes are mapped to
no standard Atom extension. These other attributes are mapped with SIR specific tags
from its own namespace.

An Atom structure looks like this:

<?xml version="1.0" encoding="utf-8"?>


<feed xmlns="http://www.w3.org/2005/Atom">

<title>Example Feed</title>
<subtitle>A subtitle.</subtitle>
<link href="http://example.org/feed/" rel="self"/>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
<email>johndoe@example.com</email>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>

<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>

94
Diseño e Implementación de Servicios de Colaboración Basados en Web

</feed>

A typical Atom structure contains a feed, which has information related to it, like
its title, author or dates regarding its creation or last changes. A feed is normally a
collection of entries. Each entry is defined between the tags <entry> and </entry>.
Resources are normally entries in Atom. Each entry has information related to it using
the standard Atom tags described in the Atom RFC s and its extensions. To know which
extension describes a particular tag, the following structure is used:
<ns:tag>information here</ns:tag>

Each tag has a “ns:” structure before its own name. This ns is a variable containing
the URI of the namespace used. This variable is defined in the header of an Atom
structure. For example:

<?xml version="1.0" encoding="UTF-8"?>


<feed xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:thr="http://purl.org/syndication/thread/1.0"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">

</feed>

In this particular feed we can see that there are variables defined for the Gdata,
Atom-Thread, Sir and Atom namespaces. Each namespace refers to a certain Atom
extension. When no prefix is found in a tag, then by default the tag comes from the Atom
Basic Protocol.

The extensions and namespaces used by SIR are:

Atom Standard (no prefix) => xmlns="http://www.w3.org/2005/Atom"


Gdata extension => xmlns:gd="http://schemas.google.com/g/2005"
Atom Threading Extension => xmlns:thr="http://purl.org/syndication/thread/1.0"
SIR namespace => xmlns:sir="http://sir.dit.upm.es/schema"

Therefore, if we make a GET petition to the application and adding “.atom” to the
URI, it returns a Atom object mapped to that particular resource. Also, for create and
update, Atom objects have to be send to the particular URI's by adding “.atom” to them.

95
5. APÉNDICES Rafael García Marín

HTTP RAILS
URI
METHOD METHOD
GET /resources.atom index List of all resources in Atom
POST /resources.atom create Adds a new resource by sending the
resource description in Atom
GET /resources/:id.atom show Shows details of the resource with
the determined id in Atom.
PUT /resources/:id.atom update Changes details of the resource with
the determined id in Atom.
DELETE /resources/:id.atom destroy Eliminates the resource with the
determined id returning the results of
the process in Atom.
Tabla 6: Atom Interface

5.1.5 Resources

5.1.5.1 Spaces

A Space is a virtual container of information related to a specific topic in particular.


When different people are working on the same project, they create their own space, and
there they publish and share all the information related.

Interface

Spaces use a different id than all the other resources in SIR. The :id for a Space is
the name of the space instead of the id number.

The REST interface related to the Spaces is:

HTTP
URI RAILS METHOD
METHOD
GET /spaces index
GET /spaces.:format index
POST /spaces create

96
Diseño e Implementación de Servicios de Colaboración Basados en Web

POST /spaces.:format create


GET /spaces/new new
GET /spaces/new.:format new
GET /spaces/:id/edit edit
GET /spaces/:id/edit.:format edit
GET /spaces/:id show
GET /spaces/:id.:format show
PUT /spaces/:id update
PUT /spaces/:id.:format update
DELETE /spaces/:id destroy
DELETE /spaces/:id.:format destroy
Tabla 7: Spaces Interface

Space parameters returned by read actions

The parameters which define a Space object are:

name
parent_id : Id of a parent container, if it has any.
deleted
public : Indicates if the Space is open to every user with a “1” (true) or if it is
private only for its members with a “0” (false).
created_at
updated_at
description

Therefore, a typical Space object structure would be:

#<Space id: 1, name: "Space 1", parent_id: nil, deleted: nil, public: true, created_at: "2008-
07-24 15:14:05", updated_at: "2008-07-24 15:48:38", description: "<p>This is the
description</p>">

In XML:

<spaces type="array">
<space>
<created-at type="datetime">2008-08-29T15:35:43+02:00</created-at>
<deleted type="boolean" nil="true"/>
<description><p>This is the description</p></description>
<id type="integer">2</id>
<name>Space 1</name>

97
5. APÉNDICES Rafael García Marín

<parent-id type="integer" nil="true"/>


<public type="boolean">true</public>
<updated-at type="datetime">2008-08-29T15:35:43+02:00</updated-at>
</space>
</spaces>

By doing a GET on /spaces.atom, the Atom interface shows:

<?xml version="1.0" encoding="UTF-8"?>


<feed xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom" xmlns:gd="http://sir.dit.upm.es/schema">
<id>tag:sir.dit.upm.es,2005:/spaces</id>
<link type="text/html" rel="alternate" href="http://localhost:3000"/>
<link type="application/atom+xml" rel="self" href="http://sir.dit.upm.es/spaces.atom"/>
<title>Spaces</title>
<updated>2008-09-22T18:04:19+02:00</updated>
<entry>
<id>tag:sir.dit.upm.es,2005:Space/2</id>
<published>2008-09-11T16:29:15+02:00</published>
<updated>2008-09-22T18:04:19+02:00</updated>
<link type="text/html" rel="alternate" href="http://sir.dit.upm.es/spaces/2"/>
<title>Space 2</title>
<summary type="html">Space description</summary>
<gd:deleted>true</gd:deleted>
<sir:parent_id></sir:parent_id>
<gd:visibility>public</gd:visibility>
<author>
<name>SIR</name>
</author>
</entry>

</feed>

Space parameters needed by write actions

In order to perform creation of a Space, the mandatory parameters are name,


public and description. An application trying to call a create method from SIR should send
this type of structure:

"space"=>{"name"=>"test space", "public"=>"1", "description"=>"<p>this is the description


of the space</p>"}

In XML:

98
Diseño e Implementación de Servicios de Colaboración Basados en Web

<space>
<description><p>space description</p></description>
<name>Space name</name>
<public type="boolean">true</public>
</space>

By doing a POST on /spaces.atom, the Atom interface needs this structure:

<entry xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"


xmlns="http://www.w3.org/2005/Atom" xmlns:sir="http://sir.dit.upm.es/schema">
<id>tag:sir.dit.upm.es ,2005:Space/3</id>
<published>2008-09-11T16:07:15+02:00</published>
<updated>2008-09-11T16:07:15+02:00</updated>
<link type="text/html" rel="alternate" href="http://sir.dit.upm.es/spaces/3"/>
<link type="application/atom+xml" rel="self"
href="http://sir.dit.upm.es/spaces/2.atom"/>
<title>New Space</title>
<summary type="html">Space description</summary>
<gd:deleted>true</gd:deleted>
<sir:parent_id>5</sir:parent_id>
<gd:visibility>public</gd:visibility>
<author>
<name>SIR</name>
</author>
</entry>

In the Atom interface we can see this mandatory tags:

title => maps to name


summary => maps to description
sir:parent_id => maps to parent_id
gd:visibility => This is the tag used by the Google API and maps to the SIR public
parameter. It may take the value “public” (which maps the public parameter to
true) and “private” (which maps the public parameter to false).

5.1.5.2 Users

The resource User is a representation of the people using the SIR application. Users
can be found nested into a certain Space depending on how we are using them.

99
5. APÉNDICES Rafael García Marín

Interface

When using a User on the scope of the whole SIR application the REST interface is:

HTTP
URI RAILS METHOD
METHOD
GET /users index
GET /users.:format index
POST /users create
POST /users.:format create
GET /users/new new
GET /users/new.:format new
GET /users/:id/edit edit
GET /users/:id/edit.:format edit
GET /users/:id show
GET /users/:id.:format show
PUT /users/:id update
PUT /users/:id.:format update
DELETE /users/:id destroy
DELETE /users/:id.:format destroy
Tabla 8: Users Interface

A User could be also managed in the context of a particular Space because


normally the User will be a member of this Space. Therefore, all methods are restricted
only to the scope of the Space. Performing a index action will list all the users contained in
the Space. By using a create action nesting to a Space, we are adding the user to this
Space, making it become a member. Destroying a User in the Space will erase the
membership of the User but it will not delete the User from the SIR application on the
whole.

The REST interface for nested Users in a Space is:

100
Diseño e Implementación de Servicios de Colaboración Basados en Web

HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/users index List of all users contained in
the space
POST /spaces/:space_id/users create Adds a new user to the space
GET /spaces/:space_id/users/new new Form for create
GET /spaces/:space_id/users/:id/edit edit Form for update
GET /spaces/:space_id/users/:id show Shows details of the user with
the determined id in the
determined space
PUT /spaces/:space_id/users/:id update Changes details of the user
with the determined id in the
determined space
DELETE /spaces/:space_id/users/:id destroy Eliminates the user from the
Space but not from the
application
Tabla 9: Nested Users Interface

User parameters returned by read actions

The parameters which define a User object in the SIR database are:

User id
login
email
crypted_password
salt
created_at
updated_at
remember_token
remember_token_expires_at
superuser : indicates if the user has powers of superuser or not
disabled
reset_password_code
email2
email3
activation_code
activated_at

Therefore, a typical User object structure would be:

101
5. APÉNDICES Rafael García Marín

#<User id: 1, login: "admin", email: "email@domain.com", crypted_password:


"8057e7a92d13acf21ea192bb3097550a6a205281", salt:
"193d1348682da4451dc1f4b155d89f68ae6963e0", created_at: "2008-04-03 17:34:59",
updated_at: "2008-08-26 12:26:18", remember_token: nil, remember_token_expires_at:
nil, superuser: true, disabled: false, reset_password_code: nil, email2: nil, email3: nil,
activation_code: nil, activated_at: "2008-04-03 17:34:59">

In XML:

<user>
<activated-at type="datetime">2008-04-03T17:34:59+02:00</activated-at>
<activation-code nil="true"></activation-code>
<created-at type="datetime">2008-04-03T17:34:59+02:00</created-at>
<crypted-password>8057e7a92d13acf21ea192bb3097550a6a205281</crypted-
password>
<disabled type="boolean">false</disabled>
<email>ebarra@dit.upm.es</email>
<email2 nil="true"></email2>
<email3 nil="true"></email3>
<id type="integer">1</id>
<login>admin</login>
<remember-token nil="true"></remember-token>
<remember-token-expires-at type="datetime" nil="true"></remember-token-expires-at>
<reset-password-code nil="true"></reset-password-code>
<salt>193d1348682da4451dc1f4b155d89f68ae6963e0</salt>
<superuser type="boolean">true</superuser>
<updated-at type="datetime">2008-09-03T11:51:45+02:00</updated-at>
</user>

By doing a GET on /users.atom, the Atom interface shows:

<?xml version="1.0" encoding="UTF-8"?>


<feed xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:sir.dit.upm.es,2005:/users</id>
<link type="text/html" rel="alternate" href="http://localhost:3000"/>
<link type="application/atom+xml" rel="self"
href="http://sir.dit.upm.es:3000/users.atom"/>
<title>Users</title>
<updated>2008-04-03T17:34:59+02:00</updated>
<entry>
<id>tag:sir.dit.upm.es,2005:User/1</id>
<published>2008-04-03T17:34:59+02:00</published>
<updated>2008-04-03T17:34:59+02:00</updated>
<link type="text/html" rel="alternate" href="http://sir.dit.upm.es/users/1"/>

102
Diseño e Implementación de Servicios de Colaboración Basados en Web

<title>admin</title>
<gd:email address="myprimarymail@mail.com" primary="true"/>
<gd:email address="anothermail@mail.com"/>
<gd:email address="yetanothermail@mail.com"/>
<author>
<name>SIR</name>
</author>
</entry>

</feed>

User parameters needed by write actions

In order to perform creation of a User in the SIR application, the mandatory


parameters are login, email, password, password_confirmation. Also, email2 and email3
are sent, but they are not mandatory. An application trying to call a create method from
SIR should send this type of structure:

"agent"=>{"password_confirmation"=>"passwordhere", "email2"=>"", "email3"=>"",


"login"=>"loginhere", "password"=>"passwordhere",
"email"=>"myprimarymail@mail.com"}

In XML:

<?xml version="1.0" encoding="UTF-8"?>


<user>
<password>passwordhere</password>
<password_confirmation>passwordhere</password_confirmation>
<email>mail@domain.com</email>
<email2 nil="true"></email2>
<email3 nil="true"></email3>
<login>loginname</login>
</user>

By doing a POST on /users.atom, the Atom interface needs this type of structure:

<?xml version="1.0" encoding="UTF-8"?>


<entry xmlns:gd="http://schemas.google.com/g/2005"
xmlns:sir="http://sir.dit.upm.es/schema" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">

103
5. APÉNDICES Rafael García Marín

<id>tag:sir.dit.upm.es ,2005:User/3</id>
<published>2008-04-03T17:34:59+02:00</published>
<updated>2008-04-03T17:34:59+02:00</updated>
<link type="text/html" rel="alternate" href="http://sir.dit.upm.es/users/1"/>
<link type="application/atom+xml" rel="self"
href="http://sir.dit.upm.es/spaces/1/users/1.atom"/>
<title>atom2</title>
<sir:password>prueba</sir:password>
<gd:email address="myprimarymail@mail.com" primary="true" label="email1"/>
<gd:email address="anothermail@mail.com" primary="false" label="email2"/>
<gd:email address="yetanothermail@mail.com" primary="false" label="email3"/>
<category term="tag1"/>
<category term="tag2"/>
<category term="tag3"/>
<author>
<name>SIR</name>
</author>
</entry>

In the Atom interface we can see this mandatory tags:

title => maps to login


gd:email => Uses the Google API for Users, it has the following attributes:
address => The actual email address
primary => By true indicates that this email is the default email for the user
label => The label identifies the email (as there can be more than one). SIR uses
maximum 3 emails, so the labels should be strictly email1, email2 and email3.
sir:password => maps to password
category => maps to tags, there can be more than one.

All of these tags must be included in the Atom archive in order to perform a valid
User creation or update action.

5.1.5.3 Events

The resource Event is a representation of the events held in a certain Space. Events
might be meetings or conferences or gatherings held with ISABEL.
As said before, Events are a concrete type of Posts.

104
Diseño e Implementación de Servicios de Colaboración Basados en Web

Interface

Events are always managed inside the context of a Space because they are always
attached to a certain activity or area.

The REST interface for Events is:

HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/events index List of all events contained in
the space
POST /spaces/:space_id/events create Adds a new event to the space
GET /spaces/:space_id/events/new new Form for create
GET /spaces/:space_id/events/:id/edit edit Form for update
GET /spaces/:space_id/events/:id show Shows details of the event
with the determined id
PUT /spaces/:space_id/events/:id update Changes details of the event
with the determined id
DELETE /spaces/:space_id/events/:id destroy Eliminates the event
Tabla 10: Events Interface

Event parameters returned by read actions

The parameters which define a Event object in the SIR database are:
Event id
name
password
service
quality
description
uri

Therefore, a typical Event object structure would be:

105
5. APÉNDICES Rafael García Marín

#<Event id: 5, name: "eventname", password: "passwordhere", service: "meeting.act",


quality: "1M", description: "here goes the description", uri: "xedls/eventname-30-9-2008-
at-16-57.xedl"

In XML:

<event>
<description>here goes the description</description>
<id type="integer">1</id>
<name>eventname</name>
<password>passwordhere</password>
<quality>1M</quality>
<service>meeting.act</service>
<uri>xedls/eventname-30-9-2008-at-16-57.xedl</uri>
</event>

The Atom interface shows:

<?xml version="1.0" encoding="UTF-8"?>


<feed xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:localhost,2005:/spaces/8/events</id>
<link type="text/html" rel="alternate" href="http://localhost:3000"/>
<link type="application/atom+xml" rel="self"
href="http://localhost:3000/spaces/8/events.atom"/>
<title>Events</title>
<updated>2008-09-24T11:10:50+02:00</updated>
<entry>
<id>tag:localhost,2005:Event/18</id>
<link type="text/html" rel="alternate" href="/spaces/8/events/18"/>
<title>event name</title>
<summary>this is the description</summary>
<updated>2008-09-24T11:10:50+02:00</updated>
<gd:when startTime="vie oct 10 15:41:00 +0200 2008" valueString="0" endTime="vie
oct 10 17:41:00 +0200 2008"/>
<gd:when startTime="sab oct 11 15:41:00 +0200 2008" valueString="1" endTime="sab
oct 11 17:41:00 +0200 2008"/>
<author>
<name>SIR</name>
</author>
</entry>

</feed>

These Atom tags will be explained in Event paramenters needed by write actions.

106
Diseño e Implementación de Servicios de Colaboración Basados en Web

Event parameters needed by write actions

In order to perform creation of an Event in the SIR application, the mandatory


parameters are name, service, all_participant_sites, description, password and quality.

name
description
password
quality
service
all_participant_sites

Also, more parameters are sent, but they are not part of the Event object
structure. This parameters are:

start_date”n”: The “n” is an integer number starting by “0”. As an event could be


having more than one datetime, it should be indicated by putting an “n” suffix to
this parameter (the same applies to end_date)
end_date”n”
tags : this field is hash containing all the tags separated by commas referring to the
current event.

An application trying to call a create method from SIR should send this type of
structure:

=> {"is_valid_time0"=>"true", "end_date0"=>"September 22, 2008 18:19",


"password2"=>"prueba", "accomplished0"=>"false", "tag"=>{"add_tag"=>"key word event
meeting"}, "event"=>{"name"=>"event name", "service"=>"meeting.act",
"all_participants_sites"=>"5", "description"=>"event description", "password"=>"prueba",
"quality"=>"1M"}, "los_indices"=>"1", "start_date0"=>"September 22, 2008 16:19"}

When doing an update:

{"is_valid_time0"=>"true", "end_date0"=>"septiembre 28, 2008 17:41",


"password2"=>"she", "format"=>"atom", "accomplished0"=>"false",
"event"=>{"name"=>"ATOM", "service"=>"meeting.act", "all_participants_sites"=>"5",
"description"=>"walking on by", "password"=>"she", "quality"=>"1M"},
"tag"=>{"add_tag"=>"pico"}, "action"=>"update", "id"=>"5", "los_indices"=>"1",
"controller"=>"events", "start_date0"=>"septiembre 28, 2008 15:41", "space_id"=>"2"}

107
5. APÉNDICES Rafael García Marín

In XML it is not possible to perfom a creation, however, by sending a POST on


/users.atom, the Atom interface does, and it needs this type of structure:

<?xml version="1.0" encoding="UTF-8"?>


<entry xmlns:gd="http://schemas.google.com/g/2005"
xmlns:sir="http://sir.dit.upm.es/schema" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:localhost,2005:Event/7</id>
<link type="text/html" rel="alternate" href="/spaces/8/events/7"/>
<title>atom power</title>
<summary>atom power</summary>
<updated>2008-09-19T15:42:00+02:00</updated>
<gd:when startTime="octubre 11, 2008 15:41" endTime="octubre 11, 2008 17:41"
valueString="0"/>
<gd:when startTime="octubre 13, 2008 15:41" endTime="octubre 13, 2008 17:41"
valueString="1"/>
<category term="tag1"/>
<category term="tag2"/>
<category term="tag3"/>
<sir:password>password</sir:password>
<sir:service>meeting.act</sir:service>
<sir:all_participant_sites>10</sir:all_participant_sites>
<sir:quality>1M</sir:quality>
<author>
<name>SIR</name>
</author>
</entry>

In the Atom interface we can see this mandatory tags:

title => maps to name


summary => maps to description
gd:when => Uses the Google API for Events, if has the following attributes:
o startTime => A datetime indicating the date when the event starts
o endTime => A datetime indicating the date when the event ends
o valueString => This attribute indicates the number which identifies the “n”
suffix on the start_date and end_date parameters. The count must start on
“0”
sir:password
sir:service
sir:all_participant_sites
category => maps to tags, there can be more than one.

108
Diseño e Implementación de Servicios de Colaboración Basados en Web

5.1.5.4 Articles

Articles are text messages in SIR. They may contain attachments.

Interface

Articles are always managed inside the context of a Space because they are always
attached to a certain activity or area.

The REST interface for Articles is:

HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/articles index List of all articles contained
in the space
POST /spaces/:space_id/articles create Adds a new article to the
space
GET /spaces/:space_id/articles/new new Form for create
GET /spaces/:space_id/articles/:id/edit edit Form for update
GET /spaces/:space_id/articles/:id show Shows details of the article
with the determined id
PUT /spaces/:space_id/articles/:id update Changes details of the
article with the determined
id
DELETE /spaces/:space_id/articles/:id destroy Eliminates the article
Tabla 11: Articles Interface

Article parameters returned by read actions

The parameters which define a Article object in the SIR database are:
id
title
text
created_at

109
5. APÉNDICES Rafael García Marín

updated_at

Therefore, a typical Article object structure would be:

#<Article id: 4, text: "<p>eso</p>", created_at: "2008-11-07 10:24:21", updated_at: "2008-


11-07 10:24:21", title: "Prueba de Nuevo Post Público">

The XML shows information about the Entry related to the Article, therefore
showing many fields which are only interesting internally:

<entries type="array">
<entry>
<agent-id type="integer">1</agent-id>
<agent-type>User</agent-type>
<container-id type="integer">9</container-id>
<container-type>Space</container-type>
<content-id type="integer">8</content-id>
<content-type>XhtmlText</content-type>
<created-at type="datetime">2008-09-25T12:13:40+02:00</created-at>
<description><p>This is the Article text</p></description>
<id type="integer">23</id>
<parent-id type="integer" nil="true"/>
<parent-type nil="true"/>
<public-read type="boolean">true</public-read>
<public-write type="boolean" nil="true"/>
<title>article</title>
<updated-at type="datetime">2008-09-25T12:13:40+02:00</updated-at>
</entry>
</entries>

The Atom interface shows only the real information needed, not everything stored
in the database:

<?xml version="1.0" encoding="UTF-8"?>


<feed xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:thr="http://purl.org/syndication/thread/1.0"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:localhost,2005:/spaces/Public/articles</id>
<link type="text/html" rel="alternate" href="http://localhost:3000"/>
<link type="application/atom+xml" rel="self"
href="http://localhost:3000/spaces/Public/articles.atom"/>
<title>Posts</title>
<updated>2008-11-05T17:13:02+01:00</updated>

110
Diseño e Implementación de Servicios de Colaboración Basados en Web

<entry>
<id>tag:localhost,2005:Article/996332881</id>
<published>2008-10-31T12:31:50+01:00</published>
<updated>2008-10-31T12:31:50+01:00</updated>
<link type="text/html" rel="alternate" href="/spaces/Public/articles/996332881"/>
<title>fdsfddsafdsafsda</title>
<content type="html">&lt;p&gt;fdsafdsafdsafdsafsda&lt;/p&gt;</content>
<gd:visibility>public</gd:visibility>
<author>
<name>SIR</name>
</author>
</entry>

</feed>

When the article is a comment of another article, the field thr:in-reply-to indicates
the id of the parent article.

These Atom tags will be explained in Event parameters needed by write actions.

Article parameters needed by write actions

The content of the parameters hash sent when creating an role is composed of the
following parts:

article
o title
o text
tags
space_id

An application trying to call a create method from SIR should send this type of
structure:

=> {"article"=>{"title"=>"New Post", "text"=>"<p>Description</p>"}, "tags"=>"",


"space_id"=>"Public"}

The Atom interface requires:

111
5. APÉNDICES Rafael García Marín

<?xml version="1.0" encoding="UTF-8"?>


<entry xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:localhost,2005:Article/11</id>
<published>2008-10-02T12:33:50+02:00</published>
<updated>2008-10-02T12:33:50+02:00</updated>
<link type="text/html" rel="alternate" href="/spaces/2/articles/11"/>
<link type="application/atom+xml" rel="self" href="/spaces/2/articles/11.atom"/>
<title>title</title>
<content type="html">description</content>
<thr:in-reply-to>36</thr:in-reply-to>
<gd:visibility>public</gd:visibility>
<category term="pr"/>
<category term="tag2132"/>
<category term="tag1113"/>
</entry>

In the Atom interface we can see this mandatory tags:

title
content => maps to text
thr:in-reply-to => Indicates the id of the parent Article when the Article is a
comment. When the Article is the parent one, this field does not appear.
gd:visibility => This is the tag used by the Google API and maps to the SIR public
parameter. It may take the value “public” (which maps the public parameter to
true) and “private” (which maps the public parameter to false).

5.1.5.5 Attachments

Posts may contain attachments. An Attachment is data stored in a file, this can be
any type of file, like an image or a document.

Interface

Attachments is a resource used under the scope of a certain space. Attachments


belong to Articles, and since Articles belong to Spaces, Attachments are also contained in
Spaces.

The interface for Attachments is:

112
Diseño e Implementación de Servicios de Colaboración Basados en Web

HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/attachments index List of all attachments
POST /spaces/:space_id/attachments create Adds a new
attachment
GET /spaces/:space_id/attachments/new new Form for create
GET /spaces/:space_id/attachments/:id/edit edit Form for update
GET /spaces/:space_id/attachments/:id show Shows details of the
attachment with the
determined id
PUT /spaces/:space_id/attachments/:id update Changes details of the
attachment with the
determined id
DELETE /spaces/:space_id/attachments/:id destroy Eliminates the
attachment
Tabla 12: Attachments Interface

Attachment parameters returned by read actions

The parameters which define a Attachment object in the database are:

id
size: the size in bytes of the attachment
content_type: specifies the type of the attachment's content
filename: contains the name of the file attached
height: height of the thumbnail (if any)
width: width of the thumbnail (if any)
thumbnail
db_file_id: identifies the entry in the db_files table which contains the raw bytes of
the file
created_at
updated_at

Therefore, a typical Attachment object structure would be:

113
5. APÉNDICES Rafael García Marín

#<Attachment id: 11, type: nil, size: 1905890, content_type: "image/png", filename:
"Firefox_wallpaper.png", height: 800, width: 1280, thumbnail: nil, db_file_id: 11,
created_at: "2008-10-03 17:27:17", updated_at: "2008-10-03 17:27:17">

In XML the information about the entry mapped to the attachment is also given
(every tag containing the prefix entry):

<attachments>
<attachment>
<content-type>application/x-www-form-urlencoded</content-type>
<created-at type="datetime">2008-10-06T10:59:29+02:00</created-at>
<db-file-id type="integer">12</db-file-id>
<entry-agent-id type="NilClass">1</entry-agent-id>
<entry-agent-type type="NilClass">User</entry-agent-type>
<entry-container-id type="NilClass">2</entry-container-id>
<entry-container-type type="NilClass">Space</entry-container-type>
<entry-content-id type="NilClass">12</entry-content-id>
<entry-content-type type="NilClass">Attachment</entry-content-type>
<entry-created-at type="NilClass">2008-10-06 10:59:29</entry-created-at>
<entry-description type="NilClass" nil="true"/>
<entry-id type="NilClass">60</entry-id>
<entry-parent-id type="NilClass" nil="true"/>
<entry-parent-type type="NilClass" nil="true"/>
<entry-public-read type="NilClass">1</entry-public-read>
<entry-public-write type="NilClass" nil="true"/>
<entry-title type="NilClass">attachment</entry-title>
<entry-updated-at type="NilClass">2008-10-06 10:59:29</entry-updated-at>
<filename>attachment</filename>
<height type="integer" nil="true"/>
<id type="integer">12</id>
<parent-id type="integer" nil="true"/>
<size type="integer">112678</size>
<thumbnail nil="true"/>
<updated-at type="datetime">2008-10-06T10:59:29+02:00</updated-at>
<width type="integer" nil="true"/>
</attachment>
</attachments>

The Atom interface shows only the real information needed, not everything stored
in the database:

<?xml version="1.0" encoding="UTF-8"?>


<feed xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:thr="http://purl.org/syndication/thread/1.0"

114
Diseño e Implementación de Servicios de Colaboración Basados en Web

xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:sir.dit.upm.es,2005:/spaces/2/attachments</id>
<link type="text/html" rel="alternate" href="http://sir.dit.upm.es"/>
<link type="application/atom+xml" rel="self"
href="http://sir.dit.upm.es/spaces/2/attachments.atom"/>
<title>Attachments</title>
<updated>2008-10-06T10:59:29+02:00</updated>
<entry>
<id>tag:sir.dit.upm.es,2005:Attachment/12</id>
<published>2008-10-06T10:59:29+02:00</published>
<updated>2008-10-06T10:59:29+02:00</updated>
<link type="text/html" rel="alternate" href="/spaces/2/attachments/12"/>
<title>attachment</title>
<summary></summary>
<link ref="/spaces/2/attachments/12.atom" rel="edit"/>
<content src="/spaces/2/attachments/12.all"/>
<sir:size>112678</sir:size>
<sir:filename>attachment</sir:filename>
<sir:height></sir:height>
<sir:width></sir:width>
<sir:content_type>application/x-www-form-urlencoded</sir:content_type>
<author>
<name>SIR</name>
</author>
</entry>

</feed>

Attachment parameters needed by write actions

All parameters of a attachment are obligatory for its definition.


An application trying to call a create method from SIR should send this type of
structure:

"attachment"=>{"name"=>"paco", "nickname"=>"pepe"}

115
5. APÉNDICES Rafael García Marín

5.1.5.6 Machines

Machines are representations of computers used to create the network


architecture for meetings held with ISABEL.

Interface

Machines is a resource not used under the scope of a certain space.

Along with the usual REST methods, the machines interface includes one
additional, my_mailer, used when the user needs to request machines to de administrator.
The interface for Machines is:

HTTP
URI RAILS METHOD
METHOD
GET /machines index List of all machines
POST /machines create Adds a new machine
GET /machines/new new Form for create
GET /machines/:id/edit edit Form for update
GET /machines/:id show Shows details of the machine
with the determined id
PUT /machines/:id update Changes details of the machine
with the determined id
DELETE /machines/:id destroy Eliminates the machine
GET /machines/my_mailer my_mailer Used in the contact form used to
ask for more resources
Tabla 13: Machines Interface

Machine parameters returned by read actions

The parameters which define a Machine object are:


name
nickname

116
Diseño e Implementación de Servicios de Colaboración Basados en Web

Therefore, a typical Machine object structure would be:

<Machine id: 7, name: "machine1", nickname: "machine1.domain.com">

In XML:

<machines type="array">
<machine>
<id type="integer">7</id>
<name>machine1</name>
<nickname>machine1.domain.com</nickname>
</machine>
</machines>

The Atom interface shows:

<?xml version="1.0" encoding="UTF-8"?>


<feed xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:localhost,2005:/machines</id>
<link type="text/html" rel="alternate" href="http://localhost:3000"/>
<link type="application/atom+xml" rel="self"
href="http://localhost:3000/machines.atom"/>
<title>Machines</title>
<entry>
<id>tag:localhost,2005:Machine/1</id>
<link type="text/html" rel="alternate" href="/machines/1"/>
<title>machine1</title>
<summary>machine1.domain.com</summary>
<author>
<name>SIR</name>
</author>
</entry>

</feed>

117
5. APÉNDICES Rafael García Marín

Machine parameters needed by write actions

All parameters of a machine are obligatory for its definition.


An application trying to call a create method from SIR should send this type of
structure:

"machine"=>{"name"=>"paco", "nickname"=>"pepe"}

The Atom interface requires:

<?xml version="1.0" encoding="UTF-8"?>


<entry xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:localhost,2005:Machine/1</id>
<link type="text/html" rel="alternate" href="/machines/1"/>
<link type="application/atom+xml" rel="self" href="/machines/1.atom"/>
<title>machinename</title>
<summary>machinenickname</summary>
<sir:assign_to_everybody>true</sir:assign_to_everybody>
<author>
<name>SIR</name>
</author>
</entry>

In the Atom interface we can see this mandatory tags:

title => maps to name.


summary => maps to nickname.
sir:assign_to_everybody => if this parameter is included in the Atom structure, and
set to true, the machine is assigned to every user in the application.

118
Diseño e Implementación de Servicios de Colaboración Basados en Web

5.1.5.7 Groups

Groups are associations of users inside a space. Every space will have a default
group with the same name as the space and it will contain automatically all the users with
roles admin and user within the space. Other groups can also be created in a space.

All groups will create a mailing list with the emails of all the users contained in
them.

Interface

Groups is a resource used only under the scope of a certain space.

The interface for Groups is:

HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/groups index List of all groups
contained in the space
POST /spaces/:space_id/groups create Adds a new group to the
space
GET /spaces/:space_id/groups/new new Form for create
GET /spaces/:space_id/groups/:id/edit edit Form for update
GET /spaces/:space_id/groups/:id show Shows details of the
group with the
determined id
PUT /spaces/:space_id/groups/:id update Changes details of the
group with the
determined id
DELETE /spaces/:space_id/groups/:id destroy Eliminates the group
Tabla 14: Groups Interface

119
5. APÉNDICES Rafael García Marín

Group parameters returned by read actions

The parameters which define a Group object are:

name
space_id
user_ids (parameter contained inside the join table group_users)

Therefore, a typical Group object structure directly from the table groups would
be:

<Group id: 7, name: "group1", space_id: “2”>

In XML:

<groups type="array">
<group>
<id type="integer">7</id>
<name>group1</name>
<space_id type=”integer”>2</space_id>
</group>
</groups>

The Atom interface shows also the information related to the users contained:

<?xml version="1.0" encoding="UTF-8"?>


<feed xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:localhost,2005:/spaces/tres/groups</id>
<link type="text/html" rel="alternate" href="http://localhost:3000"/>
<link type="application/atom+xml" rel="self"
href="http://localhost:3000/spaces/tres/groups.atom"/>
<title>Groups</title>
<updated>2008-10-28T15:36:02+01:00</updated>
<entry>
<id>tag:localhost,2005:Group/996332898</id>
<published>2008-10-28T15:36:02+01:00</published>
<updated>2008-10-28T15:36:02+01:00</updated>
<link type="text/html" rel="alternate" href="/spaces/tres/groups/996332898"/>
<title>tres</title>
<sir:entryLink login="admin" href="http://sir.dit.upm.es/spaces/tres/users/24"/>

120
Diseño e Implementación de Servicios de Colaboración Basados en Web

<sir:entryLink login="adminspace1" href="http://sir.dit.upm.es/spaces/tres/users/30"/>


<sir:entryLink login="rafale" href="http://sir.dit.upm.es/spaces/tres/users/31"/>
<sir:entryLink login="otro" href="http://sir.dit.upm.es/spaces/tres/users/33"/>
<sir:entryLink login="rafaelgmarin" href="http://sir.dit.upm.es/spaces/tres/users/37"/>
<author>
<name>SIR</name>
</author>
</entry>

</feed>

Group parameters needed by write actions

All parameters of a group are obligatory for its definition.


An application trying to call a create method from SIR should send this type of
structure:

"group"=>{"name"=>"group_name"}

The space_id parameter is mapped in the controller directly from the URL used to
call the method.

The Atom interface requires:

<?xml version="1.0" encoding="UTF-8"?>


<entry xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<title>atom group</title>
<sir:entryLink login="login1" href="http://sir.dit.upm.es/spaces/tres/users/31"/>
<sir:entryLink login="login2" href="http://sir.dit.upm.es/spaces/tres/users/33"/>
</entry>

In the Atom interface we can see this mandatory tags:

title => maps to name.


sir:entryLink => This parameter is used to provide the information about the users
contained in the group. There will be one entryLink for each user in the group. It
has two parameters to do this:
o login=> Login of the user
o href => URL mapping the resource representing the user

121
5. APÉNDICES Rafael García Marín

5.1.5.8 Profile

Users should have a profile related to them. The resource Profile is one of those
examples of singular resources.

Interface

Profile is a resource used only under the scope of a certain User.

The interface for Profile is:

HTTP RAILS
URI
METHOD METHOD
POST /users/:user_id/profile create Adds a profile to the user
GET /users/:user_id/profile/new new Form for create
GET /users/:user_id/profile/edit edit Form for update
GET /users/:user_id/profile show Shows details of the profile
PUT /users/:user_id/profile update Changes details of the profile
DELETE /users/:user_id/profile destroy Eliminates the profile
Tabla 15: Profile Interface

Profile parameters returned by read actions

The parameters which define a Profile object are:


name
lastname
organization
phone
mobile
fax
address
city
zipcode
province
country
user_id

122
Diseño e Implementación de Servicios de Colaboración Basados en Web

Therefore, a typical Profile object structure directly from the table Profile would
be:

<Profile id: 1, name: "Pepe", lastname: "Sancho", organization: "Dit", phone: "4546456",
mobile: "6584524", fax: "915478599", address: "Callejeando 2", city: "Madrid", zipcode:
"45236", province: "Madrid", country: "España", user_id: "24">

In XML:

<profile>
<address>Callejeando 2</address>
<city>Madrid</city>
<country>España</country>
<fax>915478599</fax>
<id type="integer">1</id>
<lastname>Sancho</lastname>
<mobile>6584524</mobile>
<name>Pepe</name>
<organization>Dit</organization>
<phone>4546456</phone>
<province>Madrid</province>
<user-id>24</user-id>
<zipcode>45236</zipcode>
</profile>

The Atom interface shows:

<?xml version="1.0" encoding="UTF-8"?>


<entry xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:localhost,2005:Profile/1</id>
<link type="text/html" rel="alternate" href="/users/24/profile"/>
<link type="application/atom+xml" rel="self" href="/users/24/profile.atom"/>
<title>Pepe</title>
<sir:lastname>Sancho</sir:lastname>
<sir:address>Callejeando 2</sir:address>
<sir:city>Madrid</sir:city>
<sir:zipcode>45236</sir:zipcode>
<sir:province>Madrid</sir:province>
<sir:country>Espa&#241;a</sir:country>
<gd:phoneNumber
rel="http://schemas.google.com/g/2005#home">4546456</gd:phoneNumber>
<gd:phoneNumber
rel="http://schemas.google.com/g/2005#fax">915478599</gd:phoneNumber>

123
5. APÉNDICES Rafael García Marín

<gd:phoneNumber
rel="http://schemas.google.com/g/2005#mobile">6584524</gd:phoneNumber>
<gd:organization>
<gd:orgName>Dit</gd:orgName>
</gd:organization>
<author>
<name>SIR</name>
</author>
</entry>

Profile parameters needed by write actions

An application trying to call a create method from SIR should send this type of
structure:

"profile"=>{"name"=>"name", "city"=>"city", "zipcode"=>"12345", "country"=>"country",


"lastname"=>"lastname", "mobile"=>"987654321", "phone"=>"123456789",
"fax"=>"132457689", "organization"=>"org", "province"=>"province", "address"=>"add"}

The user_id parameter is mapped in the controller directly from the URL used to
call the method.

The Atom interface requires at least:

<?xml version="1.0" encoding="UTF-8"?>


<entry xmlns:sir="http://sir.dit.upm.es/schema"
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<title>Pepe</title>
<sir:lastname>Sancho</sir:lastname>
<sir:city>Madrid</sir:city>
<sir:country>Espa&#241;a</sir:country>
<gd:phoneNumber
rel="http://schemas.google.com/g/2005#home">4546456</gd:phoneNumber>
<gd:organization>
<gd:orgName>Dit</gd:orgName>
</gd:organization>
</entry>

In the Atom interface we can see this mandatory tags:

124
Diseño e Implementación de Servicios de Colaboración Basados en Web

 title => maps to name.


 sir:lastname
 sir:city
 sir:country
 gd:organization => includes another tag inside (gd:orgName)
 gd:orgName=> maps to organization in the profile
 gd:phoneNumber => its value is a phone number, the type of phone is indicated by
the rel attribute inside this tag. The only one mandatory is the main telephone.
 rel => indicates the type of number:
■ http://schemas.google.com/g/2005#home => main number

In the Atom interface there are other tags that are not mandatory:

 sir:address
 sir:province
 sir:zipcode
 gd:phoneNumber => its value is a phone number, the type of phone is indicated by
the rel attribute inside this tag. The fax and mobile numbers are not mandatory.
 rel => indicates the type of number:
■ http://schemas.google.com/g/2005#fax => fax number
■ http://schemas.google.com/g/2005#mobile => mobile number

125
Diseño e Implementación de Servicios de Colaboración Basados en Web

Madrid, ___ de ____________________ de 2008

Rafael García Marín

127

S-ar putea să vă placă și