OpenProdoc: creando un Gestor Documental en solitario

openprodoc

Cuando desde este blog se me invitó a hablar sobre OpenProdoc (en adelante OPD), pensé en qué aspecto podría resultar más interesante. Mejor que un análisis sobre sus ventajas e inconvenientes, que Adrián Macías está ya realizando con mayor distanciamiento, llegué a la conclusión de que contar el proceso de construcción del software podría resultar de interés, tanto para tener una visión completa de todos los pasos para la construcción de un gestor documental de principio a fin, como por estar realizado por una única persona.

La primera duda que quizá surge es si es posible desarrollar un gestor documental “serio” y completo por una sola persona. La respuesta es que sí. Es complicado y lleva mucho trabajo, pero es posible. OPD está disponible para comprobarlo. No tiene desde luego todos los módulos opcionales de otros productos (BPM, Digitalización, Colaboración,..) pero sus funciones son comparables al núcleo base de Alfresco, Filenet o Documentum.

¿Por qué hacerlo?

Principalmente como reto profesional y también para tener el Gestor Documental que a mí me gustaría como usuario. He utilizado y desarrollado proyectos sobre muchos gestores y cada uno tiene sus lados fuertes y sus fallos. Se trataba de unir las funciones preferidas de cada uno (las cuales tendrán distinta valoración según cada persona). Adicionalmente, cuando comencé no había muchos gestores Open Source, y me parecía necesario cubrir esa carencia.

Por último, como forma de aprender, ya que no había desarrollado un gestor documental desde cero, y eso implica analizar aspectos de bajo nivel y diseño que no suelen tenerse en cuenta habitualmente pues ya vienen dados en los proyectos por el producto sobre el que se trabaja.

Especificación de Requisitos

Como en cualquier proyecto, el primer paso es la especificación de los requisitos a cubrir. Hay una frase muy significativa: “Desarrollar un proyecto a partir de sus requisitos es tan fácil como andar sobre las aguas. Basta que ambos estén congelados y sean sólidos”. Esta es la fase más importante con diferencia y debe definirse muy claramente qué es lo que se quiere conseguir, sin ambigüedades.

A continuación, enumero de forma resumida los requisitos escogidos, por orden de prioridad (La prioridad es un elemento importante, no solo para elegir el orden de construcción sino sobre todo para decidir cuándo hay colisión entre diversas necesidades).

  1. Uso sencillo para usuarios y administradores.
  2. Posibilidad de definir tipos documentales y tipos de contenedores (expedientes/carpetas/series).
  3.  Manejo de documentos y contenedores orientado a objetos.
  4. Interfaz personalizable en idioma y apariencia para cada grupo de usuarios.
  5. Modelo basado en conectores para permitir su ampliación.
  6. Seguridad avanzada basada en ACL.
  7. Gestión de tesauros y listas de términos controlados para los metadatos.
  8. Compatibilidad con el mayor número posible de bases de datos,  servidores y sistemas operativos.
  9. Posibilidad de importar y exportar definiciones, documentos y expedientes.
  10. Gestión de grupos anidados.
  11.  Granularidad de la administración para permitir diversos perfiles y administración “delegada”.
  12. Manejo de atributos multivaluados.
  13. Rendimiento alto.
  14. Cliente Ligero (web) y cliente pesado Multiplataforma .
  15. Versión portable
  16. Interfaz uniforme en todos los clientes.
  17. Diversos tipos de repositorios para almacenar documentos.
  18. Diversas formas de autenticación de usuarios.
  19. Escalabilidad.
  20. Alta disponibilidad
  21. Gestión de tareas/procesos.
  22. Papelera de documentos.

