SERVIDOR PUBLISH/SUBSCRIBE

Raúl Llorach Sánchez
Ingeniería Técnica en Informática de Gestión
Director del proyecto:
Pedro García López
Escola Tècnica Superior d’Enginyeria (ETSE)
Universidad Rovira i Virgili (URV)
[SERVIDOR PUBLISH/SUBSCRIBE]
Proyecto Final de Carrera
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Índice
1.- INTRODUCCIÓN ................................................................................................... 1
1.1 – Objetivos del proyecto ..........................................................................................4
2.- ANTECEDENTES ................................................................................................... 5
2.1 – Sistema publish/subscribe ....................................................................................5
2.1.1 – Filtrado de mensajes ......................................................................................5
2.1.2 – Topologías ......................................................................................................6
2.1.3 – Ventajas ..........................................................................................................7
2.1.4 – Desventajas ....................................................................................................8
2.2 – Arquitecturas REST ................................................................................................9
2.2.1 – Recursos .......................................................................................................10
2.3 – Protocolos XML-RPC............................................................................................11
2.4 – Tecnología AJAX ..................................................................................................12
2.5 – Java Server Pages (JSP) ........................................................................................14
2.5.1 – Arquitectura de los JSP .................................................................................16
2.6 – Sindicación web...................................................................................................17
2.6.1 – Agregador .....................................................................................................18
2.6.2 – Variedades....................................................................................................19
2.7 – Formato RSS ........................................................................................................20
2.8 – Formato RDF .......................................................................................................21
2.9 – El Lenguaje HTML ................................................................................................22
2.10 – Google Gadgets .................................................................................................24
3.- ANÁLISIS ........................................................................................................... 25
4.- DISEÑO.............................................................................................................. 28
4.1 – Diseño de la base de datos .................................................................................28
4.2 – Estructura de la aplicación web ..........................................................................30
4.2.1 – ServletREG.java ............................................................................................31
4.2.2 – ServletRPC.java.............................................................................................32
4.2.3 – ServletREST.java ...........................................................................................32
4.3 – Métodos de la aplicación ....................................................................................34
4.3.1 – Methods.java................................................................................................34
4.4 – Gadgets implementados .....................................................................................39
2
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
4.5 – Interfaz de usuario ..............................................................................................42
4.6 – Metodología de desarrollo..................................................................................45
5.- RESULTADOS ..................................................................................................... 46
6.- CONCLUSIÓN ..................................................................................................... 48
7.- TRABAJO FUTURO ............................................................................................. 49
8.- RECURSOS UTILIZADOS ...................................................................................... 50
3
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
1.- INTRODUCCIÓN
Una aplicación web es un sistema informático que los usuarios utilizan
accediendo a un servidor web a través de Internet o de una intranet. Las aplicaciones
web son populares debido a la practicidad del navegador web como cliente ligero. La
facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software
en miles de potenciales clientes es otra razón de su popularidad. Aplicaciones como los
webmails, wikis, weblogs y tiendas en línea son ejemplos bien conocidos de
aplicaciones web.
En los primeros tiempos de la computación cliente-servidor, cada aplicación tenía su
propio programa cliente y su interfaz de usuario, estos tenían que ser instalados
separadamente en cada estación de trabajo de los usuarios. Una mejora al servidor,
como parte de la aplicación, requería típicamente una mejora de los clientes instalados
en cada una de las estaciones de trabajo, añadiendo un costo de soporte técnico y
disminuyendo la eficiencia del personal.
En contraste, las aplicaciones web generan dinámicamente una serie de páginas en un
formato estándar, soportado por navegadores web comunes como HTML o XHTML. Se
utilizan lenguajes interpretados del lado del cliente, tales como JavaScript, para añadir
elementos dinámicos a la interfaz de usuario. Generalmente cada página web
individual es enviada al cliente como un documento estático, pero la secuencia de
páginas provee de una experiencia interactiva.
Las interfaces web tienen ciertas limitaciones en la funcionalidad del cliente. Métodos
comunes en las aplicaciones de escritorio como dibujar en la pantalla o arrastrar-ysoltar no están soportadas por las tecnologías web estándar. Los desarrolladores web
comúnmente utilizan lenguajes interpretados del lado del cliente para añadir más
funcionalidad, especialmente para crear una experiencia interactiva que no requiera
recargar la página cada vez (cosa que suele molestar a los usuarios). Recientemente se
han desarrollado tecnologías para coordinar estos lenguajes con tecnologías del lado
del servidor. AJAX, es una técnica de desarrollo web que usa una combinación de
varias tecnologías.
Así pues, la creación de aplicaciones web actuales requiere un amplio dominio de
muchas técnicas de programación y en muchas ocasiones usuarios o programadores
carecen de ese dominio. Concretamente me refiero a ese tipo de aplicaciones que más
popularidad están cogiendo en la red. Las aplicaciones publish/subscribe.
Una aplicación publish/subscribe es aquella en la que un servidor da una serie de
servicios, a los usuarios, para gestionar, almacenar y presentar todo tipo de
información, y otros usuarios se suscriben a ella para ser avisados de nuevas
actualizaciones o informaciones.
4
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Así pues, cuando a un técnico se le plantea hacer una aplicación web personalizada,
basada en un sistema publish/subscribe, se va a encontrar, en gran medida con
muchas dificultades que ya están resueltas. Es decir, que si quisiéramos crear un foro,
o un web-chat, o cualquiera de este tipo de aplicaciones web, en todas ellas
tendríamos que repetir un mismo patrón de programación. Por tanto si hubiera alguna
manera de poder utilizar un soporte auxiliar para paliar esos problemas, los técnicos
podrían dedicarse mucho más tiempo en el producto final. Que es su propia aplicación,
teniendo, en gran parte, todo su mecanismo implementado por esa herramienta
auxiliar.
1.1 Objetivos del proyecto
Este proyecto ofrece, a los programadores de aplicaciones web basadas en sistemas
publish/subscribe, un software auxiliar (middleware) que a partir del cual, les ayude a
crear sus propias aplicaciones y gestionarlas. Que pueden ser desde blogs, foros,
canales de noticias hasta chats en tiempo real. En definitiva se quiere diseñar un
servidor que gestione y almacene canales y eventos. Cada canal podrá ser dedicado a
una temática diferente que escogerá el propio usuario, y dentro de cada canal habrá
los distintos eventos que lo formen. Estos eventos al mismo tiempo podrán ser de
publicadores o bien de otros canales, ya que también se permite la sindicación entre
canales o servidores mediante RSS o RDF.
En principio se pretende que el registro al servidor y la creación de canales y eventos
sea libre, pero se ha dado la posibilidad de poder crear canales privados y dar
privilegios solo a ciertos usuarios para poder compartir e enviar eventos a dicho canal.
También se ha proporcionado un api rígida para que ya sea, en segundo plano (vía
REST o vía XML-RPC) o en interfaz gráfica (el mismo servidor presenta una interfaz web
que ofrece las mismas funciones pero con formularios etc.), podamos comunicarnos
con el servidor. Esto sería la base del servidor en sí, que se conseguiría programando
servlets en JAVA y utilizando páginas web JSP de JAVA. También hemos optado por
aplicar en algunas funcionalidades tecnologías AJAX, que nos permiten una rápida
respuesta entre el cliente y el servidor.
Con este planteamiento ya damos un gran avance a los futuros programadores que lo
usen ya que se desprenderán totalmente del diseño de la base de datos y se
despreocuparan de donde y como se guardan sus canales y eventos, ya que todo eso
irá a cargo del middleware desarrollado. En conclusión, se pretende realizar un
middleware que proporcione servicios a los programadores para crear sus propias
aplicaciones web publish/subscribe y gestionar dichas aplicaciones, desprendiéndose
así de gran trabajo e invirtiendo su tiempo en el verdadero objetivo de su proyecto,
diseñar su blog, su web personal etc.
5
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
2.- ANTECEDENTES.
2.1 Sistema Publish/Subscribe
El sistema publish/subscribe es un paradigma de mensajes asíncronos donde los que
envían (Publisher) mensajes no están programados para enviar sus mensajes a
receptores específicos (Subscribers), sino que se envían a algún tipo de servidor. Los
mensajes publicados se caracterizan por clases, sin tener constancia de los
subscribidores que pueda haber. Los subscribidores expresan interés en una o más
clases, y solo reciben mensajes de ese mismo interés, sin tener constancia de qué
publicadores hay. Esta relación independiente entre publicadores y subscribidores
puede permitir una mayor escalabilidad.
El sistema publish/subscribe está muy ligado al paradigma de las colas de mensajes
(Message Queue). Muchos de los sistemas de mensajería soportan en su API (ej. JMS)
los dos, publish/subscribe y el modelo de mensajes en cola.
2.1.1 Filtrado de mensajes
En el modelo publish/subscribe, los subscribidores normalmente tan solo reciben un
subconjunto del total de mensajes publicados. El proceso de selección de mensajes
para su recepción y su procesamiento es llamado ‘Filtrado de mensajes’ (filtering).
Hay dos maneras de filtrar los mensajes: por tópicos o por el contenido de estos.
Cuando hablamos de filtrado por tópicos, decimos que los mensajes son publicados
por “temas” o canales. Los subscribidores en un sistema de filtrado por tópicos
recibirán todos los mensajes publicados, de aquellos tópicos o temas en los cuales se
hayan subscrito, y todos los subscribidores de un tópico o tema recibirán los mismos
mensajes. Son los publicadores, los responsables de definir los diferentes tipos de
temas o tópicos a los cuales se subscribirán los subscribidores.
6
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Fig. 2.1 Esquema de un Sistema publish/subscribe.
En nuestro proyecto nos basamos básicamente en este tipo de filtrado, aunque hemos
dado la posibilidad de insertar parámetros adicionales en la creación de canales por si
se quiere implementar otro tipo de filtrado como se verá seguidamente.
Por otro lado, cuando hablamos de filtrado por el contenido de los mensajes, decimos
que los mensajes son enviados a los subscribidores solo si el contenido de estos
coincide con las preferencias que los subscribidores se hayan definido. El subscribidor
es responsable de clasificar los mensajes.
Algunos sistemas soportan una mezcla de los dos; los publicadores envían mensajes a
algunos tópicos o temas mientras que los subscribidores reciben solo algunos
mensajes de cada tópico según su contenido.
2.1.2 Topologías
En muchos sistemas publish/subscribe, los publicadores envían los mensajes a un
servidor intermediario (broker) y los subscribidores hacen sus subscripciones con este
servidor intermediario (broker), permitiendo a este servidor encargarse del filtrado de
los mensajes. Dicho servidor normalmente se encarga del almacenamiento de los
mensajes y a su vez de la gestión de dichos mensajes hacia los subscribidores.
El diseño de este proyecto se ha basado en la utilización de un servidor intermedio,
encargado de almacenar los mensajes y gestionarlos.
7
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Fig. 2.2 Esquema Sistema publish/subscribe con broker.
Otros sistemas publish/subscribe eliminan este servidor intermediario (broker) y
distribuyen las funciones de gestión y filtrado entre los publicadores y subscribidores,
algunas veces con ayuda de “daemons”. Otra opción más especializada involucra
mapear todas las IPs de los subscribidores y organizarlas en grupos según sus tópicos o
temas, de esta forma los mensajes podrían enviarse directamente des de los
publicadores a los subscribidores con un único mensaje. El filtrado por contenido
puede entonces llevarse a cabo en el subscribidor, antes de que los mensajes pasen a
la capa superior de la aplicación en sí.
2.1.3 Ventajas
→ Tanto los publicadores como los subscribidores no necesitan saber uno del otro.
Siendo el tópico o tema el objetivo, publicadores y subscribidores pueden permanecer
al margen de la topología del sistema. Cada uno puede operar con normalidad
independientemente del otro. Cosa que no pasaba con el paradigma tradicional
cliente-servidor, el cliente no puede mandar mensajes al servidor mientras el servidor
no está en marcha, ni puede recibir mensajes a no ser que el cliente también esté en
marcha.
→ Para instalaciones relativamente pequeñas, el sistema publish/subscribe da la
oportunidad de una mejor escalabilidad que los tradicionales sistemas cliente-servidor,
mediante operaciones en paralelo, cache de mensajes, etc. No obstante, a medida que
un sistema aumenta hasta el punto de convertirse en un centro de datos con miles de
8
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
servidores compartiendo la infraestructura publish/subscribe, este beneficio,
normalmente, se pierde; de hecho, la escalabilidad para sistemas publish/subscribe
bajo una gran carga es todavía un desafío.
2.1.4 Desventajas
El problema más serio con los sistemas publish/subscribe es, en contrapuesta, su
principal ventaja: la independencia entre el publicador y el subscribidor. El problema
está en que es muy complicado especificar propiedades más fuertes que podrían ser
útiles.
→ Como primer ejemplo, muchos sistemas publish/subscribe intentan enviar mensajes
durante un periodo corto de tiempo y después se detienen. Si una aplicación, por el
motivo que fuese, necesitase una garantía más fuerte (como podría ser: los mensajes
serán siempre enviados y en caso contrario se tendrá que informar al publicador del
hecho), el sistema publish/subscribe probablemente no tendría manera de satisfacer
esta garantía.
→ Otro ejemplo seria, cuando un publicador “asume” que un subscribidor está
escuchando. Supongamos que utilizamos un sistema publish/subscribe para capturar
mensajes de error en una fabrica: cualquier aplicación que produzca un error publicará
un apropiado mensaje, y los mensajes serán puestos en la pantalla de la consola por el
servicio (‘daemon’), el cual se subscribe al tópico “errores”. Si el captador de
excepciones se cuelga, los publicadores no serán capaces de darse cuenta, con lo cual
todos los mensajes de error desaparecerán y no se verán por la consola.
Como se ha dicho anteriormente, los sistemas publish/subscribe se comportan bien
con instalaciones pequeñas, en cuanto escalabilidad se refiere. Pero cuando nos
encontramos con instalaciones más grandes su comportamiento empieza a decaer. Y
esto se manifiesta con inestabilidades como, largos periodos de espera, retardos en
cuanto más y más aplicaciones empiezan a usar el sistema (incluso si se están
comunicando en tópicos distintos), a más de saturar una red local con el trafico de
mensajes.
En cuanto a los sistemas que utilizan servidores (brokers), estos pueden ser objeto de
problemas de seguridad. Pueden ser hackeados para enviar notificaciones a un cliente
erróneo, creando una denegación de servicio hacia dicho cliente. Los servidores
pueden sobrecargarse a medida que van almacenando y gestionando grandes
cantidades de mensajes.
Incluso con sistemas que no dependen de servidores intermedios, un subscribidor
podría ser capaz de recibir información que no le está autorizada. Un publicador no
9
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
autorizado podría ser capaz de introducir mensajes incorrectos o dañinos en el sistema
publish/subscribe. Esto es especialmente verdad en sistemas que envían todos sus
mensajes a todos sus subscriptores. La encriptación (ej. SSL/TLS) puede ser la única vía
de defensa contra accesos desautorizados.
2.2 Arquitecturas REST
La Transferencia de Estado Representacional (Representational State Transfer) o REST
es una técnica de arquitectura software para sistemas hipermedia distribuidos como la
World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la
web escrita por Roy Fielding, uno de los principales autores de la especificación del
protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de
desarrollo.
Si bien el término REST se refería originalmente a un conjunto de principios de
arquitectura —descritos más abajo—, en la actualidad se usa en el sentido más amplio
para describir cualquier interfaz web simple que utiliza XML y HTTP, sin las
abstracciones adicionales de los protocolos basados en patrones de intercambio de
mensajes como el protocolo de servicios web SOAP. Es posible diseñar sistemas de
servicios web de acuerdo con el estilo arquitectural REST de Fielding y también es
posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a
procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes del término REST
causan cierta confusión en las discusiones técnicas, aunque RPC no es un ejemplo de
REST.
Los sistemas que siguen los principios REST se llaman con frecuencia RESTful; los
defensores más acérrimos de REST se llaman a sí mismos RESTafaris.
REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de
diseños fundamentales clave:
-
Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la
información necesaria para comprender la petición. Como resultado, ni el
cliente ni el servidor necesitan recordar ningún estado de las comunicaciones
entre mensajes. Sin embargo, en la práctica, muchas aplicaciones basadas en
HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesión
(algunas de estas prácticas, como la reescritura de URLs, no son permitidas por
REST)
-
Un conjunto de operaciones bien definidas que se aplican a todos los recursos
de información: HTTP en sí define un conjunto pequeño de operaciones, las
más importantes son POST, GET, PUT y DELETE. Con frecuencia estas
10
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
operaciones se equiparan a las operaciones CRUD que se requieren para la
persistencia de datos, aunque POST no encaja exactamente en este esquema.
-
Una sintaxis universal para identificar los recursos. En un sistema REST, cada
recurso es direccionable únicamente a través de su URI.
-
El uso de hipermedios, tanto para la información de la aplicación como para las
transiciones de estado de la aplicación: la representación de este estado en un
sistema REST son típicamente HTML o XML. Como resultado de esto, es posible
navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin
requerir el uso de registros u otra infraestructura adicional.
2.2.1 Recursos
Un concepto importante en REST es la existencia de recursos (elementos de
información), que pueden ser accedidos utilizando un identificador global (un
Identificador Uniforme de Recurso) Para manipular estos recursos, los componentes
de la red (clientes y servidores) se comunican a través de un interfaz estándar (HTTP) e
intercambian representaciones de estos recursos (los ficheros que se descargan y se
envían) - es cuestión de debate, no obstante, si la distinción entre recursos y sus
representaciones es demasiado platónica para su uso práctico en la red, aunque es
popular en la comunidad RDF.
La petición puede ser tramitada por cualquier número de conectores (por ejemplo
clientes, servidores, cachés, túneles, etc.) pero cada uno lo hace sin "ver más allá" de
su propia petición (lo que se conoce como separación en capas, otra restricción de
REST, que es un principio común con muchas otras partes de la arquitectura de redes y
de la información) Así, una aplicación puede interactuar con un recurso conociendo el
identificador del recurso y la acción requerida, no necesitando conocer si existen
cachés, proxys, cortafuegos, túneles o cualquier otra cosa entre ella y el servidor que
guarda la información. La aplicación, sin embargo, debe comprender el formato de la
información devuelta (la representación), que es por lo general un documento HTML o
XML, aunque también puede ser una imagen o cualquier otro contenido.
11
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
2.3 Protocolos XML-RPC
XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para
codificar los datos y HTTP como protocolo de transmisión de mensajes.
Es un protocolo muy simple ya que sólo define unos cuantos tipos de datos y
comandos útiles, además de una descripción completa de corta extensión. La
simplicidad del XML-RPC está en contraste con la mayoría de protocolos RPC que tiene
una documentación extensa y requiere considerable soporte de software para su uso.
Fue creado por Dave Winer de la empresa UserLand Software en asociación con
Microsoft en el año 1998. Al considerar Microsoft que era muy simple decidió
adicionarle funcionalidades, los cuales después de varias etapas de desarrollo el
estándar dejó de ser sencillo y se convirtió en lo que es actualmente conocido como
SOAP. Una diferencia fundamental es que en los procedimientos en SOAP los
parámetros tienen nombre y no interesan su orden, no siendo así en XML-RPC.
Fig. 2.3 Esquema Protocolo XML-RPC.
12
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
2.4 Tecnología AJAX
AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es
una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet
Applications). Éstas se ejecutan en el cliente, es decir, en el navegador de los usuarios
y mantiene comunicación asíncrona con el servidor en segundo plano. De esta forma
es posible realizar cambios sobre la misma página sin necesidad de recargarla. Esto
significa aumentar la interactividad, velocidad y usabilidad en la misma.
AJAX es una combinación de tres tecnologías ya existentes:
-
XHTML (o HTML) y hojas de estilos en cascada (CSS) para el diseño que
acompaña a la información.
-
Document Object Model (DOM) accedido con un lenguaje de scripting por
parte del usuario, especialmente implementaciones ECMAScript como
JavaScript y JScript, para mostrar e interactuar dinámicamente con la
información presentada.
-
El objeto XMLHttpRequest para intercambiar datos asincrónicamente con el
servidor web. En algunos frameworks y en algunas situaciones concretas, se
usa un objeto iframe en lugar del XMLHttpRequest para realizar dichos
intercambios.
-
XML es el formato usado comúnmente para la transferencia de vuelta al
servidor, aunque cualquier formato puede funcionar, incluyendo HTML pre
formateado, texto plano, JSON y hasta EBML.
Como el DHTML, LAMP o SPA, AJAX no constituye una tecnología en sí, sino que es un
término que engloba a un grupo de éstas que trabajan conjuntamente.
13
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Fig. 2.4 Esquema del funcionamiento de AJAX.
A pesar de que el término «AJAX» fuese creado en 2005, la historia de las tecnologías
que permiten AJAX se remonta a una década antes con la iniciativa de Microsoft en el
desarrollo de Scripting Remoto. Sin embargo, las técnicas para la carga asíncrona de
contenidos en una página existente sin requerir recarga completa remontan al tiempo
del elemento iframe (introducido en Internet Explorer 3 en 1996) y el tipo de elemento
layer (introducido en Netscape 4 en 1997, abandonado durante las primeras etapas de
desarrollo de Mozilla). Ambos tipos de elemento tenían el atributo src que podía
14
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
tomar cualquier dirección URL externa, y cargando una página que contenga javascript
que manipule la página paterna, pueden lograrse efectos parecidos al AJAX.
El Microsoft's Remote Scripting (o MSRS, introducido en 1998) resultó un sustituto más
elegante para estas técnicas, con envío de datos a través de un applet Java el cual se
puede comunicar con el cliente usando JavaScript. Esta técnica funcionó en ambos
navegadores, Internet Explorer versión 4 y Netscape Navigator versión 4. Microsoft la
utilizó en el Outlook Web Access provisto con la versión 2000 de Microsoft Exchange
Server.
La comunidad de desarrolladores web, primero colaborando por medio del grupo de
noticias microsoft.public.scripting.remote y después usando blogs, desarrollaron una
gama de técnicas de scripting remoto para conseguir los mismos resultados en
diferentes navegadores. Los primeros ejemplos incluyen la librería JSRS en el año 2000,
la introducción a la técnica imagen/cookie en el mismo año y la técnica JavaScript bajo
demanda (JavaScript on Demand) en 2002. En ese año, se realizó una modificación por
parte de la comunidad de usuarios al Microsoft's Remote Scripting para reemplazar el
applet Java por XMLHttpRequest.
Frameworks de Scripting Remoto como el ARSCIF aparecieron en 2003 poco antes de
que Microsoft introdujera Callbacks en ASP. NET.
Desde que XMLHttpRequest está implementado en la mayoría de los navegadores,
raramente se usan técnicas alternativas. Sin embargo, todavía se utilizan donde se
requiere una mayor compatibilidad, una reducida implementación, o acceso cruzado
entre sitios web. Una alternativa, el Terminal SVG (basado en SVG), emplea una
conexión persistente para el intercambio continuo entre el navegador y el servidor.
2.5 Java Server Pages (JSP)
Java Server Pages (JSP) es una tecnología Java que permite generar contenido
dinámico para web, en forma de documentos HTML, XML o de otro tipo.
Esta tecnología es un desarrollo de la compañía Sun Microsystems. La Especificación
JSP 1.2 fue la primera que se liberó y en la actualidad está disponible la Especificación
JSP 2.1.
Las JSP's permiten la utilización de código Java mediante scripts. Además es posible
utilizar algunas acciones JSP predefinidas mediante etiquetas. Estas etiquetas pueden
ser enriquecidas mediante la utilización de Librerías de Etiquetas (TagLibs o Tag
Libraries) externas e incluso personalizadas.
15
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Microsoft, la más directa competencia de Sun, ha visto en esta estrategia de Sun una
amenaza, lo que le ha llevado a que su plataforma .NET incluya su lenguaje de scripts
ASP.NET que permite ser integrado con clases .NET (ya estén hechas en C++,
VisualBasic o C#) del mismo modo que jsp se integra con clases Java.
2.5.1 Arquitectura de los JSP
Desde el punto de vista de arquitectura, podríamos situar esta tecnología como una
capa superior a las Servlets dentro de nuestra aplicación, ya que extiende la
Especificación Servlet 2.1. Ambas tecnologías fueron desarrolladas originalmente por
Sun Microsystem.
El funcionamiento general de la tecnología JSP es que el Servidor de Aplicaciones
interpreta el código contenido en la página JSP para construir un Servlet, cuya salida
será un documento estático (típicamente HTML) que se presentará en la pantalla del
Navegador del usuario.
Fig. 2.5 Flujo de la información.
A su vez, es posible enriquecer este lenguaje de etiquetas. Para ello debemos extender
la capa de alto nivel JSP mediante la implementación de Librerías de Etiquetas (Tags
Libraries). Un ejemplo de estas librerías son las proporcionadas por Sun bajo la
denominación de JSTL o las distribuidas por Apache junto con el Framework de Struts.
JSP no se puede considerar un script al 100%, ya que antes de ejecutarse el Servidor de
Aplicaciones compila el contenido del documento JSP (script y etiquetas) y genera una
clase Servlet. Por lo tanto, se puede decir que aunque este proceso sea transparente
para el programador no deja de ser una tecnología compilada.
16
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
La principal ventaja de JSP frente a otros lenguajes es que permite integrarse con
clases Java (.class) lo que permite separar en niveles las aplicaciones web,
almacenando en clases java las partes que consumen más recursos (así como las que
requieren más seguridad) y dejando la parte encargada de formatear el documento
HTML en el archivo JSP. La idea fundamental detrás de este criterio es el de separar la
lógica del negocio de la presentación de la información.
Independientemente de la certeza de la aseveración, Java es conocido por ser un
lenguaje muy portable (su lema publicitario reza: escríbelo una vez, ejecútalo donde
sea) y sumado a las capacidades de JSP se hace una combinación muy atractiva.
Los servlets y Java Server Pages (JSPs) son dos métodos de creación de páginas web
dinámicas en servidor usando el lenguaje Java. En ese sentido son similares a otros
métodos o lenguajes tales como el PHP, los CGIs (common gateway interface),
programas que generan páginas web en el servidor, o los ASP (Active Server Pages), un
método específico de Microsoft. Sin embargo, se diferencian de ellos en otras cosas.
Para empezar, los JSPs y servlets se ejecutan en una máquina virtual Java, lo cual
permite que, en principio, se puedan usar en cualquier tipo de ordenador, siempre que
exista una máquina virtual Java para él. Cada servlet (o JSP, a partir de ahora lo
usaremos de forma indistinta) se ejecuta en su propia hebra, es decir, en su propio
contexto; pero no se comienza a ejecutar cada vez que recibe una petición, sino que
persiste de una petición a la siguiente, de forma que no se pierde tiempo en invocarlo
(cargar programa + intérprete). Su persistencia le permite también hacer una serie de
cosas de forma más eficiente: conexión a bases de datos y manejo de sesiones, por
ejemplo.
Los JSPs son en realidad servlets: un JSP se compila a un programa en Java la primera
vez que se invoca, y del programa en Java se crea una clase que se empieza a ejecutar
en el servidor como un servlet. La principal diferencia entre los servlets y los JSPs es el
enfoque de la programación: un JSP es una página Web con etiquetas especiales y
código Java incrustado, mientras que un servlet es un programa que recibe peticiones
y genera a partir de ellas una página web.
2.6 Sindicación Web
La sindicación web es una forma de redifusión (distribución) de información mediante
la cual parte de una página web que se pone a disposición para su uso desde otras
páginas. Esto puede ser simplemente licenciando el contenido para que puedan usarlo
otras personas; sin embargo, en general, la sindicación web se refiere a ofrecer una
fuente web desde una página web para proporcionar a otras personas una lista
17
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
actualizada de su contenido (por ejemplo, noticias de un periódico, nuevos artículos en
una bitácora, los últimos comentarios en un foro, etcétera).
Las fuentes suelen codificarse en XML, aunque el formato puede ser cualquier cosa
que pueda transportarse a través de HTTP, como el HTML o el Javascript. Las dos
principales familias de formatos de sindicación web son el RSS y el Atom.
Recientemente el término RSS (Sindicación Realmente Simple) se ha usado
indistintamente para referirse a cualquiera de los formatos RSS o Atom.
Para leer una fuente es necesario suscribirse mediante un agregador, que más
adelante explicaremos con más detalle, pero para dar un avance diremos que es una
aplicación (de escritorio o basada en web) que muestra los contenidos nuevos
publicados por el proveedor de la fuente suscrita.
Esto tuvo su origen en las páginas de noticias y los blogs, pero cada vez se utiliza más
para redifundir cualquier tipo de información. La sindicación web también está
ganando importancia en el comercio en línea, ya que los internautas cada vez son más
reacios a proporcionar información personal para información promocional (como
apuntarse a un boletín de noticias) y en cambio esperan la posibilidad de suscribirse a
una fuente de sindicación.
Fig. 2.6 Icono que señala la presencia de feeds RSS.
2.6.1 Agregador
Un agregador o agregador de noticias es un tipo de software para suscribirse a canales
de noticias en formatos RSS, Atom y otros derivados de XML/RDF). El agregador reúne
las noticias o historias publicadas en los sitios web sindicados elegidos, y muestra las
novedades o modificaciones que se han producido en esos canales; es decir, avisa de
qué webs han incorporado contenido nuevo desde nuestra última lectura y cuál es ese
contenido. Esta información es la que se conoce como feed.
Un agregador es muy similar en sus prestaciones a los anteriores lectores de noticias
(client newsreaders/NNTP), pero la tecnología XML y el web semántico los ha hecho
más populares. Hoy en día, una enorme cantidad de blogs y sitios web ofrecen sus
18
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
actualizaciones, que pueden ser fácilmente reunidas y administradas en un solo punto,
como es el caso del servicio My Yahoo!, Google Reader, y otros agregadores de
escritorio.
2.6.2 Variedades
La gran variedad de aplicaciones de software y componentes para publicar feeds es
una prueba de la flexibilidad del formato XML.
-
Basados en web: Los agregadores basados en web son aplicaciones que residen
en servidores remotos y que funcionan como aplicaciones que se ejecutan en la
propia web: Google Reader o Bloglines.
Otros métodos avanzados de agregadores de feeds están construidos en código
AJAX y XML y son también conocidos como Web widgets. Éstos permiten reunir
servicios de email, documentos o feeds en una sola interfaz. Algunos de los
portales que disponen de estas funcionalidades son: iGoogle, Live.com, etc.
El más utilizado en la red es el de My Yahoo!, y para ver las estadísticas de
utilización de agregadores basados en web, más abajo tenemos un diagrama
que nos lo muestra:
Fig. 2.7 Diagrama de los agregadores basados en web más utilizados.
19
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
-
Cliente de software: Los agregadores que funcionan como programas clientes
son aplicaciones que se instalan en los ordenadores y están diseñados para
reunir suscripciones de feeds y agruparlas todas usando una interfaz amigable.
En estos programas, las suscripciones están agrupadas generalmente en la
columna izquierda y las entradas de cada feed se pueden buscar, seleccionar y
leer en la columna o caja de la derecha.
2.7 Formato RSS
RSS es un sencillo formato de datos que es utilizado para redifundir contenidos a
suscriptores de un sitio web. El formato permite distribuir contenido sin necesidad de
un navegador, utilizando un software diseñado para leer estos contenidos RSS
(agregador). A pesar de eso, es posible utilizar el mismo navegador para ver los
contenidos RSS. Las últimas versiones de los principales navegadores permiten leer los
RSS sin necesidad de software adicional.
RSS es parte de la familia de los formatos XML desarrollado específicamente para todo
tipo de sitios que se actualicen con frecuencia y por medio del cual se puede compartir
la información y usarla en otros sitios web o programas. A esto se le conoce como
redifusión web o sindicación web (una traducción incorrecta, pero de uso muy común).
Fig. 2.8 Lecturas de Wikinoticias en inglés realizadas en el formato RSS.
Este acrónimo se usa para referirse a los siguientes estándares:
* Rich Site Summary (RSS 0.91)
* RDF Site Summary (RSS 0.9 y 1.0)
* Really Simple Syndication (RSS 2.0)
* Además es usual que el término RSS sea usado indistintamente para referirse a
cualquiera de los formatos RSS o Atom.
20
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Gracias a los agregadores o lectores de feeds (programas o sitios que permiten leer
fuentes web) se puede obtener resúmenes de todos los sitios que se desee desde el
escritorio del sistema operativo, programas de correo electrónico o por medio de
aplicaciones web que funcionan como agregadores. No es necesario abrir el navegador
y visitar decenas de webs.
Pero lo verdaderamente importante es que a partir de este formato se está
desarrollando una cadena de valor nueva en el sector de los contenidos que está
cambiando las formas de relación con la información tanto de los profesionales y
empresas del sector como de los usuarios. Varias empresas están explorando nuevas
formas de uso y distribución de la información.
La redifusión web no es sólo un fenómeno vinculado a los weblogs, aunque han
ayudado mucho a su popularización. Siempre se han sindicado contenidos y se ha
compartido todo tipo de información en formato XML, de esta forma podemos ofrecer
contenidos propios para que sean mostrados en otras páginas web de forma
integrada, lo que aumenta el valor de la página que muestra el contenido y también
nos genera más valor, ya que normalmente la redifusión web siempre enlaza con los
contenidos originales.
2.8 Formato RDF
El Marco de Descripción de Recursos (del inglés resource description framework, RDF)
es un framework para metadatos en la World Wide Web (WWW), desarrollado por el
World Wide Web Consortium (W3C).
El origen de RDF se debe a Ramanathan V. Guha cuando trabajaba en Apple Computer
en su forma inicial conocida como MCF, más tarde continuada durante su etapa en
Netscape Communications Corporation. Este modelo se basa en la idea de convertir las
declaraciones de los recursos en expresiones con la forma sujeto-predicado-objeto
(conocidas en términos RDF como tripletes). El sujeto es el recurso, es decir aquello
que se está describiendo. El predicado es la propiedad o relación que se desea
establecer acerca del recurso. Por último, el objeto es el valor de la propiedad o el otro
recurso con el que se establece la relación. La combinación de RDF con otras
herramientas como RDF Schema y OWL permite añadir significado a las páginas, y es
una de las tecnologías esenciales de la Web semántica.
21
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Fig. 2.9 Ejemplo de un RDF.
En definitiva, vemos que un RDF nos permite:
-
Definir información sobre cualquier dominio.
-
Todo lo que se describen son recursos (identificados por sus URIs).
-
Definido como una tripleta (s,p,o):
• Sujeto – Recurso (http://www.w3c.es/Personal/Martin).
• Predicado – Propiedad (creador).
• Objeto – Literal (“Martín Álvarez”).
-
Utiliza el Lenguaje de Marcado Extensible (XML) para la codificación.
-
Facilita la creación e intercambio de los metadatos.
2.9 El lenguaje HTML
HTML es el acrónimo inglés de HyperText Markup Language, que se traduce al español
como Lenguaje de Etiquetas de Hipertexto. Es un lenguaje de marcado diseñado para
estructurar textos y presentarlos en forma de hipertexto, que es el formato estándar
de las páginas web. Gracias a Internet y a los navegadores como Internet Explorer,
Opera, Firefox, Netscape o Safari, el HTML se ha convertido en uno de los formatos
22
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
más populares y fáciles de aprender que existen para la elaboración de documentos
para web.
En 1989 existían dos técnicas que permitían vincular documentos electrónicos, por un
lado los hipervínculos (links) y por otro lado un poderoso lenguaje de etiquetas
denominado SGML. Por entonces un usuario conocedor de ambas opciones, Tim
Berners-Lee físico nuclear del Centro Europeo para la Investigación Nuclear da a
conocer a la prensa que estaba trabajando en un sistema que permitirá acceder a
ficheros en línea, funcionando sobre redes de computadoras o máquinas electrónicas
basadas en el protocolo TCP/IP.
A principios de 1990, Tim Berners-Lee define por fin el HTML como un subconjunto del
conocido SGML y crea algo más valioso aún, el World Wide Web. En 1991, Tim
Berners-Lee crea el primer navegador de HTML que funcionaría en modo texto y para
UNIX.
Los trabajos para crear un sucesor del HTML, denominado HTML +, comenzaron a
finales de 1993. HTML+ se diseñó originalmente para ser un superconjunto del HTML
que permitiera evolucionar gradualmente desde el formato HTML anterior. A la
primera especificación formal de HTML+ se le dio, por lo tanto, el número de versión 2
para distinguirla de las propuestas no oficiales previas. Los trabajos sobre HTML+
continuaron, pero nunca se convirtió en un estándar, a pesar de ser la base
formalmente más parecida al aspecto compositivo de las especificaciones actuales.
El borrador del estándar HTML 3.0 fue propuesto por el recién formado W3C en marzo
de 1995. Con él se introdujeron muchas nuevas capacidades, tales como facilidades
para crear tablas, hacer que el texto fluyese alrededor de las figuras y mostrar
elementos matemáticos complejos. Aunque se diseñó para ser compatible con HTML
2.0, era demasiado complejo para ser implementado con la tecnología de la época y,
cuando el borrador del estándar expiró en septiembre de 1995, se abandonó debido a
la carencia de apoyos de los fabricantes de navegadores web. El HTML 3.1 nunca llegó
a ser propuesto oficialmente, y el estándar siguiente fue el HTML 3.2, que abandonaba
la mayoría de las nuevas características del HTML 3.0 y, a cambio, adoptaba muchos
elementos desarrollados inicialmente por los navegadores web Netscape y Mosaic. La
posibilidad de trabajar con fórmulas matemáticas que se había propuesto en el HTML
3.0 pasó a quedar integrada en un estándar distinto llamado MathML.
El HTML 4.0 también adoptó muchos elementos específicos desarrollados inicialmente
para un navegador web concreto, pero al mismo tiempo comenzó a limpiar el HTML
señalando algunos de ellos como 'desaprobados'.
23
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
2.10 Google Gadgets
El término gadget (o widget), se ha dado a una nueva categoría de mini aplicaciones,
diseñadas para proveer de información o mejorar una aplicación o servicios de un
ordenador o computadora, o bien cualquier tipo de interacción a través de Internet,
por ejemplo una extensión de alguna aplicación de negocios, que nos provea
información en tiempo real del estatus del negocio u organización.
Un ejemplo de un gadget en una computadora serían los gadgets del Dashboard del
sistema de Apple el Mac OS X Tiger o los de la barra lateral de Windows, que viene
incluida en el nuevo sistema operativo de Microsoft: Windows Vista.
Hasta aquí hemos explicado que es un gadget o widget, pero y los google gadgets? Pos
bien, esto no es nada más que una adaptación que ha hecho google para proporcionar
pequeñas aplicaciones que pueden correr en múltiples sitios, incluyendo iGoogle,
Google Desktop, Google Page Creator, y miles de sitios que utilicen los google gadgets.
Estos gadgets son escritos por autores en un lenguaje modular XML. Cuando un
usuario añade un gadget en su página personal, google lo que hace es convertir el
gadget xml en código HTML y JavaScript normal, permitiendo al gadget poder ser
visualizado con cualquier navegador moderno.
Fig. 2.10 Diferentes Google Gadgets.
24
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
3.- ANÁLISIS
Se pretende crear un middleware para facilitar las bases de un sistema
publish/subscribe. De modo que los desarrolladores de un proyecto puedan dedicarse
única e íntegramente en su objetivo. Para tal fin se ha decidido crear un servidor
intermedio que separará de una forma clara los que son ‘publicadores’ y los que son
‘subscribidores’. Este servidor intermedio será dotado de todas las funciones básicas
necesarias para gestionar los mensajes de los publicadores.
Para desarrollar esta aplicación web utilizaremos un servidor Apache con una base de
datos SQL, las páginas web serán creadas en JAVA (JSP) y AJAX. Utilizaremos
protocolos de comunicación como XML-RPC y los métodos básicos del protocolo HTTP
(GET, POST, PUT, DELETE) para dar soporte al api REST.
Se ha decidido que el filtrado de los mensajes sea en base a un tópico, es decir, que
todos los mensajes que publiquen los publicadores deberán estar dentro de su
correspondiente canal que los clasificará según su temática. No obstante damos cabida
a que se puedan implementar futuras aplicaciones externas a dicho servidor que
puedan gestionar la manera en que se subscriben a diferentes canales. Digo esto
porque se ha dado la posibilidad de poner parámetros extras en la creación de canales
y eventos. Por tanto si se quisiera, también se podría desarrollar un tipo de aplicación
cliente (por parte de los subscribidores) que se subscribieran solamente a esos canales
cuyos parámetros contengan palabras como “coche”, “motor”, etc. Es decir, de alguna
manera damos cabida a que se puedan sindicar a canales también según su contenido.
La idea es crear un entorno que sea libre, en el sentido de que todo el mundo tenga la
posibilidad de crear canales y enviar eventos pero no sin renunciar a la seguridad y a la
privacidad. Por tanto se ha dado la posibilidad de crear canales privados donde
solamente usuarios autorizados puedan leer, publicar y subscribirse. Siguiendo con
este planteamiento también se ha querido dar un aspecto de interoperabilidad entre
diferentes servidores que soporten sindicación RSS o RDF. Con lo cual se podrá crear
canales que al mismo tiempo estén sindicados a otros servidores o canales, para
importar todos sus eventos a nuestro servidor y mantener actualizado dicho canal con
información de otros servidores si se ve necesario. La sindicación a dichos servidores
se programará de manera independiente por parte del servidor, que será el que cada
cierto tiempo vaya preguntando al otro servidor sindicado si hay nueva información
para incorporar. Es decir, es como si hubiéramos implementado un agregador de RSS.
Para gestionar todos los canales se han creado una serie de operaciones básicas que se
podrán utilizar de distintos modos. Hemos creído conveniente que al ser este proyecto
planteado como un middleware, es necesario que se puedan gestionar los canales sin
necesidad de ir específicamente a la interfaz web del servidor, es decir que se puedan
25
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
llamar a dichos métodos en segundo plano para poder ser utilizados des de otras
aplicaciones web. Por tanto se ha dotado al servidor de un api REST que proporcione
los métodos GET, PUT, POST y DELETE para que mediante el protocolo HTTP se pueda
mandar uno de estos métodos con sus parámetros respectivos y haga la acción
deseada. Esta manera de utilizar el servidor en segundo plano es muy sencilla y fácil,
sobre todo si no requerimos tratar el resultado de la acción, ya que dichos métodos
devuelven los resultados directamente en HTTP.
Por otro lado, si lo que pretendemos es realizar una acción y utilizar su resultado para
tratarlo entonces se ha dotado al servidor de una interfaz XML-RPC, en la cual se
pueda llamar a las mismas funciones básicas pero estas devolverán siempre un
formato XML con el resultado de la acción.
Las funciones básicas que proporciona el servidor son las siguientes:
-
List Channels: con esta opción nos listará todos los canales del servidor,
públicos y privados (de estos últimos, claro, no podremos ver su información si
no tenemos privilegios). Dentro de esta opción podemos escoger si queremos
que nos liste tan solo los ‘x’ últimos canales que se han añadido al servidor para
facilitar así la búsqueda.
-
List Events: con esta opción nos listará todos los eventos del servidor, y en que
canales están cada uno de ellos. Dentro de esta opción podemos escoger si
queremos que nos liste tan solo los ‘x’ últimos eventos que se han añadido en
el servidor. Y a más si queremos podemos especificar no solamente en todo el
servidor sino también en un canal concreto.
-
Get Channel: con esta opción podremos conseguir información sobre el canal
concreto que le pidamos.
-
Get Event: con esta opción podremos conseguir información sobre el evento
concreto que le pidamos. Hay que tener en cuenta que si el evento se
encontrara en un canal privado no podríamos verlo si no disponemos de
privilegios.
-
Post Event: esta opción nos permite enviar un evento a un canal concreto. Si el
canal es privado necesitamos tener privilegios para poder enviar eventos.
Dentro de esta opción podemos rellenar todos los campos necesarios para
crear dicho evento.
-
Put Channel: con esta opción podremos crear un canal nuevo con todas sus
opciones y atributos.
26
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
-
Delete Channel: con esta opción eliminaremos un canal y todos sus eventos.
Está claro que para poder realizar esta acción se debe ser el creador del canal
en concreto.
-
Add RSS: con esta opción podremos sindicar cualquier canal ya creado a otro
servidor u otro canal para recibir sus eventos periódicamente.
En algunas de estas funciones se ha incorporado una opción para realizar la acción
pero solo con tus propios canales o eventos. Es decir, hemos creado como “un
espacio” en el cual las acciones que hagas solo tendrán efecto en tus canales, de esta
manera, si quieres listar solo tus canales y no todos los del servidor con esta opción se
podrá hacer.
Como hemos dicho antes todas estas funciones pueden ser ejecutadas des de la
interfaz web de la aplicación o en segundo plano mediante la api REST o mediante la
api XML-RPC.
27
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
4.- DISEÑO
4.1 Diseño de la Base de Datos
La base de datos está formada por 6 tablas que seguidamente vamos a explicar:
CREATE TABLE users (
login
CHAR(11),
pass
CHAR(11),
PRIMARY KEY (login));
Esta tabla corresponde a los usuarios del sistema, en ella guardamos un nombre de
usuario y una contraseña.
CREATE TABLE channels (
login
CHAR(11),
channel
CHAR(25),
description
TEXT(1000),
date
TIMESTAMP,
private
BOOLEAN,
PRIMARY KEY (channel),
FOREIGN KEY (login) REFERENCES users);
En esta segunda tabla guardamos los canales. Cada canal irá asociado con el usuario
que lo ha creado, y tendrá el nombre del canal, su descripción, la fecha de creación del
canal y un booleano indicando si se trata de un canal público o privado.
CREATE TABLE
login
channel
PRIMARY
FOREIGN
FOREIGN
channel_users (
CHAR(11),
CHAR(25),
KEY (login,channel),
KEY (login) REFERENCES users,
KEY (channel) REFERENCES channels);
En esta tabla guardamos los canales privados junto con el usuario que tiene privilegios
para verlo o enviar eventos. De esta forma podemos tener el mismo canal privado
pero con diferentes usuarios, que son los aceptados para que puedan ver dicho canal.
CREATE TABLE events (
channel
CHAR(25),
title
CHAR(255),
description
TEXT(1000),
date
TIMESTAMP,
PRIMARY KEY (channel,title),
FOREIGN KEY (channel) REFERENCES channels);
Esta es la tabla de los eventos, en ella guardamos todos los atributos de un evento.
Que son el canal al cual pertenece dicho evento, el titulo del evento, su descripción y
su fecha de creación.
28
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
CREATE TABLE channel_params (
channel
CHAR(25),
param
CHAR(50),
value
CHAR(255),
PRIMARY KEY (channel,param),
FOREIGN KEY (channel) REFERENCES channels);
Esta tabla guarda los parámetros de cada canal, en ella se especifica el nombre del
canal junto con el nombre del parámetro y su valor.
CREATE TABLE event_params (
channel
CHAR(25),
title
CHAR(255),
param
CHAR(50),
value
CHAR(255),
PRIMARY KEY (channel,title,param),
FOREIGN KEY (channel,title) REFERENCES events);
Finalmente tenemos la última tabla, muy parecida a la anterior, en la que guardamos
los parámetros de un evento, como el canal al que pertenece el evento, el titulo del
evento, el nombre del parámetro y su valor.
Seguidamente mostraremos un pequeño diagrama en el que se ven las relaciones
existentes entre las diferentes tablas que forman la base de datos.
Fig. 4.1 Diagrama Entidad Relación.
Está claro que antes de arrancar la aplicación web las tablas deben de estar creadas y
listas en la base de datos.
29
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Como podemos observar la base de datos consta de un conjunto de canales, cuyo
título será el tópico que determinará la clasificación de los canales y eventos.
Entonces, cada canal puede disponer de ‘x’ eventos y un conjunto de parámetros
extras que servirán, como hemos comentado anteriormente, para dar funcionalidades
extras a posibles aplicaciones clientes externas. Cada canal, a más, vendrá identificado
por el usuario que lo ha creado. Esto se hace para poder tener constancia de su
creador y saber identificarlo cuando se precise hacer operaciones comprometedoras a
dicho canal.
Por otra parte también tenemos la tabla ‘event’, en la cual guardaremos los eventos
publicados por los publicadores. Un evento siempre estará en un canal concreto, y
dispondrá, al igual que en los canales, un conjunto de parámetros que servirán para
dar funcionalidades extras a posibles aplicaciones clientes externas.
Finalmente, la última tabla, ‘channel_users’, será donde guardemos las relaciones de
canal con usuario. Es decir, cada canal con su usuario creador. Esto se hace para poder
tener una rápida referencia al creador de cualquier canal.
4.2 Estructura de la aplicación web
Como he comentado anteriormente la web ha sido creada en JAVA utilizando páginas
JSP y servlets de JAVA. Básicamente el cuerpo de la web son 3 servlets (servletREG,
servletREST, servletRPC). Los 3 se encargan de procesar peticiones o formularios. Más
adelante entraremos en más detalle sobre cada uno de los servlets.
Fig. 4.2 Diagrama de clases y flujo de la información.
30
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Como hemos dicho antes las clases principales son: servletRPC, servletREST y
servletREG. Estas 3 clases reciben peticiones de los clientes y dan respuesta a dichas
peticiones. Pero cada clase tiene una diferencia. El servletRPC devuelve toda respuesta
en formato XML. Siguiendo la especificación XML-RPC. El servletREST devuelve la
respuesta en formato HTML, interpretable por cualquier navegador estándar. Por
último el servletREG sólo recibe peticiones para el registro, logeo y deslogeo del
servidor. Los 3 servlets anteriores descritos utilizan una clase donde van todos los
métodos. Esta clase “Methods” utiliza otras para realizar sus operaciones, como son la
clase JDBC, utilizada para crear la conexión entre java y la base de datos SQL. Y la clase
RSS “Methods”, que contiene los métodos para realizar los archivos XML (RSS) de los
canales.
Una vez se ha construido la respuesta a cierta petición, esta se pasa a las clases
encargadas de dar la vista, es decir, de mostrarlo al cliente. Existen 4 clases distintas
que se utilizan para exponer los resultados. Entre todas ellas se diferencia por la forma
en que dan los resultados.
Acto seguido explicaremos más concretamente que hace cada clase y de que
sentencias está compuesta.
4.2.1 servletREG.java
Este servlet es el encargado de procesar la entrada nueva de un usuario que se acaba
de registrar y la identificación de entrada y salida que hace un usuario ya registrado en
el sistema. Este servlet acepta dos tipos de peticiones (GET y POST). Y para poder
realizar sus operaciones hace uso de otra clase muy importante en el proyecto. La
clase ‘methods’. Esta clase se explicará más adelante pero para dar un pequeño avance
diremos que es la clase donde se guardan todas las operaciones o funciones de las que
es capaz de realizar un usuario en la web.
Con este código conseguimos la sesión que un usuario ha establecido con el servidor
por haberlo visitado y por tanto podemos saber (gracias a la clase Authentication) si el
usuario es anónimo o no. Si es anónimo mostraremos menús para que se pueda
registrar o identificar y al mismo tiempo impediremos que pueda realizar funciones que solo
los miembros registrados pueden hacer.
La clase Authentication tan solo lleva los atributos de un usuario normal, su nombre,
su contraseña, etc.
31
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Para entrar un nuevo usuario a la base de datos simplemente cogemos los valores
introducidos por el usuario y comprobamos que no estén ya en la base de datos o que
no coincida con el usuario ‘Anonymous’. Una vez ha pasado estos trámites el usuario
ya es introducido en el sistema.
4.2.2 servletRPC.java
Este servlet se encarga de la parte XML-RPC, en la que se utilizan los métodos de la
clase methods. Para este fin, utilizamos el método HTTP POST, el cual deberá ser
construido con los parámetros adecuados para poder llamar a la función deseada.
XmlRpcServer xrs = new XmlRpcServer();
xrs.addHandler("method",new Methods());
try {
byte[] datos=xrs.execute(request.getInputStream());
response.setContentType("text/xml");
response.setContentLength(datos.length);
response.setHeader("Cache-Control","no-cache, mustrevalidate");
OutputStream out = response.getOutputStream();
out.write(datos);
out.close();
} catch (Exception e) {
e.printStackTrace();
}
Con este procedimiento podemos coger todas las peticiones xml-rpc que siguen la
especificación exacta del protocolo XML-RPC. Fijémonos bien en la sentencia
“response.setHeader("Cache-Control","no-cache,must-revalidate")”,
esto lo hacemos para asegurarnos que el navegador que reciba los resultados no los
guarde en la caché y erróneamente los utilice para dar futuros resultados con la misma
petición.
4.2.3 servletREST.java
Este último servlet se encarga de las peticiones REST, es decir, procesa los métodos
principales del protocolo HTTP (GET, PUT, POST y DELETE). Este servlet también hace
uso de los métodos de la clase ‘methods’. La diferencia principal con el servlet anterior
es que el anterior devolvía los resultados con un formato XML y en cambio este servlet
devuelve la salida directa en formato HTML. Es decir, este servlet es de gran uso para
hacer las peticiones rápidas sin necesidad de tratar resultados.
El funcionamiento de este servlet es sencillo. Las peticiones que puedes hacer siempre
serán con las cuatro instrucciones expuestas anteriormente, por tanto, en este servlet
32
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
tan solo miramos cuál de esas funciones es. Una vez dentro del método exacto,
tenemos que comprobar que la petición que nos han enviado contenga todos los
parámetros necesarios para realizar la acción, en este estado si no es correcto,
creamos una página de error.
Al devolver una respuesta, tenemos 4 tipos de páginas JSPs (response.jsp,
response1.jsp, response2.jsp, response3.jsp). Realmente la diferencia entre estas
páginas es como muestran los resultados.
-
Response: muestra todos los mensajes de error.
-
Response1: muestra la lista de canales y eventos.
-
Response2: muestra la información de un canal concreto.
-
Response3: muestra la información de un evento concreto.
Fig. 4.2.3 Esquema del flujo de la información.
Los métodos que permite ejecutar el servletREST son los que se explicaran en el
siguiente apartado. Tan solo hay un método que solamente puede ser invocado des de
la api REST, ese método es el “create_rss”. Este método utiliza un conjunto de clases
que están dentro el paquete RSS, que más adelante se explicarán. En ellas hay una
clase llamada RSS mediante la cual se consigue crear un archivo en formato XML (RSS).
Y es el encargado de crear los RSS de los canales del servidor.
33
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
4.3 Métodos de la aplicación
Para implementar todas las funcionalidades de la aplicación web se ha decidido crear
una clase ‘methods’, la cual contendrá todas las operaciones disponibles. Después,
cada servlet, ya es responsable de llamar a dichos métodos.
En un principio queríamos mantener la posibilidad de realizar cualquier operación de
manera anónima y sin ningún tipo de registro, pero dado que se quiere dar seguridad
en algunos aspectos, algunos de los métodos aquí expuestos requieren una
identificación para ser ejecutados, de lo contrario devuelven un error. Esta
identificación no es más que el usuario y la contraseña con la que se registra en el
sistema.
4.3.1 Methods.java
●
Esta primera función se encarga de comprobar si el usuario dado en (login y pass)
existe en la base de datos. Para realizar esta acción es necesario ejecutar la secuencia
SQL siguiente:
Si la instrucción no devuelve ningún valor, se prepara la página de error.
●
Está función permite crear un nuevo usuario en la base de datos. La instrucción SQL a
ejecutar es la siguiente:
En caso de que el usuario ya esté en la base de datos o el usuario introducido sea
incorrecto, la propia base de datos devuelve un error y el sistema construye la página
de error con dicho mensaje.
●
Esta operación lista todos los canales del sistema. El parámetro login solo es necesario
cuando el booleano ‘space’ está a ‘true’. Esto significa que solo se listaran esos canales
que sean del usuario ‘login’. Esto se hace así para facilitar la búsqueda entre canales.
Como se puede observar las operaciones que retornan valores, a no ser que sean tipos
sencillos como ‘Strings’ etc. Estos siempre devolverán vectores. Esto es así porque el
api XML-RPC nos obliga a poner este tipo de datos para la respuesta en formato XML.
34
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
//last_ones==0 && space=true
// last_ones==0&&space=false
// last_ones==1&&space=true
// last_ones==0&&space=false
Aquí se puede ver que dependiendo las opciones de búsqueda que se hayan
seleccionado se tienen diferentes sentencias SQL. La diferencia está en si solo se
buscaran los canales de dicho usuario y si solo se quiere listar los ‘x’ últimos canales.
●
Este método lista todos los eventos del sistema y se comporta de manera similar al
método anterior.
●
Esta operación devuelve un canal en concreto. Para realizar dicha operación se
requiere la autenticación del mismo usuario para validar, si fuese el caso en que el
canal fuese privado, que el usuario tuviera privilegios para poder verlo.
Para realizar la operación se siguen diferentes fases:
1- Se comprueba que el canal que se quiere listar exista.
2- Si el canal es privado, comprobamos si el usuario existe en la base de datos y si
tiene privilegios para poderlo ver.
3- Acto seguido se seleccionará el canal y sus parámetros para poder mostrarlo.
Estas son las sentencias SQL necesarias para realizar la operación.
●
Está operación se comporta exactamente que la anterior, pero en este caso lo que se
va a listar es un evento en concreto. Se requiere un usuario y una contraseña para
verificar, en el caso de que el evento esté en un canal privado, que dicho usuario tenga
35
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
derecho a verlo. Se requiere incluir el canal en el cual está, ya que un mismo título de
un evento podría estar en diferentes canales.
Estas son las instrucciones SQL necesarias para realizar la acción.
●
…
…
Esta operación nos permite enviar un evento, en principio, a cualquier canal de forma
anónima. En caso de que el canal al cual queramos enviar un evento sea privado, se
requiere una identificación mediante un login y una contraseña. Los pasos que se
siguen para realizar dicha acción son los siguientes:
1. Comprobar que el canal al cual queremos hacer el envío existe en el sistema.
2. Comprobar si el canal es privado, y si es así mirar si el usuario existe y tiene
privilegios para poder realizar el envío.
3. En caso afirmativo empezaremos a enviar el evento.
●
…
…
…
…
Esta operación nos permitirá introducir un canal en el sistema. Hay que decir que es
necesario para realizar dicha acción haberse registrado en el sistema. Cuando se crea
un canal se da la posibilidad de sindicarlo a otro servidor, canal, etc. También podemos
optar por ponerlo como privado y elegir los usuarios de la base de datos a los que
daremos permisos para que puedan postear eventos.
36
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Para crear esta funcionalidad, hemos utilizado AJAX que funciona de la siguiente
manera: cuando el usuario presiona el botón “prívate” para hacerlo privado. El
navegador envía una petición al servidor pidiendo todos los usuarios de la base de
datos que más tarde se listan en el cliente otra vez, pareciendo que solo eso se ha
cargado. Aquí es donde podemos ver una utilización óptima de las ventajas de AJAX. El
código asociado a esta acción sigue de esta manera:
Con esta pequeña función creamos el objeto o bien para Microsoft (Explorer) o bien
para Mozilla (Firefox). Este objeto (XMLHttpRequest ()) nos permitirá llamar a
funciones especificas de AJAX. Seguidamente veremos cómo llamamos al método de
listar los usuarios mediante el objeto comentado anteriormente:
…
En el método “open” especificamos el comando HTTP que queremos enviar, a la url
especifica y en el “xmlbody” incluimos los parámetros necesarios para llamar a la
función…
Volviendo a la operación “put_channel”, lo primero que comprobamos antes de crear
el nuevo canal es, si el usuario existe en la base de datos realmente. Seguidamente ya
procedemos a insertar los datos del canal, siempre y cuando no esté ya repetido en el
servidor.
Esta última sentencia SQL sirve solo en caso de que el canal sea privado, ya que ahora
lo que hacemos es introducir los usuarios que tendrán acceso a dicho canal para
postear o ver sus eventos.
37
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
●
Esta operación elimina un canal y todos sus eventos. Por este motivo es necesario que
el usuario que llame a esta función se identifique con un usuario y una contraseña para
validar que el canal sea suyo.
El primer paso es validar que el usuario exista realmente, y después se mira que sea el
creador del canal y que dicho canal también exista realmente. Las sentencias SQL
utilizadas son las siguientes:
…
…
●
Esta operación está pensada para sindicar un canal ya creado a otro servidor o canal
RSS. Para eso debes ser el creador de dicho canal, por eso es necesario un usuario y
una contraseña para la validación. A más, como es lógico debe proporcionarse la url
donde está almacenado el RSS.
Dentro de esta función se llama a un conjunto de clases almacenadas dentro del
paquete RSS. Este conjunto de clases se encarga de la gestión de los RSS (como puede
ser, la sindicación, la creación del RSS de los canales y la programación automática
para ir actualizando los RSS a los que nos hayamos sindicado). No se puede escoger el
tiempo de actualización, que por defecto se ha considerado 60 segundos.
Para lograr esto, se ha recurrido al “timer” de java. A parte se ha creado la clase
“RSSTask” que extiende de “TimerTask” y donde hay el método “run ()”. Este se
encarga de ir leyendo los RSS e ir actualizándose. A continuación tenéis el código
utilizado para coger el RSS.
Volviendo a la operación básica, los pasos que se siguen para añadir un RSS a nuestro
canal son los siguientes:
1. Comprobar que el usuario exista realmente en la base de datos.
2. Comprobar que el canal exista y el usuario sea su creador real.
38
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
●
Finalmente tenemos la última operación disponible que es la de listar todos los
usuarios del sistema. Esta operación es utilizada para privatizar los canales y escoger
que usuarios pueden tener privilegios y cuáles no. Anteriormente ya describimos como
lo hacíamos mediante AJAX.
La única sentencia SQL necesaria para realizar esta acción es la siguiente:
4.4 Gadgets implementados
Una vez teníamos hecho el servidor, queríamos añadir algún tipo de cliente para
probar la aplicación y nos decidimos por crear dos gadgets. Un gadget consiste en un
mini chat, que lo único que hace es listar los eventos que hay en un canal cada ‘x’
segundos. Para hacer esto, lo que hacemos es suscribirnos a un canal, con lo cual
recibimos su RSS. Si esto lo hacemos cada ‘x’ segundos, podemos ver cada vez cuantos
eventos hay en el canal y por tanto podemos ir listándolos, mediante AJAX, como si
fuera un chat vía web.
Esta es la función básica que está continuamente enviando los mensajes que se
escriben y recibiendo los eventos nuevos que se incorporan en el canal. Al mismo
tiempo cada vez que recibimos el RSS del canal, debemos procesarlo para coger los
eventos y escribirlos en pantalla.
39
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Como podemos ver solo mostramos el apartado JavaScript, ya que el resto del código
es simple código HTML que se encarga de la interfaz grafica del usuario.
Fig. 4.4.1 Chat creado con Google Gadgets
El segundo gadget implementado es parecido al anterior. Este consiste en ir listando
cada ‘x’ segundos los comentarios sobre un canal, evento, etc. Básicamente hace
exactamente lo mismo. Reservamos un canal, en el cual vamos a incluir todos los
eventos que hacen referencia a comentarios sobre algún canal o eventos. El gadget se
suscribe a él mediante RSS y cada ‘x’ tiempo vamos listando su contenido. A más
podemos enviar un mensaje mediante dicho gadget que se listará en el canal de
mensajes como uno nuevo.
40
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Fig. 4.4 Comments creado con Google Gadgets.
41
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
4.5 Interfaz de usuario
Como hemos comentado anteriormente, esta aplicación web permite dos tipos de
interacción con el servidor. Una en segundo plano mediante XML-RPC o mediante el
api REST. Seguidamente voy a describir la interfaz gráfica utilizada.
La página web principal muestra en la parte derecha de la pantalla el conjunto de
opciones que se pueden realizar. Estas opciones siempre serán mostradas seas el
usuario que seas, es decir, aunque seas un usuario anónimo, serás capaz de ver estas
opciones pero no podrás llevarlas a cabo si se requiere autenticación para ello.
Justo encima de estas opciones, sobre el logotipo de la web, encontramos un pequeño
formulario que nos permitirá entrar en el sistema con un usuario y una contraseña.
Este panel también será mostrado en todos los estados posibles de la web. Si somos
nuevos y todavía no hemos realizado un registro, podemos hacerlo mediante el link
“here” que se muestra en el panel rojo de más abajo. Como podemos ver, en este
panel siempre habrá un mensaje de bienvenida indicando si eres anónimo o un usuario
registrado.
Para realizar las acciones, se abre otra página web que mediante formularios recoge
toda la información necesaria. Seguidamente es procesada mediante servlets.
Fig. 4.5 Interfaz web.
42
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Fig. 4.6 Formularios.
Hay dos apartados más en la interfaz web que nos presentan las diferentes Apis con las
que podemos interactuar con el servidor. Estas Apis nos dan una descripción detallada
de cómo debemos realizar los comandos REST (GET, POST, PUT, DELETE)
correctamente para poder hacer la petición. También se encuentra la descripción para
poder comunicarnos con el servidor mediante el protocolo XML-RPC.
Fig. 4.7 Apis REST y XML-RPC.
43
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
En cuanto a los errores, estos se muestran al cliente mediante la clase “response.jsp”,
en ella se especifica, justo en el título, el servlet que ha provocado la excepción y abajo
se especifica el mensaje de error.
Algunos mensajes son errores concretos que pueden venir ocasionados por la falta de
datos en un formulario, o por datos mal formados en un formulario o incluso que la
acción realizada ha producido algún tipo de error. Otros errores vienen directamente
de la base de datos. Esto ocurre cuando por ejemplo queremos introducir un canal,
cuyo nombre ya existe en la base de datos. En estos casos el error que nos aparecerá
en pantalla tendrá una sintaxis SQL, ya que será un error devuelto por la base de datos.
Fig. 4.8 Error provocado por la base de datos.
Como podemos ver en la figura anterior, ya existe un usuario en la base de datos con
el nombre de ‘admin’, por este motivo el servlet_reg, que se encarga de la entrada de
usuarios en el servidor no avisa que ha sucedido un error provocado por la base de
datos SQL.
Fig. 4.9 Error provocado por el propio servlet.
En cambio en este otro error podemos observar, que aun y haberse provocado en el
mismo servlet (servlet_reg), el mensaje es distinto y ha sido provocado por introducir
un login o contraseña incorrecta.
Se han controlado todos los errores posibles en la interfaz web, excepto los RSS. Estos
en particular no podemos validar que la dirección que se ponga en el campo RSS sea
una dirección válida, o que, si la dirección hace referencia a un canal privado, que
tengas privilegios para poderte suscribir a ese canal.
Por otro lado, todos estos errores se muestran tanto en la interfaz gráfica (web) como
en las otras formas de comunicación con el servidor.
44
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
4.6 Metodología de desarrollo
Antes de todo, hay que aclarar que ninguna de estas etapas se ha realizado con un
inicio y un final claro, sino que se ha empezado a realizar y cuando supuestamente se
ha pensado que el trabajo de esa etapa estaba finalizado se ha empezado la siguiente
etapa. Pero si en algún momento hemos visto oportuno retocar, añadir o modificar
algún aspecto de la etapa anterior, se ha hecho. De esta manera se ha ido
perfeccionando cada una de las etapas a medida que se iba construyendo la aplicación.
La metodología de desarrollo que hemos seguido ha sido primeramente, diseñar la
base de datos. Que tablas tendría que tener, las relaciones entre dichas tablas, etc. Las
instrucciones que darían acceso a estas tablas se han creado junto con las clases que
se iban programando. La creación de todas las clases ha sido la siguiente etapa. En la
cual se ha pensado las posibles clases que podría tener la aplicación.
Es decir, antes de ponernos a hacer el diseño web o la interfaz grafica, hemos definido
los servlets que darían respuesta a todas las peticiones de los clientes. Cada uno de
estos servlets se encargaría de llamar a las funciones correspondientes para realizar
una acción. Una vez finalizada dicha acción el resultado sería devuelto en el formato
correspondiente a cada servlet. Digo esto, porque cada servlet se diferencia del otro
por la salida de datos. De este modo, por ejemplo, el servlet ‘REST’ da una salida de
datos codificados en HTML que se utiliza para ser vista des de un navegador
cualquiera. En cambio, el servlet ‘XML-RPC’ da una salida de datos codificado en un
archivo xml, para poder ser tratado por una aplicación secundaria.
Una vez hechos estos servlets y las clases que nos proporcionarían los métodos para
realizar todas las acciones. Se ha diseñado las clases secundarias que han ido
surgiendo según las necesidades de la web. Un ejemplo de esto sería la necesidad de
registrar un usuario, por lo tanto se han hecho las clases necesarias para poder guardar
la información de un usuario y clases encargadas de gestionar el estado del usuario
(conectado, no conectado, anónimo, registrado…). También para la sindicación RSS se
ha tenido que programar más clases que dieran soporte a estas acciones.
Finalmente, ya solo faltaba empezar el diseño grafico de la web. Para ello, se han
cogido distintos gráficos de internet, ya hechos. Y se ha diseñado las tablas para poder
poner estos gráficos, los textos y opciones que darían cuerpo a lo que sería el sitio
web. Esta tarea ha dado casi tanto trabajo como la programación de las clases. Ya que
se mantienen muchas páginas web para dar respuesta a errores, resultados, vistas, etc.
Una vez ya finalizado el aspecto gráfico de la web se ha implementado los gadgets para
crear un pequeño cliente que probara el servidor.
45
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
5.- RESULTADOS
Para probar toda la aplicación web se requieren muchos tipos de pruebas. Por un lado
se necesitaría probar la aplicación desde su interfaz grafica. Lo cual lo hemos hecho
personalmente probando todas las posibles acciones. Cuando los resultados son
buenos, se realiza la acción y se nos muestra su correspondiente mensaje. Al igual pasa
cuando la acción realizada por algún motivo ha fallado y se nos muestra también su
correspondiente mensaje de error.
En el proceso de prueba con la sindicación RSS tuvimos un pequeño problema. Y es
que en un principio solo se contempló la posibilidad de poder suscribir nuestro canal a
otros RSS, pero después de ciertas pruebas observamos que también existe otro
formato parecido al RSS, que es el RDF, y que no sigue el mismo formato que el RSS. Lo
que hicimos fue adaptar la sindicación de tal forma que ahora se pueda sindicar
nuestro canal tanto a un RSS como a un RDF. Hicimos diferentes pruebas y fueron
satisfactorias. En cuanto a las acciones normales del servidor, probamos de añadir un
canal, sindicarlo a otro, añadirle parámetros, añadirle eventos, listarlo y borrarlo.
Todas estas acciones funcionaron correctamente y en caso contrario mostraron un
mensaje de error totalmente comprensible. También hicimos lo mismo con las
acciones que hacen referencia a los eventos y de igual forma funcionaron
correctamente.
Hay que añadir aquí, que en teoría queríamos que nuestro servidor fuera totalmente
libre, sin necesidad de pedir usuarios ni contraseñas. Pero al querer incorporar la
posibilidad de admitir canales privados nos vimos obligados a implementar métodos
más seguros, es decir, a pedir nombres de usuarios y contraseñas, que han dificultado
un poco la implementación.
En cuanto a otras formas de utilización de nuestro servidor. Nos hicimos una pequeña
aplicación que mandaba mensajes HTTP con los métodos GET, POST, PUT y DELETE. En
todos ellos tuvimos éxito en su ejecución. Las acciones de cada método se realizan y
los resultados son devueltos en formato HTTP que pueden ser interpretados por
cualquier navegador. En la página web de la aplicación se encuentra la especificación
exacta de cómo formar los distintos mensajes para enviarlos.
Siguiendo con la otra forma de utilización del servidor, con el protocolo XML-RPC,
también nos hicimos un pequeño programa, el cual se encargaba de enviar mensajes
POST con sus correspondientes parámetros, tal y como específica el protocolo XMLRPC. En este caso hemos ejecutado todas las operaciones posibles y el resultado ha
sido positivo. Sus acciones se realizaban y nos devolvía el resultado en formato XML tal
y como específica el protocolo. Esto lo hace tanto si el resultado es positivo como si lo
es negativo.
46
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
Una vez visto que las principales acciones funcionan de todas las maneras posibles, se
ha comprobado que también funcionen bajo otras circunstancias susceptibles de que
traigan errores como listar eventos de un canal privado siendo un usuario anónimo,
sindicarme a un canal privado sin permisos, dar privilegios a los usuarios para que
puedan ver mi canal privado, listar los ‘x’ últimos canales/eventos añadidos en el
servidor, etc.
Finalmente para crear un cliente y ver realmente que funcionaba todo, hemos creado
2 gadgets que utilizan el api REST para mandar mensajes y reciben un resultado en
formato XML (en la sindicación de un canal). En este apartado hemos tenido un
problema de seguridad que está asociado al objeto ‘XMLHttpRequest’ de AJAX.
Exactamente consiste en que los métodos de este objeto como ‘open (“url”,…)’ no
pueden acceder a cualquier servidor que no sea el mismo del cual procedan. Es decir,
que en el parámetro “url” no podemos poner el servidor que nosotros queramos, solo
nos permite poner la misma url que nos ha enviado dicho script AJAX. Esto es así para
evitar problemas de seguridad en que un posible componente AJAX se nos pudiera
conectar a otro servidor e intercambiar con él información comprometedora. Esto se
comprobó en el momento que subimos un gadget al directorio de google gadgets. Lo
que quisimos es, acceder a ese gadget de google y que dicho gadget utilizara mi
servidor para listar los eventos de un canal concreto. Pues bien, lo que estábamos
haciendo exactamente era acceder a otro dominio distinto del de google, que era
donde estaba colgado nuestro gadget. Con lo cual en cualquier navegador nos
mostraba el mensaje de ‘permiso denegado’.
Ante este error, si lo que queríamos era, que mediante un gadget de google
pudiéramos acceder a nuestro servidor, lo que hicimos fue alojar este script AJAX en
nuestro servidor, y el gadget que almacenábamos en el directorio de google
simplemente era un código en el cual hacía referencia a nuestro servidor donde tenía
que ir a buscar el código real del gadget. Así en la página principal de google se abría el
gadget, pero realmente lo estaba buscando en mi servidor. De esta manera, ahora si
funcionaba ya que las llamadas a mi servidor se producían en el mismo dominio y no a
una “url” distinta.
A modo de conclusión, se puede decir que todas las pruebas llevadas a cabo con el
servidor y con los gadgets de google han sido satisfactorias demostrando un correcto
funcionamiento del sistema web.
47
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
6.- CONCLUSIÓN
Después de realizar un gran número de pruebas y de obtener los correspondientes
resultados, considero que se han alcanzado los objetivos iníciales de este proyecto. Y
que utilizando el servidor web implementado como a middleware se puede ahorrar
mucho trabajo a futuros programadores de servicios web, como en la implementación
de foros, canales de noticias, etc.
Del diseño del sistema se pueden extraer las siguientes conclusiones. En primer lugar
decir que la utilización de la tecnología AJAX permite dar un paso más en la
programación web. En el sentido de comodidad al cliente, ya que da la sensación de
estar programando una aplicación casi de escritorio y no las típicas aplicaciones web
donde en cada momento estamos cargando el contenido del sitio web. Por otra parte
también hemos visto que depende el uso que hagamos de AJAX lo que podemos
conseguir es que el servidor trabaje más de lo debido y por tanto lo sobrecarguemos
mas. Todo depende de la cantidad de peticiones que hagamos al servidor. También
destacar que el hecho de dar al servidor la característica de recibir y responder
peticiones mediante la api REST y el protocolo XML-RPC permite al sistema dar al
cliente una mayor usabilidad y facilidad en cuanto al uso de dicho servidor como
middleware. Y finalmente el uso de la sindicación vía RSS o RDF, ha permitido dar un
paso más en la comunicación entre servidores y permitir crear una red donde
cualquier servidor puede estar comunicado al instante de cualquier evento en
cualquier otro servidor.
En el ámbito personal, la realización de este proyecto ha sido muy enriquecedora, ya
que me ha permitido conocer casi todas las tecnologías que envuelven una aplicación
web. Por ejemplo, y como gran novedad, la tecnología AJAX. Que al mismo tiempo que
hablamos de AJAX, también hablamos de javascript. Por tanto esta tecnología te obliga
a comprender este lenguaje de programación en el cliente. Con los distintos métodos
de comunicación que permite este servidor también he podido aprender nuevos
protocolos, a parte del HTTP (REST), como es el XML-RPC, que incluso y trabajar bajo
HTTP, sus parámetros son muy diferentes. Y sin dejar de lado, el diseño de una base de
datos comunicándose con servlets de JAVA, que pese a haber hecho algo en la
universidad, con este proyecto he consolidado todavía más todas estas tecnologías y
una vez finalizado el proyecto me he visto capaz de realizar aplicaciones web más
complejas y con las nuevas tecnologías existentes.
48
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
7.- TRABAJO FUTURO
Como he podido observar, crear una aplicación web conlleva un trabajo muy laborioso,
y por tanto esta aplicación web podría mejorarse mucho en cuanto a calidad y
funcionalidades. Como por ejemplo:
-
Añadir más funciones a la interfaz grafica para que los clientes que envían
eventos les sea más fácil esta tarea.
-
Permitir investigar más sobre la escalabilidad del sistema. Comprobar cuántos
clientes pueden conectarse y enviar peticiones y ver sus límites. Y respecto a
esto intentar crear métodos para repartir el trabajo entre distintos servidores
etc.
-
Añadir más formas de comunicarse con el servidor, como por ejemplo, dar la
posibilidad, con el api REST actual, de recibir las respuestas en formato JSON.
Para facilitar todavía más al cliente, el tratar la respuesta del servidor.
Realizando estos cambios conseguiríamos una aplicación web más rica y al mismo
tiempo un sistema más robusto para aguantar un gran volumen de información.
49
SERVIDOR PUBLISH/SUBSCRIBE Raúl Llorach Sánchez
8.- RECURSOS UTILIZADOS
→ http://es.wikipedia.org/wiki/Portada
Esta página web es una gran enciclopedia, que me ha permitido buscar gran
información sobre conceptos en general, (REST, XML-RPC, RSS, RDF, AJAX, etc.).
→ http://www.xmlrpc.com/spec
En esta página web se encuentran todas las especificaciones exactas para poder
trabajar de forma correcta con el protocolo XML-RPC.
→ http://www.rss-specifications.com/rss-specifications.htm
En esta página web se encuentran todas las especificaciones sobre el formato xml que
sigue el RSS. Sus campos, valores, etc.
→ http://www.xfront.com/REST-Web-Services.html
En esta web encontramos una gran explicación de los servicios que funcionan
mediante REST. Da ejemplos y ayuda a comprender su funcionamiento.
→ http://www.dynamicajax.com/
En esta página web encontramos cantidad de tutoriales para adentrarse en el mundo
AJAX.
→ http://dev.mysql.com/doc/refman/5.0/es/index.html
Sitio web donde se encuentra un completo manual sobre la configuración y utilización
de la base de datos MYSQL.
→ http://java.sun.com/j2se/1.5.0/docs/api/
El Api de java utilizado.
50