Mémoire de fin d'études esiea - Free

2009 

Mémoire de fin d’études 

esiea 

Portail d’Architecture et environnement 

collaboratif – Opportunités du Web 2.0 et des 

portlets 

Enterprise architecture portal and collaborative 

environments: Opportunities of Web 2.0 and 

portlets 

Société : Arismore à Saint-Cloud (92) 

Président de Jury, Tuteur, Parrain : 

Mr Lambarki, Mr Tonnelier, Mr Doriot 

Benjamin Petitprez 

Arismore 

03/03/2009

Table des matières 

[MEMOIRE DE FIN D’ETUDES ESIEA] 3 mars 2009 

Remerciements ....................................................................................... 4 

Résumé ................................................................................................. 5 

Introduction générale ............................................................................... 7 

Introduction ......................................................................................... 7 

Contexte ................................................................................................ 9 

Arismore : Une société innovante en forte croissance .............................. 9 

Organisations des stages chez Arismore ...............................................13 

Contexte du stage ............................................................................14 

Architecture d’entreprise et Urbanisme .......................................................17 

Introduction ........................................................................................17 

Définition ........................................................................................17 

Architecture et Urbanisme à l’heure actuelle ..........................................18 

Les Framework ....................................................................................18 

Zachman .........................................................................................18 

Le TOGAF ........................................................................................19 

Autres.............................................................................................20 

Etude d’une démarche d’architecture idéale .............................................21 

Le modèle en couche .........................................................................21 

Le métier ........................................................................................22 

Le fonctionnel ..................................................................................25 

L’applicatif .......................................................................................30 

Le technique ....................................................................................34 

Le bilan ..............................................................................................36 

Synthèse technique du projet ...................................................................37 

Présentation détaillée du sujet ...............................................................37 

Les différentes phases du projet .............................................................38 

Phase d’étude ..................................................................................38 

Principaux besoins attendus ...............................................................44 

Solutions techniques apportées aux demandes de besoins .......................49 

Phase de conception.............................................................................50 

Objectifs .........................................................................................50 

Description globale de l’architecture logicielle ........................................50 

Comment cette architecture répond aux cas d’utilisation .........................51 

Arismore | Remerciements 2


Présentation des différentes interactions...............................................53 

Résultats obtenus ...................................................................................56 

Difficultés rencontrées .............................................................................58 

Conduite de projet ..................................................................................59 

Conduite de projet ..................................................................................59 

Première phase : Travail seul.................................................................59 

Deuxième phase : Travail en équipe .......................................................62 

Conclusion .............................................................................................64 

Bibliographie ..........................................................................................66 

Glossaire ...............................................................................................67 

Annexes ................................................................................................68 

Grilles d’évaluation des différents portails ................................................69 

Liferay ............................................................................................69 

JBoss Portal .....................................................................................73 

Jetspeed .........................................................................................75 

Différence Flex/Ajax .............................................................................78 

Présentation ....................................................................................78 

Description détaillée d’Ajax ................................................................81 

Librairies .........................................................................................82 

Description détaillée de Flex ...............................................................85 

Communication Flex ..........................................................................86 

Mise en place d’une Portlet Client Riche (Flex) ..........................................88 

Présentation des différentes technologies utilisées ....................................89 

Les portlets JSR-286 .........................................................................89 

Java Content Repository JSR-170 ...........................................................94 

Réunion de travail avec Olivier Tonnelier .................................................95 


Remerciements 


Je voudrais dans un premier temps remercier toute l’équipe Arismore qui a 

facilité mon intégration dans l’entreprise. 

Et plus particulièrement, Olivier Tonnelier qui me guida, m’orienta et me 

forma aux bonnes pratiques de travail en entreprise. Je remercie également 

Johan Brelet qui m’épaula tout au long de mon stage sur les différentes parties 

techniques. 

Je tiens à remercier l’équipe de travail (Johan Brelet, Julien Lefebvre et 

Jean-Christophe Bohin) qui c’est construite vers la fin de mon stage, pour 

m’avoir intégré au sein d’une vraie équipe projet et ainsi avoir pu connaître les 

enjeux et les différentes démarches de travail que peut amener cette 

organisation. 

Je remercie également Mr Guy Doriot, qui a accepté de me suivre tout au 

long de ce stage de fin d’étude. De plus, j’en profite pour remercier toute l’équipe 

enseignante du MIC esiea (Mr Jean-Paul Vedel, Mr Gérard Delatour et Mr. Guy 

Doriot) pour la clarté de leur formation. 

Je remercie également tout le corps enseignant de l’esiea, qui m’a permis 

de m’épanouir lors de ces cinq dernières années, qui m’a donné l’opportunité de 

côtoyer différents domaines et environnements de travail. 

Je remercie également tous les élèves de ma promotion 2008, avec qui j’ai 

partagé et avec qui je partage toujours de très bons moments qu’il soient d’ordre 

amical ou professionnel. 

Et pour finir, je remercie Mr Lambarki, Mr Guy Doriot et Mr Olivier 

Tonnelier pour leurs présences lors de ma soutenance de fin de stage. 


Résumé 


Ce stage a été effectué dans le cadre du stage de fin d’étude de l’esiea. Il 

a été effectué au sein de la société Arismore basée à Saint-Cloud (92). Arismore 

est une jeune société dynamique en pleine croissance composé d’une centaine de 

salariés. Le cœur de métier de cette société est l’architecture d’entreprise et le 

conseil d’entreprise. 

Mon stage, intitulé portail d’Architecture et environnement collaboratif : 

Opportunités du Web 2.0 et des Portlets, a été effectué au sein du pôle 

innovation d’Arismore. Il possède donc un fort enjeu, d’une part par l’utilisation 

de nouvelles technologies (Portail, Portlet, Client riche, Système de gestion de 

contenu) et d’autre part par l’attrait de clients par une telle solution qui n’existe 

pas encore sur le marché. 

Afin de définir ce portail d’architecture, il faut bien comprendre ce qu’est la 

technologie de portail Web. Un portail Web est un environnement constitué de 

plusieurs Portlet ou mini applications interagissant entre elle (messagerie, forum, 

wiki, annuaire…). Il existe également des portails d’entreprise qui servent de 

serveur de gestion de document ou d’espace de collaboration. Contrairement à 

ces portails qui sont orientés ressources, notre portail d’architecture est plus 

orienté processus et objectifs. Le travail de l’architecte lui impose la production 

de rapports expliquant différentes solutions. L’accumulation, la redondance ou le 

suivi de ces rapports est un des principaux problèmes des entreprises. C’est 

pourquoi, ce portail s’inscrit dans un projet d’innovation car il permettra d’éviter 

la redondance des informations et surtout permettra de réaliser un réel suivi des 

rapports produits. 

Notre portail d’Architecture permettra de sélectionner via un bandeau de 

navigation, représentant un processus (Process, Activity, Task), un document 

qui pourra être édité en ligne en suivant un certain template préalablement 

défini. Ce document s’appuiera directement sur les références du Système 

d’Information (SI) de l’entreprise. Ainsi toute modification sur le SI sera 

Arismore | Résumé 5


immédiatement reflétée sur les documents produits. Et ainsi, une simple reprise 

du document sera nécessaire pour la mise à jour. 

Mon stage c’est entièrement déroulé dans les locaux d’Arismore. On peut 

le décomposer en 4 phases successives. Une première a été la compréhension de 

la documentation autour du sujet et des technologies à utiliser. La seconde a été 

une phase de spécification qui a été de mettre en adéquation mes recherches 

avec les attentes du projet. Une troisième a été une phase de développement de 

ces différentes fonctionnalités. Puis la dernière phase a été l’intégration a une 

équipe projet qui c’est construite sur le portail d’Architecture. J’ai donc côtoyé le 

réel travail en équipe autour d’un modèle agile, ce qui signifie qu’on avance par 

petites itérations rapides. Ceci dans le fait que les différents acteurs du projet 

pouvaient à tout moment rejoindre un autre projet. 

Pour conclure, ce stage a été très fructueux. J’ai pu me former à de 

nombreuses et innovantes technologies, ce qui est un grand plus pour se 

positionner sur le marché de l’emploi. De plus, l’équipe Arismore a été très 

accueillante et très disponible pour répondre à mes questions. 

Enfin, ce stage m’a permis de trouver un emploi, puisque Arismore 

m’embauche dès le 16 Février 2009. 

Arismore | Résumé 6


Introduction générale 

Introduction 

Ce stage s’inscrit dans la continuité de l’enseignement de l’esiea et de la 

volonté de faire connaître aux étudiants, dès leur première année, le monde 

professionnel de l’entreprise. Ceci par la pratique de nombreux stages (ouvrier, 

technique, à l’étranger et de fin d’étude). Cette dynamique permet à l’étudiant 

d’appréhender de la meilleure des façons ce dernier stage de 9 mois. 

Arismore, étant une jeune entreprise avec une forte croissance et une 

importante dynamique, attire de nombreux étudiants pour la réalisation de leurs 

stages de fin d’étude. Un des points forts de cette société est l’attractivité et 

l’intérêt porté aux stages proposés. En effet, les sujets proposés sont établis de 

façon à apporter une utilité aux réflexions, aux études, et aux futurs projets de la 

société. Ils présentent donc un réel centre d’intérêt commun au stagiaire et à 

l’entreprise. 

Le stage que j’ai choisi entre donc tout a fait dans cette perspective. Le 

projet proposé, se basant sur une réflexion et l’étude de différentes technologies 

proposées par le monde Open Source, s’ouvre sur la réalisation d’une maquette 

de portail d’architecture en fin stage. Cette étude s’ouvre sur la mise en place 

d’un réel projet interne à la société qui aboutira par sa commercialisation fin 

2009. 

Afin de bien comprendre les différents enjeux de ce stage, il faut tout 

d’abord présenter le métier d’Arismore. Je continuerai en menant une analyse 

sur le métier de l’architecture d’entreprise qui joue un rôle primordial dans un 

portail d’architecture et qui présente le cœur de métier d’Arismore. Je poursuivrai 

avec une présentation détaillée du sujet pour mieux comprendre les opportunités 

Arismore | Introduction générale 7


de la mission. Puis je détaillerai les différentes phases menées lors de ce stage 

en apportant, avec le recul, une analyse sur les choix pris. Pour terminer, je 

mènerai une réflexion sur la façon dont j’ai conduit ce projet durant les sept 

premiers mois et comment je me suis intégré à l’équipe projet mise en place par 

la suite. 

Arismore | Introduction générale 8

Contexte 


Arismore : Une société innovante en forte croissance 

Arismore en bref 

Arismore depuis sa création accompagne la transformation des systèmes 

d’information de très grandes entreprises et de grandes organisations. 

Le rythme des changements des entreprises et des organisations impose 

de transformer le système d’information pour améliorer certaines 

caractéristiques parfois contradictoires : l’agilité, la performance, la sécurité et la 

maturité. 

Ainsi l’accompagnement de ces évolutions depuis plusieurs années ont 

permis de capitaliser au sein d’Arismore sur l’usage de nouvelles pratiques de 

management et de nouvelles technologies. 

Fort de son investissement et de son expérience, Arismore est devenu le 

spécialiste en France du conseil en Architecture d’Entreprise et de la 

construction de services partagés; ce qui se traduit auprès des clients par : 

La réalisation de prestation de conseil en 

Stratégie et Gouvernance des systèmes d’information 

Architecture des systèmes d’information 

La conception et l’intégration de solutions 

Gestion des accès et des identités 

Gestion de la qualité de service, 

SOA (Architecture Orientée Services) 

La diffusion des bonnes pratiques avec un centre de formation et de 

certification : 

Arismore | Contexte 9


Architecture d’entreprise 

TOGAF : The Open Group Architecture Framework 

ITIL 

Convergence telecom : IMS : IP Multimedia Subsystem 

Le Chiffre d’Affaires d’Arismore est de 8 420 K€ avec un résultat de 730 K€ 

au 31 Mars 2008. 

axes : 

Innovation et Croissance rentable 

Arismore investit 8% de son chiffre d’Affaires en innovation sur deux 

Les technologies en rupture et leurs usages 

Les méthodes et outils d’Architecture d’Entreprise 

Ainsi, Arismore s’est positionné sur des domaines à forte valeur ajoutée 

auprès des directions des systèmes d’information et des opérateurs télécom, 

notamment pour mettre en œuvre des projets innovants et critiques tant pour 

leur impact métier que pour leur transversalité. 

D’une part Arismore est identifiée comme une PME innovante en forte 

croissance par le Ministère des PME et par OSEO et d’autre part obtient depuis 

trois années consécutives la note G3, attribuée par la Banque de France, pour 

récompenser sa santé financière. Cette note correspond à la note maximum de 

sa catégorie. 



Engagement et relation de confiance 

Arismore inscrit sa relation avec ses clients dans la durée, de part sa 