No incluyo todas las funciones mínimas de cualquier gestor documental (control de versiones, histórico, checkin-checkout, inserción y búsqueda de documentos, seguridad, ..) que serían los mínimos para poder ser clasificado como gestor documental. Algunos requisitos, como cliente Web totalmente accesible (clasificación AAA) no pudieron ser implementados, pues colisionaban con el requisito 17 y hasta cierto punto con el 1, debido a la necesidad de utilizar Javascript. No obstante se ha tenido especial cuidado en la accesibilidad de la interfaz web, y además al poder configurarse un interfaz personalizado para grupos de usuarios, puede crearse un interfaz para usuarios con baja visión (alto contraste, fuentes grandes, etc. (…)

Diseño del producto

Una vez definidos requisitos, la siguiente fase es el diseño: Arquitectura, Lenguajes, Bases de datos, servidores (…).

Como arquitectura se ha elegido un modelo particular, más cercano a los modelos Cloud, ya que no existe un servidor único. Se basa en un “motor” que puede instalarse en tantos servidores o equipos como se desee. Incluso los puestos cliente incluyen el “motor”, que debido a su diminuto tamaño no presenta problemas. Esto reparte la carga y hace todo el sistema muy escalable.

El almacenamiento de los documentos puede realizarse en múltiples repositorios de diverso tipo, por lo que no representa un problema de rendimiento o escalabilidad.

La información de los metadatos y configuración del sistema se almacena en una base de datos común a todos los nodos. Por tanto la escalabilidad y alta disponibilidad de la base de datos son los únicos elementos que limitan la solución.

El cliente ligero web se ha desarrollado como aplicación J2EE basada en servlets y se despliega en cualquier servidor de aplicaciones al modo “tradicional”, embebiendo el motor.

Como lenguaje de desarrollo, desde luego se partía del requisito técnico de utilizar un lenguaje orientado a objetos, debido a las ventajas que proporciona, y compilado, por la eficiencia y calidad que aporta. Tras analizar las ventajas e inconvenientes de utilizar C++ o Java, opté finalmente por el uso de Java, debido a las ventajas que aportaría la portabilidad multiplataforma o la posibilidad de desplegarlo en servidores de aplicaciones J2EE.

Todo el desarrollo está muy orientado a objetos, con gran uso de herencia y polimorfismo. Esto incluye no solo los elementos de lógica interna, sino incluso los elementos de interfaz de usuario (formularios Swing o Web, controles html, etc).

En cuanto a la base de datos, un requisito muy importante era la posibilidad de desplegarlo en cualquiera, por lo que se ha tenido especial cuidado en evitar el uso de elementos propietarios. El resultado es que la aplicación resulta compatible con todas las bases de datos probadas hasta el momento (MySQL, HSQLDB, Oracle, DB2, PostgreSQL, Derby, SQL-Server).

Quizá la fase más importante del diseño en este proyecto ha sido el modelado de la base de datos. Debe tenerse en cuenta que en un gestor documental puede definirse diferentes tipos documentales o de expedientes, cada uno con diferentes metadatos. El modelo elegido para crear y utilizar todas las tablas internas así como para contener las nuevas definiciones es crítico y determina no solo el rendimiento, sino las funciones que puede ofrecerse. Como “subproducto” del estudio que realicé para el proyecto elaboré un artículo sobre el tema: Definición de tipos documentales en los productos de ECM. Implicaciones de la forma de implementación en SGBD.

Construcción

Para iniciar el desarrollo, lo primero es elegir herramientas de desarrollo y el repositorio donde mantener diusponibles las versiones y difundir el código.

El desarrollo se ha realizado íntegramente sobre un PC con Linux. Se ha utilizado Netbeans como herramienta de desarrollo Java. En mi opinión es el entorno más eficaz y más sencillo de utilizar. La depuración se ha realizado utilizando las herramientas integradas, la base de datos Apache Derby y servidor de aplicaciones Glassfish.

Hay que destacar varias herramientas adicionales imprescindibles:

  • Squirrel SQL: un cliente Java multiplataforma de acceso a Bases de datos. Permite trabajar sobre todo tipo de bases de datos de forma muy sencilla, verificando el resultado de las distintas operaciones realizadas desde el programa, comprobando compatibilidad SQL o simplemente actualizando datos.
  • Firebug: un plugin de Firefox que permite analizar y depurar TODO lo que ocurre en el navegador (Javascript, comunicaciones, elementos html, css,..).
  • Virtualbox: Para la comprobación de compatibilidad con diversos sistemas operativos, bases de datos o navegadores se han utilizado máquinas virtuales. En algunos casos descargando las máquinas virtuales completas (appliance) que ofrece el fabricante (Ej. Weblogic-Oracle) y en otros complementando un sistema base con los componentes opensource necesarios (ej. XAMP) o con las versiones reducidas/express que ofrecen muchos fabricantes de software comercial (Ej. DB2).
  • HSQLDB: Como base de datos para embeber en la distribución portable, tras analizar Apache Derby, SQL-Lite y HSQLDB, elegí HSQLDB por rendimiento, por ser Java puro y por ofrecer funciones adicionales (administración, servidor,..) en un único paquete muy compacto y reducido, acorde con la misma filosofía de construcción de OPD.

En cuanto al repositorio, tras evaluar SourceForge y GoogleCode, opté finalmente por GoogleCode, utilizando Subversion como control de versiones, aunque estaba más familiarizado con SourceForge, ya que conozco y utilizo diversos proyecto albergados allí. El optar por Google se debió tanto a las mejores posibilidades de difusión como al contrato/condiciones para albergar el proyecto, ya que en SourceForge me parecía, más que un “Contrato de depósito”, un “Contrato de Donación”.

google code

Pruebas

Se han realizado pruebas de tres tipos:

  • Durante el desarrollo se comprobó el correcto funcionamiento de cada uno de los elementos desde el entorno de desarrollo NetBeans. Utilizando las herramientas de depuración se diagnosticaron errores de desarrollo, fallos de diseño, etc.
  • Una vez finalizada una etapa, se generaba el paquete de instalación y se comprobaba en una máquina virtual no solo el correcto funcionamiento del mismo sino el funcionamiento de las distintas versiones de la aplicación en un entorno “limpio”. Esto permitía detectar errores de instalación y también problemas de funcionamiento no descubiertos sobre el entorno habitual de trabajo.
  • Por último, se realizaron pruebas de carga con un doble objetivo. Por una parte medir el comportamiento ante miles de peticiones en un intervalo corto de tiempo, y por otra parte conducidas a la detección de fallos de desarrollo o retrasos que puedan producirse en situaciones de carga muy elevada. Estas pruebas, además de detectar y corregir algún problema de concurrencia, han mostrado un rendimiento muy alto (más de 200.000 documentos insertados por hora con un único servidor, un PC doméstico).

Distribución

Para la distribución como Open Source he optado por usar una licencia GPL 3.0. Adicionalmente se plantea como un sistema multilicencia, de forma que si alguien estuviera interesado en utilizarlo en un proyecto con otro tipo de licenciamiento (incluido sistemas no opensource) se puede analizar y estudiar.

Además de las posibilidades de descarga desde Googlecode (que por cierto cambian a partir de 2014) está disponible para su descarga en distintos puntos que realizan copias periódicas, como www.softpedia.com  o www.portalProgramas.com.

Situación actual

En estos momentos está disponible para su descarga la versión 0.8.1 en nube de Amazonhttp://code.google.com/p/openprodoc/downloads/list. La versión 0.9 está en desarrollo e incluiá como principal novedad la gestión de tareas/procesos, tanto programados cronológicamente como por eventos (ej. al insertar o actualizar documentos o expedientes). Además gracias a la colaboración de dos personas, estará traducido al catalán y al gallego. A ello se une un cambio en la arquitectura que aumenta la seguridad y permite trabajar con servidores en modo “caché”. Por último, podrá utilizarse como repositorio de documentos la nube de Amazon por medio de aws S3.

 

¡Evita las sanciones del GDPR!