REPUBLIQUE DU SENEGAL UNIVERSITE CHEIKH ANTA DIOP …Chapitre 1: Présentation générale ... JSON...

Année universitaire : 2013 – 2014

REPUBLIQUE DU SENEGAL ***** * * ********

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

SUJET : Intégration de la spécification OASIS

CMIS dans PexOne Exchange Platform

MEMOIRE DE FIN DE CYCLE

Pour l’obtention du :

DIPLOME D’INGENIEUR DE CONCEPTION (DIC)

Lieu de stage : Angokh Systems Période stage : 03/2014 – 07/2014

Présenté et soutenu par Professeurs encadreurs Maitres de stage

Ibrahima Diop M. Ibrahima Ngom M. Aly Wane Diène

ECOLE SUPERIEURE POLYTECHNIQUE DEPARTEMENT GENIE INFORMATIQUE

Centre de Dakar

Intégration de la spécification OASIS CMIS dans PexOne Exchange Platform. 1

Je dédie ce mémoire :

À ma chère mère et complice qui a toujours été présente. Maman, je

t’adore.

À mon défunt père Mapenda Diop. Que dieu l’accueille dans son paradis.

À ma grande sœur et amie Fatou Diop pour avoir toujours cru en moi,

Binetou, je t’estime beaucoup.

À mes frères: Issa, Libasse, Omar, Birane, Mansour, Ndiaga.

À mes sœurs : Ndeye, Anta, Adja, Soda, Khady.

À toute ma famille : mes tantes, mes oncles, mes cousins et cousines.

À mes amis Maguette, Issa, Malick, Ndiaga, Epsilon et toute la famille

Mboup.

À tous les étudiants de ma promotion.

DEDICACES


Avant tout, je rends grâce à Dieu le Tout puissant et Miséricordieux.

J’adresse mes remerciements les plus chaleureux à:

M. IBRAHIMA NGOM, pour son encadrement, ses conseils et sa

disponibilité,

M. MENDY, Chef du Département Génie Informatique,

M. ALY WANE DIENE, mon maître de stage,

M. IBRAHIMA FALL, responsable DIC informatique,

Tous mes professeurs,

Tout le reste du personnel enseignant et administratif du Département

Génie Informatique,

Tous mes collègues d’Angokh Systems,

Toutes les personnes qui, de près ou de loin, ont contribué à la réalisation de

ce document.

REMERCIEMENTS


L’Ecole Supérieure Polytechnique est une partie intégrante de

l’université Cheikh Anta Diop. Elle a pour vocation de former des

techniciens supérieurs et des ingénieurs dans ses six (6) départements :

Génie Informatique, Génie Electrique, Génie Mécanique, Génie Civil,

Génie Chimie et Gestion.

Pour l’obtention du DIC (Diplôme d’Ingénieur de Conception), les

étudiants du Département Génie Informatique sont tenus d’effectuer un

stage dans une structure afin de mettre en œuvre les connaissances

acquises durant leurs formations. Ce stage leur permettra de découvrir la

vie professionnelle. C’est dans cette optique que nous avons effectué un

stage à l’entreprise Angokh Systems.

AVANT-PROPOS


Ce document est un mémoire de fin de cycle en vue de l’obtention du Diplôme

d’Ingénieur de Conception en Informatique. Il présente la conception et la réalisation

d’un projet effectué dans le cadre d’un stage à la société Angokh Systems, qui est une

entreprise de technologie et de conseil en management des systèmes d’informations.

Ce projet consiste à faire l’intégration de la norme CMIS dans la plateforme

(PexOne Exchange Platform). L’objectif de cette plateforme est d’apporter des

solutions permettant aux entreprises et organisations de dématérialiser et d’automatiser

l’ensemble de leurs processus d’échange à travers une plateforme unifiée. Notre

objectif est donc de mettre en place un référentiel CMIS permettant la gestion de

documents issus de PexOne.

Pour ce faire, nous avons d’abord maîtrisé les spécifications de CMIS, ensuite

fait la conception et la réalisation du référentiel CMIS. Et enfin, nous avons fait un

module client pour permettre à PexOne d’accéder au niveau du référentiel CMIS via

les web services.

**************************************************************

This document is an ending cycle memory in purpose for getting the Diploma of

Engineer in informatic Design. It presents the design and implementation of a project in the

framework of an internship at the company Angokh Systems, which is a business technology

and management consulting information systems.

This project involves doing the integration of CMIS standard in platform (PexOne

Exchange Platform). The aim of this platform is to provide solutions that enable businesses

and organizations to computerize and automate all processes of exchange through a unified

platform. Our goal is to implement a CMIS repository which allowed managing documents

from PexOne.

To do this, we first mastered the CMIS specification, then made the design and

implementation of the CMIS repository. And finally, we have a client module to allow

PexOne to access at the CMIS repository via web services.

RESUME / ABSTRACT


Sigles et Abréviations ............................................................................................................... 7

Table des figures ....................................................................................................................... 9

Introduction ............................................................................................................................ 10

Chapitre 1 : Présentation générale ......................................................................................... 12

I. Présentation de la structure d’accueil ........................................................................... 12

1. Présentation d’Angokh Systems................................................................................ 12 2. Domaines d’activités ................................................................................................. 12

II. Présentation du sujet ..................................................................................................... 13 1. Problématique ............................................................................................................ 13

2. Objectifs attendus ...................................................................................................... 14 III. Etude de l’existant .................................................................................................... 15

1. Présentation de PexOne ............................................................................................. 15

2. Architecture utilisée .................................................................................................. 16

3. Evolutions souhaitées ................................................................................................ 17

Chapitre 2 : CMIS : Etat de l’art ........................................................................................... 18

I. Historique ..................................................................................................................... 18

II. Définitions et concepts ................................................................................................. 18 1. Définitions ................................................................................................................. 18

1.1 CMIS ........................................................................................................................ 18 1.2 Modèle de domaine .................................................................................................. 19 2. Enjeux de CMIS ........................................................................................................ 19

III. Spécification CMIS ................................................................................................. 20 1. Le modèle de domaine .............................................................................................. 20

2. CMIS services ........................................................................................................... 23 3. CMIS liaisons ............................................................................................................ 25

3.1 Liaison AtomPub ........................................................................................................ 25 3.2 Liaison Web service ................................................................................................... 26

3.3 Liaison Browser ......................................................................................................... 26 4. Sécurité CMIS ........................................................................................................... 26 4.1 Authentification .......................................................................................................... 26

4.2 Contrôle ...................................................................................................................... 27 IV. Avantages et limites de CMIS .................................................................................. 27

1. Avantages de CMIS .................................................................................................. 27 2. Limites de CMIS ....................................................................................................... 27

V. Etude comparative des solutions proposées ................................................................. 28

Chapitre 3 : Méthode d’analyse et de conception ................................................................. 32

I. Définitions des concepts ............................................................................................... 32 1. Analyse ...................................................................................................................... 32 2. Conception ................................................................................................................ 32

II. Pourquoi utiliser une méthode ...................................................................................... 32

III. Classification des méthodes d’analyse et de conception .......................................... 32 1. Rappel sur la classification des méthodes d’analyse et de conception ..................... 32 1.1 Les méthodes cartésiennes ....................................................................................... 33

1.2 Les méthodes systématiques .................................................................................... 33 1.3 Les méthodes orientées objet ................................................................................... 33

Table des matières


1.4 Les méthodes orientées aspect ................................................................................. 33

2. Etude comparative des méthodes d’analyse et de conception ................................... 33 3. Choix de la méthode d’analyse et de conception ...................................................... 35

Chapitre 4 : Etude détaillée ..................................................................................................... 40

I. Spécifications fonctionnelles ........................................................................................ 40 1. Identification des acteurs et leurs rôles ..................................................................... 40

2. Les fonctionnalités du système ................................................................................. 41 II. Analyse de la solution .................................................................................................. 41

1. Gestion des utilisateurs .............................................................................................. 41 2. Gestion des dossiers .................................................................................................. 46 3. Gestion des documents .............................................................................................. 50

III. Conception de la solution ......................................................................................... 56 1. Diagramme de paquetage .......................................................................................... 56 2. Diagramme de classe de conception de PexOne CMIS Repository .......................... 58 3. Diagramme de classe de conception de PexOne CMIS Client ................................. 60

IV. Architecture de la solution ....................................................................................... 61

Chapitre 5 : Mise en œuvre ..................................................................................................... 64

I. Choix technologiques ................................................................................................... 64 1. Le langage Java ......................................................................................................... 64

2. XML .......................................................................................................................... 64 3. Les Web services ....................................................................................................... 65 4. Le Framework SPRING ............................................................................................ 65

5. Base de données ........................................................................................................ 66 II. Architecture technique ................................................................................................. 66

1. Architecture applicative ............................................................................................ 66 2. Diagramme de déploiement ...................................................................................... 67 3. Politique de sécurité .................................................................................................. 68

III. Réalisation ................................................................................................................ 69 1. Présentation des outils utilisés................................................................................... 69

2. Développement .......................................................................................................... 69 IV. Présentation de la solution ........................................................................................ 81

Conclusion ............................................................................................................................... 88

Bibliographie / « Wébographie » ......................................................................................... 93

Annexes .................................................................................................................................. 94


Nous présentons ici, certains sigles et abréviations que nous utiliserons dans le document.

API Application Programming Interface

B-to-B Business to Business

B-to-C Business to Consumer

CMIS Content Management Interoperability System

CMS Content Management System

CRUD Create – Read – Update – Delete

DSI Direction des Systèmes d’information

EJB Entreprise JavaBeans

ECM Entreprise Content Management

HTML Hypertext Markup Language

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

IBM International Business Machines

IDE Integrated Development Environment

JDK Java Development Kit

JVM Java Virtual Machine

JSON JavaScript Object Notation

LDAP Lightweight Directory Access Protocol

OASIS Organization Advancement Structured Information Standards

REST Representational State Transfer

SGBD Système de Gestion de Base de Données

Sigles et abréviations


SOAP Lightweight Directory Access Protocol

SADT Structured Analysis and Design Technique

UP Unified Processus

UML Unified Modeling Language

WSDL Web Services Description Language

XP eXtreme Programming


Figure 1 : Architecture de l’existant ...................................................................................................................... 16 Figure 2 : I ’enjeu de CMIS .................................................................................................................................. 20 Figure 3 : les différents types d’objet dans un référentiel CMIS ........................................................................... 23 Figure 4 : Tableau comparatif des capacités des quelques serveurs CMIS – source Webo [4]............................. 29 Figure 5 : Etude comparative des solutions fournies en matière de serveur CMIS – source Webo [4] ................ 31 Figure 6 : Etude comparative de différentes méthodes d’analyse et de conception – source Webo [5] ................ 34 Figure 7 : Tableau d’identification des acteurs et leurs rôles ................................................................................ 41 Figure 8 : Diagramme de cas d’utilisation d’authentification au niveau du serveur CMIS .................................. 42 Figure 9 : Diagramme de séquence d’authentification au niveau du serveur CMIS ............................................ 45 Figure 10 : Diagramme de séquence inscrire User au niveau du serveur CMIS ................................................... 46 Figure 11 : Diagramme de cas d’utilisation pour la gestion des dossiers .............................................................. 47 Figure 12 : Diagramme de séquence créer dossier ................................................................................................ 49 Figure 13 : Diagramme de séquence supprimer dossier ........................................................................................ 50 Figure 14 : Diagramme de cas d’utilisation pour la gestion des documents ......................................................... 51 Figure 15 : Diagramme de séquence créer document ........................................................................................... 54 Figure 16 : Diagramme de séquence supprimer document ................................................................................... 55 Figure 17 : Diagramme de séquence rechercher document ................................................................................... 56 Figure 18 : Diagramme de paquetage de conception du référentiel CMIS ........................................................... 57 Figure 19 : Diagramme de classe de conception du référentiel CMIS .................................................................. 59 Figure 20 : Tableau descriptif des services de la classe PexOneCmisService ...................................................... 60 Figure 21 : Diagramme de classe de conception de PexOne CMIS Client .......................................................... 61 Figure 22 : Architecture de la solution .................................................................................................................. 62 Figure 23 : Architecture applicative ...................................................................................................................... 66 Figure 24 : Diagramme de déploiement ................................................................................................................ 68 Figure 25 : Génération de notre serveur CMIS ..................................................................................................... 71 Figure 26 : Importation de notre projet sous éclipse ............................................................................................. 72 Figure 27 : Importation de notre projet sous éclipse (suite) .................................................................................. 72 Figure 28 : Arborescence du projet ....................................................................................................................... 73 Figure 29 : Classe PexOneCmisService ................................................................................................................ 75 Figure 30 : Classe PexOneCmisServiceFactory .................................................................................................... 75 Figure 31 : Arborescence du projet final ............................................................................................................... 76 Figure 32 : Démarrage du serveur Tomcat ............................................................................................................ 77 Figure 33 : Test de déploiement ............................................................................................................................ 78 Figure 34 : PexOne CMIS Client .......................................................................................................................... 79 Figure 35 : Connexion par web service ................................................................................................................. 80 Figure 36 : Téléchargement de document dans le référentiel ............................................................................... 81 Figure 37 : Connexion dans le référentiel CMIS .................................................................................................. 82 Figure 38 : Présentation des caractéristiques de notre référentiel ......................................................................... 83 Figure 39 : Accès au référentiel CMIS .................................................................................................................. 84 Figure 40 : Création de nouveau dossier ............................................................................................................... 85 Figure 41 : Création de dossier dans le référentiel ................................................................................................ 86 Figure 42 : Traçabilité dans le référentiel ............................................................................................................. 86 Figure 43 : Création de document dans le référentiel............................................................................................ 87 Figure 45 : Illustration de la création de document ............................................................................................... 88

