google.elements.newshow es nulo o no es un objeto

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

v

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

vii

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

ix

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.

x

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.

xi

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.

xiii

Í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

xiv

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

15

Í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

17

Í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

xix

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

xx

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

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

21

1 INTRODUCCIÓN


23

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.

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

24

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


25

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.

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

26

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.


27

2 ESTADO DEL ARTE


29

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.

http://es.wikipedia.org/wiki/Internet

http://es.wikipedia.org/wiki/Intranet

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

30

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.


31

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.


32

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


33

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).


34

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.

http://es.wikipedia.org/wiki/Navegador_web


35

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)

http://www.egroupware.org/philosophy


36

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


37

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”.


38

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.


39

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.


40

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


41

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

http://upload.wikimedia.org/wikipedia/commons/9/9c/Ruby_on_Rails_logo.jpg


42

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


43

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.


44

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


45

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


46

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


47

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.


48

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”.


49

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


50

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.

http://es.wikipedia.org/wiki/ActionScript


51

3 MEMORIA


53

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.

3. MEMORIA Rafael García Marín

54

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


55

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”.


56

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.


57

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


58

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


59

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


60

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.


61

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.


62

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


63

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


64

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


65

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


66

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


67

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.

Cliente Servidor

GET /resources.atom

resources.atom

Cliente Servidor

GET /resources/1.atom

resources/1.atom

index show

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


68

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.

Cliente Servidor

POST /resources.atom

resource/1.atom

Cliente Servidor

PUT /resources/1.atom

resources/1.atom

create update

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


69

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.


70

Cliente Servidor

POST /articles.atom

article/1.atom

Artículos con

Attachments

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


71

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).

Cliente Servidor de la Aplicación

POST /groups.atom

group/1.atom

Servidor Jungla

CUD sobre Grupos

ssh touch vcc-groupname

ssh touch vcc-ACTUALIZAR

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.


72

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


73

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


74

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.


75

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.


76

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.


77

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.

4. CONCLUSIONES Rafael García Marín

78

4 CONCLUSIONES


79

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.


80

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


81

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


82

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.


83

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


84

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.


85

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/.


86

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/.

5 APÉNDICES

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

89

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).

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

90

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 METHOD

URI RAILS 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


91

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 METHOD

URI RAILS

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:


92

HTTP METHOD

URI RAILS 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 METHOD

URI RAILS

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


93

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 METHOD

URI RAILS 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

94

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>[email protected]</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>

95

</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.

http://www.w3.org/2005/Atom


96

HTTP METHOD

URI RAILS

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 METHOD

URI RAILS METHOD

GET /spaces index

GET /spaces.:format index

POST /spaces create

97

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: "This is the description"> 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>This is the description</description> <id type="integer">2</id> <name>Space 1</name>

98

<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"=>"this is the description of the space"}

In XML:

99

<space> <description>space description</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.


100

Interface

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

HTTP METHOD

URI RAILS 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:


101

HTTP METHOD

URI RAILS

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:

102

#<User id: 1, login: "admin", email: "[email protected]", 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>[email protected]</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"/>

103

<title>admin</title> <gd:email address="[email protected]" primary="true"/> <gd:email address="[email protected]"/> <gd:email address="[email protected]"/> <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"=>"[email protected]"}

In XML:

<?xml version="1.0" encoding="UTF-8"?> <user> <password>passwordhere</password> <password_confirmation>passwordhere</password_confirmation> <email>[email protected]</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">

104

<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="[email protected]" primary="true" label="email1"/> <gd:email address="[email protected]" primary="false" label="email2"/> <gd:email address="[email protected]" primary="false" label="email3"/> <category term="tag1"/> <category term="tag2"/> <category term="tag3"/> <author> <name>SIR</name> </author> </entry>


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.


105

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 METHOD

URI RAILS

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:

106

#<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.


107

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"}

108

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>


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.


109

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 METHOD

URI RAILS

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

110

updated_at

Therefore, a typical Article object structure would be:

#<Article id: 4, text: "eso", 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>This is the Article text</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>

111

<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">fdsafdsafdsafdsafsda</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


structure:

=> {"article"=>{"title"=>"New Post", "text"=>"Description"}, "tags"=>"", "space_id"=>"Public"}

The Atom interface requires:

112

<?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>


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:


113

HTTP METHOD

URI RAILS

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:

114

#<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"

115

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.


structure:

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


116

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 METHOD

URI RAILS 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

117

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>


<?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>

118

Machine parameters needed by write actions

All parameters of a machine are obligatory for its definition.


structure:

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


<?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>


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.


119

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 METHOD

URI RAILS

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

120

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"/>

121

<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.


structure:

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

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

call the method.


<?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>


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


122

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 METHOD

URI RAILS

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

123

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>


<?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ñ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>

124

<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


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ñ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>


125

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


127

Madrid, ___ de ____________________ de 2008

Rafael García Marín