WWW EPI

Octubre 1997

Mezzanine y Saros Document Manager: arquitectura, descripcion y recuperacion de documentos (Parte I)

Por Ricardo Eíto Brun

Ambos programas configuran la plataforma cliente/servidor diseñada por Saros para satisfacer las necesidades de gestión documental.

Saros, compañía fundada en 1986, fue adquirida por FileNet en marzo del pasado año. Con esta operación, FileNet concluía una agresiva política de adquisiciones con la que consiguió aglutinar un conjunto de aplicaciones de reconocido prestigio. Si repasamos la historia de FileNet desde su fundación en 1982, encontramos:

1. la compra en julio de 1995 de Watermark, empresa que producía una solución imaging para servidores Windows NT;
2. la adquisición a comienzos de 1996 de International Financial Systems, distribuidores del software Greenbar Cold (Computer Output Laser Disk);
3. en marzo de 1996, la adquisición de Saros.

De esta forma, FileNet integraba una serie de aplicaciones de primera línea en torno a su solución imaging IMS, y a su motor Workflow de propósito general, introducido en el mercado a finales de 1994.

FileNet no sólo distribuye separadamente estos productos, sino que ofrece la posibilidad de integrarlos entre sí y con cualquier otra aplicación mediante APIs (application program interfaces).

Otro conocido producto de FileNet es Ensemble, destinado a la gestión del flujo de tareas a partir de la mensajería. Ensemble está integrado en el software GroupWise de Novell.

Saros Document Manager

La versión 4.0 de este programa se lanzó al mercado el mes de mayo de 1996. Corrige numerosas limitaciones de la versión anterior: Saros Document Manager 1.6, disponible desde mediados de 1995. Entre estas limitaciones se encontraban:

1. la imposibilidad de trabajar con documentos compuestos;
2. la imposibilidad de interrogar simultáneamente varias bases de datos (Saros emplea el término "bibliotecas" en lugar de bases de datos);
3. la imposibilidad de añadir nuevas propiedades para la descripción de documentos;

La versión 4.0 aportó las siguientes funcionalidades:

1. interface http, mediante el cual se puede acceder a las "bibliotecas" gestionadas por el servidor a través de un cliente web;
2. módulo de replicaciones;
3. publicación de documentos en formato PDF (portable document format) de Adobe.

En España, FileNet no dispone de un distribuidor directo. Aunque este factor ha podido limitar su expansión en nuestro país, Saros cuenta con un cliente emblemático: la empresa de telefonía móvil Airtel.

Arquitectura del sistema

Todas las versiones de Saros se han basado en la arquitectura cliente/servidor. El software servidor, llamado Mezzanine, está compuesto por tres módulos: el gestor de propiedades (Property manager), el gestor de contenido (Content manager) y el gestor de almacenamiento (Storage manager). En ocasiones, la documentación de Saros utiliza la designación "subsistema de catálogo" (Catalogue subsystem) para hacer referencia a los dos primeros módulos.

El servidor funciona con sistemas operativos MS-Windows NT, OS/2, Netware y con las principales plataformas Unix: AIX, Solaris, HP-UX, etc.

El software cliente, Saros Document Manager, funciona con los sistemas operativos Windows 3.1, MS-DOS, Windows95, NT, OS/2, en ordenadores Macintosh y en terminales Unix con interface Motif.

Subsistema de catálogo

El subsistema de catálogo está formado por el gestor de propiedades y el gestor de contenido.

El primero de ellos (Property Manager) consiste en una base de datos relacional que se encarga de gestionar los datos identificativos y descriptivos de los documentos incluidos en las bibliotecas gestionadas por Mezzanine.

Como veremos en el siguiente apartado, un documento cuenta con una serie de propiedades: identificador, título, autor, permisos, pertenencia a una o varias carpetas, palabras clave, etc., que son gestionadas por un sistema relacional. De hecho, el gestor de propiedades se implementará sobre los sgbds (sistemas gestores de bases de datos) Sybase, Microsoft SQL-Server u Oracle.

El gestor de propiedades no sólo registra y gestiona información sobre los documentos, sino sobre todos los objetos que intervienen en el sistema: usuarios, permisos, vistas, carpetas, etc. El servidor Mezzanine sólo puede trabajar con un único gestor de propiedades.

El gestor de contenido se encarga de la indización y recuperación en texto completo. Mezzanine trabaja con el motor de indización/recuperación Fulcrum. La indización no es un requerimiento obligatorio en una biblioteca Saros. Es decir, el administrador y el operador del sistema podrán elegir entre indizar o no un nuevo documento o una nueva versión de un documento existente.