Table des figures


Dans un monde où l’internet occupe une place importante dans la gestion de

documents, la nécessité de s’approprier de cette richesse afin de faciliter l’interopérabilité

entre les différents systèmes de gestion de contenus devient plus actuelle que jamais.

Plusieurs solutions ont vu le jour. La difficulté majeure est que cette interopérabilité est

couteuse en termes de ressources et de performances. Il devient donc nécessaire de réfléchir

sur un standard qui faciliterait l’échange de documents électroniques entre les différents

systèmes de gestion de contenus. C’est dans cette optique que la norme CMIS (Content

Management Interoperability System) est née. CMIS est une interface, un standard ouvert

permettant de faire face à la gestion de documents. Elle fournit un ensemble de services

facilitant son intégration dans la plupart des plateformes existantes.

Ayant mis en place une plateforme (PexOne Exchange Platform) d’échange B-to-B et

B-to-C pour faire face à cette complexité d’échange entre partenaires, Angokh Systems a

jugé nécessaire d’intégrer la spécification de cette norme (CMIS) dans PexOne Exchange

Platform.

C’est dans ce contexte que notre structure d’accueil, Angokh Systems nous a confié le

projet « Intégration de la spécification OASIS CMIS dans PexOne Exchange Platform ».

Cette intégration permettra l’échange de documents à travers PexOne de manière standard.

Pour bien mener ce travail, nous mettrons l’accent sur la démarche utilisée pour

atteindre les objectifs qui nous ont été assignés. Pour ce faire, nous avons réparti ce travail en

cinq chapitres :

le premier chapitre fait une brève description de la structure d’accueil et de son

domaine d’activités. La présentation du sujet sera abordée dans cette

partie ainsi que la problématique et les objectifs attendus.

le deuxième chapitre sera consacré à un état de l’art. Dans cette partie, nous

ferons une étude de la spécification définie au niveau de cette norme, de

l’architecture et du méta-modèle proposé ainsi que quelques plateformes

d’implémentations.

le troisième chapitre portera sur l’aspect méthodologique c’est-à-dire comment

nous allons aborder le problème.

INTRODUCTION


le quatrième chapitre sera consacré à l’étude détaillée. Dans cette partie nous

ressortirons les spécifications fonctionnelles du système puis ferons l’analyse

et la conception de la solution.

le cinquième chapitre sera consacré à la mise en œuvre. L’attention ici, portera

sur l’architecture technique, les choix et une présentation de ce qui y’a été

réalisé durant ce stage.

Ainsi, nous terminerons par la conclusion et les perspectives du travail effectué.


Présentation générale

I. Présentation de la structure d’accueil

1. Présentation d’Angokh Systems

Angokh Systems est une société de technologie et de conseil en management des

systèmes d’informations. Elle se positionne auprès des DSI (Direction des Systèmes

d’information) pour les accompagner dans leurs enjeux de pilotage, de performance et

d’optimisation de leurs fonctions.

Grâce à des approches éprouvées, Angokh Systems propose une offre de solutions et

de services spécialisés à très forte valeur ajoutée et s’engage aux côtés des Directions

Informatiques dans une démarche d’optimisation et d’industrialisation des applications et des

processus métier.

En tant qu’éditeur international de solutions logicielles de dématérialisation et

spécialiste des architectures distribuées, Angokh Systems permet à ses clients de bénéficier du

meilleur de la technologie open source pour développer leurs activités.

En plus de son métier d’éditeur, Angokh Systems propose des prestations de services

pour accompagner les entreprises dans le déploiement, l’intégration et la gestion de leurs

projets.

2. Domaines d’activités

Angokh Systems intervient dans trois secteurs d’activités que sont les suivants :

Conseil et expertise :

Pour apporter une réponse aux besoins des Systèmes d’information, Angokh

Systems propose un ensemble de services dans les domaines liés au conseil et à

l’expertise technique, à la mise en œuvre de projet, à la définition et

l’administration des architectures techniques et applicatives au transfert de

compétences et à la formation. Angokh Systems intervient du point de vue

organisationnel, méthodique et technique depuis la phase du conseil jusqu’à la

mise en œuvre.

CHAPITRE 1

Mémoire de fin de cycle Ibrahima Diop

Intégration de la spécification OASIS CMIS dans PexOne Exchange Platform.

13

Intégration

Angokh Systems prend la responsabilité complète des projets d’intégration grâce

à sa méthodologie spécifique d’intégration.

Elle vous accompagne tout au long de votre projet, de la définition de vos besoins

à la mise en place opérationnelle des solutions :

mise en place de la méthodologie, coordination de l'équipe projet,

comité de pilotage, validation, recette, engagements de délais et de

résultats.

identification et spécification des besoins, règles de gestion, processus et

mode de fonctionnement pour l’intégration naturelle des solutions dans

l’entreprise.

accompagnement tout au long des projets, de la définition des besoins à

la mise en place opérationnelle des solutions.

PexOne support

Angokh Systems propose son savoir-faire en matière de développement des

compétences informatiques par la mise en place de modules de formation.

Angokh Systems propose des cours de haut niveau et répondant au mieux aux

attentes d’une variété de clients. Les cours s'appuient sur des cas concrets

identifiés sur des projets de développement et d’ingénierie, et sont enseignés avec

un souci de synthèse et de progression pédagogique.

II. Présentation du sujet

1. Problématique

Nous avons constaté durant ses dernières décennies une massification des échanges

de documents (non électroniques) entre les entreprises et organisations. Pour apporter des

solutions à ces dernières, Angokh Systems a mis en place une plateforme (PexOne Exchange

Plateforme) pour permettre aux entreprises et organisations de dématérialiser et d’automatiser

l’ensemble de leur processus d’échange à travers une plateforme unifiée.

Mais la difficulté majeure de cette plateforme réside dans le fait que les documents sont

stockés au niveau du disque et indexés dans une base de données. Ce qui oblige à PexOne

d’utiliser deux moyens de stockages ; ceci venant s’ajouter du fait que les documents stockés

dans le disque ne respectent aucune norme standard.



14

Cependant, les entreprises partenaires et organisations veulent un accès au niveau du

disque à travers leurs applications de manière standard. Elles veulent également, en plus des

échanges avoir la possibilité de faire certaines opérations dans le disque telles que : la

recherche de documents, la création de documents, la définition de règles d’administration

sur les documents et les mécanismes permettant d’avoir la traçabilité des échanges.

Conscient de cette situation, Angokh Systems a donc jugé nécessaire d’intégrer au

niveau de PexOne une des nouvelles technologies apportées dans la gestion de documents : la

norme CMIS. L’objectif recherché est de pouvoir déposer ces documents dans un référentiel

CMIS pour être en conformité avec la normalisation et pour permettre aux applications de

l’organisation ou de l’entreprise d’y accéder de manière standard.

Cette intégration permettrait-il de prendre en charge l’ensemble des besoins de

PexOne, d’apporter à notre plateforme les services dont elle a besoin pour satisfaire les

entreprises et les organisations ?

2. Objectifs attendus

L’objectif principal de ce projet est de mettre en place un référentiel CMIS permettant

la gestion de documents issus de PexOne. Ce référentiel nous permettra d’être en conformité

avec la normalisation, mais aussi de permettre aux applications de l’entreprise ou de

l’organisation d’y accéder à travers une interface standard.

Pour ce faire, nous devons :

étudier d’abord cette norme, maîtriser ses spécifications, son architecture et le

méta-modèle proposé,

mettre en place PexOne CMIS Repository qui sera un référentiel conforme à la

norme CMIS permettant la gestion de documents issus de PexOne,

mettre en place PexOne CMIS Client qui sera intégré au sein de PexOne et

permettra à cette dernière d’utiliser les services exposés par le référentiel

CMIS via les web services.

Ce référentiel CMIS permettra aux applications de l’entreprise ou de l’organisation de :

faire la recherche de documents,

faire CRUD de documents : c’est-à-dire création de documents, lecture

de documents, mise à jour et suppression de documents,

faire du versioning : création d’un document en plusieurs versions,

naviguer dans l’arborescence du référentiel,



15

visualiser les caractéristiques d’un document : c’est-à-dire voir les

métadonnées,

télécharger des documents,

déposer des documents,

mettre en œuvre les mécanismes de contrôle et de validation des

échanges avec une traçabilité complète.

III. Etude de l’existant

1. Présentation de PexOne

La plateforme (PexOne Exchange Platform) a été conçue par Angokh Systems pour

apporter des solutions logicielles aux entreprises et organisations qui veulent échanger des

documents via l’internet. Elle présente différentes fonctionnalités permettant aux applications

des entreprises ou organisations d’accéder à son dépôt, afin d’utiliser les services offerts. Les

fonctionnalités les plus importantes sont les suivantes :

le téléchargement de document : cette fonctionnalité permet à une application

d’entreprise de se connecter dans le dépôt dans le but de télécharger un document

fourni par son partenaire. PexOne a la tâche d’informer un partenaire lorsqu’il existe

un document dans le dépôt qui lui est destiné. Elle envoie aussi une notification aux

partenaires concernés à chaque fois qu’un document est téléchargé au niveau du dépôt.

le dépôt de document : cette fonctionnalité permet à une application d’entreprise de

déposer un document au niveau du disque. Une fois le document déposé, PexOne

notifie les autres partenaires concernés pour leur informer que le document demandé

se trouve dans le dépôt. Les notifications sont automatisées dans la plateforme.

Nous avons deux types d’utilisateurs au niveau de PexOne :

l’utilisateur System : il est en même temps aussi l’administrateur PexOne. C’est lui qui

gère les tâches administratives de la plateforme. Il définit les rôles et les permissions

dans le dépôt.

l’utilisateur Partenaire : il est le principal bénéficiaire des solutions de la plateforme. Il

a la possibilité de télécharger des documents à partir du dépôt mais aussi d’y déposer

des documents également.



16

2. Architecture utilisée

La plateforme tourne dans un serveur d’application « JBOSS ». Elle est connectée à un

disque permettant de stocker les documents. Pour repérer les documents au niveau du disque,

PexOne utilise une base de données (MySQL) qui permet de créer des indexes pour chaque

document enregistré dans le disque.

L’architecture utilisée peut être représentée par la figure 1 ci-dessous.

Nous remarquons dans cette architecture que le stockage des documents au niveau du