démarche qui repose sur son engagement forfaitaire, la transparence dans sa 

relation, la focalisation sur l’atteinte des objectifs, son indépendance et des 

convictions affichées. 

Cela se traduit par un taux de fidélité de 100% et un mode de contractualisation 

innovant. 

Les cinq plus grands clients d’Arismore sont : 



L’équipe Arismore 

L’organisation d’Arismore s’articule autour de 3 Domaines d’Activités 

Métier (DAM) et d’un pôle d’innovation ArisLabs. Ces 3 DAM sont chevauché par 

différents Domaines d’Expertise Métier (DET) qui jouent un rôle transverse sur 

l’ensemble des 3 DAM. Ces différents DET représente les différents pôles de 

compétence du métier d’Arismore. 



Organisations des stages chez Arismore 

Les stages chez Arismore sont conçus comme un vecteur d’intégration 

dans la société sous la forme d’un premier échange entre la société et le futur 

employé. 

Dans l’esprit de dynamique de l’entreprise et de croissance actuelle des 

équipes, les stages sont une collaboration de pré embauche. 

Le stagiaire travaille directement sur des sujets qui intéressent 

directement l’une des offres et activités de la société. Il est amené à contribuer à 

une capitalisation, à l’animation du savoir-faire et au développement des 

compétences au sein de la société, à titre individuel et collectif. 

Le processus de recrutement est donc similaire à un processus 

d’embauche avec des entretiens avec le directeur de projet et le directeur 

technique. 

Un entretien de fin de stage est effectué avec le tuteur. Ceci dans le but 

d’avoir un ressenti sur le travail effectué et d’ouvrir une discussion sur les 

potentielles opportunités d’embauches. 



Contexte du stage 

Etant entré dans la cellule innovation d’ArisLabs, je me suis inscrit sur un 

projet d’innovation, de recherche et de conception. 

Le contexte du stage fut donc d’étudier dans un premier temps les 

solutions innovantes de l’apport du Web 2.0, les technologies portails et les 

solutions de gestion de contenu. 

Objet du projet 

Sujet de stage 

Ce sujet de stage peut se découper en plusieurs objectifs complémentaires : 

Le premier objectif est celui de l’analyse des fonctionnalités des 

portails, portlets, puis leurs capacités d’intégration. 

Le second fut l’analyse et l’intégration d’un système de gestion de 

contenu. 

Le troisième fut l’étude des technologies client riches et leurs capacités 

d’intégration au sein de portlets. 

Le dernier objectif et objectif final est de produire une maquette 

fonctionnelle de portail et d’y intégrer les différents outils étudiés ci- 

dessus. 



Démarche générale 

Le stage se déroula dans une démarche projet de bout en bout. Ceci 

signifie qu’il suit un processus projet qui comprend différentes phases 

(préliminaire, d’étude, de développement). 

Le stage se déroule entièrement dans les locaux d’Arismore. 

Le stagiaire est piloté de manière opérationnelle par un responsable 

technique, expert du sujet, qui apporte ses compétences tant techniques que 

méthodologiques. 

Les résultats du stage feront l’objet d’un partage et d’un échange avec les 

équipes d’Arismore aux différents jalons du projet, permettant ainsi que le stage 

s’inscrive dans une perspective métier et projet en phase avec les 

problématiques rencontrées dans le cadre des missions que la société mène chez 

ses clients. 

De plus un comité technique est prévu en fin d’échéance afin de faire 

partager les connaissances acquises et ainsi de capitaliser les différentes études 

technologiques effectuées. 

Principales étapes 

Les différentes étapes du stage sont les suivantes : 

Phase d’étude et de documentation 

o Portails du marché Open Source 

o Technologie de Portlet (JSR168 et JSR286) 

o Client riche (Flex, Ajax) 

o Système de gestion de contenu (JSR170) 

o Editeur Web (WYSIWYG) 

Phase de spécification 

o Description des différentes fonctionnalités via la définition de 

Use case UML 

o Description des enchaînements via diagramme de séquence 

UML 



Phase de conception 

o Description de l’architecture logicielle du portail 

o Définition du modèle de conception 

o Définition de l’implémentation des fonctionnalités 

o Conception itérative des différents blocs fonctionnels 

Objectif personnel 

Les objectifs personnels de ce stage sont nombreux. Ces objectifs 

viendront compléter les différentes expériences en entreprises que j’ai déjà 

effectuées. 

Une première partie repose sur des objectifs humains : 

o Compléter mon expérience de travail en entreprise 

o Acquérir une réelle méthodologie de travail sur un projet 

complexe 

o Améliorer ma capacité de travailler en équipe 

o Profiter de ce stage pour m’intégrer dans la société 

Une seconde partie repose sur des objectifs techniques : 

o Engranger un bagage technique important sur différentes 

technologies innovantes 

o Améliorer ma capacité d’adaptation et de compréhension d’un 

projet complexe 

o Connaître les différents livrables nécessaires au bon 

fonctionnement d’un projet 

o Apprendre la maitrise de conduite de projet avec les livrables 

à fournir, les échéances de travail et la communication au 

sein de l’équipe 



Architecture d’entreprise et Urbanisme 

L’architecture d’entreprise est le cœur de métier d’Arismore. De plus, 

ayant le besoin de créer un portail d’architecture, la bonne compréhension de 

cette démarche et de ce métier étaient primordiales. Je vais présenter ici les 

aspects principaux de la démarche d’architecture d’entreprise afin d’en donner 

une vision la plus complète et compréhensible possible. Dans ce contexte, je 

serai amené à parler de l’urbanisme (ou urbanisation). 

Introduction 

Définition 

Architecture d’entreprise 

L’architecture d’entreprise est une démarche qui permet de décrire les 

structures et les comportements d’une organisation existante ou cible en termes 

de métier, d’organisation fonctionnelle, applicative et technique dans le but 

d’établir et de maintenir la cohérence entre la stratégie de l’entreprise et celle du 

Système d’Information (SI). 

La cohérence du SI doit être maintenue tout au long du processus de 

transformation et des projets. L’objectif majeur de l’architecture d’entreprise est 

de fournir un cadre permettant le maintien de cette cohérence et une certaine 

transparence. 

Urbanisme 

L’urbanisme est un concept créé en France par Jacques Sassoon dans les 

années 90 dans le secteur bancaire. Il s’agit de réutiliser les concepts 

d’urbanisme et d’organisation du territoire en les adaptant au domaine des 

systèmes d’information. Les domaines adressés sont : la stratégie, le métier, le 

système d’information et le système informatique. 

L’urbanisme offre une couverture qui paraît semblable à celle de 

l’architecture d’entreprise. Cependant la démarche n’est pas la même. 

Arismore | Architecture d’entreprise et Urbanisme 17


L’urbanisme répond à une conception cible alors que l’architecture d’entreprise 

est un processus continu avec une gestion du changement permanente, guidée 

par le(s) Framework(s). 

Architecture et Urbanisme à l’heure actuelle 

L'architecture d'entreprise est un concept qui est apparu il y a une 

quinzaine d’années. Sa mise en place effective a commencé au sein des 

administrations aux Etats-Unis et notamment dans le secteur de la défense. Puis, 

la démarche s’est progressivement étendue à de grandes entreprises telles 

qu’Intel ou British Petroleum. En France, l’architecture d’entreprise est un 

concept moins développé, même au sein des grandes directions informatiques. 

La notion d’urbanisme est plus présente. Cependant la nécessité est présente et 

il est clair que cette discipline va se développer rapidement au cours des années 

à venir. En effet, des mesures légales telles que Sarbanes-Oxley aux Etats-Unis, 

la loi de protection financière en France ou encore Bâle II pour les banques 

européennes, obligent les entreprises à une plus grande transparence. Pour cela, 

ces dernières doivent se structurer, s’organiser de manière plus efficace et 

compréhensible, ce qui implique souvent une démarche d’architecture 

d’entreprise. Enfin, le jeu de la concurrence et de la compétitivité va pousser les 

entreprises à s’aligner les unes sur les autres. 

Les Framework 

La démarche d’architecture est basée sur un cadrage des activités 

réalisées. Il est donc nécessaire de définir des cadres ou Framework. Ces 

derniers englobent l’intégralité de la démarche d’architecture et permettent de 

guider l’architecte dans sa réalisation. Nous allons présenter citer ici les plus 

connus et en donner une brève description. 

Zachman 

Créé par John Zachman à la fin des années 80, ce Framework propose une 

manière très structurée de définir un système d’information. Il s’agit du premier 



Framework d’architecture d’entreprise : il présente un cadre permettant de 

mettre en relation toutes les couches du SI, tout en assurant leur cohérence. 

Le Framework de Zachman se base sur une matrice mettant en relation les 

différentes questions : Quoi (Données), Comment (Fonctions), Où (Réseaux), 

Qui (Personnes), Quand (Temps) et Pourquoi (Objectifs) avec les différentes 

entités : Direction/organisation, Responsables, Concepteurs, Développeurs et 

Sous-traitants. Chaque case de la matrice doit être cohérente avec les cases 

alentour (en ligne et en colonne) ce qui assure une cohérence globale de 

l’architecture ainsi définie. Cependant, une telle approche présente le 

désavantage de produire beaucoup de documentation, dont l’utilité n’est pas 

toujours avérée. 

Il est à noter que tous les autres Framework sont basés sur celui-ci, qui offre la 

couverture la plus complète. 

Le TOGAF 

The Open Group Architecture Framework (TOGAF) est, comme son nom 

l’indique, le Framework d’architecture créé par l’Open Group. Il en est 

actuellement à sa version 9. Il est composé d’un cycle de conception 

d’architecture en 8 étapes détaillées : Architecture Development Method et d’un 

référentiel des modèles architecturaux de l’entreprise : l’Enterprise Continuum. 

ARCHITECTURE DEVELOPMENT METHOD ENTERPRISE CONTINUUM 



Autres 

Il existe de nombreux autres Framework adaptés à des organisations 

particulières telles que les administrations ou le secteur de la défense. On citera 

notamment le DoDAF (Department of Defense Architecture Framework), utilisé 

par l’armée américaine, AGATE (Atelier de Gestion de l’ArchiTecturE), le 

Framework militaire français ou encore NAF (NATO Architecture Framework), le 

Framework de l’OTAN. On constate donc que les organisations militaires qui 

nécessitent rigueur et clarté dans leur fonctionnement et leur gestion, sont les 

premières à mettre en place des architectures d’entreprise et créent leurs 

propres Framework, adapté à leur cas. Ceci montre que l’architecture 

d’entreprise est bien une démarche qui consiste à utiliser des cadres et à 

structurer la conception, l’évolution et le pilotage du système d’information et de 

ce qui est lié, et non une recette toute faite qui s’applique de manière similaire 

dans tous les cas. 



Etude d’une démarche d’architecture idéale 

Le modèle en couche 

La démarche d’architecture d’entreprise dont il s’agit s’appuie sur le 

modèle en quatre couches que voici : 

MODELE D’ARCHITECTURE D’ENTREPRISE EN 4 COUCHES 

Ce modèle est un classique, et il est utilisé aussi bien pour l’urbanisme que 

pour l’architecture d’entreprise. Il propose un découpage des grands domaines 

de l’entreprise affectés et/ou affectant le SI. Notamment, il adresse la 

problématique de l’alignement des objectifs métiers avec les moyens 

informatique mis en œuvre. 

Par la suite, nous allons détailler chaque couche séparément. Pour autant, 

il est nécessaire de comprendre que l’enchaînement entre les couches est 

primordial et qu’elles ne sont pas indépendantes les unes des autres. De même il 



n’y a pas d’ordre préétabli dans le traitement des couches, on peut faire du Top- 

Down (conception descendante à partir du métier), du Bottom-Up (conception 

ascendante) ou encore un mélange des deux. Cela dépend des objectifs de la 

mise en place de l’architecture. 

Le métier 

Description 

La couche métier a pour objectif de formaliser le métier de l’entreprise et 

pour cela de répondre aux questions quoi, qui, où et pourquoi. Il s’agit de décrire 

l’entreprise mais aussi de définir quels sont les besoins du métier vis-à-vis du SI. 

Cette description ne concerne pas seulement l’existant mais aussi les 

évolutions du métier, qui impacteront des modifications du SI. 

Modélisation 

Les deux éléments principaux qui permettent de décrire le métier sont les 

processus métier et les activités. 

Les processus métiers constituent un découpage logique plus ou moins 

détaillé des actions ou ensembles d’actions réalisés par l’entreprise dans le but 

de produire une valeur ajoutée pour un client. Il existe différents types de 

processus métier : les processus opérationnels qui adressent directement le 

cœur de métier tandis que d’autres, les processus de support, représentent 

l’environnement nécessaire à la réalisation des processus opérationnels (comme 

par exemple la comptabilité, les ressources humaines, la gestion du SI…). On 

