Gestion Electronique de Documents : Autres aspects (4/4)

Dans le cadre d’une veille stratégiques pour un de nos clients publics, nous avons étudié les solutions de gestion électronique de documents. L’article suivant constitue la 4ème partie sur les composants Recherche, Persistence, Workflow et les aspects Sécurité et Performances associés à la gestion électronique de documents.

1. Couche Recherche

Elasticsearch et Solr sont les deux technologies de moteur de recherche utilisées. Toutes les deux sont basées sur la librairie open source Java d’Apache, Lucene. Les deux solutions partagent donc beaucoup de fonctionnalités communes.

1.1. Solr (Lucene)

Licence : Apache v2

Date de création : 2006

Site officiel : http://lucene.apache.org/solr/

Solr est un projet de R&D d’un serveur de recherche confié à la fondation Apache par CNET Networks en 2006. En 2011, Apache fusionne Solr avec Lucene, librairie de recherche utilisée dans Solr. Aujourd’hui le développement de Solr et Lucene est commun mais les distributions sont séparées.

Solr est une solution mature de recherche de texte qui dispose d’une communauté active de développeurs et d’une base de déploiement large. Les fonctionnalités sont riches et de nombreuses extensions sont disponibles.

1.2. ElasticSearch

Licence : Apache v2

Date de création : 2010

Site officiel : https://www.elastic.co/products/elasticsearch

Elasticsearch est un serveur de recherche basé sur la librairie Lucene, créé par Shay Banon en 2010, avec la volonté d’être une solution de recherche scalable. Il fournit un moteur de recherche full-text, multi-tenant, distribué avec une interface web RESTful. Elasticsearch est proposé en version open source avec des services de support payants en complément.

ElasticSearch est une solution basée sur une architecture moderne déjà très populaire. Elle se focalise plus largement sur l’extraction de données et pas uniquement sur la recherche. ElasticSearch fait partie du stack ELK (ElasticSearch, Logstash, Kibana) en tant que solution d’analyse BigData. En particulier, ElasticSearch est très orienté documents et utilise le format JSON pour les documents, qui est le format standard utilisé par le mouvement NoSQL.

1.3. Comparaison fonctionnelle

Le tableau ci-dessous compare les fonctionnalités des deux serveurs de recherche open source utilisés dans les solutions de GED :

Apache Solr

Elasticsearch

Licence

Apache v2

Apache v2

Modèle économique

Aucun

Support professionnel payant

Activité communautaire

Élevé

Élevé

API

XML / JSON (HTTP)

JSON (REST)

Recherche à facettes

Oui

Oui

Surlignage

Oui

Oui

Réplication vers d’autres serveurs

Oui

Oui

Recherche full text Lucene

Oui

Oui

Recherche quasi en temps réel

Oui

Oui

Recherche distribuée

Oui

Oui

Clustering

Oui

Oui

Adapté à un déploiement à grande échelle

Limité

Oui

Prise en charge des documents

Limité

Oui

1.4. Synthèse sur la couche recherche

Solr et ElasticSearch sont relativement proches d’un point de vue fonctionnel. Il existe fondamentalement peu de différences entre les deux. Cependant ElasticSearch est plus récent et a été conçu dès le départ pour répondre aux problématiques de Big Data à savoir : distribution, réplication, grand volume et temps réel.

2. Couche Persistence

La gestion de la persistance des données est un enjeu important en particulier dans le domaine de l’archivage électronique de documents. Le choix du système de gestion de base de données est déterminant. Nous allons ci-dessous faire la comparaison des différents types de base de données vis-à-vis de l’archivage électronique de documents.É. Notons qu’il s’agit uniquement de stocker les métadonnées dans les bases de données.

2.1. MySQL

Licence : GPL

Date : 1995

Site officiel : http://www.mysql.com/

MySQL est la base de données relationnelle open source la plus utilisée. Elle est particulièrement populaire pour une utilisation dans les applications web et est un composant principal dans les stacks logiciels d’application web de type LAMP (Linux, Apache, MySQL, Perl/PHP/Python).

Les données dans MySQL sont structurées dans des tableaux ce qui entraîne un certain nombre de limitations fonctionnelles et de performance en particulier pour la recherche full-text.

2.2. PostGreSQL

Licence : PostGreSQL

Date : 1989

Site officiel : http://postgresql.org/

PostGreSQL est une base de données relationnelle orientée objet qui se focalise sur l’extensibilité et la conformité aux normes SQL. C’est une base de données adaptée à un large public : d’une petite application pour une machine à des applications Web avec des utilisateurs concurrents. Les dernières versions de PostGreSQL intègrent la réplication de la base de données pour être scalable et disponible.

Le support de JSON permet aujourd’hui à PostGreSQL de concurrencer les bases de données NoSQL comme MongoDB. PostGreSQL est aujourd’hui une base de données performante et recommandée par Nuxeo.9

2.3. MongoDB

Licence : AGPL

Date : 2009

Site officiel : http://www.mongodb.org/

MongoDB est un système de gestion de base de données orientée documents scalable et ne nécessitant pas de schéma prédéfini de données. Ainsi contrairement à une base de données relationnelle, MongoDB regroupe l’ensemble des données d’un objet (titre, nom d’auteur, illustration…) dans une entrée unique (unique). Ce format plus flexible est particulièrement adapté pour l’archivage électronique de documents.

