Como siempre somos muy dados a las siglas, y en el caso de los Gestores de Documentos (o documentales como también se les llama) no íbamos a ser menos. DMS son las siglas de las palabras inglesas Document Management System. El tema es que estos dias y relacionado con mi trabajo profesional, me he visto en la necesidad de buscar un DMS «de pago». Como no podía ser de otra forma, me ha picado la curiosidad por ver que es lo que hay que sea de código abierto o también si es posible libre (no es lo mismo, claro). 😀
En principio no había encontrado mucho, pero es aluncinante, siempre hay algo. Tengo que decir que levantó la liebre uno de pago que por debajo utiliza en parte un proyecto de Jakarta llamado SLIDE, para implementar el almacenamiento con XML. Por cierto, el proyecto SLIDE me ha parecido más que interesante, soporte versionado de documento, bloqueo exclusivo y otras interesantes características. Muy a tener en cuenta.
Hoy haciendo una búsqueda en Google por «java slide document management» de repente me he encontrado un par de enlaces que recopilaban varias cosas interesantes. En concreto estos enlaces son:
De entre ellos, y también relacionado con SLIDE, me ha llamado la atención JACKRABBIT, que implementa JSR-170. Seguiré comentando cosas sobre todo esto, ya que aquí hay mucho que rascar.
16 de febrero, 2006 a las 12:22
Acabo de ver tu comentario. Finalmente evaluamos con mucho detalle Alfresco y Jlibrary (http://jlibrary.sourceforge.net) y finalmente nos decantamos por Jlibrary.
Tengo que publicar un análisis más detallado de las conclusiones, pero te adelanto que Alfresco es absolutamente impresionante, desarrollado por exdesarrolladores de Documentum, y utiliza un montón de tecnología estandard, inclusive MyFaces, pero tiene un gran pero, y es que, sobre haber una versión Open Source, está «capada», de tal forma, que no tiene grupos en la versión Open Source, solo usuarios, y la integración LDAP, la tienes que hacer tu. Lo de la intregración LDAP no fué un problema, pero lo de los grupos si, ya que eso nos producía muchos problemas. De todas formas, la herramienta es impresionante.
Con Jlibrary lo teníamos todo. Está basado en Jackrabbit (Alfresco creo que con Slide que es anterior) y tiene todo. La diferencia básica, además de los peros de antes, está en el entorno de gestión que no es web, si no un plugin de eclipse, pero implementa absolutamente JCR, es decir, es absolutamente estandard, y puedes conectarte por webservices o directamente a través de su api. El cliente por web lo estamos integrando nosotros, pero no es especialmente complicado.
En fin, espero que te haya servido de algo. 😀
2 de marzo, 2006 a las 13:45
Openfree,
Nosostros también hemos estado mirando lo mismo que tú y me parece que nos decantamos por jlibrary. Pêro tengo algunas dudas respecto a la integración con LDAP y el cliente web.
¿Puedes decirmes algo de tu experiencia al respecto?
Saludos.
7 de abril, 2006 a las 11:05
Las dos cosas justas que estás comentando ha sido donde estamos trabajando. La integración LDAP que nos hacía falta ha sido «fácil», ya que hemos modificado el jlibrary-server.jar para que cuando hace login, haga login contra nuestro LDAP, y que crees los usuarios necesarios en función de nuestros usuarios LDAP. Los ROLES los pilla también de nuestro LDAP (simplemente una clave más que ya nos servía en nuestra aplicación).
Respecto a la parte WEB, como sabes, Jlibrary no la tiene, y nos la hemos tenido que currar nosotros en el proyecto. Uno de nuestros programadores va a «devolver» a la comunidad, con su experiencia, una colaboración con el proyecto Jlibrary (si puede ser) para que Jlibrary pueda tener este tipo de cliente.
Jlibrary tiene, que yo sepa, dos manera de «atacar» el repositorio: directamnte y por webservices. Nosotros lo atacamos directamente de momento, aunque el poder hacerlo por webservices es muy interesante para, en un futuro, poder separar el servicio a otros servidores.
Hay que tener en cuenta que, solo se puede tener una instancia abierta del repositorio, por lo que eso condiciona que, si tiene abierto el repositorio con el cliente jlibrary, no puedes tenerlo abierto por web y viceversa, por eso el disponer de un cliente de acceso único (web o webservices) es más que interesante, para un uso col.laborativo.
Espero que los datos que te doy te dén pistas, de todas formas, puedo comentar más cosas, si quieres.
Saludos.
27 de mayo, 2008 a las 08:59
Estoy interesado en la evolución de jlibrary, ya que pretendo utilizarlo para el desarrollo de un archivo documental de consulta pública.
Me gustaría el punto de vista de alguien con experiencia en el producto sobre sus posibilidades en búsquedas por contenido en ficheros binarios, p.e. pdf, y respecto a las posibilidades de acceso a la documentación según perfil de usuario. Estos aspectos son críticos para tomar mi decisión.
No descarto otras posibilidades, pero por ahora jlibrary es mi mejor candidato.
Saludos y gracias.