disque ne respecte aucune norme standard. Il est impossible de faire certaines opérations avec

cette solution comme la recherche de documents. L’accès des applications de l’entreprise ou

de l’organisation au niveau du disque n’est pas standard.

Utilisateur

Utilisateur

Utilisateur

Interface de Gestion

Réception

Transfert

Routage

Nommage

Sécurité

Administration

Disque

Serveur

MySQL

Administrateur

Figure 1 : Architecture de l’existant



17

3. Evolutions souhaitées

Compte tenu des objectifs définis en haut, nous voulons utiliser un référentiel CMIS à

la place du disque pour stocker les documents issus de PexOne. Grâce à ce référentiel, on

pourra intégrer d’autres fonctionnalités comme la création de dossier, la recherche et la

création de document. De ce fait, on pourra permettre aux applications de l’entreprise ou

d’organisation d’accéder au référentiel de manière standard.

Ibrahima Diop 18

CMIS : Etat de l’art

I. Historique

Dans l’idée de trouver un standard qui faciliterait aux entreprises du monde ECM

(Entreprise Content Management) de s’interopérer à travers l’internet, Microsoft, alfresco,

oracle, SAP, IBM ont déclaré auprès d’OASIS1 un standard qui permettrait l’interopérabilité

entre les différents systèmes de gestion de contenus. Ce standard se nomme CMIS. La

première version fut sortie en MAI 2010 couvrant la plupart des fonctionnalités proposées par

les systèmes de gestion de contenus. Actuellement, on est à la version CMIS1.1.

II. Définitions et concepts

1. Définitions

1.1 CMIS

Selon Wikipédia : CMIS (Content Management Interoperability System) est

un standard ouvert qui permet aux différents systèmes de gestion de contenus

de s’interopérer à travers l’internet. Plus précisément, CMIS définit une

couche d’abstraction pour permettre la communication entre divers systèmes

de gestion de documents à l’aide de protocoles web.

Selon Apache Software Foundation : CMIS est une norme définie par l’OASIS

pour permettre un partage entre différents systèmes de gestion de contenus

d’information.

Cependant, nous ajouterons notre vision en percevant CMIS comme un

protocole ouvert permettant l’interopérabilité entre les CMS (Content

Management System).

1 http://en.wikipedia.org/wiki/OASIS_(organization)

CHAPITRE 2



19

1.2 Modèle de domaine

D’après Wikipédia : dans la résolution de problèmes en génie logiciel, un

modèle de domaine est un modèle conceptuel de tous les sujets liés à un

problème spécifique. Il décrit les différentes entités, leurs attributs, les rôles et

les relations, ainsi que les contraintes, qui régissent le domaine du problème.

2. Enjeux de CMIS

Aujourd’hui, on remarque une utilisation accrue de la gestion de documents

électroniques dans le milieu de l’entreprise. Ce qui favorise une rivalité entre les différents

constructeurs de gestion de stockages comme IBM, Microsoft, Alfresco etc. Chacun de ces

derniers fabrique son propre système de gestion de contenus, mais propose des moyens

spécifiques d’y accéder. Ce qui pose un problème pour les entreprises désirant s’interopérer à

travers l’internet. Ainsi, ces principaux constructeurs ont eu l’idée d’introduire un standard

CMIS qui permettrait non seulement aux développeurs de construire des applications

permettant l’accés aux différents systèmes de gestion de contenus de manière unifié, mais

aussi de favoriser l’interopérabilité entre ces systèmes. L’interface CMIS propose un

ensemble de fonctionnalités pour la mise en place d’un référentiel CMIS conforme avec la

plupart des systèmes de gestion de contenus existants. Elle propose aussi un ensemble de

services permettant le développement de clients utilisant ces fonctionnalités.

Ce concept est illustré dans la figure 2 ci-dessous.



20

Figure 2 : I ’enjeu de CMIS

III. Spécification CMIS

CMIS est un standard, et l’explication de ce standard est la spécification1 CMIS. Dans

cette dernière, CMIS définit un modèle de domaine, des services et un ensemble de liaisons

que les applications peuvent utiliser pour accéder à un référentiel CMIS.

1. Le modèle de domaine

1 Spécification CMIS, voir Webographie [1]

Cmis

Interfaces Cmis

Interfaces

Cmis

Interfaces

Cmis

Interfaces

Alfresco

Contents IBM Contents Alfresco

Contents Nuxeo

Contents

APPLICATION

Services orientés interfaces



21

Il s’agit du méta-modèle proposé par CMIS. Dans ce modèle, CMIS définit les

différents types d’objets qui sont pris en charges par un référentiel CMIS. Dans la norme

CMIS 1.0, on y trouve dans un référentiel CMIS les objets de types: Object Folder, Object

Document, Object Policy et Object Relationship.

1.1 Document Object

Les documents sont les principales entités gérées par un référentiel CMIS. Chaque

document a un ensemble de propriétés. Dans la création de l’objet « Document », les

propriétés « cmis : name » et «cmis : type » sont obligatoires. Un document peut être contenu

dans plusieurs dossiers. Il peut inclure ou non un flux de données. Les documents peuvent

être versionnables. CMIS propose un générateur automatique d’identifiant permettant

l’identification de chaque version du document. Les documents peuvent être protégés contre

certaines opérations telles que la suppression, la modification et ceci, grâce à des services

fournis par CMIS.

1.2 Folder Object

Les dossiers sont les objets contenant les documents. Ils sont stockés dans le

référentiel sous forme « d’arbres » quelconques. Tout dossier a un et un seul parent sauf la

racine qui n’a pas de parent. Il y’a une relation de dépendance entre un dossier et ses

descendants. On ne peut pas créer, ni supprimer ou encore modifier un dossier racine dans un

référentiel CMIS. Chaque dossier a un ensemble de propriétés dont celles-ci : « cmis : name »

et «cmis : type » sont obligatoires à sa création.

La suppression d’un dossier détruira tous les objets qu’il contient ainsi que ses relations avec

les autres objets.

De la même manière que les documents, les dossiers peuvent être protégés contre certaines

opérations grâce à des services fournis par CMIS.

1.3 Relationship Object

Les objets de type « Relationship Object » permettent de définir des relations entre les

différents types d’objets contenus dans un référentiel CMIS. Ces types d’objets sont différents

des objets dossiers et documents. Ils ne doivent pas en avoir du contenu mais on peut



22

appliquer des règles d’administration lors de la création de ces objets. Les relations peuvent

être définies entre des documents, des dossiers, ou entre un dossier et un document.

1.4 Policy Object

Les objets de type « Policy Object » permettent de définir des règles d’administration

qui seront appliquées aux objets du référentiel. Ces règles d’administration permettront de

protéger les objets du référentiel contre certaines actions non attribuées aux utilisateurs,

comme la suppression de document, de dossier etc. CMIS définit un objet de base avec un

ensemble de propriétés qui permet d’appliquer des règles d’administration à un objet. Chaque

développeur peut étendre cet objet pour créer ou ajouter d’autres règles d’administration dans

son référentiel.

Avec l’amélioration de cette norme, la version CMIS1.1 a ajouté deux types d’objets

supplémentaires dans un référentiel CMIS à savoir :

Secondary Object-Type : qui permet d’ajouter ou de supprimer un ensemble de

propriétés dans un référentiel CMIS.

Objet Item : destinait aux référentiels qui veulent définir d’autres types d’objets

différents des objets définis dans le standard.

La figure 3 ci-dessous montre les différents types d’objets contenus dans un référentiel CMIS

ainsi que leurs relations.



23

Figure 3 : les différents types d’objet dans un référentiel CMIS

2. CMIS services

CMIS fournit un ensemble de services applicables aux objets du référentiel.

Ces services permettront aux clients CMIS de communiquer avec le référentiel via les web

services. Ces services sont nombreux et variés. Certains sont obligatoires, d’autres sont

optionnels. Pour ne citer que les plus importants, nous avons :

Repositories services:

getRepository : qui permet d’avoir les identifiants des référentiels

disponibles.

getRepositoryInfo : qui donne les informations détaillées d’un référentiel

à savoir l’identifiant, le nom du référentiel, l’URI, la description, la



24

version du produit, les versions CMIS supportées, les propriétés

spécifiques du référentiel.

getTypes : qui permet d’avoir les types d’objets du référentiel et leurs

attributs.

getTypeDefiinition : qui retourne les propriétés détaillées d’un type

d’objet.

getAllowableActions : qui permet d’avoir les actions autorisées à

l’utilisateur sur un objet.

getContentStream : permet d’avoir le flux de contenu du document.

getPropreties : qui donne les propriétés de l’objet et éventuellement les

actions autorisées à l’utilisateur sur cet objet.

Navigations services :

getDescendant : qui permet d’avoir l’arborescence du dossier spécifié.

getChildren : qui donne les éléments situés au premier niveau du dossier

spécifié. Si toutes les versions d’un même document sont sous un même

dossier, seule la version la plus récente est renvoyée.

getFolderParent : permet d’avoir le dossier parent du dossier spécifié.

getCheckedoutDocuments : retourne les objets de type « Document »

auxquels l’utilisateur a accès.

Objects services :

creatDocument : permet la création d’objet de type « document ».

creatFolder : permet la création d’objet de type « Folder ».

createRelationship : permet de créer une relation entre deux objets.

updateProperties : permet de mettre à jour les propriétés de l’objet

spécifié.

deleteObject : permet la suppression d’un objet dans le référentiel.

deleteTree : permet de supprimer une arborescence à partir du dossier

spécifié.

setContentStream : crée ou remplace le flux de contenu associé à l’objet

« Document » spécifié.

deleteContentStream : supprime le flux de contenu associé à l’objet

«Document » spécifié.

Policies services :



25

applyPolicy : permet d’appliquer une règle d’administration à un objet.

removePolicy : permet de supprimer une règle d’administration

appliquée à un objet.

getAppliedPolicies : retourne la liste des objets « Policies » appliqués à

un objet.

Relationships services:

getRelationships : retourne la liste des relations de l’objet spécifié.

Versioning services:

checkIn : permet de faire une copie privée de la version courante du

document.

getPropertiesOfLatestVersion : retourne les propriétés de la dernière

version dans la série spécifiée.

getAllVersions: retourne la liste de toutes les versions de la série

spécifiée, triée par ordre décroissant de date de création.

deleteAllVersions : supprime toutes les versions de la série spécifiée.

Multifiling services:

addObjectToFolder : place l’objet spécifié sous un dossier.

removeObjectFromFolder : enlève l’objet spécifié d’un ou de tous les

dossiers dans lesquels il est placé.

3. CMIS liaisons

CMIS définit trois types de liaisons permettant de communiquer avec un référentiel

CMIS : la liaison AtomPub, la liaison web Service et la liaison browser.

3.1 Liaison AtomPub

La liaison AtomPub 1 est la liaison la plus utilisée dans les applications travaillant avec

un référentiel CMIS. Elle s’appuie sur les web services de type REST2. Toutes les demandes

s’exécutant dans le référentiel s’appuient donc uniquement sur le protocole http. Les

implémentations de cette liaison doivent être conformes avec la description apportée par la

spécification CMIS. Lors de l’implémentation de cette liaison, un document xml doit être

1 Pour plus d’information sur la liaison AtomPub, voir l’entrée [1] de notre webographie. 2 Voir Webographie [2]



26

fourni afin de décrire les services implémentés dans le référentiel. Les clients utilisent ce

document pour communiquer avec le référentiel.

3.2 Liaison Web service

La liaison par web service1 est le premier mode de liaison défini par la spécification

CMIS. Cette liaison implémente tous les services et opérations définis au niveau de cette

spécification. Elle se base sur les web services de type SOAP2, c’est-à-dire une combinaison

de http et du XML pour exécuter les demandes des clients dans le référentiel.

L’implémentation de cette liaison est facilitée aux développeurs grâce à un fichier WSDL. Ce

fichier présente la description des services et de tous les éléments décrits dans la

spécification.

3.3 Liaison Browser

La plupart des applications web s’exécutent dans un navigateur web. La question