peut représenter les processus de la manière suivante : 



REPRESENTATION DES PROCESSUS : ON DISTINGUE LES PROCESSUS OPERATIONNELS 

(HORIZONTAUX), DES PROCESSUS DE SUPPORT (VERTICAUX) 

Les Use Case ou cas d’utilisation présentent une vision intéressante des 

interactions de l’entreprise avec les acteurs externes, en insistant sur la notion 

de déclenchement. 



USE CASES 

Les Use Case sont ensuite détaillés en diagrammes d’activité ou 

diagrammes BPMN (Business Process Modelisation Notation). Ces deux types de 

diagrammes appartiennent à des normes différentes (UML et BPMN) mais ils 

présentent le même objectif : décrire la manipulation et la transformation 

d’objets métier par des ressources de l’entreprise. Un même diagramme décrit 

un nombre limité d’activités ayant une sémantique commune. On pourra 

éventuellement décrire différents scénarios. 

La description des activités est une phase d’une importance capitale pour deux 

raisons : 

Elle implique la description des objets métiers et des ressources de 

l’entreprise. 

Elle permet de commencer à faire le lien entre un objectif métier et la 

manière de l’accomplir (manipulation d’objets métiers, mise en œuvre de 

ressources). 



DIAGRAMME D’ACTIVITE 

La description des activités implique la spécification des objets métiers 

(quoi), des entités organisationnelles (qui) et décrivent des processus répondant 

à des objectifs (pourquoi). La majeure partie de la couche métier est donc 

décrite par ces trois diagrammes (processus, use case et activité) mais il est 

possible d’agréger des descriptions si elles sont pertinentes et fournissent des 

informations supplémentaires sur le métier de l’entreprise. Par exemple, un 

diagramme hiérarchique des entités de l’entreprise ou un diagramme des 

différents sites ou zones géographiques sont bienvenus. 

Le fonctionnel 

Description 

La couche fonctionnelle décrit les ressources logiques qui vont être mises 

en œuvre pour réaliser les activités décrites dans la couche métier. Le terme 

fonctionnel fait référence à un ensemble de fonctions logiques et sémantiques et 

non à des fonctions applicatives. Il s’agit ici de décrire une organisation, des 



traitements, des échanges en restant en dehors de toute considération 

applicative ou technique. 

Le but recherché est une organisation logique des fonctions, fortement 

découplée et sans redondance. L’urbanisation est la méthode qui semble la plus 

appropriée pour arriver à ce résultat. 

Les données manipulées par ces fonctions sont également décrites ainsi 

que les échanges entre les différents blocs fonctionnels. 

Il est important d’établir un ensemble de règles de gestion précis en ce qui 

concerne l’éclatement en blocs fonctionnels et la définition des données qu’ils 

manipulent. 

Modélisation 

L’urbanisation des fonctions consiste en la séparation en zones, quartiers 

et blocs fonctionnels. Le bloc est l’entité de plus faible granularité qui contient les 

fonctions. 

Le découpage consiste premièrement à séparer les zones de référentiels 

(données), d’échange (communication avec l’extérieur), de gestion (finance, RH, 

informatique…) et les zones opérationnelles (métier proprement dit). 



PATTERN DE DECOUPAGE FONCTIONNEL REGROUPANT LES ZONES EN 4 GROUPES : 

OPERATIONNEL, GESTION, ECHANGE ET REFERENTIEL 

Après cette première séparation, chaque zone est découpée en blocs plus 

fins (parfois appelés quartiers) qui sont eux-mêmes découpés en blocs 

fonctionnels. Le nombre de niveaux de découpage est libre et dépend du niveau 

de complexité de l’organisation qui est décrite. L’important est d’effectuer un 

découpage logique et sémantique. 

Prenons l’exemple de la zone « Gestion commerciale de l’énergie », elle 

est découpée en quartiers suivants : « Se charger des relations clients », « Se 

charger des affaires européennes »… qui traitent chacun d’un thème différent et 

séparé des autres. Le quartier « Se charger des relations clients » peut quant à 

lui être découpé en blocs : « Bloc gestion clients et contrats ARP », « Bloc 

gestion clients et contrats raccordement »… qui contiendront des fonctions 

spécifiques. Un tel découpage, soucieux de ne pas adresser plusieurs fois le 



même problème, permet une répartition judicieuse des fonctions et assure un 

bon découplage. 

DIAGRAMME D’URBANISME FONCTIONNEL : DETAIL DE LA ZONE OPERATIONNELLE « GESTION 

COMMERCIALE DE L’ENERGIE ». EN GRIS ON VOIT LES QUARTIERS ; EN BLEU, LES BLOCS 

FONCTIONNEL ET EN JAUNE, LES FONCTIONS. 

Il est possible de réaliser plusieurs diagrammes afin de conserver une 

bonne compréhension. 

Ces diagrammes d’urbanisation, une fois réalisés, offrent une bonne 

visibilité de l’organisation que l’on souhaite mettre en place. Il est intéressant de 

les compléter par une description des objets manipulés et des principaux 

échanges entre zones ou blocs fonctionnels. 



Les échanges peuvent être représentés directement sur les diagrammes 

d’urbanisme fonctionnel. Quant aux objets, ils peuvent être représentés en UML, 

grâce à un diagramme de classe qui constituera une ébauche pour la couche 

applicative. 

Lien avec la couche métier 

L’organisation qui est décrite dans la couche fonctionnelle dépend 

fortement de la description des processus et des activités qui a été faite dans la 

couche métier. Le lien entre ces deux couches est notamment réalisé par : 

La projection des activités (UML) ou des Elementary Business Process (BPMN) 

sur les fonctions présentes dans les blocs 

La couverture fonctionnelle des activités décrites dans la couche métier 

doit être complète. Cependant, il ne s’agit pas d’un mapping systématique et il 

est possible d’affecter plusieurs activités à la même fonction si elles sont 

sémantiquement similaires. 

DECOUPAGE DES ZONES, EN ZONES OU QUARTIERS DE PLUS PETITE TAILLE CONTENANT DES 

BLOCS PRESENTANT DES FONCTIONS ADRESSANT LES ACTIVITES DECRITES DANS LA COUCHE 

METIER. 



La projection des objets métier manipulés dans les diagrammes d’activités sur 

les objets décrits dans la couche fonctionnelle 

Dans la couche métier ces objets sont utilisés et non décrits en termes de 

structure. Dans la couche fonctionnelle, la structure des objets manipulés est 

étudiée sans toutefois en arriver à une description de classes applicatives. 

CORRESPONDANCE ENTRE LES OBJETS METIERS MANIPULES DANS LES DIAGRAMMES D’ACTIVITE 

DE LA COUCHE METIER ET LA DESCRIPTION STRUCTURELLE DES OBJETS EFFECTUEE DANS LA 

L’applicatif 

Description 

COUCHE FONCTIONNELLE. 

La couche applicative décrit les composants technologiques répondant à 

l’organisation fonctionnelle spécifiée précédemment. 

L’objectif est la distribution et la réutilisation des fonctions applicatives. 

L’accès aux données doit également être distribué et va influer sur le choix de la 

méthode d’intégration. En effet, au niveau applicatif, il existe plusieurs 



possibilités et le choix de la méthode dépend des objectifs qui ont été fixés ainsi 

que du cas qui est traité. 

Dans cette couche, sont modélisés : les applications, leur fonctionnement, 

leurs composants et la manière dont elles communiquent ainsi que la structure 

des données manipulées et l’utilisation de ces données par les applications en 

termes d’accès et de persistance. 

La proposition d’architecture applicative doit répondre à la modélisation 

fonctionnelle dans le cadre des exigences et contraintes spécifiques au contexte. 

Modélisation 

UML offre tous les diagrammes nécessaires à la modélisation de la couche 

applicative mais il est possible d’ajouter d’autres types de diagrammes existants 

ou « maison », s’ils facilitent la compréhension et apportent des informations 

pertinentes. 

La modélisation d’application et de données à l’aide d’UML étant largement 

connue, employée et étudiée en cours, j’ai choisi de ne pas la développer dans ce 

rapport. 

Le traitement de la couche applicative peut avoir plusieurs objectifs : 

Audit de l’architecture applicative existante. 

Cela consiste à effectuer un mapping des applications existantes sur les 

zones fonctionnelles délimitées précédemment. Grâce aux diagrammes ainsi 

obtenus, il est possible de déterminer de nombreuses informations sur 

l’architecture applicative existante et sur sa logique. Si une application est située 

sur de nombreuses zones fonctionnelles, cela met en évidence un couplage trop 

fort et donc une dépendance importante vis-à-vis de cette application. Un autre 

exemple est celui des zones fonctionnelles contenant un trop grand ou un trop 

petit nombre d’applications. 



Conception d’une nouvelle architecture applicative ou évolution de 

l’architecture existante 

Il s’agit donc de décrire une architecture cible. 

Dans le cas de la description d’une architecture cible, l’architecture 

applicative type choisie va fortement impacter la conception. 

applicatifs : 

On désigne par architecture applicative, l’agencement des éléments 

d’accès aux données 

de traitement 

de présentation 

Il existe différents modèles et différentes technologies pour réaliser et 

agencer ces éléments. C’est à ce niveau que le modèle est choisi, mais sa 

conception doit rester indépendante de l’architecture technique sur lequel il sera 

déployé. Une fois l’architecture applicative choisie, la modélisation des 

applications peut commencer. Elle favorise généralement le découpage en blocs 

applicatifs réutilisables, aussi appelés services. Si les services sont hétérogènes, 

des méthodes de communication sont prévues (EAI). Tout ce qui concerne la 

partie applicative est détaillé : les algorithmes, les design patterns utilisés… 



EXEMPLE DE DECOUPAGE D’UNE APPLICATION (CC) EN BLOCS APPLICATIFS. 

La modélisation des données sous forme de schéma entité relation est 

également traitée dans la couche applicative ainsi que la question de la 

persistance des données. 

Liens avec la couche fonctionnelle 

Le lien avec la couche fonctionnelle se fait au niveau de la répartition des blocs 

applicatifs sur les blocs fonctionnels 

Il est nécessaire de garder un découplage maximum tout en couvrant 

l’ensemble des fonctions. Pour autant, chaque fonction de la couche fonctionnelle 

ne doit pas nécessairement correspondre à une fonction applicative différente. 

Les fonctions applicatives peuvent être utilisées dans plusieurs blocs. 

Au niveau des objets métiers, modélisés sous forme de classe dans la couche 

fonctionnelle, ils vont être modélisés sous forme de données auxquelles il sera 

fait appel dans les applications. 



Le technique 

Description 

Au niveau de la couche technique, sont définies quelles sont les 

infrastructures nécessaires au déploiement des éléments définis dans la couche 

applicative ainsi que la manière dont ils communiquent. 

Le principal objectif lors de la conception de la couche technique est la 

mutualisation des plateformes techniques dans le but de réaliser des économies 

d’échelle. 

Modélisation 

La modélisation de la couche technique est principalement constituée par 

des diagrammes réseau (avec la notation Cisco par exemple) qui permettent de 

montrer la connexion entre les serveurs. Le déploiement des composants 

applicatifs sur les différents serveurs peut se représenter de la manière suivante 

(ce qui permet de faire le lien entre les couches applicatives et techniques) : 



EXEMPLE DE MODELISATION DE L’ARCHITECTURE TECHNIQUE D’UNE APPLICATION : ON PEUT 

VOIR LE DEPLOIEMENT DES COMPOSANTS APPLICATIFS SUR LES SERVEURS. 

La mutualisation des serveurs entraînant une virtualisation des serveurs à 

divers niveaux, il pourra être nécessaire de réaliser des vues de l’architecture 

technique selon certains points de vue. 

Liens avec la couche applicative 

Le lien entre les couches techniques et applicatives est constitué par le 

déploiement des composants (blocs applicatifs ou services et données) sur des 

machines physiques. 


Le bilan 


La démarche d’architecture d’entreprise permet d’aboutir à un ensemble 

structuré de documents et de spécifications qui concernent l’existant, la cible et 

la manière de passer de l’un à l’autre. 

Il s’agit d’un processus généralement long qui, si l’on souhaite qu’il soit 

efficace, doit bénéficier d’un bon encadrement et d’une bonne méthodologie. 

Pour cela le Framework est un bon guide mais il ne fait tout. La motivation et 

l’expérience des personnes concernées est essentielle. La documentation n’est 

pas produite pour « faire du papier » mais dans le but de constituer un 

référentiel clair et réutilisable, notamment pour de futures évolutions de 

l’architecture. Dans le TOGAF, la démarche proposée ne constitue d’ailleurs pas 

tout le Framework, une seconde partie, l’Enterprise Continuum propose la 

création d’un référentiel des modèles d’architecture de l’entreprise. 

Arismore | 36


Synthèse technique du projet 

Comme je l’ai rapidement détaillé ci-dessus, mon stage c’est déroulé en 3 

