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.
