Durante los últimos tres meses en zylk hemos estado
desarrollando, conjuntamente con personal de EJIE (Oscar Guadilla
en la definición de la arquitectura y gestión del proyecto,
Carlos Gonzalez de Zarate y Roberto
Tajada en la parte de platea integración y Juan
Uralde en la parte de xlnets) , una aplicación horizontal
para el intercambio temporal de ficheros. La problemática que se
quería resolver era la siguiente:
- Disponer de un sistema para que las distintas aplicaciones,
situadas en los distintos entornos (extra, intra, inter etc..),
pudieran intercambiar ficheros. - Disponer de un sistema de trazas/auditoria, consultable en tiempo
real capaz de almacenar la información de millones de transacciones. - Disponer de un sistema de eventos que permitiera
la comunicación asíncrona entre las distintas aplicaciones (en lo
que a intercambio de ficheros hace referencia) - Disponer de una librería de cliente, para navegadores, que
mejorara la experiencia de usuario a la hora de gestionar
ficheros en aplicaciones web. - Disponer de un API java que sirviera tanto para jdk 1.4,
como para jdk 1.5+ - Disponer de un API batch.
- Disponer de un API WebService
El proyecto se dividió en dos partes.
- Una primera en la que se hicieron las pruebas pertinentes para
seleccionar las tecnologías y los patrones
necesarios para el desarrollo. (Tres semanas de trabajo) - Una segunda en la que se realizó la implementación de la
solución y se depuraron todos los aspectos que no se
habían tenido en cuenta en la fase de análisis/pruebas
(Nueve semanas de trabajo)
A continuación se muestra un gráfico de los distintos componentes que
conforman las solución.
Y los distintos métodos que se pensaba crear y exponer en cada canal.
Como eje principal de la solución se optó por usar hdfs (hadoop distributed file
system1).
La idea original era crear una API java
recubriendo el API original de hadoop para exponer los siguientes métodos:
- move
- info
- copy
- list
- put
- get
La primera pega que nos encontramos fue que el API de HADOOP solo se puede ejecutar con
java 1.5+ lo que nos obligó a crear un nuevo canal de
comunicación para exponer el API java 1.4. Para ello
expusimos los métodos por medio de un API REST y creamos un cliente
compatible con java 1.4 para dichos métodos. Tanto el API para java
1.4 como el de 1.5 se instancian usando una factoría abstracta
que permite cambiar del API 1.4 al API 1.5 con tan solo cambiar las
implementaciones ya que creemos que en un futuro próximo
todas las aplicaciones correrán con java 1.5+
A continuación
mostramos un diagrama de como se han creado las
implementaciones y las interfaces relacionadas con el proyecto.
Una vez tuvimos el core creado y consensuado nos centramos en el
resto de las partes, a saber
- Sistema de trazas.
- Eventos (platea integración).
- API WS.
- Widget para upload.
A continuación presentamos un gráfico que resume todos
los canales de comunicación entre los distintos APIs y componentes.
Donde se pude ver que al core se le han añadido las funcionalidades
de trazas, metadatos y seguridad basada en xlnets.
Para el sistema de trazas se han utilizado
colas JMS con
un MDB que publica los mensajes en una base de datos noSQL como mongo-db. Se optó por esta solución
porque después de hacer pruebas de rendimiento se conseguían un
rendimiento entre 5-10 veces superior que en tablas relacionales. Hay
que decir de todas formas que en este caso el concepto de noSQL
encajaba a la perfección con el problema que se quería solventar al
igual que los conceptos de listas finitas, orden natural inverso etc..
Para la parte de metadatos se ha optado por
almacenar los mismos serializados en json en el propio hadoop,
por un tema de auto-consistencia del filesystem. Aunque creemos que a
esta parte habría que darle todavía una vuelta más e ir a un
modelo de tablón basado en HBASE, por ejemplo. Si se hiciera
esto se estudiaría también la posibilidad de cambiar el sistema de
trazas a HBASE también.
Para el componente de upload se ha usado SWFUPLOAD, ya que se intentó usar los
blobs de javascript que permiten no usar flash, pero internet-explorer
en su versión 8 no los implementa todavía. Hay que destacar que para
poder usar SWFUPLOAD en un entorno seguro que use las cookies para
mantener la sesión hay que sortear unos pequeños problemas de
flash con las cookies … pero eso es otra historia.
Para la parte de seguridad, simplemente se han
usado las librerías de xlnets.
Para la parte de eventos se uso platea integración.
Otra de las partes que se usó, fue el map-and-reduce para
el expurgo de ficheros, para lo que hadoop evidentemente nos sirvió.
Creo que esto es más o menos todo, la verdad es que la solución
final es bastante potente y creemos que puede evolucionar
satisfactoriamente y cubrir las necesidades para las que se ha diseñado.
