Pfe

Je ddie ce rapport A mes chers parents, Ali Hassane Sa et Fatim Abatcha en tmoignage de toute ma gratitude et reconnaissance innies ; A mes
trs chers frres et surs , pour mavoir soutenu pendant mon cycle acadmique ; A tous mes amis et tous ceux que je porte dans mon cur, les mots ne sussent pas pour tmoigner de toute ma sympathie.
Remerciements
Mes remerciements les plus sincres, accompagns dune grande reconnaissance,

sadressent mes encadreurs Mr Soene GHARBI et Mme Mouna MAKNI pour leurs conseils et leurs soutiens sans cesse renouvels qui mont aid normment pour llaboration de ce projet.
Ces remerciements sadressent galement Mr Mohamed Ben SASSI chef de

lquipe e-Gov pour ses suggestions, sa disponibilit et son suivi qui ont constitu des lments essentiels lamlioration de ce travail sans oublier toute lquipe pour son soutien.
Je prote par la mme occasion pour remercier Mr Abdelmajid MILED, Directeur Informatique de la municipalit dAriana qui ma facilit la tche durant mes dplacements sans oublier le responsable technique Mr Aref GHOULEM pour son accueil chaleureux et son aide.
Reconnaissance profonde mes parents, connaissances et amis, quils reoivent