étapes majeures. 

J’ai tout d’abord du comprendre et assimiler le sujet, ceci impliqua une 

forte documentation et une recherche approfondie sur le sujet. Ensuite une 

phase de recherche, de documentation et de test technologiques a été réalisée 

afin de choisir les technologies pivot du projet (choix du portail, choix d’un 

système de gestion de contenu, choix d’un serveur d’application, etc.). Ces 

différents choix furent très structurant pour la suite du projet c’est pourquoi, il 

n’a pas fallu les prendre à la légère. Suite à toutes ces études, j’ai pu rédiger un 

dossier d’étude expliquant pourquoi j’ai proposé telles et telles technologies et 

résumant la portée de mon stage par rapport au projet global. 

Suite à toutes ces réflexions et choix technologiques, j’ai pu commencer la 

rédaction d’un dossier de conception expliquant le modèle de conception qui sera 

mis en place et quelle démarche sera utilisée pour l’implémentation du portail 

d’architecture. 

Puis une troisième partie fut la réalisation concrète de ce portail. Après le 

choix des technologies, il a fallu monter en compétences sur certaines comme le 

Flex, qui est une technologie innovante dont j’étais novice, ou JackRabbit, qui a 

été retenu comme implémentation de notre système de gestion de contenu. 

Présentation détaillée du sujet 

Ce projet consiste à la mise en place d’un portail d’architecture. Ce portail 

permettra la mise à disposition d’un ensemble de documents relatif à 

l’architecture au sein d’un même et unique socle. Ce portail a pour but la 

collaboration, la mise à disposition et le partage d’informations. 

Il a pour objectif de simplifier la production de documents et surtout 

d’éviter leurs redondances et d’assurer la pérennité des documents via des mises 

à jour bidirectionnelles avec le référentiel d’architecture. 

Arismore | Synthèse technique du projet 37


Ce projet se situe dans un contexte d’innovation. En effet, aucun produit 

semblable n’existe encore sur le marché. Certains grands groupes sont en train 

de réfléchir à de telles solutions mais nous nous différentions d’eux par notre 

approche qui est plus basée processus et objectifs que ressources. 

En effet, le but de ce portail n’est pas l’accumulation de documents ou de 

comités mais plutôt de permettre de mettre en regard les contributions avec les 

capacités humaines déployées et d’offrir un environnement de travail facilitant le 

support de l’activité et le travail au quotidien. De plus, le but de ce portail est 

d’être utile par un usage par intérêt des utilisateurs et non par une obligation de 

travail. 

De nos jours, le marché des solutions informatiques est en perpétuelle 

évolution, c’est pourquoi il faut avoir une vision assez lointaine (environ 2 ans) 

des futures technologies, méthodes et solutions qui inonderont le marché afin de 

pouvoir dès maintenant les incorporer à notre solution. 

On peut distinguer 3 principaux acteurs impliqués dans ce projet : 

Benjamin Petitprez, Johan Brelet et Olivier Tonnelier. Benjamin Petitprez 

s’occupe de l’étude et de la conception du projet, il est supervisé par Johan 

Brelet qui l’appuie sur un point de vue technique. Olivier Tonnelier, quant à lui, 

est responsable du projet, c'est-à-dire qu’il coordonne le travail, apporte les 

exigences liées au projet ainsi que les fonctionnalités attendues. 

Les différentes phases du projet 

Phase d’étude 

Objectif d’une phase d’étude 

L’objectif de cette présente phase est de présenter l’étude du projet Portail 

d’Architecture. Il va permettre d’avoir une vue d’ensemble du projet et 

comprendre les besoins attendus. Nous détaillerons par la suite les différentes 



études et tests réalisés durant la phase d’étude préliminaire, afin de montrer et 

d’expliquer les solutions choisies. 

Les fondamentaux 

Le but de ce projet est la réalisation d’un portail d’architecture. Ce nouvel 

outil vise à regrouper et structurer toutes les informations utiles du métier de 

l’architecte. Ce socle commun de l’information de l’architecte suivra des normes 

et des standards comme (TOGAF, ITIL). Il devra tenir compte de l’existant dans 

un premier temps puis s’ouvrir à l’ajout et la modification de données. Ceci sera 

réalisé sur la base d’un portail Open Source qui devra être compréhensible par 

tous types d’acteurs (production, commercial, fonctionnel, technique). Pour cela, 

il devra s’articuler autour de différentes vues ou méta-modèles compréhensibles 

par chacun. 

Le concept de portail Web 

Le portail Web est la base principale de notre projet. C’est autour de ce 

concept que nous allons construire notre solution finale. Il existe aujourd’hui une 

multitude d’offres de portail Web sur le marché de l’Open Source. 

Il existe plusieurs types de portail : les portails web et les portails 

d’entreprise ou applicatif. Le portail d’entreprise doit pouvoir offrir un bureau 

virtuel aux utilisateurs afin qu’ils puissent avoir accès à différentes informations 

sur l’entreprise, un domaine ou un projet. 

Nous allons par la suite donner une définition détaillée d’un portail 

d’architecture, qui est un sous-ensemble d’un portail d’entreprise. Puis, nous 

détaillerons par la suite, le choix du portail utilisé et les raisons qui nous ont 

poussés à choisir ce dernier. 

Définition 

Le portail d’entreprise peut être assimilé à une plate-forme intranet 

donnant accès à des données de l’entreprise ainsi qu’à différentes ressources du 

système d’information au sein d’une interface unique. Il se décompose souvent 

en deux parties. La première est une partie information qui permet de référencer 



les différents artefacts constituant le SI d’une entreprise (Serveurs, Applications, 

Composants, …). La seconde partie est plus orientée gestion de contenu ce qui 

permet aux utilisateurs d’interagir au sein du portail et ainsi de publier, modifier 

ou supprimer de l’information (Section Documentaire). La jonction de ces deux 

éléments permet de rendre le portail très interactif et bidirectionnel. 

Un portail est un environnement de travail qui se compose d’une partie 

commune à tous les utilisateurs et d’une partie privée qui permet de se créer son 

propre espace personnel de travail. Ces deux parties sont composées de Portlet. 

Les Portlets peuvent être considérés comme des blocs qui traitent des 

requêtes d’une tâche ou d’un service et génèrent dynamiquement un contenu. 

Ces portlets sont soumises à la norme JSR-168 et plus récemment à la norme 

JSR-286, que nous détaillerons par la suite. Cette norme permet de qualifier les 

actions possibles de la Portlet et surtout de les construire selon un modèle qui 

permettra de les déployer sur n’importe quel portail. 

Un portail dispose également d’une partie administration qui permet de 

définir les droits des différents utilisateurs et d’administrer le portail général. Le 

choix des portlets disponibles sur le portail commun est géré par 

l’administrateur. Il donne ainsi l’accès à différentes ressources en fonction du 

profil de l’utilisateur connecté. 

Choix du portail 

Nous avons du retenir un portail Open Source pour la réalisation de notre 

portail d’architecture. Pour cela, nous avons dans un premier temps regardé les 

différentes offres que nous offrait le marché de l’Open Source. Nous avons pu 

ainsi élaborer une liste des différentes possibilités, après une première étude de 

documentation, nous avons pu effectuer une première short liste. 

Les 5 portails qui nous ont particulièrement intéressé et donc qui ont été 

retenus sont les portails Liferay, Uportal, Exo Plateform, Jetspeed et JBoss portal. 

Nous avons donc mené une étude détaillée de ces différents portails. 

suivants : 

Les différents points, fonctionnalités que nous avons étudiées sont les 

Authentification 



Gestion de contenu 

Outils collaboratifs 

Administration fonctionnelle 

Administration Technique 

Personnalisation 

Installation 

Intégration 

Business Intelligence 

Développement (OS, Base de données, Environnement, Normes 

respectées, Serveurs d’application) 

Point faible / Point fort 

Cette première étude, nous a permis de mieux comprendre les 

technologies de portails. On s’aperçoit qu’ils respectent dans l’ensemble les 

normes standard comme JSR-168, WRSP, JSF. De plus, ils sont tous les cinq 

développés sur un environnement JAVA. D’un point de vue base de données, ils 

acceptent en grande majorité les principales comme MySQL, Oracle, Postgres 

SQL,…. 

Nous avons dû choisir des critères, pour nous permettre de restreindre 

cette liste. Pour cela, nous avons regardé l’étendu et le fonctionnement des 

portlets disponibles de base. 

On a pu ainsi éliminer Uportal qui proposait peu de portlets et surtout qui 

n’était pas très adapté à notre utilisation. Ce portail est plus destiné à une 

communauté étudiante que professionnelle, par suite les outils dont il dispose 

sont orientés presque exclusivement affichage d’information et promotion 

d’évènement. 

Ensuite, nous nous sommes posé la question de la facilité de prise en main 

de la future solution. Sur ce point, Exo Plateform nous est apparue très 

complexe. En effet, il dispose de beaucoup de bons éléments comme Exo Web 

OS, Exo ECM et Exo CS mais tous ces éléments très complets technologiquement 



et graphiquement nous seront très durs à modifier. Par conséquent, nous avons 

du supprimer de notre liste ce portail également. 

En résumé, après cette première phase notre short list ne contient plus 

que 3 portails : 

Liferay 

Jetspeed 

JBoss Portal 

Une seconde étude est donc nécessaire afin de choisir un seul portail pour 

notre solution finale. Pour cela, nous avons porté attention à d’autres critères 

comme : 

La communauté qui soutient le portail 

La documentation technique et fonctionnelle qui est disponible 

La partie administration 

La gestion des droits utilisateurs 

La facilité de prise en main 

Exigences demandées 

On s’aperçoit ainsi que le portail Liferay, est très complexe dans la gestion 

de l’administration et la gestion des utilisateurs. En effet, contrairement aux 

portails dit « classiques », il ne dispose pas uniquement d’un socle commun et 

d’un socle privé mais aussi 3 autres types de socle (location, guest, …) qui ne 

nous seront pas utiles. Ensuite, d’un point de vue esthétique, le portail Jetspeed 

reste très sobre et ancestral. C’est pourquoi, nous l’avons également supprimé. 

Pour conclure, nous avons choisi d’utiliser le portail JBoss. 



Le client riche 

Aujourd’hui, il existe de plus en plus d’applications web qui utilisent les 

technologies riches. On peut distinguer deux principaux éditeurs Microsoft et 

Adobe avec respectivement Silverlight et Flex. On peut voir ensuite des solutions 

comme Mozilla avec XUL, Google avec la gestion de l’AJAX et Open Laszlo. 

De nos jours, la grande majorité des sites internet essayent de se 

convertir à ces nouvelles technologies. Elles permettent d’embarquer les 

nouveaux modes de communication comme l’écoute ou la vidéo de façon assez 

simple. Ensuite, on souhaite que les sites web soient le plus intuitif possible et 

qu’il n’y ait pas de perte de temps lors de la recherche d’informations, grâce à 

ces technologies cela est optimisé. 

En contre partie de ces atouts, une application client riche reste plus 

lourde en temps de chargement qu’une application basique. De plus, quelques 

problèmes de compatibilité d’affichage suivant le navigateur utilisé peuvent être 

ressentis. 

Java Content Repository (JCR) 

Dans le cadre de ce projet, la principale fonction est la gestion de 

document. Pour cela, nous allons nous servir d’un JCR qui s’appuie sur la 

spécification JSR-170. Le JCR nous permettra de manager nos documents, que 

ce soit pour l’ajout, la modification, le versioning ou la suppression. 

Le JCR permet à l’utilisateur de ne pas se soucier de la façon dont est 

stockée en base de données l’information. L’utilisation du JCR est équivalente à 

la gestion d’arbres qui comporte un ensemble de nœuds qui peuvent eux-mêmes 

posséder un ensemble de propriétés. 

Notre JCR s’appuie sur l’implémentation JackRabbit, qui est la solution 

open-source de référence. Le stockage s’effectue au sein d’une base MySQL 5. 



Principaux besoins attendus 

Saisie documentaire 

Description fonctionnelle 

L’espace de saisie documentaire est l’un des éléments importants du 

portail d’architecture. Cet espace est destiné à la création ou à la modification de 

contenu. Un contenu est stocké dans le registre du portail, il doit pouvoir 

s’adosser aux informations issues du registre du référentiel. Pour cela, il doit être 

possible de faire des tags sémantiques vers des informations du référentiel 

(préciser le contexte, le modèle, …) ou de faire un push d’informations issues 

d’un outil extérieur (modèle Sparx (modèle UML), …). 

Cet espace s’appuie principalement sur le bandeau de navigation afin de 

pouvoir naviguer au sein du processus et ainsi effectuer une tâche. 

Voici un aperçu de l’IHM de notre espace de saisie documentaire avec le 

bandeau de navigation : 



Après la saisie de notre contenu, on dispose de plusieurs possibilités 