serait donc de réfléchir sur une nouvelle liaison qui s’appuierait sur les nouvelles technologies

aux quelles les développeurs d’application ont l’habitude d’utiliser. Il s’agit des formulaires

html, du JavaScript etc. C’est dans cette optique, que la version CMIS.1.1 a introduite une

nouvelle liaison3 «Browser » qui permet aux développeurs d’application de construire des

clients CMIS s’exécutant dans les navigateurs web.

4. Sécurité CMIS

La plupart des référentiels CMIS contiennent des données confidentielles. C’est aux

développeurs de mettre en place une politique de sécurité pour la protection de ces données.

Par contre CMIS propose des mécanismes de protection liés à l’authentification et au contrôle

sur les objets du référentiel.

4.1 Authentification

Dans l’authentification des utilisateurs dans un référentiel CMIS, la norme propose

l’utilisation d’une base de données, d’un annuaire LDAP ou tout autre moyen permettant

1 Pour plus d’information sur la liaison web service, voir l’entrée [1] de notre webographie. 2 Voir Webographie [3] 3 Pour plus d’information sur la liaison browser, voir l’entrée [1] de notre webographie.



27

d’identifier les utilisateurs. Mais néanmoins, elle définit des mécanismes qui permettent la

traçabilité dans le référentiel et l’authentification des utilisateurs avant l’exécution d’une

quelconque instruction dans le référentiel. Pour renforcer la sécurité dans le référentiel, CMIS

propose d’utiliser l’implémentation de https afin d’éviter certaines attaques.

4.2 Contrôle

L’aspect sécuritaire est géré aussi bien au niveau de l’authentification qu’au niveau du

contrôle sur les objets du référentiel. Les données d’un référentiel CMIS doivent être

protégées contre certaines opérations. Pour ce faire, CMIS définit dans sa spécification des

services permettant le contrôle sur la manipulation des objets. Parmi ces services nous avons :

ApplyPolicy : qui applique des règles d’administration sur un objet.

ApplyAcl : qui permet d’ajouter d’autres mécanismes de sécurité sur un objet.

IV. Avantages et limites de CMIS

CMIS est un standard qui présente aussi bien des avantages que des inconvénients

parmi lesquels nous présentons quelques-uns.

1. Avantages de CMIS

Les avantages fournis par la norme CMIS sont nombreux et variés. Pour ne citer que

les plus importants, CMIS permet :

de bénéficier d’un modèle de données standard dans la gestion de documents.

d’éviter le développement de solutions spécifiques.

de mettre en place une plateforme interopérable.

de faciliter l’interopérabilité entre les différents systèmes de gestion de

contenus.

aux développeurs de bénéficier d’un ensemble de services permettant la mise

en place d’un référentiel CMIS avec des opérations telles que la recherche, le

téléchargement etc.

2. Limites de CMIS

Un référentiel CMIS présente des limites malgré les nombreux services qu’il offre.

Parmi ces limites, on peut citer :

la gestion des profils qui n’est pas prise en compte par les services offerts.

l’absence de services pour exécuter des transactions dans le référentiel.



28

les mécanismes permettant au référentiel d’exécuter certaines tâches

d’administration comme les notifications.

V. Etude comparative des solutions proposées

Les implémentations proposées en matière de CMIS serveur sont nombreuses et

variées, de même que les technologies utilisées. La plupart de ces implémentations

s’inspirent du projet Apache Chemistry1 d’Apache Software Fondation qui y’a fourni des

implémentations de cette norme dans plusieurs langages de programmation. Une étude

comparative de ces solutions serait donc nécessaire pour pouvoir faire un choix du type de

serveur qui sera intégré dans PexOne Exchange Platform.

Les deux tableaux suivants font une étude comparative de certaines solutions proposées.

1 Apache Chemistry est un projet de Apache Software Fundation regroupant plusieurs sous projets



29

Capacités/Logiciel

FileShare

Repository

Apache

Chemistry

inMemory

server

ISIS

Papyrus

Objects

LogicalDOC

Nuxeo

DM 5 .3+

et DAM

1.1+

ACL

AllVersionsSearchable

Changes

ContentStream-

Updatability

GetDescendants

GetFolderTree

Multifiling

PWCSearchable

PWCUpdatable

Query

Renditions

Unfiling

VersionSpecificFiling

Join

Manage

False

Objectidsonly

anytime

True

True

True

True

True

Bothcombined

Read

False

False

None

None

False

Properties

Pwconly

True

True

True

False

True

Metadataonly

None

True

False

None

None

True

None

None

True

True

True

False

False

None

None

False

False

None

None

False

Properties

Pwconly

True

True

True

False

True

Metadataonly

Read

False

False

None

None

True

Objectidso

nly

Pwconly

True

True

False

True

True

Bothcomb

ined

Read

False

False

Innerrando

uter

Figure 4 : Tableau comparatif des capacités des quelques serveurs CMIS – source Webo [4]



30

La figure 4 ci-dessus fait une étude comparative des capacités les plus importantes

dans un référentiel CMIS selon l’implémentation utilisée.

Chacune des capacités définie en haut admet un ensemble de valeurs définies par CMIS.

La capacité GetDescendant admet deux valeurs « true » ou « false ». Ces deux valeurs

permettent de définir si le référentiel peut supporter la navigation dans les dossiers.

Pour la capacité Query, lorsque sa valeur vaut « Metadataonly », cela signifie que le

référentiel supporte uniquement les requêtes sur les métadonnées.

La description de ces logiciels ainsi que la technologie utilisée sont présentées dans la figure 5

ci-dessous.

Logiciel

Open Source

Note

Technologies

utilisées

FileShare

Repository

OUI

Cette implémentation garde toutes les

données dans une partie du disque. Elle est

fournie aux développeurs qui veulent créer

des serveurs CMIS. Elle n’est pas destinée

donc à la production.

JAVA

InMemory

Server

OUI

Cette implémentation permet de garder

toutes les données du référentiel en

mémoire. Elle fournit aussi des bouts de

code permettant aux développeurs de les

intégrer facilement dans leurs

développements. Contrairement à

« FileShare Repository », cette

implémentation met en œuvre l’exécution

des requêtes dans le référentiel.

JAVA

ISIS Papyrus

Objects

NON

Ce module expose les objets définis dans le

dépôt Papyrus.

C++



31

LogicalDOC

OUI

Cette implémentation enregistre tous les

documents dans le LogicalDOC.

Elle vous donne la possibilité de les

consulter. Elle est destinée en production.

JAVA

Nuxeo DM

5 .3+ et DAM

1.1+

OUI

Cette implémentation est faite en php.

Elle est destinée en mode production mais

l’inconvénient est que les documents proxy

et les flux de contenus secondaires ne sont

pas accessibles via CMIS

PHP

Figure 5 : Etude comparative des solutions fournies en matière de serveur CMIS –

source Webo [4]

D’après une étude comparative suivant plusieurs critères, nous avons jugés nécessaire

d’intégrer le projet « FileShare Repository » dans PexOne. Et comme ce projet ne prend pas

en compte le service « query », on le combine avec le projet « InMemory Server» pour

assurer l’exécution des requêtes dans le référentiel. Ces deux projets font partie du projet

d’OpenCMIS1. Nous justifions notre choix par les critères suivants :

la technologie utilisée s’adapte à celle utilisée dans PexOne Exchange

Platform.

cette implémentation est Open Source.

sa documentation est accessible et disponible au public contrairement aux

autres.

par son but qui est de faire :

un simple CMIS client-serveur en java pour les développeurs.

de cacher les détails de liaison et fournit des APIs qui sont faciles à

intégrer dans votre solution.

Ces deux projets implémentent la plupart des services définis dans la spécification.

Le projet « InMemory Server » définit des services permettant d’exécuter des fonctions de

recherche dans le référentiel.

Ces deux projets incluent également des outils permettant aux développeurs de faire des tests.

1 OpenCMIS est un projet d’Apache Software Foundation fournissant l’implémentation de serveur CMIS dans

plusieurs langages de programmation.


Méthode d’analyse et de conception

I. Définitions des concepts

1. Analyse

L’analyse constitue une étape importante dans un projet informatique. Elle permet

d’avoir une idée claire des résultats attendus, de ressortir les fonctionnalités du système par un

besoin des utilisateurs. L’analyse permet donc de répondre à la question « que faut-il faire ? ».

Dans cette phase, on doit ressortir les besoins des utilisateurs afin de décrire le système en

termes de fonctionnalités.

2. Conception

La conception constitue également une étape importante dans un projet informatique.

Elle permet de définir le fonctionnement du système pour faciliter sa réalisation. La

conception permet de modéliser le système afin de délimiter ses périmètres. Elle permet de

répondre à la question «que faut-il faire et comment faut-il le faire ? ».

II. Pourquoi utiliser une méthode

Avec l’avènement de la technologie nous assistons à une complexité des systèmes

d’information. Les projets informatiques prennent de plus en plus de l’ampleur. Il devient

donc nécessaire de trouver un moyen pour optimiser les ressources et de garantir les budgets

et délais dans la réalisation d’application informatique. Les méthodes répondent bel et bien à

ces exigences. Nous devons noter qu’avec les progrès de la technologie, plusieurs méthodes

ont vu le jour. Une classification de ces méthodes serait donc nécessaire pour pouvoir faire un

choix.

III. Classification des méthodes d’analyse et de conception

1. Rappel sur la classification des méthodes d’analyse et de conception

CHAPITRE 3



33

1.1 Les méthodes cartésiennes

Avec les méthodes cartésiennes, le processus de conception se veut de manière

linéaire. Le système est étudié en termes de fonctionnalités. On se préoccupe plus des

méthodes à implémenter plutôt que les données à gérer. Dans ces méthodes, le système

étudié est décomposé en sous-systèmes jusqu’à un niveau élémentaire. Parmi les méthodes

cartésiennes les plus utilisées, nous avons SADT qui est une méthode très utile dans les

phases d’analyse d’un projet informatique.

1.2 Les méthodes systématiques

Dans l’approche systématique, on étudie le système en mettant l’accent sur les

différents éléments qui le constitue ainsi que leurs relations. Ces méthodes permettent de

modéliser les systèmes d’informations en apportant une représentation logique des éléments

du système. Cette approche trouve son importance dans l’organisation des systèmes

d’informations dans le milieu des entreprises. Parmi les méthodes systématiques les plus

connues, nous avons Merise qui est une méthode très utilisée dans l’analyse et la conception

de système d’informations.

1.3 Les méthodes orientées objet

Les méthodes orientées objet cherchent à apporter des solutions là où la plupart des

autres méthodes ont montré leurs limites. Pour ce faire, les approches objets apportent une

représentation informatique des éléments du monde réel. Elles permettent de rapprocher les

données et leurs traitements au sein d’un unique objet. La force de ces méthodes est qu’elles

ne se soucient pas de la manière dont les éléments seront implémentés. Elles sont donc,

indépendantes des langages de programmation.

1.4 Les méthodes orientées aspect

L’approche orientée aspect, est une nouvelle méthode apportée dans les projets

informatiques. Elle permet de résoudre les problèmes de séparation des préoccupations qui

existent dans la modélisation des applications. Avec cette approche, votre code devient plus

lisible, réutilisable et le remplacement de composants se fait rapidement grâce à la séparation

des préoccupations. Cette approche est très utilisée dans les applications utilisant le

framework SPRING.

2. Etude comparative des méthodes d’analyse et de conception



34

Les méthodes d’analyse et de conception présentent aussi bien des avantages que des

inconvénients. Nous ferons une étude comparative dans la figure 6 pour ressortir les forces et

les faiblesses de chacune de ces méthodes.

Méthodes

Avantages

Inconvenients

Cartésiennes (SADT)

La décomposition fonctionnelle

du système garantit la

conformité de la conception aux

besoins des utilisateurs.

Capacité à produire des solutions

à plusieurs niveaux

d’abstraction.

Elles ne permettent pas la

modélisation de systèmes

complexes.

On se préoccupe plus sur les

fonctions que sur les données à

gérer.

Systématiques

