Implémentation d`une infrastructure collaborative asynchrone basée

Transcription

Badji Mokhtar University -AnnabaUniversite Badji Mokhtar -Annaba-
‫ﺟﺎﻣﻌﺔ ﺑـﺎﺟﻲ ﻣﺨـﺘﺎر ﻋﻨﺎﺑﺔ‬
Faculté : Sciences de l'Ingénieur
Année 2010
Département : Informatique
MEMOIRE
Présenté en vue de l'obtention du diplôme de magister
Implémentation d’une infrastructure
collaborative asynchrone basée sur les
services web
Option
Texte Parole et Image
Par
Chemame Chaouki
DIRECTEUR DE MEMOIRE: M. M.SELLAMI
Professeur Université Annaba
DEVANT LE JURY
Président :
FARAH Nadir
MC
Université Annaba
Examinateurs :
SERIDI Hassina
MC
Université Annaba
BELLEILI Habiba
MC
Université Annaba
Avant tout, je remercie Dieu le tout puissant de m’avoir
aidé à concrétiser et à mener à terme ce travail.
Je tiens à exprimer mes vifs remerciements à mon
encadreur ; le professeur Sellami « Directeur du laboratoire
de recherche en informatique de l’université Badji Mokhtar
Annaba », d’avoir assuré l’encadrement de ce travail et pour
le soutien qu’il m’a apporté tout le long de la réalisation de
ce manuscrit, qu’il trouve ici l’expression de ma très
profonde reconnaissance.
Je remercie vivement les membres du jury qui m’ont fait
le grand honneur d’accepter de juger ce travail.
Ma reconnaissance s’adresse, à tous les enseignants du
département d’informatique pour l’enseignement et les
conseils qu’ils m’ont apportés durant toute ma formation
ainsi qu’à toutes les personnes qui, de prés ou de loin, ont
généreusement contribués à l’élaboration de ce mémoire.
Merci infiniment
Mémoire de Magister
1
2010
‫ﻣﻠﺨﺺ‬
‫اﻟﺘﻄﻮر اﻟﺴﺮﻳﻊ ﻓﻲ ﺗﻜﻨﻮﻟﻮﺟﻴﺎ اﻟﻤﻌﻠﻮﻣﺎت ‪ ،‬اﻟﺸﺒﻜﺎت واﻻﺗﺼﺎﻻت أدى إﻟﻲ‬
‫ﺗﻮﺱﻊ هﺎﺋﻞ ﻟﻺﻥﺘﺮﻥﺖ‪ .‬إﻥﻨﺎ ﻥﻤﺮ ﺏﻌﻬﺪ ﺟﺪﻳﺪ ﻣﻦ اﻟﺪﻳﻤﻘﺮاﻃﻴﺔ ﻓﻲ ﻹﻥﺘﺮﻥﺖ ‪ ،‬و اﻻﻥﺘﻘﺎل‬
‫إﻟﻰ ﻣﺠﺘﻤﻊ اﻟﻤﻌﻠﻮﻣﺎت اﻟﻠﺬان أدﻳﺎ إﻟﻰ ﻋﻤﻠﻴﺔ ﻋﻮﻟﻤﺔ اﻟﺘﻲ ﻗﺎﻣﺖ ﺏﺘﺤﺮﻳﺾ اﻟﻨﺎس ﻋﻠﻰ‬
‫إﻗﺎﻣﺔ ﻋﻼﻗﺎت وإﻥﺸﺎء ﻓﺮق اﻓﺘﺮاﺿﻴﺔ ﻣﻊ ﺏﻌﻀﻬﻢ اﻟﺒﻌﺾ وﻓﻲ آﺎﻓﺔ أﻥﺤﺎء اﻟﻌﺎﻟﻢ‪.‬‬
‫وهﻜﺬا ﻳﺄﺗﻲ ﻋﻬﺪ ﺏﻨﺎء ﻣﻨﺎهﺞ ﺗﻌﺎوﻥﻴﺔ ﻓﻲ ﻣﺨﺘﻠﻒ اﻟﻤﺠﺎﻻت )إدارة اﻟﻤﻌﺮﻓﺔ‪ ،‬اﻟﺘﻌﻠﻢ‬
‫واﻟﻄﺐ ﻋﻦ ﺏﻌﺪ‪ ...‬إﻟﺦ(‪ .‬هﺬﻩ اﻟﻤﻨﺎهﺞ اﻟﺘﻌﺎوﻥﻴﺔ ﻳﻤﻜﻦ أن ﺗﺪﻣﺞ ﻋﺪة أدوات ﺗﻌﺎوﻥﻴﺔ‬
‫اﻟﻤﺘﺰاﻣﻨﺔ ﻣﻨﻬﺎ و اﻟﻐﻴﺮ ﻣﺘﺰاﻣﻨﺔ‪ ،‬و هﺬا ﻹﺗﺎﺡﺔ ﻓﺮص اﻟﺘﻔﺎﻋﻞ وﺗﺒﺎدل اﻟﻤﻌﻠﻮﻣﺎت‬
‫ﺏﻴﻦ ﻣﺠﻤﻮﻋﺎت ﻣﻦ اﻟﻨﺎس ﻋﻦ ﺏﻌﺪ‪.‬‬
‫إن وﺹﻮل ﺗﻜﻨﻮﻟﻮﺟﻴﺎ اﻟﺨﺪﻣﺎت اﻟﻤﻮﺟﻬﺔ وﺗﻜﻨﻮﻟﻮﺟﻴﺎ ﺥﺪﻣﺎت اﻻﻥﺘﺮﻥﺖ وﻓﺮ ﻋﺪة‬
‫ﺡﻠﻮل ﺟﺪﻳﺪة ﻟﻬﺬﻩ اﻟﻤﻨﺎهﺞ اﻟﺘﻌﺎوﻥﻴﺔ‪ ،‬ﻻﺱﻴﻤﺎ ﻣﻦ ﺡﻴﺚ ﺱﺮﻋﺔ اﻻﺱﺘﺠﺎﺏﺔ وذﻟﻚ ﻣﻦ‬
‫ﺥﻼل إﻥﺸﺎء وﺡﺪات ﺗﻌﺎوﻥﻴﺔ ﻗﺎﺏﻠﺔ ﻟﻺﻋﺎدة ﺡﺴﺐ اﺡﺘﻴﺎﺟﺎت اﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪،‬أو ﻣﻦ‬
‫ﺡﻴﺚ ﻣﺴﺘﻮى اﻟﻤﺮوﻥﺔ وﻋﺪم اﻟﺘﺠﺎﻥﺲ ﺏﺠﻌﻞ آﺎﻓﺔ اﻟﺨﺪﻣﺎت ﺗﺘﻌﺎﻣﻞ ﻣﻊ ﺏﻌﻀﻬﺎ‬
‫اﻟﺒﻌﺾ رﻏﻢ اﺥﺘﻼف ﻃﺒﻴﻌﺘﻬﺎ‪ ،‬اﻟﺘﻲ ﺗﺼﺒﺢ ﺏﺪورهﺎ ﺥﺪﻣﺎت ﺟﺪﻳﺪ ﻗﺎﺏﻠﺔ ﻟﻼﺱﺘﻬﻼك‬
‫ﻣﻦ ﻃﺮف ﻣﻨﺎهﺞ أﺥﺮى‪.‬‬
‫إذا اﻟﻐﺮض ﻣﻦ هﺬﻩ اﻟﻤﺬآﺮة هﻮ ﺗﻮﻓﻴﺮ ﺏﻨﻴﺔ ﺗﻌﺎوﻥﻴﺔ ﺗﺴﺘﻨﺪ إﻟﻲ ﻣﺠﻤﻮﻋﺔ ﻣﻦ‬
‫أدوات اﻟﺘﻌﺎون اﻟﻐﻴﺮ ﻣﺘﺰاﻣﻦ ﻣﺼﻤﻤﺔ ﻓﻲ ﺵﻜﻞ ﺥﺪﻣﺎت ﻳﻤﻜﻦ اﺱﺘﻬﻼآﻬﺎ ﻣﻦ ﻃﺮف‬
‫أي ﻣﻨﺼﺔ ﺗﻮﻓﺮ هﺬا اﻟﻨﻮع ﻣﻦ اﻟﺘﻜﻨﻮﻟﻮﺟﻴﺎ‪.‬‬
‫اﻝﻜﻠﻤﺎت اﻝﻤﻔﺘﺎﺣﻴﺔ‪ :‬اﻟﻬﻨﺪﺱﺔ اﻟﻤﻮﺟﻬﺔ ﻟﻠﺨﺪﻣﺎت‪ ،‬ﺥﺪﻣﺎت اﻟﺸﺒﻜﺔ اﻟﻌﺎﻟﻤﻴﺔ‪ ،‬اﻟﻤﻨﺼﺔ‬
‫اﻟﺘﻌﺎوﻥﻴﺔ‪ ،‬أداة اﻟﺘﻌﺎون اﻟﻤﺘﺰاﻣﻦ‪ ،‬أداة اﻟﺘﻌﺎون اﻟﻐﻴﺮ ﻣﺘﺰاﻣﻦ‪.‬‬
‫‪2010‬‬
‫‪2‬‬
‫‪Mémoire de Magister‬‬
Résumé
Le développement fulgurant des technologies de l’information, des réseaux et
des moyens de communication est à l’origine d’une expansion prodigieuse de
l’internet. Nous traversons une nouvelle ère où la démocratisation de l’internet et le
passage à la société de l’information conduisent à un processus de globalisation
incitant à la mise en relation des personnes et à la constitution d’équipes virtuelles
réparties à travers le monde. Ainsi l’ère des plates-formes collaboratives construites
dans des domaines différents (gestion des connaissances, enseignement à distance,
Télémédecine, etc.), intègrent plusieurs outils de collaboration (synchrones et
asynchrones) et offrent des possibilités d’interaction et d’échange d’informations
entre des groupes de personnes situés dans des endroits différents.
L’avènement de l’architecture orientée service et des technologies des services
web a apporté de nouvelles solutions à ces plates-formes collaboratives , notamment
au niveau de la réactivité et de l’évolutivité, en mettant en place des services ou des
modules de collaboration évolutifs et recomposables au gré des besoins des
utilisateurs, et au niveau de la flexibilité et de l’hétérogénéité, en faisant
communiquer des services de natures différentes, qui peuvent devenir à leur tour
des nouveaux services consommables par d’autres plates-formes.
Le but de ce mémoire est ainsi de proposer une infrastructure collaborative
basée sur un ensemble d’outils de collaboration asynchrones conçus sous forme de
services et qui peuvent être consommés par n’importe quelle plate-forme offrant ce
type de technologies.
Mots clés : Architecture Orientée Services, SOA, Services web, Plate-forme
collaborative, Outil de collaboration synchrone, Outil de collaboration asynchrone.
3
2010
Abstract
The rapid development of information technology, networks and
communications rise to a prodigious expansion of the Internet, We are in a
developing era where democratization of the Internet and the transition from
information to society has led a process of globalization, encouraging the linking of
people and the creation of virtual teams spread around the world. Thus the era of
collaborative platforms built in different fields, such as knowledge management,
distance learning, telemedicine, etc, that are Integrating several collaborative tools,
which include synchronous and asynchronous, providing opportunities for
interaction and exchange of information between groups of people located in
different places.
The arrival of service-oriented architecture and Web services technologies has
provided solutions to this newly found collaborative platform, especially in the
reactivity and the scalability, by setting up services or collaborative evolutionary
modules and redialing to the needs of users and concerning flexibility and
heterogeneity by communicating with different types of services, which have become
new services consumable by other platforms.
The purpose of this memorandum is to provide a collaborative infrastructure
based on a set of asynchronous collaboration tools designed in the form of services
and which can be consumed by any other platform offering this type of technology.
Key words: Service oriented architecture, SOA, Web service, Collaborative
platform, Synchronous tool for collaboration, Asynchronous tool for collaboration.
4
2010
TABLEAU DE MATIERES
Table des matières
‫ ﻣﻠﺨﺺ‬................................................................................................................................................ 2
RESUME........................................................................................................................................ 3
ABSTRACT ................................................................................................................................... 4
TABLE DES MATIERES ............................................................................................................ 5
LISTE DES FIGURES.................................................................................................................. 9
INTRODUCTION GENERALE ............................................................................................... 11
CHAPITRE I : ARCHITECTURE DES SERVICES WEB ................................................... 14
PARTIE 1 : ARCHITECTURE DES SERVICES WEB......................................................... 15
I.1. INTRODUCTION.....................................................................................................................15
I.2. SERVICES WEB : DEFINITION ET PRINCIPES ...........................................................................15
I.3. DESCRIPTION DE SERVICES WEB ..........................................................................................16
I.3.1. Description fonctionnelle et structurelle WSDL .........................................................16
I.3.2. Description comportementale......................................................................................17
I.3.3. Description d'aspects non-fonctionnels < WS-Policy >.............................................17
I.4. LES PRINCIPALES TECHNOLOGIES DE DEVELOPPEMENT DES SERVICES WEB ........................18
I.4.1. XML (Extensible Markup Language)...........................................................................18
I.4.1.1. XML un descendant de SGML .............................................................................18
I.4.1.2. Codage des données et interopérabilité.................................................................18
I.4.1.3. Utilisation des fichiers XML ................................................................................19
I.4.2. SOAP (Simple Object Access Protocol).......................................................................20
I.4.2.1. Modèles d’échange de messages en SOAP ..........................................................20
I.4.2.2. Enveloppe SOAP ..................................................................................................21
I.4.2.3. En tête SOAP ........................................................................................................21
I.4.2.4. Corps SOAP..........................................................................................................21
I.4.3. Apatche-Axis Une mise en œuvre de SOAP .................................................................22
I.4.4. WSDL (Web Service Description Language)...............................................................23
I.4.5. UDDI (Universal Description Discovery and Integration) .........................................24
I.5. CYCLE DE VIE DES SERVICES WEB........................................................................................24
I.6. AVANTAGES DES SERVICES WEB.........................................................................................25
I.7. LIMITES DES SERVICES WEB.................................................................................................26
PARTIE 2 : COMPOSITION DES SERVICES WEB ............................................................ 27
I.8. DEFINITIONS ET TYPES DE COMPOSITION DE SERVICES WEB ................................................27
I.8.1. Définitions....................................................................................................................27
I.8.1.1. L’encapsulation de services natifs ........................................................................27
I.8.1.2. L’établissement d’accord d’externalisation ..........................................................27
I.8.1.3. L’assemblage de services composants..................................................................27
I.8.1.4. L’exécution de services composants.....................................................................27
I.8.1.5. Le contrôle de l’exécution de services composites...............................................27
I.8.1.6. L’évolutivité des services .....................................................................................28
I.8.2. Types de composition de services Web ........................................................................28
5
2010
TABLEAU DE MATIERES
I.8.2.1. Orchestration.........................................................................................................28
I.8.2.2. Chorégraphie.........................................................................................................30
I.8.3. Langages de composition de services Web..................................................................32
I.8.3.1. XLANG (XML Business Process Language).......................................................33
I.8.3.2. BPML (Business Process Modeling Language) ...................................................33
I.8.3.3. WSFL (Web Service Flow Language)..................................................................33
I.8.3.4. WSCL (Web Service Conversation Language) ....................................................34
I.8.3.5. WSCI (Web Service Choreography Interface) .....................................................34
I.8.3.6. BPEL4WS.............................................................................................................34
a. Le processus abstrait..................................................................................................35
b. Le processus exécutable ............................................................................................35
I.8.3.7. WS-CDL (Web Services Choreography Description Language) .........................37
I.9. CONCLUSION ........................................................................................................................37
CHAPITRE II : LES PLATES-FORMES COLLABORATIVES ......................................... 38
II.1. INTRODUCTION ...................................................................................................................39
II.1.1. Les Outils Synchrones ................................................................................................39
II.1.2. Les Outils Asynchrones ..............................................................................................39
II.2. DEFINITION DE TRAVAIL COLLABORATIVE ..........................................................................39
II.3. CATEGORIE DES SYSTEMES COLLABORATIFS.......................................................................40
II.3.1. Les collecticiels...........................................................................................................40
II.3.2. Le Workflow................................................................................................................40
II.4. LES PRINCIPAUX PLATES-FORMES EXISTANTES ...................................................................41
II.4.1. SAKAI .........................................................................................................................41
II.4.2. Open-Xchange ............................................................................................................42
II.4.2.1. Présentation ......................................................................................................... 42
II.4.2.2. Fonctionnalités de Open-Xchange Server ...........................................................43
II.4.3. Silverpeas....................................................................................................................44
II.4.3.1. Des services collaboratifs ....................................................................................44
a. Le service« ALMANACH » .....................................................................................45
b. Le service« CHAT » .................................................................................................45
c. Le service « ANNUAIRE ».......................................................................................45
d. Le service « ENQUETE ».........................................................................................45
e. Le service « FORUM » .............................................................................................46
f. Le service de « GESTION DE PROJET » - (PROJECT ORGANIZER)..................47
g. Le service « PLAN D’ACTION ».............................................................................47
h. Le service « QUIZ »..................................................................................................48
i. Le service « NEWS ».................................................................................................48
j. Le service « BLOG » .................................................................................................49
k. Le service « GALLERY » (BANQUE D’IMAGES)................................................49
l. Le service « SILVERCRAWLER »...........................................................................50
m. Le service de NOTIFICATION ...............................................................................50
n. WORKFLOW DE CIRCULATION DES INFORMATIONS .................................50
II.4.3.2. Des services de GED et de gestion de connaissances .........................................50
II.4.4. Xwiki ...........................................................................................................................51
II.5. CONCLUSION ......................................................................................................................52
6
2010
TABLEAU DE MATIERES
CHAPITRE III : ARCHITECTURE PROPOSEE.................................................................. 53
III.1. INTRODUCTION ..................................................................................................................54
III.2. L’OUTIL OPEN SOURCE ......................................................................................................54
III.2.1. Définition...................................................................................................................54
III.2.2. La licence open source..............................................................................................54
III.2.2.1. Libre redistribution.............................................................................................54
III.2.2.2. Code source ........................................................................................................54
III.2.2.3. Travaux dérivés ..................................................................................................54
III.2.2.4. Intégrité du code source de l'auteur....................................................................55
III.2.2.5. Pas de discrimination entre les personnes ou les groupes..................................55
III.2.2.6. Pas de discrimination entre les domaines d'application .....................................55
III.2.2.7. Distribution de la licence....................................................................................55
III.2.2.8. La licence ne doit pas être spécifique à un produit ............................................55
III.2.2.9. La licence ne doit pas contaminer d'autres logiciels ..........................................55
III.3. L’INTEGRATION DES APPLICATIONS AU SEIN D'UN ENVIRONNEMENT COLLABORATIVE ........56
III.3.1. Les problèmes liés à l’intégration d’applications.....................................................56
III.3.1.1. La complexité.....................................................................................................56
III.3.1.2. Une programmation redondante et ne pouvant être réutilisée............................56
III.3.1.3. Des interfaces multiples .....................................................................................56
III.3.2. Les exigences de la programmation d’aujourd’hui ..................................................57
III.3.2.1. L’exploitation du parc informatique existant .....................................................57
III.3.2.2. La prise en charge de tous les types d’intégrations requis .................................57
III.3.2.3. La possibilité de mises en œuvre incrémentielles et de migration du parc ........58
III.3.2.4. La constitution dans un cadre de composants standards ....................................58
III.3.2.5. La possibilité de mise en œuvre de nouveaux modèles informatiques ..............58
III.3.3. Une architecture orientée services : au-delà des services Web................................58
III.3.3.1. Les éléments constitutifs d’une architecture orientée services ..........................59
III.3.3.2. La nature d’un service ........................................................................................59
III.3.3.3. L’intégration d’applications ...............................................................................60
III.3.3.4. Les exigences d’intégration au sein de l’architecture ........................................61
a. L’intégration au niveau de l’interface .......................................................................62
b. La connectivité d’applications ..................................................................................62
c. L’intégration des informations ..................................................................................62
III.4. ARCHITECTURE PROPOSEE .................................................................................................63
III.4.1. Architecture orientée service (SOA) .........................................................................63
III.4.2. Difficultés rencontrées dans la réalisation d’une plate-forme collaborative complète
...............................................................................................................................................64
III.4.3. Vers l’intégration d’applications existantes .............................................................65
III.4.4. Architecture proposée ...............................................................................................66
III.5. CONCLUSION .....................................................................................................................68
CHAPITRE IV : EXPERIMENTATION................................................................................. 69
IV.1. INTRODUCTION ..................................................................................................................70
IV.2. LA PLATE-FORME SILVERPEAS ..........................................................................................70
IV.2.1. Présentation de la plateforme silverpeas ..................................................................70
IV.2.2. La Structure de Silverpeas.........................................................................................71
IV.2.2.1. Administration ...................................................................................................72
IV.2.2.2. Le Bus ................................................................................................................72
IV.2.2.3. Services ..............................................................................................................73
7
2010
TABLEAU DE MATIERES
IV.2.3. L’architecture de Silverpeas......................................................................................73
IV.3. LA PLATE-FORME XWIKI ...................................................................................................74
IV.3.1. Installation de Xwiki..................................................................................................75
IV.3.1.1. Configurer Tomcat .............................................................................................75
IV.3.1.2. Configurer MySQL ............................................................................................76
IV.3.1.3. Démarrer Xwiki .................................................................................................77
IV.3.2. Architecture de la plate-forme Xwiki ........................................................................78
IV.4. QUELQUES SCENARIOS DE TEST .........................................................................................78
IV.4.1. L’espace personnel....................................................................................................79
IV.4.2. Moteur de recherche..................................................................................................80
IV.4.3. Barre D’outils............................................................................................................80
IV.4.4. Page d’accueil ...........................................................................................................81
IV.4.5. Logo Silverpeas .........................................................................................................81
IV.4.6. Espaces et Services....................................................................................................81
IV.5. LES SERVICES DE LA PLATE-FORME ...................................................................................81
IV.5.1. Attribution des Rôles .................................................................................................82
IV.6. CREER UN ESPACE OU UN SOUS ESPACE .............................................................................82
IV.7. OUVRIR XWIKI ..................................................................................................................83
IV.8. CONCLUSION .....................................................................................................................84
CONCLUSION............................................................................................................................ 86
RÉFÉRENCES ............................................................................................................................ 89
ANNEXE ...................................................................................................................................... 91
8
2010
LISTE DES FIGURES
Liste des figures
Figure I-1 : Représentation d’un livre en xml .......................................................................... 19
Figure I-2 : Structure d’un message SOAP.............................................................................. 20
Figure I-3 : Définition du type d’enveloppe SOAP ................................................................. 22
Figure I-4 : Spécification d’un Service Web avec WSDL ....................................................... 23
Figure I-5 : Cycle de vie de service Web ................................................................................. 25
Figure I-6 : Illustration de l'orchestration................................................................................. 29
Figure I-7 : Vue générale de l'orchestration ............................................................................. 29
Figure I-8 : Illustration de la Chorégraphie............................................................................. 31
Figure I-9 : Vue générale d’une composition de services Web de type chorégraphie............. 31
Figure I-10 : Langages de coordination de Web services ........................................................ 33
Figure I-11 : Mise en œuvre des deux types de processus (exécutable et abstrait) par BPEL4WS
............................................................................................................................ 36
Figure I-12 : Exemple de code source...................................................................................... 37
Figure II-1 : Architecture Générale de Sakai ........................................................................... 41
Figure II-2 : Open-Xchange ..................................................................................................... 43
Figure II-3 : Interface Silverpeas. ............................................................................................ 44
Figure II-4 : Interface Xwiki. ................................................................................................... 51
Figure III-1 : Le problème d’intégration .................................................................................. 57
Figure III-2 : L’intégration d’applications ............................................................................... 61
Figure III-3 : L’intégration des services................................................................................... 61
Figure III-4 : Exemple d’interaction simple entre une application cliente et un service Web. 66
Figure III-5 : L’architecture générale de la plate-forme .......................................................... 67
Figure IV-1 : Présentation de Silverpeas.................................................................................. 71
Figure IV-2 : Structure de Silverpeas....................................................................................... 72
Figure IV-3 : Architecture de Silverpeas. ................................................................................ 74
Figure IV-4 : Ouverture de serveur Tomcat............................................................................. 75
Figure IV-5 : La page d’administration Tomcat. ..................................................................... 76
Figure IV-6 : Fichier Hibernate................................................................................................ 76
Figure IV-7 : Page d’ouverture de Xwiki................................................................................. 77
Figure IV-8 : La page d’accueil par défaut de Xwiki .............................................................. 77
Figure IV-9 : L’architecture de la plate-forme Xwiki.............................................................. 78
Figure IV-10 : La fenêtre d’accueille de l’application............................................................. 79
Figure IV-11 : Rubriques de l’espace personnel...................................................................... 79
Figure IV-12 : Barre d’outils.................................................................................................... 81
Figure IV-13 : Liste des services disponibles .......................................................................... 81
Figure IV-14 : Création d’un espace ou d’un sous-espace....................................................... 83
Figure IV-15 : Espace université badji mokhtar annaba. ......................................................... 83
Figure IV-16 : le lien de service wiki....................................................................................... 84
Figure IV-17 : Service Wiki de la plate-forme ........................................................................ 84
9
2010
INTRODUCTION
INTRODUCTION
Mémoire de Magister 2010
10
Chemame Chaouki
« Implémentation d’une infrastructure collaborative asynchrone basée sur les services web »
INTRODUCTION GENERALE
Introduction Générale
Problématique abordée
Face aux nouveaux défis à relever, l'information, la connaissance et le savoir-faire
constituent des ressources stratégiques et opérationnelles indispensables pour permettre aux
diverses organisations d'assurer une croissance pérenne. Le développement et l'exploitation
des connaissances requièrent alors de déployer des dispositifs organisationnels et techniques
(réseaux informatiques et les technologies de l’information et de la connaissance) permettant
à la fois leur mémorisation, leur partage, leur production collective et leur diffusion au plus
près des acteurs concernés.
Autour de ces technologies, le management des " communautés de pratiques " prend
une importance considérable, en définissant des nouvelles formes de coordination au sein ou
entre les organisations, mais en offrant également des outils facilitant la communication et les
échanges, tels que les services de collaboration asynchrones. Nous pouvons citer à titre
d’exemple :
¾
Forum : ce service permet l’organisation et le suivi de forums de discussion sur
l’ensemble de l’entreprise ou au niveau d’un espace collaboratif.
¾
Gestion de projet : ce service permet au chef de projet d’allouer des tâches aux
membres de son équipe et faire le suivi de l’évolution du projet. Chaque participant peut
gérer ses propres tâches tout en visualisant le travail réalisé par les autres membres de
l’équipe.
¾
Quizz : le service Quizz permet d’évaluer le niveau de connaissance acquis par
l’audience visée et de faire un suivi des formations. Ce service est instanciable dans
l’espace entreprise mais également dans chaque espace collaboratif. Il peut être utilisé
pour des tests de vérification des connaissances.
¾
Le service Gallery : permet de gérer et d’afficher des fichiers de type images dans une
arborescence d’albums. La publication d’images est facilitée grâce à l’utilisation du
glisser/déposer qui accepte un/plusieurs fichier(s), un/plusieurs répertoire(s) mais aussi
un fichier zip. Gallery permet de classer et d’afficher des images (photos, logos,
plans…etc) dans des albums.
Faire interagir ces différentes applications en réseau a toujours été une affaire
complexe, notamment si on souhaite standardiser certains aspects de cette interaction.
11
2010
Pour résoudre ce problème on fait appel à un ensemble de protocoles qui permettent,
au moins de faire communiquer (avec un protocole de haut niveau) des programmes tournant
sur des machines différentes et écrits dans des langages de programmation différents. Ils le
font en reprenant certains principes du Web (transport sur HTTP, formatage en XML) mais en
mettant l’accent sur la communication entre applications, pas entre humains en se basant sur
une architecture orientée services.
Objectif du mémoire
On a deux principaux objectifs dans notre mémoire, le premier objectif, est ainsi de
proposer une infrastructure collaborative intégrant et offrant des services de collaboration
asynchrones en se basant sur les nouvelles technologies orientées services.
Notre deuxième objectif est de mettre en œuvre cette infrastructure en proposant une
approche qui se base sur l’intégration d’applications déjà existantes en utilisant des services
web. De nombreux travaux se sont déjà focalisés sur cette problématique : les plates-formes
collaboratives à base d’intégration. Notamment dans le domaine des applications reparties, où
le spectre va vers des solutions à base d’intergiciels (tel que CORBA, et les langages de
composition des services web) à l’utilisation de nouvelles technologies des services web.
Plan du mémoire
Le mémoire est structuré en quatre chapitres, plus cette introduction et une conclusion
générale et perspectives.
Dans le premier chapitre, intitulé « Architecture Des Services Web », se compose de
deux parties, dans la première partie, nous présentons la définition, la description et les
principales technologies de développement des services web. Dans la deuxième partie, nous
présentons les différents types de composition de service web et nous terminons par la
présentation d’un ensemble des langages de composition des services web les plus utilisés
actuellement.
Dans le deuxième chapitre, intitulé « Les Plates-Formes Collaboratives », nous présentons
un état de l’art de notre problématique de recherche, nous introduisons des concepts
fondamentaux sur la collaboration et la coopération, afin de présenter le contexte de nos travaux.
Dans ce contexte, nous abordons la problématique liée au développement d’applications
collaboratives, nous présentons les différents outils de collaboration ainsi que quelques platesformes collaboratives que nous avons testé tout au long de notre travail, pour pouvoir concevoir
une plate-forme qui se base sur une approche d’intégration basée sur des frameworks.
12
2010
Dans le troisième chapitre intitulé « Architecture Proposée », on fait une présentation
générale de l’architecture orientée service, et l’outil open source afin de pouvoir proposer une
architecture ou bien une infrastructure collaborative basée sur ce type de technologies. Nous
présentons aussi notre propre architecture basé sur une architecture web service et qui englobe
plusieurs technologies :
¾
L’utilisation d’outils open source.
¾
L’utilisation d’une architecture orientée service.
¾
la notion d’intégration d’applications.
Dans le dernier chapitre, intitulé « Expérimentation », et dans le but de valider notre
approche nous optons pour l’intégration de deux plates-formes libres afin d’offrir à une
communauté d’utilisateurs un environnement collaboratif proposant des outils de
collaboration asynchrones dans un domaine bien précis. La première plate-forme s’appelle
« Silverpeas » qui se base sur une architecture orienté service, elle offre à l’utilisateur via une
interface riche un ensemble de services asynchrones (forum, enquête, annuaire, …etc). La
deuxième plate-forme s’appelle « XWIKI », c’est une plate-forme de la famille des systèmes
de gestion de contenu de site web rendant les pages web modifiables par tous les visiteurs y
étant autorisés. Il facilite l'écriture collaborative de documents avec un minimum de
contraintes.
Nous terminons notre contribution par une conclusion générale et perspectives où nous
présentons les principaux résultats et nous proposons quelques perspectives à développer dans
le prochain futur.
13
2010
CHAPITRE I
ARCHITECTURE DES SERVICES WEB
CHAPITRE I. ARCHITECTURE DES
SERVICES WEB
14
Chemame Chaouki
CHAPITRE I
Partie 1 : Architecture Des Services Web
I.1. Introduction
L'accès aux systèmes d'information s'appuie aujourd'hui de plus en plus sur des
technologies de l’Internet. Les efforts de standardisation dans ce contexte ont accentué
l'engouement des personnes et des organisations (aussi bien académiques, qu'industrielles,
commerciales, ou institutionnelles) pour l'utilisation de l'Internet et ont permis l'émergence
des services Web comme support de développement des applications accessibles par Internet.
Ainsi, les technologies associées aux services Web sont devenues incontournables pour le
développement d'applications interagissant les unes avec les autres par le biais de l'Internet.
Nous proposons dans ce chapitre de faire un point sur le sujet des services Web.
L'objectif de la discussion est de traiter des aspects conceptuels des services aussi bien
que des aspects liés à leur implantation.
I.2. Services Web : définition et principes
Plusieurs définitions des services Web ont été mises en avant par différents auteurs.
Ci-dessous, nous citons une définition généralement acceptée et fournie par le
consortiumW3C
“A Web service is a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machine-processable
format (specifically WSDL). Other systems interact with the Web service in a manner
prescribed by its description using SOAP messages, typically conveyed using HTTP with an
XML serialization in conjunction with other Web-related standards” [1].
Une étude plus approfondie des points communs partagés par les différentes
définitions et par les usages qui sont faits des services Web, permet de dégager au moins deux
principes fondamentaux :
¾
Les services Web interagissent au travers d'échanges de messages encodés en XML.
¾
Les interactions dans lesquelles les services Web peuvent s'engager sont décrites au sein
d'interfaces. La définition W3C restreint la portée des interfaces des services Web aux
aspects fonctionnels et structurels, en utilisant le langage WSDL qui, essentiellement,
ne permet de décrire que des noms d'opérations et des types de messages
15
2010
CHAPITRE I
I.3. Description de services Web
Dans cette section nous discutons à la description des interfaces des services. Cette
description peut porter sur les aspects structurels et/ou comportementaux des services, aussi
bien que sur leurs aspects non-fonctionnels. Les langages présentés dans cette section sont
fondés sur XML (Extensible Markup Language), XML est un standard de représentation de
données semi-structurées [2].
Dans un document XML, la structure des données est fournie par le biais de
l'utilisation de balises (comme en SGML Standard Generalized Markup Language [3], mais
en s'affranchissant des aspects liés à la présentation des données). Cette structure n'est pas
aussi rigide que celle d'une base de données relationnelle par exemple. Dans un document
XML, les données peuvent être définies selon un schéma, mais cela n'est pas obligatoire et le
schéma peut laisser quelques parties partiellement spécifiées.
Une problématique généralement associée à la description de services est celle de leur
publication et de leur découverte. Un standard proposé pour s'attaquer à cette problématique
est UDDI [4]. UDDI définit une interface de programmation pour publier des descriptions de
services dans des répertoires dédiés, pour soumettre des requêtes à base de mots-clés sur ces
répertoires et pour naviguer au travers des descriptions obtenues par le biais de ces requêtes.
I.3.1. Description fonctionnelle et structurelle WSDL
WSDL (Web Services Description Language) est un langage de la famille XML
permettant de décrire les types de données supportés et les fonctions offertes par un service
Web. L'objectif est de fournir la description, en XML, des services indépendamment de la
plate-forme et du langage utilisés et sous une forme que des personnes ou des programmes
peuvent interpréter. Les descriptions WSDL sont en fait l'équivalent des interfaces IDL
(Interface Définition Language) de CORBA par exemple [5].
Dans le langage WSDL, un service est vu comme une collection de messages pour les
échanges et d'une collection de points d'entrée. Un point d'entrée consiste en la description
abstraite d'une interface et de son implantation. La description abstraite contient :
¾
la définition des messages qui sont consommés et générés par le service (les entrées et
les sorties)
¾
la signature des opérations offertes par le service.
16
2010
CHAPITRE I
I.3.2. Description comportementale
La portée de WSDL est limitée la description des types des données incluses dans les
messages qu'un service est capable de recevoir ou d'émettre. Dans de nombreuses
applications, ces descriptions uniquement structurelles n'offrent pas assez d'information sur
les contraintes régissant les interactions dans lesquelles un service peut ou est censé s'engager.
Dans certains cas, ces contraintes sont assez simples, comme par exemple : < le
fournisseur n'envoie le bordereau de livraison qu'après avoir reçu la confirmation du paiement
>. D'autres fois, ces contraintes peuvent être relativement complexes.
Plusieurs initiatives de recherche, de développement et de standardisation sont en
cours afin de définir des langages de description de services prenant en compte des aspects
comportementaux, et d'utiliser ces descriptions < comportementales >lors du développement
et de l'exécution des services.
BPEL est un langage fondé sur XML et permettant de décrire aussi bien des interfaces
comportementales que des orchestrations complètement exécutables. En quelques mots,
BPEL permet de décrire des actions communicationnelles (envois et réceptions de message
dont les types sont décrits en WSDL et XML Schéma), et de lier ces actions au travers
d'opérateurs de flot de contrôle (par exemple la séquence, le choix, l'itération, et les clauses
throw/catch pour le traitement des exceptions).
I.3.3. Description d'aspects non-fonctionnels < WS-Policy >
Les services Web étant généralement développés par des équipes indépendantes, ont
besoin d'être décrits de façon précise selon des conventions standards, et de telle manière que
leurs descriptions puissent être utilisées au maximum pour automatiser le processus de
développement et de déploiement des futurs services devant interagir avec un service existant.
WSDL et BPEL permettent de décrire les opérations fournies par un service Web, les types de
données des messages devant être échangés pour invoquer ces opérations, et les dépendances
comportementales entre ces opérations. Cependant, ils ne permettent pas de décrire des
aspects non-fonctionnels des services tels que leur capacité à garantir une certaine qualité de
service par rapport à des préoccupations telles que la sécurité, la fiabilité, la journalisation des
accès ou la gestion de transactions.
Ce manque est en partie compensé par le concept de politiques d'usage. Une politique
d'usage est une énonciation explicite des possibilités et des restrictions d'usage d'un service
Web. < WS-Policy >est un langage extensible permettant d'exprimer des politiques (ou règles)
d'usage sous forme de conjonctions et de disjonctions (au sens logique) d'assertions [6].
17
2010
CHAPITRE I
I.4. Les principales technologies de développement des Services Web
Une caractéristique qui a permis un grand succès de la technologie des services web
est qu'elle est construite sur des technologies standards de l’industrie. Dans cette section il y a
une description de ces technologies.
I.4.1. XML (Extensible Markup Language)
Le langage XML (Extensible Markup Language) est un langage balisé, issu d’une
recommandation W3C (WorldWideWeb Consortium), ayant pour but d’encoder tout type de
données, indépendamment du code machine de celles-ci. Il a été développé dans le but de
partager facilement des données entres différents systèmes et en particulier à travers un réseau
Internet.
I.4.1.1. XML un descendant de SGML
SGML (Standard Generalized Markup Language) est un métalangage avec lequel il est
possible de définir des langages balisés. Il est lui-même descendant de la recherche sur la
théorie des langages et en particulier du langage GML (Generalized Markup Language)
d’IBM. Il est devenu par la suite un standard ISO.
XML est un sous-ensemble simplifié du langage SGML (Standard Generalized
Markup Language) et est utilisé dans de nombreuses technologies ou protocoles tels que
(RDF, RSS, XHTML, Atom, MathML, ...etc). Tous les langages dérivés présentent le même
avantage : encoder de façon structurée l’information destinée à être partagée à travers un parc
d’ordinateurs et de logiciels hétérogènes.
En plus d’avoir donné naissance à XML, SGML est également à la base du langage de
balisage HTML, un des éléments clés d’Internet. Par contre, son petit frère, XHTML qui
hérite les propriétés de XML, d’où les similitudes entre ces différents langages [7].
I.4.1.2. Codage des données et interopérabilité
XML permet d’écrire sous forme de fichier texte, dont le codage est exprimé en entête, tous les types définis eux-mêmes par un autre fichier XML. Ainsi, grâce à ces deux
fichiers (l’un contenant les données, l’autre de description des types de données), n’importe
quel logiciel pouvant accéder à des fichiers texte peut analyser les données.
Ce type de technologie est une solution, très utilisée aujourd’hui, pour permettre
l’interopérabilité des logiciels à travers Internet. Il est vrai que la syntaxe XML est très
verbeuse, ce qui la rend difficilement lisible pour un humain : mais c’est le prix à payer pour
une compatibilité maximale et une description au mieux des données pour leur traduction
informatique.
18
2010
CHAPITRE I
Son succès est grandissant, et de nouvelles technologies apparaissent comme AJAX
par exemple, une technologie web basée sur la JavaScript, le XML et le XHTML, permettant
de travailler les données du côté client pour en envoyer une version complète au serveur sans
faire de requête entre chaque petite modification.
I.4.1.3. Utilisation des fichiers XML
Plusieurs méthodes permettent d’exploiter les données d’un fichier XML. Des
méthodes permettent d’accéder à la donnée précise en parcourant le chemin hiérarchique lié
au balisage du fichier : ce sont les technologies telles que le langage XPath. Il permet
d’exploiter le fichier sans devoir construire une représentation complète en mémoire du
fichier. D’autres technologies consistent à construire un arbre représentant le fichier XML
dans son entier, les nœuds de cet arbre étant les différentes balises XML. Cet arbre s’appelle
l’arbre DOM (Document Object Model). Une telle utilisation est difficilement concevable
pour accéder aux quantités de données stockées dans une base de données XML, mais est
totalement viable pour analyser un fichier de description simple de service web, par exemple.
Nous allons prendre un exemple simple pour visualiser graphiquement quelle serait la
hiérarchie du document XML correspondant et quelle est la structure du document.
L’exemple choisi est celui d’un livre (Figure I-1).
<Livre>
<titre>Le super livre</titre>
<chapitre>
<numéro>1</numéro>
<titre>titre du chapitre 1</titre>
<contenu>abcdef…</contenu>
</chapitre>
<chapitre>
</chapitre>
</Livre>
Figure I-1 : Représentation d’un livre en xml
XML possède une galaxie de technologies. Parmi celles-ci nous pouvons citer XML
Query (langage de requêtes), XSL – Extensible Stylesheet Language (définition de
présentations de documents XML), XSLT – XSL Transformations (langage permettant la
transformation de documents XML), XPath – XML Path (langage de requêtes permettant
d’accéder à chaque élément d’un document XML).
19
2010
CHAPITRE I
I.4.2. SOAP (Simple Object Access Protocol)
SOAP [8] est un protocole pour l’échange d’information dans un environnement réparti,
basé sur le standard XML. Ce protocole comporte trois parties : Une enveloppe qui définit un
canevas pour décrire le contenu du message, la façon de le traiter, un jeu de règles de codage
pour exprimer les types de données et une convention pour représenter des appels de procédure
éloignés. SOAP n’est lié à aucun système d’exploitation ni langage de programmation. Il est
indépendant du langage d’implémentation des applications client et serveur. En plus, il peut
potentiellement être utilisé avec une variété de protocoles (ex : HTTP, HTTP Extension
Framework).
I.4.2.1. Modèles d’échange de messages en SOAP
Les messages SOAP sont des transmissions fondamentalement à sens unique d'un
expéditeur à un récepteur. Lorsqu’une transmissions d’un message commence (ex : invocation
d’un service web), un message SOAP (ou document XML) est généré. Ce message est envoyé
à partir d’une entité appelé le SOAP sender, localisé dans un SOAP nœud. Le message est
transmis à zéro ou plusieurs nœuds intermédiaires (SOAP intermediates) et le processus fini
lorsque le message arrive au SOAP receiver. Le chemin suivi par un message SOAP est
nommé message path. La Figure I-2 montre les éléments qui participent au processus.
SOAP Message
SOAP Enveloppe
SOAP Header
SOAP Body
Nœud Serveur
Nœud Client
SOAP
Sender
Nœud Intermédiaire
SOAP
Receiver
Figure I-2 : Structure d’un message SOAP
Quand un message SOAP arrive dans une entité SOAP, il suit le processus décrit ci-dessous :
¾
Identifier toutes les parties du message SOAP destiné à cette entité.
¾
Vérifiez que ces parties sont soutenues par l’entité et traitez-les en conséquence. Si ce
n'est pas le cas rejeter le message.
20
2010
CHAPITRE I
¾
Si l’entité n'est pas la destination suprême du message, il faut enlever alors toutes les
parties identifiées avant l'expédition du message.
I.4.2.2. Enveloppe SOAP
Un message SOAP est composé d’un élément obligatoire appelé le SOAP enveloppe.
L’enveloppe SOAP définit l’espace de nom (Namespace : URI permettant de connaître la
provenance de chaque balise) précisant la version supportée de SOAP. Cet espace de nom est
standard et permet de différencier les éléments du schéma.
L’enveloppe SOAP est constituée d’un en-tête facultatif (SOAP header) et d’un corps
obligatoire (SOAP body). Une description générale de l’enveloppe SOAP et ses composants
est donnée par un extrait de code (Figure I-3).
I.4.2.3. En tête SOAP
L’en-tête peut avoir plusieurs fils (SOAP blocks). Ces fils sont utilisés pour ajouter
des fonctionnalités au message comme l’authentification et la gestion des transactions. L’entête peut utiliser les attributs mustUnderstand et/ou SOAP actor pour indiquer comment traiter
l'entrée et par qui.
L'attribut mustunderstand peut être utilisé pour indiquer si une entrée d’en-tête est
obligatoire ou facultative pour être traitée par le destinataire. Le destinataire d'une entrée
d’en-tête est défini par l'attribut d'acteur de SOAP. La valeur de l'attribut de mustunderstand
est "1" ou "0". L'absence de cet attribut est sémantiquement équivalente à sa présence avec la
valeur "0".
Un message SOAP voyage du SOAP sender au SOAP receiver, en passant par un
groupe de SOAP intermédiaires. Un SOAP intermédiaire est une entité qui est capable de
recevoir et transmettre les messages SOAP. Les nœuds intermédiaires aussi bien que le SOAP
receiver sont identifiés par une URL. L'attribut acteur de SOAP peut être utilisé pour indiquer
le destinataire d'un élément d'en-tête. La valeur de l'attribut d'acteur de SOAP est une URL.
I.4.2.4. Corps SOAP
Le corps SOAP contient l’information destinée au receveur. Il doit fournir le nom de
la méthode invoquée par une requête, ou le nom de la méthode pour générer la réponse. Il doit
aussi, fournir l’espace de nom correspondant au nom du service. Le contenu du corps SOAP
est utilisé dans le processus comme le marshaling d’appels RPC et le rapport des erreurs.
Le corps SOAP peut contenir un SOAP fault. Ce bloc est utilisé pour transmettre
l’information des erreurs durant le traitement du message.
21
2010
CHAPITRE I
Malgré que l'en-tête et le corps soient définis comme des éléments indépendants, ils
ont une relation : une entrée de corps est sémantiquement équivalente à une entrée d'en-tête
destinée pour l'acteur de défaut et avec une valeur d'attribut mustunderstand de 1 (Figure I-3).
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope/ ">
<env:Header>
<authentication xmlns=http://myDomain/app” >
<user>admin</user>
<password>********</password>
</authentication>
</env:Header>
<env:Body>
<stock: getStockQuoteResponse
xmlns: stock=”http://www.acme.com/service ”>
<stock_quote>
…
</stock_quote>
</stock: getStockQuoteResponse
</env:Body>
</env:Envelope>
Figure I-3 : Définition du type d’enveloppe SOAP
I.4.3. Apatche-Axis Une mise en œuvre de SOAP
Axis est essentiellement un moteur de SOAP, mais il inclut aussi :
¾
Un serveur autonome simple.
¾
Un serveur servlet comme Tomcat.
¾
Appui vaste pour WSDL.
¾
L'outillage d'émetteur (ex : WSDL2Java) qui produit des classes Java à partir du fichier
WSDL.
¾
L'outillage d'émetteur (ex : Java2WSDL) qui produit le fichier WSDL à partir de la
classe de l’interface Java.
¾
Un outil pour surveiller des paquets de TCP/IP [9].
22
2010
CHAPITRE I
I.4.4. WSDL (Web Service Description Language)
Le WSDL [10] est un langage qui permet de décrire les services web, et en particulier,
leurs interfaces. Ces descriptions sont des documents XML. WSDL décrit un service web en
deux étapes fondamentales : une abstraite et une concrète. Dans chaque étape, la description
utilise un nombre de constructions pour favoriser la réutilisation de la description et pour
séparer les préoccupations de conception indépendantes (voir Figure I-4).
Spécification WSDL
Partie abstraite
Types
Messages
Operations
Types de port
Partie concrète
bindings
Services et ports
Figure I-4 : Spécification d’un Service Web avec WSDL
Au niveau abstrait, WSDL décrit un service Web en termes des messages qu'il envoie
et reçoit; les messages sont décrits de façon indépendante d'un format spécifique en utilisant
un système de types, typiquement un schéma XML. La partie abstraite est composée de
définitions de "port type" qui sont analogues aux interfaces des "middleware" traditionnel.
Chaque "port type" est une collection logique d'opérations. Une "opération"
associe un
modèle d'échange de message à un ou plusieurs messages. Un message est une unité de
communication avec un service web. Il représente les données échangées dans une unique
transmission logique.
Un modèle d'échange de messages identifie l'ordre et la cardinalité des messages
envoyés et/ou reçus. Une interface groupe un ensemble d'opérations.
23
2010
CHAPITRE I
Au niveau concret, un "binding" indique des détails de format de transport pour une ou
plusieurs interfaces. Un "endpoint" (point final) associe une adresse de réseau à un "binding"
(attache). Finalement, un service groupe un ensemble d'endpoints qui implémente une
interface commune.
I.4.5. UDDI (Universal Description Discovery and Integration)
L’objectif primaire d'UDDI [8] est la spécification d'un canevas pour décrire et
découvrir des services Web. Le noyau d’UDDI travaille avec la notion de "business registry",
qui est un service sophistiqué de noms et répertoires. Plus précisément, UDDI définit des
structures de données et APIs pour publier les descriptions des services dans le registre et
pour interroger ce registre afin de chercher des descriptions publiées. Parce que les APIs
d’UDDI sont aussi spécifiés en WSDL avec une attache SOAP, le registre peut être invoqué
comme un service Web (en conséquence, ses caractéristiques peuvent être décrites dans le
même registre, comme un autre service).
Les spécifications du « registry » UDDI ont deux buts principaux en ce qui concerne
la découverte d'un service: le premier, soutenir les développeurs dans la découverte
d'informations sur les services. Le deuxième, permettre la liaison dynamique et en
conséquence habiliter les clients pour interroger le registre et obtenir des références aux
services d’intérêt.
I.5. Cycle de vie des services Web
¾
Chaque service Web est défini par un fournisseur. Le fournisseur de services déploie et
publie la description de son service dans des registres en vue d’être localisé par des
clients.
¾
Les clients localisent leurs besoins en terme de services en effectuant des recherches sur
les registres de services Web ;
¾
Une fois le service localisé, le client extrait sa description du registre ;
¾
Sur la base des informations définies dans la description du service, le client entreprend
une interaction (Figure I-5).
24
2010
CHAPITRE I
Figure I-5 : Cycle de vie de service Web
¾
SOAP : « assure la communication avec et inter services Web »
¾
WSDL : « offre un schéma formel de description des services Web »
¾
UDDI : « offre une manière uniforme de définir des registres des services Web et aussi
un schéma uniformément extensible de descriptions des services Web. »
Actuellement, SOAP, WSDL et UDDI sont les trois standards qui constituent
l’architecture Services Web. Ensemble, ils résolvent les problèmes de l’hétérogénéité des
systèmes pour l’intégration d’applications en ligne.
I.6. Avantages Des Services Web
Il y a trois caractéristiques qui ont réellement fait la différence et sont en grande partie
responsable du succès des services Web :
¾
Technologie basée sur des standards ouverts (XML).
¾
Loose Coupling ou le Découplage: Séparation nette entre les interfaces et les
implémentations. Une fois qu’un programme est publié en tant que service Web, il est
relativement simple de le déplacer grâce au fait que ces services constituent une couche
d’abstraction des fonctionnalités logicielles par rapport à l’interface.
¾
La disponibilité permanente: Utilisation universelle et abondance des outils
disponibles. La disponibilité permanente correspond aux capacités des services Web à
être actives et disponibles partout sur un réseau, ou un groupe de réseaux, sans aucuns
impacts quand à ses fonctionnalités.
25
2010
CHAPITRE I
I.7. Limites des services Web
Les services Web présentent quelques inconvénients :
¾
Service sans état (Stateless Service).
¾
Comportement orienté objet.
¾
Orientation client/serveur.
¾
Aucune adaptation à l’utilisateur.
¾
Aucune mémoire.
¾
Aucune gestion de vie.
¾
Aucune conversation (interaction requête/réponse simple).
¾
Communication synchrone.
¾
Pas plus que des appels à des procédures à distance passifs.
26
2010
CHAPITRE I
Partie 2 : Composition Des Services Web
Dans cette partie, nous présentons dans un premier temps les définitions et les types de
composition de services Web présents dans la littérature. Ensuite, nous étudions quelques
langages de composition de services Web.
I.8. Définitions et types de composition de services Web
Cette section a pour but d’exposer, d’une part, l’ensemble des définitions et objectifs
de la composition de services selon différents points de vue rencontrés dans la littérature, et,
d’autre part, les différents types de composition.
I.8.1. Définitions
La composition de services Web est un moyen efficace pour créer, exécuter, et
maintenir des services qui dépendent d’autres services. Le cycle de vie d’une composition de
services Web reposant à partir de six activités [11].
I.8.1.1. L’encapsulation de services natifs
Cette première activité permet de s’assurer que tout service peut être appelé lors d’une
composition, indépendamment de son modèle de données, de son format de message, et de
son protocole d’interaction.
I.8.1.2. L’établissement d’accord d’externalisation
Cette seconde activité consiste à négocier, établir, et appliquer des obligations
contractuelles entre les services.
I.8.1.3. L’assemblage de services composants
Cette activité permet de spécifier, à un haut niveau d’abstraction, l’ensemble des
services à composer afin d’atteindre l’objectif attendu. Cet assemblage comporte une phase
d’identification des services et de spécification de leurs interactions conformément aux
descriptions et aux accords entre services.
I.8.1.4. L’exécution de services composants
Cette activité consiste en l’exécution des spécifications de la composition
précédemment définies.
I.8.1.5. Le contrôle de l’exécution de services composites
La phase de contrôle permet de superviser l’exécution de la composition en vérifiant,
par exemple, l’accès aux services, les changements de statut, les échanges de messages. Ce
contrôle permet de détecter des violations de contrats, de mesurer les performances des services
appelés et de prédire des exceptions.
27
2010
CHAPITRE I
I.8.1.6. L’évolutivité des services
Cette dernière phase permet de faire évoluer la composition en modifiant les
altérations de l’organisation de services, en utilisant de nouveaux services, ou en prenant en
compte les retours de la phase de contrôle.
I.8.2. Types de composition de services Web
La plupart des travaux portant sur la composition de services Web reconnaissent deux
types de composition : l’orchestration et la chorégraphie de services. Cependant, selon les
travaux, les définitions des types de composition diffèrent.
¾
l’orchestration et la chorégraphie sont des moyens de concevoir la composition [12].
¾
tandis que l’orchestration et la chorégraphie sont des points de vue de la composition de
services [13].
I.8.2.1. Orchestration
L’orchestration est un ensemble de processus exécutés dans un ordre prédéfini afin de
répondre à un but [13]. Ce type de composition permet de centraliser l’invocation des services
Web composant. Chaque service est décrit en termes d’actions internes. Les contrats entre
deux services sont constitués selon le processus à exécuter.
L’orchestration est un ensemble d’actions à réaliser par l’intermédiaire de services
Web. Un moteur d’exécution, un service Web jouant le rôle de chef d’orchestre, gère
l’enchaînement des services Web par une logique de contrôle. Pour concevoir une
orchestration de services Web, il faut décrire les interactions entre le moteur d’exécution et les
services Web. Ces interactions correspondent aux appels, effectués par le moteur, d’action(s)
proposée(s) par les services Web composants [13].
L’orchestration de services Web consiste en la programmation d’un moteur qui
appelle un ensemble de services Web selon un processus prédéfini. Ce moteur définit le
processus dans son ensemble et appelle les services Web (tant internes qu’externes à
l’organisation) selon l’ordre des tâches d’exécution. La Figure I-6 illustre l’exécution du
moteur (lui-même un service Web – Service Web Moteur) permise par l’enchaînement de
l’exécution de deux autres services Web (le Service Web 1 puis le Service Web 2).
Cet enchaînement est possible via un opérateur d’ordonnancement (représenté par le
losange). L’exécution de la composition repose sur l’appel du Service Web 1, puis sur l’appel
du Service Web 2, réalisés tous deux par le Service Web Moteur [12].
28
2010
CHAPITRE I
Service
Web
Moteur
Service
Web1
Service
Web2
Figure I-6 : Illustration de l'orchestration
SW2
SW1
1° appel
Client
2° appel
Moteur
4° appel
SW4
3° appel
SW3
Légende
Requête
Résultat de la requête
Figure I-7 : Vue générale de l'orchestration
29
2010
CHAPITRE I
L’orchestration peut être vue comme une composition ascendante : les services Web
utilisés dans la composition existent au préalable et sont appelés selon un enchaînement
prédéfini afin de réaliser un processus précis. La Figure I-7 illustre l’orchestration. La requête
du client (logiciel ou humain) est transmise au moteur d’exécution (Moteur). Ce dernier,
d’après le processus préalablement défini, appelle les services Web (ici, SW1, SW2, SW3 et
SW4) selon l’ordre d’exécution.
I.8.2.2. Chorégraphie
La chorégraphie permet de décrire la composition comme un moyen d’atteindre un but
commun en utilisant un ensemble de services Web [12]. La collaboration entre chaque service
Web de la collection (faisant partie de la composition) est décrite par des flots de contrôle. Le
fait que la chorégraphie mette en oeuvre un ensemble de services Web afin d’accomplir un
but commun [14].
Pour concevoir une chorégraphie, les interactions entre les différents services doivent
être décrites. La logique de contrôle est supervisée par chacun des services intervenant dans la
composition. L’exécution du processus est alors distribuée.
La description de chaque service Web intervenant dans la chorégraphie inclut la
description de sa participation dans le processus. De ce fait, ces services peuvent collaborer à
l’aide de messages échangés afin de savoir si tel ou tel service peut aider dans l’exécution de
la requête [12].
Chaque service Web peut communiquer avec un autre service Web par l’intermédiaire
d’échange de messages. La
Figure I-8 représente un protocole d’initiation de collaboration entre deux services dans
le cadre d’une chorégraphie. Dans cet exemple, le Service Web 1 demande l’exécution d’une
méthode du Service Web 2 par l’intermédiaire d’un envoi de message (Requête de service).
Cette requête est acceptée par le service Web 2. Ce dernier envoi un message
d’acceptation au Service Web 1 (Acceptation). Le Service Web 1 accepte le service proposé
par le Service Web 2 en lui envoyant un message (Service admis) accordé (Acceptation) par
ce second service. Une fois ces messages échangés le Service Web 1 peut invoquer les Service
Web 2 dans le cadre de la composition.
30
2010
CHAPITRE I
Service Web 1
Requête de service
Acceptation
Service admis
Acceptation
Service Web 2
Figure I-8 : Illustration de la Chorégraphie
La chorégraphie est aussi appelée composition dynamique [12]. En effet, l’exécution
n’est pas régie de manière statique comme dans une composition de type orchestration. Dans
une chorégraphie, à chaque pas de l’exécution (à chaque étape de la composition), un service
Web choisit le service Web qui lui succède et implémente ainsi une partie de la chorégraphie.
La composition de type chorégraphie n’est pas connue, ni décrite à l’avance (Figure I-9).
SW1
SW2
SW4
SW3
Client
Légende
Requête
Résultat de la requête
Echange de messages
Envoi du résultat du SW
Figure I-9 : Vue générale d’une composition de services Web de type chorégraphie
31
2010
CHAPITRE I
Cette figure (Figure I-9) permet d’illustrer une vue générale d’une composition de
services Web de type chorégraphie. Le client (logiciel ou humain) établit une requête qui est
satisfaite par l’exécution automatique de quatre services Web (SW1, SW2, SW3 et SW4). La
requête de l’utilisateur est transmise au premier service Web (SW1) qui est exécuté. Le SW1
découvre ensuite le service Web lui succédant. Le processus de découverte repose, selon les
cas, soit sur une recherche dans un registre local ou public, soit sur une découverte globale sur
le Web à l’aide d’ontologies. Une fois le service découvert, les deux services (SW1 et SW2)
échangent des messages (comme illustré par la Figure I-9) afin de vérifier si leur
communication est viable dans le cadre de la requête. Si les échanges de messages sont
concluants, le résultat de l’action du SW1 est transmis au SW2 qui l’utilise comme paramètre
d’entrée. Le processus d’implémentation de la composition est identique pour chaque étape
(SW2 et SW3). Le SW4 termine le processus et le résultat de son action est transmis au client.
I.8.3. Langages de composition de services Web
De nombreux industriels (tels qu’IBM ou Microsoft) et consortium (tel que le W3C)
travaillent afin de mettre en œuvre un langage de composition de services Web standard (tel
que WSCI – Web Service Choreography Integration [15]). Dans cette section, nous étudions
les langages qui sont soit largement utilisés dans l’industrie (BPEL4WS), soit en cours de
standardisation (WS-CDL et OWL-S). Pour chaque langage étudié, nous indiquons l’origine
du travail, les bases théoriques sur lesquelles le langage est construit et une illustration de la
description d’une composition de services.
Depuis la naissance des termes Orchestration et Chorégraphie, de nombreux langages
de coordination de Web services sont apparus. Certains de ces langages étaient plutôt centrés
sur l’orchestration, d’autres plutôt sur la chorégraphie, représentés sur la (Figure I-10) dans
l’ordre chronologique d’apparition sur le marché:
¾
XLANG XML Business Process Language (Microsoft).
¾
BPML Business Process Modeling Language (BPMI).
¾
WSFL Web Service Flow Langage (IBM).
¾
WSCL Web Service Conversation Language (Hewlett-Packard).
¾
WSCI Web Service Choregraphy Interface (SUN).
¾
BPEL4WS-Business Process Execution Language for Web Services (IBM, Microsoft,
BEA).
¾
WS-CDL Web Services Choreography Description Language (effort du W3C).
32
2010
CHAPITRE I
Figure I-10 : Langages de coordination de Web services
I.8.3.1. XLANG (XML Business Process Language)
Le langage XLANG est une extension de la spécification WSDL. Elle fournit en même
temps un modèle pour une orchestration des services et des contrats de collaboration entre
celles-ci.
Les actions sont les constituants de base d'une définition de processus de XLANG. Le
fichier de description de service XLANG contient donc la description WSDL, et y ajoute les
deux autres genres d'action: arrêts (date-limite et durée) et exceptions [16].
I.8.3.2. BPML (Business Process Modeling Language)
Le BPML est un langage de modélisation des processus métiers. Il gère la
coordination de toute sorte de participants, et non pas de Web services uniquement [17].
Les processus métiers sont représentés par un flux de données, un flux d'événements
sur lesquels on peut influer en définissant des règles métier, des règles de sécurité, des règles
de transactions.
On peut ensuite lancer l'exécution du modèle et vérifier le fonctionnement théorique
des différents processus.
I.8.3.3. WSFL (Web Service Flow Language)
WSFL est un langage basé sur XML pour la description des Web services composite.
Il permet de décrire :
¾
L’enchaînement des appels d’opérations de Web services.
¾
Les
interactions
entre
deux
Web
services,
en
explicitant
les
relations
"producteur/consommateur de messages" entre leurs descriptions WSDL. Cette
description est abstraite, basée sur les deux fichiers WSDL, en laissant les Web services
"en blanc" afin de les implémenter plus tard [16].
33
2010
CHAPITRE I
I.8.3.4. WSCL (Web Service Conversation Language)
WSCL est un langage XML, il se charge uniquement de d´écrire les interactions entre
les couples de Web services sans spécifier comment est crée le contenu des messages
échangés [18].
WSDL permet de décrire les Web services, et WSCL se charge de décrire les
conversations entre deux Web services. Ainsi, ces deux descriptions sont séparées, afin de
permettre la réutilisation [17].
Le langage de conversation WSCL ne s’occupe que de la description de conversations
entre paires de Web services. Il est donc plus léger que WSCI qui décrit des conversations
entre plusieurs Web services, et non pas seulement entre deux Web services. Mais
contrairement à WSCI, WSCL utilise une forme de procédé pour décrire la conversation, et
l’exécution de la conversation n’est pas centralisée. C’est un langage de chorégraphie.
I.8.3.5. WSCI (Web Service Choreography Interface)
WSCI est un langage de description basé sur XML, il décrit l’interface du Web service
participant à un échange donné de message (la chorégraphie de messages) [19].
« WSCI est un langage XML, permettant de décrire la chorégraphie entre les Web services.
Ainsi, les interfaces statiques des Web services sont décrites en WSDL, et la chorégraphie
entre eux est décrite en WSCI »[17].
Le langage WSCI permet de décrire les interfaces de Web services pour réaliser une
chorégraphie. Ce langage offre une vision différente de la collaboration, qui prend une forme
de conversation entre plusieurs Web services. La collaboration se passe alors d’une manière
décentralisée en utilisant plusieurs procédés distribués plutôt qu’un procédé principal.
I.8.3.6. BPEL4WS
BEA, IBM, SAP, Siebel Systems et Microsoft ont uni leurs efforts afin de produire un
langage de composition de services Web, conçu pour supporter les processus métier à travers
les services Web.
Ce langage, BPEL4WS (Business Process Execution Language for Web Services), est
issu de la fusion de deux langages : WSFL – Web Service Flow Language [20] d’IBM et
XLANG de Microsoft. BPEL4WS combine les caractéristiques d'un langage de processus
structuré par bloc (XLANG) avec ceux d'un langage de processus basé sur les processus
métier (WSFL). BPEL4WS est basé sur XML et sur les workflows. Ce langage distingue les
processus abstraits des processus exécutables [21].
34
2010
CHAPITRE I
a. Le processus abstrait
Ce processus spécifie les messages échangés entre les différentes parties (services Web
composants) sans indiquer le comportement de chacune d’elles.
Business Protocol, c'est-à-dire la spécification du comportement des partenaires par
rapport aux messages échangés, sans rendre public le comportement interne [22]. Ce
processus abstrait peut être relié à une composition de type chorégraphie. Les services Web
communiquent alors à l’aide d’échanges de messages (partie gauche de la Figure I-11).
b. Le processus exécutable
Ce processus permet de spécifier l’ordre d’exécution des activités, le partenaire
concerné, les messages échangés entre ces partenaires, et les mécanismes des erreurs et des
exceptions. En d’autres termes, il s’agit du moteur de l’orchestration donnant une
représentation indépendante des interactions entre les partenaires.
La Figure I-11 illustre la mise en œuvre des deux types de processus (exécutable et
abstrait) par BPEL4WS. La définition du processus métier est donnée par le processus
exécutable. Les processus abstraits gèrent les invocations entre les différents services Web
(WS) permettant l’exécution de la composition de services définie dans le processus
exécutable.
Trois éléments permettent à BPEL4WS de gérer le flot de processus dans le processus
exécutable :
Les transactions (Exception handling and transactions), les partenaires (Roles and
Partners) et les espaces de stockage (Persistance and Containers) (Figure I-11).
¾
Les transactions : Les transactions sont utilisées dans BPEL4WS pour gérer les
erreurs et les appels d’autres services si le service appelé est indisponible ou défaillant.
¾
Les partenaires : Les partenaires sont différents services Web invoqués dans le
processus. Ils ont chacun un rôle spécifique dans un processus donné. Chaque partenaire
est décrit par son nom, son rôle (en tant que service indépendant), et son rôle dans le
processus. Dans la Figure I-12, présentant la définition d’un processus exécutable en
BPEL4WS, nous pouvons voir les définitions de deux partenaires (des lignes 2 à 11). Le
fait de décrire deux niveaux de rôle permet à chaque partenaire d’avoir une vie
indépendante des compositions dans lesquelles il intervient.
35
2010
CHAPITRE I
¾
Les espaces de stockage : Les espaces de stockage permettent la transmission des
données. Le flot de processus BPEL4WS permet que ces données soient cohérentes à
travers les messages échangés entre les services Web. Un message peut être un message
d’appel (invoke), de réponse (reply) ou d’attente (receive).
Figure I-11 : Mise en œuvre des deux types de processus (exécutable et abstrait) par
BPEL4WS
La structure des différentes activités peut être, soit séquentielle (Sequential flow), soit
parallèle (Parallel flow). Si l’activité est parallèle, alors plusieurs services peuvent être
invoqués en même temps.
36
2010
CHAPITRE I
Figure I-12 : Exemple de code source.
I.8.3.7. WS-CDL (Web Services Choreography Description Language)
Le langage de description de chorégraphies de Web services, WS-CDL est un effort du
W3C ayant pour objectif d’apporter un langage reflétant des collaborations pair-à-pair (P2P)
entre services. C’est un langage basé sur XML définissant, selon un point de vue global, le
comportement observable commun et complémentaire des services, dont le résultat est
l'accomplissement d'un processus métier[23].
En WS-CDL, seules les interactions entre deux Web services sont considérées. La
description qui en découle prend la forme d'un processus dont l'exécution est effectuée de
manière décentralisée, comme une chorégraphie. La description des interactions est
indépendante des environnements d'exécution des services impliqués. Une définition globale
des conditions et des contraintes selon lesquelles les messages sont échangés est donnée par le
biais d'un contrat que chaque partenaire doit respecter [24] .
I.9. Conclusion
Dans ce chapitre, nous avons mis en relief les différents langages proposés par le
consortium W3C permettant aux fournisseurs de décrire leurs services Web. Cette étape de
description est le premier processus indispensable (après l’implémentation du service) dans le
cycle de vie d’une application basée sur une AOS (Architecture Orientée Service).
37
2010
CHAPITRE II
LES PLATES FORMES COLLABORATIVES
CHAPITRE II. LES PLATES FORMES
COLLABORATIVES
38
Chemame Chaouki
LES PLATES-FORMES COLLABORATIVES
CHAPITRE II
II.1. Introduction
Le Groupware, ou logiciel de travail en groupe, ou logiciel collaboratif, désigne une
catégorie des logiciels conçus pour une utilisation en réseau par plusieurs individus faisant
partie d'une même équipe de travail ou amenés à travailler ensemble [25].
Cependant un grand nombre de ces outils a été conçu dans le but évident de faciliter la
tache aux personnes qui travaillent en réseau
mais il est extrêmement rare que les
développeurs de logiciels ou d’outils de communication consultent des utilisateurs pour
s’assurer de répondre à l’ensemble des besoins de toutes les clientèles c’est la raison qui nous
incite à développer l’outil de travail qui répond à nos propre besoins a l'aide des plateformes
collaboratives open source.
II.1.1. Les Outils Synchrones
Se sont des outils de collaboration qui s’utilisent en temps réel entre des personnes
situées à des endroits différents. La communication à distance entre les interlocuteurs se fait
donc un peu comme au téléphone c’est-à-dire en temps réel. Le but de ce type de
communication est d’échanger des informations le plus rapidement possible pour décider de
la suite des événements ou encore de réunir différentes personnes pour les informer en même
temps de certaines informations à consigner (Exemple : réunions, cours). Parmi ces types
d’outils de collaboration synchrones, on peut citer : la vidéoconférence, la téléphonie par
Internet, la séance de clavardage, l’utilisation de tableau partagé ou (« whiteboard »).
II.1.2. Les Outils Asynchrones
Ces outils sont utilisés dans le web mais à des moments différents dans le temps. Ces
outils, à temps différé, permettent une communication en continu sans tenir compte des
obstacles liés à l’espace et au temps. (Exemple : La messagerie électronique, le forum de
discussion, les listes de diffusion, les journaux Web (type blogue, wiki, portails et les outils de
transfert de fichiers).
II.2. Définition de travail collaborative
Dans la littérature scientifique il y a quelques nuances entre le « travail coopératif » et
« travail collaboratif ». Le travail coopératif implique une division du travail entre les
participants, chaque participant étant responsable d’une partie du problème à résoudre. Dans
le travail collaboratif, les participants s’engagent tous dans les mêmes tâches, en se
coordonnant, afin de résoudre le problème ensemble. Cette distinction n’est pas toujours
pertinente, il n’est pas toujours facile de différencier les deux [26].
39
2010
CHAPITRE II
Le travail collaboratif [27], appelé à l'origine travail coopératif (ou Computer upported
Cooperative Work), correspond à l'utilisation d'ordinateurs en réseau pour le travail des
groupes d'utilisateurs. Pour clarifier nos propos, deux citations très générales définissent bien
le domaine des systèmes collaboratifs:
¾
Première citation est donnée par [28] : « Système à base d'ordinateurs qui supporte
des groupes de personnes réalisant en commun une tâche ou un but et qui fournit une
interface pour accéder à un environnement commun ».
¾
Deuxième citation est donnée par [29] : « Système informatique qui facilite la
résolution de problèmes par un ensemble de décideurs travaillant en groupe ».
Donc un système collaboratif est un système informatique qui regroupe plusieurs
utilisateurs répartis au sein de différents groupes. Ce système facilite la prise en charge
d’activités commune aux membres d’un groupe et fournit une interface pour un
environnement partagé.
II.3. Catégorie des systèmes collaboratifs
Les systèmes collaboratifs actuels sont principalement répartis suivant deux catégories
: les collecticiels et les systèmes de Workflows [30].
II.3.1. Les collecticiels
Le collecticiel (ou groupware) désigne tous les produits logiciels, outils, services ou
plates-formes, conçus pour des groupes d'utilisateurs. Le collecticiel représente la technologie
qui met en œuvre cette coopération en exploitant les progrès marqués par les technologies
d'information dans le domaine des réseaux, mais aussi dans les domaines du matériels et du
logiciels. Toutes les technologies qui mettent en œuvre la communication et le partage
d'information ont aussi une place importante dans cette technologie (groupware) qui peut être
définie comme étant tout système aidant les individus à coopérer au sein d'un groupe en vue
d'atteindre des objectifs communs [6].
II.3.2. Le Workflow
Le workflow se joint à la définition des rôles et à l'exécution des tâches inhérentes aux
activités du processus. Au-delà, le workflow s’étend à la gestion des mécanismes de
coordination et de coopération entre les différents acteurs d'un processus. Dans toutes les
organisations, la division du travail et le mécanisme de coordination qui lui sont sous-jacents,
reposent sur de nombreux procédés structurés et prédéfinis. A cet effet, le workflow recouvre
tous les processus de travail prédéfinis pour lesquels il est possible de formaliser des règles de
gestion et de coordination.
40
2010
CHAPITRE II
Ces règles sont ensuite implémentées dans un système de gestion de workflow qui
permet d’améliorer les performances en qualité des produits, des services fournis, de réduire
les coûts et les délais au niveau de nombreux processus.
II.4. Les principaux plates-formes existantes
II.4.1. SAKAI
Sakai [30] est un environnement collaboratif open source lancé en 2004 par quatre
universités américaines avec pour objectif de consolider leurs développements en matière de
plateforme d’apprentissage. Chacune de ces universités, soit Indiana University,
Massachusetts Institute of Technology (MIT), Stanford University et University of Michigan
utilisaient des systèmes de gestion de cours différents, souvent développé à l’interne. A ce
groupe s’est joint des membres de Uportal ainsi du projet OKI (Open Knowledge Initiative).
Sakai est développé en Java et utilise plusieurs technologies issues de J2EE. Il est construit
sur des frameworks et librairies libres tels que Spring, Hibernate, log4j et Jakarta Common.
Sakai permet la mise en place d’une architecture orientée service (SOA) en offrant la
possibilité d’interconnecter les différents composants à l’aide des services Web (Figure II-1).
Figure II-1 : Architecture Générale de Sakai
Sakai se décompose en trois composants principaux : les outils, les services et le Framework.
¾
Les outils : correspondent aux fonctionnalités présentées aux utilisateurs (barres de
navigation, texte de présentation, forum de discussion, calendrier,…). Seuls les outils
génèrent du contenu graphique. Les contenus qu’ils présentent sont accédés via les services.
¾
Les services : regroupent l’ensemble des opérations relatives à la plateforme. Il s’agit, entre
autres, l’authentification, la gestion des utilisateurs, la gestion des contenus, l’accès aux
données et la gestion des groupes, ...etc
¾
Le Framework : agit comme le point central de l’application, son rôle est de gérer et de
référencer les services et les outils.
41
2010
CHAPITRE II
Sakai propose des outils de collaboration synchrones, tel que les salles de discussion
(également appelées chat room), ainsi que des outils de collaboration asynchrones comme par
exemple des forums de discussion. Les salles de discussion permettent aux élèves inscrits
dans le même cour de discuter entre eux en direct. Le professeur peut également organiser des
périodes de consultation pendant lesquelles il sera connecté à la salle de discussion afin
répondre aux questions des étudiants. Ces échanges ne sont pas confidentiels et il est possible
de consulter les derniers messages sur la page d’accueil du site. Quant aux forums de
discussion, ils permettent aux étudiants et enseignants d’échanger des messages qui sont
consultables par tous les membres de la plateforme.
II.4.2. Open-Xchange
II.4.2.1. Présentation
Le serveur Open-Xchange est un environnement de collaboration et de messagerie
permettant de : enregistrer les contacts, prendre des rendez-vous, planifier les tâches, envoyer
des emails, partager des documents et d'autres choses encore que les utilisateurs pourront
partager avec les autres.
Cet environnement peut être utilisé par un navigateur Web ou par de multiples clients
lourds comme KDE Contact, Apples Ical, Konqueror, Mozilla Calendar et bien d'autre basé
sur des standards ouverts (Figure II-2).
Si vous utilisez le connecteur Outlook OXTender, les fonctionnalités de OpenXchange peuvent aussi être accessibles via Outlook ou certains périphériques mobiles.
Chaque produit tiers permet d'accéder aux différentes applications en utilisant
différentes interfaces comme WebDAV (XML), LDAP, ICal et HTTP/S. Toutes ces
fonctionnalités font de Open-Xchange Server un produit puissant pouvant être utilisé
facilement par tous les utilisateurs depuis toutes les plateformes pour accéder aux emails ou
partager des informations.
Open-Xchange Server est basé sur les modules open source suivant :
¾
Un serveur HTTP/S (Apache)
¾
Un moteur de génération de Servlet (Tomcat)
¾
Une base de donnée (PostgreSQL)
¾
Un annuaire (OpenLDAP)
¾
Un serveur de messagerie SMTP / IMAP / POP3 (Postfix et Cyrus)
42
2010
CHAPITRE II
Figure II-2 : Open-Xchange
II.4.2.2. Fonctionnalités de Open-Xchange Server
¾
Portail : Une page d'accueil permet d'avoir un aperçu de tous les éléments concernant
l’utilisateur, y compris les emails, calendrier et contacts et un accès direct à toutes les
informations personnelles comme les tâches, les réunions, les projets en cours. Les
nouveaux éléments sont mis en gras pour une meilleure visibilité.
¾
Calendrier : Ce module OPEN-XCHANGE permet de coordonner les rendez-vous
personnels et de grouper avec les informations de disponibilité de chaque utilisateur et
chaque ressource.
¾
Contacts : Un module pour la gestion de contact peut être personnalisé avec des
catégories optionnelles, le carnet d'adresse global de la société, les contacts relatifs aux
projets internes et externes.
¾
Tâches : Un module OPEN-XCHANGE pour la gestion et l'administration des tâches
individuelles.
¾
Projets : Un module OPEN-XCHANGE conçu pour organiser les équipes qui
travaillent sur des projets en planifiant les réunions, les tâches, et en gérant les
documents rattachés au projet.
¾
Gestion de documents : Un module OPEN-XCHANGE pour la gestion de documents
inclut des fonctionnalités de gestion de version, de verrouillage pendant l'édition des
documents.
43
2010
CHAPITRE II
¾
Webmail : Un module OPEN-XCHANGE permet de lire, filtrer, envoyer et gérer les
emails et les dossiers de messagerie en utilisant le carnet d'adresse global ou personnel,
les signatures, ...etc
¾
Base de connaissances, Signet, Forum et tableau d'affichage : Il existe d'autres
modules pour la gestion des connaissances entre les employés: l'utilisateur peut
construire une base de connaissance centralisée, gérer les signets et les discutions dans
les forums.
II.4.3. Silverpeas
La plateforme Silverpeas est un outil destiné à faciliter la collaboration des différents
acteurs et partenaires de l’entreprise, par la mise à disposition d’outils dans le cadre d’un
Intranet, d’un Extranet ou d’un site Internet « Web 2.0 » (Figure II-3). Silverpeas propose
différents services.
Figure II-3 : Interface Silverpeas.
II.4.3.1. Des services collaboratifs
Les services décrits ci-après ne constituent qu’une petite partie du catalogue de
services, riche de plus de 40 éléments. (Agendas partagés, Annuaires, Documents partagés,
Galerie d’images, Blogs, Forums, Chat, Enquêtes, Messagerie instantanée, Notifications et
abonnements, Actualités , Annuaire de sites , Designer de page web , Designer de site web ,
Journal périodique ,Gestion de contenu multi-axes , Hyperliens , Lettre informative )
44
2010
CHAPITRE II
a. Le service« ALMANACH »
Il permet de créer et de visualiser les différents agendas d’évènements définis dans les
espaces et sous espaces collaboratifs. L’Almanach est maintenu par le publieur de ce service.
Le gestionnaire du service le déploie en lui donnant :
¾
Un titre, un descriptif, une date de début et de fin, un caractère prioritaire ou non
¾
La possibilité d’associer des fichiers aux événements.
Chaque événement peut être décrit avec une heure et un lieu. Une extension de
fonctionnalités permet en outre de réserver des ressources (salles, video- projecteurs), et un
planning de formations.
b. Le service« CHAT »
Le service « Chat » offre un lieu de réunion virtuel où les utilisateurs peuvent se
rencontrer et discuter avec tous les collaborateurs de l’entreprise ou en privé au sein d’un
espace collaboratif ou de sous-espaces.
Le Chat est défini par:
¾
Un titre, un sujet, un nombre maximum d’utilisateurs
¾
Une liste de participants
¾
Le nombre maximum de messages
¾
La fréquence de réactualisation
¾
Liste des messages publics et privés
c. Le service « ANNUAIRE »
Ce service permet de créer des annuaires partagés instanciables dans chaque espace
collaboratif. Ces annuaires peuvent intégrer des contacts internes et externes à l’organisation.
Les contacts sont définis par :
¾
Les coordonnées professionnelles complètes de la personne
¾
L’auteur de la fiche contact
¾
La date de création
¾
Le modèle de présentation pouvant inclure une photo et les coordonnées personnelles
d. Le service « ENQUETE »
Ce service permet de créer des enquêtes d’opinion au sein de l’organisation. Les
participants peuvent suivre l’évolution des réponses en temps réel. Le publieur du service gère
l’intégralité du processus.
45
2010
CHAPITRE II
Ce service est défini par :
¾
Un libellé
¾
Une description
¾
Les dates de création, d’ouverture et de clôture des enquêtes
¾
Le nombre de questions
¾
Le type de questions
¾
Le nombre de réponses autorisées
¾
La possibilité d’ajouter un commentaire
Les fonctionnalités majeures sont :
¾
Création d’enquêtes
¾
Définition de questions ouvertes ou fermées
¾
Définition de questions à choix multiple
¾
Possibilité d’associer des images aux questions
¾
Suivi du niveau de participation et des résultats
¾
Organisation des enquêtes en cours, terminées et en attente
e. Le service « FORUM »
Ce service permet l’organisation et le suivi de forums de discussion sur l’ensemble de
l’entreprise ou au niveau d’un espace collaboratif.
Forum est défini par :
¾
Un thème et un descriptif
¾
Des messages postés par les participants
¾
L’auteur
¾
La date de publication
¾
La possibilité de répondre aux messages
¾
Création de forum
¾
Contact du modérateur du Forum
¾
Definition des participants
46
2010
CHAPITRE II
f. Le service de « GESTION DE PROJET » - (PROJECT ORGANIZER)
Ce service permet au chef de projet d’allouer des tâches aux membres de son équipe et
faire le suivi de l’évolution du projet. Chaque participant peut gérer ses propres tâches tout en
visualisant le travail réalisé par les autres membres de l’équipe.
Un Project est défini par :
¾
Le nom du projet .
¾
Un chef de projet
¾
Les objectifs du projet
¾
Les dates de début et de fin du projet
¾
La désignation du projet
¾
La personne affectée au projet
¾
La durée du projet
¾
Le taux d’avancement du projet
¾
La description des actions
¾
Création du projet
¾
Création de tâches et de liens entre tâches pour re-planification automatique
¾
Allocation des tâches aux membres de l’équipe
¾
Réalisation du suivi des tâches par le diagramme de Gantt
¾
Notification des modifications de tâches aux ressources concernées
g. Le service « PLAN D’ACTION »
Il permet de faire vivre un plan d’action décidé en réunion. Le service Plan d’actions
reprend le quasi totalité des fonctionnalités du composant Project Organiser :
¾
le diagramme de Gantt
¾
les commentaires au niveau global et au niveau d’une tâche
¾
les pièces jointes au niveau d’une tâche
¾
la notion de sous-tâche (ou de tâche composite)
47
2010
CHAPITRE II
h. Le service « QUIZ »
Le service Quizz permet d’évaluer le niveau de connaissance acquis par l’audience
visée et de faire un suivi des formations. Ce service est instancier dans l’espace entreprise
mais également dans chaque espace collaboratif.
Il peut être utilisé pour des tests de vérification des connaissances et gestion des formations.
Le service est défini par :
¾
Un titre et un descriptif
¾
Des dates de création, d’ouverture et de clôture
¾
Le nombre de questions par page
¾
Le nombre de participations possibles
¾
Un libellé pour les questions
¾
Le type de réponse (unique ou multiple)
¾
Le nombre de réponses proposées
¾
Le nombre de points minimum, maximum et de pénalité attribuables
¾
Un indice
¾
Création du questionnaire
¾
Définition des participants
¾
Définition des questions
¾
Suivi du niveau de participation et des résultats
i. Le service « NEWS »
Le service « News » permet de diffuser des nouvelles brèves à toute l’organisation ou à un
public plus restreint.
Elles ont une durée de vie définie par le publieur du service.
Un service « News » est défini par :
¾
Un titre
¾
Une information
¾
Une date de début et de fin de diffusion
¾
Publication d’informations
48
2010
CHAPITRE II
¾
Copier/coller
j. Le service « BLOG »
Le service « News » permet de gérer le contenu d’un blog.
Un « billet » est défini par:
¾
Un titre
¾
Une date de publication
¾
Une catégorie
¾
un contenu WYSIWYG
¾
Des liens
¾
Créer des catégories
¾
Ajouter un billet (article) et le rattacher à une catégorie
¾
Ajouter des commentaires sur un billet
¾
Rechercher par date, par catégorie
¾
Recherche sur mot clé.
k. Le service « GALLERY » (BANQUE D’IMAGES)
Le service Gallery Permet de gérer et d’afficher des fichiers de type images dans une
arborescence d’albums. Gallery permet de classer et d’afficher des images (photos, logos,
plans…) dans des albums
Une image est définie par:
¾
Un titre, une description
¾
Une vignette
¾
Un auteur
¾
Des dates limites de téléchargement
¾
Si l’image est téléchargeable au format original
¾
Ajouter un album
¾
Ajouter des images
¾
Classer les images, trier les images
49
2010
CHAPITRE II
¾
Choisir la taille des vignettes
¾
Diaporama
l. Le service « SILVERCRAWLER »
Ce service permet de donner accès en consultation à des répertoires d’un serveur de
fichiers, et d’indexer le contenu de façon à ce que le moteur de recherche de Silverpeas puisse
compléter ses résultats avec des fichiers contenus dans ces répertoires.
Les droits d’accès peuvent donc être gérés au niveau de ce service.
m. Le service de NOTIFICATION
Ce puissant outil permet à l’utilisateur de créer des canaux d’information par lesquels
il sera notifié, soit spontanément par des contributeurs, soit automatiquement, dans le cas d’un
abonnement à des thèmes, ou Forums de discussion.
Les canaux par lequel les informations viennent à l’utilisateur sont au choix : boîte (s) e-mail,
SMS via un serveur SMS, fenêtre pop-up, boîte de notification dans la plateforme.
n. WORKFLOW DE CIRCULATION DES INFORMATIONS
Grâce à son moteur de workflow, Silverpeas permet d’automatiser et coordonner les
procédures de circulation des informations, auprès de différents utilisateurs, en faisant passer
formulaires, documents et tâches d’un intervenant à un autre selon des règles procédurales
prédéfinies, de façon à ce que chacun puisse remplir son rôle au moment opportun.
Exemples : Procédure de validation d’une demande d’achat, d'un contenu destiné au Web, ou
simple procédure de gestion des congés.
Dans Silverpeas, les INTERVENANTS (ex : le comptable) se voient attribuer des
rôles (ex : valideur, responsable hiérarchique, …) et accomplissent des ACTIONS (ex :
valider une demande de congés), commandées par L’ETAT d’avancement de la procédure (ex
: demande en attente de validation). Le DOSSIER rassemble l’ensemble des informations, des
pièces et des documents qui font l’objet d’une procédure (ex : justificatifs et formulaire de
saisie d’une note de frais) et les données (ex : nombre de jours, commentaire du responsable).
¾
Des Workflows documentaires,
¾
Un CMS (Content Management System)
¾
L’accès à d’autres applications (fonction portail)
II.4.3.2. Des services de GED et de gestion de connaissances
Les services « ThemeTracker » ou « FileBox » sont les deux principaux services de
gestion documentaire. (GED).
50
2010
CHAPITRE II
¾
ThemeTracker est une gestion de contenu multi thèmes, qui permet de créer des
publications à l'aide de formulaires ou d'un éditeur WYSIWYG, et de leur associer des
pièces jointes.
¾
FileBox plus simple, permet de construire des bibliothèques de fichiers et de les classer
II.4.4. Xwiki
XWiki est un wiki Open-Source de seconde génération (ou "wiki applicatif") écrit en
Java (Figure II-4). Il offre non seulement les principales fonctions d'un wiki (édition
collaborative, suivi d'information, gestion de l'accès des membres), mais aussi des possibilités
de développement avancées comme :
¾
Créer et utiliser de nouveaux templates dans la création de page wiki grâce à
l'intégration de Velocity.
¾
créer des pages wiki "applicative" grâce à l'intégration du langage de script Groovy.
¾
créer de nouveaux objets Xwiki en plus des objets prédéfinis (albums photo, calendrier,
blog) grâce à une API de plugin Java .
¾
gérer finement les droits d'accès : cela permet de restreindre certaines actions (lecture,
écriture, administration) à une certaine population (un simple internaute, un membre du
wiki ou un administrateur) et ceci, par page ou par espace du wiki.
Figure II-4 : Interface Xwiki.
51
2010
CHAPITRE II
II.5. Conclusion
Dans ce chapitre nous avons vu quelques plateformes collaboratives et les différents
outils de communication utilisés dans ces derniers. Ce court panorama nous a donné une idée
sur les systèmes existants et les fonctionnalités qu’il serait intéressant de l’exploiter dans
notre contribution.
52
2010
CHAPITRE III
ARCHITECTURE PROPOSEE
CHAPITRE III. ARCHITECTURE
PROPOSEE
53
Chemame Chaouki
CHAPITRE III
III.1. Introduction
Dans ce chapitre nous allons donner une architecture globale d’une plate-forme
collaborative basée sur les différents outils de collaborations, cette architecture englobe
plusieurs technologies.
III.2. L’outil open source
III.2.1. Définition
L'expression Open Source signifie littéralement "source ouverte" en français,
s'applique à certains logiciels dont la licence respecte les critères définis par l'association
Open Source Initiative(OSI).
L’Open Source Initiative défend en particulier la liberté d'accéder aux sources des
programmes. Ainsi, les logiciels approuvés par l’OSI offrent la possibilité de libre
redistribution, d'accès au code source et de travaux dérivés.
III.2.2. La licence open source
« Open Source » implique plus que la simple diffusion du code source. La licence d'un
programme « open-source » doit correspondre aux critères suivants :
III.2.2.1. Libre redistribution
La licence ne doit pas empêcher de vendre ou de donner le logiciel en tant que
composant d'une distribution d'un ensemble contenant des programmes de diverses origines.
La licence ne doit pas exiger que cette vente soit soumise à l'acquittement de droits d'auteur
ou de royalties.
III.2.2.2. Code source
Le programme doit inclure le code source, et la distribution sous forme de code source
comme sous forme compilée doit être autorisée. Quand une forme d'un produit n'est pas
distribuée avec le code source correspondant, il doit exister un moyen clairement indiqué de
télécharger le code source, depuis l'Internet, sans frais supplémentaires. Le code source est la
forme la plus adéquate pour qu'un programmeur modifie le programme. Il n'est pas autorisé
de proposer un code source rendu difficile à comprendre. Il n'est pas autorisé de proposer des
formes intermédiaires, comme ce qu'engendre un pré processeur ou un traducteur
automatique.
III.2.2.3. Travaux dérivés
La licence doit autoriser les modifications et les travaux dérivés, et leur distribution
sous les mêmes conditions que celles qu'autorise la licence du programme original.
54
2010
CHAPITRE III
III.2.2.4. Intégrité du code source de l'auteur
La licence ne peut restreindre la redistribution du code source sous forme modifiée
que si elle autorise la distribution de fichiers « patch » aux côtés du code source dans le but de
modifier le programme au moment de la construction. La licence doit explicitement permettre
la distribution de logiciel construit à partir du code source modifié. La licence peut exiger que
les travaux dérivés portent un nom différent ou un numéro de version distinct de ceux du
logiciel original.
III.2.2.5. Pas de discrimination entre les personnes ou les groupes
La licence ne doit opérer aucune discrimination à l'encontre de personnes ou de
groupes de personnes.
III.2.2.6. Pas de discrimination entre les domaines d'application
La licence ne doit pas limiter le champ d'application du programme. Par exemple, elle
ne doit pas interdire l'utilisation du programme pour faire des affaires ou dans le cadre de la
recherche génétique.
III.2.2.7. Distribution de la licence
Les droits attachés au programme doivent s'appliquer à tous ceux à qui le programme
est redistribué sans que ces parties ne doivent remplir les conditions d'une licence
supplémentaire.
III.2.2.8. La licence ne doit pas être spécifique à un produit
Les droits attachés au programme ne doivent pas dépendre du fait que le programme
fait partie d'une distribution logicielle spécifique. Si le programme est extrait de cette
distribution et utilisé ou distribué selon les conditions de la licence du programme, toutes les
parties auxquelles le programme est redistribué doivent bénéficier des droits accordés lorsque
le programme est au sein de la distribution originale de logiciels
III.2.2.9. La licence ne doit pas contaminer d'autres logiciels
La licence ne doit pas apposer de restrictions sur d'autres logiciels distribués avec le
programme qu'elle couvre. Par exemple, la licence ne doit pas exiger que tous les programmes
distribués grâce au même médium soient des logiciels « open-source ».
55
2010
CHAPITRE III
III.3. L’intégration des applications au sein d'un environnement
collaborative
III.3.1. Les problèmes liés à l’intégration d’applications
Depuis que CORBA a pensé que l’intégration d’applications sur des plates-formes
hétérogènes était possible, beaucoup de problèmes sont apparus et deviennent de plus en plus
complexes chaque année. Parmi ces problèmes on peut citer :
III.3.1.1. La complexité
Aujourd’hui, certains aspects informatiques ont changé, les environnements sont plus
complexes, l’accès à faible coût et omniprésent à Internet a créé de nouveaux modèles de
développement surtout pour les entreprises qui souhaitent fusionner des applications entières
qui répondent à leurs besoins. Dans un environnement d’une telle complexité, les solutions
point à point ne font qu’exacerber les problèmes et ne relèvent jamais véritablement les défis.
Donc il faut développer des systèmes qui incorporent le caractère hétérogène des
organisations, en tant que composant essentiel de l’environnement informatique, de sorte que
ces systèmes puissent prendre en charge une gamme diverse et sans limite de matériel, de
systèmes d’exploitation, de logiciels intermédiaires, de langages et de stockage de données.
III.3.1.2. Une programmation redondante et ne pouvant être réutilisée
Comme dans beaucoup de sociétés, l’éventail des applications a peut-être augmenté en
raison de fusions ou d’acquisitions d’autres entreprises. Le résultat est de faire face à des
applications redondantes ou à des applications dont les fonctions ne peuvent être facilement
réutilisées. Il se peut que chaque unité de l’organisation ait travaillé indépendamment des
autres, ce qui freine l’effort de coordination visant à créer un parc ou des services
informatiques fonctionnels et réutilisables. Cette redondance augmente les coûts et le temps
de mise sur le marché pour le déploiement de nouveaux produits et services, car les
modifications doivent être effectuées pour chaque application ou système concerné. Le fait de
ne pouvoir réutiliser certaines fonctions requiert, en fin de compte, plus de ressources, et
souvent plus de temps, pour livrer de nouvelles applications.
III.3.1.3. Des interfaces multiples
Il faut penser au problème d’intégration. Les développeurs d’entreprises par exemple
doivent faire face à des problèmes d’intégration, quelle que soit leur nature, en raison d’une
fusion, d’un nouveau partenariat commercial ou simplement d’un besoin d’interconnexion
entre des systèmes existants. Si n systèmes d’applications doivent être directement
interconnectés, le processus va créer n.(n-1) connexions ou interfaces. Comme illustre la
Figure III-1, où chaque pointe de flèche représente une interface.
56
2010
CHAPITRE III
Application 1
Application 2
Application 3
Application 4
Application 5
Figure III-1 : Le problème d’intégration
Par conséquent, si on a besoin d’intégrer un autre système d’applications (n+1), on
doit créer, documenter, tester et maintenir 2n interfaces nouvelles. Dans la Figure III-1,
l’ensemble de cinq applications requiert 20 interfaces directes. L’ajout d’une sixième
application supposerait dix nouvelles interfaces. Et pour augmenter la complexité de
l’opération, on doit également modifier le code de chaque application.
III.3.2. Les exigences de la programmation d’aujourd’hui
Au vu des problèmes débattus précédemment, il devrait être évident qu’il est
important de développer une architecture qui satisfasse un ensemble d’exigences. Ces
exigences devraient inclure les éléments suivants :
III.3.2.1. L’exploitation du parc informatique existant
Il s’agit de la condition la plus importante. Il est rare que des systèmes existants
puissent être éliminés. Ils contiennent certainement des données de grande importance.
L’objectif est de constituer une nouvelle architecture dont le rendement corresponde à ce
qu’on souhaite.
III.3.2.2. La prise en charge de tous les types d’intégrations requis
Cela comprend l’interaction avec l’utilisateur (pour fournir un fonctionnement unique
et interactif), la connectivité des applications (pour créer un modèle de communication qui
sous-tend toute l’architecture), l’intégration des processus (pour organiser les applications et
les services), l’intégration des informations (pour rassembler et déplacer les données)
et la possibilité d’effectuer de futures intégrations (pour créer et déployer de nouveaux
services et applications).
57
2010
CHAPITRE III
III.3.2.3. La possibilité de mises en œuvre incrémentielles et de migration
du parc
Si cette exigence est satisfaite, l’un des aspects essentiels du développement de
l’architecture pourra être mis en place la possibilité de produire un retour sur investissement
différentiel. D’innombrables projets d’intégration ont échoué en raison de leur complexité, de
leur coût et de temps de mise en œuvre impossibles à réaliser.
III.3.2.4. La constitution dans un cadre de composants standards
On doit inclure un environnement de développement créé autour d’un cadre de
composants standards pour promouvoir une meilleure réutilisation des modules et des
systèmes, permettre au parc informatique existant de migrer vers le cadre en question et
permettre une mise en œuvre opportune des nouvelles technologies.
III.3.2.5. La possibilité de mise en œuvre de nouveaux modèles
informatiques
Avec l’apparition des nouveaux modèles tels que les clients de portails, le calcul
distribué et l’informatique à la demande ...etc L’Architecture Orientée Services vienne à
répondre à ces exigences, car elle permet de concevoir des systèmes logiciels fournissant des
services à d’autres applications à l’aide d’interfaces publiées et découvrables, et où les
services peuvent être sollicités via un réseau.
Ce nouveau model d’architecture est apparu avec l’apparition de ce qu’on appelle les
services web, car son principal objectif était de publier sur (internet, extranet ou encore
intranet) un ensemble d’offre (existant ou non) réalisant un service bien précis (par exemple
un service pour crypter des données, un autre pour authentifier une personne, etc…).Une
apparition dans ce cadre appelle ces différents services quand elle en a besoin et peut être ellemême déployée comme un nouveau service.
III.3.3. Une architecture orientée services : au-delà des services Web
L’évènement des services Web a précipité le changement fondamental dans le
développement, le déploiement et la gestion des infrastructures informatiques. La réussite de
nombreux projets de services Web a montré que la technologie permettant de mettre en œuvre
une véritable architecture orientée services. Elle permet de prendre du recul pour examiner
l’architecture des applications. D’un point de vue de l’entreprise, le problème n’est plus
uniquement un problème technologique. Il s’agit de développer une architecture et un cadre
d’applications au sein desquels on pourra définir des problèmes et mettre en œuvre des
solutions qu’on pourra réutiliser de manière cohérente.
58
2010
CHAPITRE III
Toutefois, il est important d’abord de comprendre qu’une architecture orientée
services ne se limite pas aux services Web. Les services Web constituent un ensemble de
technologies, y compris les technologies XML, SOAP (Simple Object Access Protocol),
WSDL (Web Services Description Language) et UDDI (Universal Description, Discover and
Integration), qui nous permet de créer des solutions de programmation pour des problèmes de
messagerie et d’intégration d’applications spécifiques. Ces technologies sont suffisantes et ont
déjà démontré qu’on peut dès à présent mettre en œuvre une architecture orientée services.
III.3.3.1. Les éléments constitutifs d’une architecture orientée services
Une architecture orientée services porte bien son nom car il s’agit en effet d’une
architecture. Ce n’est pas uniquement un ensemble spécifique de technologies, telles que les
services Web. Elle transcende ces technologies et, en théorie, en est complètement
indépendante. Au sein d’un environnement d’entreprise, une définition purement
architecturale d’une architecture orientée services pourrait être la suivante : « Architecture
d’applications au sein de laquelle toutes les fonctions sont définies en tant que services
indépendants, comprenant des interfaces bien définies qui peuvent être sollicitées dans des
séquences définies ».
Par conséquent, un système basé sur ce type d’architecture doit effectuer et gérer la
sollicitation du service et non l’application appelante. Cette fonction permet la réalisation de
deux caractéristiques essentielles :
¾
L’indépendance véritable des services
¾
La possibilité de gérer les services.
La gestion comprend plusieurs fonctions :
¾
La sécurité, l’autorisation des requêtes, le cryptage et le décryptage des données, selon
les instructions données, et la validation des informations.
¾
Le déploiement permet au service d’être déplacé au sein du réseau pour maximiser les
performances et supprimer la redondance afin que la disponibilité des applications soit
maximale.
¾
La maintenance permet de gérer de nouvelles versions du service.
III.3.3.2. La nature d’un service
Un service au sein d’un environnement d’entreprise constitue en général une fonction
simple, une transaction plus complexe ou un service système. D’un point de vue de
l’application, ces fonctions sont des fonctions non atomiques.
59
2010
CHAPITRE III
Les transactions peuvent sembler n’être que de simples fonctions pour l’application
appelante, mais elles peuvent être mises en œuvre en tant que fonctions composites masquées
par leur contexte transactionnel propre. Elles impliquent parfois de multiples fonctions de
niveau inférieur transparentes pour l’appelant. Les fonctions systèmes sont des fonctions
généralisées qui peuvent être extraites d’une plateforme spécifique, telle que Microsoft
Windows ou Linux.
Ceci n’est pas une simple distinction artificielle entre les différents services. D’un
point de vue de l’application, tous les services sont atomiques, mais le fait qu’il s’agisse de
services d’entreprise ou système n’a aucune importance. Cette distinction ne sert qu’à
introduire le concept important de granularité. La décomposition des applications d’entreprise
en services ne constitue pas uniquement un processus abstrait, elle implique également des
opérations très pratiques. Les services peuvent être composés de fonctions de niveau inférieur
(granularité fine) ou de niveau supérieur complexe (granularité grossière). Il existe de
véritables compromis de performance, de flexibilité, de possibilités de maintenance et de
réutilisation basés sur les définitions de ces fonctions. Le niveau de granularité indique la
richesse fonctionnelle d’un service. Par exemple, plus la granularité d’un service est grossière,
plus la fonction offerte par le service est riche.
Les services sont en général composés de fonctions commerciales à granularité
grossière, telles que le service « ouvrir un compte », car ces opérations peuvent supposer
l’exécution de multiples opérations à granularité plus fine, telles que le service « vérifier
l’identité du client » et le service « créer le compte client ». Ce processus de définition de
services est en général effectué dans un cadre plus large, le cadre d’applications. C’est ce
cadre qui doit être mis en place. Il s’agit de développer un cadre d’applications de composants
dans lequel les services sont définis en tant qu’ensemble de composants réutilisables pour
créer de nouvelles applications ou intégrer un parc logiciel existant.
III.3.3.3. L’intégration d’applications
Si nous revenons à présent au premier exemple d’intégration mentionné (Figure III-1),
on peut l’améliorer par un schéma qui minimise le nombre d’interfaces requises, tel que celui
présenté à la Figure III-2, cette figure peut paraître trop simpliste, mais elle illustre bien le
point de départ de l’intégration des applications.
60
2010
CHAPITRE III
Application 1
Application 3
Application 2
Application 4
Application 5
Figure III-2 : L’intégration d’applications
En suivant ce cadre d’intégration, on peut ajouter le concept architectural de bus de
services, représenté dans la figure précédente par la ligne épaisse au centre, et un gestionnaire
de services ou de flux pour connecter les services et fournir un chemin aux requêtes de
services. Le gestionnaire de flux traite une séquence d’exécution définie, ou flux de services,
qui sollicite les services requis dans la séquence adéquate pour produire le résultat final
(voir Figure III-3).
Service 2
Service1
Gestionnaire
de flux
Service 3
Service 4
Service n
Figure III-3 : L’intégration des services
III.3.3.4. Les exigences d’intégration au sein de l’architecture
Jusqu’à présent, le débat sur l’intégration s’est limité à l’intégration d’applications via
des services de composants, mais l’intégration est un sujet beaucoup plus vaste. Lorsqu’on
évalue nos exigences en ce qui concerne une architecture, on doit prendre en compte plusieurs
types d’intégrations. On doit penser non seulement à l’intégration d’applications, mais
également à celle de l’interface de l’utilisateur final, à la connectivité des applications, à
l’intégration des processus, à l’intégration des informations et au modèle de développement
prêt à l’intégration.
61
2010
CHAPITRE III
a. L’intégration au niveau de l’interface
L’intégration au niveau de l’interface de l’utilisateur final correspond à la manière
dont l’ensemble complet d’applications et de services auquel un utilisateur donné accède est
intégré afin de fournir une interface utilisable, efficace et cohérente. Ce sujet est en évolution
constante et les nouveaux développements, à court terme, traiteront essentiellement des
avancées dans l’utilisation des serveurs de portails. Alors que les portlets peuvent déjà
solliciter des composants de services locaux à l’aide des services Web, des nouvelles
technologies, telles que les services Web pour portlets distants, activeront des fournisseurs de
contenu et d’applications pour créer des services interactifs prêts à être utilisés avec des
portails via Internet et offriront donc de nombreuses possibilités nouvelles d’intégration.
b. La connectivité d’applications
La connectivité d’applications est un type d’intégration relatif à tous les types de
connectivités devant être pris en charge par l’architecture. À un certain niveau, cette
intégration traite des communications synchrones et asynchrones, du routage, des
transformations, de la distribution rapide des données, et des convertisseurs de passerelles et
de protocoles. À un autre niveau, elle s’occupe également de la virtualisation des données en
entrée et des résultats, ou des sources et des récepteurs, tels que les programmes de gestion de
canaux et de protocoles. Le problème réside dans la manière fondamentale dont les données
entrent, sortent et se déplacent dans le cadre qui met en œuvre l’architecture.
c. L’intégration des informations
L’intégration des informations est un processus qui fournit un accès cohérent à toutes
les données pour toutes les applications, quel que soit la manière dont ces données doivent
être envoyées : leur format, leur source ou leur emplacement. Lors de la mise en œuvre, cette
exigence peut supposer la simple utilisation d’un logiciel adaptateur et d’un moteur de
transformation. Toutefois, en général, le processus est plus complexe. Le concept clé est
souvent la virtualisation des données qui peut inclure le développement d’un bus de données à
partir duquel toutes les applications peuvent envoyer des requêtes de données via des services
ou des interfaces standards. Les données peuvent ainsi être envoyées à l’application qu’elles
proviennent d’une feuille de calcul, d’un fichier natif, d’une base de données SQL (Structure
Query Language), d’un autre type de base de données ou d’un stockage de données en
mémoire.
62
2010
CHAPITRE III
III.4. Architecture proposée
III.4.1. Architecture orientée service (SOA)
L’Architecture Orientée Services (AOS ou SOA – Service-Oriented Architecture en
anglais) permet aux concepteurs de systèmes d’information d’organiser un ensemble de
logiciels isolés en un ensemble de services interconnectés, accessibles par une interface et des
protocoles standard.
Un service est une unité discrète qui remplit une collection de tâches répondant au(x)
même(s) objectif(s). L’AOS est un paradigme architectural qui peut être utilisé pour
concevoir des infrastructures permettant aux clients et aux fournisseurs d’échanger des
services, malgré la disparité des domaines, des technologies, et des fournisseurs.
Un ensemble de facteurs clés fait converger les clients vers une architecture orientée services.
D’après notre point de vue, trois facteurs sont essentiels : la réutilisation, la découverte, et la
composition.
¾
La réutilisation : Les unités logiques des architectures des systèmes sont divisées en
services dans l’intention de promouvoir leur réutilisation. Cette réutilisation nécessite
que chaque service utilisé dans un système basé sur une AOS soit, au préalable, décrit
par son fournisseur. L’avantage de la réutilisation est un gain de temps et
d’investissement lors de la conception d’une nouvelle application.
¾
La découverte : Les services sont conçus afin d’être sélectionnés via des mécanismes
de recherche. La découverte est permise par la description préalable des services et leur
publication au sein d’un registre. La découverte est un point clé nécessaire à la
réutilisation des services élémentaires dans une AOS.
¾
La composition : Des collections de services peuvent être coordonnées et assemblées
afin de former une composition de services. Cette possibilité de construire de nouveaux
systèmes à partir de services existants constitue un des avantages de l’AOS.
Dans le contexte de mise en œuvre d’applications à base d’architecture orientée
services, la technologie la plus utilisée est celle des services Web. Un service Web est un
logiciel conçu pour supporter l’interaction entre machines inter opérables à travers un réseau.
Cette interopérabilité est rendue possible grâce à deux standards connus par l’ensemble des
acteurs (fournisseurs et clients). Le premier est le langage de description (WSDL – Web
Service Description Language ) et le second est le protocole de communication (SOAP –
Simple Object Access Protocol).
63
2010
CHAPITRE III
L’avantage principal de l’architecture orientée services en général et Web en
particulier, est que ce paradigme pourrait répondre aux besoins en termes de flexibilité et
d’adaptabilité rapide exprimés par les concepteurs. Une application à base de services est
flexible puisqu’un service défaillant peut être remplacé par un autre sans modifier l’ensemble
de l’application. De plus, elle est adaptable du fait que le service sélectionné est celui choisi
comme étant le meilleur dans un contexte donné. Ce type d’architecture est aujourd’hui
d’autant plus populaire qu’il est amplement utilisé par les organisations qui veulent prendre
part au Web 2.0.
III.4.2. Difficultés rencontrées dans la réalisation d’une plate-forme
collaborative complète
Indépendamment de l’approche de développement choisie, la conception de nouvelles
applications collaboratives qui soient extensibles se présente comme un grand défi pour les
développeurs. Si d’un coté l’utilisation de boîtes à outils s’avère simple et rapide, le degré
d’extensibilité obtenu est très restreint. Si les développeurs choisissent de s’appuyer sur des
Framework ou des plates-formes, la possibilité d’intégrer de nouveaux composants est
également contraignante puisque ces derniers doivent suivre un schéma d’interaction imposé
par le système en question. Ou alors les développeurs doivent faire face à la complexité des
logiciels afin de pouvoir intégrer des composants disponibles en open source.
Dans la pratique il n’existe que des collecticiels se focalisant sur des aspects spécifiques de la
collaboration, et qui ont souvent été développés selon l’approche « From scratch », soit des platesformes collaboratives, qui ont souvent été développées selon des frameworks très sophistiqués. Ces
applications peuvent donner à l’utilisateur un certain niveau d’extensibilité, mais malgré toutes les
possibilités d’extensibilité offertes par ces plates-formes, elles sont loin d’être considérées comme une
panacée. Outre le coût associé à ces systèmes, l’utilisateur se trouve toujours limité à une plate-forme
donnée. Autrement dit, il est confronté à un choix limité d’outils de collaboration. Ainsi, des
utilisateurs finissent par composer leurs propres “environnements collaboratifs” en choisissant, selon
leurs besoins, différentes applications offrant des fonctionnalités spécifiques, en les exécutant en
même temps mais indépendamment les unes des autres.
Réaliser une plate-forme collaborative qui répond aux exigences des collaborateurs est
une tâche très difficile même avec l’utilisation d’une architecture orientée service qui offre
beaucoup de solutions d’interopérabilité et d’extensibilité, les développeurs doivent
développer les différents services de collaboration (exemple : le tableau blanc, la vidéo
conférence, le bureau partagé, quiz, enquête, le chat, le forum, le wiki, …etc) en prenant en
compte leurs domaines d’utilisation.
64
2010
CHAPITRE III
Pour remédier à cela nous proposons une approche permettant à plusieurs platesformes collaboratives de communiquer ensemble à l’aide de ce qu’on appelle l’intégration de
modules en se basant sur l’architecture orientée service, et plus précisément les services web.
Avant de détailler cette approche nous allons donner une petite introduction sur la technique
d’intégration des outils de collaboration.
III.4.3. Vers l’intégration d’applications existantes
La problématique associée à l’intégration d’applications existantes est l’un des
principaux axes de recherche qui concerne la possibilité de faire interopérer différents
systèmes. L’interopérabilité ou l’intégration entre les applications facilite la coopération au
sein d’une organisation ou entre différentes organisations sans les obliger à utiliser
exactement les mêmes systèmes ni à posséder les mêmes équipements.
La notion d’intergiciel a fait son apparition afin de faciliter le développement
d’applications réparties et de gérer les interactions entre ces applications via des plates-formes
hétérogènes (par exemple diversité du matériel, des systèmes d’exploitation ou des langages
de programmation). Un intergiciel représente ainsi une solution architecturale au problème de
l’intégration de différentes applications tout en imposant à ces applications une interface de
service commune.
Parallèlement à l’évolution des intergiciels et d’internet, les technologies Web ont
émergé et remporté un succès important, en permettant des interactions simples avec des
ordinateurs à distance. Plus récemment, les services Web, qui reprennent la plupart des
principes du Web en les appliquant à des interactions ordinateur-ordinateur, se présentent
comme une technologie potentielle pour l’intégration d’applications à travers l’Internet.
Le Figure III-4 illustre de façon détaillée l’interaction entre une application cliente et
un service web. Ce schéma nous montre que SOAP représente une sorte de façade qui masque
l’hétérogénéité technique de l’application ou des données sous-jacentes. Nous avons donc une
surcouche logicielle intercalée entre le programme développé (dans un langage propriétaire)
et le monde extérieur. L’interopérabilité est ainsi un aspect intrinsèque des services Web.
Grâce à leur formalisation standard définissant des normes ouvertes, ils fournissent un moyen
technique pour exposer les interfaces de programmation de leurs applications dans un format
compréhensible par n’importe quelle autre application. Des applications implémentées dans
divers langages de programmation et sur diverses plates-formes peuvent ainsi employer des
services Web pour interagir et échanger des données à travers des réseaux informatiques.
65
2010
CHAPITRE III
Application
cliente
Client
SOAP
Service
Requête SOAP
Réponse SOAP
Processeur
SOAP
Application
WSDL
Requête
UDDI
PublicationUDDI
Annuaire
UDDI
Figure III-4 : Exemple d’interaction simple entre une application cliente et un service Web.
III.4.4. Architecture proposée
L’architecture qu’on propose pour la conception d’une plate-forme collaborative est
une infrastructure composée d’une architecture orientée service SOA qui met en œuvre un
certain nombre de services pour la plate-forme utiles pour la collaboration couplée avec une
interface client, qui offre ainsi un degré d’interactivité et une ergonomie comparables aux
interfaces utilisateurs standards. L'objectif principal de l’architecture orientée services est
donc de décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées
services, ce dernier est le composant clef de l'Architecture. Il consiste en une fonction ou
fonctionnalité bien définie. C'est aussi un composant autonome qui ne dépend d’aucun
contexte ou service externe, fournis par des composants et de décrire finement le schéma
d'interaction entre ces services. L'idée de cette approche est de construire une architecture
logicielle globale décomposée en services correspondant aux besoins des utilisateurs.
Notre architecture est composée de deux plateforme collaboratives la premier est la
Plate-forme open source SILVERPEAS et la deuxième c'est la plate-forme XWIKI et un
service web coordinateur d’orchestration.
Le service web coordinateur d’orchestration peut être vue comme une composition des
services Web utilisés dans la composition existent au préalable et sont appelés selon un
enchaînement défini par l’utilisateur afin de réaliser un processus précis (voir Figure III-5).
66
2010
CHAPITRE III
Service web
Coordinateur
Services Web WIKI
Service 1
Service 2
BUS
Service 3
Service 4
UDDI
.
.
.
Service n
Outils d’administration
Outils d’administration
Plate-forme
Open Source
SILVERPEAS
Plate-forme
Open Source
XWIKI
Figure III-5 : L’architecture générale de la plate-forme
Le schéma précédant montre qu’on peut intégrer des applications collaboratives déjà
existantes en open source dans une infrastructure collaborative basée services web, cela se fait
en se basant sur les services web. Initialement on va définir un service web qu’on va nommer
« service coordinateur », on va l’intégrer dans une plate-forme collaborative open source
basée sur les services de collaboration asynchrone dans le but de rendre cette plate-forme
capable de communiquer avec n’importe quelle plate-forme collaborative. Le rôle principal de
ce service est de récupérer les paramètres nécessaires du serveur d’application de la plateforme qu’on veut intégrer par la création d’un fichier XML qui englobe tous les paramètres
concernant cette application.
Ce service peut être enregistré dans un annuaire UDDI comme étant un nouveau
service qui sera prêt à être utilisé par d’autres applications clientes, ce registre sert donc de
répertoire des applications intégrées, dans le quel on trouve les informations nécessaires pour
communiquer avec le service généré (identificateur et URL).
67
2010
CHAPITRE III
III.5. Conclusion
Dans ce chapitre nous avons pu constater la difficulté associée à la conception d’une
plate-forme collaborative extensible offrant plusieurs services de collaboration. Nous avons
proposé une architecture générale basée sur l’intégration d’applications existantes (open
source). Ces applications peuvent être des applications collaboratives client/serveur
accessibles depuis le Web ou bien des applications déjà basées services web.
Pour mettre en œuvre cette approche, le meilleur choix est d’utiliser les technologies
de services Web. Pour cela on peut utiliser un service web qui peut communiquer avec
l’interface service web d’une autre application externe dans le but de générer un nouveau
service accessible pour d’autres applications.
68
2010
CHAPITRE IV
EXPERIMENTATION
CHAPITRE IV. EXPERIMENTATION
69
Chemame Chaouki
CHAPITRE IV
EXPERIMENTATION
IV.1. Introduction
Dans le chapitre précédant nous avons vu la difficulté de concevoir une plate-forme
collaborative offrant les différents outils de collaboration qui peuvent être utilisé dans
plusieurs domaines nécessitant la collaboration.
Pour résoudre ce problème, nous avons proposé une architecture globale basée sur
l’intégration d’outils open source en utilisant les services Web. Pour valider cette approche
nous avons travaillé sur deux plates-formes open-source, la première s’appelle Silverpeas qui
est une plate-forme collaborative basée sur des services Web offrant les différents outils de
collaboration asynchrones (le forum, Agendas partagés, Annuaires, Documents partagés,
Galerie d’images, Blogs, Forums, Enquêtes), et la deuxième plate-forme s’appelle XWIKI
offre un service wiki. Pour bien comprendre notre approche proposée on a besoin des tests et
d’expérimentation
IV.2. La plate-forme Silverpeas
IV.2.1. Présentation de la plateforme silverpeas
La plateforme Silverpeas est un outil destiné à faciliter la collaboration des différents
acteurs et partenaires de l’entreprise, par la mise à disposition d’outils dans le cadre d’un
Intranet, d’un Extranet ou d’un site Internet « Web 2.0 » (Figure IV-1).
Accessible depuis un simple navigateur, ou depuis un PDA, Silverpeas propose :
¾
des services collaboratifs : Agendas partagés, Annuaires, Documents partagés, Galerie
d’images, Blogs, Forums, Chat, Enquêtes, Messagerie instantanée, Notifications et
abonnements,
¾
des Workflows documentaires,
¾
des services de GED et de gestion de connaissances,
¾
un CMS (Content Management System)
¾
l’accès à d’autres applications (fonction portail)
L’outil permet donc à des utilisateurs, voisins ou géographiquement distants, de collaborer
autour de documents, de dossiers et de projets, etc…
Son ergonomie intuitive leur permet d’utiliser l’outil sans formation particulière.
70
2010
CHAPITRE IV
EXPERIMENTATION
Figure IV-1 : Présentation de Silverpeas.
Silverpeas est une application qui offre aux utilisateurs de :
¾
Fournir ou accéder à des données qui contiennent la connaissance de l’entreprise multisources (base documentaire, sites Web, etc…) ou multi-formes (document, publication
Web, mail, base de données, forum et agenda, etc…).
¾
Réaliser des actions en ligne, prendre des décisions dans des domaines d’activités variés
grâce aux ressources disponibles.
¾
Communiquer, collaborer et coordonner des travaux d’équipe.
¾
Mettre en place une stratégie et des outils de gestion de la connaissance (Knowledge
Management)
IV.2.2. La Structure de Silverpeas
La Figure IV-2 représente la structure de la plateforme Silverpeas, cette structure
constituée essentiellement d’un outil d’administration, de bus et un ensemble de service.
71
2010
CHAPITRE IV
EXPERIMENTATION
Service 1
Service 3
Service 4
BUS
Service 2
.
.
.
Service n
Administration
Figure IV-2 : Structure de Silverpeas.
IV.2.2.1. Administration
Le module d’administration permet d'agencer l’ensemble du portail. Il est essentiel car au
démarrage de Silverpeas, la première chose à faire est de structurer le portail : de créer les
Espaces, d’attribuer des rôles et de déployer les services.
L'administration est constituée de quatre volets :
¾
Outils : permet notamment d'importer des données dans Silverpeas à partir d'un fichier
XML.
¾
Statistiques : permet de gérer toutes sortes de statistiques. Par ex: la quantité de
publications stockées sur Silverpeas, combien de connexions il y a eu à une date
précise.
¾
Plan de Classement : contient les services « axe » et « synonyme ». Ces services
permettent de gérer le plan de classement.
¾
Administration : organise et gère le domaine, les espaces et le design des espaces.
IV.2.2.2. Le Bus
Le bus contient le savoir-faire pour animer les services et gérer les flux d’informations
internes à l’application et entre l’application et l’utilisateur comme les fonctionnalités ou les
services suivants :
72
2010
CHAPITRE IV
EXPERIMENTATION
¾
Moteur de recherche.
¾
Plan de classement
¾
Espace Personnel : comprend mon Agenda, mes Tâches, mes Notifications, mes
Abonnements, mes Requêtes favorites et mes Liens Favoris.
¾
Espaces Collaboratifs.
IV.2.2.3. Services
Des mini-applications réutilisables, chaque service remplit une mission. Les services
s'appuient sur le bus pour fonctionner. La structuration du portail Silverpeas se déroule en 5
phases :
¾
Création du référentiel des utilisateurs : saisie ou import des utilisateurs Silverpeas.
¾
Description de l’organisation : constitution de l’arborescence multi-niveaux des
utilisateurs, en relation avec l’organisation interne et externe de l’entreprise.
¾
Identification des espaces collaboratifs, reflétant l’organisation de la communication et
des groupes de travail dans l’entreprise.
¾
Instanciation des service pour chaque espace, permettant la mise en œuvre d’outils de
collaboration propres à chaque espace.
¾
Attribution des droits par service, les rôles étant propres à chaque service.
IV.2.3. L’architecture de Silverpeas
L'architecture de Silverpeas est de type "client léger" (aucune installation nécessaire
sur les postes clients) et s'appuie sur le standard J2EE (Java 2 Enterprise Edition).
La base de données est relationnelle (MS SQL et Oracle) utilisée pour stocker les
métas donnés, le système de fichier du système d’exploitation (Windows ou Unix) et les
pièces jointes, la plateforme silverpeas contienne aussi un serveur d'application J2EE (serveur
de page et Java Beans) : Weblogic, Websphere, Borland Enterprise Server, Orion ou JBoss
(Figure IV-3).
73
2010
CHAPITRE IV
EXPERIMENTATION
Figure IV-3 : Architecture de Silverpeas.
Cette architecture est celle retenue par les plus grandes entreprises et assure la
scalabilité de l'application pour une montée en charge importante. (pooling d’objet, loadbalancing, clustering, gestion des transactions)
Le langage JAVA est le langage objet standard de l’industrie, il assure :
¾
La portabilité (Linux, NT, Solaris, ….)
¾
La modularité.
¾
La maintenabilité.
¾
L’évolutivité.
XML (eXtensible Markup Language) est le langage de description de données, il assure :
¾
Une sémantique ouverte au contraire de HTML.
¾
Une grande souplesse dans la gestion des flux de données inter-applicatif.
IV.3. La plate-forme Xwiki
XWiki est un wiki Open-Source de seconde génération (ou "wiki applicatif") écrit en
Java. Il offre non seulement les fonctions principales d'un wiki (édition collaborative, suivi
d'informations, gestion de l'accès des membres), mais aussi des possibilités de développement
avancées
74
2010
CHAPITRE IV
EXPERIMENTATION
IV.3.1. Installation de Xwiki
Il y a plusieurs manières d'installer XWiki. La plus simple étant l'utilisation de
l'installateur Windows qui vient avec la base de données HSQLDB et le moteur web Jetty.
XWiki peut aussi s'exécuter sur tout conteneur de servlet récent (Tomcat, JBoss, GlassFish...)
et avec plusieurs bases de données relationnelles (comme HSQL et MySQL).
Dans notre implémentation, on utilisera Tomcat et MySQL. Tout d'abord, il faut
télécharger les deux fichiers XWiki, c'est à dire :
¾
xwiki-1.0.war qui contient l'application à proprement parlé
¾
xwiki-1.0.xar qui contient des modules XWiki déjà créés (le user admin, des panneaux,
des pages...).
IV.3.1.1. Configurer Tomcat
L'installation de XWiki dans Tomcat est très simple. Une fois votre Tomcat téléchargé
et installé, il suffit de décompresser le fichier xwiki-1.0.war dans le répertoire
%TOMCAT_HOME%\webapps\xwiki. ( ce répertoire sera nommé %XWIKI_HOME%.).
Lancer le serveur d'application tomcat en utilisant l'option Start Tomcat, attention les
ports 8080 et 8081 ne doivent pas être occupés par un autre serveur. Lancer un navigateur sur
l'url http://localhost:8080/admin.
Il faut saisir le nom de l'utilisateur et le mot de passe utilisés lors de l'installation (voirFigure
IV-4), après la page d’administration de Tomcat s’affiche (voir Figure IV-5)
Figure IV-4 : Ouverture de serveur Tomcat.
75
2010
CHAPITRE IV
EXPERIMENTATION
Figure IV-5 : La page d’administration Tomcat.
IV.3.1.2. Configurer MySQL
XWiki stocke ses pages dans une base de données. Il faut donc télécharger et installer
MySQL. Il faut ensuite créer une base pour XWiki, pour cela :
¾
On démarre MySQL (mysqld --console).
¾
On crée la base de données xwikiDB en tapant la commande mysql « user=root »
exécute="create database xwikiDB".
¾
On donne les droits d'accès à l'utilisateur xwikiUser (mot de passe xwikiPwd) sur la
base de données xwikiDB en tapant la commande mysql « user=root » execute="grant
all privilèges on xwikiDB.* to xwikiUser@localhost identified by 'xwikiPwd'".
¾
On vérifie que la base de données xwikiDB a bien été créé en tapant mysql
« user=root » execute="show databases".
XWiki utilise Hibernate comme moteur de persistance. Il faut donc lui fournir tous les
paramètres de connexion à la base de données xwikiDB. Pour cela, il faut modifier le fichier
%WIKI_HOME%\WEB-INF\hibernate.cfg.xml (voir Figure IV-6).
Figure IV-6 : Fichier Hibernate.
76
2010
CHAPITRE IV
EXPERIMENTATION
IV.3.1.3. Démarrer Xwiki
Il ne nous reste plus qu'à démarrer Tomcat (%TOMCAT_HOME% \bin\startup.bat) et
nous rendre à l'URL http://localhost:8080/xwiki. Une première page s'affiche sur notre
navigateur vous informant que l'installation de XWiki est imminente (voir Figure IV-7).
Figure IV-7 : Page d’ouverture de Xwiki.
Il nous suffit de cliquer sur le lien "XWiki Home Page" et d'attendre un petit moment,
le temps qu'Hibernate crée les tables dont XWiki a besoin. Si nous voulons voir la liste des
tables créées, on tape la commande suivante : mysql --user=xwikiUser --password=xwikiPwd
--database=xwikiDB --execute="show tables".
XWiki maintenant est configuré et la page d'accueil par défaut s'affiche (voir Figure IV-8).
Figure IV-8 : La page d’accueil par défaut de Xwiki
77
2010
CHAPITRE IV
EXPERIMENTATION
IV.3.2. Architecture de la plate-forme Xwiki
La Plate-forme XWiki propose des interfaces communes et des éléments de l'interface
utilisateur avec un ensemble de fichiers tel que : Figure IV-9
XWiki Core est un fichier JAR unique qui se fractionne en plusieurs modules distincts
et qui met actuellement en œuvre les fonctionnalités suivantes :
¾
Modèle : Toutes les classes représentant le modèle du wiki, c'est à dire les notions
suivantes: classes de documents, Espace, Wiki, et Objets, pièces jointes et plus encore.
¾
Cache : Il s'agit du service cache qui est utilisé pour éviter de recréer les pages de wiki
à partir de la base de données pour chaque utilisateur.
¾
XWiki Syntax : un service utilisé pour la gestion de la syntaxe.
¾
Localisation: Gère les traductions dans différentes langues.
¾
Notification : Utilisée pour exporter n’importe quel type de document (PDF, RTF,
XAR).
¾
Sécurité: Authentification et autorisation de manutention.
Figure IV-9 : L’architecture de la plate-forme Xwiki
IV.4. Quelques scénarios de test
La Figure IV-10 montre la page d’accueille de la plate forme Silverpeas avec ces
différentes services.
78
2010
CHAPITRE IV
EXPERIMENTATION
Figure IV-10 : La fenêtre d’accueille de l’application
IV.4.1. L’espace personnel
La Figure IV-11 montre un exemple de l’espace personnel, où on trouve différentes
services tels que : l’agenda, les taches, les notifications, les abonnements, les requêtes
favorites, les liens favoris, personnalisation, écrire à l’administrateur et la presse papier.
Figure IV-11 : Rubriques de l’espace personnel
¾
Mon agenda : Il permet de:
9 Planifier tout type d’événement à la journée, à la semaine, au mois ou à l’année.
9 Inviter d'autres utilisateurs à un événement.
9 Consulter les disponibilités des utilisateurs que l'on souhaite inviter.
9 Refuser ou accepter une invitation
¾
Mes tâches : Vous avez la possibilité de définir des tâches, spécifier l’avancement, la
date de début, de fin, la classification (privée, publique) ainsi que la priorité de la tâche
à effectuer.
79
2010
CHAPITRE IV
¾
EXPERIMENTATION
Mes notifications : Permet de vous tenir informé de certaines nouveautés (une nouvelle
publication par exemple). Vous en serez informé par courrier dans votre messagerie
personnelle, votre boîte de notification, ou encore par une fenêtre pop-up.
¾
Mes abonnements : Vous pouvez vous abonner à des thèmes et recevoir ensuite des
notifications quand une nouvelle publication est faite dans ce thème.
¾
Mes requêtes favorites : Lorsque l’on cherche des données (en général des
publications), on peut utiliser les options de recherche avancée pour cibler un peu plus
la recherche. Il s’agit de requêtes. Vous pouvez ainsi enregistrer vos requêtes favorites,
lorsque celles-ci sont effectuées régulièrement.
¾
Mes liens favoris : Possibilité de spécifier des thèmes ou des fichiers favoris.
¾
Personnaliser : Possibilité de changer votre mot de passe, votre langue d’interface,
votre espace d’accueil, votre e-mail, vos coordonnées, de désactiver les applets et
activeX (glisser-déposer et intégration MS Office).
¾
Ecrire à l’administrateur : Pour suggérer une amélioration, signaler une anomalie.
¾
Presse papier : Permet de visualiser et supprimer des éléments copiés ou coupés dans
le presse papier (publications, thèmes, services, espaces).
IV.4.2. Moteur de recherche
Il permet de retrouver les différentes publications créées dans la plupart des services
2
de Silverpeas à partir de mots clés, de classements, de services, de formulaires, etc…
Les documents trouvés sont ensuite listés par ordre de pertinence décroissante, et
peuvent être exportés. Il est aussi possible de mémoriser une recherche pour la relancer plus
tard.
IV.4.3. Barre D’outils
Dans la barre d’outils on trouve plusieurs liens tels que (voirFigure IV-12) :
¾
Glossaire (définition de vocabulaires spécifiques à la société).
¾
Plan du site (Arborescence des espaces (personnel et autres).
¾
Aide détaillée sur la plate forme.
¾
Administration
80
2010
CHAPITRE IV
EXPERIMENTATION
Figure IV-12 : Barre d’outils
IV.4.4. Page d’accueil
Cette page peut être personnalisée (choix de portlets, page HTML, ou service particulier)
IV.4.5. Logo Silverpeas
Pour retourner à la page d’accueil de Silverpeas, on clique sur le logo Silverpeas (ou
bien le logo personnalisé)
IV.4.6. Espaces et Services
On utilisant ce volet pour accéder aux espaces, les sous-espaces collaboratifs et les services
accessibles
IV.5. Les services de la plate-forme
La plate-forme collaborative Silverpeas contienne plusieurs services comme il est illustré dans
la Figure IV-13.
Figure IV-13 : Liste des services disponibles
81
2010
CHAPITRE IV
EXPERIMENTATION
Pour ajouter un service dans un espace, on a choisi dans la liste d’opérations située en
haut à droite, l’icône « Ajouter un service ». Pour avoir des explications sur les différents
services, on glisse la souris au dessus de l’icône, une bulle apparaît qui explique le service.
IV.5.1. Attribution des Rôles
Il est possible de définir des droits au niveau espace ou au niveau service, si des droits
sont définis au niveau espace, tous les services qui y sont installés, en héritant par défaut, mais
il est possible de les modifier.
Pour chaque service on définit des rôles qui induisent des droits d’utilisation
différents. Il y a de 2 à 4 rôles selon le service :
¾
Gestionnaire : il organise et structure le composant en gérant les thèmes, les dossiers,
les forums, les consultations.
¾
Publieur : il alimente et gère le contenu, les publications, les articles, les documents,
les événements, etc…
¾
Rédacteur : il rédige des publications soumises à validation.
¾
Lecteur : son rôle est présent dans tous les services tel que la consultation et la
participation si c'est possible.
IV.6. Créer un espace ou un sous espace
Pour créer un espace on sélectionne l’option « Créer un espace » Dans la liste des
opérations accessibles dans l’onglet « gestion d’espace». Par exemple, on peut créer un espace
« université badji mokhtar annaba » sur la base d’un modèle d’espace (paramétrable en
XML), dans le champ modèle d’espace on sélectionne « tous les composants » afin d’installer
automatiquement tous les services disponible dans la plate-forme (voirFigure IV-14).
82
2010
CHAPITRE IV
EXPERIMENTATION
Figure IV-14 : Création d’un espace ou d’un sous-espace
Après la création de l’espace « Université Badji Mokhtar Annaba », ce dernier
apparaîtra dans la page d’accueil de la plate forme avec tous les services disponibles (voir
Figure IV-15).
Figure IV-15 : Espace université badji mokhtar annaba.
IV.7. Ouvrir Xwiki
Pour atteindre la page d’accueille de la plate-forme Xwiki, on va sélectionner dans la
liste des services le service wiki qui nous permettre de modifier les pages online (voir Figure
IV-16). Apres la sélection du service wiki la page d’accueil de la plate forme Xwiki s’affiche
(voir Figure IV-17).
83
2010
CHAPITRE IV
EXPERIMENTATION
Figure IV-16 : le lien de service wiki
Figure IV-17 : Service Wiki de la plate-forme
IV.8. Conclusion
Nous avons vu dans ce chapitre une expérimentation sur l’utilisation et le déploiement
de nos deux plates-formes. La première qui s’appelle Silverpeas, elle offre aux utilisateurs les
différents outils de collaboration asynchrones, et la deuxième qui s’appelle Xwiki qui offre le
service wiki.
84
2010
CONCLUSION GENERALE & PERSPECTIVES
CONCLUSION GENERALE
&
PERSPECTIVES
85
Chemame Chaouki
Conclusion
Les travaux de recherche développés dans ce mémoire s’inscrivent dans le domaine
des plates-formes collaboratives intégrant les différents outils de collaboration (synchrones et
asynchrones). Plus précisément, nous avons proposé une approche générale pour créer un
environnement collaboratif qui se base sur les différents outils de collaborations synchrones
s’appuyant sur une intégration d’applications collaboratives (ou collecticiels) existantes.
Dans le premier chapitre de ce mémoire nous avons présenté l’architecture orienté
service et nous avons consacré le deuxième chapitre pour illustrer les différents outils de
collaborations, leurs domaines d’application, en citant les différentes approches de
développement avec leurs avantages et limitations. Ceci pour pouvoir positionner notre
approche, qui se base sur une architecture orientée services basés sur l’intégration des platesformes dans le but d’accomplir une tache collaborative dans un domaine bien précis.
Comme notre approche est basée sur les architectures orientées services, nous avons
expliqué en détail le concept général de cette architecture qui constitue la prochaine vague de
développement et qui comprend des propriétés spécifiques, des composants et des
interconnexions qui mettent l’accent sur l’interfonctionnement et la transparence
d’emplacement.
Dans le troisième chapitre, nous avons proposé une approche générale pour concevoir
un environnement collaboratif simple et extensible. Cette approche se base sur l’intégration
d’applications existantes en utilisant le principe des services web qui est une nouvelle
technologie permettant l’interopérabilité et l’extensibilité des applications.
Dans la pratique ceci nous a conduit de choisir deux plates-formes existantes open
source, la première plate-forme Silverpeas qui offre des outils de collaboration en générale
synchrones en les exposant comme étant des services web, et la deuxième plate-forme xwiki
pour l’édition collaborative et le suivi d'information.
Donc notre but était de proposer un environnement collaboratif qui offre des outils
collaboratifs asynchrones le forum, email, gallérie d’images, news, wiki, quiz,…etc. et nous
avons implémenté cet environnement avec l’utilisation des services web et les plates-formes
open source. Nous avons testé avec succès notre plate forme ce qui rendre l’intégration et
l’extensibilité des plates-formes possible. Ce qui présente l’intérêt majeur de l’utilisation des
services web.
86
2010
Limitations et perspectives
Des limitations peuvent être observées dans notre approche, parmi les quelles on peut citer :
¾
L’approche est basée sur l’intégration des applications par le billet des services web,
donc l’implémentation va se baser sur les propriétés des deux plates-formes.
¾
La plate-forme n’a pas été testée sur un grand réseau et avec un nombre important de
participants, où d’autres problèmes peuvent surgir.
Les améliorations que nous proposons sont les suivantes :
¾
Notre premier objectif consiste à compléter l’implémentation de notre approche surtout
par l’intégration d’autres outils de collaborations asynchrone et synchrone pour rendre
notre environnement plus complet.
¾
Notre deuxième objectif consiste à poursuivre nos travaux pour une mise en œuvre
complète d’un environnement collaboratif qui ne se base pas uniquement sur
l’intégration des plates-formes basées sur des services web, mais peut aussi intégrer
d’autres plates-formes client serveur. Cela se fait par l’implémentation d’un module
constitué d’un ensemble de services qui permet d’intégrer un maximum des platesformes et d’outils de collaboration en les considérant comme étant des boites noires
(c'est-à-dire sans modifier leurs codes internes).
87
2010
REFERENCES BIBLIOGRAPHIQUES
88
Chemame Chaouki
Références
[1] W3C-WSA-Group (2004). W3C Web Service Architecture Group. Web
[2] W3C-XML. XML coordination group.
[3] Goldfard, C.-F. (1990). The SGML Handbook. Oxford Clarendon Press.
[4] OASIS UDDI (2005). Universal Description, Discovery and Integration version
[5] W3C-WSD-Group. Web Services Description Working Group.
[6] Kaler, C. and Nadalin, A. Web services security policy language (wssecuritypolicy)
[7] Origine des normes SGML, HTML et XML, Standard Generalized Markup, Language,
http://www.jalix.org/ressources/miscellaneous/infodoc/_Loria-Evry/04.xml.pdf
[8] Eric van der Vlist, “Le tryptique SOAP/WSDL/UDDI ”, Web service convention, juin
2004. http://dyomedea.com/papers/2004-wsc/3-soap.pdf
[9] Mohamed Karami, “Déploiement et Appel aux web services java avec Axis”.
http://superdown.sourceforge.net/Pages/wsaxis/wsaxis.pdf
[10] Yasser shohoud, “Introduction to WSDL”.
http://w2ks.dei.isep.ipp.pt/labdotnet/recursos/wsdl.pdf
[11] Benatallah, B., Dumas, M., Fauvet, M.-C., Rabhi, F.A., Sheng, Q.Z.
[12] Peltz, C. Web Services Orchestration and Choreography. IEEE Computer,
2003, vol.36, n°10, pp.46-52.
[13] Barros A., Dumas, M., Oaks, P. Standards for Web Service Choreography and
Orchestration: Status and Perspectives. In: Procs of the 3rd International Conference the
Business Process Management (BPM 2005), 1st International Workshop on Web Service
Choreography and Orchestration for Business Process Management, Nancy, France, Sept.
2005, pp.1-15.
[14] Benatallah B., Dijkman R., Dumas M., Maamar Z. Service Composition: Concepts,
Techniques, Tools and Trends. In: Stojanovic Z., Dahanayake A., Eds. Service-Oriented
Software Engineering: Challenges and Practices. Idea Group Inc (IGI), 2005, pp.48-66.
[15] Arkin, A., Askary, S., Fordin, S., Jekeli, W., Kawaguchi, K., Orchard, D.,
Pogliani, S., Riemer, K., Struble, S., Takacsi, P., Trickovic, I., Zimek, S. Web Service
Choreography Interface (WSCI) 1.0. W3C Note [en ligne], 2002. Disponible sur :
<http://www.w3.org/TR/wsci>.
[16] Leymann F. Web Service Flow Language 1.0. IBM Report [en ligne], 2001.
Disponible sur : <http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf>.
[17] Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F.,
Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S. Business Process
Execution Language for Web Services, Version 1.1. IBM Specification [en ligne], 2003.
89
2010
Disponible sur : <http://www-128.ibm.com/developerworks/library/specification/ws-bpel>.
[18] Wynen F. Conception et développement d’une plate-forme de coopération
inter-organisationnelle : le point de synchronisation. Mémoire d’ingénieur CNAM –
Conservatoire Nationale des Arts et Métiers, Nancy, 2003, 102p.
[19] N. Arenaza, Composition semi-automatique de Services Web, Projet de Master,
Ecole Polytechnique Fédérale de Lausanne (EPFL), Février 2006.
http://lawww.epfl.ch/webdav/site/la/users/139973/public/repports/Rapport- Arenaza.pdf
[20] S. Jamal (épouse Sanlaville), Environnement de procédé extensible pour l’orchestration :
Application aux services Web, Thèse présentée et soutenue publiquement le 13 Décembre
2005 pour l'obtention du Doctorat de l'Université Joseph Fourier de Grenoble I.
http://tel.archives-ouvertes.fr/docs/00/05/38/31/PDF/TheseSonia.pdf
[21] J. Guitton, Planification multi-agent pour la composition dynamique de services Web,
Université Joseph Fourier, Grenoble I, Informatique et Mathématiques Appliquées, Rapport
de stage Master 2 Recherche, Juin 2006.
http://www.cert.fr/dcsd/THESES/jguitton/papers/guitton-master-06.pdf
[22] H. D. Rojas, Orchestration à haut niveau et BPEL, Master Mathématiques Informatique
2e année, Recherche Spécialité Systèmes et Logiciels, Soutenu le 21 juin 2006, Université
Joseph
Fourier
de
Grenoble.
http://www-adele.imag.fr/Les.Publications/reports/
M2R2006Roj.pdf
[23] Y. Charif, Chorégraphie dynamique de services basée sur la coordination d’agents
introspectifs, Thèse de doctorat, université pierre et marie curie, paris IV, 10 Décembre 2007.
http://www-poleia.lip6.fr/~sabouret/ps/yasmine-PhD.pdf
[24] H. Duarte Amaya, Tcows : Canevas pour la composition de services web avec propriétés
transactionnelles, Thèse présentée et soutenue publiquement le 13 Novembre 2007 pour
l'obtention du Doctorat de l'Université Joseph Fourier.
http://tel.archives-ouvertes.fr/docs/00/19/29/24/PDF/TheseHelgaDuarteAmaya.pdf
[25] guide pratique des outils de collaboration, Une production du Centre des lettres et des
mots (CLEM),
[26] Recherche et rédaction : Mario Breton, Brigitte Juteau, Bernard Hudon et Martin Lauzon
[27] Graphisme et mise en page : Mario Breton et Martin Lauzon
[28] Coordination du projet : Bernard Hudon
[29] http://www.nald.ca/clrf/guide/titre.htm.
[30] I. Salah, A. Kadmi, E. Reyes, L’hypermédia au service du travail collaboratif, Juin
2005, édition Hermès.
90
2010
ANNEXE
ANNEXE
91
Chemame Chaouki
ANNEXE
GLOSSAIRE
Ajax (Asynchronous Java Script and XML) désignant une solution informatique libre pour
le développement d’applications web. Ajax n’est pas une technologie en elle-même, mais un
terme qui évoque l’utilisation conjointe d’un ensemble de technologies libres couramment
utilisées sur le web par exemple (XML et HTML).
Apache Apache HTTP Server, souvent appelé Apache, est un logiciel de serveur HTTP
produit par l’Apache software fondation. C’est le serveur HTTP le plus populaire du Web.
C’est un logiciel libre avec un type spécifique de licence, nommée licence Apache.
BSD (Berkeley Software Distribution) c’est une licence libre utilisée pour la distribution de
logiciels. Elle permet de réutiliser tout ou une partie du logiciel sans restriction, qu’il soit
intégré dans un logiciel libre ou propriétaire.
CORBA (Common Object Request Broker Architecture) est une architecture logicielle
pour le développement de composants et d’ORB (Object Request Broker).ces composants qui
sont assemblés afin de construire des applications complètes, peuvent être écrits dans des
langages de programmation distincts, être exécutés dans des processus séparés, voire être
déployés sur des machines distinctes.
Framework est un ensemble de bibliothèques, d’outils et de conventions permettant le
développement
d’applications.il fournit suffisamment de briques logicielles et impose
suffisamment de rigueur pour pouvoir produire une application aboutie et dont la maintenance
est aisée.ces composants sont organisés pour être utilisés en interaction les uns avec les autres.
GPL (Licence Publique Générale) c’est une licence qui fixe les conditions légales de
distribution des logiciels libres du projet GNU.
HTML (HyperText Markup Language) Langage de balise servant a la publication de
pages web sur internet.les bases de HTML ont été développées dans le but de pouvoir écrire
des documents hypertextes liant les diverses ressources d’internet.
HTTP (Hypertext Transfer Protocol) le protocole de transfert hypertexte est un protocole
de communication client-serveur développé pour le World Wide Web.il est utilisé pour
échanger toute sorte de données entre un client http et un serveur http.
JAVA Java est à la fois un langage de programmation et une plateforme d'exécution. Le
langage Java a la particularité principale d'être portable sur plusieurs systèmes d'exploitation
tels que Windows, MacOS ou Linux. C'est la plate-forme qui garantit la portabilité des
applications développées en Java.
92
2010
ANNEXE
J2EE (Java Entreprise Edition) est spécification pour la technologie Java de Sun plus
particulièrement destinée aux applications d’entreprise .
JRE (Java Runtime Environment) ou environnement d’exécution java, c’est un ensemble
d’outils permettant l’exécution de programmes java sur toutes les plates-formes supportées.
La JRE est constituée d’une JVM (machine virtuelle JAVA) pour interpréter le code java et le
convertir en code natif, et d’une bibliothèque standard à partir de laquelle doivent être
développés tous les programmes en java.
MySQL est un système de gestion de base de données (SGBD) développé dans un souci de
performances élevées, ce qui signifie qu’il est d’avantage orienté vers le service de données
déjà en place que vers celui de mises a jour fréquentes et sécurisées.il est multi-thread et
multi-utilisateurs.
ORB (Object Request Broker) est l’ensemble de fonctions (classes Java, bibliothèque, C++,
etc…), qui implémentent un bus logiciel par lequel des objets envoient et reçoivent des
requêtes et des réponses, de manière transparente et portable : il s’agit de l’activation ou de
l’invocation par un objet, et a distance d’une méthode d’un autre objet distant.
PDA (Personal Digital Assistant) est un assistant personnel ou un ordinateur de poche basé
sur le principe d’une calculatrice évoluée, il sert d’agenda, de carnet d’adresses et de blocnotes.il est doté d’un clavier, avec des petites touches ou d’écran tactile, associé alors a un
stylet.
PDF (Portable Document Format)
le format de document portable généralement abrégé
PDF, est un format de fichier informatique créer par Adobe Systems .c’est un format ouvert
dont les spécifications sont publiques et utilisables librement et gratuitement.il est dérivé du
format PostScript et contient des données au format XML.
P2P (Peer-To-Peer) souvent abrégé “P2P”, est un modèle de réseau informatique qui
s’oppose strictement au modèle client-serveur. Le partage des fichiers avec ce type de réseau
se fait d’égal à égal, c’est-à-dire les différentes machines ont à la fois le rôle de serveur et du
client.
RPC (Remote Procedure Call) est un protocole permettant de faire des appels de procédures
sur un ordinateur distant à l’aide d’un serveur d’application. Ce protocole est utilisé dans le
modèle client-serveur et permet de gérer les différents messages entre ces différentes entités.
93
2010
ANNEXE
SQL (Structured Query Language) le langage structuré de requêtes est un pseudo-langage
informatique (de type requête) standard et normalisé, destiné à interroger ou à manipuler une
base de données relationnelles.
W3C (World Wide Web Consortium) abrégé par le sigle W3C, est un organisme de
standardisation a but non lucratif ,fondé en octobre 1994 comme un consortium « association
ou collaboration temporaire » chargé de promouvoir la compatibilité des technologies du web
telles que XML,HTML,RDF,CSS,SOAP,etc…
XPath est le langage de requêtes élémentaire dans XSLT, il détermine si une règle s’applique
Via son attribut, et peut aussi servir à extraire des contenus du document XML transformé
par le programme XSLT.
XPath peut être utilisé comme langage de requêtes dans les bases de données XML, souvent
en tant que sous-ensemble de X-Query.
XSL (eXtensible Stylsheet Language) c’est le langage de description de feuilles de style du
W3C associé à XML.une feuille de style XSL est un fichier qui décrit comment doivent êtres
présentés Les documents XML basés sur une même définition de type de documents (DTD)
ou un même schéma.
XSLT (eXtensible Stylsheet Language Transformations) défini au sein de la
recommandation XSL du W3C comme étant un langage de transformation d’un document
XML vers un autre, que ce soit un dialecte XML (XHTML, XSL-FO, HTML, ...etc) ou bien
un autre type de document.
94
2010

Implémentation d`une infrastructure collaborative asynchrone basée

Transcription

Documents pareils

LATIN 5e séquence 3 MAGISTER ET DISCIPULI

Edito Newsletter - Patrouilles Tranchant

“1900”de MARIUS FABRE

Edito Newsletter - Patrouilles Tranchant

Hamli Ben Zahar Hamid

Les Services Web

Savon - Soap - Ugarit Maison de l`Artisanat

Développement sur mesure

Plate-forme automotrice