d’enregistrement : 

Simple validation 

Demande de validation auprès d’un ou d’autres acteurs 

Demande de complément auprès d’un ou d’autres acteurs 

Description technique 

Afin de pouvoir créer des contenus, il faudra intégrer un éditeur de texte. 

Plusieurs offres du marché s’offrent à nous, 2 principales, FCKeditor et tinyMCE 

(éditeur utilisé dans le CMS de JBoss), pourraient nous intéresser. Elles disposent 

toutes deux d’un éditeur WYSIWYG permettant de mettre facilement en forme 

son texte. Les composites ainsi créés seront stockés au sein du JCR dans le 

registre Portail. 

Section explorateur et catalogue 


L’explorateur sera également très important au sein du portail. Il 

permettra de pouvoir accéder rapidement aux ressources, qu’elles soient situées 

dans la section documentaire, dans le registre du référentiel ou dans le 

continuum. 



Explications de fonctionnement : 

On sélectionne dans un premier temps le choix du registre à explorer 

(Section documentaire (Rapport), Référentiel d’architecture ou continuum) 

On peut effectuer une recherche directement par type de support ou à 

l’aide du nom du fichier. 

Cas section documentaire (Mode view et modif) 

On choisi le domaine et le travail (obligatoire) 

Choix de la tâche (optionnel) 

Visualisation des différents documents dans l’explorateur 

• Si tâche sélectionnée : visibilité uniquement des documents 

associés 

• Si tâche non sélectionnée : visibilité de toutes les tâches et de leurs 

documents associés 


Redirection 


Après sélection du document redirection vers un viewer ou la Portlet 

d’édition pour modification 


D’un point de vue technique, cet explorateur s’appuie sur les différents 

JCR. En effet, il va faire une lecture des différents registres et ainsi afficher et 

mettre à disposition les différents documents qui les composent. Ceci va se faire 

en parcourant l’arbre de chaque registre et ainsi on récupérera les différents 

documents et propriétés associées. Ensuite via plusieurs actions, nous pourrons 

être redirigés vers l’espace de travail ou vers un simple viewer. 

Bandeau de navigation au sein d’un processus 


Le bandeau de navigation doit permettre à l’utilisateur d’accéder de façon 

intuitive à la tâche sur laquelle il souhaite travailler et ainsi le guider au travers 

des différentes phases et activités. 

Voici une IHM non dynamique du futur bandeau : 

Explications de fonctionnement : 

Ce bandeau sera appelé dans le cas d’un travail. Il est généré à partir d’un 

fichier XML en fonction du domaine et du travail choisi préalablement. 

Il se divise en 3 parties : 

• Choix de la phase du processus 



• Choix de l’activité 

• Choix de la tâche 

Les activités et tâches auxquelles on ne peut pas contribuer sont grisées. 

Lorsque nous allons sur une tâche, nous pouvons voir la liste des entrants 

et sortants demandés. 

Lorsque nous cliquons sur le sortant auquel nous voulons contribuer, nous 

sommes redirigés vers la zone d’édition. 

Lorsque qu’une tâche possède tous ces entrants, elle passe en mode 

accessible et lorsqu’elle possède tous ces sortants, on peut la clôturer. 


Afin de réaliser le bandeau, nous avons du faire de la lecture de fichier 

XML stocké en base de données. Pour cela, nous avons utilisé un mapping 

Hibernate afin de récupérer le fichier en base et ensuite nous utilisons la librairie 

DOM pour traiter et récupérer les informations (phase, activité, tâche) afin de 

pouvoir générer le bandeau. 

Dans un état final, le bandeau devra être dynamique et utiliser les 

nouvelles technologies client riche comme le Flex. Ceci permettra de le mettre en 

avant et de le rendre le plus intuitif possible pour les utilisateurs. 



Solutions techniques apportées aux demandes de besoins 

Utilisation d’un JCR pour le management des données 

Afin de pouvoir gérer les fichiers issus de notre espace de travail, nous 

utilisons un Java Content Repository. Ce JCR s’appuie sur la norme JSR-170 et 

est implémenté par JackRabbit. Le stockage des données d’un JCR s’effectue de 

manière très ordonnée en base. En effet, il sépare les nœuds des propriétés, des 

fichiers, des versions. Ceci dans le but de faire du content management, c'est-à- 

dire de gérer les versions de fichiers, créer, supprimer ou de modifier les 

documents. Mais grâce au Java Content Repository, cette couche base de 

données est transparente pour le développeur. Il accède directement aux 

données via JackRabbit, on récupère ainsi un arbre avec un nœud Root en tant 

que racine, il ne reste plus qu’à le parcourir pour récupérer les éléments 

souhaités. 

Utilisation d’Hibernate 

Pour la génération du bandeau nous utilisons différents Template XML qui 

représentent les différents travaux qui peuvent être réalisés. Ces fichiers XML 

sont enregistrés dans une base de données, nous avons utilisé Hibernate afin de 

réaliser un mapping entre les éléments de la base et des objets java. Ceci dans 

le but de simplifier l’utilisation des données de la base de données. 

Utilisation de Flex pour dynamiser le bandeau 

L’utilisation d’une technologie riche comme le Flex permettrait de rendre 

dynamique le bandeau de navigation et ainsi le rendre le plus intuitif possible. De 

plus, grâce à cette technologie on peut donner un aspect visuel très intéressant. 



Phase de conception 

Suite à cette phase d’étude qui s’effectua sur les 4 premiers mois, j’ai pu 

avoir une bonne connaissance du contexte du projet et des technologies qui s’y 

rattachent. J’ai donc proposé un premier modèle de conception qui m’a servi de 

base de travail pour la suite. 

Objectifs 

Le but de ce présent document est de montrer le modèle de conception 

choisi et la démarche utilisée pour l’implémentation de ce portail d’architecture. 

Seront ainsi détaillés les différents diagrammes de séquence des principaux cas 

d’utilisation détaillé dans le dossier de spécification. Nous détaillerons également 

l’architecture logicielle et les technologies choisies. Nous commencerons par une 

étude générale du projet puis nous nous attarderons plus précisément sur une 

description plus fine des différents lots de conception qui ont été définis. 

Description globale de l’architecture logicielle 

L’architecture logicielle de notre projet va nous permettre de décrire les 

différents composants utilisés, leurs interrelations et leurs interactions. Nous 

allons donc essayer de décrire comment notre portail doit être conçu afin de 

répondre aux spécifications demandées. 

Notre projet va s’articuler autour d’une architecture 3-tiers : 

Une couche IHM qui permettra aux utilisateurs de naviguer via les 

différentes interfaces présentes. 

Une couche traitements qui réalisera les différents traitements 

nécessaires à l’affichage, à la sauvegarde ou la gestion des 

différentes données. 

Une couche données qui, comme son nom l’indique, servira à 

stocker les différentes informations de notre portail. 



Voici 2 schémas présentant l’architecture logicielle mise en place : 

Comment cette architecture répond aux cas d’utilisation 

Comme nous l’avions vu précédemment, notre architecture doit répondre à 

différents cas d’utilisation. 

Dans le cadre de la contribution à un travail, notre architecture répond 

également parfaitement au cas d’utilisation. En effet, la Portlet Travail permettra 

à l’utilisateur de contribuer sur un document. Ensuite le bloc de traitement de 

gestion de contenu (JSR-170) organisera et gérera le versioning du contenu au 

sein du référentiel portail. 

Une Portlet explorateur était également demandée afin de pouvoir accéder 

aux différents contenus sauvegardés dans les référentiels. Ceci est également 

géré via le gestionnaire de contenu et affiché dans la Portlet Explorateur. 



Afin de pouvoir contribuer facilement à un document voulu, nous avons 

mis en place un bandeau de navigation visant à aider l’utilisateur à naviguer au 

sein des activités et tâches d’un travail. La génération de ce bandeau se réalise à 

l’aide d’un fichier XML qui sera envoyé et traité par le bloc Gestion XML. 



Présentation des différentes interactions 

Récupération d’une section documentaire 



La création d’un nouveau travail s’effectue à partir de l’IHM d’accueil. L’utilisateur choisi un nom de Domaine, 

d’Entreprise et le nom de son travail. A l’aide de ces différents éléments, notre programme va récupérer en base le template 

XML de notre travail et ainsi créer les différents nœuds dans notre registre. 

Cette création permettra de pouvoir générer notre bandeau de navigation si besoin et rendre disponible les différents 

nœuds dans notre explorateur. 

Stockage d’une section documentaire 



L’explorateur permet d’accéder rapidement à une section documentaire. Après avoir choisi le document souhaité, nous 

ouvrons ce dernier dans la Portlet Travail. Nous pouvons ainsi le modifier ou simplement le visualiser. Dans le cas où le 

fichier a été modifié une version n+1 du document est créée dans le registre, ceci nous permet ainsi de ne pas perdre les 

versions antérieures de document et de pouvoir les récupérer dans le cas voulu. 


Résultats obtenus 


Les objectifs principaux étaient ma montée en compétence sur les 

différentes technologies étudiées (JCR, Portail, Portlet et Client Riche comme 

Flex), réaliser un entrant pour une future équipe de travail et la réalisation d’une 

maquette fonctionnelle présentant le portail d’architecture. 

La monté en compétence est effective. En effet, j’ai acquis de très bonnes 

bases sur 2 spécifications, la JSR-286 qui régit la technologie de Portlet et la 

JSR-170, qui régit la technologie de Java Content Repository. 

La maîtrise de la technologie de Portlet induit : 

Développement de Portlet en Java 

Déploiement sur un portail et plus particulièrement sur JBoss 

portal 

Communication InterPortlet 

Maitrise des différentes vues et états (View, Edit, Help et 

Minimized, Maximized) 

La maîtrise de la Technologie de Java Content Repository induit : 

Connaissance de JackRabbit, une implémentation de cette 

technologie 

Maitrise de l’ajout, suppression, modification, versioning d’un 

système de gestion de contenu 

Mon stage a permis de réaliser un bon entrant pour l’équipe de travail qui 

s’est composée par la suite. En effet, une première ébauche de l’architecture 

logicielle était réalisée. J’ai ainsi pu préparer l’arriver de nouveaux membres, ceci 

par le biais de la documentation que j’avais réalisé et par les différentes 

explications que j’ai pu leurs apporter. 

Arismore | Résultats obtenus 56


Quant à la réalisation de la maquette fonctionnelle, elle est également 

réalisée. Cette maquette ne présente pas toutes les fonctionnalités définies en 

milieu de stage car à partir du mois de Décembre une équipe c’est constituée 

autour du projet ce qui a modifié mon planning et donc changé les objectifs de 

cette réalisation. 

Le principal résultat obtenu a été ma compréhension du métier de 

l’architecture, qui représente le cœur de métier d’Arismore. Cette connaissance a 

surement facilité la signature de mon futur contrat au sein de la société. 

Pour conclure, Olivier Tonnelier a validé les résultats obtenus lors de ce 

stage et a été satisfait de l’investissement et de la motivation montrés. 

Arismore | 57


Difficultés rencontrées 

Ces difficultés ou, comme les appelés Olivier Tonnelier, ces challenges à 

relever ont été nombreux. En effet, s’attaquant à de nombreuses technologies 

innovantes comme les portails ou le Flex amènent plusieurs points de blocage. 

Tout d’abord, parlons du cas de Flex. Ce client riche, très novateur induit 

une bonne connaissance de l’Action Script 3. Ne connaissant que très peu ce 

langage, il a fallu se documenter et réalisé plusieurs test afin d’apprendre, 

comprendre et maitrisé cette technologie. Un des problèmes rencontrés était le 

manque d’informations sur Internet, ceci étant du au manque de maturité de 

cette jeune technologie. 

Ensuite, quand on parle de portail on parle forcément de Portlet. Comme 

je vous l’ai expliqué précédemment, les Portlets sont régi par une spécification. 

Lors du début de mon stage, la spécification de référence était la JSR-168, puis 

vers le courant Août, une nouvelle spécification est arrivée sur le marché (JSR- 

286) qui est une évolution de la JSR-168. Les problèmes rencontrés ont été 

principalement la perte de temps. Ceci, car j’ai voulu réaliser des fonctionnalités 

qui n’était pas natives à la JSR-168 et qui ont été spécifiées dans la JSR-286 

comme l’inter Portlet communication. 

D’un point de vue projet, il a été aussi compliqué pour moi de réaliser les 

premiers documents à fournir, n’ayant pas tout le vocabulaire, les terminologies 

et une bonne démarche, il a été difficile de réaliser un dossier d’étude par 

exemple. Mais Olivier Tonnelier, a pris le temps de bien m’expliquer et à toujours 

été à l’écoute de mes requêtes, difficultés ou besoins. 

Arismore | Difficultés rencontrées 58

Conduite de projet 


Lors de ce stage, j’ai connu 2 phases de travail. Lors dès 7 premiers mois, 