Capacités à modéliser les

systèmes d’informations en

apportant une représentation des

données.

Capacités de décrire les

systèmes complexes.

Manque de cohérence entre

données et traitements.

Faiblesse de la modélisation

des traitements.

Orientées Objet

Capacités à modéliser des objets

complexes.

Intégration des traitements aux

données.

Capacités à représenter des

objets du monde réel

Encapsulation des données.

Aspect fonctionnel mal

représenté.

Orientées Aspect

Maintenance aisée.

Meilleure réutilisation.

Gain de productivité.

Amélioration de la qualité du

code.

Production de code difficile à

analyser.

Figure 6 : Etude comparative de différentes méthodes d’analyse et de conception – source

Webo [5]



35

3. Choix de la méthode d’analyse et de conception

3.1 Synthèse

Nous avons fait tout au début de cette partie une classification des méthodes d’analyse

et de conception des méthodes les plus utilisées dans un projet informatique. Chacune de ces

méthodes présente aussi bien des avantages que des inconvénients.

Pour les méthodes cartésiennes, le fait de décomposer le système de manière

fonctionnelle permet de garantir la conformité entre les besoins du client et la conception.

L’inconvénient est qu’avec cette approche, la modélisation de système complexe devient

presque impossible.

Pour les méthodes systématiques, le gros avantage réside dans leurs capacités à

proposer une modélisation d’un système en s’appuyant sur des modèles à des niveaux

d’abstraction différentes, conception, organisation, logique, physique, etc.

L’inconvénient avec ces méthodes réside dans le fait que les données et leur traitement sont

séparés. Ceci entraînera un manque de cohérence entre les données et les traitements.

Pour les méthodes orientées objet, leur particularité vient de leurs capacités à pouvoir

modéliser les systèmes complexes, à apporter une représentation informatique des objets du

monde réel. Leurs approches permettent aussi une encapsulation des données. Les méthodes

orientées objet ne présentent pas de gros inconvénients par rapport aux autres. Mais

néanmoins, il faut souligner que l’aspect fonctionnel est mal représenté avec ces méthodes.

Pour les méthodes orientées aspect, l’avantage réside dans le fait que ces approches

permettent une réutilisation du code et de son amélioration. Elles permettent une maintenance

facile du produit et un gain de productivité. Son inconvénient est que le code produit est

difficile à analyser.

3.2 Choix de la méthode d’analyse et de conception

Dans le cadre de la réalisation de notre projet de stage, nous avons l’obligation de tenir

des réunions avec notre maître de stage afin de fixer des objectifs et de les réaliser au fur et à

mesure que le projet avance. Nous nous devons donc cibler une méthode itérative et

incrémentale pour être en phase avec cette logique. Les méthodes orientées objet répondent

bien à ces exigences.

Dans la suite de notre étude nous allons nous appesantir sur une approche orientée

objet. Cette approche est simple et générique. Elle trouve son origine dans le livre de Pascal



36

Roques intitulé « UML- Modéliser un site e-commerce »1. Cette méthode se situe entre UP

(Unified Process), qui est un cadre général de processus de développement, et une des

méthodes agiles XP (eXtreme Programming), qui est une approche minimaliste au mode

centré sur le code.

Cette méthode présente de nombreux avantages :

de la même manière qu’UP, cette méthode est conduite par les cas d’utilisation.

elle est aussi relativement légère et restreinte comme XP.

elle est centrée sur l’architecture.

elle est aussi itérative et incrémentale.

elle s’appuie sur l’utilisation du langage UML pour la modélisation.

En conformité avec cette démarche, nous portons notre choix sur UML pour

la modélisation dans les phases d’analyse et de conception

3.2.1 UP

a. Définitions et caractéristiques

Le processus unifié est un processus de développement logiciel itératif et incrémental,

centré sur l’architecture, piloté par les risques et conduit par les cas d’utilisation.

Itératif et incrémental : pour mieux maîtriser le projet, ce dernier est

décomposé en de petites itérations. Ce découpage est conditionné par les cas

d’utilisation et l’étude des risques. A la fin de chaque itération un livrable du

projet est fourni de façon incrémentale.

Centré sur l’architecture : la réussite d’un logiciel est conditionnée par le choix

d’une bonne architecture. L’architecture permet de satisfaire les besoins des

utilisateurs exprimés dans la phase de spécification des besoins. Elle permet

aussi de prendre en compte les évolutions futures du logiciel.

Piloté par les risques : Tous projets présentent des risques. Ces derniers doivent

être détectés le plutôt possible afin de pouvoir déterminer l’ordre des

itérations. Les risques majeurs doivent être traités en priorité.

Conduit par les cas d’utilisation : ce qui fait la réussite d’un projet est son

utilité. Le projet doit être conduit par les besoins des utilisateurs. Donc toutes

les étapes doivent être guidées par les cas d’utilisation.

1 Pour plus d’information sur cette méthode voir bibliographie [1]



37

b. Les phases du Processus Unifié

Les étapes du processus unifié peuvent être regroupées en quatre phases : l’analyse des

besoins, l’élaboration, la construction et la transition.

La phase d’analyse des besoins : cette phase consiste à donner une vision claire

du projet. Elle est destinée à faire une analyse des risques majeurs, une analyse

du budget et éventuellement le délai du projet sans oublier l’architecture

générale du système.

La phase d’élaboration : elle permet d’apporter plus de précision aux éléments

définis au niveau de la phase d’analyse des besoins.

Les objectifs de cette phase sont :

la création d’architecture de référentiel.

l’identification des risques, du budget et du délai du projet.

la planification de la phase de construction.

la phase de construction : elle est destinée à la réalisation du produit. C’est

dans cette phase que toutes les fonctionnalités doivent être implémentées.

C’est la phase qui consomme le plus de ressources.

la phase de transition : c’est dans cette phase que le produit est livré aux

utilisateurs. Cette phase permet de détecter les failles du produit afin de les

corriger et d’apporter éventuellement une formation aux utilisateurs.

3.2.2 XP

Les méthodes agiles sont des méthodologies orientées objet. Elles sont itératives,

incrémentales et destinées à la gestion de projets informatiques. Les méthodes agiles

cherchent à diminuer le cycle de vie du développement du produit en créant une version

minimale, puis à faire des intégrations en se basant sur les besoins du client. Cette démarche

itérative et incrémentale, implique les collaborateurs et le client tout au long du cycle de vie

du développement du produit.

XP (eXtreme Programming) est une méthode agile orientée sur l’aspect réalisation

d’une application, sans pour autant négliger l’aspect gestion de projet.



38

XP n’est donc qu’un certain nombre de bonnes pratiques qui permet le développement d’un

produit tout en mettant le client au centre du processus de développement.

Les principaux concepts qui font la force de XP sont les suivants :

les tests et le débogage sont fréquemment appliqués tout au long du processus

de développement,

les développeurs travaillent en collaboration avec le client tout au long du

développement du projet,

les livrables sont fournis à temps afin de maximiser l’impact des retours des

utilisateurs,

la mesure de l’avancement du projet est très importante et elle est gérée grâce à

des indicateurs,

le travail en équipe durant tout le processus du développement.

3.2.3 UML

a. Définition

UML (Unified Modeling Langage) est un langage de modélisation permettant une

représentation informatique des objets du monde réel. Il permet la représentation et la

communication des différents composants d’un système d’information. Par sa possibilité de

fournir divers éléments permettant la construction de modèles, UML peut être considéré

comme un métalangage.

b. Mise en œuvre

Dans sa version UML 2.0, UML fournit treize types de diagrammes permettant une

modélisation des systèmes d’informations. Ces diagrammes sont répartis en deux grandes

familles :

Diagrammes structurels ou statiques

Diagramme de classes : il permet de fournir une représentation abstraite

des objets du système ainsi que leurs interactions.

Diagramme d’objets : il permet d’avoir une vision plus claire des objets

ainsi que leurs interactions dans un diagramme de classe.



39

Diagramme de composants : il permet de représenter les composants du

système du point de vue physique.

Diagramme de déploiement : il montre la disposition physique des

différents matériels qui entrent dans la composition d’un système et la

répartition des instances de composants, de processus et d’objets qui

vivent sur ces matériels.

Diagramme de paquetages : il permet un regroupement logique des

éléments du système.

Diagramme de structures composites : il permet de décrire sous forme

de boîte blanche les relations entre composants d’une classe.

Diagrammes comportementaux ou dynamiques

Diagramme d’activités : Il permet de représenter graphiquement le

déroulement d’un cas d’utilisation.

Diagramme de cas d’utilisation : il permet de représenter les

fonctionnalités du système grâce à l’expression des besoins des

utilisateurs.

Diagramme d’états-transitions : il décrit le comportement des objets

appartenant à une même classe.

Diagramme de séquence : il permet de visualiser les séquences d’action

qui permettent la réalisation d’un cas d’utilisation.

Diagramme de communication : il permet de mettre en évidence les

interactions entre les différents objets du système.

Diagramme global d’interaction : il permet de définir l’enchainement

des états de classe et fait apparaître l’ordonnancement des travaux.

Diagramme de temps : il permet de décrire les variations d’une donnée

au cours du temps.



40

Etude détaillée

I. Spécifications fonctionnelles

Cette partie sera consacrée à l’identification des spécifications fonctionnelles du

système à réaliser. Pour ce faire, nous allons donc identifier les différents acteurs du système

et leurs rôles, ainsi que les différentes fonctionnalités du système.

1. Identification des acteurs et leurs rôles

Un acteur est une entité externe qui interagit directement ou indirectement avec notre

système. Les principaux acteurs de notre système sont l’utilisateur System qui est en même

temps aussi l’administrateur de PexOne Exchange Platform et l’utilisateur partenaire qui est le

principal bénéficiaire des solutions de la plateforme.

La description des acteurs ainsi que leurs rôles est représentée dans le tableau suivant (Figure

7).

Utilisateur System

Utilisateur Partenaire

L’utilisateur System dispose tous les

droits sur les fonctionnalités du

référentiel. IL est en même temps

l’administrateur de PexOne et du

référentiel. Il est chargé de :

faire CRUD de dossier.

faire CRUD de document.

définir des règles d’administration

sur les objets.

définir les rôles et les permissions.

L’utilisateur Partenaire, c’est lui qui bénéficie des

fonctionnalités exposées par le référentiel.

Il a la possibilité de :

faire un CRUD document.

voir les métadonnées d’un document.

télécharger un document.

déposer un document.

faire du versioning.

rechercher un document.

partager un document.

CHAPITRE 4



41

gérer la sécurité et la maintenance

du référentiel.

gérer la gestion des utilisateurs.

Figure 7 : Tableau d’identification des acteurs et leurs rôles

2. Les fonctionnalités du système

Les fonctionnalités du système seront divisées en trois catégories :

la gestion des utilisateurs, la gestion des dossiers et la gestion des documents.

Chacune de ces fonctionnalités englobe d’autres fonctionnalités.

La gestion des utilisateurs

Cette fonctionnalité sera gérée par l’administrateur PexOne qui est en même

temps aussi l’utilisateur System. Elle permettra à l’administrateur PexOne de

gérer les profils des utilisateurs, d’assurer la sécurité du référentiel ainsi que les

rôles, les permissions et les règles d’administration sur le référentiel.

La gestion des dossiers

Cette fonctionnalité sera aussi gérée par l’administrateur PexOne et l‘utilisateur

Partenaire. Elle permettra de bien organiser les dossiers dans le référentiel afin de

faciliter certaines opérations telles que la recherche de dossier, la création de

dossier etc. Cette fonctionnalité permettra donc à l’administrateur PexOne de faire

la création, la modification et la suppression de dossier dans le référentiel. Les

règles d’administration seront aussi appliquées sur les dossiers afin de les protéger

contre certaines opérations non autorisées.

La gestion des documents

Cette fonctionnalité permettra de gérer les documents PexOne. Elle regroupe

plusieurs fonctionnalités. Certaines sont communes aux deux utilisateurs définis

au niveau des acteurs du système comme la création de documents, le versioning,