Les fonctionnalités proposées sont entre autres le support full index, les requêtes riches, la haute disponibilité et la réplication. MongoDB apporte ainsi une nouvelle dimension à la scalabilité. Elle se prête en particulier aux applications qui nécessitent la manipulation de quantité d’informations très importante et des écritures parallèles massives. La base MongoDB est la seule à proposer via le format BSON et GridFS de stocker les fichiers directement dans la base de données10.

2.4. CouchDB

Licence : Apache v2

Date : 2005

Site officiel : http://couchdb.apache.org/

CouchDB est une base de données orientée NoSQL qui utilise JSON pour stocker les données, Javascript comme langage de requête utilisant MapReduce, et HTTP comme API. Le projet est aujourd’hui géré par la fondation Apache.

Les capacités de réplication et de synchronisation rendent cette solution idéale pour des usages mobiles. CouchDB est également idéal pour les applications qui accumulent et changent occasionnellement les données, sur lesquels un certain nombre de requêtes prédéfinies sont lancées et où le versioning est important.

2.5. Comparaison fonctionnelle

Le tableau ci-dessous compare les fonctionnalités des bases de données open source utilisées dans les solutions de GED :

MySQL

PostGreSQL

MongoDB

CouchDB

Type de base de données

Relationnel

Relationnel orienté objet

Documents

Documents

Popularité

Élevé

Élevé

Élevé

Moyen

Accès concurrent

Oui

Oui

Oui

Oui

Schéma de données

Oui

Oui

Non

Non

Réplication

Limité

Oui

Oui

Oui

Performance

Moyen

Élevé

Élevé

Élevé

Disponibilité (1)

Élevé

Élevé

Moyen

Élevé

Consistance (1)

Élevé

Élevé

Élevé

Moyen

Tolérance partition (1)

Moyen

Moyen

Élevé

Élevé

(1) La disponibilité signifie que tous les clients peuvent lire et écrire tout le temps. La consistance signifie que chaque client a toujours la même version des données. La tolérance partition signifie que le système fonctionne correctement malgré les différentes partitions physiques de réseau. Source : http://blog.scottlogic.com/2014/08/04/mongodb-vs-couchdb.html

2.6. Synthèse sur la couche Persistance

Les solutions de GED qui utilisent traditionnellement des bases de données type SQL sont aujourd’hui en train de migrer vers celles orientées objets et NoSQL. En fonction des priorités de l’Administration, les bases de données PostGreSQL, MongoDB ou CouchDB peuvent être recommandées pour stocker les métadonnées des documents dans le cadre de la gestion électronique de documents.

3. Couche Workflow

3.1. JBPM

Licence : Apache v2

Date : 2006

Site officiel : http://www.jbpm.org/

JBPM est la référence open source en termes de moteur de workflow. Il permet la gestion de flux d’informations et la coordination entre les biens et les personnes. JBPM est écrit en Java et peut exécuter les procédures métiers décrites par le standard BPMN 2.0. il est proposé par quasiment toutes les solutions de gestion électroniques de documents. JBPM est édité par la société Red Hat.

3.2. Activiti BPMN

Licence : Apache v2

Date : 2010

Site officiel : http://www.activiti.org/

Activiti BPMN est un autre moteur de workflow écrit en Java qui peut également exécuter des procédures métiers décrites par le standard BPMN 2.0. Cette solution d’Alfresco est développée en 2010 par deux anciens de Red Hat qui travaillaient sur JBPM et qui sont devenus employés d’Alfresco.

3.3. Comparaison fonctionnelle

Le tableau ci-dessous compare les fonctionnalités des deux moteurs de workflow open source :

JBPM

Activiti

Licence

Apache v2

Apache v2

Modèle économique

Aucun

Service professionnel payant

Activité communautaire

Élevé

Élevé

Support BPMN 2.0

Oui

Oui

Moteur de règles intégré

Oui

Non

Intégration avec Drools

Oui

Limité

Support Spring

Non

Oui

3.4. Synthèse sur la Couche Workflow

JBPM est le moteur de workflow historique disposant d’une richesse fonctionnelle sans équivalent. Le support de Spring reste cependant la spécialité de Activiti.

4. Sécurité et contrôle d’accès

Les dépôts de contenu contiennent généralement des données confidentielles. C’est le rôle du dépôt d’assurer la protection des données, le CMIS n’étant qu’un moyen de transport de l’information. Les aspects de sécurité et de contrôle importants à traiter sont :

  • L’authentification des utilisateurs qui n’est pas définie par le CMIS. Le développement d’un serveur d’authentification est nécessaire.

  • L’autorisation qui est définie dans le CMIS par les règles et les listes de contrôle d’accès.

  • Les rétentions et les verrouillages qui sont une nouveauté de la norme CMIS 1.1. Ils permettent de s’assurer que les documents archivés ne sont pas modifiés jusqu’à une date donnée.

Plus d’informations sont disponibles dans le chapitre 12 du livre CMIS and Apache Chemistry in Action.

5. Performances

De nombreux éléments peuvent affecter la performance d’une application CMIS. Même si la performance du dépôt de contenu joue un rôle primordial dans la performance, d’autres facteurs peuvent avoir un impact comme l’infrastructure du réseau et le design de l’application.

En particulier, il est recommandé de :

  • sélectionner le groupement de données le plus petit possible en utilisant par exemple des filtres ou la requête OperationContext dans OpenCMIS

  • utiliser les caches de sessions intégrées dans OpenCMIS

  • privilégier la liaison Browser quand c’est possible sinon la liaison AtomPub pour que les transferts soient plus rapides

Plus d’informations sont disponibles dans le chapitre 13 du livre CMIS and Apache Chemistry in Action.