Uno de los últimos proyectos en los que ha estado trabajando el equipo ha sido la segunda parte del proyecto relacionado con el intercambio de ficheros usando HADOOP comentado en el post Usando hadoop para intercambio masivo de ficheros en un contexto de big data.
El equipo responsable del desarrollo ha sido el mismo que en el caso anterior. Por parte de EJIEOscar 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, y por parte de zylk Irune Prado y Gustavo Fernández
En su primera versión el API de intercambio de ficheros para EJIE nos dejó la posibilidad de utilizar las operaciones básicas típicas de un CRUD: info, list, put, get, move, copy y delete.
El propósito de esta segunda iteración ha sido ampliar el número de accesos al API, incluyendo así el uso de:
- REST: J2EE y acceso vía curl
- WEBDAV
- Acceso a gestor de ficheros web
Además de realizar tareas de mantenimiento generales para madurar el producto en base a las necesidades detectadas durante su primer año de vida.
Acceso REST
En la primera versión ya se contemplaba la existencia de un API REST, pero con una explotación diferente a la actual. Como ya se comentó en el previo post, el API de HADOOP requería una versión 1.5+ de Java, pero a su vez se requería que el API fuera accesible con un Java 1.4. La solución vino con una exposición de la implementación en 1.5 mediante REST, para que se consumiera como tal en la implementación para 1.4.
Durante esta fase se han realizado pruebas para consumir este API REST desde diferentes clientes.
- Acceso J2EE vía REST: Pruebas sobre el API REST haciendo uso de las librerías Commons IO para la gestión de stream y FlexJSON para el manejo de JSON.
- Acceso J2EE vía CURL (shell): Pruebas del API REST haciendo uso de la herramienta curl. En esta vertiente se desarrolló también un script de shell a modo de KIT, para poder invocar este tipo de comandos desde un formato más simple.
$>./y31ApiBatchPersona.sh t17i t17i list /t69i
$>./y31ApiBatchPersona.sh t17i t17i info /t69i
$>./y31ApiBatchPersona.sh t17i t17i put fichero.txt /t69i/put/fichero.txt
$>./y31ApiBatchPersona.sh t17i t17i copy /t69i/mv/fichero.txt /t69i/fichero.txt
$>./y31ApiBatchPersona.sh t17i t17i delete
Acceso WebDAV
El acceso vía WebDAV es algo implementado en su totalidad en esta fase. Así se posibilita tanto a usuario como a aplicación del acceso haciendo uso de sus credenciales XLNet de usuario y contraseña.
- Acceso J2EE WebDAV: Se han realizado ejercicios de prueba para este acceso usando la librería Sardine.
Las unidades WebDAV se pueden montar con clientes nativos de los sistemas operativos, como pueden ser:
- Cliente webdav de windows
- Cliente webdav de Gnome (nautilus)
- Cliente webdav de Android (hay varios)
Esto permite trabajar con la zona de intercambio desde cualquier dispositivo usando un canal estándar. A continuación se muestra una vista de la unidad webdav montada en un linux
y una vez configurada y montada:
Acceso a gestor de ficheros web
Hasta ahora la plataforma para el intercambio de ficheros carecía de un interfaz de usuario que integrara la visualización de archivos así como la gestión de estos y es por ello que nació la idea de un gestor de archivos web, o concepto de Box (a modo de DropBox).
El componente base de este gestor de ficheros es elFinder, un componente Javascript desarrollado de forma transparente a su implementación, ya que mantiene una interfaz JSON entre el backend y frontend.
Además de la implementación Java del backend mediante el uso del API de ficheros desarrollado en la etapa anterior, se han realizado diversas modificaciones al componente.
Además creemos que el proyecto puede ser interesante y una vez implantado en EJIE, desde zylk.net estamos realizando algunos cambios en el mismo para poder desacoplar la seguridad y el bus de eventos de los componentes usados en EJIE (xlnets y bus de weblogic). En este caso hemos creado una implementación que usa rabbit-mq y hace uso de la seguridad del contenedor. Si alguien está interesado en su uso se puede poner en contacto con nosotros para intentar montar un proyecto en google-code y poder evolucionar el desarrollo. Tenemos una versión funcional del proyecto montada sobre tomcat, rabbit-mq y conectada a un openldap para proveer los usuarios.