la mise à jour et le téléchargement de documents. Par contre les services tels que

la définition des règles d’administration sur les documents ainsi que la

suppression de documents sont spécifiques à l’administrateur PexOne.

II. Analyse de la solution

1. Gestion des utilisateurs



42

Dans cette partie, nous travaillons sur la gestion des utilisateurs. Nous allons faire le

diagramme de cas d’utilisation pour la gestion des utilisateurs, faire la description textuelle de

quelques fonctionnalités et les illustrer par des diagrammes de séquences.

1.1 Diagramme de cas d’utilisation

Figure 8 : Diagramme de cas d’utilisation d’authentification au niveau du serveur CMIS

Description textuelle : s’authentifier

Résumé : Ce cas d’utilisation permet à l’utilisateur de se connecter au niveau du

référentiel CMIS.



43

Acteurs : Utilisateur Partenaire, Utilisateur System

Préconditions : L’utilisateur est connecté au niveau de la plateforme PexOne.

Post-conditions : L’utilisateur est connecté au niveau du référentiel CMIS.

Scénario nominal :

1. l’utilisateur accède à son profil au niveau de PexOne en fournissant son

identifiant et son mot de passe.

2. Il envoie une demande de connexion au niveau du serveur CMIS.

3. PexOne invoque l’interface connectionRequest exposée par le serveur CMIS en

lui fournissant l’identifiant et le mot de passe de l’utilisateur.

4. Le serveur CMIS valide la demande et envoie à PexOne la réponse par

l’intermédiaire de l’interface ConnectionResponse.

5. l’utilisateur accède au référentiel CMIS.

Scenario alternatif :

A1. Les paramètres de connexion ne figurent pas dans le serveur CMIS.

Ce scenario démarre entre 3 et 4. L’identifiant ou le mot de passe de l’utilisateur ne

figurent pas dans le serveur CMIS. Ce dernier envoie à PexOne un message d’erreur

et le scenario reprend en 2.

Description textuelle : créer utilisateur

Résumé : Ce cas d’utilisation permet d’inscrire un utilisateur au niveau du serveur

CMIS.

Acteurs : Utilisateur System

Précondition : L’utilisateur Partenaire ne possède pas de compte au niveau du serveur

CMIS.

Post-condition : L’utilisateur Partenaire admet un compte au niveau du serveur CMIS.

Scénario nominal :

1. L’utilisateur System accède à son profil.

2. Il envoie une demande de création User au niveau du serveur CMIS.



44

3. PexOne invoque l’interface createUser en lui fournissant un login et un

password.

4. Le serveur CMIS vérifie les paramètres fournis par l’utilisateur System.

5. Il valide l’inscription et enregistre l’utilisateur.

6. Il envoie un message à PexOne.

7. PexOne envoie une notification à l’utilisateur.

Scénario alternatif :

A1. Erreur lors de l’inscription de l’utilisateur.

Ce scénario commence entre 3 et 4. Le serveur CMIS détecte les erreurs sur les

paramètres fournis. Il envoie à l’utilisateur System un message d’erreur par

l’intermédiaire de PexOne. Le scénario reprend en 2.

Ces cas d’utilisation peuvent être représentés par les diagrammes de séquences suivants.

1.2 Diagramme de séquence

S’authentifier



45

Figure 9 : Diagramme de séquence d’authentification au niveau du serveur CMIS

Inscrire User



46

Figure 10 : Diagramme de séquence inscrire User au niveau du serveur CMIS

2. Gestion des dossiers

Dans cette partie, nous travaillons sur la gestion des dossiers. Nous allons faire le

diagramme de cas d’utilisation pour la gestion des dossiers, faire la description textuelle de





47

Figure 11 : Diagramme de cas d’utilisation pour la gestion des dossiers

Description textuelle : créer dossier

Résumé : Ce cas d’utilisation permet à l’utilisateur System de créer des dossiers au

niveau du référentiel CMIS.


Précondition : L’utilisateur System est connecté au niveau du serveur CMIS.

Post-condition : L’utilisateur System a créé un dossier.

Scénario nominal :

1. L’utilisateur System envoie une demande de création de dossier.

2. PexOne invoque l’interface createFolderRequest exposée par le serveur CMIS.



48

3. Le serveur CMIS vérifie les permissions attribuées à l’utilisateur System et envoie

une réponse à PexOne.

4. L’utilisateur System renseigne les paramètres sur le dossier à créer.

5. PexOne vérifie et invoque l’interface createFolder exposée par le serveur CMIS.

6. L’interface crée le dossier et le serveur CMIS envoie une réponse à PexOne.

7. Cette dernière envoie une notification à l’utilisateur System.


A1. L’utilisateur System n’a pas le droit de créer un dossier.

Ce scénario commence entre 2 et 3. Le serveur CMIS constate que l’utilisateur

System n’a pas le droit de créer un dossier. Il avertit PexOne et cette dernière envoie

à l’utilisateur System un message d’alerte et le scénario reprend en 1.

Description textuelle : supprimer dossier

Résumé : Ce cas d’utilisation permet à l’Utilisateur System de supprimer des dossiers

au niveau du référentiel CMIS.


Précondition : L’utilisateur System est connecté au niveau du serveur CMIS.

Post-condition : L’utilisateur System a supprimé un dossier dans le référentiel CMIS.

Scénario nominal :

1. L’utilisateur System envoie une demande de suppression de dossier.

2. PexOne invoque l’interface deleteFolderRequest exposée par le serveur CMIS.

3. Ce dernier vérifie les permissions attribuées à l’utilisateur System et envoie une

réponse à PexOne.

4. L’utilisateur System renseigne les paramètres sur le dossier à supprimer.

5. PexOne vérifie et invoque l’interface deleteFolder.

6. L’interface supprime le dossier et le serveur CMIS envoie une réponse à PexOne.




49


A1. L’utilisateur System n’a pas le droit de supprimer un dossier.

Ce scénario commence entre 2 et 3. Le Serveur CMIS constate que l’utilisateur

System n’a pas le droit de supprimer un dossier. Il avertit PexOne qui à son tour,

envoie à l’utilisateur System un message d’alerte et le scénario reprend en 1.

Ces cas d’utilisation peuvent être illustrés par les diagrammes de séquences suivants.


Créer dossier

Figure 12 : Diagramme de séquence créer dossier



50

Supprimer dossier

Figure 13 : Diagramme de séquence supprimer dossier

3. Gestion des documents

Dans cette partie, nous travaillons sur la gestion des utilisateurs. Nous allons faire le

diagramme de cas d’utilisation pour la gestion des utilisateurs, faire la description textuelle de





51

Figure 14 : Diagramme de cas d’utilisation pour la gestion des documents

Description textuelle : créer document

Résumé : Ce cas d’utilisation permet aux deux utilisateurs de créer des documents au

niveau du référentiel CMIS.

Acteurs : Utilisateur System, Utilisateur Partenaire

Précondition : L’utilisateur est connecté au niveau du serveur CMIS.

Post-condition : L’utilisateur a créé un document dans le référentiel CMIS.

Scénario nominal :

1. L’utilisateur envoie une demande de création de document.

2. PexOne invoque l’interface createDocumentRequest exposée par le serveur CMIS.



52

3. Ce dernier vérifie les permissions attribuées à l’utilisateur et envoie une réponse à

PexOne.

4. L’utilisateur renseigne les paramètres du document.

5. PexOne vérifie et invoque l’interface createDocument.

6. L’interface créée le document et le serveur CMIS envoie une réponse à PexOne.

7. Cette dernière envoie une notification à l’utilisateur.


A1. L’utilisateur n’a pas le droit de créer un document.

Ce scénario commence entre 2 et 3. Le Serveur CMIS constate que l’utilisateur n’a

pas le droit de créer un document. Il avertit PexOne. Cette dernière envoie à

l’utilisateur un message d’alerte et le scénario reprend en 1.

Description textuelle : supprimer document

Résumé : Ce cas permet à l’Utilisateur System de supprimer des documents au niveau

du référentiel CMIS.



Post-condition : L’utilisateur System a supprimé un document.

Scénario nominal :

1. L’utilisateur System envoie une demande de suppression de document.

2. PexOne invoque l’interface deleteDocumentRequest exposée par le Serveur

CMIS.

3. Ce dernier vérifie les permissions attribuées à l’utilisateur System et envoie une

réponse à PexOne.

4. L’utilisateur System renseigne les paramètres du document à supprimer.



53

5. PexOne vérifie et invoque l’interface deleteDocument.

6. L’interface supprime le document et le serveur CMIS envoie une réponse à

PexOne.



A1. L’utilisateur System n’a pas le droit de supprimer un document.

Ce scénario commence entre 2 et 3. Le serveur CMIS constate que l’utilisateur n’a

pas le droit de supprimer un document. Il avertit PexOne, cette dernière envoie à

l’utilisateur System un message d’alerte et le scénario reprend en 1.

Description textuelle : rechercher document

Résumé : Ce cas d’utilisation permet aux deux utilisateurs de rechercher un document

au niveau du référentiel CMIS.

Acteurs : Utilisateur System, Utilisateur Partenaire


Post-condition : L’utilisateur a trouvé le document cherché.

Scénario nominal :

1. L’utilisateur envoie une requête au niveau du serveur CMIS.

2. PexOne invoque l’interface query exposée par le serveur CMIS.

3. ce dernier fait l’analyse lexicale et syntaxique grâce au parseur ANTLR.

4. La requête est ensuite transformée en objet et envoyée au niveau du référentiel.

5. Le serveur CMIS envoie la réponse sous format JSON ou XML à PexOne.

6. PexOne envoie la réponse à l’utilisateur.


A1. Le document ne se trouve pas dans le référentiel CMIS.



54

Ce scénario commence entre 4 et 5. Le serveur CMIS constate que le document ne se

trouve pas dans le référentiel. Il envoie une alerte à PexOne. Cette dernière notifie

l’utilisateur et le scénario reprend en 1.

Ces cas d’utilisation peuvent être illustrés par les diagrammes de séquences suivants.


Créer document

Figure 15 : Diagramme de séquence créer document



55

Supprimer document

Figure 16 : Diagramme de séquence supprimer document

Rechercher document



56

Figure 17 : Diagramme de séquence rechercher document

III. Conception de la solution

Dans cette partie, nous allons faire la conception de la solution. Dans un premier

temps, nous présentons le diagramme de paquetage qui permet de montrer l’ensemble des

packages du projet OpenCMIS intervenant dans la mise en place de notre référentiel CMIS.

Dans un deuxième temps, on mettra en place le diagramme de classe de conception de

PexOne CMIS Repository et enfin, nous passons au diagramme de classe de PexOne CMIS

Client et de l’architecture de la solution.

1. Diagramme de paquetage

Dans le diagramme de paquetage ci-dessous nous présentons l’ensemble des packages

qui vont intervenir dans la mise en place de notre référentiel CMIS.



57

Figure 18 : Diagramme de paquetage de conception du référentiel CMIS

Le package org.apache.chemistry.opencmis.commons.server contient l’ensemble des

interfaces et des classes qu’il faut implémenter pour pouvoir communiquer avec notre

référentiel.

Le package org.apache.chemistry.opencmis.client.api contient la classe Session qu’il faut

utiliser pour se connecter à notre référentiel. Il contient également les interfaces des objets

définis dans le méta-modèle.

Le package org.apache.chemisry.opencmis.spi contient les interfaces décrivant l’ensemble

des services qu’on va définir dans notre référentiel CMIS.



58

Le package org.apache.chemistry.opencmis.commons.impl.server contient les classes

abstraites implémentant les interfaces définies dans le package

org.apache.chemistry.opencmis.commons.server

Le package org.apache.chemistry.opencmis.commons.definitions contient les interfaces

définissant les objets à implémenter dans notre référentiel CMIS.

Le package org.apache.chemistry.opencmis.commons.exception contient les interfaces

permettant de gérer les exceptions des méthodes.

Le package angokh.pexone.cmis.server permettra de mettre en place notre référentiel

CMIS. C’est ce package qui va implémenter toutes les interfaces définies en haut pour que