j’ai travaillé seul sur le projet avec l’aide de Johan Brelet, qui me guidait 

techniquement sur les méthodologies de recherches, d’études, de tests et de 

réalisation. Puis par la suite une équipe de 4 personnes, composée de Johan 

Brelet, Julien Lefebvre et Jean-Christophe Bohin et moi, s’est construite autour 

du projet. J’ai donc pu avoir deux vues totalement différentes sur le travail. Voici 

une description et le ressenti que j’ai pu rencontrer. 

Première phase : Travail seul 

Lors de ces 7 sept premiers mois, j’ai donc travaillé de façon autonome. 

Mon maître de stage, Olivier Tonnelier, m’avait parlé qu’il y aurait surement une 

équipe qui serait déployée sur le projet mais aucune date n’avait été avancée. 

Par la suite, j’ai du apprendre et mettre en place de la rigueur et de la 

méthodologie dans l’ensemble de mes travaux, ceci dans plusieurs buts : 

D’un point de vue personnel, j’ai ainsi pu me former aux méthodes 

Arismore. En effet, comme la majorité des entreprises, Arismore s’appuie 

sur des modèles de document (compte rendu de réunion, présentation, 

dossier d’étude, …). 

Dans l’optique de l’arrivé de nouvelles personnes sur le projet, une bonne 

capitalisation de l’information et du travail déjà effectué est une bonne 

pratique et permet un gain de temps important le jour venu. 

Les premiers mois furent consacrés, d’une part à la compréhension du 

sujet, qui n’était pas évident et très diversifié. En effet, il a fallu comprendre 

l’ensemble du sujet avant de définir un périmètre plus restreint pour la 

réalisation du stage. D’autre part, il a donc fallu faire de nombreuses recherches 

et se documenter sur les différents points techniques sur lesquels j’étais 

débutant. 

Arismore | Conduite de projet 59


Afin de tenir une rigueur et un suivi dans ce stage, j’effectuais un point 

bihebdomadaire avec Olivier Tonnelier. Ces réunions permettaient de faire le 

point sur le travail effectué, les documents produits et sur les nouveaux objectifs. 

Après cette phase de recherche et documentation, nous nous sommes 

fixés 2 jalons avec Olivier. L’avantage de créer des lotissements, puis des blocs 

de travail permet d’éviter les effets tunnel. En effet, sur de grands projets, une 

des principales difficultés est de ne pas se perdre et savoir par quel bout 

commencer. Le premier se trouvait fin Novembre 2008 et un second qui était 

planifié pour la fin de Janvier 2009. Ces objectifs ont permis de vraiment se 

focaliser sur 3 technologies précises, ainsi d’avoir une meilleure montée en 

compétence. De plus, cette organisation a permis de réaliser une maquette 

fonctionnelle moins étoffé mais plus rapidement. 

PLANNING MONTRANT LE DECOUPAGE EN JALONS 

Le premier jalon a été validé avec succès, il consistait à la réalisation d’une 

première maquette qui mettait en place une partie des technologies étudiés lors 



des premiers mois. Le second jalon était en bonne voie lorsqu’une équipe c’est 

mise en place autour du projet, ce qui a totalement changé ma façon de 

travailler. Je me suis donc intégré à cette équipe, ce qui n’était pas pour me 

déplaire car j’allais pouvoir vraiment faire du travail en équipe de projet ce qui 

est beaucoup plus intéressant et enrichissant. 



Deuxième phase : Travail en équipe 

Cette phase commença courant Décembre 2008 mais une réelle 

méthodologie de travail c’est mise en place début Janvier 2009. 

Julien Lefebvre, architecte fonctionnel depuis 2 ans, a pris les reines du 

projet en main, c'est-à-dire qu’il coordonne l’équipe, définit l’architecture 

fonctionnel du portail d’architecture, organise les différents points 

hebdomadaires, gère le suivi du projet et joue le rôle de responsable de l’équipe 

sous Olivier Tonnelier. 

EXEMPLE DE TABLEUR EXCEL DE SUIVI DE PROJET 

Jean-Christophe Bohin, nous apporte, quant à lui, une connaissance 

générale sur de nombreuses technologies (Application Server, Database,..) et sur 

l’architecture applicative et technique qu’il maîtrise vue sa position chez 

Arismore. 



Ensuite, Johan Brelet apporte sa connaissance d’intégration d’application, 

de projet de développement et de façon plus générale sa connaissance 

technique. 

Et pour finir, moi, qui est apporté ma connaissance générale sur le projet 

et sur les systèmes de gestion de contenu que j’avais étudié lors de ma phase de 

recherche. De plus, j’ai pu apporter mes connaissances en développement J2EE. 

Nous avons mis en place une méthodologie de travail s’articulant autour 

du modèle agile. Ce modèle s’articule autour d’une méthode d'organisation de 

projets par itérations courtes et incrémentales, assurant une certaine souplesse, 

un meilleur respect des objectifs fonctionnels et une meilleure proximité avec le 

client, MOA ou le donneur d'ordres. Ce modèle permet après une bonne 

répartition des rôles de pouvoir travailler indépendamment sur différents 

modules. De plus, elle permet de produire rapidement des maquettes 

fonctionnelles. Ceci est le cas dans notre projet, car le cahier des charges 

présenté par Olivier et Julien demande de réaliser une démonstration toutes les 2 

semaines afin de présenter et montrer l’avancement du travail. 

Afin de pouvoir être efficace dans notre travail nous avons mis en place un 

logiciel de subversion (TortoiseSVN). Ce logiciel permet de partager un répertoire 

de travail entre tous les acteurs d’un projet. Ainsi, après chaque réalisation de 

document, de diagramme, de modèle et de code, il est possible très facilement 

de les partager. 


Conclusion 


Arrivant à la fin de mon stage et donc par conséquent à la fin de mon 

cursus scolaire, je vais réaliser un check-up de ces 5 dernières années à l’esiea. 

Tout d’abord, d’un point de vue scolaire, l’esiea Laval m’a offert un cadre 

prestigieux et très convivial. L’enseignement reçu a été de bonne qualité, 

diversifié, parfois général et parfois spécialisé, ce qui donne de la profondeur et 

du poids à l’ingénieur esiea. Un des atouts a été la proximité avec le corps 

enseignant et directorial. Cela permet, en cas de problème, de trouver 

rapidement les solutions adaptées. 

De plus m’étant intégré au bureau des élèves en tant que responsable 

Colloque 2007, j’ai pu porter un lourd et intéressant projet sur mes épaules. Ce 

qui permet d’acquérir de l’expérience personnelle, de la confiance en soi et du 

professionnalisme auprès des différentes entreprises rencontrés. 

Pour finir avec ce cursus, il ne faut pas négliger tout les projets effectués 

