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.