notre référentiel soit conforme à la normalisation.

2. Diagramme de classe de conception de PexOne CMIS Repository

Dans le diagramme de classe de conception ci-dessous (figure 19), nous allons

représenter l’ensemble des classes du package angokh.pexone.cmis.server qui permet de

mettre en place notre référentiel CMIS.



59

Figure 19 : Diagramme de classe de conception du référentiel CMIS

Dans le diagramme de classe de conception ci-dessus, nous avons représenté les classes

qui permettent de mettre en place notre référentiel CMIS.

Les deux classes PexoneCmisService et PexoneCmisServiceFactory vont permettre la

communication entre PexOne et notre référentiel via les web services.

La classe PexoneRepository implémentera tous les services définis dans la spécification

CMIS 1.1.

La classe PexoneCmisService fera appel à tous les services dont on aura besoin au niveau de

la plateforme (PexOne Exchange Platform).

La classe PexoneCmisServiceFactory servira à fabriquer des objets de la classe

PexoneCmisService.



60

Nous allons faire une description des services les plus importants de la classe

PexoneCmisService dans le tableau suivant.

Méthodes

Description

query

Elle permet d’executer des requétes au

niveau de notre référentiel.

createFolder

Elle permet de créer un dossier dans le

référentiel.

deleteFolder

Elle permet de supprimer un dossier dans le

référentiel

updateFolder

Elle permet de modifier les propriétés d’un

dossier.

createDocument

Elle permet la création d’un document.

deleteDocument

Elle permet la suppression d’un document

copy

Elle permet de copier un document contenu

dans un dossier du référentiel vers un autre

dossier.

updateProperties

Elle permet de mettre à jour les propriétés

d’un document ou d’un dossier.

getContentStream

Elle permet de recupérer le contenu du

document.

Figure 20 : Tableau descriptif des services de la classe PexOneCmisService

3. Diagramme de classe de conception de PexOne CMIS Client

Dans le diagramme de classe de conception ci-dessous (figure 21), nous représentons

les classes permettant de mettre en place le client qui sera intégré au niveau de la plateforme.



61

Ce client permettra à PexOne d’utiliser les fonctionnalités exposées par notre référentiel via

les web services.

Figure 21 : Diagramme de classe de conception de PexOne CMIS Client

IV. Architecture de la solution

L’architecture de la solution sera composée de plusieurs composants interconnectés

entre eux.

Nous aurons une base de données qui nous permettra de gérer l’authentification

des utilisateurs au niveau du référentiel.



62

Le Serveur CMIS qui contiendra les différents services exposés par le

référentiel.

Repository qui est notre référentiel CMIS. Il va stocker l’ensemble des

documents issus de PexOne.

Un serveur d’application hébergeant notre serveur CMIS. Nous utiliserons

Tomcat mais on peut bel et bien utiliser JBOSS ou un autre serveur

d’application.

Le module SPRING permettra l’exécution de certaines tâches en locale avant

de pouvoir les propulser dans le réseau via les web services.

Le module CMIS Client qui sera intégré dans PexOne. Ce module servira à

PexOne d’utiliser les services exposés par le référentiel CMIS via les web

services.

Le module d’Integration permettra de faire l’intégration entre PexOne et le

serveur CMIS.

L’architecture est représentée par la figure 22 ci-dessous.

Utilisateur

Utilisateur

Utilisateur

Module CMIS Client

Interface de

Gestion

Réception

Transfert

Routage

Nommage

Sécurité

Administration

Serveur TOMCAT

Module Integration

Serveur CMIS

Module SPRING

Module SPRING

Repository Serveur MySQL Administrateur

Figure 22 : Architecture de la solution



63

La force de notre solution repose essentiellement sur l’intégration de modules qui assurent sa

performance. Nous allons faire dans le chapitre suivant la mise en œuvre.



6

4

64

Mise en œuvre

I. Choix technologiques

1. Le langage Java

1.1 Présentation

Java est un langage informatique orienté objet. Contrairement à d’autres langages, Java

se veut d’être un langage fortement typé. Il présente de nombreux avantages dans la

programmation orientée objet.

1.2 Avantages

Le langage Java présente de nombreux avantages. Pour ne citer que les plus

importants, nous avons :

L’aspect sécurité qui est bien gérer car l’interpréteur Java vérifie toujours la conformité du

code entre la compilation et l’exécution.

Java est un langage portable : on peut exécuter un programme Java dans n’importe quel

système d’exploitation possédant un « JVM ».

Java fournit un ensemble d’APIs pour sa communauté ainsi qu’une documentation facilitant

son utilisation.

Java se détache des pointeurs au profit des tableaux.

2. XML

2.1 Présentation

XML (extensible Markup Language) est un langage fondé sur les balises. Il dérive du

langage SGML. Contrairement à html qui s’occupe de la présentation des données, XML est

un langage qui s’intéresse aux contenus des données. Sa syntaxe est simple et il permet de

décrire des documents. XML permet de définir aussi des espaces de noms qui sont très utiles

dans la programmation orientée objet.

2.2 Avantages

CHAPITRE 5



65

XML présente de nombreux avantages que sont les suivants :

N’importe quel type de données peut être décrit en xml.

Le langage XML est extensible.

Grâce à son arborescence, XML permet de faire des recherches faciles dans un document.

Il permet de faciliter l’interopérabilité entre les systèmes de gestion de contenus.

Avec xml, il est facile de parser des objets dans le développement orienté objet.

Une structure arborescente : permettant de modéliser la majorité des problèmes informatiques.

Intégrité : un document XML est utilisable par toute application pourvue d’un parseur.

Extensibilité : un document XML doit être utilisable dans tous les domaines d’application.

XML est donc particulièrement adapté à l’échange de données et de documents.

3. Les Web services

Un service web est une technologie web favorisant l’échange de données entre des

applications et des systèmes hétérogènes dans des milieux distribués. Il permet donc la

communication d’applications distantes via internet. Cette communication est indépendante

des langages de programmation et des plateformes utilisées. Un web service est décrit dans un

document WSDL (Web Service Description Language) qui précise les méthodes à appeler. Il

existe deux types de web services :

les web services de type SOAP où les requêtes et les réponses sont des flux xml

transportés par le protocole http.

les web services de type REST qui utilisent seulement du protocole http pour

invoquer des méthodes à distance.

4. Le Framework SPRING

Le framework SPRING peut être défini comme étant un conteneur « léger ». Son but

est de prendre en charge la création des objets. Il permet aussi de mettre en relation des objets,

grâce à un fichier de configuration qui décrit les dépendances entre les objets. La force de

SPRING réside dans le fait que les classes n’ont pas besoin d’implémenter une interface pour

être prises en charge par le framework. SPRING propose également un ensemble de services

permettant de prendre en charge la persistance des objets, la création d’EJBs, la création de

web services, les transactions etc.



66

Dans notre projet, nous utilisons ce framework afin de permettre certains modules de

s’exécuter en local avant de se propager dans le réseau via les web services.

5. Base de données

Pour la gestion des utilisateurs du référentiel, nous allons utiliser une base de données

ou un fichier local généré automatiquement par le serveur CMIS pour gérer l’authentification.

Il existe plusieurs Systèmes de Gestion de Base de Données dont les plus répandus sur le

marché sont MySQL, Oracle, SQL Server. Nous avons porté notre choix sur MySQL.

MySQL est un SGBD Open Source. Il fait partie des moteurs de base de données les plus

utilisés dans le monde. Son utilisation fonctionne avec la plupart des environnements de

développement. Il supporte les transactions et accepte les accès concurrents.

II. Architecture technique

1. Architecture applicative

Utilisateur

Utilisateur

Utilisateur

PexOne CMIS Client

Interface de

Gestion

Réception

Transfert

Routage

Nommage

Sécurité

Administration

Serveur TOMCAT

PexOne CMIS

Integration

Serveur CMIS

Référentiel

CMIS

Administrateur

Figure 23 : Architecture applicative



67

Nous pouvons ainsi remarquer que la force de notre solution repose essentiellement

sur l’intégration de modules qui assurent sa performance. L’authentification des utilisateurs

au niveau du référentiel est gérée par le serveur CMIS ainsi que les différents services exposés

par le référentiel CMIS. Les différents modules composant notre solution sont :

le serveur CMIS qui contiendra les différents services exposés par le

référentiel.

le référentiel CMIS qui va stocker l’ensemble des documents issus de PexOne.

le serveur Tomcat qui va héberger notre serveur CMIS.

le module CMIS Client qui sera intégré dans PexOne. Ce module servira à

PexOne d’utiliser les services exposés par le référentiel CMIS via les web

services.

le module PexOne CMIS Integration qui permettra de faire l’intégration entre

PexOne et le serveur CMIS.

2. Diagramme de déploiement

Le diagramme de déploiement montre la disposition physique des matériels et la

répartition des composants sur ces matériels. Pour le déploiement de notre solution, nous

aurons besoin :

d’un serveur CMIS qui sera connecté à notre référentiel CMIS,

d’un serveur d’application Tomcat hébergeant notre serveur CMIS,

d’un Repository CMIS qui stockera les données issues de PexOne,

du module CMIS Client et du module CMIS Intégration.



68

Figure 24 : Diagramme de déploiement

3. Politique de sécurité

La sécurité de notre solution est gérée à deux niveaux : l’authentification des

utilisateurs et la manipulation des objets du référentiel.

Pour l’authentification des utilisateurs, nous avons appliqué une des

recommandations proposées par la spécification CMIS. Lors de la connexion d’un

utilisateur, ces paramètres seront mis dans un objet «callContext ». Cet objet admet

un ensemble de paramètres dont le nom d’utilisateur et son mot de passe y figurent.

Cet objet nous permettra d’authentifier l’utilisateur grâce aux services

d’authentification définis dans le référentiel. Les identifiants des utilisateurs ainsi

que leurs mots de passe sont stockés au niveau du serveur CMIS.

Pour la manipulation des objets du référentiel, nous avons défini des règles

d’administration permettant de vérifier d’abord les profils avant l’exécution d’une

quelconque opération dans le référentiel.



69

III. Réalisation

1. Présentation des outils utilisés

JDK : C’est un ensemble d’outils et de bibliothèques proposés par oracle. Il est

open source et il permet à la JVM (machine virtuelle Java) d’exécuter des

programmes Java. Il existe plusieurs versions de JDK. La dernière version

stable est la version 7.0.25, fonctionnant dans la plupart des plateformes Java.

Tomcat : C’est un conteneur web. Il est fourni par Apache Software

Foundation. Il est open source et il peut s’exécuter via la machine virtuelle

Java dans n’importe quel système d’exploitation. De même que JDK, il existe

plusieurs versions de Tomcat fonctionnant dans la plupart des plateformes

Java. La dernière version de Tomcat est la version 7.0.54.

Maven : C’est un outil de build pour les projets Java. Maven est un produit

d’Apache Software Foundation et il est open source. Maven utilise un fichier

xml nommé POM (Project Object Model) pour configurer les projets ainsi que

leurs dépendances. Il existe plusieurs versions de maven dont la dernière est la

version 3.2.2.

2. Développement

Dans le développement, nous allons travailler sur la mise en place de PexOne CMIS

Repository et de PexOne CMIS Client.

2.1 PexOne CMIS Repository

Comme nous l’avons énuméré en haut PexOne CMIS Repository nous permettra de

mettre en place notre référentiel CMIS qui stockera les documents issus de PexOne. Il sera

développé dans un environnement objet (JAVA) avec comme version 1.7.0_21.

Nous allons utiliser comme IDE « Eclipse Kepler » version complète.

La mise en place du référentiel CMIS nécessite la création de projet maven avec une version 3

ou plus. Nous allons utiliser donc maven 3.1.1.

Pour le déploiement de notre serveur CMIS nous aurons besoin d’un serveur d’application.

Comme nous déployons sous tomcat, nous allons utiliser la version 7.0.53.



70

Ainsi, va suivre maintenant la mise en place du serveur CMIS. Pour ce faire, on se place dans

le répertoire « C:\book_home\projet » et on exécute la commande suivante :