qu’il soit interne (PFE, PFH) ou externe (Réalisation de 2 Raid Expérience 

Lavallois, APIC avec les salons fréquentés et le projet de questionnaire afin de 

savoir comment est connu et ressenti notre école au sein des lycéens, grand 

public et entreprise. 

Ensuite, l’esiea met un point d’honneur à former ses étudiants à la vie en 

entreprise. Pour cela, elle prône un grand nombre de stages qui débute en 

première année avec un stage de découverte de l’entreprise pour se terminer par 

2 stages plus techniques (stage technique et stage de fin d’étude) ceci en 

effectuant un stage à l’étranger afin d’apprendre de nouvelles cultures. 

D’un point de vue professionnel, ce stage s’est très bien déroulé, l’équipe 

d’Arismore m’a parfaitement intégré et le sujet de stage m’a permis de 

m’épanouir sur de nombreux points. J’ai donc pu acquérir une sérieuse 

expérience de travail et par suite je me sens tout à fait apte à poursuivre cette 

aventure au sein de l’équipe d’Arismore dès le début Mars 2009. 

Arismore | Conclusion 64


En conclusion, je suis très satisfait d’avoir choisi l’esiea comme école pour 

la réalisation de mes études d’ingénieur et Arismore comme entreprise pour mon 

stage de fin d’étude et j’espère pour une belle et longue carrière professionnelle. 

Arismore | Conclusion 65

Bibliographie 

Livres 

Site Web 


Marco Casario, « Flex Solutions Essential Techniques for Flex 2 and 

3 developers », FriendSof, 2007 

Sunil Patil, « What is a Java content Repository » 10 Mars 2009, 

http://www.onjava.com/pub/a/onjava/2006/10/04/what-is-java- 

content-repository.html?page=1 

Thomas Heute, Julien Viet, « JBoss Portal 2.7, reference guide » 

July 2008, 

http://docs.jboss.com/jbportal/v2.7.0/referenceGuide/html 

Stephan Hepper, Olivier Köth, « What's new in the Java Portlet 

Specification V2.0 (JSR 286)? », 18 Mars 2008, 

http://www.ibm.com/developerworks/websphere/library/techarticles/ 

0803_hepper/0803_hepper.html 

Moxiecode Sytems, « TinyMCE, free javascript editor », 2003-2009, 

http://tinymce.moxiecode.com/index.php 

Apache Foundation Softaware, « Welcome to Apache Jackrabbit », 

2003-2009, http://jackrabbit.apache.org/ 

Wikipedia, Wikipedia Foundation, « Wikipedia, L’encyclopédie libre » 

http://fr.wikipedia.org/wiki/Accueil 

Arismopedia, Arismore, « Intranet d’Arismore », 2009 

https://extranet.arismore.fr/arismopedia/bin/view/Main/WebHome 

Nabble, « Free Forum », 2003-2009, http://www.nabble.com/ 

Arismore | Bibliographie 66

Glossaire 

Comité technique 

JSR 

Sparxs 

Open Source 

JCR 

Flex 

Portlet 


Inter-Portlet Communication 

Ajax 

Arismore | Glossaire 67

Annexes 


GRILLES D’EVALUATION DES DIFFERENTS PORTAILS 

LIFERAY 

JBOSS PORTAL 

JETSPEED 

DIFFERENCE FLEX/AJAX 

PRESENTATION 

DESCRIPTION DETAILLEE D’AJAX 

FRAMEWORK 

LIBRAIRIES 

DESCRIPTION DETAILLEE DE FLEX 

COMMUNICATION FLEX 

MISE EN PLACE D’UNE PORTLET CLIENT RICHE (FLEX) 

PRESENTATION DES DIFFERENTES TECHNOLOGIES UTILISEES 

LES PORTLETS JSR-286 

JAVA CONTENT REPOSITORY JSR-286 

Arismore | Annexes 68


Grilles d’évaluation des différents portails 

Annotation des fonctionnalités 

0 -> absent, 1 -> partiellement couvert, 2 -> présent, 3 -> présent + possibilités d’extension intéressantes 

Liferay 

Fonctionnalités Outils 

proposés 

Appréciation Description 

Authentification 2 Authentification via un LDAP avec la connexion SSO sécurisé CAS. 

Gestion de 

contenu 

Possibilité d’intégrer d’autres SSO comme Netegrity. 

2 Présent sous forme de journal avec la seule possibilité de créer des 

articles et de les publier sur une page. Les articles sont structurés 

(titre, photos, texte HTML). 

Gestion de catégorie, date de publication, d’expiration 

Possibilité d’ajouter le CMS Alfresco 

Outils collaboratif Blog 2 Blog avec interaction avec les flux RSS afin d’avoir les dernières 

news en live 

Favoris 1 Gestion de favoris 


Administration 

fonctionnelle 

Administration 

Technique 


Forum 2 Création de fils de discussion avec possibilités d’ajout de pièces 

Chat 0 

jointes 

Mail 1 Serveur mail Imap. Connexion à un seul serveur pour tous les 

utilisateurs. 

Sondage 1 Outils de publication de sondages 

Wiki 2 Wiki qui permet à tous utilisateur de créer, modifier des pages 

intégré au sein d’une Portlet 

Calendrier 3 Publication d’évènement et de partage au sein des membres d’une 

communauté 

RSS 1 Lecture de flux RSS issu du blog interne ou de site extérieur. 

2 Possibilité de regrouper des utilisateurs basée en 3 niveaux : 

entreprise, organisation ou par « location » 

1 Gestion par Portlet est également possible 

Un système de logging (débogage) est présent sous la forme log4j 

Personnalisation 2 Il est possible de modéliser son poste de travail à souhait que ce soit 

Business 0 

sur le nombre de portlets ou leurs dispositions (layout différents) 

Une grande variété de skins différents est également mise à 

disposition 


Intelligence 


Installation 1 Assez simple mais l’utilisation de certaine portlets mis à disposition 

peut rester assez complexe 

Intégration 1 Supporte presque tous les serveurs d’exploitation et un grands 

nombre de base de données. De plus, il est possible de le connecter à 

un annuaire LDAP et il respecte la norme JSR-168 

Développement OS 2 Windows XP, Linux, Mac, Windows server 

Base de 

données 

2 Une base de données HSQL intégré afin d’avoir un développement 

rapide. 

Possibilité de mettre en place : DB2, Firebird,Hypersonic, Interbase, 

JDataStore, MySQL, Oracle, PostgresSQL, SAP, SQLServer 

Des scripts de création sont fournis pour un grand nombre de ces 

bases. 

Environnement 2 JAVA 

Normes 

respectées 

Serveurs 

d’application 

2 Possibilités de déployer des portlets de normes JSR-168 et WRSP, 

JSF, Struts, Spring 

2 Borland ES, Geronimo,GlassFish, JBoss, JOnAS, JRun, OracleAS, 

Orion, Pramati, RexIP, Sun JSAS, WebLogic,WebSphere 

Point faible 0 Aucun outil de reporting n’est présent. 



Perspectives Produit assez mature avec une grande communauté de développeur 

ce qui peut annoncer une belle vie 

Le portail Liferay est un portail très complet. En effet, il dispose d’un très grand nombre de fonctionnalités, que ce soit 

sur la diversité de ces portlets ou sur la gestion de son administration. Ce portail possède 60 portlets prêt à l’emploi qui se 

décline en plusieurs catégories (collaboration, news, bureautique, …). 

Il est également possible de créer de nouvelles portlets. Il dispose d’un plugin eclipse (LiferayPedia) qui facilite 

grandement la création de Portlet. Le déploiement s’effectue ensuite grâce à une Portlet d’ajout intégré au portail. Il suffit 

ensuite d’uploader un *.war ou un zip. Il est possible de développer des portlets en PHP, JSP, JSF, Hibernate and DAO, 

IceFaces, Sun Facelets, Struts. Le portail suit la norme JSR-168, on peut donc déployer toutes portlets respectant cette 

norme. 

Il dispose également une grande communauté. Un wiki (anglais) réparti en 6 catégorie (Installation, Starting with 

Liferay, Using Liferay, développement, customisation, comprendre Liferay), nous apporte un grand nombre de solutions aux 

différents problèmes que nous pouvons rencontrer. De plus, il existe aussi un forum actif, qui est géré par les développeurs 

de Liferay. 

Le point faible de ce portail pourrait se porter sur la partie administration, gestion des utilisateurs, gestion des pages 

(communauté, location, groupe, rôle) qui est très complète et donc très complexe à prendre en main. 

Le point fort, quant à lui, est la multitude de Portlet préinstallées ainsi que le design général du portail. 



JBoss Portal 

Fonctionnalités Outils proposés Appréciation Description 

Authentification 2 SSO et LDPA : Authentification classique 

Gestion de contenu CMS Portlet 3 Création de répertoire, fichier via un éditeur CMS. 

Arismore | Annexes 73 

Upload et edit des fichiers Text et Html via 

l’éditeur WYSIWYG HTML. 

Cpoy, Move, Delete 

Avec gestion des droits View, edit , delete 

Fonction de Secure ressources 

Outils collaboratif Blog 1 Sous forme de Portlet à télécharger 

Wiki Une portlet spécifique Blog peut être ajouté 

Forum Wiki, Forum 

Widget google 

Administration 2 Gestion d’administration des droits d’utilisateurs 

et des pages 

Personnalisation 2 Drag And Drop 

Business Intelligence 0 

Installation 2 Base de donnée HSQL intégré puis serveur JBoss 

Intégration 0


Développement OS 2 Linux, Windows, Unix, Mac Os X 

Base de données 3 MySQL 4.x., MySQL 5, PostgreSQL 8.x, Hypersonic 

SQL 


Derby, Oracle 9 and 10g, Microsoft SQL Server, 

MaxDB 

Environnement 2 Java 

Normes respectées 2 JSR 168, WSRP 1.0, JSR 170 

Serveurs 


2 JBoss 4.2.1, 4.2.2, EAP 4.2, EAP 4.3 

Autres 3 Documentation complète et compréhensible ++ 

Perspectives Portail très simple et ne disposant pas de tous les 

gadgets non utiles. 

Une très bonne base documentaire 

JBoss portail est très intuitif d’utilisation. Il possède une base d’administration qui s’oriente autour de rôle et 

d’utilisateur : chaque utilisateur possède un rôle Administrators ou User. En fonction de ce rôle, l’utilisateur peut ou non avoir 

accès à la base d’administration. Le portail s’ouvre sur 2 types de pages, une première qui est le portail commun à tous les 

utilisateurs et la seconde est une page privée qui est paramétrable (type, nombre et disposition de Portlets) par l’utilisateur 

lui-même. Ce paramétrage se fait via la page Dashboard editor, qui propose les portlets disponibles et permet de choisir 

l’emplacement. L’ajout de Portlet est assez simple également, il suffit de déployer la Portlet au format *.war dans le


répertoire C:\jboss-portal-2.6.5.SP1\server\default\deploy du portail. Le déploiement est ensuite automatique et la Portlet se 

rend disponible. Les portlets doivent suivre la norme JSR-168 afin qu’elle puisse être compatible au sein du portail. 

Une documentation très détaillée, nous montre le fonctionnement de toutes les fonctionnalités du portail : 

JBossPortalUserGuide.pdf. 

De plus une documentation plus technique est aussi disponible : JBossPortalreferenceGuide.pdf. 

Jetspeed 

Fonctionnalités Outils proposés Appréciation Description 

Authentification Login Portlet 2 Via un LDAP et utilise l’API JASS via une Portlet 

Request Password 2 Module d’envoi de mot de passe par mail en cas d’oubli 

User registration 2 Portlet d’inscription d’un nouvel utilisateur 


(enregistrement en tant que user) 

Gestion de contenu 0 Possibilité d’intégré un outil de gestion de contenu sous la 

norme WSRP 

Outils collaboratif Favoris 1 Gestion des favoris 

Calendrier 1 Application légère. Possibilité de prendre des notes 

exclusivement 

Bloc Note 1 Bloc note ou seul l’utilisateur peut voir ses notes : genre de 

mémo


RSS 1 Lecteur de flux RSS 2.0 

Administration 2 4 types de droits : utilisateur, groupe, rôle et propriétaire 


Possibilités : view, edit, help 

Personnalisation 2 Personnalisation de ses pages, portlets suivant les droits. 

Business Intelligence 0 

Plusieurs layout afin de disposer les portlets n’ importe où 

Installation 1 Installation simple, avec base de données HSQL livré avec 

le projet 

Intégration 2 Accepte Tomcat 4/5 et JBoss 

Prise en main assez difficile, manque de documentation 

pour la modification même si il y a un Wiki de mis en place 

Base de données : HSQL, MySQL et Oracle 

Permet de récupérer des contenus JSR168, WSRP, XML, 

RSS 

Développement OS 2 Windows Xp, Linux 

Possibilité de créer des portlets en Struts ou PHP 

Base de données 2 Une base HSQL est intégrée de base mais possibilité de 

Environnement JAVA, J2EE 

mettre en place une base MySQL ou Oracle 8i/9i 

Normes respectées 2 JSR-168, Struts, XML, Portlet en PHP, RSS, WSRP, Perl


Serveurs 


2 Tomcat 4/5, JBoss 

Autres 2 Possibilité de déploiement sur WAP 

Perspectives Vu les évolutions entre Jetspeed 1 et 2, on peut croire à un 

bel avenir 


Petit bémol sur la complexité de prise en main 

Jetspeed portail est un outil classique, la gestion d’administration est assez complexe. L’aspect graphique n’est pas très 

évolué (carré). On peut également développer plusieurs types de Portlet JSP, JSP et Velocity, PHP, Struts. La communauté 

est assez importante également, on peut disposer d’un wiki (anglais) qui nous montre sous forme d’exemple les différentes 

créations, configuration ou customisation du portail. Il suit aussi la norme JSR-168. Il n’existe pas de forum dédié 

principalement à ce portail, ce qui peut rendre le développement plus difficile en cas de problème.


Différence Flex/Ajax 

Présentation 

Flex 

La technologie Flex a été créée en 2004 par Macromedia. A la fin de 

l’année 2005, Abobe opère au rachat de Macromedia. Pensant que le Flex pouvait 

devenir la technologie riche de référence, il décida de poursuivre son 

développement jusqu'à Flex 3 sorti courant 2007. Flex est ensemble d’outil 

formant un Framework de développement d’application en flash. Il s’appuie sur 

le langage XML et sur l’Action Script 3 (mi chemin entre java et c#) 

Il existe différents outils Adobe permettant un meilleur développement : 

Flex SDK : compilateur gratuit 

Flex Builder : l’IDE, version gratuite 60 jours 

Flex Charts : création de graphique 

Flex Data services : briques fournissant divers services vers le 

serveur 

Le point fort de cette technologie est la rapidité de développement 

d’application grâce à son IDE qui propose les différents utilitaires d’interfaces 

(bouton, liste,...). De plus, de nouveaux composants sont ajoutés (slider, 

accordéon), ce qui permet d’enrichir nos applications. Les appels à des Web 

Services sont très simplifiés. Il possède également une large communauté, ce 

qui permet d’interagir sur de nombreux problèmes. 

riche. 

L’avantage d’une base flash lui permet une création innovante, belle et 

Flex est sous licence MPL (Mozilla Public License) toutes les briques de son 

SDK, notamment : 



les compilateurs ActionScript 3 et MXML, c'est à dire le langage de 

script utilisé par Flex et la grammaire XML de description d'interfaces 

Flex 

le débuggeur ActionScript ainsi que les core librairies (toutes les 

fonctionnalités "de base") 

l'ensemble des composants Flex (correspondant par exemple aux 

accordéons, aux grilles de données, etc.) 

Ajax 

L’Ajax (Asynchronous JavaScript and XML) n’est pas une technologie mais 

une méthode d’utilisation de plusieurs technologies : Html, Xml, 

XmlHttpRequest, Css et JavaScript. Son principe de fonctionnement est que l’on 

ne recharge plus la page tout entière à chaque demande mais seulement une 

partie ce qui permet un temps de réaction beaucoup plus rapide. De plus, avec 

l’Ajax le traitement est effectué par le navigateur, et les données envoyées et 

reçues sont moins nombreuses. On peut donc ainsi avoir la possibilité du 

glisser/déposer par exemple. 

Plusieurs Framework sont mis à disposition afin de faciliter son 

développement (Dojo, Rialto, ATF, …). 

Le point fort de cette méthode est sa gratuité totale. Le nombre de 

Framework du marché assiste maintenant le développement pour le rende 

beaucoup plus simple et respectueux des normes en vigueur. 

AJAX n'est pas une technologie. 

AJAX est indépendant de tout environnement. 

AJAX peut être implémenté sur toute plateforme Web (PHP, JSP, Zope, 

...). 

AJAX désigne l'utilisation conjointe de plusieurs technologies Open 

Source. 



Site avec plusieurs exemples pour débuter : http://miniajax.com/ 

Laszlo 

Cette plateforme open source utilise le Xml et le JavaScript et est compilé 

sur une base Flash. 


diffusion 


Description détaillée d’Ajax 

Framework 

Prototype : ce Framework Javascript est utilisable tel quel, mais il sert 

également de base pour des librairies plus évoluées et plus lourdes comme 

Rico et Script.aculo.us (à voir ci-dessous). Il n’inclut donc pas d’effets 

visuels, mais comporte tout le nécessaire pour effectuer des requêtes en 

Ajax 

jQuery : JQuery est une librairie Javascript très prometteuse. Elle est 

légère, extensible et très simple à utiliser. La documentation est vraiment 

très complète, avec des tutoriaux abordant de manière thématique les 

différentes fonctionnalités. Idéal pour se lancer dans le développement 

Ajax 

Google Web Toolkit (Java) : Le Google Web Toolkit (GWT) est un 

Framework AJAX atypique dans le sens où : 

le développement se fait intégralement sous Java 1.4 (avec 

une API spécifique rappelant celle des bibliothèques 

graphiques Swing ou AWT) ; 

la compilation traduit le code Java en JavaScript (code illisible 

pour une modification future) 

Cette translation de code est une solution élégante pour développer des 

applications AJAX sans même connaître JavaScript 

Autorisation Google obligatoire pour la commercialisation, modification et 

de gwt-dev-***.jar (Java2Javascript) 



Atlas : Microsoft Atlas est un framework AJAX conçu pour s'intégrer au 

framework .NET. Ses bibliothèques Javascript sont construites et liées de 

manière complexe ce qui rend difficile leur utilisation sans les outils 

Microsoft (Visual Studio). De fait, Atlas prévoit des mécanismes exploitant 

la puissance de son framework .NET (par exemple, l'accès via C# à une 

base de données). De nombreux Widgets sont non compatibles Safari et 

Firefox. Solution propriétaire. 

Rico : A l’inverse de Prototype, Rico propose donc en plus du support Ajax 

la possibilité de fabriquer des animations ou d’effectuer des glissers- 

déposers (ou drags and drops en anglais) comme dans un logiciel 

classique. Malheureusement, sa documentation semble un peu succincte 

Librairies 

Script.aculo.us : sûrement un des plus connus (probablement à cause de 

son intégration à Ruby on Rails). Il bénéficie d’une communauté par 

conséquent importante et dispose même d’un mécanisme d’extension. 

Script.aculo.us est fournit de base avec l’auto-complétion en Ajax. Elle 

possède une large palette graphique. S’utilise avec la version 1.5.0 RC de 

prototype. 

Mootools : une librairie compacte et modulaire qui a été conçue en suivant 

les principes de la programmation orientée objet. Sa syntaxe est très 

agréable et de nombreuses extensions viennent compléter les 

fonctionnalités de base. Le module Ajax est capable de gérer le format 

Json 

Dojo Toolkit : certainement une des librairies les plus complètes qui 

soient. Dojo Toolkit est supportée par une fondation qui regroupe des 

entreprises comme IBM ou encore Sun Microsystems. Elle repose sur un 

système de widgets et le package Ajax prend en compte différents types 

de transport comme les iframes 



MochiKit : apparemment, les développeurs Python devraient s’y retrouver 

plus facilement que les autres, car on retrouve dans cette librairie un peu 

la philosophie de ce langage. MochiKit dispose de tout le nécessaire pour 

implémenter des tâches asynchrones. Peut de possibilité technique 

Yahoo! UI Library : Yahoo! a mis à disposition sa librairie Javascript sous 

une licence open source. Il est donc maintenant possible de concevoir des 

pages tout aussi riches et interactives que celles des nombreux portails de 

la société. Le support est bien évidemment exemplaire. Gestion des CSS. 

Mais un nombre restreint de composant. Possibilité de mettre cette 

bibliothèque au sein de Framework. 

Il existe encore bien d’autres librairies Ajax, dont certaines dépendent d’un 

langage de programmation comme Google Web Toolkit (Java) ou Xajax (Php) ou 

bien d’un environnement propriétaire comme Aflax (Flash). 

Il faut vraiment prendre le temps d’étudier en détails ces librairies afin de 

choisir celle qui correspond le mieux à ses besoins. Ce choix est important car il 

n’est pas facile ensuite de faire machine arrière et de migrer vers un autre 

Framework. 

On peut également citer Google Web Toolkit, qui est assez original par son 

modèle de développement : programmez en Java, le GWT génère le javascript 

pour vous ! Pratique pour bénéficier des environnements de développement 

Java, et surtout pour éviter d’avoir à maîtriser le Javascript (une connaissance 

rudimentaire ne suffit souvent pas pour faire des développements Ajax). GWT 

masque également les différences de comportement sur les principaux browsers, 

et permet d’automatiser les tests unitaires. 



SOURCE :HTTP://WWW.SIMPLEENTREPRENEUR.COM/2007/05/08/UNE-LISTE-DE- 

LIBRAIRIES-JAVASCRIPT-POUR-DEVELOPPER-EN-AJAX/ 

HTTP://AJAXIAN.COM/ARCHIVES/AJAXIANCOM-2006-SURVEY-RESULTS 

Tous ces produits sont Open Source sauf le GWT et Atlas qui sont des 

produits propriétaires. 



Description détaillée de Flex 

Un seul produit Adobe est disponible. 

Une version gratuite de Flex 3 SDK peut être installée dans Eclipse. Quant 

à lui, le Framework complet n’existe que en version free 60 jours et sinon est 

payant. 

Depuis 1 an Adobe à décidé de publier un socle de base au sein d’une 

communauté open-source afin de faire connaitre sa technologie. Il est donc 

possible de récupérer les applications de bases pour développer en Flex. 

Langages 

Le langage MXML est utilisé par les développeurs pour définir 

l'agencement, l'aspect et le comportement d'une application Flex. Le langage 

ActionScript 3 permet de définir les fonctions de traitement côté client. Il s'agit 

d'un langage orienté objet reposant sur le standard ECMAScript. La compilation 

des contenus MXML et ActionScript produit un fichier .swf unique constituant 

votre application Flex. Le compilateur étant fourni sous forme d'utilitaire distinct 

dans le kit SDK Flex 3 ou de composant d'Adobe Flex Builder 3, les 

développeurs optent pour l'environnement de développement intégré à Flex 

Builder, basé sur Eclipse, ou pour celui de leur choix. 

Bibliothèque de classes et services applicatifs 

Flex comprend une bibliothèque de classes prédéfinies et des services 

applicatifs facilitant l'assemblage et l'élaboration d'applications Internet riches 

côté développeurs. Ces services incluent les liaisons de données, le glisser- 

déposer, le système d'affichage applicable à l'agencement de l'interface 

utilisateur, le système stylistique gérant l'aspect de tous les composants de 

l'interface utilisateur, ainsi que le système d'effets spéciaux et d'animations 

applicables aux animations et transitions. 



Composants (Optimisation Flex 3) 

Options, cases à cocher ou boutons radio simples, ou grilles de données, 

listes modifiables ou éditeurs complexes, la bibliothèque de composants 

comprend toutes les commandes d'interfaces utilisateur requises par les 

développeurs. Servez-vous des conteneurs fournis pour concevoir facilement des 

agencements complexes et évolutifs, et utilisez les superbes habillages 

(modifiables à loisir) pour obtenir l'aspect recherché. 

Source : http://www.adobe.com/fr/products/flex/features/flex_framework/ 

Communication Flex 

Nous utilisons la technologie Flex afin de pouvoir créer un bandeau de 

navigation dynamique qui nous permettra de se balader au sein même des 

différentes activités et taches des processus Travail. Afin de pouvoir le créer 

dynamiquement à partir d’un fichier XML représentant notre structure du JCR, 

nous utilisons un service Web. Ensuite, afin de pouvoir interagir avec le broker 

d’évènement de la JSR-286, nous utilisons une communication Flex-JavaScript. 

Via Service Web 

En Flex l’appel d’un service Web est assez simple, il est réalisé à l’aide de 

la balise . Il a donc fallut créer un 

Service Web qui renvoi un Objet String représentant un fichier XML de notre JCR. 

Ensuite à l’aide de l’Action Script, nous recréons un fichier XML à partir de la 

réponse. 

Il ne reste plus qu’a traiter notre fichier XML afin de pouvoir créer 

dynamiquement notre processus. 

Via JavaScript 

Nous avons utilisé cette communication, qui est transparente pour 

l’utilisateur, afin de pouvoir récupérer et traiter un événement Flex (appuie sur 

un bouton). Ainsi, lorsque nous cliquons sur une section documentaire Flex appel 



une fonction ExternalInterface qui envoie un évènement qui est interprété par 

une fonction JavaScript présente dans la jsp embarquant notre application SWF. 

Il ne reste qu’a se plugger sur le système de communication « classique » 

(Récupération d’un formulaire html). On peut ainsi envoyer un évènement au 

broker qui le dispatchera à la Portlet appropriée. 



Mise en place d’une Portlet Client Riche (Flex) 

Comme nous l’avons décrit précédemment, ce portail est basé sur 

l’innovation et les nouvelles technologies. C’est pourquoi, l’arrivée des 

technologies client riche ne pouvait pas nous laisser indifférents. 

Nous avons donc décidé de mettre en place ces technologies au sein de 

notre bandeau de navigation. Nous avons retenu le Flex pour l’ergonomie de son 

design et pour la portée de ses actions. Ainsi, il a fallut l’intégrer au sein d’une 

Portlet. 

Voici un aperçu du concept à mettre en place afin de pouvoir l’utiliser : 

JSP portlets 

Wrapper.html 

chargeant le 

SWF 

Classe Java de 

traitement 

Transformation 

du Html en Jsp 

Web Service 

Wrapper.html 

AC_OETags.js 

History.js 

SWF 

MXML 

Compilation 



Présentation des différentes technologies utilisées 

Les portlets JSR-286 

La spécification JSR-286 est sorti courant été 2008 et elle est venue en 

complément de la spécification JSR-168. La principale nouveauté de cette 

spécification est la possibilité de coordination entre les différentes Portlet d’un 

même portail. 

De plus, la sortie de la nouvelle version de JBoss Portal 2.7, incorporant un 

Portlet container interprétant cette nouvelle spécification, nous a permis de 

totalement l’exploiter. 

Cycle de vie d’une Portlet 

Le conteneur de Portlet permet de faire le lien entre le portail (IHM) et les 

Portlets, il se charge de réceptionner les requêtes client et de les transmettre à la 

Portlet concernée. 

Phase d’initialisation 

HTTP://SZNAJDERMAN.DEVELOPPEZ.COM/ARTICLES/PORTLET/JSR168/ 

Durant cette phase (démarrage du serveur) les méthodes init() de 

chacune des Portlets sont appelées successivement. 



Phase d’exécution 

HTTP://SZNAJDERMAN.DEVELOPPEZ.COM/ARTICLES/PORTLET/JSR168/ 

Pendant la phase d’exécution, le Portal container exécute la méthode 

processAction() de la Portlet concernée par l’appel. Ensuite, les différents 

render() ou doView() des autres portlets sont appelés. On opère ainsi un 

rafraichissement de toutes les portlets de la page. 

destroy(). 

Lors de l’arrêt du serveur, toutes les portlets sont détruites via l’appel de 



Broker d’évènement 

Event 

Une des lacunes de la JSR-168 était la possibilité de communication entre 

les différentes portlets d’un portail. Avec l’arrivée de la JSR-286, cela devient 

possible à l’aide du broker d’évènement. 

Portlet. 

Voici un petit schéma qui explique parfaitement la communication inter- 

HTTP://WWW.IBM.COM/DEVELOPERWORKS/WEBSPHERE/LIBRARY/TECHARTICLES/0803_HEPP 

ER/0803_HEPPER.HTML 

Il suffit de définir dans le fichier de configuration Portlet.xml, quelles 

Portlets peuvent publier un évènement et quelles Portlets peuvent en recevoir. 

Ceci s’effectue à l’aide des tags respectivement publishing (nom de l’évènement 

à envoyer) et processing (nom de l’évènement à recevoir). Ensuite la Portlet 

réceptrice doit contenir une méthode processEvent() qui lui permettra de 

recevoir et traiter l’évènement. 

Lors de l’envoi d’un évènement, c’est le broker qui dispatchera les 

évènements vers les portlets appropriées. 



Public Render Parameters and aliases 

Nous avons du utiliser les public render parameters et les aliases, en 

complément des évents afin de pouvoir faire communiquer des portlets qui se 

trouvent sur 2 pages différentes (espace accueil et espace travail). 

Mise à part cet avantage de pouvoir partager un paramètre sur plusieurs 

pages, les public parameters sont limité au partage d’un seul paramètre alors 

que les évents sont plus appropriés lors du partage d’une structure. 

Le but de ces « public render parameters » est de partager au sein des 

portlets, préalablement définie, un paramètre public. A l’aide des aliases, on peut 

également faire le lien entre 2 paramètres et ainsi pouvoir communiquer entre 2 

portlets qui se trouvent sur 2 pages différentes. 



Voici comment on définit un public parameters : 

 

nomTravail 

qnomTravail 

 

Il suffit ensuite de définir qu’elle Portlet supporte ce paramètre : 

nomTravail). 