Cada gestor de contenido puede indexar hasta 16 millones de documentos. Además, se dispone de la posibilidad de eliminar del índice las entradas correspondientes a los documentos que se borran. Mezzanine puede trabajar con un máximo de tres gestores de contenido.

Gestor de almacenamiento

Se encarga de facilitar la localización de los documentos en las distintas unidades de almacenamiento físico que estén siendo utilizadas. Mezzanine puede trabajar con un número ilimitado de gestores de almacenamiento, aunque existe una posible limitación: el gestor de contenidos debe estar instalado en el mismo servidor que el gestor de almacenamiento. Un gestor de almacenamiento puede trabajar con un máximo de 999 dispositivos de almacenamiento, que pueden estar distribuidos en cualquier lugar de la red.

En la gestión del almacenamiento, podemos elegir dos posibilidades: asignar un gestor de almacenamiento a cada usuario, o asignar un gestor de almacenamiento a cada tipo de archivo que se grabe en las bases de datos.

En el primer caso, cada usuario de Mezzanine tendrá asignado un gestor de almacenamiento por defecto, que se encargará de gestionar sus peticiones de grabación en las bases de datos. Si por una u otra causa el gestor de almacenamiento no estuviese disponible, Mezzanine dirigiría la solicitud a un segundo gestor de almacenamiento, optimizando así los tiempos de respuesta del sistema. Evidentemente, un gestor de almacenamiento podrá ser compartido por varios usuarios.

En el segundo caso, todos los documentos incluidos en una librería tendrán una propiedad, Storage category, por la que se indicará en qué servidor de la red corporativa va a grabarse el documento y todas sus versiones. Conviene señalar que, para Mezzanine, un documento es cualquier tipo de información, en soporte digital o no, independientemente de cuál sea su formato, por lo que, al hablar de diferentes tipos de documentos, en realidad se está hablando de distintos formatos de ficheros identificables a partir de su extensión:.doc,.wp6, .gif,.tif,.pdf, etc.

Módulos complementarios: ARROBA mezzanine y Rendition

El servidor puede incluir dos módulos complementarios:

ARROBA mezzanine y Rendition.

ARROBA mezzanine permite consultar las bases de datos desde un cliente http. Se ha diseñado a partir de seis scripts CGI; cada uno de ellos se encarga de gestionar:

1. la conexión y autentificación del usuario ante Mezzanine;
2. el cierre de las sesiones de trabajo;
3. el envío de la ecuación de búsqueda desde el cliente http, y su recepción en Mezzanine;
4. el envío de los resultados obtenidos al ejecutar la ecuación de búsqueda en formato html;
5. ejecución de macros de búsqueda guardadas en el servidor Mezzanine;
6. validación de búsquedas basadas en propiedades y en texto completo.

Las sesiones de trabajo entre el cliente web y Mezzanine se gestionan mediante cookies (v. IWE vol.6, n. 3, p. 28).

Es posible parametrizar los formularios html distribuidos por Saros.

Aunque inicialmente ARROBA mezzanine necesitaba el servidor http de Netscape, ya está preparado para funcionar con internet Information Server de Microsoft (recientemente Saros obtuvo la certificación BackOffice que acredita su funcionalidad con la "gama alta" de productos Microsoft: Windows NT, Exchange-Server, IIS, SQL-Server, etc.).

Rendition es un módulo que facilita la conversión de documentos MS-Word al formato .pdf. En otros números de IWE ya se han señalado las grandes ventajas de este formato para la distribución de documentos electrónicos. Con Rendition, Saros ofrece la posibilidad de publicar documentos de trabajo en formato .pdf, una vez se haya decidido cuál va a ser su contenido y formato definitivo.

Módulo de administración FileShare: gestión de réplicas y backup

FileShare es el módulo de administración de Mezzanine. Basado en línea de comandos, resulta un sistema poco "amigable" para el usuario, lo que constituye uno de los "puntos negros" de la aplicación.

Como contrapartida, Mezzanine permite una fácil integración, no sólo con el resto de módulos ofertados por FileNet para imaging o flujo de tareas, sino con cualquier otra aplicación mediante un API.

La versión 4.0 incluye un Replication Manager encargado de gestionar la replicación de librerías en un entorno distribuido. De esta forma, es posible copiar bibliotecas completas, o conjuntos de documentos pertenecientes a una misma biblioteca, a otros dispositivos de almacenamiento de la red corporativa gestionados por otros servidores Mezzanine.

