Documente Academic
Documente Profesional
Documente Cultură
Desarrollo e Implementación de un
Sistema de Colaboración Web con
Metodología Ágil
Calificación
Resumen
Palabras Clave
Internet, Web 2.0, Ruby on Rails, Atom, REST, CMS, SIR, Modelo-Vista-
Controlador, Ágil, Flex
v
Abstract
Alongside the new Internet, we find the paradigm of what it is being called Web
2.0. This concept relates to all applications and Internet services sustained on a database,
which can be modified by users of the service not only in its content but in the way they
are presented. This main characteristic of Web 2.0 is what has developed a social
revolution regarding the user of internet.
The main subject in the Web is the user, and this explains the massive user of
applications called “social networks”. Based in knowledge sharing and total interactivity
between users and applications, the business world is beginning to regard this movement
as a great working tool.
This project sustains over this concepts. The most important are the use of
technologies highly related to this new movement in internet such as Ruby on Rails, and
the necessity of user interfaces much more powerful and useful. This is way Flex is
developed as a Flash evolution and a programming language. Connecting a Flex client
application and a Rails server will be done by using Atom Syndication Format and Atom
Publishing Protocol as main standards of what an application interface should be when
based on RESTful Web Services.
Key Words
Internet, Web 2.0, Ruby on Rails, Atom, REST, CMS, SIR, Model-View-
Controller, Agile, Flex
vii
Agradecimientos
Y es que no podía ser de otra manera. Mi proyecto debe comenzar con una sección
interminable de agradecimientos, como viene siendo habitual en los PFCs de los
isabelinos. Seguramente sea la única parte que se vaya a leer de este pedazo de PFC, y por
ello es el texto más trabajado y pensado de todo el libro.
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.
Sin embargo, sí que puedo nombrar uno a uno cada uno de los isabelinos, porque
son los que más han tenido que ver en el proyecto, porque han estado ahí conmigo en
este sprint final, y porque sé cuántos son y no se me va a olvidar ninguno. Secáos las
lagrimillas porque ahora viene lo bueno.
ix
Primero quiero nombrar a los que ya no están en la beca. Alfredo por ser el más
modernito y el que más partido saca a su pelo, y porque hackear la coctelera nunca fue tan
fácil. Jubun, porque los screencasts ya no son lo mismo sin David Jubunemeier. A J. Ágora,
porque nunca vi persona que hablara menos. Al gran Fonta, porque no tengo palabras
para describir tanta genialidad junta, y probablemente se quedaría dormido mientras las
busco. Y por supuesto, no me voy a olvidar de él, a Pabluto, iniciador de este trabajo y
maestro del “cómo ser ingeniero con un proyecto de proyecto”, al cual si le buscáis y no le
encontráis, ya sabéis por qué es. Es que está con Estefi. Por cierto, ¿dónde está Estefi?
Pabluto… ¿dónde está Estefi?
x
Y a los que se creen mejores porque están dentro del cubículo del que siempre se
olvidan la llave. A Emilio, porque siempre siga en modo juguetón, porque el rabo está muy
bueno (el de toro) y porque el cine doblado es una mierda. A Fernando, porque nunca
deberé cruzarme con él en una reunión si quiero seguir con vida. A Barce, porque gracias a
él ya casi sé pilotar aviones comerciales (casi). A Jaime porque da gusto verle, siempre con
una sonrisa. A Vicen, el revolucionario, porque gracias a él hacer una tesis y ser isabelino
ya no será incompatible (¿o lo seguirá siendo?). A Sandra, para que nunca se quede sin
agua en la nevera. Y también por supuesto, al gran vegano, enmarronador de
enmarronadores, Abel, porque nunca pensé que no comer carne fuera tan divertido (para
los demás, claro). Y no se me olvida, a Enjuto Heinemeier, por ser el más grande de todos
los screencasts, y porque nunca se hará uno mejor.
Y 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.
xi
Índice de Contenido
1 INTRODUCCIÓN ............................................................................................... 21
3 MEMORIA ....................................................................................................... 51
xiii
3.3 Diseño e Implementación .......................................................................... 63
4 CONCLUSIONES ............................................................................................... 78
5 APÉNDICES ...................................................................................................... 87
xiv
Índice de Imágenes
15
Índice de tablas
17
Glosario
xix
RFC Request For Comments
xx
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
1 INTRODUCCIÓN
21
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
1.1 Introducción
Este primer capítulo está dedicado a explicar el marco que engloba al presente
Proyecto Fin de Carrera, con el objetivo de situar a éste en su contexto, permitiendo al
lector comprender mejor su alcance y envergadura. Para ello se hará una breve explicación
del estado actual de las aplicaciones existentes sobre trabajo colaborativo y los
procedimientos de la metodología ágil. Así mismo en este capítulo se detallarán los
objetivos del proyecto y la estructura del documento.
23
1. INTRODUCCIÓN Rafael García Marín
Es por ello que Ruby on Rails es muy adecuado para el desarrollo de aplicaciones
Web 2.0.
1.1.2 Objetivos
24
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
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.
25
1. INTRODUCCIÓN Rafael García Marín
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”.
26
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
27
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
29
2. ESTADO DEL ARTE Rafael García Marín
Isabel
30
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
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
31
2. ESTADO DEL ARTE Rafael García Marín
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.
Lotus
Lotus es una herramienta integrada de Lotus Software (filial de IBM) que está
compuesta por varias aplicaciones para gestión del trabajo colaborativo. Es una aplicación
muy utilizada por empresas de todo el mundo. Se trata de un sistema cliente – servidor (la
32
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
parte servidor recibe el nombre de Domino, la parte cliente es Notes). Permite enviar
correos electrónicos, manejar calendarios y agendas, compartir bases de datos de
información ya sean documentos, manuales o foros de discusión, y también sirve de
plataforma de coordinación con flujos de trabajo (workflows).
33
2. ESTADO DEL ARTE Rafael García Marín
BSCW
Open-Xchange
34
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
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.
35
2. ESTADO DEL ARTE Rafael García Marín
La aplicación MIR como se puede ver no es más que una herramienta para
gestionar las sesiones de la aplicación ISABEL. Sin embargo, su versión posterior, la
36
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
37
2. ESTADO DEL ARTE Rafael García Marín
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.
38
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
39
2. ESTADO DEL ARTE Rafael García Marín
40
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
usuario. Se enfatiza el hecho de que los sistemas deberían hacer hincapié en las
necesidades del hombre más que en las de la máquina. De hecho Matsumoto afirma que
su primer objetivo en cuanto al diseño de Ruby era crear un lenguaje que él mismo
disfrutara usando, minimizando el trabajo del programador y las confusiones posibles.
Entre las grandes ventajas del lenguaje, destacar su flexibilidad para funcionar en
múltiples paradigmas. Actualmente su gran difusión se debe a la creación del framework
Rails para la creación de aplicaciones web.
Ruby utiliza un sistema propio para gestionar paquetes que provee un formato
estándar para distribuir programas escritos en Ruby y librerías. El formato en el que se los
programas son contenidos recibe el nombre de “gema” (gem). La herramienta que
gestiona estas gemas es RubyGems. Actualmente, es parte de la versión estándar 1.9 de
Ruby. El framework Rails se instala como una gema, al igual que muchas otras
herramientas utilizadas en el desarrollo del presente proyecto.
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.
41
2. ESTADO DEL ARTE Rafael García Marín
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).
42
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
describir estas relaciones que de otra manera no tendría que haber hecho. Todo el
framework Rails se basa en este hecho. Por lo tanto, un programador experimentado y
conocedor de todos los convenios de Rails es capaz de programar aplicaciones con gran
rapidez y agilidad. Esto puede ser un impedimento al principio para un desarrollador
nuevo en el lenguaje, pero es una gran recompensa para los programadores que aprenden
el framework.
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.
43
2. ESTADO DEL ARTE Rafael García Marín
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).
“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)
Para el acceso a los recursos, REST promulga la necesidad de tener URLs claros que
los identifiquen. Por ejemplo, si tuviéramos un avión Boeing 747 y quisiéramos acceder a
él, la compañía puede haber definido el recurso con la siguiente URL:
http://www.boeing.com/aircraft/747
Accediendo a este URL se nos devuelve una representación del recurso avión
Boeing 747 (por ejemplo, la página Boeing747.html). El resultado de pulsar en algún link
dentro de esta página es que vamos a acceder a otro recurso. Esta nueva representación
44
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
1. La clave para crear servicios web en una red REST (como el Web) es identificar
todas las entidades conceptuales que se quieran exponer como servicios.
2. Crear un URL para cada recurso. Los recursos deberían ser sustantivos, nunca
verbos. Por ejemplo, no se debería usar:
http://www.parts-depot.com/parts/getPart?id=00345
Hay que notar el verdo, getPart. En lugar de eso se debe usar un nombre:
http://www.parts-depot.com/parts/00345
3. Hay que categorizar los recursos de acuerdo a si los clientes quieren recibir una
representación del recurso, o si deben poder modificar o añadir un recurso. Para el
primer caso, los recursos deben ser accesibles por HTTP GET. Para el segundo caso,
los recursos deben ser accesibles por HTTP POST, PUT o DELETE.
4. Las representaciones de los recursos no deberían ser objetos aislados del exterior.
Es decir, hay que poner enlaces dentro de los recursos para acceder a otros
recursos de forma que los clientes puedan acceder a más información o para
obtener información relacionada con el recurso.
5. Todos los recursos accedidos por HTTP GET deberían evitar ser modificados en
cualquier caso. Esto es, mediante HTTP GET sólo se debe acceder a una
45
2. ESTADO DEL ARTE Rafael García Marín
representación del recurso, para modificar un recurso tenemos que usar los otros
métodos HTTP.
6. Se debe diseñar para revelar datos de forma gradual. No se debería entregar toda
la información dentro de un mismo documento de respuesta. Es mejor proveer
enlaces dentro del recurso para acceder a más detalles.
7. Se debe especificar el formato de los datos accedidos usando algún esquema. Para
aquellos servicios que requieran un POST o un PUT, además hay que proveer un
esquema para especificar el formato de la respuesta.
8. Hay que describir cómo se invocan los servicios ya sea usando un documento
WSDL o simplemente un documento HTML.
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.
Los sitios Web usan feeds para permitir que programas externos puedan
comprobar automáticamente si hay actualizaciones publicadas dentro del sitio web. Para
46
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
proveer un web feed, el dueño de un sitio debe usar un software especializado que
publique una lista (o “feed”) de artículos recientes o contenidos en un formato
estandarizado y legible por una máquina. Los feeds pueden ser descargados por sitios web
que sindiquen contenido desde el feed o por lectores de feeds que permiten a los usuarios
de internet suscribirse a los feeds y leer su contenido. Un feed puede contener entradas
(entries), que pueden ser títulos, textos completos, descripciones, resúmenes o enlaces al
contenido en un sitio web, así como metadatos asociados a las entradas o recursos.
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)
Existirán dos tipos de documentos Atom: los Atom Feed Documents y los Atom
Entry Documents. Un Atom Feed Document es una representación de un Atom Feed,
incluyendo metadata sobre el feed y sobre algunas o todas las entradas que están
asociadas a él. Un Atom Feed Entry representa exactamente un único Atom Entry, fuera
del contexto de un Atom Feed.
47
2. ESTADO DEL ARTE Rafael García Marín
Cada una de las dos estructuras tiene un esquema parecido. Contienen una serie
de elementos obligatorios y opcionales. Tanto el Feed como el Entry tendrá una cabecera
que indicará el idioma del documento y varios namespaces asociados. Por defecto, el
namespace a utilizar en cualquier documento será el de Atom,
“http://www.w3.org/2005/Atom”. Este namespace contiene las reglas para todas las
construcciones que se utilizan en el Atom Syndication Format de forma básica. Sin
embargo, Atom es extensible y se pueden utilizar otros namespaces para ampliar las
definiciones de las construcciones y usar otras nuevas.
SIR namespace:
Aún utilizando los namespaces de Atom y las extensiones de Threading y GData,
algunos de los campos de los recursos de SIR, debido a su peculiaridad programática
y a que cuando se escribió la aplicación no se pensó en integrarla con Atom, no se
pueden mapear. Esto implica que durante el diseño del interfaz Atom se tuvo que
tomar la decisión de crear un namespace propio para todos esos campos. El
namespace es “http://sir.dit.upm.es/schema”.
48
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
2.2.4 Flex
49
2. ESTADO DEL ARTE Rafael García Marín
En un modelo multicapa como es el caso que nos ocupa, la aplicación Flex servirá
de capa de presentación. Al contrario que las páginas basadas en HTML, las aplicaciones
en Flex proveen un cliente basado en estados que no requiere recargar nuevas páginas.
Flex utilizará HTTPRequests para acceder a los recursos del SIR usando el paradigma de los
RESTful Web Services.
50
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
3 MEMORIA
51
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
53
3. MEMORIA Rafael García Marín
54
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
Debido a que los requisitos son muy cambiantes y a veces incluso pueden llegar a
ser contradictorios entre sí, la metodología en espiral sigue siendo demasiado rígida para
este caso concreto. Finalmente se decidió usar un modelo que es idóneo para nuestras
necesidades gracias a lo flexible y permisivo que es. Se trata de la Metodología Ágil de
Programación.
55
3. MEMORIA Rafael García Marín
Valorar más a los individuos y su interacción que a los procesos y las herramientas
Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los
principios que de ellos se derivan: (8)
56
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
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.
57
3. MEMORIA Rafael García Marín
58
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
59
3. MEMORIA Rafael García Marín
La conexión entre los lados Flex y Rails se hace mediante los métodos del interfaz
de aplicación siguiendo la filosofía de los RESTful Web Services. Las vistas en Flex harán
peticiones a la aplicación Rails, que devolverá un resultado, y la parte Flex se encargará de
su presentación al usuario, al igual que hacían las vistas en HTML, pero con mayor
complejidad. Flex permite hacer aplicaciones web de gran complejidad, no solo la simple
presentación de datos con un interfaz de usuario. Es por ello que realmente, el lado Flex es
una aplicación en sí misma que utiliza el lado Rails como un recubrimiento de la base de
datos. Así, las dos partes se pueden considerar como una sola aplicación en sí mismas por
separado, y a la vez una aplicación completa cuando interactúan.
60
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
Figura 18: Arquitectura de una aplicación Web con Rails y Flex con un interfaz Atom
61
3. MEMORIA Rafael García Marín
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.
62
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
que aparecen en función del número de veces que las hayan utilizado. Por último, los
grupos son conjuntos de usuarios dentro de un espacio. Estos grupos sirven como listas de
correo.
Cada uno de los recursos tendrá un interfaz CRUD asociado (Create, Read, Update,
Delete) tal y como manda el paradigma de los RESTful Web Services. Para el correcto
funcionamiento de la aplicación, estos interfaces ofrecen una serie de parámetros
concretos sobre cada recurso que son necesarios, tanto para operaciones de lectura como
de escritura, y que si no se manipulan adecuadamente, la comunicación entre los distintos
agentes (Rails y Flex en este caso) no es posible. La documentación exacta y exhaustiva de
los interfaces es también objeto del presente proyecto fin de carrera y se puede encontrar
en los Apéndices, ya que la información es demasiado técnica y densa como para incluirla
dentro de la memoria del proyecto.
3.3.1 Refactoring
63
3. MEMORIA Rafael García Marín
contará el proceso de forma resumida y se omitirán los nombres concretos de los métodos
tal y como estaban antiguamente, puesto que no tienen mucha relevancia.
Lo primero fue cambiar las rutas anidadas a espacios de toda la aplicación, que
antes se hacían de la forma /:container_type/:container_id/…, con parámetros (lo que van
con un prefijo formado por dos puntos) y esas ya no servían. Esto es principalmente
porque el CMSPlugin utilizaba antes rutas anidadas a contenedores de forma genérica. A la
vez que se hacía el refactoring del SIR, el plugin cambió estas rutas puesto que era
demasiado complicado tener rutas tan genéricas cuando al final realmente sobre lo único
que se anidaba como primer contenedor era sobre espacios. Por ello, se cambiaron a la
forma /spaces/:space_id/…. Con estas nuevas rutas no es necesario especificar el tipo de
contenedor, puesto que siempre es un espacio, y el parámetro id del contenedor pasa a
ser un id del espacio. Al principio como id se usó un parámetro numérico (id en la base de
datos) como identificador de los espacios. Más tarde esto se sustituyó por nombres de los
espacios completos. De esta forma, las rutas se hicieron inteligibles.
64
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
servían para realizar acciones con AJAX de forma que se enseñara información sobre cada
evento, pero sin llegar a recargar la página. Antes se llamaban directamente con la ruta y
cada método. Ahora, y siguiendo la arquitectura REST, esta lógica está incluida dentro de
los métodos correspondientes (por ejemplo, si se trata de leer información sobre un
evento concreto, se incluyó dentro del método show) y mediante el mecanismo de
respuesta al formato (el método respond_to) se llama a las vistas correspondientes de
AJAX. Esto quiere decir, por ejemplo, que si se hace una llamada a un método que
renderiza una vista con componentes javascript, en vez de llamar a ese método, la lógica
de renderizar esa vista concreta se incluye dentro del método REST correspondiente y la
llamada del método se traduce a una URL de REST añadiento el formato “.js”. El
respond_to se encarga de comprobar que efectivamente se trata de una llamada
javascript y renderiza la vista concreta. Esto no sólo sucede para las llamadas a métodos
de javascript, se produce también para llamadas a archivos con formatos como “.txt”,
“.ical” o “.xedl”. Algunos de ellos son formatos MIME estándar, otros se usan en la
aplicación ISABEL para gestión de sesiones de videoconferencia. En todos los casos se
procede de la misma forma, añadiendo el formato al respond_to y renderizando el
documento correspondiente en cada caso. Otros métodos del controlador de eventos que
no siguen la filosofía REST, no se han modificado puesto que sólo se usan para
funcionalidades muy concretas dentro de las vistas en HTML y no tiene sentido ofrecer su
funcionalidad en un interfaz para integración con otras aplicaciones. Estos son en su
mayoría, métodos de ayuda en formularios, como en el caso de los eventos, para
seleccionar varias fechas a la hora de crear un nuevo evento, para copiar la fecha de un
evento para la semana siguiente o funcionalidades similares.
65
3. MEMORIA Rafael García Marín
filosofía REST. Además, el controlador incluía métodos que contenían lógica para el envío
de emails para pedir recursos al administrador del sistema. Estos métodos se movieron al
controlador que se encarga del envío de emails en el SIR.
Una vez que el interfaz REST estaba completado, se procedió a construir las
terminaciones Atom de los métodos.
La base de la construcción del interfaz Atom nos la ofrece el CMSPlugin. Este plugin
es un módulo para Rails desarrollado por Antonio Tapiador del Dujo, dentro del
Departamento de Ingeniería Telemática, y que sirve de estructura principal para el SIR. El
plugin ofrece toda la funcionalidad necesaria para construir una aplicación CMS (Content
Management System o Sistema de Gestión de Contenido) incluyendo clases para
autenticación, creación y organización de tags, filtros de autorización o gestión de
contenidos y contenedores entre otras cosas. El plugin además incluye dentro de sí mismo
librerías de Ruby que son útiles en el desarrollo del SIR, la más importante y que nos ocupa
en este momento es la librería de atom-tools. Esta librería provee clases y métodos para
manipular objetos mapeando estructuras en Atom. Con estos métodos podemos construir
los feeds de Atom, y también podemos extraer parámetros de un feed de Atom que
recibamos en SIR (lo que vulgarmente se conoce como “parsear”).
Como hemos explicado previamente, hay dos partes funcionales del interfaz Atom,
una de lectura y otra de escritura. El interfaz de lectura es el que se refiere a los métodos
que se relacionan directamente con los métodos GET de HTTP. Éstos son el index y el show
en Rails. El index es un HTTP GET sobre la colección, nos da información sobre todos los
recursos. El show es un HTTP GET sobre el miembro, es decir, sólo nos da información
sobre un miembro concreto, por lo que se debe pasar un parámetro que identifica al
66
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
recurso o miembro concreto del que queremos información. Llamando a estos métodos
añadiendo “.atom” al URL, invocamos al interfaz en Atom, por lo que las respuestas que se
consiguen son documentos en formato Atom, en este caso y por ser de lectura, basados en
el protocolo Atom Syndication Format.
index show
resources.atom resources/1.atom
Figura 19: Esquema de secuencia de peticiones para los métodos de lectura index y show
De esta forma para cada recurso y cada método, se mapean todos los atributos de
los recursos y sus campos en la base de datos y con ellos se construye cada vista. Es
responsabilidad del programador el incluir los campos y tags XML concretos para
conseguir que los feeds y entries de Atom sean válidos siguiendo las especificaciones del
protocolo Atom Syndication Protocol. Por lo tanto, con estas prerrogativas se construyen
los archivos index.atom.builder y show.atom.builder para cada recurso, constructores de
feeds en el primer caso y entries en el segundo, teniendo cuidado que se cumple el
protocolo y comprobando en cada caso que el contenido sindicado entregado es válido
67
3. MEMORIA Rafael García Marín
según la RFC. Para ello se utilizó un servicio del W3C de validación de feeds de Atom
mediante web, introduciendo el resultado de cada llamada a métodos de lectura
directamente en dicha página. (9)
La otra parte del interfaz, la de escritura, es la que se refiere a los métodos “de
entrada” al SIR. Éstos son los métodos que se mapean con las llamadas POST, PUT y
DELETE de HTTP, es decir, los métodos create, update y destroy respectivamente. El
método create es un POST sobre la colección mientras que los métodos update y destroy
son un PUT y un DELETE respectivamente pero sobre un miembro concreto de la
colección. Además, los métodos create y update esperan un documento en Atom
conteniendo los parámetros de creación específicos de un recurso. El método destroy no
necesita ningún parámetro específico más que el parámetro identificativo del miembro al
que se refiere, pero en ningún caso hace falta incluir un documento en Atom junto con la
llamada. De hecho, el paquete HTTP con método DELETE no acepta contenido dentro de
su cuerpo.
create update
resource/1.atom resources/1.atom
Figura 20: Esquema de secuencia de peticiones para los métodos de escritura, create y update
Para la parte funcional de escritura hay que construir la lógica que extrae
parámetros útiles de los documentos Atom que recibe el SIR. Esta funcionalidad nos la
ofrece el CMSPlugin, con métodos que proveen una arquitectura lógica entre clases para
poder recibir los datos de un documento en Atom y extraer su contenido. De esta forma,
en la clase correspondiente al modelo de cada recurso se debe añadir al comienzo el
comando set_params_from_atom. Esto llama a un método del plugin de forma que
cuando llega una llamada con contenido Atom, la aplicación lo detecta y manda
directamente el contenido del documento a un método de la clase del modelo
correspondiente. Este método es el atom_parser. Dentro de ese método se recogen los
68
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
datos que devuelve el plugin en forma de objeto REXML (objeto que recubre estructuras
en XML en lenguaje Ruby) . Estos objetos REXML contienen métodos para sacar los datos,
dependiendo del tag que los recubre y el namespace que contiene a cada tag. Al final de
ese método, se devuelve un array de parámetros (params[]) que es lo que recibe el
método correspondiente (create o update) con los datos necesarios. Este array de
parámetros es exactamente igual que los que generan los formularios en HTML. De hecho,
para definir cuáles son los parámetros que se debían enviar dentro de cada Atom, se
observó qué es lo que se enviaba en cada formulario de los métodos create y update para
cada tipo de recurso. Estos parámetros concretos están detallados dentro de la
documentación sobre el interfaz Atom que se incluye en los Apéndices de este libro.
69
3. MEMORIA Rafael García Marín
Artículos con
Attachments Servidor
Cliente
POST /articles.atom
article/1.atom
attachment/1.atom
attachment/1.atom
70
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
todos sus miembros. Además de esto se pueden crear otros grupos con nuevas conjuntos
de usuarios del espacio.
POST /groups.atom
ssh touch vcc-ACTUALIZAR
group/1.atom
ssh touch vcc-groupname
Siempre que se llame a uno de los métodos Create, Update y Delete (CUD) sobre
Grupos, se producirán cambios en el servidor de jungla. Esta funcionalidad, debido a lo
delicado que resulta estar modificando un servidor externo que está dedicado a la
administración de listas de correo de todo el departamento, únicamente funciona cuando
la aplicación está en modo producción, de forma que crear grupos en desarrollo no
produce llamadas al servidor jungla.
71
3. MEMORIA Rafael García Marín
3.4 Pruebas
Hablaremos ahora de las pruebas que se realizaron sobre los cambios en el interfaz
de aplicación del SIR y las nuevas funcionalidades añadidas.
Antes del desarrollo del presente proyecto fin de carrera, el SIR contaba con
numerosos tests para probar el funcionamiento del código implementado a nivel de
clases, tanto de controladores como de modelos. Estos tests pasaban perfectamente y
aseguraban el buen funcionamiento de dichas clases antes de afrontar todos los cambios.
Una vez que empezaron a modificarse todas las rutas de la aplicación y creando el interfaz
REST, todos estos tests se rompieron y tuvieron que rehacerse de nuevo. Esto implicó
reescribir todas líneas de código de los tests para arreglar todas las llamadas y rutas que
habían quedado desactualizadas.
Estos tests incluyen varios tipos de pruebas, unitarias para probar los modelos y
funcionales para los controladores. Las unitarias están situadas dentro del directorio unit,
las funcionales se encuentran dentro del directorio functional. Existe un directorio fixtures
donde se especifican datos de prueba para la base de datos que se utilizarán en los tests.
Estos archivos tienen un formato especial, el YAML. Cada vez que se ejecutan los tests, el
framework carga sobre la base de datos de test toda la información contenida dentro de
los archivos YAML, de forma que cada ejecución es independiente y se prueba con
seguridad.
Las nuevas funcionalidades, sin embargo, se desarrollaron con las nuevas rutas ya
en un funcionamiento y esto permitió experimentar con una forma de implementación
que está siendo muy utilizada por la comunidad de programación que defiende a las
metodologías ágiles de programación. Son las llamadas TDD y BDD.
72
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
También se ha usado la herramienta Rcov. Es una gema de Ruby que se utiliza para
ejecutar los tests y que indica qué porcentaje del código se ha cubierto con los test, y
muestra en HTML el código de las clases probadas, con colores, verde si la línea se ejecutó
y rojo si no. Sin embargo, los resultados no son realmente definitivos, puesto que en
muchos casos se puede crear un test que simplemente recorra el código pero no pruebe
su funcionalidad. Esto no serviría de nada y además invalidaría el valor de medida. De
73
3. MEMORIA Rafael García Marín
todas formas, es una herramienta bastante estimativa, que ayuda a tener más o menos
claro qué partes del código se han cubierto con test y cuáles no.
3.5 Despliegue
74
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
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
75
3. MEMORIA Rafael García Marín
3.5.3 Capistrano
3.6 Documentación
76
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
77
4. CONCLUSIONES Rafael García Marín
4 CONCLUSIONES
78
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
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.
79
4. CONCLUSIONES Rafael García Marín
Por último, el problema fundamental para el buen desarrollo del interfaz Atom ha
sido el hecho de que el lado Flex de la aplicación final se ha llevado a cabo en un momento
distinto al desarrollo de este proyecto y por lo tanto, se ha echado en falta la
realimentación vital que hubiera arrojado el desarrollo de la capa Flex para una mejor
definición de los parámetros y los interfaces Atom desarrollados.
4.2 Conclusiones
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 conocimientos adquiridos han sido muchos y muy variados. En primer lugar, he
profundizado mucho en el área de la programación orientada a objetos, además de
aprender el lenguaje Ruby y su framework Rails, desconocidos para mí antes del comienzo
del proyecto. En segundo lugar he aprendido otras tecnologías y conceptos como Atom,
REST, Apache y he usado herramientas y entornos de programación como Eclipse y
RadRails. A esto hay que unir que todo el trabajo se ha desarrollado sobre sistemas UNIX,
concretamente distribuciones de Linux (Ubuntu Debian), y esto también ha sido muy
interesante como aprendizaje del sistema operativo y de muchos comandos básicos y
avanzados que se utilizan. Además, hemos utilizado bases de datos como MySQL, que
80
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
también supone una primera aproximación en cuanto al aprendizaje sobre bases de datos
se refiere.
Por otra parte, el hecho de haber trabajado con código escrito previamente por
otros desarrolladores ha hecho que entienda la importancia de mantener una
documentación de calidad y actualizada sobre el código escrito para permitir a otros
desarrolladores su reutilización con el mínimo esfuerzo posible. Esto y el enfrentamiento a
los problemas que han ido apareciendo durante todo el desarrollo suponen una gran
experiencia para poder evitar en el futuro que se produzcan otros parecidos. Como
conclusión de este hecho se aprende lo fundamental que es tener un código robusto y
probado continuamente mediante tests de calidad.
En resumen, el desarrollo del Proyecto Fin de Carrea ha sido un éxito ya que se han
cumplido los objetivos, tanto a nivel del proyecto como a nivel personal, y se han
adquirido conocimientos muy útiles que suponen una primera experiencia profesional
para el alumno.
Repositorio de documentos
Esta es una de las funcionalidades que ya se han planteado para el futuro a corto
plazo. Se trata de hacer que el SIR tenga un lugar virtual donde se almacenen documentos,
ya no sólo a nivel de posts con attachments como se realiza actualmente, sino con una
estructura virtual de directorios con permisos y roles asociados a los espacios en los que se
encuentra cada repositorio. De esta forma, cada espacio tendría un repositorio de
documentos asociado, y únicamente los usuarios miembros de dicho espacio tendrían
81
4. CONCLUSIONES Rafael García Marín
acceso a los documentos contenidos en el espacio. Además, dependiendo del rol de cada
usuario y de sus permisos, cada uno podría crear un directorio nuevo, leer, editar o borrar
archivos ya existentes o añadir otros nuevos.
Todo esto debería ser implementado con la misma filosofía de recursos REST que
tiene la aplicación SIR. Por ello, su creación requeriría la construcción de dos nuevos
recursos, uno llamado Document o similar, y otro llamado Directory. El primero de ellos y
como su nombre indica se referiría a los documentos, el otro, a los directorios. En primera
aproximación, cada recurso Document estaría contenido en un Directory, y se crearían
rutas anidadas del tipo /space/space_id/directory/directory_id/document.
Subespacios
82
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
Historial de acciones
Una de las posibilidades interesantes que ofrece el hecho de integrar SIR junto con
el resto de aplicaciones del departamento así como la estructura del LDAP es el hecho de
poder integrar la aplicación de videoconferencias Marte dentro del SIR. Esta tarea es
83
4. CONCLUSIONES Rafael García Marín
complicada, sin embargo, una vez que la integración con LDAP se lleve a cabo, el hecho de
que el sistema de usuarios y autorizaciones que usan ambas aplicaciones sea el mismo
hará mucho más sencilla su integración.
La idea es que cada espacio tenga salas asociadas de la aplicación Marte. Así, los
usuarios dentro del mismo espacio podrán entablar conversaciones en tiempo real. Esto
añade funcionalidades síncronas al SIR que ahora mismo no tiene puesto que es una
aplicación Groupware de tipo asíncrono. Además, añadiría la funcionalidad de presencia,
cada usuario sabría en cada momento quién está conectado al mismo tiempo.
Internacionalización
Para lograrlo se puede usar un plugin que tiene Rails llamado globalize.
Una posible opción de mejora es reescribir todos los tests usando rspec. Rspec
cumple las mismas funciones que la suite de testing que viene de base con Rails, pero
además ofrece otras opciones para aumentar la calidad del testing. La forma de escribir los
tests con rspec es más natural e intuitiva, y permite el uso de cucumber, un plugin que
permite escribir los tests como si fueran casos de uso directamente (user stories). Este
hecho va en sintonía con la filosofía BDD y aumenta la experiencia y la calidad del uso de
metodologías ágiles de programación. De hecho, los tests de integración son mucho
mejores que los tests de integración básicos que vienen de base con Rails.
84
Desarrollo e Implementación de un Sistema de Colaboración Web con Metodología Ágil
4.4 Bibliografía
1. Open-Xchange. Open-Xchange: Community Area. [En línea] http://www.open-
xchange.com/header/community_area.html.
3. Costello, Roger L. Building Web Services the REST Way. [En línea]
http://www.xfront.com/REST-Web-Services.html.
85
4. CONCLUSIONES Rafael García Marín
20. Hasson, David Heinemier. Agile Web Development With Ruby on Rails. s.l. :
Pragmatic Proggramer. ISBN 097669400X.
22. Aptana. Aptana IDE para el desarrollo de RoR. [En línea] http://www.aptana.com/.
86
5 APÉNDICES
Diseño e Implementación de Servicios de Colaboración Basados en Web
5.1.1 Introduction
The SIR application is designed using the REST approach. This means that
everything in the application is a “resource”.
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.
This document explains how to manage resources from SIR. Each type of resource
is explained on its own, includes a list of its REST methods and how to call them, and also
the parameters which define the attributes of the resource.
These parameters are needed when performing a write action (create or update).
Also, when calling to a read action (index or show) the resource is returned with all its
parameters. There are fewer parameters needed when performing a write action than
those returned by a read action. This is because some of these parameters are determined
automatically when the write action is done (usually depending on the date or the order of
creation).
89
5. APÉNDICES Rafael García Marín
A RESTful application has an API very well determined and almost standard for
every application. There are 7 methods to manage resources:
HTTP
URI RAILS METHOD
METHOD
GET /resources index List of all resources
POST /resources create Adds a new resource
GET /resources/new new Form for create
GET /resources/:id/edit edit Form for update
GET /resources/:id show Shows details of the resource with
the determined id.
PUT /resources/:id update Changes details of the resource
with the determined id.
DELETE /resources/:id destroy Eliminates the resource with the
determined id.
Tabla 1: REST Resources
The main 4 actions are show, create, update and destroy. These 4 actions are the
main methods of a CRUD interface (Create, Read, Update, Delete). The index action is a
“show” call but instead of only one resource, a list of all of them. The remaining 2
methods, new and edit, are calls to forms which gather the parameters needed by the
create and update methods.
When a GET or a DELETE HTTP message is sent, there are no parameters needed,
but when the method is a POST or a PUT, because we are creating or updating certain
resource, we need to include the information related to the resource attributes. If any
parameter is to be sent in a GET message, it would be included in the URI, because a HTTP
packet for a GET message doesn't have any body containing information.
When the information is required in a specific format, the URI needs to include the
extension of this format. This way, if we wanted a list of all the resources in XML, we
should perform a GET method to the URI /resources.xml
90
Diseño e Implementación de Servicios de Colaboración Basados en Web
Resources can also be nested. This way, if we had a resource called “message”
which is contained into a “space” resource, the URIs for the REST methods will nest too,
and the table would be:
HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/messages index List of all messages
contained in the space
POST /spaces/:space_id/messages create Adds a new message to the
space
GET /spaces/:space_id/messages/new new Form for create
GET /spaces/:space_id/messages/:id/edit edit Form for update
GET /spaces/:space_id/messages/:id show Shows details of the
message with the
determined id in the
determined space
PUT /spaces/:space_id/messages/:id update Changes details of the
message with the
determined id in the
determined space
DELETE /spaces/:space_id/messages/:id destroy Eliminates the message
with the determined id in
the determined space
Tabla 2: Nested resources in REST
In this particular case, :space_id indicates the id number to identify a certain space.
There is also a particular type of resource which is always singular. This means that
certain methods don't make sense for this type of resource. The index method, which
returns a list of all resources, is eliminated from the list, in the case of a singular resource,
the only read option we will have is the show method. Also, its important to know that the
URI is composed of the name of the resource but this time in singular, not in plural as done
before. The table this time is:
91
5. APÉNDICES Rafael García Marín
HTTP
URI RAILS METHOD
METHOD
POST /resource create Adds a new resource
GET /resource/new new Form for create
GET /resource/edit edit Form for update
GET /resource show Shows details of the resource
PUT /resource update Changes details of the resource
DELETE /resource destroy Eliminates the resource
Tabla 3: Single Resource in REST
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.
HTTP RAILS
URI
METHOD METHOD
GET /resources.:format index List of all resources in the format
specified
POST /resources.:format create Adds a new resource by sending
the resource description in the
format specified
GET /resources/:id.:format show Shows details of the resource
with the determined id in the
format specified.
PUT /resources/:id.:format update Changes details of the resource
with the determined id in the
format specified.
DELETE /resources/:id.:format destroy Eliminates the resource with the
92
Diseño e Implementación de Servicios de Colaboración Basados en Web
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.
One of the formatted interfaces provided by the SIR application is XML. This is a
very simple interface. Gives descriptions of every resource by merely putting tags to the
values of the columns in the database.
Therefore, if we make a GET petition to the application and adding “.xml” to the
URI, it returns a XML object mapped to that particular resource. Also, for create and
update, XML objects have to be send to the particular URI's by adding “.xml” to them.
HTTP
URI RAILS METHOD
METHOD
GET /resources.xml index List of all resources in XML
POST /resources.xml create Adds a new resource by sending the
resource description in XML
GET /resources/:id.xml show Shows details of the resource with
the determined id in XML.
PUT /resources/:id.xml update Changes details of the resource
with the determined id in XML.
DELETE /resources/:id.xml destroy Eliminates the resource with the
determined id returning the results
of the process in XML.
Tabla 5: XML Interface
93
5. APÉNDICES Rafael García Marín
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.
<title>Example Feed</title>
<subtitle>A subtitle.</subtitle>
<link href="http://example.org/feed/" rel="self"/>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
<email>johndoe@example.com</email>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>
94
Diseño e Implementación de Servicios de Colaboración Basados en Web
</feed>
A typical Atom structure contains a feed, which has information related to it, like
its title, author or dates regarding its creation or last changes. A feed is normally a
collection of entries. Each entry is defined between the tags <entry> and </entry>.
Resources are normally entries in Atom. Each entry has information related to it using
the standard Atom tags described in the Atom RFC s and its extensions. To know which
extension describes a particular tag, the following structure is used:
<ns:tag>information here</ns:tag>
Each tag has a “ns:” structure before its own name. This ns is a variable containing
the URI of the namespace used. This variable is defined in the header of an Atom
structure. For example:
</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.
Therefore, if we make a GET petition to the application and adding “.atom” to the
URI, it returns a Atom object mapped to that particular resource. Also, for create and
update, Atom objects have to be send to the particular URI's by adding “.atom” to them.
95
5. APÉNDICES Rafael García Marín
HTTP RAILS
URI
METHOD METHOD
GET /resources.atom index List of all resources in Atom
POST /resources.atom create Adds a new resource by sending the
resource description in Atom
GET /resources/:id.atom show Shows details of the resource with
the determined id in Atom.
PUT /resources/:id.atom update Changes details of the resource with
the determined id in Atom.
DELETE /resources/:id.atom destroy Eliminates the resource with the
determined id returning the results of
the process in Atom.
Tabla 6: Atom Interface
5.1.5 Resources
5.1.5.1 Spaces
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.
HTTP
URI RAILS METHOD
METHOD
GET /spaces index
GET /spaces.:format index
POST /spaces create
96
Diseño e Implementación de Servicios de Colaboración Basados en Web
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
#<Space id: 1, name: "Space 1", parent_id: nil, deleted: nil, public: true, created_at: "2008-
07-24 15:14:05", updated_at: "2008-07-24 15:48:38", description: "<p>This is the
description</p>">
In XML:
<spaces type="array">
<space>
<created-at type="datetime">2008-08-29T15:35:43+02:00</created-at>
<deleted type="boolean" nil="true"/>
<description><p>This is the description</p></description>
<id type="integer">2</id>
<name>Space 1</name>
97
5. APÉNDICES Rafael García Marín
</feed>
In XML:
98
Diseño e Implementación de Servicios de Colaboración Basados en Web
<space>
<description><p>space description</p></description>
<name>Space name</name>
<public type="boolean">true</public>
</space>
5.1.5.2 Users
The resource User is a representation of the people using the SIR application. Users
can be found nested into a certain Space depending on how we are using them.
99
5. APÉNDICES Rafael García Marín
Interface
When using a User on the scope of the whole SIR application the REST interface is:
HTTP
URI RAILS METHOD
METHOD
GET /users index
GET /users.:format index
POST /users create
POST /users.:format create
GET /users/new new
GET /users/new.:format new
GET /users/:id/edit edit
GET /users/:id/edit.:format edit
GET /users/:id show
GET /users/:id.:format show
PUT /users/:id update
PUT /users/:id.:format update
DELETE /users/:id destroy
DELETE /users/:id.:format destroy
Tabla 8: Users Interface
100
Diseño e Implementación de Servicios de Colaboración Basados en Web
HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/users index List of all users contained in
the space
POST /spaces/:space_id/users create Adds a new user to the space
GET /spaces/:space_id/users/new new Form for create
GET /spaces/:space_id/users/:id/edit edit Form for update
GET /spaces/:space_id/users/:id show Shows details of the user with
the determined id in the
determined space
PUT /spaces/:space_id/users/:id update Changes details of the user
with the determined id in the
determined space
DELETE /spaces/:space_id/users/:id destroy Eliminates the user from the
Space but not from the
application
Tabla 9: Nested Users Interface
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
101
5. APÉNDICES Rafael García Marín
In XML:
<user>
<activated-at type="datetime">2008-04-03T17:34:59+02:00</activated-at>
<activation-code nil="true"></activation-code>
<created-at type="datetime">2008-04-03T17:34:59+02:00</created-at>
<crypted-password>8057e7a92d13acf21ea192bb3097550a6a205281</crypted-
password>
<disabled type="boolean">false</disabled>
<email>ebarra@dit.upm.es</email>
<email2 nil="true"></email2>
<email3 nil="true"></email3>
<id type="integer">1</id>
<login>admin</login>
<remember-token nil="true"></remember-token>
<remember-token-expires-at type="datetime" nil="true"></remember-token-expires-at>
<reset-password-code nil="true"></reset-password-code>
<salt>193d1348682da4451dc1f4b155d89f68ae6963e0</salt>
<superuser type="boolean">true</superuser>
<updated-at type="datetime">2008-09-03T11:51:45+02:00</updated-at>
</user>
102
Diseño e Implementación de Servicios de Colaboración Basados en Web
<title>admin</title>
<gd:email address="myprimarymail@mail.com" primary="true"/>
<gd:email address="anothermail@mail.com"/>
<gd:email address="yetanothermail@mail.com"/>
<author>
<name>SIR</name>
</author>
</entry>
</feed>
In XML:
By doing a POST on /users.atom, the Atom interface needs this type of structure:
103
5. APÉNDICES Rafael García Marín
<id>tag:sir.dit.upm.es ,2005:User/3</id>
<published>2008-04-03T17:34:59+02:00</published>
<updated>2008-04-03T17:34:59+02:00</updated>
<link type="text/html" rel="alternate" href="http://sir.dit.upm.es/users/1"/>
<link type="application/atom+xml" rel="self"
href="http://sir.dit.upm.es/spaces/1/users/1.atom"/>
<title>atom2</title>
<sir:password>prueba</sir:password>
<gd:email address="myprimarymail@mail.com" primary="true" label="email1"/>
<gd:email address="anothermail@mail.com" primary="false" label="email2"/>
<gd:email address="yetanothermail@mail.com" primary="false" label="email3"/>
<category term="tag1"/>
<category term="tag2"/>
<category term="tag3"/>
<author>
<name>SIR</name>
</author>
</entry>
All of these tags must be included in the Atom archive in order to perform a valid
User creation or update action.
5.1.5.3 Events
The resource Event is a representation of the events held in a certain Space. Events
might be meetings or conferences or gatherings held with ISABEL.
As said before, Events are a concrete type of Posts.
104
Diseño e Implementación de Servicios de Colaboración Basados en Web
Interface
Events are always managed inside the context of a Space because they are always
attached to a certain activity or area.
HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/events index List of all events contained in
the space
POST /spaces/:space_id/events create Adds a new event to the space
GET /spaces/:space_id/events/new new Form for create
GET /spaces/:space_id/events/:id/edit edit Form for update
GET /spaces/:space_id/events/:id show Shows details of the event
with the determined id
PUT /spaces/:space_id/events/:id update Changes details of the event
with the determined id
DELETE /spaces/:space_id/events/:id destroy Eliminates the event
Tabla 10: Events Interface
The parameters which define a Event object in the SIR database are:
Event id
name
password
service
quality
description
uri
105
5. APÉNDICES Rafael García Marín
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>
</feed>
These Atom tags will be explained in Event paramenters needed by write actions.
106
Diseño e Implementación de Servicios de Colaboración Basados en Web
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:
An application trying to call a create method from SIR should send this type of
structure:
107
5. APÉNDICES Rafael García Marín
108
Diseño e Implementación de Servicios de Colaboración Basados en Web
5.1.5.4 Articles
Interface
Articles are always managed inside the context of a Space because they are always
attached to a certain activity or area.
HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/articles index List of all articles contained
in the space
POST /spaces/:space_id/articles create Adds a new article to the
space
GET /spaces/:space_id/articles/new new Form for create
GET /spaces/:space_id/articles/:id/edit edit Form for update
GET /spaces/:space_id/articles/:id show Shows details of the article
with the determined id
PUT /spaces/:space_id/articles/:id update Changes details of the
article with the determined
id
DELETE /spaces/:space_id/articles/:id destroy Eliminates the article
Tabla 11: Articles Interface
The parameters which define a Article object in the SIR database are:
id
title
text
created_at
109
5. APÉNDICES Rafael García Marín
updated_at
The XML shows information about the Entry related to the Article, therefore
showing many fields which are only interesting internally:
<entries type="array">
<entry>
<agent-id type="integer">1</agent-id>
<agent-type>User</agent-type>
<container-id type="integer">9</container-id>
<container-type>Space</container-type>
<content-id type="integer">8</content-id>
<content-type>XhtmlText</content-type>
<created-at type="datetime">2008-09-25T12:13:40+02:00</created-at>
<description><p>This is the Article text</p></description>
<id type="integer">23</id>
<parent-id type="integer" nil="true"/>
<parent-type nil="true"/>
<public-read type="boolean">true</public-read>
<public-write type="boolean" nil="true"/>
<title>article</title>
<updated-at type="datetime">2008-09-25T12:13:40+02:00</updated-at>
</entry>
</entries>
The Atom interface shows only the real information needed, not everything stored
in the database:
110
Diseño e Implementación de Servicios de Colaboración Basados en Web
<entry>
<id>tag:localhost,2005:Article/996332881</id>
<published>2008-10-31T12:31:50+01:00</published>
<updated>2008-10-31T12:31:50+01:00</updated>
<link type="text/html" rel="alternate" href="/spaces/Public/articles/996332881"/>
<title>fdsfddsafdsafsda</title>
<content type="html"><p>fdsafdsafdsafdsafsda</p></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.
The content of the parameters hash sent when creating an role is composed of the
following parts:
article
o title
o text
tags
space_id
An application trying to call a create method from SIR should send this type of
structure:
111
5. APÉNDICES Rafael García Marín
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
112
Diseño e Implementación de Servicios de Colaboración Basados en Web
HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/attachments index List of all attachments
POST /spaces/:space_id/attachments create Adds a new
attachment
GET /spaces/:space_id/attachments/new new Form for create
GET /spaces/:space_id/attachments/:id/edit edit Form for update
GET /spaces/:space_id/attachments/:id show Shows details of the
attachment with the
determined id
PUT /spaces/:space_id/attachments/:id update Changes details of the
attachment with the
determined id
DELETE /spaces/:space_id/attachments/:id destroy Eliminates the
attachment
Tabla 12: Attachments Interface
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
113
5. APÉNDICES Rafael García Marín
#<Attachment id: 11, type: nil, size: 1905890, content_type: "image/png", filename:
"Firefox_wallpaper.png", height: 800, width: 1280, thumbnail: nil, db_file_id: 11,
created_at: "2008-10-03 17:27:17", updated_at: "2008-10-03 17:27:17">
In XML the information about the entry mapped to the attachment is also given
(every tag containing the prefix entry):
<attachments>
<attachment>
<content-type>application/x-www-form-urlencoded</content-type>
<created-at type="datetime">2008-10-06T10:59:29+02:00</created-at>
<db-file-id type="integer">12</db-file-id>
<entry-agent-id type="NilClass">1</entry-agent-id>
<entry-agent-type type="NilClass">User</entry-agent-type>
<entry-container-id type="NilClass">2</entry-container-id>
<entry-container-type type="NilClass">Space</entry-container-type>
<entry-content-id type="NilClass">12</entry-content-id>
<entry-content-type type="NilClass">Attachment</entry-content-type>
<entry-created-at type="NilClass">2008-10-06 10:59:29</entry-created-at>
<entry-description type="NilClass" nil="true"/>
<entry-id type="NilClass">60</entry-id>
<entry-parent-id type="NilClass" nil="true"/>
<entry-parent-type type="NilClass" nil="true"/>
<entry-public-read type="NilClass">1</entry-public-read>
<entry-public-write type="NilClass" nil="true"/>
<entry-title type="NilClass">attachment</entry-title>
<entry-updated-at type="NilClass">2008-10-06 10:59:29</entry-updated-at>
<filename>attachment</filename>
<height type="integer" nil="true"/>
<id type="integer">12</id>
<parent-id type="integer" nil="true"/>
<size type="integer">112678</size>
<thumbnail nil="true"/>
<updated-at type="datetime">2008-10-06T10:59:29+02:00</updated-at>
<width type="integer" nil="true"/>
</attachment>
</attachments>
The Atom interface shows only the real information needed, not everything stored
in the database:
114
Diseño e Implementación de Servicios de Colaboración Basados en Web
xmlns:gd="http://schemas.google.com/g/2005" xml:lang="en-US"
xmlns="http://www.w3.org/2005/Atom">
<id>tag:sir.dit.upm.es,2005:/spaces/2/attachments</id>
<link type="text/html" rel="alternate" href="http://sir.dit.upm.es"/>
<link type="application/atom+xml" rel="self"
href="http://sir.dit.upm.es/spaces/2/attachments.atom"/>
<title>Attachments</title>
<updated>2008-10-06T10:59:29+02:00</updated>
<entry>
<id>tag:sir.dit.upm.es,2005:Attachment/12</id>
<published>2008-10-06T10:59:29+02:00</published>
<updated>2008-10-06T10:59:29+02:00</updated>
<link type="text/html" rel="alternate" href="/spaces/2/attachments/12"/>
<title>attachment</title>
<summary></summary>
<link ref="/spaces/2/attachments/12.atom" rel="edit"/>
<content src="/spaces/2/attachments/12.all"/>
<sir:size>112678</sir:size>
<sir:filename>attachment</sir:filename>
<sir:height></sir:height>
<sir:width></sir:width>
<sir:content_type>application/x-www-form-urlencoded</sir:content_type>
<author>
<name>SIR</name>
</author>
</entry>
</feed>
"attachment"=>{"name"=>"paco", "nickname"=>"pepe"}
115
5. APÉNDICES Rafael García Marín
5.1.5.6 Machines
Interface
Along with the usual REST methods, the machines interface includes one
additional, my_mailer, used when the user needs to request machines to de administrator.
The interface for Machines is:
HTTP
URI RAILS METHOD
METHOD
GET /machines index List of all machines
POST /machines create Adds a new machine
GET /machines/new new Form for create
GET /machines/:id/edit edit Form for update
GET /machines/:id show Shows details of the machine
with the determined id
PUT /machines/:id update Changes details of the machine
with the determined id
DELETE /machines/:id destroy Eliminates the machine
GET /machines/my_mailer my_mailer Used in the contact form used to
ask for more resources
Tabla 13: Machines Interface
116
Diseño e Implementación de Servicios de Colaboración Basados en Web
In XML:
<machines type="array">
<machine>
<id type="integer">7</id>
<name>machine1</name>
<nickname>machine1.domain.com</nickname>
</machine>
</machines>
</feed>
117
5. APÉNDICES Rafael García Marín
"machine"=>{"name"=>"paco", "nickname"=>"pepe"}
118
Diseño e Implementación de Servicios de Colaboración Basados en Web
5.1.5.7 Groups
Groups are associations of users inside a space. Every space will have a default
group with the same name as the space and it will contain automatically all the users with
roles admin and user within the space. Other groups can also be created in a space.
All groups will create a mailing list with the emails of all the users contained in
them.
Interface
HTTP RAILS
URI
METHOD METHOD
GET /spaces/:space_id/groups index List of all groups
contained in the space
POST /spaces/:space_id/groups create Adds a new group to the
space
GET /spaces/:space_id/groups/new new Form for create
GET /spaces/:space_id/groups/:id/edit edit Form for update
GET /spaces/:space_id/groups/:id show Shows details of the
group with the
determined id
PUT /spaces/:space_id/groups/:id update Changes details of the
group with the
determined id
DELETE /spaces/:space_id/groups/:id destroy Eliminates the group
Tabla 14: Groups Interface
119
5. APÉNDICES Rafael García Marín
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:
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:
120
Diseño e Implementación de Servicios de Colaboración Basados en Web
</feed>
"group"=>{"name"=>"group_name"}
The space_id parameter is mapped in the controller directly from the URL used to
call the method.
121
5. APÉNDICES Rafael García Marín
5.1.5.8 Profile
Users should have a profile related to them. The resource Profile is one of those
examples of singular resources.
Interface
HTTP RAILS
URI
METHOD METHOD
POST /users/:user_id/profile create Adds a profile to the user
GET /users/:user_id/profile/new new Form for create
GET /users/:user_id/profile/edit edit Form for update
GET /users/:user_id/profile show Shows details of the profile
PUT /users/:user_id/profile update Changes details of the profile
DELETE /users/:user_id/profile destroy Eliminates the profile
Tabla 15: Profile Interface
122
Diseño e Implementación de Servicios de Colaboración Basados en Web
Therefore, a typical Profile object structure directly from the table Profile would
be:
<Profile id: 1, name: "Pepe", lastname: "Sancho", organization: "Dit", phone: "4546456",
mobile: "6584524", fax: "915478599", address: "Callejeando 2", city: "Madrid", zipcode:
"45236", province: "Madrid", country: "España", user_id: "24">
In XML:
<profile>
<address>Callejeando 2</address>
<city>Madrid</city>
<country>España</country>
<fax>915478599</fax>
<id type="integer">1</id>
<lastname>Sancho</lastname>
<mobile>6584524</mobile>
<name>Pepe</name>
<organization>Dit</organization>
<phone>4546456</phone>
<province>Madrid</province>
<user-id>24</user-id>
<zipcode>45236</zipcode>
</profile>
123
5. APÉNDICES Rafael García Marín
<gd:phoneNumber
rel="http://schemas.google.com/g/2005#mobile">6584524</gd:phoneNumber>
<gd:organization>
<gd:orgName>Dit</gd:orgName>
</gd:organization>
<author>
<name>SIR</name>
</author>
</entry>
An application trying to call a create method from SIR should send this type of
structure:
The user_id parameter is mapped in the controller directly from the URL used to
call the method.
124
Diseño e Implementación de Servicios de Colaboración Basados en Web
In the Atom interface there are other tags that are not mandatory:
sir:address
sir:province
sir:zipcode
gd:phoneNumber => its value is a phone number, the type of phone is indicated by
the rel attribute inside this tag. The fax and mobile numbers are not mandatory.
rel => indicates the type of number:
■ http://schemas.google.com/g/2005#fax => fax number
■ http://schemas.google.com/g/2005#mobile => mobile number
125
Diseño e Implementación de Servicios de Colaboración Basados en Web
127