Puis, une fois dans la Portlet, on récupère ce paramètre à l’aide de la 

fonction classique : 

request.getParameter(« nomParamètre »). 



Java Content Repository JSR-170 

Afin de pouvoir réaliser une gestion de contenu digne de ce nom, nous 

nous sommes appuyés sur la JSR-170 et nous l’avons implémentée à l’aide de 

l’outil Open Source d’Apache, JackRabbit. 

Cette implémentation permet de parfaitement séparer la couche 

traitement et la couche données. Ainsi, le développeur ne s’occupe pas de la 

façon dont sont stockées les données en base de données. Il ne s’appuiera que 

sur les méthodes de JackRabbit pour sauver ses données. Comme nous l’avons 

expliqué dans les dossiers précédents, la structuration de nos données s’effectue 

sous forme d’un arbre comprenant différents nœuds et chaque nœud peut 

posséder de 0 à n propriété(s). 

Dans notre cas d’enregistrement d’une nouvelle section documentaire, le 

programme va vérifier si le nœud existe, si ce n’est pas le cas il va en créer un 

nouveau. Ensuite, nous allons sauvegarder le contenu de ce nœud dans une 

propriété « content » via la méthode Nœud.setProperty (« content », content). Il 

ne reste plus qu’à sauvegarder la session afin que tous les changements soient 

effectifs. Ensuite nous allons sauvegarder une version du nœud courant afin de 

pouvoir versionner nos contenu. 



Réunion de travail avec Olivier Tonnelier

Mémoire de fin d'études esiea - Free

Create successful ePaper yourself

Delete template?

Save as template?