ici toute ma gratitude. Abdelsalam.
ii
Abstract
This project was carried out at ESPRITEC in collaboration with the municipality of Ariana, and follows within program of e-government in Tunisia. Our goal is to integrate dierent applications of the municipality in the Service Oriented Architecture (SOA) using middleware (ESB) to provide e-services for citizens and for the municipal agents.
Keywords : SOA, ESB, ServiceMix, OSGI, BPMN, SoaML.
Rsum.
Ce projet ralis au sein dESPRITEC en collaboration avec la municipalit de lAriana, entre dans le programme de ladministration lectronique en Tunisie. Il consiste intgrer les direntes applications municipales dans une architecture Oriente Service (SOA). Et ceci en utilisant un middleware (ESB) pour orir des eservices aux citoyens et aux agents municipaux.
Mot cls : SOA, ESB, ServiceMix, OSGI, BPMN, SoaML.
iii
Table des matires
Remerciements Liste des gures Introduction gnrale 1 Prsentation gnrale 1.1 1.2 Prsentation de lorganisme daccueil . . . . . . . . . . . . . . . . . . . Prsentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.3 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . Etude de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . Critique de lexistant . . . . . . . . . . . . . . . . . . . . . . . . Solution propose . . . . . . . . . . . . . . . . . . . . . . . . . .
ii vii 1 3 3 4 4 4 5 7 7 8 8 10 12 13 13 14 iv
Mthodologie de dveloppement . . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choix de la mthodologie de dveloppement . . . . . . . . . . .
2 Etat de lart des approches dintgration 2.1 Larchitecture SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 Les concepts lis une SOA . . . . . . . . . . . . . . . . . . . . Les approches dintgrations . . . . . . . . . . . . . . . . . . . .
TABLE DES MATIRES
2.1.3 2.1.4
Choix de lapproche . . . . . . . . . . . . . . . . . . . . . . . . . Les ESBs dans une SOA . . . . . . . . . . . . . . . . . . . . . .
19 19 21 21 21 22 22 23 27 27 28 30 37
3 Etude fonctionnelle et technique 3.1 Etude fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.1.4 3.2 Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . Identication des besoins . . . . . . . . . . . . . . . . . . . . . . Identication des cas dutilisations . . . . . . . . . . . . . . . . Description des cas dutilisations . . . . . . . . . . . . . . . . .
Etude technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 Capture des besoins techniques . . . . . . . . . . . . . . . . . . Choix de bus de mdiation . . . . . . . . . . . . . . . . . . . . . Les marchs des ESBs Open Source . . . . . . . . . . . . . . . .
4 Conception 4.1 Les approches de la mise en place dune SOA 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.2 . . . . . . . . . . . . . .
37 38 38 38 39 39 39 39 40 41 42 42 43 44 v
Approche Top down . . . . . . . . . . . . . . . . . . . . . . . . Approche Bottom up . . . . . . . . . . . . . . . . . . . . . . . . Outside In (Meet In The Middle) . . . . . . . . . . . . . . . . . Middle Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approche retenue . . . . . . . . . . . . . . . . . . . . . . . . . .
Couche mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 Langage de Modlisation BPMN . . . . . . . . . . . . . . . . .
Les processus mtiers . . . . . . . . . . . . . . . . . . . . . . . .
4.3
Couche fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 4.3.4 Language de modelisation SoaML . . . . . . . . . . . . . . . . . Architecture des services . . . . . . . . . . . . . . . . . . . . . . Le contract des services . . . . . . . . . . . . . . . . . . . . . .
Conception dynamique . . . . . . . . . . . . . . . . . . . . . . .
TABLE DES MATIRES
5 Ralisation 5.1 Gestion des congurations . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.2 Conguration matriel . . . . . . . . . . . . . . . . . . . . . . . Conguration logicielle . . . . . . . . . . . . . . . . . . . . . . .
48 48 48 49 51 51 52 54 54 55 55 56 57 58 60 61 i iii iv vi vii vii ix
Les direntes phases de ralisation . . . . . . . . . . . . . . . . . . . . 5.2.1 5.2.2 5.2.3 5.2.4 Architecture Cible . . . . . . . . . . . . . . . . . . . . . . . . . Le module Payments API . . . . . . . . . . . . . . . . . . . . Le module Update API . . . . . . . . . . . . . . . . . . . . . Dploiement des modules dans ServiceMix . . . . . . . . . . . .
5.3
Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 5.3.2 5.3.3 Test des services web . . . . . . . . . . . . . . . . . . . . . . . . Lapplication Web . . . . . . . . . . . . . . . . . . . . . . . . . Test des routes Apache Camel . . . . . . . . . . . . . . . . .
5.4 5.5
Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les ds relevs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion Gnrale Bibliographie Annexes A SOA B JBI(JSR 168) B.1 Les composants enchables (pluggable components) . . . . . . . . . . . B.2 Le mdiateur de JBI (JBI mediator) . . . . . . . . . . . . . . . . . . . C OSGI(JSR 8)
vi
Liste des gures
1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 3.2 3.3 3.4 3.5 3.6
Interface de lapplication Marchs et Biens . . . . . . . . . . . . . . . . Interface de lapplication GRB-Recette . . . . . . . . . . . . . . . . . . Flux interapplicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approche dintgration . . . . . . . . . . . . . . . . . . . . . . . . . . . Mthodologie 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evolution des technologies dintgration [7] . . . . . . . . . . . . . . . . Rle dun ESB dans une SOA [6] . . . . . . . . . . . . . . . . . . . . . . Processus mtier [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service mtier [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approche point point . . . . . . . . . . . . . . . . . . . . . . . . . . . Approche EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approche ESB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 6 6 8 10 12 13 14 14 15 16 17 19 22 27 28 28 31 32 vii
Rle dun ESB dans une SOA [6] . . . . . . . . . . . . . . . . . . . . . . Diagramme des cas dutilisation . . . . . . . . . . . . . . . . . . . . . . Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . Marchs des ESBs open source [4] . . . . . . . . . . . . . . . . . . . . . Les composants de Mule ESB [4] . . . . . . . . . . . . . . . . . . . . . Les composants de ServiceMix ESB [4] . . . . . . . . . . . . . . . . . .
LISTE DES FIGURES
3.7 3.8 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8
Les composants de Jboss ESB [4] . . . . . . . . . . . . . . . . . . . . . Les composants de Open ESB [4] . . . . . . . . . . . . . . . . . . . . . Approche de mise en place dune SOA . . . . . . . . . . . . . . . . . . Processus payement de lavis . . . . . . . . . . . . . . . . . . . . . . . . Processus Mis jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service consultation de lavis de payement . . . . . . . . . . . . . . . . Service eectuer payement . . . . . . . . . . . . . . . . . . . . . . . . . Service Etat payement (Mis jour) . . . . . . . . . . . . . . . . . . . . Diagramme de Squence objet pour le payement(Mis jour) . . . . . . Squence objet pour la mis jour . . . . . . . . . . . . . . . . . . . . . Architecture cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service getAvis de payement . . . . . . . . . . . . . . . . . . . . . . . . service web Eectuer payement . . . . . . . . . . . . . . . . . . . . . . Dploiement des modules dans ServiceMix . . . . . . . . . . . . . . . . Test avec soapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les interfaces web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test avec soapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chronogramme de droulement du projet . . . . . . . . . . . . . . . . .
33 34 37 40 41 42 43 44 44 45 46 52 53 53 55 55 56 57 59 vi
B.1 Archicture JBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 One Way Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
viii
Liste des tableaux
1.1 2.1 3.1 3.2 3.3 3.4 3.5 5.1 5.2
Comparaison entre les mthodologies de dveloppement . . . . . . . . . Principale fonctionnalits dun ESB[3] . . . . . . . . . . . . . . . . . .
9 18 23 24 25 26 35 53 54
Description du cas dutilisation "Consulter avis de payement" . . . . . Description du cas dutilisation "Eectuer payement" . . . . . . . . . . Description du cas dutilisation "Journaliser donnes des payements" . Description des cas "Mettre jour donnes" . . . . . . . . . . . . . . . Tableau compartatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description de service getAvis . . . . . . . . . . . . . . . . . . . . . . . Description de Service payement . . . . . . . . . . . . . . . . . . . . . .
ix
Introduction gnrale
Lmergence des socits de linformation et de la communication a considrablement aect les attentes des citoyens. Face cela, les administrations publiques doivent ds lors se rfrer des stratgies relevant du domaine des systmes dinformation pour la modernisation de leurs services publics. Ladministration lectronique ou e-Gov est lutilisation des technologies de linformation et de la communication, et plus particulirement dinternet, comme outils pour arriver une meilleure administration. 1 Lobjectif de la e-Gov au sens le plus large est ainsi une meilleure administration permettant ltablissement dun contact direct avec les citoyens. Comment les institutions peuvent-elles collaborer plus ecacement entre elles pour essayer de rsoudre des problmes communs ? Comment cibler davantage lusager et comment tisser des liens avec des partenaires du secteur priv ? Tels sont quelques problmes auxquels la e-Gov tente dapporter des rponses. La Tunisie intresse par ce modle dadministration a entrepris un projet de modernisation de son administration publique en particulier ses composantes locales dont les municipalits, qui joueront un rle dterminant.
Cest dans ce cadre que sinscrit ce projet de n dtudes ralis au sein dEspriTec en collaboration avec la municipalit dAriana et qui consiste faire communiquer les applications existantes a n daboutir un systme dinformation municipal intgr. Ce systme permet ainsi dorir des e-Services aux usagers : citoyens et entreprises dune part, dcideurs et responsables de la municipalit dautre part, pour une bonne
1. Dnition donne par lOCDE (Organisation de Coopration et de Dveloppement conomiques)
INTRODUCTION GNRALE
coordination des tches. Le prsent rapport sarticule autour de cinq chapitres : Le premier chapitre situe le projet dans son contexte gnral. Nous prsenterons dabord lorganisme daccueil EspriTec. Ensuite nous tudierons les applications existantes an de dcouvrir les moyens dchanges dinformations inter applicatifs. Le deuxime chapitre sintresse ltude thorique en relation avec le sujet dans le but de faire ressortir ltat de lart des approches dintgration. Dans le chapitre suivant une tude fonctionnelle pralable est faite pour dnir les besoins suivie dune tude technique pour faire le choix des principales technologies. Le quatrime chapitre consiste concevoir la solution propose avec un langage de modlisation simple et comprhensible. La phase de ralisation et des tests seront dcrits au niveau du cinquime chapitre. De plus, un bilan ainsi que les perspectives damlioration de la solution mise en place au cours de ce stage achveront ce rapport.
CHAPITRE
Prsentation gnrale
Introduction
Ce chapitre est consacr la description du cadre gnral du travail. La premire partie fournit une vue densemble sur lorganisme daccueil et la deuxime partie dcrit le contexte gnral en soulevant la probmatique du projet et en prsentant ltude du cas pour enn proposer une solution. Ladoption dune mthodologie du travail marquera la n de ce chapitre.
1.1
Prsentation de lorganisme daccueil
Le projet a t ralis au sein dEspriTec, lunit de Recherche-DveloppementInnovation (RDI) de lEcole Suprieure Priv dIngnierie et de Technologies (ESPRIT) situ au ple technologique El Ghazela. Cette unit soriente vers la recherche applique et privilgie deux axes : Laxe Technologique : pour la maitrse des technologies avances. Il ncessite la mise en place dun plate-forme pour le dveloppement des services et lexprimentation des nouvelles applications et des nouveaux services. Laxe Application et service : pour dvelopper des prototypes, des nouveaux services et applications avances pouvant avoir des retombes industrielles et/ou socio-conomique. EspriTec partage ses activits entre 3 grandes quipes : Lquipe e-gov ralise des projets dintegration et durbanisation des systmes dinformations ; Lquipe M2M(Machine to Machine) fait dans la technologie ambiante et le trai3
CHAPITRE 1. PRSENTATION GNRALE
tement dimage ; Lquipe Cloud travaille sur la mise en place des clouds. Les projets entrepris mobilisent des quipes composes de plusieurs chercheurs, enseignants-chercheurs, ingnieurs et tudiants en projet de n dtudes (PFE) et projet de n de lanne (PFA) sous la conduite dun chef de projet. Des tudiants en PFE, Mastres ou Doctorats dautres institutions sont aussi intgrs dans les quipes de projets dans le cadre de conventions de partenariat avec les laboratoires et units de recherche des tablissements publics. Notre projet, ralis au sein de lquipe e-gov entre galement dans le cadre de coopration entre EspriTec et ladministration publique Tunisienne dans son programme de gouvenement lectronique.
1.2
1.2.1
Prsentation du projet
Problmatique
Typiquement, le systme dinformation (SI) dune entreprise est gnralement bas sur des logiciels et des sources de donnes htrognes, rsultant de lutilisation successive des direntes technologies. Faire communiquer ces applications est une tche dlicate tant donn quelles ne sont pas dveloppes avec la mme technologie ou bien quelles sont installes sur des systmes dexploitations dirents. On peut faire face ce problme en dveloppant des connecteurs spcique pour chaque besoin dintgration mais cette solution verra rapidement ses limites quand le nombre des connexions augmente conduisant ainsi une architecture "Accidentelle" rsultant de lensemble des connexions. Ce qui empchera lvolution de systme dinformation
1.2.2
Cadre du projet
Le projet e-commune est un volet du grand projet de modernisation de ladministration lectronique (eGov) en Tunisie et en particulier sa composante locale o les municipalits joueront un rle dterminant. Il consiste faire communiquer les applications des municipalits pour aboutir un systme dinformation totalement intgr permettant dorir des e-Services aux usagers : citoyens et entreprises dune part, d4
cideurs, responsables et employs de la municipalit dautre part, an de les aider bien accomplir leurs tches.
1.2.3
Etude de lexistant
Le systme dinformation de la municipalit est constitu des applications htrognes qui sont installes sur des sites distants. Ces applications sont souvent amenes collaborer plus ecacement entre elles pour essayer de rsoudre des problmes communs. Dans cet optique, une tude sera mene sur deux principales applications (GRB-recettes et MB-application de gestion de biens) pour dcouvrir le moyen de communication existant. 1.2.3.1 Application Marchs et biens
Dveloppe en WinDev avec une base de donnes SQL Server, lapplication Marchs et biens permet de grer tous les biens que possdent la municipalit donc les marchs municipaux. Elle permet de suivre ltat de payement des locales lous.
Figure 1.1 Interface de lapplication Marchs et Biens
1.2.3.2
Application GRB
Cette application permet la gestion des ressources octroyant une partie du nancement du budget de la municipalit. Elle permet le recouvrement des ressources bud5
gtaires de la municipalit. Elle se prsente comme un systme qui se compose de dirents modules. Chaque module est dploy sur un site distant, en tenant compte de lactivit de ce site. Nous nous intressons au module GRB-recettes qui ore le service de payement.
Figure 1.2 Interface de lapplication GRB-Recette
1.2.3.3
Flux inter applicatif
A ltat actuel, la municpalit utilise des moyens traditionnels pour assurer linteroperabilit.
Figure 1.3 Flux interapplicatif
A partir de la Figure 1.3 on constate que : 1. Un avis de payement est gnr par lapplication MB ; 2. Cet avis est envoy par poste au locataire ; 3. Le locataire va se dplacer la recette municipale pour eectuer le payement ; 4. Une fois le payement eectu, lapplication GRB journalise les oprations de payement sous forme des reus ; 5. Un agent de lapplication MB se dplacera la recette pour rcuprer les reus de payement ; 6. En n lagent retournera lapplication MB pour mettre jour la situation nancire de tous les locataires.
Cette opration de mise jour est eectue regulirement un jour sur deux.
1.2.4
Critique de lexistant
Bien que La solution existante rponde aux besoins, cette dernire est loin dtre satisfaisante dans le cas o : La rception de lavis par le locataire nest pas garantie par le fait quil soit envoy par poste ; Le locataire est oblig chaque fois de faire la queue devant la recette municipale pour rgler sa situation nancire ; Les risques derreur ne sont pas pargns puisque le processus de journalisation et de mise jour est eectu manuellement, do la ncessit de recruter des agents supplmentaires pour faire les vrications. Dans la perspective douverture des SI sur des nouveaux partenaires administratifs, il y a un fort besoin dautomatisation et dvolution des processus mtier inter-agences, par consquent, il devient urgent de raligner le SI pour le moderniser et orir une meilleure qualit de service aux citoyens et aux dcideurs.
1.2.5
Solution propose
Face la problmatique dintgration, des solutions techniques sont disponible sur le march. Nous avons choisi dassurer linter oprabilit en mettant en place un bus 7
de mdiation qui assurer lintgration et lensemble ses problmatiques.
Figure 1.4 Approche dintgration
A partir de cette Figure 1.4, on peut constater que le bus joue le rle dun super mdiateur. Il bus permet une intgration plus rapide, plus conomique, plus souple des nouvelles applications dans le SI, et ouvrir la voie pour la mise dune architecture oriente service dans laquelle les direntes applications vont cooprer pour rsoudre un problme commun.
1.3
Mthodologie de dveloppement
Comme tout uvre humaine, le dveloppement informatique ncessite une mthode rigoureuse pour assurer un meilleur rendement en terme de qualit et de productivit. Au milieu des annes 90, on compte plus dune cinquantaine des methodes objets, chacune dnit par une notation et un processus spcique [9]. Vu ce nombre important, nous allons nous limiter une comparaison entre les mthodologies le plus utilises qui sont RUP, 2TUP et Scrum.
1.3.1
Comparaison
8
Description RUP Promu par Rational Le RUP est la fois une mthodologie et un outil prt lemploi Cible des projets de plus de 10 personnes 2TUP
Point forts Itratif Spcie le dialogue entre les dirents intervenants du projet Propose des modles de documents pour des projets types
Point faibles Coteux personnaliser Trs ax processus Peu de place pour le code et la technologie
Sarticule autour de larchitecture Propose un cycle de dveloppement en Y Cible des projets detoutes tailles
Itratif Laisse une large place la technologie et la gestion du risque Dnit des livrables, les les prols planintervenants,les
Plutt superciel sur les phases situes en amont et en aval du dveloppement Ne propose pas des documents types
nings,les prototypes Scrum
Se base des itrations dites sprints de dveloppement
Donner conance veloppeurs laisser travail ; aux et faire
toute dles leur
La mise en uvre du dveloppement nest pas prcise, seule compte la gestion des ressources humaines ; Le rapide tif une sur se dveloppement et rptipar des pression traduit
Faire des itrations de 30 jours pour laisser le temps de coder. Chaque itration a un objectif bien prcis("BackLog") et fournit une fonctionnalit teste.
forte
lensemble
membres de lquipe de dveloppement.
Tableau 1.1 Comparaison entre les mthodologies de dveloppement
On peut constater partir du rsultat du tableau comparatif que : Le RUP met laccent sur le cycle de vie de projet en spciant les interaction entre chacune des phases ; Scrum subdivise les dirente phases du projet en sprint qui en thorie ne dpasse pas 30 jours ; 2TUP laisse une large place lanalyse des besoins et larchitecture.
1.3.2
Choix de la mthodologie de dveloppement
Notre choix se portera sur la mthode 2TUP par le fait quil spare lanalyse des besoins du choix technique. Etant donn que le projet e-commune se base sur des applications existantes, cette mthodologie va faciliter ladoption du SI des nouvelles technologies. 2TUP fait partie de la famille des processus UPUnied Process qui constitue une trame commune pour intgrer les meilleures pratiques de dveloppement [9]. Un processus UP rpond aux exigences suivantes : il est itratif et incrmental, centr sur larchitecture, conduit par les exigences des utilisateurs et pilot par les risques.
Figure 1.5 Mthodologie 2TUP
10
Le processus 2TUP est un processus UP qui rpond aux exigences que nous venons de citer. 2 Track signie littralement que le processus suit deux chemins. Il sagit des chemins fonctionnels et darchitecture technique qui correspond aux deux axes des changements imposs au systme dinformation. [8] Ces deux branches vont fusionner ensuite pour aboutir une ralisation comme illustr dans la Figure 1.5
Conclusion
Au cours de ce chapitre nous avons prsent lorganisme daccueil EspriTec ainsi ses objectifs. Il tait aussi question de poser le problme an de trouver une solution. En vue de suivre la mthodologie adopte dans la dernire partie, une tude fonctionnelle et technique fera lobjet du prochain chapitre.
11
CHAPITRE
Etat de lart des approches dintgration
Introduction
Le systme dinformation dune entreprise est gnralement constitu des applications et de donnes htrognes rsultant de son hritage ou de lvolution technologique, ce qui se prsente comme un frein a la capacit dadaptation de lentreprise face des nouvelles technologies ou des nouvelles opportunits. Une de solution cette problmatique tait la mise dune architecture orient service (SOA). Une SOA vise mettre en place un systme dinformation trs souple, constitu de services applicatifs indpendants mais interconnects. Il ne sagit donc pas dune technologie mais bien dun concept architectural, sa mise en place est assure par des solutions techniques qui ont volu depuis le dbut des annes 90 (Figure 2.1).
Figure 2.1 Evolution des technologies dintgration [7]
12
CHAPITRE 2. ETAT DE LART DES APPROCHES DINTGRATION
Dans ce chapitre nous allons dabord prsenter les concepts lis une SOA ensuite faire un tour dhorizon sur les direntes approches dintgration pour la mise en place dune SOA.
2.1
Larchitecture SOA
"Une SOA est un style darchitecture logicielle pour lequel les processus mtier de lentreprise sont des composants logiciels paramtrables, orchestrant des tches avec les acteurs de lentreprise et des appels des composants de services pour sexcuter. "
Figure 2.2 Rle dun ESB dans une SOA [6]
2.1.1
2.1.1.1
Les concepts lis une SOA

Processus mtier
"Un processus mtier est un enchanement de tches mtier ralises par un ensemble dacteurs de lentreprise et produisant une valeur ajoute pour celle-ci".[6] Comme illustr sur la Figure, chaque tche du processus mtier consomme et/ou produit un objet mtier, chaque objet mtier reprsentant de linformation manipule par lentreprise, indpendamment de linformatisation. Un processus est dclench par un vnement, qui provient soit dun acteur, soit dun changement dtat dun objet mtier. 13
Figure 2.3 Processus mtier [6]
2.1.1.2
Service mtier
"Un service est un traitement normalis, mutualis et rfrenc au sein de lentreprise, dont linterface dappel est dcrite dans un langage neutre (indpendant des technologies) et qui est dploy physiquement sur un serveur."[6] On parle habituelle-
Figure 2.4 Service mtier [6]
ment de services au sens mtier, parce que ce sont les traitements mtier que lentreprise dsire mutualiser en tout premier lieu.
2.1.2
Les approches dintgrations
La mis en place dune architecture SOA consiste dabord intgrer les ressources applicatives de lentreprise. Dans ce qui suit nous allons prsenter les direntes approches dintgration pour choisir celle qui sera la mieux adapte pour la mise en place dune SOA. 14
2.1.2.1
Lintgration point point
La premire solution dintgration qui a vu le jour tait lintgration point point qui permet dtablir une connexion spcique entre chaque besoin dinteroprabilit. Elle peut tre classe suivant deux catgories : Lintgration par chiers dans laquelle le premier systme produit des chiers qui peuvent tre consomms par dautres systmes ; Lintgration par une base de donnes partage dans laquelle le premier systme crit dans une base de donnes partage, les autres systmes vont la consulter instantanment pour mettre jour leurs donnes.
Les problmes lis lintgration point point
Figure 2.5 Approche point point
Comme on peut voir sur la Figure 2.4, ce type dintgration ncessite la ralisation dune connexion spcique pour chaque besoin. Ce qui donnera lieu une architecture dite accidentelle semblable un plat de Spaghetti, qui aura comme consquence : une maintenance dicile et coteuse ; des connexions redondantes ; la dicult dajouter des nouvelles applications dans le SI ; Pour faire face ces problmes, dautres technologies dintgration ont vu le jour dans le but dorir une solution plus exible. Cest dans ce sens que lapproche EAI 15
(Entreprise Intgration Pattern) est apparue.
2.1.2.2
Les EAIs (Entreprise Application Integration)
Le produit EAI propose une architecture base sur un composant central (broker). Ce composant prend en charge lensemble des problmatiques dintgration (localisation, disponibilit, communication, interoprabilit au moyen de connecteurs spcialiss, audit, traces, scurit voire transaction) [2]. Chaque application a besoin dtablir une seule connexion avec le broker pour quelle puisse communiquer avec les autres applications du SI, ce qui permettra de mettre en valeur les applications existantes et de faire voluer en douceur le systme dinformation an de sadapter aux changements mtiers et lvolution technologique.
Les problmes lis lapproche EAI
Figure 2.6 Approche EAI
Malgr son rle central, les solutions dEAIs sourent de leur caractre trs propritaire [2] : Le protocole utilis pour les changes et le transport des messages au sein dun EAI est propritaire ; La technologie interne aux EAIs est propritaire. Ainsi, laccs aux applications se fait par lintermdiaire de connecteurs encore largement spcique chaque 16
diteur malgr des tentatives de standardisation comme JCA1 1 ; Le cot dacquisition et de la mise en place est assez lev vu laspect propritaire des EAIs ; A cause de son architecture hub and spoke 2 , lEAI centralise toutes les tches dintgration, en crant un Single Point Of Failure dans le sens o si lEAI tombe en panne cest tout le SI qui sera impact. Ce qui obligera de mettre en place un EAI hautement disponible avec un cot important. 2.1.2.3 Les ESBs (Entreprise Service Bus)
Selon Roy Schulte 3 , "LESB est une nouvelle architecture qui exploite les services web, les systmes orients messages, le routage intelligent et la transformation. LESB agit comme une colonne vertbrale lgre et omniprsente de lintgration travers laquelle les services logiciels et les composants applicatifs circulent". LESB peut tre considr comme le successeur direct des produits EAIs sauf quil propose une architecture en bus [Fig ESB]totalement distribue.
Figure 2.7 Approche ESB
1. Java Connector Architecutre 2. Architecture mettant en uvre un point de connexion central, A partir duquel on peut atteindre chacune des terminaisons situes la priphrie 3. Roy Schulte est le vice-prsident et analyste de Gartner Research
17
Fonctionnalit Connectivit
Description Supporte de multiples protocoles de transport synchrone ou asynchrone. Il faut voir lESB comme un "superconnecteur". Son rle est de se connecter tout type de ressources ou fournisseurs de services. Cest grce cela quil permet une exposition en couplage lche de fournisseurs de services.
Routage
Permet deectuer des routages de message bass sur des rgles (de contenu, de contexte, etc.). Idalement ce routage sappuie sur un annuaire, sur un registre de services et ventuellement sur un moteur de rgles.
Mdiation Exposition vices Agrgation simple des services des ser-
Adapte le format des messages, le protocole, eectue des transcodications entre lappelant et lappel. Transforme en service(s) un composant ou un traitement dune application qui ne le peut pas facilement. Eectue des agrgations simples de services de niveau N pour construire des services de niveau N+1. Si lagrgation est complexe on prfrera utiliser un moteur dorchestration.
Traitement
dvne-
Permet la cration des rgles de corrlation et de jointure dvnements. Permet la dnition des contrats de services : SLA, niveau de QoS, gestion des priorits, scurisation des messages (signature et cryptage), garantie de la livraison et de lintgrit des messages.
ments complexes Contract de service
Supervision et Audit
Ore des fonctions daudit, de traabilit, de mesure, dadministration et dexploitation qui permettent le suivi des traitements. Selon la qualit de limplmentation, cette fonctionnalit sera dlgue un outil tiers.
Tableau 2.1 Principale fonctionnalits dun ESB[3]
Le tableau ci dessus synthtise les prinicipales fonctionnalits que peut orir un ESB. 18
2.1.3
Choix de lapproche
Bien que lapproche ESB rpond la plupart des problmes pos par le produit EAI en adoptant des normes et de standards, mais son utilisation en dehors dune architecture oriente service ne favorise pas lagilit attendu dun SI. Une dmarche SOA avec lutilisation dun ESB rpondra la limite de lutilisation classique dun ESB.
2.1.4
Les ESBs dans une SOA
Pour que les composants dune SOA puissent communiquer de faon standard, il est ncessaire de disposer dune infrastructure permettant de les mettre en relation. Cest le rle de lESB. "LESB est un bus logiciel dintgration permettant de mettre en relation les dirents composants logiciels dune SOA au sein de lentreprise, indpendamment des types de protocoles et de messages utiliss" [6]. Il faut cependant savoir que la mise dun ESB ne deduit pas la mise en place dune SOA mme sil facilte normement la dmarche SOA.
Figure 2.8 Rle dun ESB dans une SOA [6]
Comme ulliust sur la Figure 2.7, lESB assure au minumum les fonctionnalits suivantes : Connecteurs ; 19
Transformation de donnes ; Annuaire de services ; Scurit et Monitoring ; Publication/Souscription dvnements ; Transport/Routage ;
Conclusion
Les direntes approches dintrgration savoir lintgration point point, les EAIs et lapproche SOA ont t voqu dans ce chapitre, Il a qui peut tre assur par la mise en place dun bus applicatif qui assure la communication, le routage, le transformation et lorchestration des services mtiers. Le prochain chapitre consistera analyser les besoins fonctionnels et techniques pour aboutir a une conception.
20
CHAPITRE
Etude fonctionnelle et technique
Introduction
Un modle bien dni est moiti rsolu. Lanalyse et la spcication des besoins sont une phase cruciale dans le processus de dveloppement des applications. Nous allons commencer ce chapitre par la dnition les besoins fonctionnels dans lesquels nous identierons les dirents acteurs ainsi que les cas dutilisation, suivi dune tude des besoins techniques qui consistera faire le choix de larchitecture et le bus de mdiation (ESB).
3.1
Etude fonctionnelle
Cette phase reprsente le point de vue fonctionnel de la solution. Il sera question principalement de dnir les acteurs et les dirents cas dutilisation.
3.1.1
Identication des acteurs
Lacteur est une entit externe qui interagit avec le systme. Il peut tre une personne humaine ou un systme. Trois acteurs ont t identis dans notre cas : Locataire : qui peut consulter, et ventuellement rgler sa situation nancire ; Lacteur MB : cest un acteur systme qui permet au locataire de consulter ses factures 21
CHAPITRE 3. ETUDE FONCTIONNELLE ET TECHNIQUE
Lacteur GRB : Cet acteur systme ore le service payement au locataire, il est responsable galement dassurer la mise jour avec lapplication MB.
3.1.2
Identication des besoins
Le rsultat de ltude prliminaire nous a permit de dgager les besoins suivants : La consultation en ligne de lavis de payement ; Le payement des dettes ; La journalisation des payements ; La mise jour des donnes.
3.1.3
Identication des cas dutilisations
Un cas dutilisation reprsente un ensemble de squences dactions ralises par le systme et produisant un rsultat observable intressant pour un acteur particulier.
Figure 3.1 Diagramme des cas dutilisation
22
3.1.4
3.1.4.1 Rsum
Description des cas dutilisations

Description du cas dutilisation Consulter avis de payement
Acteur : Locataire (principal) MB (secondaire) ; Titre : Consulter avis ; Description : Ce cas dutilisation permet au bnciaire de consulter ses dettes au prs de la municipalit.
Pr-condition
Le locataire doit tre identi auprs du systme
Enchainement 1. Le locataire fournit son identiant ou code scal ; 2. Le systme transmet lidentiant lapplication MB ; 3. Le MB vrie lidentit du bnciaire. Post-condition
La dette totale du bnciaire est dbite du montant rgl.
Squencement
Tableau 3.1 Description du cas dutilisation "Consulter avis de payement"
23
3.1.4.2 Rsum
Description du cas dutilisation Eectuer payement
Acteur : Locataire (principal) GRB (secondaire) ; Titre : Eectuer payement ; Description : Ce cas dutilisation permet lagent qui est en charge de lapplication MB denvoyer les avis des payements.
Pr-condition
Le locataire est identi auprs du systme
Enchainement 1. Le locataire fournit le montant payer ; 2. Le systme contrle le montant choisi par rapport la dette ; 3. Le systme rcupre ce montant pour envoyer au GRB ; 4. Lapplication GRB valide le payement. Post-condition
La dette totale du bnciaire est dbite du montant rgl La transaction est enregistre.
Squencement
Tableau 3.2 Description du cas dutilisation "Eectuer payement"
24
3.1.4.3
Description des cas dutilisations Journaliser donnes des payements
Rsum
Acteur : GRB(principal), MB(secondaire) Titre : Jounaliser donnes des payements Description : Lacteur systme GRB journalise les donnes des payements partir de ce cas dutilisation
Pr-condition
Payement eectu avec succs
Enchainement 1. Lapplication GRB journalise les payements ; 2. Le systme consulte ce journal pour dclencher la Mis jour. Scnario Alternatif
le journal est vide, le systme reprend lopration aprs un temps
Squencement
Tableau 3.3 Description du cas dutilisation "Journaliser donnes des payements"
25
3.1.4.4
Description du cas dutilisation Mettre jour donnes
Rsum
Acteur : GRB(principal), GRB(secondaire) Titre : Mettre jour Description : Par ce cas dutilisation lapplication GRB dclenche la mis jour avec lapplication MB.
Pr-condition
Il existe des donnes mettre jour
Enchainement 1. Lapplication GRB journalise les payements ; 2. Elle lance la mis jour auprs de MB ; 3. Lapplication valide la mis jour en renvoyant un message de succs. Scnario Alternatif
Code didentication erron : le systme indique lagent que le code est erron.
Squencement
Tableau 3.4 Description des cas "Mettre jour donnes"
26
3.2
Etude technique
La capture des besoins techniques couvre les spcications logicielles et la structure matrielle. Cette branche est primordiale dans le cycle de vie Y (2TUP dans notre cas), elle donne une vision globale sur larchitecture gnrale de notre projet. Cette tape comporte 2 grandes lignes : les spcications techniques et les spcications logicielles.
3.2.1
3.2.1.1
Capture des besoins techniques

Spcication du point de vue matriel
Le dploiement de la solution est illustr par le diagramme ci-dessous : Le locataire se connecte depuis son un poste au portail de la municipalit, le portail va le rediriger vers le serveur qui contient la couche prsentation (web). Le serveur a son tour consulte le service expos par lESB pour rpondre. En eet lESB hberge les processus mtier de lapplication. Ceux-ci interagissent avec les serveurs base des donnes de lapplication GRB et MB
Figure 3.2 Diagramme de dploiement
3.2.1.2
Spcication du style darchitecture
Dans un souci davoir un SI interoprable, nous avons choisi dadopter une architecture SOA puisquil rend le SI plus exible et volutive. Une telle architecucture est 27
subdivise en gnrale en quatre couches : La couche prsentation : qui permet linteraction entre le SI et les acteurs ; La couche mtier : qui hberge les processus mtier ; La couche fonctionnelle : expose les services oert par les blocs applicatifs du SI. Linfrastructure physique : o sont implments et excuts les blocs.
Figure 3.3 Architecture de la solution
3.2.2
Choix de bus de mdiation
Au cours de la dernire dcennie, dirents Open source ESBs ont fait leur apparition sur le march. Ladoption des standards comme XML et SOAP et des spcications comme la JBI,JCA ont ouvert la voie au dveloppement des ESBs Open source.
Figure 3.4 Marchs des ESBs open source [4]
28
3.2.2.1
Critre dvaluation
Dans le cadre de ce travail, nous allons eectuer une tude comparative entre les ESBs qui ont marqu le plus lattention (Mule ESB, Apache ServiceMix, Jboss ESB, Open ESB) selon les critres dnis ci-dessous : Support des standards ; Qualit de la documentation ; Support des moteurs dexcution ; Visibilit sur le march ; Support des outils de dveloppement ;
3.2.2.2
Support des standards
Les ESBs sont apparus la base pour palier au caractre propritaire des EAIs. Pour cela plusieurs standards (XML, Web service, ...) et des normes (JBI, OSGI, JCA) sont adopts pour standardiser les technologies dintgration. Cest pourquoi le support des standards est un critre prioritaire.
3.2.2.3
Qualit de la documentation
La dicult de travailler avec des produits open source est souvent li la qualit de la documentation. Il est ncessaire et mme trs important quune bonne documentation complte et mis jour soit mise la disposition des dveloppeurs (guide de dmarrage, exemples) pour faciliter son utilisation. Ce qui permettra aussi de crer une communaut active qui va soutenir ce projet.
3.2.2.4
Support des moteurs dexcution
Le support des outils dexcution comme le moteur de rgles mtiers est aussi un critre important. Lutilisation des moteurs dexcution existant sur le march rendra la solution plus complte et plus performante. 29
3.2.2.5
Visibilit sur le march
Un produit open source visible sur le march veut dire quil a attir lattention des plusieurs personne, soit des dveloppeurs ou des utilisateurs, ce qui garantie que ce produit a t test et prsentera moins de risque pour utiliser dans un environnement de production. 3.2.2.6 Support des outils de dveloppement
Un dernier critre quon veut voquer est le support des outils des dveloppements (IDE). En eet il est trs apprci que les solutions dintgration ore des outils de travail que la plupart des dveloppeurs sont familier comme Netbeans ou Eclipse car a va diminuer le temps dapprentissage et ainsi augmenter la productivit de lquipe de dveloppement.
3.2.3
3.2.3.1
Les marchs des ESBs Open Source

Mule ESB
Mule ESB est un projet de Mule Source dvelopp la base par Ross Mason 1 qui a voulu implmenter un outil dintgration en basant sur les EIP(Entreprise Intgration Pattern). Cest lESB open source le plus utilis au monde avec plus dun million et demi (1,5 millions) de tlchargement [ociel]. Il est lger, bas sur Java et peut tre intgr dans nimporte quel serveur dapplication JEE. Mule ESB a choisi de ne pas implmenter la spcication JBI mais ore un connecteur qui lui permit dtre compatible JBI.
1. CTO Co-fondateur du Mule Source
30
Figure 3.5 Les composants de Mule ESB [4]
Daprs cette Figure 3.5 on peut constater que Mule : fournit une large gamme des composants de liaison le plus populaire dont : HTTP, FTP, XMPP, EJB, Mail, ... supporte les outils dexecution pour la transformation, le routage... ore des outils de dveloppement pour lIDE Netbeans et Eclipse ; est support par la communaut Mule Source souvent en version commerciale. Rsum : Mule ESB est bien plac sur le march des ESBs, car il occupe la premire place devant ServiceMix. En eet il est utilis par les gants de linformatique comme Google et HP pour sa simplicit de mise en place et sa robustesse. Mule ESB accuse cependant quelques retards au niveau de lutilisation des normes JBI et OSGI. 31
3.2.3.2
Apache ServiceMix
Projet open source de la fondation Apache, ServiceMix est une implmentation de la norme JBI (Java Business Intgration), lobjectif de la spcication tant de standardiser la technologie dintgration. ServiceMix est intgr avec plusieurs autres projets Apache comme : ActiveMQ pour le messaging ; Apache Camel pour implmenter les patterns EIP ; Apache CXF pour les Webservices ; Apache ODE comme moteur dorchestration.
Figure 3.6 Les composants de ServiceMix ESB [4]
La Figure 3.6 montre que : Les adaptateurs File, FTP, HTTP, SNMP, SMPP, XMPP, VSF, mail sont fournis par ServiceMix ; ServiceMix supporte les moteurs dexcution pour le bean, Workow, Drools, Saxon... ; Possde des outils de dveloppement comme : Eclipse Bpel designer, Fuse Inte32
gration Designer ; Bnecie du support de la communaut Apache et Fuse(support commercial). Rsum : LESB de la fondation Apache a un avenir clairement trac vers des pratiques dles lavenir de linformatique [2]. Ceci grce a sa conformit aux normes des technologies dintgration et aussi des puissants outils comme Apache Camel, ActiveMQ, Apache CXF... ServiceMix se distingue galement par le soutien apport par Software Progress sous son projet FUSE. 3.2.3.3 Jboss ESB
La solution est issue de lESB Rosetta acquis par JBoss en juin 2006, et mis en Open Source. JBoss ESB reste tout de mme trs li avec les autres produits JBoss. Ainsi il utilise [2] : JBoss Rules pour assurer la fonctionnalit de routage ; JBPM pour orchestrer les processus mtiers ; JBoss Application Server pour utiliser des composants EJB3 (Entreprise JavaBeans) ou des POJOs(Plain Old Java Object) ;
Figure 3.7 Les composants de Jboss ESB [4]
33
lillustration de la Figure 3.7 montre que Jboss : permet dadapter les protocoles comme HTTP, FTP, XMPP, EJB, JCA, mais aussi les base de donnes ; peut intgrer le moteur Drools, les EJBs, Seam, Spring bean ; possde Jboss Tools comme outils de dveloppement mais aussi Jboss Dvelopper Studio en version commercial ; bncie dun support communautaire de la part Jboss Community mais aussi un support commercial Jboss SOA subscription. Rsum : Dans son tat actuel, JBoss ESB reste une ore classique qui ne se distingue pas[2]. En revanche JBoss pourra faire mieux en protant de sa forte communaut et aussi en pensant respecter le standard dimplmentation comme la JBI et NMR.
3.2.3.4
Open ESB
Open ESB est une implmentation JBI de Sun Microsystems. Suite au rachat du SUN par oracle, Open ESB est confront la concurrence de lore ESB de ce dernier, mais des solutions sont en cours pour unier ces deux solutions.
Figure 3.8 Les composants de Open ESB [4]
34
La Figure 3.8 permet de faire les remarque suivant sur lESB de Sun/Oracle : possde une liste compte dadaptateur mme si certain sont en version incubator ; se distingue par un outil de dveloppement complet qui inclut : un Bpel Editor, Service Assembly Editor, CASA... est support par la communaut SUN. Rsum : OpenESB se distingue des autres ESB par le fait quil est bas sur une architecture solide (JBI-NMR, Glasssh, gwt-console) et sur un environnement de dveloppement convivial (Netbeans) pour quelques composants standards (BPEL, EIP). Malheureusement, les composants nachent pas tous le mme niveau de qualit et de fonctionnalit. La prochaine version dOpen ESB reposera sur des composants OSGI - Open Services Gateway Initiatives (comme la version 3 de Glasssh) et sur Maven pour la partie dveloppement [2]. Il sera donc possible de crer et de dployer des composants partir de commandes Maven. 3.2.3.5 Solution rtnue
Letude prcedente nous a permi de construire le tableau comparatif ci-dessous :
Critres Support des standards Qualit de la documentation Support des moteurs dexcution Visibilit march Support des outils de dveloppement
Tableau 3.5 Tableau compartatif
+ ++ + ++ +
++ ++ ++ ++ +
++ + + + ++
+ ++ + + +
sur
le
35
Le tableau 3.5 permet de dduire que : Mule ESB est bien plac sur le march des ESBs open source OpenESB et JBoss ESB sappuient plus sur un style de dveloppement graphique orient "drag and drop". ServiceMix se base essentiellement sur les standards comme la JBI et OSGI et ore un outillage complet pour un solution dintgration ; ServiceMix vient derrire Mule ESB en terme de visibilit sur le march. ServiceMix bncie du soutient de la grande communaut IONA dans son projet FUSE. Dans le cadre de notre travail, notre choix sest port sur ServiceMix ESB pour les raisons suivantes : Il est conforme aux standards dimplmentation JBI et OSGI. Ce qui facilite le partage et la rutilisabilit des composants ; Il bncie du support de la communaut FUSE en plus de la communaut Apache ; Il supporte la plupart des projets dintgration dApache tels que Apache Camel, Apache CXF, Apache Felix, Apache ODE, Active MQ.
conclusion
Ce chapitre a servi pour, dune part la prsentation en clair de nos besoins en identiant les acteurs, les cas dutilisations et dautre part une tude technique dans laquelle nous avions spci le choix de larchitecutre et fait une tude comparative aux niveaux des direntes ores ESBs pour choisir enn ServiceMix comme bus de mdiation. Cette description dgage prpare le terrain pour la phase de conception.
36
CHAPITRE
Conception
Introduction
La fusion entre la branche fonctionnelle et la branche technique seectue ce stade : cest ltape la plus dlicate, qui va intgrer la branche fonctionnelle qui constitue lme du projet et la branche technique qui constitue le squelette de ce dernier de manire tracer la cartographie des composants du systme dvelopper. Au cours de ce chapitre nous allons eectuer une tude sur les direntes approches de la mise en place dune SOA ensuite concevoir la solution avec lapproche choisie.
4.1
Les approches de la mise en place dune SOA
Mettre en place une architecture SOA nest pas chose facile puisquil va impacter toutes les composantes du SI. Direntes approches existent, chacun avec sa spcicit.
Figure 4.1 Approche de mise en place dune SOA
37
CHAPITRE 4. CONCEPTION
4.1.1
Approche Top down
Lapproche top down consiste dnir dabord les services mtiers et ensuite dvelopp les services ncessaires pour raliser les processus mtiers. Cette approche permet de piloter la SOA par les besoins mtiers et de minimiser la redondance de services. Elle nest cependant que rarement possible car elle signie une refonte de tout ou partie du SI, juge bien souvent trop coteuse et trop risqu [7] .
4.1.2
Approche Bottom up
A linverse de lapproche top down, cette approche propose une dmarche ascendante pour la mise en place dune SOA. Autrement dit, elle consiste faire une analyse de lexistant an didentier les services. Elle peut sduire par plusieurs aspects car : Elle contraint dresser une cartographie du SI pour faciliter la rutilisation des services. Le cot de ralisation peut paratre moins lev que pour une dmarche Top Down. Cependant : Elle bloque le pilotage de la SOA par les besoins mtiers. Elle ne favorise pas la mise en place dun eort transverse : elle ne permet pas de sortir de la culture projet. En eet, les services mergeants de cette approche restent trs fortement coupls leur application dorigine. Enn, cette approche se limite une mise en mode service de fonctions existantes sur le SI.
4.1.3
Outside In (Meet In The Middle)
Cette approche prconise de mener en parallle : Une dmarche Top Down pour dnir les processus mtiers et les services de plus haut niveau ncessaires leur ralisation ; Une dmarche Bottom Up an de cartographier lexistant applicatif dont dispose lentreprise pour supporter les services mtiers forte valeur ajoute. Une fois ces deux dmarches termines, il faut fusionner les rsultats de ces deux approches an de dterminer les processus mtiers. Ainsi, cette approche runit les 38
bnces des approches Top Down et Bottom Up. Elle permet de piloter la SOA par les besoins mtiers tout en facilitant la rutilisation de services et la capitalisation sur lexistant. Mais elle cumule galement les travers des deux approches, notamment en induisant un trs fort risque deet tunnel [7].
4.1.4
Middle Out
Par opposition lapproche Outside In, cette mthode propose de commencer In the middle, cest--dire l o le mtier et les IT parlent le mme langage (ou en tout cas presque). Cette approche fait donc la part belle au dialogue entre mtier et IT et pose la comprhension mutuelle comme prrequis la mise en uvre dune SOA. Elle limite par contre le pilotage de la SOA par les besoins mtiers, puisque le point de dpart est lidentication des services mtiers ncessaires et non la dnition des processus ralisant le mtier de lentreprise.
4.1.5
Approche retenue
Ltude prcdente permet de constater quil nexiste pas une recette miracle pour la mise en uvre dune architecture oriente services (SOA). Il ne sert rien donc de croire que lapplication dune des approches (prsentes plus haut) garantisse sa russite puisque la rponse adquate dpend du contexte de lentreprise : ses besoins, ses moyens, ses ambitions, son existant (organisationnel et mthodologique), Ainsi lapproche qui parat plus adquate pour la prsente tude de cas est la Outside In (Meet In The Middle) pour les raisons suivantes : Valorisation de lexistant pour crer des services valeur ajoute ; Alignement de la SI de la municipalit derrire son mtier.
4.2
4.2.1
Couche mtier
Langage de Modlisation BPMN
Business Process Modeling Notation (BPMN) est une norme de notation graphique pour la modlisation de processus, soutenue par lOMG/BPMI (Object Management Group/Business Process Management Initiative).[8] 39
Son objectif est de fournir un cadre permettant de dcrire un processus dune manire commune tous les utilisateurs et ceci indpendamment de loutil utilis. Loutil tant bien sr cens supporter la norme. Les lments de base sont de quatre types : les couloirs (Pools et Lanes) qui dnissent les participants et les activits qui leurs sont attribus ; les objets de ux (Tasks, Events et Gateways) qui reprsentent les activits, vnements et les portes ; les objets de relation (Connecting Objects) qui reprsentent les squences, les messages et les associations ; les objets symboliques (Artifacts) produits et consomms par les activits. La combinaison de ces lments permet de dcrire graphiquement les interactions entre les participants (humains ou systme) et le comportement attendu de lapplication.
4.2.2
Les processus mtiers
Dans cette section nous allons modliser les dirents processus mtier en utilisant le langage de modlisation BPMN. 4.2.2.1 Processus payement
Le processus consultation et payement de lavis est modlis de la manire suivante :
Figure 4.2 Processus payement de lavis
40
Le diagramme de la Figure 4.2 dcrit les direntes tape pour la consultation et le payement, en eet chaque couloirs contient le participant avec ses activits (tches), et les interactions avec les autres participant. Le participant locataire lance le processus avec une demande de consultation auprs du participant MB. Ce dernier lui autorise consulter son avis et procde en n au payement par le biai du participant GRB.
4.2.2.2
Processus mis jour
Le deuxime processus identi est le processus mis jour qui est rpresent par le diagramme BPMN ci-dessous :
Figure 4.3 Processus Mis jour
Ce diagramme permet de constater que le processus est lanc par un Timer, ensuite la tche mis jour est lance. Sil existe des donnes mettre jour. Cette tche sera eective, sinon un message derreur marquera la n du processus.
4.3
Couche fonctionnelle
Chaque processus dcrit dans la couche mtier va tre dtaill dans la couche fonctionnelle (service) de manire identier les services participants sa ralisation. Ce qui permettra didentier les interfaces et les oprations des services ainsi que les composants applicatifs qui les fournissent ou requirent. Pour raliser cette modlisation, nous utiliserons le langage SoaML . 41
4.3.1
Language de modelisation SoaML
Service oriented architecture Modeling Language (SoaML) adopte en 2009 par lOMG est une extension du langage de modlisation UML ddi la modlisation darchitecture SOA, selon le standard OMG. Le but de SoaML est de fournir aux utilisateurs du langage UML les moyens de modliser une architecture oriente services, comprenant donc des notions de consommateurs et de fournisseurs de services, ainsi que la notion de contrats [10].
4.3.2
Architecture des services
Avant de procder lidentication des services, nous prsenterons dabord larchicteture des services en montrant les dirents participants et leur rle (Consommateur ou fournisseur).
Figure 4.4 Service Architecture
42
Daprs ce diagramme, lutilisateur et les ressources applicatives sont considrs comme des participants au sens SoaML du terme. Un participant peut tre fournisseur et/ou consommateur de service. Chaque pair de participants est li par un contrat de service. Ainsi, les services exposs sont : Le service consultation de lavis de payement, oert par lapplication MB permet au locataire de consulter ses dettes ; Le service de paiement, fourni par lapplication GRB-Recette permet au locataire de payer sa facture ; Les services mise jour ralise la mise jour de ltat de locataire une fois quil a eectuer son payement au prs lapplication GRB.
4.3.3
Le contract des services
Dans cette section, chaque service dcrit dans les diagrammes Systeme architecture va tre dtaill an de dcrire son interface et son contrat laide du diagramme de contrat de service. Le contrat de service reprsente un accord entre les participant la faon dont le service doit tre fourni et consomm. Laccord inclut les interfaces, la chorgraphie et toutes les autres modalits et conditions. Un contrat de service permet de : Spcier linterface du service, ses oprations, ses conditions dutilisations ; Relier les fournisseurs et les consommateurs du service. Les gures suivantes reprsentent les diagrammes des contrats des services mtiers dnis prcdemment.
Figure 4.5 Service consultation de lavis de payement
43
Le diagramme de la Figure 4.5 reprsente le contrat qui existe entre le fournisseur et le consommateur de service consultation de lavis de payement. le fournisseur de ce service est le provider MB qui va condition lutilisation de ce service que par un consumer de type locataire.
Figure 4.6 Service eectuer payement
La Figure 4.6 met en vidence le contract qui existe entre le GRB provider et le locataire consumer pour lutilisation du service payement.
Figure 4.7 Service Etat payement (Mis jour)
Le contract de service mis jour est present par le diagramme de la Figure 4.7 en montrant le provider et le consumer de ce service.
4.3.4
Conception dynamique
Pour mieux comprendre le comportement du systme lors de chaque action, le diagramme de squences est plus signicatifs en termes de dynamicit. "Les diagrammes 44
de squences sont la reprsentation graphique des interactions entre les acteurs et le systme selon un ordre chronologique dans la formulation UML." Nous allons prsenter le diagramme de squence dynamique pour le scnario consultation et payement et le scnario mis jour.
4.3.4.1
scnario Consultation et Payement
Figure 4.8 Diagramme de Squence objet pour le payement(Mis jour)
La Figure 4.8 dcrit le scnario "Consultation et Payement", Le locataire partir du portail de la municipalit consulte son avis de payement. LESB prend en charge cette demande pour retourner les donnes de payement. Ce qui permettra au locataire deectuer un payement. La tentative de la consultation est limit pour renforcer la 45
securit du systme. 4.3.4.2 Scnario Mis jour
Figure 4.9 Squence objet pour la mis jour
Le diagramme de la Figure 4.9 montre les direntes tapes avec lesquelles la mise jour des donnes est eectue entre GRB et MB. LESB coute partir dun leEndpoint et rcupre les donnes journaliss pendant le payement. Ensuite une requte de mis jour permettra de naliser lopration. En cas derreur, un Message derreur ach.
46
conclusion
Ce chapitre a donn loccasion dexplicitr notre approche de conception, nous avons dabord modlis les processus mtiers ncessaires pour la mise en place de larchitecture SOA. La description simple et dtaille de ces services vont faciliter le dernire phase de ce projet qui consiste implmenter les dirents services an de concrtiser la solution.
47
CHAPITRE
Ralisation
Introduction
Dans cette partie, il sera question de dcrire laspect implmentation du systme. La premire partie prsentera la conguration matrielle et logicielle du travail, la deuxime partie sera consacre aux direntes phases de ralisation de ce projet.
5.1
5.1.1
Gestion des congurations

Conguration matriel
Le prsent travail est ralis dans un environement distribu qui est constitu de deux serveurs distants dans lesquels sont installes les applications de la recette municipale (GRB) et celle de gestion de marchs et biens(MB). Loutil de mdiation (ServiceMix ESB) peut tre install dans lune de ces deux machines avec une conguration minimale de : Hardware : 100 MB despace disque pour ServiceMix 4.x binary distribution. Systme dexploitation : Windows : Windows XP SP2, Windows 2000, Windows Vista, Windows 7 ; Unix : Nimporte quelle distribution Linux/Unix platform qui supporte Java. Environnement : Java Developer Kit (JDK) 1.6.x (Java 6) ou suprieur pour le dploiement et la compilation. 48
CHAPITRE 5. RALISATION
5.1.2
Conguration logicielle
Au cours dun dveloppement logiciel, plusieurs changement peuvent survenir : dabord le code change rgulirement et en plus nous ne sommes pas labri des mauvaises surprises. Ce qui nous impose de contrler ces changements et de mettre en place un moyen de restauration en cas de perte des donnes. Pour cela, nous avons eu recours a la Software conguration management (SCM). Dans cette section nous allons prsenter les dirents outils que nous avons utiliss conformment aux standards SCM :
5.1.2.1
Subclipse plugin
Subclipse est un plugin de gestion de version fournit avec lIDE eclipse. Dvelopp et maintnu par "Subversion core committers", Subclipse est un outil de partage de code au sein de lquipe de dveloppement.
5.1.2.2
Rioux SVN Serveur
Rioux est un "Subversion hosting website" priv et totalement gratuit. Il permet essentiellement de synchroniser le workspace local avec le repository en ligne et de partager le projet avec le reste de lquipe.
5.1.2.3
Outils de dveloppement
La mise en place de la solution a necessit galement lutilisation de plusieurs autres outils :
Eclipse Eclipse est un projet de la Fondation Eclipse visant dvelopper tout un environnement de dveloppement libre, extensible, universel et polyvalent. Son objectif est de produire et fournir divers outils gravitant autour de la ralisation de logiciel, englobant les activits de codage logiciel proprement dites (avec notamment un environnement de dveloppement intgr) mais aussi de modlisation, de conception, de test, de reporting, etc. Son environnement de dveloppement notamment vise la gnricit pour 49
lui permettre de supporter nimporte quel langage de programmation.
Maven 3 Apache Maven est un outil logiciel libre pour la gestion et lautomatisation de production des projets logiciels Java en gnral et Java EE en particulier. Lobjectif recherch est comparable au systme Make sous Unix : produire un logiciel partir de ses sources, en optimisant les tches ralises cette n et en garantissant le bon ordre de fabrication.
soapUI soapUI est un outil open source multi-plateforme pour faire des tests fonctionnels. Avec un interface graphique facile utiliser, soapUI permet facilement et rapidement crer et excuter automatiss les fonctionnalits de rgression, de la conformit et des tests de charge. soapUI permet de tester des webservices, des composants JMS, JDBC, etc...
MySQL 5.1 MySQL est un systme de gestion de base de donnes (SGBD). Selon le type dapplication, sa licence est libre ou propritaire. Il fait partie des logiciels de gestion de base de donnes les plus utiliss au monde, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avec Oracle et Microsoft SQL Server.
MySQL Workbench 5.1 MySQL Workbench est un outil visuel uni pour architectes, dveloppeurs et administrateurs de base de donnes. MySQL Workbench fournit la modlisation des donnes, le dveloppement SQL et des outils dadministration complets pour la conguration des serveurs, ladministration des utilisateurs et davantage. MySQL Workbench est disponible sous Windows, Linux et Mac OS. 50
LaTeX
A L TEX, est un langage et un systme de composition de documents cr par Leslie
Lamport. Plus exactement, il sagit dune collection de macro-commandes destines faciliter lutilisation du processeur de texte TeX de Donald Knuth. Il a t cre en
A 1985. Depuis 1993, il est maintenu par le L TEX3 Project team. La dernire version majeure est appele LaTeX2 .
OmniGrae OmniGrae est un logiciel de cration de diagramme dvelopp par Omni Group et uniquement pour Mac OS X. Dans beaucoup daspects, OmniGrae est similaire Microsoft Oce Visio, de plus la version professionnelle de OmniGrae peut aussi bien importer quexporter des documents Visio. Il peut tre utilis pour raliser des diagrammes simples, des organigrammes ou des illustrations. Il fonctionne grce une interface WYSIWYG tout en glissant-dposant. Des palettes regroupant des motifs sont disponibles sous la forme dextensions et les utilisateurs peuvent galement crer leurs propres palettes.
5.2
Les direntes phases de ralisation
Dans cette section les direntes phases de la ralisation seront prsentes. nous allons dabord prsenter larchitecture avant de dtailler les services qui ont t developp. Nous allons nir par une phase de test et validation.
5.2.1
Architecture Cible
Larchitecture cible est illustre par la Figure 5.1. Elle est divise en deux modules : Le module Payments API Le module Update API
51
lESB joue le rle dun conteneur et hberge les services necessaires pour la ralisation des modules. Il assure galement la communication avec lextrieur avec les protocoles JDBC, SOAP, HTTP, FTP.
Figure 5.1 Architecture cible
5.2.2
Le module Payments API
Ce module est ralis base de deux services web qui sont : Le service consultation de lavis de payement ; Le service eectuer payement. Nous avons utilis Apache CXF pour dvelopper les services web et dployer ServiceMix. En eet Apache CXF est un Framework open source pour le dveloppement des services web. Il permet de crer des services en utilisant les technologies JAX-WS, JAX-RS. Ces services peuvent communiquer travers une varit de protocoles dont SOAP, XML/HTTP, REST/HTTP et CORBA.
52
5.2.2.1
Le service consultation de lavis de payement
Le service web consultation de lavis de payement permet dextraire les donnes de payement partir de lapplication MB. Il est illustr par la Figure 5.2.
Figure 5.2 Service getAvis de payement
Element <Service> <Operation> <Messages> <portType>
Description ServiceGetAvis getAvis getAvis, getAvisResponse getAvisImplPort

Tableau 5.1 Description de service getAvis
5.2.2.2
Le service eectuer payement
Le service eectuer payement est galement dvelopp sous forme dun web service (Figure 5.3) oert par lapplication GRB.
Figure 5.3 service web Eectuer payement
53
Element <Service> <Operation> <Messages> <portType>
Description ServicePayement payerAvis payerAvis, payerAvisResponse payementImplPort

Tableau 5.2 Description de Service payement
5.2.3
Le module Update API
Ce module se charge de mettre jour les donnes entre la base de donnes de lapplication GRB et celle de la MB. Ce service est ralis par le composant Apache Camel. Apache Camel est une implmentation des EIPs par la fondation Apache et fournit avec la solution ServiceMix. Il est notamment consitu : dun leConsumer qui lit les messages partir dun serveur FTP ; dun JMS queue qui reoit les message en provenance du leConsumer ; dun client JMS qui lit partir de la queue JMS ; dun agregator quant a lui se charge de rassembler tous les messages reus en un seul message ; dun module "Upadate API" qui eectue la mis jour vers la base de donnes de MB. Lutilisation des messages dans ce module sexplique par le fait quil favorise la communication asynchrone.
5.2.4
Dploiement des modules dans ServiceMix
Le dploiement des modules sous Servicemix se fait de plusieurs manires : soit en crant des composant JBI communment appel Service Assembly soit sous forme des Bundles OSGI. Nous avons opt pour la deuxime alternative pour sa simplicit et le fait quon peut dployer dans nimporte quel conteneur OSGI. 54
Figure 5.4 Dploiement des modules dans ServiceMix
5.3
dedis.
Tests et validation
Cette phase consiste faire les tests sur les services developps avec des outils
5.3.1
Test des services web
Le test des services a t eectu avec loutil soapUI.
Figure 5.5 Test avec soapUI
55
Lappel chacun de ces deux services web est rpresent par lillustration ci-dessus. On peut constater que : Le premier webservice rpond avec un temps total de 6ms Le deuxime webservice quand a lui prend 5ms ce qui donne un temps de rponse moyen de 5.5ms qui est largement acceptable.
5.3.2
Lapplication Web
Pour tester les direntes fonctionnalits, nous avons dvelopp un portail web pour la municipalit. Ce portail est dvelopp en Java(JSP/servlet) et communique avec lESB travers des services web.
Figure 5.6 Les interfaces web
La Figure 5.6 prsente les interfaces web pour la consultation et le payement : 1. Le locataire consulte ses dettes en donnant le code locale et le mot de passe correspondant ; 56
2. Si le code fournit est correcte, le portail lui ache ses dettes avec la possibilit deectuer un payement ; 3. Un accus de rception avec ltat de payement serra ach sur le troisime interface.
5.3.3
Test des routes Apache Camel
Pour tester la route cre par Apache Camel nous avons utilis le console JMX. "Java Management Extensions (JMX) est une API pour Java permettant de grer le fonctionnement dune application Java en cours dexcution. Il a t intgr dans J2SE partir de la version 5.0. " Il permet donc de visualiser le contenu de la machine virtuelle et dexplorer ainsi le contenu de conteneur ServiceMix et les queues ActiveMQ.
Figure 5.7 Test avec soapUI
57
La Figure 5.7 dcrit le contenu de la Queue JMS explor par le console.
5.4
Chronogramme
Dans ce paragraphe, nous nous intressons prsenter le chronogramme du droulement du projet. Le projet tait divis en trois grandes parties selon le chronogramme de la Figure 5.8. Nous avons : commenc par une tude comparative sur les principaux ESBs open sources ; ensuite eectu un tude de lexistant a n de dnir les besoins en change dinformations ; modlis les processus pour concevoir larchitecture de la solution ; pour nir avec une implmentation de la solution propose.
58
59
Figure 5.8 Chronogramme de droulement du projet
5.5
Les ds relevs
Durant la ralisation de ce projet nous avons pu faire face quelques ds techniques que nous avons relev, notamment avec loutil Maven 3.0. En eet la gestion de dpendance, la compilation et le dploiement de bundle OSGI dans le conteneur ServiceMix, sont quelques unes des tches les plus dlicates. La manque dune documentation mis jour pour lutilisation de ServiceMix tait aussi un rel handicape. Il a fallut quon sintresse la version commerciale de ServiceMix (Fuse ESB) qui ore quelques supports en version libre. En outre, le changement de ltude de cas durant le droulement du projet a aect le bon fonctionnement du projet mais, la bonne volont des responsables de la municipalit a permit de surmonter ce problme en proposant une tude similaire la premire.
Conclusion
Ce chapitre a illustr les travaux raliss suivant les principales fonctionnalits de notre solution. Nous avons commenc prsenter dabord la gestion de conguration(Logicielle et Materiel). Ensuite prsent les dirents tapes de la ralisation en montrant les services raliss en les orchestrant sous forme des processus mtiers. Le chronogramme du travail et les dicults rencontres ont marqu la n de ce chapitre.
60
Conclusion Gnrale
Lobjectif de ce projet tait de proposer une solution dintgration au SI municipal pour concrtiser le programme de modernisation de ladministration lectronique en Tunisie. La mise en place dune architecture SOA en utilisant un middleware (ESB) tait la rponse adquate cette problmatique. Pour cela nous avons dabord eectu une tude comparative entre les principaux ESB open source pour choisir ServiceMix comme outil de mdiation Aprs avoir eectu une tude sur le terrain, nous tions amen suivre une dmarche pour mettre en place une telle architecture. Puisque le SI municipale est constitu des applications existantes, nous avons choisi lapproche Outside In (Meet In The Middle) qui permet de piloter la SOA par les besoins mtiers tout en facilitant la rutilisation des services et la capitalisation sur lexistant. Ralis dans une unit de recherche(RDI), ce projet nous a permis dexplorer de nouveaux concepts dans le domaine de la recherche qui sont : ladministration lectronique et larchitecture SOA. En outre ce projet, qui nest pas du tout classique nous a permis dutiliser des technologies nouvelles que nous navons pas abordes durant notre formation. Nous avons dvelopper des solutions dinter oprabilits en utilisant un ESB open source (ServiceMix) avec toutes les technologies qui lui sont lies. La modlisation des processus mtiers avec BPMN 1 tait pour nous dune grande utilit de mme que pour la conception de larchitecture de la solution avec le langage SoaML 2 .
1. Business Process Modeling Notation est une notation graphique standardise pour modliser des procdures dentreprise dans un workow. 2. SoaML, est une extension du langage de modlisation UML pour les architectures SOA
61
CONCLUSION GNRALE
Bien que la solution ralise prsente une rponse claire au cahier des charges, ce travail reste un prototype volutif, nous pourrions envisager dtendre la solution toutes les autres applications. En eet le SI de la municipale est constitu dune dizaine dapplications qui sont souvent amenes interagir entre elles pour un change dinformations. Ainsi pourrons aboutir un SI municipale totalement intgr qui fournira des services valeur ajoute aux citoyens et aux agents. Enn, nous tirons un bilan positif de la ralisation de ce projet comportant la fois un aspect thorique sur le concept de la e-Gov et pratique sur larchitecture SOA. Bien que nous ayons eu faire face quelques dicults, notre capacit les rsoudre et les mthodologies que nous avons adoptes sont les motifs de notre satisfaction. Mais le travail ralis nest pas une n en soi car comme le dit le commun des mortels : un travail se base sur les travaux dj raliss et xe ses racines pour les travaux venir.
62
Bibliographie
[1] N. Hron : "Anatomie de trois ESB Open Source JBoss ESB, ServiceMix et Open ESB", IT-Express, mars/avril 2010 [2] A. Louis : "Bus de Service -ESB- Nouvelle technologie pour lintgration", Petals Link, Novembre 2008 [3] Xebia : "Comprendre et savoir utiliser un ESB dans une SOA" ,Xebia, Novembre 2007 [4] Optimation IT : "Open Source Enterprise Service Bus (ESB) Evaluation" , Optimation, 2009 [5] T. RADEMAKERS, J. DIRKSEN : "Open-Source ESBs in Action : Example Implementations in Mule and ServiceMix", Manning Publications Company, 2008 [6] Valtech : "Urbanisation & Intgration de Systmes Urbanisation THINK SERVICE, Valtech", Septembre 2007 [7] http ://goo.gl/NC7Up, visit le 27/06/2011 [8] http ://www.interfacing.ca/normes/bpmn/ visit le 01/06/2011 [9] P. Roques, F. Valle : "UML 2 en action, De lanalyse des besoins la conception 4e dition", EYROLLES, 2000 [10] http ://www.omg.org/spec/SoaML/1.0/Beta2/PDF/ visit le 20/05/2011
Abrviations
ESB : Entreprise Service Bus EIP : Entreprise Integration Pattern EAI : Entreprise Application Integration JCA : Java Connector Architecture JDK : Java Development Kit JBI : Java Business Integration JSR : Java Specication Request BPEL : Business Process Execution Language BPMN : Business Process Management Notation WSDL : Web Services Description Language SCM : Software Conguration Management SOA : Service Oriented Architecture SaoML : Service Oriented Architecture Modeling Language BPMN : Business Process Modeling Language UDDI : Universal Description Discovery and Integration XML : Extensible Markup Language OSGI : Open Services Gateway initiative ODE : Orchestration Director Engine SCM : Software Conguration Management GRB : Gestion des Recettes Budgtaires MB : Application de gestion des Marchs et Biens ii
ABRVIATIONS
2TUP : Two Track Unied Process SI : Systme dInformation
iii
ANNEXE
SOA
Le systme dinformation de lentreprise est gnralement constitu dapplications et de donnes constituant son hritage (en anglais legacy). Avec les fusions de groupe, lvolution des technologies, cet hritage a tendance devenir htrogne et se spcialiser par mtier (entit, service, etc.), ce qui provoque un fonctionnement en silo, cest--dire un cloisonnement des dirents mtiers empchant certaines formes de transversalit et masquant au dcideur une vision globale du systme dinformation de son entreprise. Lintgration des applications de lentreprise(EAI) est une solution ce problme. Elle consiste dvelopper des connecteurs spciques permettant de faire communiquer entre eux les dirents silos de lentreprise.
Architecture oriente service

Une architecture oriente services (note SOA pour Services Oriented Architecture) est une architecture logicielle sappuyant sur un ensemble de services simples. Lobjectif dune architecture oriente services est donc de dcomposer une fonctionnalit en un ensemble de fonctions basiques, appeles services, fournies par des composants et de dcrire nement le schma dinteraction entre ces services. Lide sous-jacente est de cesser de construire la vie de lentreprise autour dapplications pour faire en sorte de construire une architecture logicielle globale dcomposes en services correspondant aux processus mtiers de lentreprise. Lorsque larchitecture SOA sappuie sur des web services, on parle alors de WSOA, pour Web Services Oriented Architecture). Principes gnraux dune architecture oriente service Il nexiste pas proprement parler de spcications ocielles dune architecture SOA, nanmoins les principales notions fdratrices que lon retrouve dans une telle architecture sont les suivantes : La notion de service, cest--dire une fonction encapsule dans un composant que iv
ANNEXE A. SOA
lon peut interroger laide dune requte compose dun ou plusieurs paramtres et fournissant une ou plusieurs rponses. Idalement chaque service doit tre indpendant des autres an de garantir sa rutilisabilit et son interoprabilit. La description du service, consistant dcrire les paramtres dentre du service et le format et le type des donnes retournes. Le principal format de description de services est WSDL(Web Services Description Language), normalis par le W3C. La publication(en anglais advertising) et la dcouverte (discovery) des services. La publication consiste publier dans un registre (en anglais registry ou repository) les services disponibles aux utilisateurs, tandis que la notion de dcouverte recouvre la possibilit de rechercher un service parmi ceux qui ont t publis. Le principal standard utilis est UDDI (Universal Description Discovery and Integration), normalis par lOASIS. Linvocation, reprsentant la connexion et linteraction du client avec le service. Le principal protocole utilis pour linvocation de services est SOAP(Simple Object Access Protocol).
Avantages dune architecture oriente service

Une architecture oriente services permet dobtenir tous les avantages dune architecture client-serveur et notamment : Une modularit permettant de remplacer facilement un composant(service) par un autre Une rutilisabilit possible des composants(par opposition une systme touten-un fait sur mesure pour une organisation). De meilleures possibilits dvolution(il sut de faire voluer un service ou dajouter un nouveau service) Une plus grande tolrance aux pannes Une maintenance facilite source : http ://bit.ly/oQELQQ
ANNEXE
JBI(JSR 168)
Introduction
Java Business Integration est une norme dicte sous la JSR 208 dans le cadre du Java Community Process. JBI est bas sur une approche SOA. Le problme initial est lintgration de donnes en provenance de sources direntes au sein dun systme dinformation compos dapplications disparates. JBI dnit une architecture qui permet la mise en place de solutions dintgration bases sur lutilisation de composants qui communiquent via des messages. Les Enterprise Service Bus sont une implmentation de cette norme. JBI est une spcication normalisant ces intgrations via un jeu dAPI permettant tout fournisseur les respectant de pouvoir se connecter un conteneur JBI pour changer des messages avec le reste du S.I.. Ci-dessous larchitecture high level dun environnement JBI telle quelle est dcrite dans la JSR-208.
Figure B.1 Archicture JBI
vi
ANNEXE B. JBI(JSR 168)
Vu dun aspect de trs haut niveau, larchitecture JBI est base sur deux concepts : les composants enchables et la mdiation de messages normaliss.
B.1
Les composants enchables (pluggable components)
La plupart des scnarios aujourdhui tournent autour de la transformation de protocoles et/ou de donnes ainsi que de leurs routages. Cependant les types de protocoles et les formats de donnes traduire varient grandement. Le modle JBI, et donc son architecture, a besoin de supporter une liste innie de protocole et de service dintgration. La solution de JBI est de proposer les composants enchables. Ils sont de deux types : les services engines (composants utilitaires de transformation, de routages, denrichissemenents, dorchestration, ...) et les binding components (composants qui relient lenvironnement JBI et des composants externes).
B.2
Le mdiateur de JBI (JBI mediator)
Les binding components et les services engines ninteragissent pas directement entre eux. Comme pour toutes les architectures stables, il y a un mdiateur qui grera les intractions entre les dirents composants. Le mdiateur est le routeur de messages normaliss (normalized message router : NMR). Ce dernier accepte les messages XML normaliss des binding components (dposs dans le normalized delivery channel) et invoque les services engines sur base de leurs WSDL(Web service description language). Voici un exemple prsent dans la JSR-208 : Lillustration ci-dessus montre un scnario denvoi dun datagramme (simple oneway message request). Ici le NMR reoit un message dun service engine qui la dpos sur son delivery channel. Il la redirige ensuite vers le delivery channel dun binding component. vii
ANNEXE B. JBI(JSR 168)
Figure B.2 One Way Message
Conclusion
Les bases de lenvironnement JBI, le framework de composants, le normalized message router, le WS-I binding, les outils de dploiement et les fonctions de gestion du bus correspondent fortement aux bases dun ESB. Il est tout fait normal de ce fait que les ESB commerciaux dans quelques semaines voire mme dans quelques mois deviennent JBI compliant. source : http ://bit.ly/qvfLO4
viii
ANNEXE
OSGI(JSR 8)
Prsentation de lOSGI
OSGI est une organisation indpendante. Fonde en 1999, on lui attribua la JSR 8 pour la dnition dun systme composants dynamiques pour la plateforme Java : OSGI pour Open Services Gateway Initiative. Son but principal est de proposer un modle pour la modularit de composants ainsi quun modle de collaboration intercomposant. Et les avantages que lon peut en tirer aujourdhui ne manque pas :
Une meilleure cohabitation :

OSGI propose de partager la machine virtuelle Java aux applications dans un une architecture modulaire, en isolant en toute scurit les applications les unes des elles. En introduisant le bundle comme lunit de dploiement, OSGI y impose la dclaration explicite des dpendances.
Une collaboration base de service

OSGI prconise ds 2000 un modle collaboratif dynamique base de service. Cette architecture permet un couplage faible entre bundles et un suivi de service lexcution grce aux notications dvnements dapparition ou de disparition de service. Cest un modle SOA intra JVM. ix
ANNEXE C. OSGI(JSR 8)
Quelques exemples dutilisation

Eclipse est un trs bel exemple du potentiel quore la spcication OSGI. En eet, Eclipse 2 proposait un modle de composant propritaire et il a t dcid en 2003 de basculer sur le modle OSGI pour Eclipse 3.0. Aujourdhui, Eclipse compte des milliers de bundles disponibles pour tendre ces fonctionnalits. Et il est trs simple de construire une application modulaire grce Eclipse PDE. On peut trouver dautres exemples dans lindustrie automobile avec BMW et son dploiement de dapplication avec la plateforme Prosyst (OSGI R4), dans lindustrie internet avec CISCO et ses routeurs administrable distance grce OSGI, mais aussi avec le projet Mjordom dEDF pour orir au consommateur un ensemble de services accessibles par divers sources (Mobile, ordinateur, compteur...). Lindustrie logicielle nest pas en reste : BEA ore un serveur lger Event-Driven le WebLogic Event Server, IBM basculer sa plateforme Notes sous OSGI (en se basant sur Eclipse), le serveur GlassFish 3 de Sun, le serveur Jonas 5.0 galement Dautres projets sont ltude et permettent OSGI dtendre son rayonnement. On peut citer Spring et son serveur dapplication Springsource Application Platform. Les implmentations OSGI. On dnombre aujourdhui quatre acteurs majeurs pour les plateformes OSGI R4 open-source : Eclipse Equinox Apache Felix MAKEWAVE Knopersh Prosyst mBedded Server Editions (Bas sur Eclipse Equinox)
Conclusion
OSGI apporte de lorganisation lexcution la plateforme Java. Cest un transfert de responsabilit du dveloppeur au Framework OSGI. Le dveloppeur est ainsi librer de certaines tches non essentielles et peut se consacrer pleinement au cur de son mtier : rpondre aux exigences de son client. Il nest plus dans une intention constante dcriture de ligne de code, mais de composition et de rutilisation. Cette architecture de haut niveau a pour avantage dapporter de la discipline et de la lisibilit dans les dveloppements des applications dentreprise. source : http ://bit.ly/pZ7uSU x

Pfe

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Pfe

Hochgeladen von

Copyright:

Verfügbare Formate

Je ddie ce rapport A mes chers parents, Ali Hassane Sa et Fatim Abatcha en tmoignage de toute ma gratitude et reconnaissance innies ; A mes

Mes remerciements les plus sincres, accompagns dune grande reconnaissance,

Ces remerciements sadressent galement Mr Mohamed Ben SASSI chef de

Reconnaissance profonde mes parents, connaissances et amis, quils reoivent

Keywords : SOA, ESB, ServiceMix, OSGI, BPMN, SoaML.

Mot cls : SOA, ESB, ServiceMix, OSGI, BPMN, SoaML.

Table des matires

Mthodologie de dveloppement . . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choix de la mthodologie de dveloppement . . . . . . . . . . .

TABLE DES MATIRES

Choix de lapproche . . . . . . . . . . . . . . . . . . . . . . . . . Les ESBs dans une SOA . . . . . . . . . . . . . . . . . . . . . .

Couche mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 Langage de Modlisation BPMN . . . . . . . . . . . . . . . . .

Les processus mtiers . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

48 48 48 49 51 51 52 54 54 55 55 56 57 58 60 61 i iii iv vi vii vii ix

Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les ds relevs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Liste des gures

LISTE DES FIGURES

B.1 Archicture JBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.2 One Way Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Liste des tableaux

1.1 2.1 3.1 3.2 3.3 3.4 3.5 5.1 5.2

Comparaison entre les mthodologies de dveloppement . . . . . . . . . Principale fonctionnalits dun ESB[3] . . . . . . . . . . . . . . . . . .

Prsentation de lorganisme daccueil

CHAPITRE 1. PRSENTATION GNRALE

CHAPITRE 1. PRSENTATION GNRALE

Figure 1.1 Interface de lapplication Marchs et Biens

CHAPITRE 1. PRSENTATION GNRALE

Figure 1.2 Interface de lapplication GRB-Recette

Flux inter applicatif

Figure 1.3 Flux interapplicatif

CHAPITRE 1. PRSENTATION GNRALE

CHAPITRE 1. PRSENTATION GNRALE

de mdiation qui assurer lintgration et lensemble ses problmatiques.

Figure 1.4 Approche dintgration

CHAPITRE 1. PRSENTATION GNRALE

nings,les prototypes Scrum

Se base des itrations dites sprints de dveloppement

Donner conance veloppeurs laisser travail ; aux et faire

toute dles leur

membres de lquipe de dveloppement.

Tableau 1.1 Comparaison entre les mthodologies de dveloppement

CHAPITRE 1. PRSENTATION GNRALE

Choix de la mthodologie de dveloppement

Figure 1.5 Mthodologie 2TUP

CHAPITRE 1. PRSENTATION GNRALE

Etat de lart des approches dintgration

Figure 2.1 Evolution des technologies dintgration [7]

CHAPITRE 2. ETAT DE LART DES APPROCHES DINTGRATION

Figure 2.2 Rle dun ESB dans une SOA [6]

Les concepts lis une SOA

CHAPITRE 2. ETAT DE LART DES APPROCHES DINTGRATION

Figure 2.3 Processus mtier [6]

Figure 2.4 Service mtier [6]

Les approches dintgrations

CHAPITRE 2. ETAT DE LART DES APPROCHES DINTGRATION

Lintgration point point

Les problmes lis lintgration point point

Figure 2.5 Approche point point

CHAPITRE 2. ETAT DE LART DES APPROCHES DINTGRATION

(Entreprise Intgration Pattern) est apparue.

Les EAIs (Entreprise Application Integration)

Les problmes lis lapproche EAI

Figure 2.6 Approche EAI