La replicación se basa en la metodología maestro-esclavo, es decir, la biblioteca cuyo contenido se replique disfrutará de prioridad sobre la biblioteca destino de la réplica, y podrá sobreescribir los documentos con un mismo identificador. Es posible replicar el contenido de una biblioteca a varias bibliotecas simultáneamente.

Las réplicas pueden hacerse en cualquier momento, a petición del administrador, o ser programadas para que se ejecuten cada cierto número de días.

Otro aspecto que se destaca ya en las versiones anteriores de Mezzanine es la capacidad de crear copias de seguridad o backup. Las copias pueden hacerse mientras el sistema se encuentra funcionando, con destino a disco o a cinta.

Características funcionales

Para estudiar las características funcionales de Saros atenderemos a los siguientes criterios:

1. estructuración de los documentos;
2. sistemas utilizados para su organización;
3. capacidad de recuperación;
4. control de versiones y workflow;
5. seguridad y control de acceso;
6. publicación y difusión de los documentos registrados en la base de datos;
7. edición y posibilidades de importación;
8. integración con otras aplicaciones.

Estructura de los documentos: propiedades

Un documento de una biblioteca Mezzanine puede consistir en un archivo digital, cualquiera que sea su formato, o una referencia a un documento del que no existen copias en formato digital. Es decir, una librería puede incluir referencias a documentos en soporte papel cinta magnética, fotografías, etc.

Una misma librería Mezzanine soporta documentos en distinto formato: .doc, .wp6, .pdf, .avi, .gif, .tif, etc., y documentos compuestos: es decir, documentos integrados por otros documentos, por ejemplo, un documento creado con MS-Word que incluye referencias OLE a archivos de imágenes, o una página html con referencias a archivos .avi o .wav.

No sólo es posible almacenar estos documentos, sino que disponemos de una completa metodología para el control de versiones, que nos permite responder a necesidades del tipo:

1. Quiero cambiar la versión de un documento compuesto, siempre que cambie uno de sus componentes.
2. Sólo quiero grabar una nueva versión de un documento, en el caso de que cambien todos sus componentes.
3. Quiero cambiar la versión de un documento cuando cambie, al menos, un número determinado de sus componentes.

Esta política de gestión de versiones puede establecerse a nivel de documento, es decir, distintos documentos en una misma biblioteca pueden estar asociados a metodologías de control de versiones diferentes.

Un documento contará con una serie de propiedades. Mezzanine incluye unas treinta de ellas predefinidas. Aunque el número resulta suficientemente amplio para responder a las principales necesidades de la gestión documental, con la versión 4.0 el administrador puede añadir nuevas propiedades a los documentos, siendo posible trabajar con algunas multivaluadas. Lo que sigue sin ser posible es eliminar propiedades o cambiar el tipo de dato que tienen asociado.

Entre las incluidas por defecto encontramos: el identificador único del documento, palabras clave, quién y cuándo ha creado o modificado un documento, número de versión, archivo al que está asociado, etc.

Se hecha en falta una que indique el formato del documento (por ejemplo, si se trata de una imagen, un documento creado con un procesador de textos determinado o una hoja de cálculo), sin que exista ninguna forma de distinguir, en una relación de documentos contenidos en una carpeta o recuperados por una ecuación de búsqueda, qué formato corresponde a cada uno de ellos.

Otra limitación muy importante de Mezzanine es que todas las propiedades se aplican a todos los objetos del sistema. Es decir, no podemos definir tipologías documentales caracterizadas por una serie de propiedades particulares. Por ejemplo, si quisiéramos incorporar en nuestra base de datos patentes digitalizadas, tendríamos que incluir nuevas propiedades: oficina en la que se cursó la solicitud, número de la solicitud, etc., que a partir de ese momento serían aplicables al resto de documentos de todas las bibliotecas (incluidos aquellos que no sean patentes).

Esto no sólo supone un problema en la optimización del espacio requerido para almacenar las propiedades, sino que impone serias restricciones a la hora de llevar a cabo una gestión documental ordenada y coherente. Mezzanine enmascara este problema a través de un objeto que describiremos en el siguiente apartado: las vistas.

Ricardo Eíto Brun

ricardoe ARROBA meta4.es

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1997/octubre/mezzanine_y_saros_document_manager_arquitectura_descripcion_y_recuperacion_de_documentos_parte_i.html