mvn archetype: generate

-DgroupId = com.angokh.cmis

-DartifactId = chemistry-opencmis-server-fileshare

-Dversion = 1.0-SNAPSHOT

-Dpackage = com.angokh.cmis.server

-DprojectPrefix = PexOne

-DarchetypeGroupId = org.apache.chemistry.opencmis

-DarchetypeArtifactId = chemistry-opencmis-server-archetype

-DarchetypeVersion = 0.9.0

-DinteractiveMode = false

Cette commande nous permet de générer notre serveur CMIS (PexOne CMIS Repository).

Pour plus d’information concernant la mise en place de ce serveur CMIS et l’interprétation de

cette commande, se référer à l’entrée [2] de notre Webographie.

La figure 25 montre que notre serveur CMIS a été généré avec succès.



71

Figure 25 : Génération de notre serveur CMIS

Une fois notre projet crée, on l’importe sous éclipse comme un projet maven.

Les figures 26 et 27 montrent l’importation de notre projet sous éclipse.



72

Figure 26 : Importation de notre projet sous éclipse

Figure 27 : Importation de notre projet sous éclipse (suite)



73

La figure 28 montre l’arborescence du projet.

Figure 28 : Arborescence du projet

Le serveur généré est un « OpenCMIS1 » serveur qui contient quelques services de

lecture dans le référentiel et qui respecte les standards définis dans la norme.

Il nous faut maintenant implémenter les autres services par notre propre code. Comme le

serveur généré est un « OpenCMIS » serveur, nous allons nous inspirer de la manière dont ce

dernier a été implémenté dans le projet Apache Chemistry, plus particulièrement dans les

projets « FileShare Project » et « InMemory Project ».

Pour cela, on télécharge le code source fourni par OpenCMIS pour choisir les modules à

intégrer dans notre référentiel.

1 Voir lien : http://chemistry.apache.org/java/developing/index.html

http://chemistry.apache.org/java/developing/index.html



74

Nous remarquons dans le projet généré les deux classes définies au niveau de la figure

19 : la classe PexOneCmisService et la classe PexOneCmisServiceFactory.

La classe PexOneCmisService permettra la communication entre le client (PexOne CMIS

Client) et le référentiel CMIS. Tous les services (décrits au niveau de la spécification) qu’on

veut implémenter au niveau du serveur CMIS, devraient être appelés dans cette classe.

La classe PexOneCmisServiceFactory servira à fabriquer des objets de la classe

PexOneCmisService.

Le fichier « repository.properties » permettra la connexion entre le serveur CMIS et le

référentiel CMIS.

La première instruction de ce fichier doit être le nom de la classe PexOneCmisServiceFactory.

C’est dans ce fichier que nous définissons la racine de notre référentiel, les utilisateurs et les

permissions.

Le fichier « pom.xml » contient toutes les configurations nécessaires pour la mise en place de

notre serveur CMIS.

Pour l’implémentation des classes PexOneCmisService et PexOneCmisServiceFactory,

OpenCMIS fournit deux classes abstraites AbstractCmisService et

AbstractCmisServiceFactory qui implémentent presque la plupart des services définis dans un

référentiel CMIS. Donc nos classes PexOneCmisService et PexOneCmisServiceFactory vont

étendre respectivement AbstractCmisService et AbstractCmisServiceFactory.

La figure 29 ci-dessous montre une partie de la classe PexOneCmisService.



75

Figure 29 : Classe PexOneCmisService

La classe PexOneCmisServiceFactory est illustrée dans la figure 30 ci-dessous.

Figure 30 : Classe PexOneCmisServiceFactory



76

La figure 31 ci-dessous montre l’arborescence du projet après son implémentation.

Figure 31 : Arborescence du projet final

Une fois implémenté notre serveur CMIS, on génère le fichier « war » en exécutant la

commande suivante :

mvn clean install.



77

On déploie1 notre serveur CMIS dans un serveur d’application (Tomcat).

Pour vérifier que notre déploiement fonctionne, on démarre le serveur « Tomcat » (voir la

figure 32).

Figure 32 : Démarrage du serveur Tomcat

Puis on accède à l’URL de notre serveur CMIS (voir figure 33).

1 Déploiement sous Tomcat voir Webographie [6]



78

Figure 33 : Test de déploiement

Nous remarquons bien que notre serveur est basé sur le projet « OpenCMIS »

d’Apache Chemistry. Cette page « jsp » explique les caractéristiques de notre serveur CMIS.

Nous remarquons les trois types de liaisons permettant aux clients d’accéder au référentiel.

CMIS fournit un client swing « Workbench » permettant aux développeurs de tester les

fonctionnalités de leurs référentiels.

Une fois notre serveur créé, nous allons faire la mise en place de notre client (PexOne CMIS

Client ) qui sera intégré au niveau de la plateforme.

2.2 PexOne CMIS Client

Pour la mise en place du client (PexOne CMIS Client), on utilise un petit client fourni

par OpenCMIS qui intègre toutes les dépendances nécessaires pour se connecter dans un

référentiel CMIS. On pouvait bien créer le client en créant un projet maven. Ensuite on crée

nos propres classes pour appeler à distance les services exposés par notre référentiel. La

structure de notre classe client est représentée dans la figure 34 ci-dessous.



79

Figure 34 : PexOne CMIS Client

Nous remarquons ici, que les différentes classes permettent la gestion des dossiers,

des documents et des utilisateurs.

Ce module sera intégré au niveau de PexOne. Il servira à cette dernière de se connecter dans

notre serveur CMIS afin d’utiliser les services exposés par notre référentiel.

La méthode donnant la connexion par web service peut être illustrée dans la figure 35 ci-

dessous.



80

Figure 35 : Connexion par web service

La méthode pour se connecter et télécharger un document dans le référentiel via les web

services, est illustrée dans la figure 36 ci-dessous.



81

Figure 36 : Téléchargement de document dans le référentiel

IV. Présentation de la solution

Pour la présentation de la solution, nous allons présenter le référentiel CMIS. Comme

l’accés au référentiel est standard pour les clients CMIS, nous utilisons le client

« Workbench » pour vérifier les caractéristiques de notre référentiel ainsi que les

fonctionnalités telles que la création de dossiers et de documents. Pour les autres

fonctionnalités, nous les présentons avec notre propre client dans la partie annexe.

Dans la figure 37 ci-dessous nous présentons une connexion de l’utilisateur System

dans le référentiel avec l’utilisation de la liaison AtomPub.



82

Figure 37 : Connexion dans le référentiel CMIS

La figure 38 suivante présente les caractéristiques de notre référentiel, sa capacité, les

permissions et les règles d’administration définies.



83

Figure 38 : Présentation des caractéristiques de notre référentiel

Nous remarquons bien que notre référentiel supporte la navigation dans les dossiers. Les

permissions définies dans le référentiel sont : « cmis : read », « cmis : write » et « cmis : all ».

Ce qui signifie que les trois permissions attribuées aux utilisations sont : la lecture, l’écriture

et « tout ».

La figure 39 ci-dessous montre l’accés de l’utilisateur System dans notre référentiel.



84

Figure 39 : Accès au référentiel CMIS

Nous voyons à droite de l’écran les caractéristiques de notre référentiel : son nom, son

identifiant, son chemin d’accès etc.

La figure 40 ci-dessous montre la création d’un dossier dans le référentiel. Seul

l’utilisateur System a le droit de créer des dossiers.



85

Figure 40 : Création de nouveau dossier

La figure 41 ci-dessous, montre que notre dossier « NewFolder » a été créé avec

succès. On remarque également l’identifiant du dossier qui est généré de manière automatique

et les actions possibles à faire dans le dossier.



86

Figure 41 : Création de dossier dans le référentiel

Nous observons les propriétés qui permettent d’avoir la traçabilité dans le référentiel

dans la figure 42 ci-dessous.

Figure 42 : Traçabilité dans le référentiel



87

La figure 43 montre la création d’un document de l’utilisateur System. Pour créer un

document il faut d’abord choisir le dossier, ensuite donner les deux propriétés obligations

(nom et type du document). On peut créer un document directement dans la racine.

Figure 43 : Création de document dans le référentiel

La figure ci-dessous montre que le document est créé. De même que les dossiers, les

documents admettent aussi des identifiants générés de manière automatique. Il y’a aussi un

ensemble d’actions possibles attribuées aux utilisateurs sur le document.



88

Figure 44 : Illustration de la création de document



89

L’un des problèmes majeurs de la plateforme (PexOne Exchange Platform) est que les

documents sont stockés au niveau du disque et indexés dans une base de données.

L’objectif de ce projet est de mettre en place un référentiel CMIS pour être en

conformité avec la normalisation et pour permettre aux applications de l’entreprise ou de

l’organisation d’y accéder de manière standard.

D’abord, nous avons maîtrisé les spécifications de CMIS, son architecture et son méta-

modèle. Ensuite, nous avons fait la conception et la réalisation du référentiel CMIS. Et enfin,

nous avons réalisé le client CMIS qui sera intégré au sein de PexOne permettant aux

applications de l’entreprise ou de l’organisation d’avoir un accès standard dans le référentiel.

La principale difficulté rencontrée réside dans le fait que cette norme est récente et il

existe peu d’implémentation fournie.

Comme perspectives, nous envisageons d’ajouter dans notre référentiel d’autres

fonctionnalités qui n’ont pas été fournies par CMIS. Parmi ces fonctionnalités, nous avons :

les services permettant d’exécuter des transactions dans le référentiel.

les mécanismes permettant au référentiel d’exécuter certaines tâches d’administration

comme les notifications.

CONCLUSION

Bibliographie :

[1] : UML- Modéliser un site e-commerce, Pascal Roques, 2002 Edition Eyrolles

[2]: CMIS and Apache Chemistry in Action, FLORIAN MÜLLER, JAY BROWN ET JEFF

POTTS, 2013 Manning Publications

[3]: UML2 par la pratique, Pascal Roques, 5eme Edition, 2006 Edition Eyrolles

[4] : UML2 en action, De l’analyse des besoins à la conception, Pascal Roques, Frank Vallée,

4eme Edition, 2007 Edition Eyrolles

Webographie:

[1] : Liaison CMIS, Spécification CMIS :

URL: http://docs.oasis-open.org/cmis/CMIS/v1.1/csprd01/CMIS-v1.1-csprd01.pdf

[2] : Liaison AtomPub :

URL: http://fr.wikipedia.org/wiki/Representational_State_Transfer

[3] : Liaison Web Service :

URL : http://fr.wikipedia.org/wiki/SOAP

[4] : Etude comparative des solutions proposées :

URL: http://fr.wikipedia.org/wiki/CMIS

[5] : Etude comparative des méthodes d’analyse et de conception

URL: http://www.ingenieurs.com/documents/cours/methodes-d-analyse-comparee-

105.php

[6]: PexOne CMIS Repository

URL: http://chemistry.apache.org/java/developing/index.html

Bibliographie

http://docs.oasis-open.org/cmis/CMIS/v1.1/csprd01/CMIS-v1.1-csprd01.pdf

http://fr.wikipedia.org/wiki/Representational_State_Transfer

http://fr.wikipedia.org/wiki/SOAP

http://fr.wikipedia.org/wiki/CMIS

http://www.ingenieurs.com/documents/cours/methodes-d-analyse-comparee-%20105.php

http://www.ingenieurs.com/documents/cours/methodes-d-analyse-comparee-%20105.php

http://chemistry.apache.org/java/developing/index.html

A1 : Arborescence du référentiel PexoneRepository

A2 : Méthode permettant de créer un dossier

Annexes

A3 : Méthode permettant de mettre à jour un document

A4 : Les librairies utilisées et les dépendances

A5 : Module d’intégration

REPUBLIQUE DU SENEGAL UNIVERSITE CHEIKH ANTA DIOP …Chapitre 1: Présentation générale ... JSON...

Documents

Transcript of REPUBLIQUE DU SENEGAL UNIVERSITE CHEIKH ANTA DIOP …Chapitre 1: Présentation générale ... JSON...