LivreOrange SOA

---
Urbanisation & Intgration de Systmes THINK SERVICE

Valtech septembre 2007 Version 1.2
1/87
Valtech V1.2 - septembre 2007
Table des matires

1 PREAMBULE ___________________________________________________________ 4 2 THINK SERVICE ________________________________________________________ 5
2.1 Dfinition des concepts sous-tendant une SOA.....................................................................5
Processus mtier ........................................................................................................................... 5 Service ........................................................................................................................................... 6 SOA (Service-Oriented Architecture)............................................................................................. 7 EDA (Event-Driven Architecture) ................................................................................................. 10 ESB (Enterprise Service Bus)...................................................................................................... 11 Contrat de service ........................................................................................................................ 12 Notre approche ............................................................................................................................ 13 Problmatique .............................................................................................................................. 15 Architecture Mtier ....................................................................................................................... 15 Architecture fonctionnelle............................................................................................................. 17 Architecture Applicative et technique........................................................................................... 22 Une approche agile...................................................................................................................... 25 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7
2.2
Think Service en action .......................................................................................................15
2.2.1 2.2.2 2.2.3 2.2.4 2.2.5
3 VERS UN MODELE SAAS _________________________________________________ 26

3.1 3.2 3.3 3.4 3.5 3.6 Les applications composites................................................................................................27 Les services mtier (Web services).....................................................................................28 La gestion des processus....................................................................................................29
Modlisation des processus......................................................................................................... 29 Excution des processus ............................................................................................................. 29
3.3.1 3.3.2
La couche graphique...........................................................................................................30 Exemple dapplication composite ........................................................................................31 SaaS integration platform : Composants cls ................................................................33
SOA Metadata Repository ........................................................................................................... 34 Execution layer ............................................................................................................................ 34 Portal............................................................................................................................................ 35 QoS / Security / Management / Monitoring.................................................................................. 35
3.6.1 3.6.2 3.6.3 3.6.4
3.7 4.1
Perspectives offertes par le modle SaaS...........................................................................35 Les composants ..................................................................................................................37

Interaction avec les acteurs ......................................................................................................... 37 Processus Mtier ......................................................................................................................... 38 Services Mtier ............................................................................................................................ 39 Ressources applicatives .............................................................................................................. 39 Les colonnes transverses : LESB et lIDE .................................................................................. 39 Gestion des Interactions utilisateurs ............................................................................................ 40 Gestion des processus ................................................................................................................ 41 Apache Tomcat / Axis2 : un duo de conception de Web Services .............................................. 43 Les ESB ....................................................................................................................................... 44 Eclipse STP : Un IDE pour SOA .................................................................................................. 45
4 SOA ET OPEN-SOURCE : ETAT DES LIEUX ____________________________________ 37

4.1.1 4.1.2 4.1.3 4.1.4 4.1.5
4.2
Prsentation des solutions slectionnes............................................................................39
4.2.1 4.2.2 4.2.3 4.2.4 4.2.5
4.3 5.1 5.2
Conclusion ..........................................................................................................................46 Description du contexte.......................................................................................................47 Principes darchitecture applicative SOA .............................................................................47

Principe de couplage faible.......................................................................................................... 49 2/87
5 UN RETOUR D'EXPERIENCE EN URBANISATION & SOA____________________________ 47

5.2.1
5.2.2 5.2.3
Couche daccs aux donnes (SDO) .......................................................................................... 50 Habilitations.................................................................................................................................. 51
5.3 5.4
Dmarche de ltude durbanisme .......................................................................................51 Dclinaison de la mthode sur un sous-ensemble du systme............................................51

Architecture mtier ....................................................................................................................... 51 Architecture fonctionnelle............................................................................................................. 53 Architecture applicative................................................................................................................ 53 Insertion dans le SI ...................................................................................................................... 54
5.4.1 5.4.2 5.4.3 5.4.4
5.5 6.1 6.2 6.3 6.4
Bilan de cette tude.............................................................................................................55 Prambule...........................................................................................................................57 Identification des interlocuteurs concerns et du primtre adresser................................58 Ncessit dun organisme dtude et de dcision................................................................59 La gouvernance SOA en pratique .......................................................................................61
Modle de maturit ...................................................................................................................... 61 Architecture fonctionnelle............................................................................................................. 63 Architecture applicative................................................................................................................ 63 Architecture technique ................................................................................................................. 64 Trajectoire .................................................................................................................................... 65 Pilotage ........................................................................................................................................ 66
6 RFLEXION SUR LA GOUVERNANCE SOA _____________________________________ 57
6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6
6.5 7.1 7.2 7.3
Conclusion ..........................................................................................................................66 Problmatique et solution cible............................................................................................68 Description de la dmarche LSC .........................................................................................69

Livrables....................................................................................................................................... 69 Dmarche de travail..................................................................................................................... 74 Pourquoi ?.................................................................................................................................... 77 Donnes mises disposition ....................................................................................................... 77 Format des donnes .................................................................................................................... 78 Techniques de mise disposition................................................................................................ 78 Alimentation ................................................................................................................................. 78 Diffrentiel .................................................................................................................................... 79
7 RETOUR D'EXPERIENCE EN URBANISATION & INTEGRATION ________________________ 68

7.2.1 7.2.2 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6
Serveur de rfrentiel..........................................................................................................77
7.4 8.1 8.2 9.1 9.2 9.3
Bilan de cette tude.............................................................................................................80 Synthse des concepts SOA dans Think Service................................................................81 Complments EDA SOA dans Think Service ...................................................................82 Les bases de BPMN............................................................................................................83 Le contrle du flot................................................................................................................84 Les Exemples......................................................................................................................86
8 ANNEXE : METMODELE POUR LAPPROCHE THINK SERVICE ________________________ 81
9 ANNEXE : APERU DE BPMN _____________________________________________ 83
3/87
1 Prambule
Ce document reprsente une compilation du savoir-faire et de lexpertise de Valtech dans le domaine de lurbanisation et de lintgration de systmes. Il sintresse aussi bien aux nouvelles perspectives offertes par la vision SOA quaux retours dexpriences de Valtech dans ce domaine et plus gnralement dans lurbanisation et lintgration de systmes. La rdaction de ce document a dmarr en 2006 et une premire version a t dite en janvier 2007. Son contenu nest pas fig ; il ne se veut donc pas exhaustif et est amen vivre pour tre complt au fur et mesure des volutions de notre approche et des technologies. Des mises jour rgulires sont donc effectues. Ce document est une uvre collective ; les consultants ayant donn de leur temps pour llaboration de ce Livre Orange, par lcriture ou par lapport de rflexion sur le sujet, sont : Olivier Delie, Olivier Flebus, Nicolas Fonrose, Willy Goldgewicht, Simon Iermann, Gabriel Langouet, Laurent Macquet, Alain Parmentier, Sbastien Ranvier, Eric Suignard, Christophe Surdieux. Ce document ne se veut ni acadmique, ni un tat de lart sur lurbanisation ou lintgration de systmes. Son unique objectif est de vous faire partager notre exprience des technologies et des projets, en restant concis, synthtique et en privilgiant lagilit. Il na pas non plus pour objectif de se lire dune traite de la premire la dernire page ; il est constitu de chapitres relativement distincts pouvant tre lus indpendamment les uns des autres, tout en restant cohrent avec notre approche Think Service qui prne avant tout lagilit sur les volutions apporter au systme dinformation pour lmergence dune SOA.
Yann Le Tanou Responsable de loffre Urbanisation & Intgration de Systmes Contact : yann.letanou@valtech.fr
4/87
2 Think Service
Le systme dinformation dune entreprise est habituellement reprsent selon quatre niveaux darchitecture : Larchitecture mtier : processus mtier de lentreprise Larchitecture fonctionnelle : blocs fonctionnels et flux dinformation supports la ralisation des processus mtier, indpendamment des technologies mises en uvre Larchitecture applicative : blocs applicatifs et changes, supports la ralisation des blocs fonctionnels et des flux, dpendant des technologies mises en uvre dans le SI. Larchitecture technique : infrastructure sur laquelle sont implments et excuts les blocs applicatifs et leurs changes, dpendant des contraintes de performance et de scurit et de la qualit de services demande. Dans une vision SOA du SI, ce dcoupage reste tout fait dactualit, la diffrence que la brique de base de construction du SI devient le service. Lapproche Think Service vous montre comment les diffrents niveaux de reprsentation du SI vont vous permettre de tendre vers une vision SOA du SI. Think Service ne se veut en aucun cas une dmarche thorique et abstraite. Elle sinscrit dans le tournant de lAgilit prn par Valtech et dfinit uniquement des bonnes pratiques indiquant a minima les diffrents lments produire pour faire une SOA. Nous utilisons donc un vocabulaire simple et classique, connu des acteurs de lurbanisation et de lintgration. Dans la suite du document, nous ne vous ferons pas une prsentation acadmique de Think Service, mais exploiterons un exemple concret bas sur le SI dune entreprise de travail temporaire pour montrer les principes sous-tendant notre approche.
2.1
Dfinition des concepts sous-tendant une SOA
Avant daborder lapproche mise en avant par Valtech, il nous parat tout dabord ncessaire de donner les dfinitions des concepts de base, puisquil nexiste pas aujourdhui de dfinitions standards autour de SOA. Nous allons vous donner ici celles qui nous paraissent les plus pertinentes et qui sont issues des rflexions et de la pratique des consultants Valtech, lobjectif tant de donner des dfinitions concrtes en une phrase. 2.1.1 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. Comme illustr sur la Figure 1, 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. Exemple : un processus de facturation va manipuler des objets Mtier Contrat et Facture et sera dclench sur validation dun objet mtier Commande.
5/87
Figure 1
Illustration dun processus mtier
2.1.2
Service 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.
On parle habituellement de services au sens mtier, parce que ce sont les traitements mtier que lentreprise dsire en tout premier lieu mutualiser. Mais dautres types de traitements sont mutualisables au sein de lentreprise comme notamment les services dauthentification. Mais dans tous les cas, ces services doivent tre normaliss au sein de lentreprise. La normalisation est en effet fondamentale. Sans normalisation, la mutualisation des services est impossible. La normalisation impose la dfinition de donnes communes, utilises comme paramtres dappel des services. Cest le rle de la dfinition dun modle dobjets pivots.
Figure 2
Illustration dun service
Le terme service applicatif est galement souvent employ, gnralement de manire confuse sans savoir exactement ce que recouvre ce terme. Un service applicatif correspond soit : un service mis en place spcifiquement pour une application du SI, sans mutualisation possible de celui-ci, un service propos spcifiquement par un progiciel. Dans les deux cas de figure, le service nest pas normalis et ne fait pas usage des objets pivots partags. Le premier cas na dintrt que pour faciliter la conception dune application, car le service ne sera pas mutualis. Il contribue alors la ralisation de la logique applicative dune application.
6/87
Pour le second cas, nous pouvons facilement monter un service normalis au-dessus du service applicatif. Nous pouvons galement avoir une approche encore plus pragmatique et considrer que le service applicatif est un service normalis part entire, et donc utilisable tel quel. Ses donnes dentre/sortie deviennent alors partie intgrante du modle des objets pivots. Linterface dappel dun service est constitue de 1 N oprations qui constituent les traitements lmentaires et atomiques proposs par le service. Pour dcrire linterface dappel dans un langage neutre, le standard de fait est WSDL1. Attention, le fait de dfinir linterface dun service en WSDL ne signifie pas quil faut implmenter tous les services par des WebServices et quil faut utiliser SOAP2 pour les communications. Le rfrencement est ralis travers la mise en place dun annuaire de service dentreprise UDDI (Universal Description, Discovery and Integration) qui indique notamment o sont dploys les services. 2.1.3 SOA (Service-Oriented Architecture) 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.
1 2
WebService Description Language (recommandation du W3C) Simple Object Access Protocol (recommandation du W3C)
7/87
Figure 3
Les principes dune SOA (Architecture applicative)
Une SOA place donc au cur de larchitecture dun systme dinformation les services (qui sont ses briques de base de construction) puis les processus mtier qui vont les orchestrer. Les applications mises la disposition des acteurs sont alors construites par composition de processus et de services. Processus et Service sont de vritables composants logiciels, qui vont permettre de faire le liant entre la vision mtier des Matrises dOuvrage et la vision technique des Matrises duvre. Cest la diffrence fondamentale par rapport de lEAI classique : un EAI nest quun moyen mis en uvre pour interconnecter des applications htrognes, et pour lequel les processus mtier sont noys. Une SOA est un vritable prcepte darchitecture, dans laquelle des ressources applicatives htrognes se retrouvent faades par les services, et pour laquelle les processus sont explicites et donc facilement matrisables et instrumentables . Les diffrents composants dune SOA peuvent tre mis en relation par le mtamodle synthtique Figure 4.
Figure 4
Mtamodle synthtique des composants d'une SOA
Une SOA est organise selon les niveaux suivants : Interactions avec les acteurs : ensemble des composants logiciels permettant aux acteurs dinteragir avec le systme dinformation et de raliser les logiques applicatives. Les acteurs considrs ici sont soit des humains, pour lesquels on mettra typiquement en place des solutions de type portail permettant de traiter la diffusion multi-canal de linformation, ou des systmes externes dans le cadre dchanges B2B. Un composant dinteraction communique avec les processus et les services. Processus Mtier : ensemble des composants logiciels permettant de raliser les processus mtier de lentreprise par une orchestration de tches automatiques ou humaines, correspondant rciproquement de lappel doprations de services et de lattente de donnes de la part dacteurs. Nous pourrons mettrons en place ici des solutions de type BPEL3.
Business Process Execution Language : recommandation W3C pour la description XML des orchestrations de webservices.
8/87
Le processus peut tre vu comme un service permettant laccs aux instances en cours dexcution. Un service Processus offrira gnralement une interface daccs standardis pour tous les processus, offrant les diffrentes oprations permettant dexcuter une nouvelle instance de processus, daccder la liste des instances en cours dexcution et leur statut associ ou encore de mettre en pause ou de stopper une instance. Services Mtier : ensemble des composants permettant de raliser les services mutualiss de lentreprise, et permettant de mettre en place des faades homognes au-dessus des ressources applicatives. Typiquement les services seront dcrits ici par WSDL. Chaque service expose des oprations dont les paramtres sont dfinis par des classes dobjets pivots. Ces oprations sont appelles soit via les processus (dans le cadre dune orchestration), soit directement par les interactions. Ressources applicatives : ensemble des ressources applicatives du SI exploites par les services. Nous retrouverons donc ici les progiciels de lentreprise, les bases de donnes, les mainframes, les applications propritaires existantes. Les services accdent aux ressources via lutilisation de connecteurs. Par exemple, dans le cas dun daccs java une base de donnes, nous pourrons mettre en place une connexion JDBC. Lensemble de ces composants logiciels permet au final de construire des applications dites composites. Ce concept dapplications composites est plus particulirement dvelopp au chapitre 3 consacr au modle SaaS. Dans une SOA nous allons retrouver deux grandes familles de services mtier mutualiss : Les services Donnes4 : fournissent les oprations de manipulation dune classe dobjet mtier et garantit lapplication des rgles de gestion associes. Les services Composs : offrent des oprations ncessitant la manipulation de divers objets mtier travers lusage des services Donnes associs. En plus des services mtier, nous pouvons galement trouver des services dits technique , qui permettent de faader et de mutualiser des fonctionnalits non-mtier. Dans cette famille de services, nous trouverons notamment : Les services dauthentification Les services de messagerie Les services dimpression Quant aux services applicatifs, il ny a pas de rgles propres leur conception, celle-ci tant dpendante de la technologie employe pour limplmentation de la logique applicative. Ainsi, un service applicatif peut lui-mme tre compos dappels des services mutualiss, quils soient Composs ou Donnes. Chaque service doit rpondre aux caractristiques suivantes pour tre ligible dans une SOA : Couplage faible : un service doit tre indpendant des autres services de sa famille. Un service Donnes ne peut appeler dautres services Donnes. Un service Compos peut appeler des services Donnes mais pas dautres services Composs. Langage commun : les donnes changes par les services doivent tre dfinies dans un dictionnaire de donnes commun, dfinissant lensemble des objets Pivot en entre/sortie des services. Composition : tout service doit tre composable par les processus. Rutilisation : chaque traitement mtier doit tre offert par un seul service. Ce besoin de rutilisation doit tre trait au niveau dune gouvernance SOA au sein de lentreprise. Rfrenc : chaque service est rfrenc dans un annuaire de services.
4
Egalement appels services CRUD pour Create, Retrieve, Update and Delete.
9/87
Stateless : lexcution dun service est non-interruptible et ne dpend pas de son excution prcdente. 2.1.4 EDA (Event-Driven Architecture) EDA est un style darchitecture logicielle pour lequel les diffrents composants logiciels communiquent de manire totalement asynchrone grce la publication et la souscription dvnements. Un vnement correspond un changement significatif dtat du systme. Dans un SI, ce sont typiquement les changements dtats des objets mtier qui vont tout particulirement nous intresser. La gestion des vnements est donc aussi un concept important considrer dans une SOA. Nous constatons que SOA est souvent confront EDA, alors que les principes de celle-ci viennent complmenter idalement une SOA. Une EDA pourra typiquement tre utilise pour propager les donnes dans lensemble du systme dinformation lorsque cela savre ncessaire. Le producteur de la donne la publie dans linfrastructure. Les consommateurs, abonns sur cet vnement, sont notifis (et en gnral consomment la donne en la persistant localement). De facto, les donnes sont alors dupliques dans les diffrents composants des systmes abonns.
Figure 5
Principe dusage mixte SOA+EDA
Dans une SOA+EDA, nous traiterons les vnements deux niveaux, comme montr Figure 5 : Service : chaque composant ralisant un service Donnes peut potentiellement produire les vnements correspondant aux changements dtat des objets mtier grs. La production dvnements est une fonctionnalit offerte par le composant et non par le service en tant que tel. Un composant de service ne consomme pas dvnement car toute excution dun traitement doit tre faite en passant explicitement par lappel dun service. La gestion des vnements est assure par un composant de mdiation, dont le rle est de router les vnements produits vers les consommateurs. (Ce composant de mdiation peut tre implment via un ESB, cf. 2.1.5) Processus : Dans une mise en place classique dune SOA+EDA, un composant Processus appelle des services et consomme des instances dvnements produits par les composants
10/87
Service. Dans une mise en place Full-EDA , les composants Processus produiraient galement des vnements en lieu et place des appels de services. Le composant de mdiation assurerait alors en plus le mapping entre les vnements produits par les processus et les services appeler. Toutefois une mise en place full-EDA nest gnralement pas conseille, car difficile mettre en uvre du point de vue fonctionnel et technique. On limitera donc gnralement lusage dune EDA de la production dvnements par les composants de services et leur consommation par les processus. Nous pouvons complter le mtamodle des composants dune SOA (Figure 4) avec ceux dune EDA (Figure 6) pour obtenir un mtamodle SOA+EDA.
Figure 6
Complment EDA au mtamodle SOA
2.1.5
ESB (Enterprise Service Bus)
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 diffrents composants logiciels dune SOA au sein de lentreprise, indpendamment des types de protocoles et de messages utiliss. Attention, il est important de savoir que la mise en place dun ESB ne signifie pas la mise en place automatique dune SOA. LESB est uniquement un moyen dchange et non une fin en soi. De la mme manire, les premires tapes de mise en place dune SOA peuvent tout fait se passer dESB. LESB vient donc sintgrer dans nos principes darchitecture (Figure 7), comme le moyen de support des diffrents composants de la SOA et permettant de les mettre en relation. Cest une infrastructure ayant pour finalit de couvrir lensemble des moyens dchanges standardiss entre les diffrents applicatifs du SI, incluant le support des services. LESB sappuie sur des standards du march tels que JCA5, JMS6, SOAP et les Web Services.
5 6
Java Connector Architecture Java Messaging Service
11/87
Figure 7
Intgration de lESB dans les principes dune SOA
Un ESB doit donc apporter au minimum les fonctionnalits suivantes : Connecteur Transformation de donnes Annuaire de services Scurit Publication/Souscription dvnements Transport/Routage Monitoring 2.1.6 Contrat de service
Chaque service est dfini selon un contrat, tablissant les rgles dusage du service. Au minimum le contrat est constitu des informations suivantes : En-tte : Nom du service Dfinition Type (donnes ou compos) Objet(s) mtier manipul(s) Version Propritaire, en charge de lvolution/maintenance du service RACI (li la gouvernance SOA) : Responsible : personnes en charge des modifications apporter aux services, sous la responsabilit de la personne Accountable.
12/87
Accountable : le responsable en charge de la gestion du contrat et des modifications sur le service. Consulted : personnes consulter avant dapporter une modification au contrat, et impactant sur la dcision finale de modification. Informed : personnes informer de la modification du contrat. Oprations du service Nom Paramtre(s) et objet(s) pivot(s) Traitement et rgle de gestion raliss Proprits Mode(s) dappel supports Contraintes de scurit Qualit de service, dfinissant le niveau de tolrance aux pannes permis SLA7 (Service Level Agreement) : dfinit le niveau de service attendu par un client pour le service. Un SLA par client peut tre dfini. Chaque SLA dfinit au moins le temps moyen dexcution attendu, ainsi que le nombre maximum dappels pour une priode de temps donne. Transactionnel : dfinit si le service peut tre utilis dans une transaction longue et si oui quel mode de compensation doit tre utilis. Comme vu dans la dfinition dune SOA, les vnements sont une proprit offerte par les composants ralisant les services et non par ces derniers en tant que tel. En consquence, le contrat de service ne dfinit pas dvnements. 2.1.7 Notre approche
Les principes mis en avant par Think Service peuvent facilement se rsumer comme suit. Aprs avoir modlis les processus mtiers cls entrant dans la mise en place de la SOA (Architecture Mtier), ceux-ci sont dtaills en sous-processus permettant de faire merger aisment les interactions avec les acteurs et les diffrents services ncessaires la ralisation du processus (Architecture Fonctionnelle). Les blocs fonctionnels sont alors ajouts pour organiser de manire cohrente objets mtier, service et interaction associs. Ceci forme la vision urbanisation du SI. Les processus dtaills vont alors servir de spcification pour lvolution ou le remplacement des applications existantes (Architecture Applicative). Les services sont exposs par des composants logiciels de services dont le primtre correspond aux blocs fonctionnels dfinis en amont. Ces composants offrent une faade de services aux ressources applicatives existantes de manire rutiliser au maximum les applications existantes du SI. Pour les applications qui sont remplaces, les composants de services masquent la mise en place des nouveaux rfrentiels et supportent lensemble des rgles mtier associes. Ceci forme la vision intgration du SI. Enfin, les diffrents composants logiciels de notre SOA sont dploys sur une infrastructure technique, pour lesquelles sont mises en place des solutions base de serveurs dapplication et de clusters (Architecture Technique). Lapproche Think Service mixe de faon raliste et pragmatique les deux visions urbanisation et intgration, comme montr Figure 8. Lannexe du chapitre 8 prsente le mtamodle des concepts associ notre approche.
Le contrle des SLA est une des fonctionnalits pouvant tre offerte par un ESB
13/87
Figure 8
Les quatre niveaux darchitecture du SI pour une SOA
Think Service met en avant les services comme concept central permettant de faire la rconciliation entre ces deux visions en mariant la rutilisation des ressources applicatives existantes avec lmergence dune SOA naturellement tourne vers les services et les processus. Ces derniers sont implments par un moteur dorchestration des services et des tches attendues des acteurs via des composants dinteraction. Cette partie interactive est fondamentale pour faire merger une interface unifie du SI au-dessus des processus et des services. Au final la mise en place dune SOA permet de tendre vers une architecture applicative aligne sur larchitecture fonctionnelle et les processus mtier de lentreprise, ceci grce aux composants de service qui se positionnent en faade des applications existantes. La rutilisation de celle-ci est en effet fondamentale ; il faut au maximum r-exploiter lexistant quand cest possible, la vision SOA permettant dapporter une unification des applications travers une vision unique des processus et des portails daccs ceux-ci pour les diffrents intervenants. A travers la mise en place de notre approche, nous avons galement dfini un modle de maturit sur les pratiques durbanisation et dintgration de systmes. Ce modle est l encore bas sur le pragmatisme est pour unique objectif daider les entreprises se positionner dans leurs pratiques actuelles, pour identifier aisment les manques leur permettant de tendre vers une vision SOA de leur systme dinformation. Un aperu de ce modle de maturit est prsent au chapitre 6.
14/87
2.2
Think Service en action
Nous allons montrer comment lapproche Think Service permet de concrtement faire merger au plus tt les services devant tre supports par le SI. Lapproche est droule sur une tude de cas concrte, portant sur le SI dune entreprise de travail temporaire. Think Service utilise les notations standards de lOMG UML et BPMN8 pour la modlisation, de manire pouvoir exploiter sans problme la majorit des outils de modlisation. 2.2.1 Problmatique
Le mtier de notre entreprise de travail temporaire est orient autour de trois axes : La gestion de la relation avec ses clients La gestion de la relation avec ses intrimaires La gestion de la paie des intrimaires La direction gnrale a fait un certain nombre de constats sur le SI existant. Notamment, le systme actuel ne permet pas une gestion optimale de la mise en relation des intrimaires avec les demandes des employeurs. En effet, il nexiste pas de dfinition commune des mtiers entre lapplication ayant en charge la passation de commandes et lapplication ayant en charge la gestion des intrimaires. Ce manque de rfrentiel entrane quil est difficile pour les agences de slectionner les bons intrimaires disponibles, potentiellement aptes raliser les missions, sans une relle aide du systme. Ce manque de cohrence entrane une perte de parts de march face des concurrents plus ractifs. En consquence, il devient urgent de raligner le SI pour le moderniser et offrir un maximum daide la dcision aux agences. De plus, les agences se plaignent du gros manque dergonomie actuelle des outils, tout en tant satisfait du fonctionnel implment. La direction gnrale a donc demand la DSI de lancer un projet de remise niveau de son SI, mais avec un budget restreint impliquant que la DSI ne fasse pas de choix trop ambitieux vis--vis des enjeux. Notamment elle doit rutiliser au maximum lexistant, fortement bas sur des progiciels. Le systme informatique actuel est bas sur un ensemble htrogne de technologies : Un progiciel ddi pour la gestion de la paie Un progiciel ddi la gestion de clients (ici les employeurs) Du dveloppement spcifique client/serveur avec un L4G est une base de donnes pour la gestion des intrimaires. Pour limiter les cots dvolution et de maintenance, la DSI a la volont pour les nouveaux dveloppements de sorienter vers des technologies J2EE et de tendre vers une vision SOA, lenjeu tant ici de commencer monter des faades au-dessus des progiciels, pour rorienter correctement le SI vers le pilotage par les processus et un portail daccs unique pour les agences. Dans la suite, nous allons dvelopper les deux visions top-down et bottom-up pour faire merger une architecture cible rpondant aux attentes des deux parties, travers lusage de bonnes pratiques prsentes pour chaque niveau darchitecture du SI. 2.2.2 Architecture Mtier
Nous commenons par larchitecture mtier pour nous intresser ici au processus mtier cl permettant de servir une demande dun employeur.
Business Process Modeling Notation : notation standard de lOMG (www.bpmn.org) pour la modlisation des processus mtier, dont un rsum est donne lannexe 9.
15/87
Bonne pratique : Se concentrer sur la modlisation des processus mtier cls En effet, il nest pas question ici de modliser lensemble des processus mtier de lentreprise. Nous nous intressons aux processus qui ont un rel impact sur lamlioration de notre SI, et qui sont ligibles pour devenir de vritables composants Processus au cur de notre SOA. Pour raliser cette modlisation, nous utiliserons la notation standard BPMN, comme montr sur notre exemple Figure 9.
Figure 9
Processus mtier BPMN
Dans ce processus nous distinguons deux couloirs principaux dexcution : lemployeur qui fait la demande et lentreprise de travail temporaire qui la reoit. Nous subdivisons celle-ci en deux profils de responsabilit : le gestionnaire des employeurs et le gestionnaire des intrimaires. Bonne pratique : Rester au stade du macro-processus mtier Les processus mtier sont un outil dchange entre les MOA et MOE. Il nest donc pas ncessaire de descendre dans des niveaux de dtail trop important. Lobjectif est de partager une vision macro du processus avec ces activits majeurs et les concepts mtier manipuls au sein dun cheminement nominal, plus les quelques alternatives importantes distinguer. Chaque activit reprsente par dfaut une tche quun humain doit raliser, en dehors de toute considration informatique. Le processus dtaill sera lui dcrit au niveau de sa mise en uvre dans larchitecture fonctionnelle SOA, pour faire merger en dtail les services et les tches humaines. Chaque activit doit apporter une plus-value dans le processus, et procder au changement dtat dun objet mtier majeur. Notre exemple fait ainsi apparatre trois objets mtier manipuls : la demande de lemployeur, la proposition dintrimaire et enfin le contrat validant une proposition accepte.
16/87
Bonne pratique : Faire merger les objets mtier majeurs issus des processus cls Au fur et mesure de la modlisation des processus cl slectionns, nous faisons rapidement merger le modle des objets mtier, reprsentant les concepts manipuls par lentreprise indpendamment de linformatisation. Ce modle est trs stable et peu sujet au changement, moins dune volution majeure dans les pratiques du mtier. Pour notre exemple, (et partir dautres processus non tudis ici), nous bauchons le modle synthtique montr Figure 10.
Figure 10
Exemple de modle synthtique des objets mtier
Ce modle va nous permettre dans ltude de larchitecture fonctionnelle de faire rapidement merger notre dcoupage en bloc fonctionnel, comme nous allons le voir dans la section suivante. Parmi les objets mtier, nous pourrons distinguer les objets principaux des objets secondaires. Les principaux sont les concepts majeurs du mtier, tandis que les secondaires sont des concepts plus souvant li lorganisation. Par exemple dans notre modle, lobjet mtier Comptence est principal, tandis quun objet Branche Comptence servant organiser les comptence sera plutt considr comme secondaire. 2.2.3 Architecture fonctionnelle
Pour notre exemple, nous nous intresserons uniquement aux blocs fonctionnels curs de mtier, que nous regrouperons dans un bloc nomm Oprations. Chacun de ces blocs est construit autour dune classe mtier principale et permet de spcifier les lments associs suivants : Les interactions et cas dutilisation associs Les services Les donnes mtier Les vnements EDA associs aux changements dtats des objets mtier Un bloc contient quant lui la spcification et ladaptation dtaille des processus mtier notre SI. Il spcifie galement les fonctions de gestion associes, les indicateurs de performance9 et les diffrents profils utilisateur. Ce bloc peut tre subdivis en diffrents mtiers si ncessaire.
Ce sont les KPI (Key Performance Indicator)
17/87
Dans notre architecture fonctionnelle, nous faisons galement apparatre un bloc Pilotage, un bloc Support et un bloc Echange, permettant de spcifier les modes dchanges inter-blocs attendus en interne et en externe lentreprise, ainsi que lensemble des donnes pivot exploits pour ces changes. Ces objets pivots seront notamment utiliss en paramtre des services. Bonne pratique : Dcouper le SI en blocs cohrents autour des objets mtier Chaque objet mtier majeur identifi dans les processus mtier est sous la responsabilit dun seul et unique bloc fonctionnel, comme montr Figure 11. A partir de son objet mtier, chaque bloc aura ainsi en charge les services et interactions associs, identifis partir de ltude des processus mtier dtaills. Pour chaque interaction, nous pourrons dvelopper des cas dutilisation spcifiant les enchanements dcrans ou de formulaires ncessaires la ralisation de chaque interaction humaine avec un processus.
Figure 11
Dcoupage du SI en blocs fonctionnels pour prparer la SOA
Les objets mtier dits oprationnels sont placs dans des blocs doprations. Leurs instances sont traites et transformes par les processus oprationnels. Dans notre exemple, nous rangerons dans cette famille les objets Activit, Demande (+Proposition), Paye, Acompte et Contrat. Les objets mtier dits de rfrence sont placs dans des blocs rfrentiels. Leurs instances sont stables et ne sont pas directement modifies par les processus mtier oprationnels. Ces derniers sappuient sur ces objets de rfrence pour travailler. Dans notre exemple nous rangerons dans cette famille les objets Comptence, Employeur et Intrimaire. Dautres blocs peuvent galement tre distingus en fonction du primtre de ltude. Cest le cas du bloc Support pour les services non-spcifiques au mtier (la facturation et lditique par exemple), et du bloc Pilotage pour la construction de tableaux de bord. Pour la vision fonctionnelle dune SOA, deux autres blocs vont plus particulirement nous intresser : le bloc Processus et le bloc Echanges, tout deux dfinis ci-aprs. Bonne pratique : Identifier un bloc Processus Ce bloc fonctionnel va regrouper lensemble des spcifications dtailles des processus mtier. Ce dtail permet de distinguer les tches humaines des tches automatiques et va donc nous permettre didentifier puis dorganiser les services mtier ainsi que lensemble des interactions
18/87
ncessaires avec les acteurs. Ce bloc va galement regrouper les exigences relatives la mise en place dun moteur dorchestration et la gestion de workflow avec les utilisateurs. La modlisation des processus mtier dtaills sera utilise pour effectuer la gnration automatique du BPEL et du BPEL4People interprts par le moteur dorchestration au niveau de larchitecture applicative du SI. Bonne pratique : Identifier un bloc Echanges Ce bloc fonctionnel va mutualiser lensemble des spcifications des objets pivots, des vnements (si usage de lEDA) ainsi que toutes les exigences en termes de transport/routage, de monitoring ou de scurit. Ces spcifications permettront dorienter le choix dun ESB, mais aussi les choix en terme dintgration dapplications existantes par de lEAI classique ou encore dETL10 pour lextraction de donnes vers un bloc Pilotage ayant en charge la gestion dun entrept de donnes pour les fonctions dcisionnelles de lentreprise. Ce blocs dchange assure aussi bien les changes internes au SI que les changes externes, notamment par la mise en place de services B2B construits gnralement au-dessus des services des blocs Oprations et Rfrentiels. Ces services B2B sont en consquence des services composs. La modlisation des objets pivots sera utilise pour gnrer directement les dfinitions XML Schema, en accompagnement des dfinitions WSDL pour les services. Bonne pratique : Dtailler les processus en distinguant les tches humaines des tches automatiques Chaque processus dcrit dans larchitecture mtier va tre dtaill dans larchitecture fonctionnelle de manire identifier et distinguer les tches automatiques et les tches humaines. Les premires vont tre reprsentes sous forme doprations de services tandis que les secondes seront reprsentes sous forme dopration de dialogue. Chaque activit dun processus mtier va tre raffine en un sous-processus, dcrit directement laide de BPMN ou sous la forme dun diagramme dactivits UML. A ce niveau de dtail, nous identifions les entres/sorties de nos diffrentes tches sous la forme dobjets pivots, qui vont tre ensuite exploits dans la dfinition des paramtres des oprations de services.
Extract, Transform, Load : plateforme d'intgration logicielle permettant d'effectuer des synchronisations massives d'information d'une base de donnes vers une autre, en temps diffr. Les ETL sont largement utiliss pour alimenter les entrepts de donnes pour le dcisionnel (datawarehouse), partir des bases de donnes oprationnelles.
10
19/87
Figure 12
Processus mtier dtaill dans larchitecture fonctionnel
Chaque tche automatique identifie dans le processus dtaill est directement dcline en une opration de service11. Les entres/sorties de la tche deviennent alors les paramtres de lopration de service, sous la forme dobjets pivot. Une fois les oprations dun service dfinies, nous exploiterons directement une gnration WSDL pour dcrire le WebService correspondant. La majeure parties des outils de modlisation UML supporte aujourdhui directement cette gnration automatique UML WSDL (et inversement) en exploitant un profil UML ddi12. Chaque tche humaine identifie dans le processus dtaill est galement dfini de manire identique une opration de service (avec ses entres et ses sorties sous forme dobjets pivots), la diffrence prs que ces oprations seront regroupes dans des classes boundary . Lintrt est double : Cela permet de facilement rutiliser une tche humaine plusieurs endroits dun processus ou dans des processus spars. Cela permet de pouvoir facilement remplacer la tche humaine par un service, dans le cas o celle-ci pourrait tre plus tard soit automatise par un service, soit dlgu un partenaire externe galement sous la forme dun service. Chaque tche humaine peut ensuite tre spcifie par un cas dutilisation, de manire dfinir les diffrents crans ou formulaires mettre en place pour raliser la tche, la navigation associe ainsi que les appels de services qui seront directement exploits ce niveau. Par dfaut, nous rangerons chaque cas dutilisation dans le bloc fonctionnel de lobjet mtier dont il assure majoritairement la gestion. Dans notre exemple, le cas dutilisation Constituer une proposition qui travaille sur les objets Demande et Proposition sera donc rang dans le bloc Gestion des demandes.
Pour associer une tche dun diagramme dactivit UML une opration, nous utiliserons les actions call operation Cest par exemple le cas de loutil RSA dIBM ou encore de loutil Enterprise Architect dit par la socit Sparx System.
12
11
20/87
Bonne pratique : Standardiser les services de donnes Chaque service Donne est responsable des rgles de gestion propre un ou plusieurs objets mtier (souvent un principal et les secondaires associs) dont il a la responsabilit. Il expose notamment les diffrentes oprations permettant la manipulation13 des donnes quil gre mais galement tous autres types doprations permettant par exemple de raliser des traitements14 sur les donnes. Il est fortement conseill de standardiser le contrat des services de donnes travers un pattern garantissant leur homognit travers lensemble du systme dinformation. A titre indicatif, la figure ci-dessous montre un exemple de que peut tre un tel pattern de service Donne.
Figure 13
Exemple de pattern de service Donne
Lorsquun objet mtier porte des rfrences vers dautres objets mtier du systme, le service Donne ne peut garantir leur intgrit. Celle-ci peut alors tre porte par un service Composite ayant en charge la gestion de cette intgrit. Ces services composites sintercalent alors entre les services de donnes et les processus. Bonne pratique : Faire des cartographies synthtiques Pour illustrer la vision fonctionnelle de notre SOA, nous synthtiserons lensemble des lments dune tude de processus dans une cartographie fonctionnelle synthtique, comme montre Figure
13 14
On parle habituellement dopration CRUD pour Create, Retrieve, Update et Delete. Par exemple, un service Prt Bancaire pourra exposer une opration permettant deffectuer la simulation dun prt.
21/87
14. Cette cartographie est idalement ralise pour chaque processus mtier support par notre SOA. Elle fait apparatre les diffrentes relations dappel entre le processus mtier, les interactions regroupant les oprations humaines (et les cas dutilisation associs), les services et leurs oprations. Nous faisons ici dlibrment abstraction du bloc Echanges, celui-ci napportant pas de plus-value la comprhension de notre schma ; il faut juste garder en tte que les communications passent par celui-ci.
Figure 14
Zoom sur le contenu et les relations des blocs fonctionnels dans une vision SOA
2.2.4
Architecture Applicative et technique
Au niveau de larchitecture applicative, nous allons laborer deux cartographies : Tout dabord, la cartographie de lexistant applicatif, qui va nous permettre de dterminer les ressources applicatives que nous allons pouvoir exploiter pour monter nos services et nos processus. Puis la cartographie applicative cible, qui va identifier et positionner les diffrents composants logiciels nous permettant de mettre en place notre SOA. A partir de cette cartographie, nous pourrons laborer une trajectoire dvolution de notre SI sur une dure dfinie, nous permettant didentifier les diffrents jalons de mise en uvre SOA et les projets impliqus dans celle-ci. Bonne pratique : Projeter lexistant applicatif sur larchitecture fonctionnelle Lanalyse de larchitecture applicative existante est ralise en deux grandes tapes : Tout dabord la cartographie de celle-ci en identifiant les diffrentes ressources applicatives du SI, leurs responsabilits fonctionnelles et les donnes manipules, leurs interconnexions sous forme dchanges (message, synchronisation de donnes, transfert de fichiers priodique, etc.) ; Puis la projection de ces ressources applicative sur larchitecture fonctionnelle, comme montr sur lexemple Figure 15, en fonction des responsabilits identifies prcdemment compares
22/87
celles des blocs fonctionnels ; cette projection permet de dterminer les verrous prsents sur lexistant et rendant lvolution du SI difficile.
Figure 15
Mapping de lapplicatif existant sur larchitecture fonctionnelle
Une analyse rapide de lexistant de notre exemple permet ainsi de faire les constats suivants : Un progiciel regroupe lensemble des oprations de gestion des employeurs, tandis quun autre assure les oprations de paie. Ces deux progiciels donnent globalement satisfaction aux utilisateurs en termes de fonctionnalits. Par contre les interfaces graphiques sont peu ergonomiques et ne donnent pas satisfaction aux utilisateurs, surtout pour la gestion des employeurs. Notons que ces progiciels sont ouverts car disposant de connecteurs sous formes dAPI. La gestion des intrimaires est ralise par une application vieillissante btie sur une base de donnes et un L4G, arrivant en fin de vie. Lditeur a en effet dcid de labandonner. Il nexiste pas proprement parler de vritable rfrentiel des comptences des intrimaires. En effet cette notion est prsente dans deux ressources distinctes (le progiciel Employeur et lapplication de gestion des intrimaires), sans garantie de cohrence de gestion entre les deux car il nexiste pas de synchronisation. Bonne pratique : Identifier les ressources applicatives entrant dans la ralisation des services et les connecteurs exploitables Dans notre exemple, il est choisi en cible applicative dapporter les volutions suivantes : Conserver les progiciels en montant des faades de services et en exploitant leurs connecteurs applicatifs Refaire la gestion des intrimaires sur une technologie J2EE et un rfrentiel centralis associ. Au niveau de larchitecture technique, lensemble sera dploy sur un cluster de serveurs pour supporter la charge ncessaire lensemble des agences (plusieurs centaines rparties au niveau national) Synchroniser le rfrentiel intrimaire (matre) avec les donnes quivalentes des progiciels (esclaves) Monter une interface graphique unifie sous la forme de portails. Il est ainsi prvu de crer progressivement trois portails : Un portail Agence pour laccs lensemble des services de gestion des employeurs, des intrimaires et de la paie. Un portail Intrimaire pour permettent ceux-ci daccder leur dossier et de faire des demandes leurs agences.
23/87
Un portail Employeur pour permettent ceux-ci de faire directement leurs demandes en ligne. Les grands principes de notre cible applicative sont montrs sur la Figure 16. Il reste ensuite laborer la trajectoire dvolution de notre SI en dfinissant les diffrents paliers de mise en uvre.
Figure 16
Architecture Applicative cible SOA
Bonne pratique : Dfinir un composant de service par bloc fonctionnel Par dfaut, nous crons un composant de service pour chaque bloc de larchitecture fonctionnelle. Ces composants seront typiquement raliss sous la forme de WebServices. Ils ont en charge la gestion des changes avec les ressources applicatives exploites, via leurs connecteurs. Les composants de service assurent galement les fonctions de mapping entre les formats de donnes applicatives et les objets pivots sous forme de messages XML. Cette rgle signifie donc que les blocs fonctionnels assurant la gestion des processus et les changes possdent galement leurs propres composants de services. Effectivement chaque composant processus peut galement tre expos sous la forme dun WebService offrant les services standards permettant daccder aux diffrentes instances et tches en cours. Pour le bloc change, les services exposs permettront de fournir ainsi des oprations de publication/consommation dvnement ou encore de gestion dauthentification travers lusage dun annuaire LDAP. Bonne pratique : Considrer les composants processus comme des services Comme nous lavons dj abord 2.1.3, les processus peuvent galement tre exposs sous forme de services pour faciliter leur usage et accder leur tat dexcution. Ils peuvent ainsi tre potentiellement partags par plusieurs applications, bien que leur excution diffre des services mtier. En effet, ces derniers sont atomiques et synchrones, tandis que les processus sont interruptibles et asynchrones. Linterface des services Processus est gnralement impos par le moteur dorchestration utilis.
24/87
Bonne pratique : Unifier les interfaces homme-machine La mise en place dune SOA est loccasion de se concentrer sur la mise en place dinterfaces homme-machine unifies (sous la forme de portail mais aussi de clients riches), dont lobjectif est de remplacer les interfaces diverses et varis des applications existantes. Ceci permet de limiter ces dernires de la fourniture unique de traitements et de donnes via les services. Cette unification est galement loccasion daborder les enjeux de la distribution multi-canal dinformations et de services. Cette distribution multi-canal peut tre : Oriente mtier : dans notre exemple nous mettons en place diffrents portails en fonction de la famille dacteurs considre. Oriente support : la diffusion dinformations et de services sur un PC connect au WEB nest pas la mme que sur un tlphone mobile. Bonne pratique : Ajouter les composants de mdiation pour la synchronisation des donnes La mise en place dune architecture SOA ne signifie pas que tous les autres modes dchanges disparaissent. Il est en effet souvent ncessaire de faire coexister des changes inter-applicatifs plus classiques, pour des raisons de trajectoire de mise en uvre mais aussi de performances. Ces changes inter-applicatifs sont identifis en faisant apparatre des composants de mdiation, ayant en charge limplmentation dchanges de donnes entre applications. Ces composants seront pris en charge par des fonctions dEAI/ESB ou par des dveloppements spcifiques. Ainsi, dans notre exemple, nous utilisons deux composants de mdiation pour implmenter les synchronisations les donnes stockes dans le rfrentiel Intrimaire et les donnes dupliques dans les progiciels Employeur et Paye. Une solution type MDM15 pourrait galement tre mise en place dans ce cas de figure. Nous verrons plus loin dans la section 6.2 la prsentation de la dmarche Valtech LSC qui permet de facilement spcifier des changes inter-applicatifs. Cette dmarche complmente idalement Think Service pour les problmatiques classiques dintgration inter-applicative. 2.2.5 Une approche agile
Lapproche Think Service de Valtech permet de marier de manire concrte et pragmatique les concepts classiques durbanisation avec les concepts avancs ports par SOA et EDA. Elle montre quune approche mariant urbanisation top-down et intgration bottom-up permet dobtenir des rsultats rapides et ralistes pour faire merger une vision SOA dans le SI et rationaliser ainsi celuici par la mise en place des services. Pour faire merger facilement ceux-ci, il est fondamental de penser service ds le premier niveau de dcomposition du SI quest larchitecture fonctionnelle, et non relguer cette identification un problme purement applicatif. Lidentification de services au niveau fonctionnel nimpose pas de devoir tous les concrtiser au niveau applicatif. Larchitecture fonctionnelle reste un idal et des arbitrages sont raliser pour dterminer les priorits en fonction de la stratgie dentreprise. Ceci passe par la dfinition et le pilotage dune trajectoire partage par lensemble des projets informatiques.
Master Data Management : Principe de gestion consistant regrouper dans un rfrentiel matre les donnes cls de lentreprise puis les synchroniser dans des bases esclaves rparties au sein de diverses applications du SI.
15
25/87
3 Vers un Modle SaaS

Le terme SaaS pour Software As A Service nest pas nouveau. Cependant sa dfinition a grandement volue avec larrive des architectures orientes services, des solutions de gestion des processus mtier et la gnralisation progressive des Web Services. Initialement, SaaS tait le terme gnrique utilis pour dsigner les applications loues sur Internet par les ASP (Application Service Provider). Il sagit essentiellement dapplications spcialises dans le domaine de la gestion dentreprise comme la gestion de la relation client ou les ressources humaines. Dans ce contexte, SaaS est un moyen technique et commercial de distribution dapplications, qui cible principalement les PME/PMI et qui a pour avantage : De permettre une entreprise dutiliser une solution informatique sans se soucier des problmatiques techniques, De proposer un modle conomique souple pour adapter la facturation la typologie de lentreprise et lutilisation relle de loutil (facturation la demande), Dobtenir un dploiement et un retour sur investissement rapide. Par contre, ce modle atteint ces limites par : Le faible niveau dadaptation de loutil aux spcificits mtier de lentreprise, Les faibles possibilits dintgration avec le reste du SI. Aujourdhui apparaissent les solutions SaaS dites de deuxime gnration (SaaS 2.0) fondes sur lassociation SOA/BPM et Web Services qui permettent de dvelopper et dexploiter des applications composites mtier c'est--dire des applications construites sur mesure partir dun ensemble de services et des processus mtier mettre en uvre. On peut galement retrouver ces applications sous lacronyme SOBA (Service Oriented Business Application). Le schma Figure 17 prsente les trois couches principales16 constitutives dune application composite SOBA : Les services mtier (1) La gestion des processus (2) La prsentation graphique (3)
Prsentation
Gestion des processus
Web services
Web services
Web services
Web services
Web services
Figure 17
Couches constitutives dune application composite adoptant le style SOBA
16
Nous remarquerons que le style SOBA est naturellement celui mis en avant par notre approche Think Service.
26/87
De nouvelles offres commerciales mergent galement. En effet, les SaaS Providers proposent, en mode hberg, lensemble des composants ncessaires lexploitation dapplications composites, savoir : une plateforme dintgration oriente service SOA , un catalogue de services mtier, des outils de modlisation des processus pour lassemblage final des services et une couche de dploiement du type portail web. On parle galement de SaaS Integration Platform pour dsigner lensemble de ces composants. Une SaaS Integration Platform peut potentiellement grer un nombre illimit de services et autant dapplications composites. A ce titre, elles peuvent tre compares des systmes dexploitation ebusiness dont lobjectif est de permettre des entreprises et leurs partenaires de crer de vritables SI virtuels bass sur un ensemble dapplications composites, le tout partiellement ou totalement externalis et facturable lusage : on demand . Parmi les fournisseurs prsents sur le crneau SaaS 2.0, nous avons dun ct les diteurs de solutions dintgration SaaS : Les pure players avec le leader de lASP Salesforce.com et son offre Appexchange suivi de startups comme Employease.com ou Reardencommerce.com pour ne citer quelles. Les diteurs traditionnels comme SAP, Oracle, BEA ou IBM par exemple qui proposent des solutions packages qui couvrent lensemble du primtre dune SaaS Integration Platform et qui fournissent galement des services dhbergement. Et de lautre les fournisseurs de services mtier grosses mailles comme : Les diteurs de logiciels qui proposent de plus en plus leurs outils sous forme dun ensemble de web services pr-intgrs qui pourront tre consomms (et facturs) la demande au travers dune plateforme dintgration SaaS 2.0 et Les ISV (Independent Software Vendor) qui sont spcialiss dans ldition de services mtier spcialiss comme la socit XwebServices qui dveloppe des services dans le domaine de la sant, de limmobilier ou du e-commerce. Le modle SaaS 2.0 illustre bien le potentiel de lassociation SOA, BPM et autres Web Services et mme si le modle SaaS fait avant tout rfrence aux solutions hberges, il nen reste pas moins dclinable sous la forme de solutions internalises et ainsi tre adapt aux diffrentes stratgies des entreprises.
3.1
Les applications composites
Une application composite est une application constitue de fonctionnalits et de donnes provenant dune ou plusieurs sources, assembles en fonction de processus mtier et qui dispose dune interface graphique unifie. Un des objectifs poursuivi par les solutions SaaS 2.0 est de simplifier la cration dapplications composites en adoptant le principe de la conception dirige par les modles (Model-Driven) qui consiste spcifier une application grce un ensemble de modles spcialiss (Meta-model) convertibles en code informatique exploitable par la couche dexcution. Cette simplification est rendue possible notamment grce la capacit des SOA exposer et intgrer des services mtier et aux outils de BPM qui permettent de dfinir les processus mtier partir de modles. Lassemblage des lments constitutifs dune application composite est une opration complexe qui met en uvre de nombreux mcanismes aussi bien au niveau de lintgration que de lautomatisation de certaines tches. Le schma Figure 18 montre les principaux composants qui entrent en jeu.
27/87
Figure 18
Composants constitutifs dune application composite
Dans les paragraphes suivants nous allons voir de faon plus dtaille quelles sont les standards et les outils utiliss pour lassemblage des services, des processus et des composants de linterface utilisateur qui constitueront une application composite mtier.
3.2
Les services mtier (Web services)
Dans le contexte SaaS 2.0, les fonctionnalits et sources de donnes sont fournies aux travers de web services grande maille c'est--dire des web services de granularits suffisamment importantes pour avoir une signification mtier. Ces services peuvent remplir de nombreuses tches comme par exemples : fournir un accs des donnes (le prix dun article en fonction de sa rfrence), fournir un processus ou une fonctionnalit (calculer une taxe en fonction dun montant donn), lancer un processus (procdure de rapprovisionnement des stocks). Pour exploiter ces services, nous utiliserons les lments standards fournis par une SOA : un annuaire qui permet de recenser les services disponibles : UDDI17 une description des donnes et des mthodes ncessaires lutilisation du service : WSDL18, une mthode dappel dun service : SOAP19, un format dchange des messages : XML.
17 18
Universal Description Discovery and Integration (normalisation OASIS) Web Services Description Language (recommandation du W3C) 19 Simple Object Access Protocol (recommandation du W3C)
28/87
Les services vont donc dfinir les fonctionnalits de lapplication. Il reste dcrire la logique mtier, c'est--dire la faon dont ils seront invoqus.
3.3
La gestion des processus
Linvocation des services est dfinie par les processus qui vont dcrire les interactions entres les services et les participants humains de ces processus. Ils constituent donc un point central dans la construction dune application composite. Les descriptions et lexcution des processus sont facilites par lutilisation de technologies et de normes comme BPMN (Business Process Modeling Notation) et BPEL (Business Process Execution Language) que nous prsentons succinctement dans les paragraphes suivants. 3.3.1 Modlisation des processus
BPMN est un standard de modlisation des processus mtier. Il regroupe un ensemble de diagrammes simples et normaliss qui peuvent tre assembls pour former un modle graphique qui reprsentera un processus. Les lments de base sont de quatre types20 : les couloirs (Swimlanes) qui dfinissent les participants et les activits qui leurs sont attribus, les objets de flux (Flow Objects) qui reprsentent les activits, vnements et les portes (gateway), les objets de relation (Connecting Objects) qui reprsentent les squences, les messages et les associations, et les objets symboliques (Artifacts). La combinaison de ces lments permet de dcrire graphiquement les interactions entre les participants (humains ou systme) et le comportement attendu de lapplication. En plus de la modlisation graphique des processus, une des finalits de BPMN est de permettre la traduction automatique des diagrammes en un langage interprtable par un moteur dexcution des processus mtier, le langage BPEL. 3.3.2 Excution des processus
Aprs avoir t modlis avec BPMN, le processus est converti au standard BPEL qui dfinit un langage XML normalis permettant : De spcifier les processus mtier automatiss, bass sur lorchestration dactivits de multiples web services et qui peut tre interprt et excut par un moteur dorchestration compatible, De suivre le droulement des processus ainsi orchestrs. BPEL a t conu pour dcrire de faon standard un processus mtier automatis, cest--dire les interactions entre les services mtier. Cependant, de nombreux processus ncessitent galement des interactions humaines. Cest pour dcrire ces interactions que lextension BPEL4People a t dveloppe par IBM et SAP. BPEL4People est une surcouche de BPEL qui permet de dcrire les activits humaines dans un processus, cest--dire les tches qui ncessitent des actions particulires de la part dutilisateurs ou de groupes dutilisateurs. Il sagit donc de lier des actions du type Valider, Transfrer, Excuter des individus (des rles, des profils,).
20
Voir galement lannexe 9
29/87
Prenons lexemple dune application de type self service qui permette aux salaris dune entreprise de poser des jours de congs partir du portail de la socit. Les actions humaines excuter sont les suivantes : Saisir les dates souhaites Envoyer le formulaire au manager Valider ou non la demande (manager) Dans notre exemple les oprations seront dcrites et assignes des groupes dutilisateurs en fonction de lorganisation de lentreprise. Par exemple, si le collaborateur est du service marketing, envoyer la demande au responsable du service marketing. Si ce dernier nest pas disponible (en congs) alors transmettre la demande au directeur gnral. Cela implique une interconnexion avec le rfrentiel des utilisateurs de lentreprise. BPEL4People permet aussi de dfinir des enchainements dactions conditionnels quun utilisateur doit raliser. Si nous reprenons notre exemple : Le collaborateur saisi un nombre de jours de congs suprieur au solde de jours quil peut prendre dans lanne, alors le systme propose un formulaire complmentaire de demande davance de jours de congs sur lanne suivante En rsum, BPEL va permettre de dcrire les interactions et les messages changs avec les services mtier et BPEL4People va permettre de dcrire les interactions (question, rponse, question/rponse) et les messages changs entre les acteurs humains dun processus et les services mtier. En plus de lorchestration, il peut galement tre ncessaire de grer lchange de messages entre des processus indpendants, voire des processus B to B . Cest le rle de la chorgraphie des processus et du standard WS-CDL (Choregraphy Description Langage) qui sera utilis en complment de BPEL. Le schma Figure 19 rsume ces deux principes de chorgraphies et dorchestrations.
Orchestration
Web services
Web services
Web services
Chorgraphie
Web services
Web services Web services Web services
Figure 19
Chorgraphie Vs. Orchestration
3.4
La couche graphique
Dans la construction dune application composite, lInterface Homme/Machine est un lment critique qui permet aux utilisateurs dinteragir avec les services suivant le processus mtier dcrit avec BPMN.
30/87
La philosophie self service du concept SaaS 2.0 pousse lautomatisation de la construction de lIHM qui doit galement tre faiblement couple avec les autres couches de lapplication afin de disposer de son propre cycle de vie. Pour assurer cette automatisation, il est possible de faire appel une couche dabstraction ddie pour construire linterface partir de la description des interactions utilisateurs/systme et des messages changs. Une partie de ces descriptions sont fournies par BPEL et son extension BPEL4People. Pour assurer la correspondance BPEL / Interface, il existe plusieurs approches. Une des plus intressantes consiste dcomposer le processus en un ensemble dentres-sorties dont les caractristiques dpendent de la nature des messages changs et des mthodes utilises. Ainsi dcomposes, ces entres / sorties sont associes des composants graphiques prdfinis (liste droulante / champ de saisie / tableau / bouton / calendrier) dans un rfrentiel (UI components repository) qui seront orchestrs pour former des blocs fonctionnels homognes. La couche BPEL fournit une partie des informations ncessaires la construction de lIHM et le reste des lments est dcrit par lutilisateur laide dun outil graphique de paramtrage fourni avec la plupart des solutions SaaS 2.0. Linterface dune application est constitue dun ou plusieurs blocs agrgs via une couche de chorgraphie qui pourra tre assure dynamiquement par un client riche grce des technologies RIA (Rich Internet Application) comme AJAX par exemple. La fonction dagrgation des blocs est gnralement assure par la couche portail qui permet galement dunifier linterface et dassurer des fonctions dauthentification entre les diffrents blocs (SSO). Quelques normes comme WSRP 2.0 (Web Services for Remote Portlets) ou WSIA (Web Services Interactive Applications) tentent de standardiser les interfaces qui seront construites pour quelles puissent tre intgres de faon transparente dans nimporte quel portail compatible avec une de ces deux normes voire quelles puissent tre encapsules dans dautres applications. Le schma Figure 20 prsente les diffrentes couches de construction dune interface :
Figure 20
Intgration de la couche graphique
3.5
Exemple dapplication composite
Prenons lexemple dune entreprise de travaux publics : Chaque chantier sur lequel elle intervient est assimil un forfait sur lequel est assign un certain nombre de jours de travaux.
31/87
Pour optimiser la gestion de ses diffrents projets, cette entreprise dcide de mettre en place une application de suivi de lavancement des projets et de la disponibilit des ressources. Les principales fonctions de lapplication seront dune part denregistrer lactivit des ressources en fonction des projets et des absences, et dautre part de fournir un tableau de bord de suivi. Le processus suivant a t dfini : Les chefs de projets dclarent leurs projets et les plannings associs. Ensuite, ils vont slectionner les membres de leurs quipes. Chaque membre dquipe devra ensuite remplir un formulaire de suivi hebdomadaire. Un contrle de cohrence des informations saisies sera effectu (pas dheures saisies sur une journe de congs, pas de jours dclars sur plusieurs projets) Les chefs de projets valideront les formulaires transmis. Lapplication consolidera les informations et gnrera les rapports de suivi et de planification. Principales fonctions : identifier les projets et les ressources enregistrer les heures journalires passes sur un projet vrifier la cohrence des informations saisies faire valider par les chefs de projets les informations saisies consolider les informations gnrer les rapports Ces fonctions pourront tre fournies par les services suivants : service dannuaire fourni par lannuaire LDAP de lentreprise service de gestion de la liste des projets fourni par lapplication CRM de lentreprise service de calendrier des jours ouvrs fourni par lapplication RH service de gestion des absences fourni par lapplication RH de lentreprise service de stockage des donnes (ex : un SGBD) service de validation des informations par les responsables dquipe service de reporting qui fournira le rapport dactivit (consolidation des donnes stockes dans le SGBD via une application de BI) Les services seront assembls (orchestrs et chorgraphis) en fonction du processus dfini par lentreprise laide de BPMN et lensemble sera anim par le moteur dexcution des processus. Cette application peut tre reprsente par le schma Figure 21. Elle suit lensemble des bonnes pratiques mis en avant par notre approche Think Service.
32/87
Utilisateurs
Interface Utilisateur
service dannuaire
service de gestion des absences
service de calendrier
service de gestion des contrats
service de stockage des donnes
Service de validation des donnes saisies
service de reporting
Application A annuaire LDAP
Application B Gestion Ressources Humaines
Application C CRM
Application D SGBD
Application F BI
Figure 21
Exemple dapplication composite
3.6
SaaS integration platform : Composants cls
Il ne sagit pas ici de dcrire de faon exhaustive une architecture SaaS type mais de prsenter les composants qui paraissent essentiels au fonctionnement de ce type solution. Revenons sur les trois fonctionnalits de bases dune solution SaaS 2.0 : Proposer un ensemble de services mtier Permettre de modliser des processus associant services mtiers et utilisateurs Excuter dployer ces processus sous forme dapplications composites dans un portail web Ces fonctionnalits peuvent tre assures par les composants du schma montr Figure 22.
33/87
Portal QOS / Security / Management / Monitoring
Execution layer
SOA Metadata Repository

UI Model Services Model Business Model
Organizational Model
Corporate Services
Figure 22
Service Marketplaces
Architecture fonctionnelle
3.6.1
SOA Metadata Repository
Dans la logique self service impulse par le modle SaaS 2.0, la construction dune application composite doit pouvoir tre ralise directement par les experts mtier. Cela signifie que les concepteurs vont dfinir leurs exigences en fonction de la stratgie de lentreprise, mais galement quils doivent pouvoir facilement les modifier en fonction des volutions. Pour offrir cette possibilit, une SaaS integration platform sappuiera sur un rfrentiel de mtadonnes, un SOA metadata repository dont lobjectif est de fournir des informations sur les donnes, les processus et les rgles quun utilisateur peut manipuler pour construire son application. Ces informations sont dcrites sous forme de modles qui seront assembls et interprts par la couche dexcution. La plupart des solutions SaaS 2.0 proposent des outils graphiques qui permettent de crer et grer les modles comme BPMN pour la modlisation des processus par exemple. Dans le SOA metadata repository, nous trouverons principalement des informations sur : les services utilisables (fournis par la couche dintgration) les processus lorganisation Les diteurs de solutions SOA intgrent de plus en plus ce type de composant dans leurs suites logicielles et en font un lment cl. Cest notamment le cas des diteurs Software AG et Fujitsu et de leur solution commune CentraSite. 3.6.2 Execution layer
La couche dexcution execution layer est charge dinterprter les donnes du SOA repository pour construire lapplication.
34/87
Cette couche intgre le moteur dexcution des processus que sera responsable de la chorgraphie et de lorchestration des services en fonction des processus modliss par les utilisateurs. 3.6.3 Portal
Le portail reprsente le dernier tage de notre solution. Il offre aux utilisateurs une interface unifie et un point daccs centralis lensemble des applications. Cest lui qui est responsable de la prsentation et des changes utilisateurs / systme. Les solutions les plus volues proposeront plusieurs dclinaisons comme par exemple une version vocale interactive ou mobile Larrive de technologies RIA (Rich Internet Application) comme AJAX permettent de dporter une partie des traitements (non critiques) au niveau des postes clients. Cela permet de rpartir la charge entre les serveurs et le poste client mais aussi damliorer lergonomie et la ractivit des interfaces pour se rapprocher de ce que lon peut obtenir avec un client lourd . 3.6.4 QoS / Security / Management / Monitoring
Le modle SaaS est par nature fortement distribu. Cela implique des fonctionnalits avances de suivi de la qualit de service et des performances mais aussi des fonctions ddies la scurit comme le contrle daccs, la gestion des droits et lauthentification. Limplmentation de ces fonctionnalits est dfinie au travers de standards comme WSManagement et WS-Security qui doivent tre intgrs la solution.
3.7
Perspectives offertes par le modle SaaS
Comme nous lavons vu, le modle SaaS 2.0 offre une nouvelle approche de linformatique qui combine la fois la conception oriente services et processus et lexternalisation de lexploitation. Lobjectif est de reprendre le meilleur de chaque monde savoir la souplesse et lvolutivit des SOA, lorientation processus mtier des BPM et louverture et le contrle des cots des solutions hberges. Les solutions les plus volues promettent mme de mettre le dveloppement dapplications complexes la porte dutilisateurs non-informaticiens grce lutilisation de modles prdfinis reprsentant services, processus, composants, participants,, modifiables au travers dinterfaces graphiques intuitives et de wizards . Pour une entreprise, le concept est sduisant et, au-del des rticences lies lexternalisation, la possibilit de virtualiser son systme dinformation, datteindre un niveau dagilit qui permette de raligner moindre cot chaque application sur ses processus mtier, contrler les cots et rduire les temps de dveloppement sont autant de bnfices que lon peut attendre du concept. Au niveau conomique, tout un cosystme se dveloppe autour du modle SaaS 2.0. Il y a les fournisseurs de solutions cls en mains comme Salesforce.com qui fournissent rfrentiel de composants, applications pr-intgres, outils de dveloppement, dadministration et portail unifi. Dautres solutions sont spcialises dans le rfrencement de services mtier pr-intgrs et leur facturation la demande. On parle alors de Services Marketplaces . La socit Strikeiron.com est particulirement dynamique sur ce segment et multiplie les partenariats avec des diteurs comme Salesforces ou Microsoft par exemple. La pr-intgration dune marketplace permet un diteur denrichir sa solution en proposant ses clients dajouter des services (ex. service de conversion montaire, calculs de taxes).
35/87
Il y a galement les ISV (Independent Software Vendors) qui dveloppent des solutions mtier ou fonctionnelles sous forme de web services hbergs limage de ce que propose la socit XwebServices. La plupart des ISV sont rfrencs par les Services Marketplaces . Enfin, les diteurs traditionnels comme Business Object par exemple proposent de plus en plus leurs solutions sous forme de services. Ces applications peuvent tre hberges ou non, vendues sous forme dun ensemble de web services intgrer ou de package pr-intgr une solution SaaS. Par exemple, Business Object a sign un partenariat avec Salesforce et propose une partie de ses logiciels sous forme de modules intgrables dans Appexchange. Le modle SaaS 2.0 illustre bien le potentiel quoffre lassociation SOA, BPM et ASP aussi bien au niveau fonctionnel que technologique et conomique. Cependant le modle repose sur certaines briques dont le niveau de maturit et de standardisation oblige rester prudent. Lapproche Think Service de Valtech permet de prendre en compte lensemble de ces enjeux, notamment par une approche itrative qui permettra de limiter les risques, comme montr Figure 23. En effet, le concept est dclinable en une multitude dapproches quil conviendra de dfinir en fonction de ses besoins et des fonctionnalits que lon souhaite dvelopper.
Agilit
Externalisation de tout ou partie du systme SOA + BPM + Portail + solution de conception dapplications mtier oriente modlisation (Model-Driven) SOA + BPM + Solution de Portail SOA + solution de gestion des processus mtier (BPM : Business Process Management) Mise en place dune architecture SOA
Vers SaaS 2.0

Figure 23 Niveaux dimplmentation vers le modle SaaS 2.0
36/87
4 SOA et Open-Source : Etat des lieux

Lessor des concepts lis au dveloppement des architectures orientes services fait merger de nouveaux besoins en terme doutils de conception et dexploitation. De mme la maturit des standards ncessaire la mise en place de ces outils est propice au dveloppement de composants normaliss et ouverts. Ainsi cot des offres des grands diteurs se dveloppe tout un cosystme de solutions Open-Source capables de rpondre aux enjeux poses par une SOA. Lobjectif de ce chapitre est donc de prsenter succinctement une slection de solutions OpenSource bases sur Java. Pour ce faire, nous reviendrons dans un premier temps sur quelques concepts prsents dans les chapitres prcdant afin de positionner les solutions, puis nous prsenterons les principales caractristiques des outils slectionns. Cette tude nest en aucun cas une prsentation exhaustive des outils Open-Source disponibles mais prsente une slection doutils qui ont retenu notre attention de part les projets et les accompagnements que nous ralisons auprs de nos clients.
4.1
Les composants
Comme nous lavons vu dans les chapitres prcdents il est possible de reprsenter une SOA sur quatre couches principales : Interactions avec les acteurs (intgrant la logique applicative, indpendante du mtier) Processus Mtier Services Mtier Ressources Applicatives A ces quatre couches horizontales nous ajoutons deux colonnes transverses : ESB (Enterprise Service Bus) : le bus logiciel permettant de faire communiquer lensemble des couches IDE (Integrated Development Environment) : les outils de dveloppement que nous allons utiliser pour dvelopper le contenu de chaque couche. Voyons maintenant, en fonction de cette reprsentation telle que montre Figure 24, les principales caractristiques des composants de notre SOA. 4.1.1 Interaction avec les acteurs
Lobjet de cette couche est de grer les interactions avec les utilisateurs (internes / externes) du systme et dimplmenter la logique applicative indpendante du mtier (principalement la navigation entre les crans). A ce niveau nous avons identifi quatre catgories dapplications que nous dfinirons de la faon suivante : Les applications lgres : la prsentation est assure par un navigateur web install sur le poste client et les traitements sont assurs par un serveur. Typiquement ce sont des pages html simples . Les applications internet riches (Rich Internet Application ou RIA) : la logique de prsentation et une partie des traitements sont excutes par un navigateur web au travers de plug-in spcifiques comme Adobe Flash ou en faisant appel des fonctionnalits avances du navigateur via lutilisation dAJAX (Asynchronous JavaScript And XML) par exemple pour enrichir lergonomie des applications et lexprience utilisateur. On parle alors dapplication du type web 2.0. Les applications bureautiques riches (Rich Desktop Application ou RDA) : application dploye et excute sur un socle applicatif normalis souvent multiplateformes qui est install sur le poste client. Le socle applicatif est responsable de la prsentation et de tout ou partie des
37/87
traitements. Il peut prendre galement en charge les services dinstallation, de dploiement et de mise jour des applications pour en faciliter ladministration. Les RDA offrent un niveau dintgration plus pouss avec le poste client ainsi que la possibilit de fonctionner en mode dconnect. Les clients lourds : application dploye et excute directement par le poste client. Elle est fortement dpendante de son environnement dexploitation (OS / CPU). Nous avons cart de cette tude les clients lourds qui ne correspondent pas rellement aux tendances de dveloppements actuelles et aux pratiques SOA. Nous garderons donc les clients lgers dvelopps autour du conteneur de servlets Apache Tomcat21 et de pages JSP (JavaServer Pages), RIA avec les portails Web 2.0 comme Liferay22 ou Alfresco23 plus orient gestion documentaire et les RDA avec Eclipse RCP.
Figure 24
Positionnement des composants SOA
4.1.2
Processus Mtier
Cette couche est responsable de la globalit dun processus mtier informatis, c'est--dire des appels de services mtier et de la gestion des interventions humaines en relation avec la couche dInteractions avec les acteurs. De plus, nous devons tre en mesure dexcuter un processus mtier partir dun modle mtier BPMN24 par exemple et doffrir des capacits de suivi dindicateurs cls de performance au travers des fonctionnalits de BAM (Business Activity Monitoring).
21 22
http://tomcat.apache.org/ http://www.liferay.com/ 23 http://www.alfresco.com/ 24 http://www.bpmn.org
38/87
Pour cette couche nous avons slectionn Intalio BPMS25 qui propose une solution complte BPEL/BPEL4People et BPMN. Nous voquerons galement deux solutions de reporting telles que BIRT26 et JasperReports27 pour les fonctionnalits de BAM. 4.1.3 Services Mtier
Sur cette couche nous aborderons les solutions qui permettent de concevoir rapidement des services notamment le duo Apache Tomcat / Axis228. 4.1.4 Ressources applicatives
Nous ne faisons pas ici de recommandations particulires, tant donn que cette couche rassemble lensemble des ressources du SI faades par les services. Nous retrouvons potentiellement ici un ensemble de technologie htrogne, de la base de donnes au progiciel. Toutefois pour les bases de donnes, on pourra privilgier l encore des solutions open-source (lune des plus populaire tant mySQL29) pour lvolution des bases de donnes de volumtrie moyenne. 4.1.5 Les colonnes transverses : LESB et lIDE
LESB : Au niveau des outils de mdiation nous prsenterons deux solutions ESB qui sont ServiceMix30 et MuleSource31. Pour rappel nous dfinissons lESB comme un outil de mdiation qui assure les fonctions suivantes : Transport / Routage de messages Annuaire Monitoring Connecteurs Scurit Transformation de donnes Publication / Souscription dvnements LIDE : Le nombre doutils qui composent une SOA ainsi que le nombre dacteurs qui peuvent potentiellement intervenir rend lutilisation dun outil intgr de dveloppement lment essentiel de productivit. En loccurrence, la fondation Eclipse via le projet STP32 (SOA Tool Platform) retiendra toute notre attention.
4.2
Prsentation des solutions slectionnes
Aprs avoir positionn les solutions que nous avons slectionnes sur notre schma darchitecture, nous allons maintenant les prsenter. Nous commencerons par les applications de gestion des interactions utilisateurs avec des solutions orientes applications lgres (Apache Tomcat) puis les RIA (Liferay / Alfresco) et enfin les RDA (Eclipse RCP).
25 26
http://www.intalio.com http://www.eclipse.org/birt/ 27 http://jasperforge.org/sf/projects/jasperreports 28 http://ws.apache.org/axis2/ 29 http://www-fr.mysql.com/ 30 http://incubator.apache.org/servicemix/ 31 http://www.mulesource.com/ 32 http://www.eclipse.org/stp/
39/87
Ensuite nous prsenterons des solutions orientes processus mtier avec dune part un outil de BPM et dautre part des outils de BAM. Nous continuerons avec les outils de conception de services et les ESB et nous terminerons par la prsentation de lIDE SOA Eclipse STP. 4.2.1
4.2.1.1
Gestion des Interactions utilisateurs

Apache Tomcat / JSP
Apache Tomcat est un conteneur de servlet J2EE conforme avec les spcifications Servlet / JSP de Sun Microsystems. Il intgre son propre serveur http mme sil est prfrable de lassocier avec le serveur http externe comme Apache par exemple. JSP (JavaServer Pages) est une technologie Java qui permet de crer des pages web dynamiquement partir du serveur. JSP permet daccder des bases de donnes, de grer des transactions complexes, dappeler des web services et de mettre en forme le rsultat sous forme de pages web. Le couple Apache Tomcat / JSP offre la possibilit de crer des applications web lgres et performantes de faon simple et peu coteuse capables dinvoquer des Web Services. Cette solution est particulirement bien adapte aux projets qui ne ncessitent pas lusage dEJB.
4.2.1.2 Liferay
Liferay est une solution de type portail Web 2.0 Java dveloppe par lditeur amricain du mme nom. Liferay est orient gestion de portlet et est compatible JSR168. Liferay offre un service dauthentification compatible LDAP, de personnalisation de laffichage et de rendu graphique html/Ajax. Liferay dispose de passerelles dintgration vers de nombreuses solutions tiers comme la solution de gestion de contenus Alfresco par exemple. De plus il dispose dun connecteur JBI33 via lESB ServiceMix ce qui simplifie lintgration de services et doutils dorchestrations BPEL compatibles JBI comme Apache ODE34 par exemple. Il existe une version Professional et une version Enterprise . La diffrence entre les deux rside dans lutilisation ou non des EJB. La version Professional ne ncessite que Tomcat et le JDK 1.4 ou 1.5 et la version Enterprise un serveur dapplication J2EE comme JBOSS pour les EJB. Elles sont toutes les deux librement tlchargeables sur le site officiel (http://www.liferay.com).
4.2.1.3 Alfresco
Alfresco (http://www.alfresco.com) est une solution de gestion de contenus qui offre des fonctionnalits de travail collaboratif, de publication, de versionning et de partage de documents. Alfresco est une solution Java qui ncessite Tomcat ou un serveur dapplication J2EE comme JBOSS. Alfresco est disponible sous forme de portlet pour Liferay permettant ainsi denrichir les fonctionnalits du premier par une puissante solution de gestion de contenus dentreprise. LAPI Alfresco permet dappeler des web services externes mais galement dexposer les fonctionnalits dAlfresco sous forme de web services.
33 34
Spcifications JBI de Sun : http://java.sun.com/developer/technicalArticles/WebServices/soa3/ImplementingSOA.pdf http://incubator.apache.org/ode/
40/87
Le couple Liferay / Alfresco apparat comme une solution Java complte de cration dIntranet / Extranet Web 2.0 capables de grer portlets, contenus et web services. Enfin il faut noter que les deux diteurs ont officiellement annonc un partenariat avec lditeur Intalio que nous prsenterons plus loin et qui propose une solution Open-Source de gestion de processus mtier (BPMS) oriente service. La combinaison des trois offres permet dimaginer une solution dentreprise novatrice qui allierait IHM riches Web 2.0, gestion de processus mtier et fonctions avances de gestion de contenus. Un cocktail particulirement sduisant pour la conception dapplications composites orientes services.
4.2.1.4 Eclipse RCP
Le Framework Open-SourceEclipse RCP35 (Rich Client Platform) a t lanc en 2004 avec pour objectif de fournir un socle applicatif Java multiplateforme pour la cration dapplications Riches installes sur le poste de travail (RDA). Aujourdhui, Eclipse RCP constitue la base du clbre IDE Eclipse. Il est bas sur la bibliothque graphique de composants java SWT dveloppe par la fondation Eclipse comme alternative aux bibliothques AWT et Swing. SWT est juge plus performante par ses concepteurs quAWT et Swing. Le Framework Eclipse RCP permet aux applications dveloppes de bnficier par dfaut dun mcanisme de mise jour automatique paramtrable par un administrateur, de composants graphiques conformes ceux de lOS de lutilisateur pour ne pas le dstabiliser (apport SWT), dune forte intgration avec les applications bureautiques existantes, laccs aux ressources distantes pour un fonctionnement connect ou non et enfin une portabilit multiplateforme (Java). 4.2.2
4.2.2.1

Intalio|BPMS
Cr en 1999, Intalio36 fait parti des socits lorigine de BPMN (Business Process Modeling Notation) dont les spcifications ont t rcemment reprises par le consortium international OMG (Object Management Group), ce qui lui assure une plus grande reconnaissance en faisant de facto un standard. Lobjectif du BPMN est doffrir un modle graphique de description standard des processus mtier. Intalio est galement membre de lOASIS et a particip la finalisation du standard BPEL (Business Process Execution Language) dont lobjectif est doffrir un langage dexcution des processus. La maitrise des deux standards (BPMN et BPEL) a permis Intalio de dvelopper une solution complte de BPMS (Business Process Management Suite) qui va de la modlisation des processus mtier en BPMN lexcution des processus (aprs conversion automatique en BPEL). Techniquement la solution Intalio|BPMS est architecture autour des composants suivants : Intalio|Designer (bas sur Eclipse) qui assure la modlisation BPMN des processus, la conception des interfaces graphiques pour les tches humaines ventuelles et le dploiement des processus sur le serveur dexcution. Nous retrouvons ce mme Designer dans le projet Open-Source Eclipse STP qui est dtaill plus loin et dont Intalio est partenaire. Intalio|Server qui est responsable de lexcution des processus avec dune part lorchestration BPEL et dautre part la gestion des tches humaines. Lorchestration est assure par le moteur
35 36
http://www.eclipse.org/rcp/ http://www.intalio.com
41/87
Open-Source Apache ODE37 co-dvelopp par Intalio et offert la fondation Apache. ODE est un orchestrateur Java compatible BPEL 2.0 et JBI (Java Business Integration). La gestion des tches humaines est base sur lutilisation du moteur de workflow Tempo38 qui est une extension optionnelle de lorchestrateur. Tempo est une solution Open-Source base sur le standard BPEL4People et compatible JSR-168 ce qui facilite son intgration dans une infrastructure de type portail. Intalio distribue sa solution suivant trois offres : Une offre Open-Source qui permet de tlcharger et daccder aux sources du Designer, de ODE et de Tempo. Loffre Intalio|BPMS Community qui propose gratuitement un bundle complet et fonctionnel de trois composants (ODE, Tempo et du Designer) avec Geronimo comme serveur dapplication J2EE et Derby ou MySQL comme SGBD. Cette offre package est librement tlchargeable sur le site de lditeur et permet galement daccder aux forums ddis. Loffre Intalio|BPMS Enterprise qui est une offre commerciale permettant de faire fonctionner les trois composants de bases sur le serveur dapplication J2EE et la base de donnes de votre choix et offre des composants supplmentaires de BAM par exemple ainsi que laccs un service de support.
4.2.2.2 Solutions de BAM
Les processus mtiers sont au cur dune SOA ce qui permet de crer, de faon non intrusive, des indicateurs mtiers bass sur les donnes oprationnelles qui sont manipules lors des processus. Typiquement, lorchestrateur prend en charge lexcution des processus. Il dispose dune base oprationnelle dans laquelle nous retrouverons les messages changs et les vnements lis lexcution des processus. Cest partir de lexploitation de cette base que nous construirons nos indicateurs. Reste trouver les applications qui permettront de gnrer des tats en fonction des besoins avec un minimum de programmation et de les mettre en formes dans des rapports interactifs. Pour ces fonctionnalits nous avons slectionn Eclipse BIRT et JasperReports. BIRT39 (Business Intelligence and Reporting Tools) est un outil dcisionnel Open-Source dvelopp dans le cadre de la fondation Eclipse. BIRT est bas sur deux composants principaux : le Report Designer qui est bas sur Eclipse et le Report Engine qui sinstalle dans un serveur dapplication J2EE. Le Designer permet de concevoir des rapports partir dune bibliothque de modles. Les rapports incluent tableaux complexes et reprsentations graphiques 2D/3D. Les donnes partir desquelles les rapports sont crs peuvent provenir de multiples sources comme une base de donnes JDBC, un fichier XML ou des Web Services. Le data explorer permet de crer les requtes graphiquement sans code, cependant il est possible de les enrichir partir de scripts (JavaScript / Java). Les rapports sont crs en XML. Le Report Engine est responsable de la gnration des rapports et de leurs publications multiformats (HTML, PDF, XLS, DOC, PPT et Postscrip) au travers dune application Web (JSP).
37 38
http://incubator.apache.org/ode/ http://tempo.intalio.org 39 http://www.eclipse.org/birt/
42/87
Figure 25
Composants BIRT
Quant JasperReports40, cest un gnrateur dtats Java Open-Source qui permet de crer des rapports partir de multiples sources donnes (JDBC, EJB, POJO, Hibernate, XML) et de les exporter aux formats PDF, HTML, XLS, CSV, XML, RTF, TXT Les rapports sont dvelopps en XML. Pour en simplifier la cration est possible dutiliser iReports qui est un diteur WYSIWYG Open Source. 4.2.3 Apache Tomcat / Axis2 : un duo de conception de Web Services
Un lment de notre SOA est la construction de services soit comme faades des ressources applicatives existantes au sein du SI ou comme interfaces standards des futures applications. Axis2 a t dvelopp pour simplifier la cration de web service en environnement Java. Axis241 est un serveur de dploiement de web services et un client dvelopp par la fondation Apache. Axis2 implmente les spcifications SOAP 1.1 et 1.2. Il peut fonctionner comme moteur de services web autonomes ou comme application J2EE dans un conteneur de servlet comme Apache Tomcat par exemple. Axis2 permet notamment de grer des messages (envoyer, recevoir, transformer) SOAP, de crer des web services partir de classe java et inversement de gnrer des classes java partir de WSDL. Il existe dautres modules qui permettent dtendre les fonctionnalits dAxis2. Les services conus ou appels par Axis2 peuvent sappuyer sur certaines recommandations comme WS-Security, WS-ReliableMessaging, WS-Addressing, WS-Coordination, et WS-Atomic Transaction. Axis2 dispose galement doutils de dploiement, test et monitoring des services notamment sous la forme de plug-in Eclispe.
40 41
http://jasperforge.org/ http://ws.apache.org/axis2/
43/87
4.2.4
4.2.4.1
Les ESB
ServiceMix
Apache ServiceMix42 est un ESB Open-Source bas sur les spcifications JBI (Java Business Integration). On le classera galement dans la catgorie conteneur JBI . JBI est une spcification (JSR20843) dicte dans le cadre du Java Community Process dans le but de dfinir un modle dintgration plug & play de composants producteurs et/ou consommateurs de services. La description des services est assure par lutilisation du WSDL 2.0.
Figure 26
Architecture JBI
Larchitecture dun conteneur JBI est articule autour deux types de composants : Les Binding Components (BC) responsables de la gestion des protocoles pour lintgration des services et Les Services Engines (SE) responsables de la logique de traitement (routage des messages, orchestration, transformation). Le routage des messages entre les composants est assur par le Normalized Message Router (NMR) et les messages sont changs via un des quatre Message Exchange Patterns (MEP) : In-Only. Le consommateur envoie un message au producteur qui fournit en retour un statut. Robust In-Only. Le consommateur envoie un message au producteur qui renvoie soit un statut soit une exception. Dans ce cas le consommateur devra renvoyer un statut. In-Out. Le consommateur envoie un message et le producteur rpond avec un autre message. In Optional-Out. Le consommateur envoie un message au producteur qui pourra optionnellement renvoyer un message retour. Linstallation, le dploiement, le contrle et le monitoring des composants sont assurs par lutilisation de JMX (Java Management Extensions). Il est possible de plugger sur un conteneur JBI nimporte quel type de composant JBI chaud et donc den tendre les fonctionnalits et la liste des protocoles supports. Par exemple,
42 43
http://incubator.apache.org/servicemix/home.html http://www.jcp.org/en/jsr/detail?id=208
44/87
lorchestrateur BPEL Apache ODE que nous avons prsent est compatible JBI, c'est--dire quil peut tre intgr comme Service Engine dans un conteneur JBI comme ServiceMix. ServiceMix dispose de son propre plugin IDE Eclipse nomm Cimero. Cet outil a t dvelopp initialement par Bull et a ensuite t offert la communaut ServiceMix.
4.2.4.2 Mule
Mule est un ESB Open-Source bas sur Java dvelopp par MuleSource44.
Figure 27
Mule Architecture (source www.mulesource.com)
Un des avantages de Mule rside dans le grand nombre de connecteurs supports parmi lesquels : JMS, JBI, JCA, JDBC, TCP, UDP, HTTP, FTP, POP3. Lorchestration des services est assure par un moteur BPEL / BPMS. Sur ce dernier point un partenariat avec Intalio a t sign pour faciliter lintgration de services exposs par Mule dans des processus grs par Intalio|BPMS. Mule est multiplateforme (Java 1.4 et sup.) et a t test avec les environnements J2EE suivants : Apache Tomcat, WebLogic, WebSphere, Geronimo, JBoss, Oracle, Resin, Jetty, JRun. Enfin, Mule dispose de son propre IDE bas sur Eclipse. 4.2.5 Eclipse STP : Un IDE pour SOA
Le projet Eclipse SOA Tool Platform (STP) a pour objectif de fournir dans un environnement unifi les outils ncessaires la gestion du cycle de vie dune architecture oriente service. STP est bas entre autres sur les spcifications SCA45 (Service Component Architecture) dveloppes entre autres par IBM, BEA Systems, Oracle, SAP et TIBCO Software Inc. SCA dfini un modle dimplmentation et dassemblage de composants pour la conception dune SOA technologiquement neutre .
44 45
http://www.mulesource.com http://www.ibm.com/developerworks/library/specification/ws-sca/
45/87
Les outils proposs par Eclipse STP couvrent le dveloppement, le paramtrage, lassemblage, le dploiement, la supervision et la gestion des services mis en uvres. Par exemple, parmi les lments proposs, nous trouvons un outil de modlisation BPMN capable de valider les processus mtier modliss et de les convertir au standard dexcution BPEL. Cet outil a t dvelopp et fourni la communaut Eclipse par lditeur de solutions de BPMS Intalio. La premire version du Framework STP est disponible avec la version 3.3 (Europa) dEclipse (sortie fin Juin 2007).
4.3
Conclusion
Cette rapide prsentation permet de mettre en avant le dynamisme des communauts OpenSource dans le domaine des architectures orientes services. En effet, il est aujourdhui parfaitement envisageable dutiliser tout ou partie de ces solutions pour btir des architectures modernes bases sur les standards du moment. Reste valuer la facilit avec laquelle ces outils sont intgrables. Sur ce point, limplmentation de standards dintgration et les derniers partenariats (Liferay / Alfresco / Intalio / MuleSource / ServiceMix / Apache / Elcipse) permettent dtre optimiste. En conclusion nous dirons simplement qu lheure actuelle, lorsquune entreprise doit faire le choix doutils SOA, il est indispensable pour elles de considrer les solutions Open-Source au regard des offres commerciales.
46/87
5 Un retour d'exprience en urbanisation & SOA

Ce Chapitre rapporte un retour dexprience dune mission de neuf mois mene par les consultants Valtech. Celle-ci se droule dans le cadre dun programme innovant de rnovation dune partie dun systme dinformation dans le domaine de lnergie. Elle montre comment les concepts vu dans le chapitre prcdents sont utiliss et adapt au contexte du client.
5.1
Description du contexte
Un acteur majeur du secteur de lnergie sest engag dans la refonte dune partie de son systme dinformation. Ce SI est constitu aujourdhui par un nombre important dapplications, dans des technologies diverses et avec une gestion des donnes et des flux complexes. Ceci rend le systme dinformation fragile et difficile faire voluer, un moment o les modifications rglementaires et limportance grandissante des leviers daction aux diffrents horizons de temps ncessitent un systme dinformation de plus en plus robuste et volutif. Lentreprise a dfini un programme qui a pour objectif une rnovation progressive du SI, afin dviter un effet big bang , anti-pattern notoire. Le programme se droule sur plusieurs annes et vise terme un remplacement de lensemble des applications. La planification prend en compte : Des critres techniques (remplacement de technologies obsoltes, proof-of-concept sur des nouvelles technologies) ; Des critres fonctionnels (ralisation doutils servant des processus mtier critiques et mise en uvre dvolutions fonctionnelles demandes par le mtier) ; Des critres organisationnels (prise en compte de dpendances avec des rorganisations dquipe). Lobjectif est de mettre en uvre un systme rpondant une architecture conforme aux standards actuels de linformatique. Cest pourquoi le programme est demandeur dune architecture SOA (Service-Oriented Architecture). La SOA est aujourd'hui considre comme la solution d'architecture permettant de russir lurbanisation du Systme dInformation. Les solutions SOA et les outils associs sont mis en avant par tous les grands diteurs du march, et particulirement dans la rponse des intgrateurs aux appels doffre. La mission a consist en une tude durbanisme dont les objectifs taient daccompagner le client dans une monte en comptence sur des choix darchitecture innovants et de structurer larchitecture du systme. Cette tude durbanisme porte sur les quatre niveaux darchitecture mtier, fonctionnel, applicatif et technique tels que dfinit dans Think Service
5.2
Principes darchitecture applicative SOA
Dans ce paragraphe, nous dcrivons comment les concepts vu prcdemment dans le chapitre 2 Think Service ont t dclin et adapt au contexte de cette intervention. La SOA est un style architectural dans lequel les processus mtier sont livrs sous la forme dun ensemble de services faiblement coupls, et non pas sous la forme dapplications monolithiques. La notion traditionnelle dApplication sy trouve quelque peu dissoute au profit de la notion de Service qui, par construction, nappartiennent aucune application particulire.
47/87
On appellera alors Processus Instrument la dmatrialisation dun processus mtier (ou dune partie dun processus) qui orchestre dynamiquement des services rutilisables nappartenant aucune application particulire. Une architecture SOA qui sinscrit dans une dmarche durbanisme contribue aligner le Systme dInformation sur les processus mtier de lentreprise et contribue garantir une volution matrise et optimise du SI lorsque les processus mtier voluent. SOA doit tre vu comme un pattern darchitecture dans lequel chaque processus mtier est ralis par une squence de services. Les services vus comme des traitements mtier grosse maille sont indpendants, interoprables et rfrencs. Le mta-modle reprsent Figure 28 explicite lensemble des concepts SOA utilis dans le cadre du programme. Ce mtamodle drive de celui vu prcdemment 2.1.3.
Figure 28
Mtamodle SOA adapt au contexte de lintervention
Un processus mtier est une chane de valeur dcrite par un enchanement dactivits et de transformations. Une opration est une partie du processus rutilisable dans diffrents contextes. Une opration est un traitement qui regroupe plusieurs activits/transformations contigus et non interruptibles du processus mtier. Un service est le packaging de (1..n) oprations qui forment une cohrence fonctionnelle.
48/87
Pour le contexte de notre intervention, nous exploiterons ici le concept de catgorie46. Une catgorie est un agrgat dobjets de granularit fine permettant dimplmenter un objet mtier, et dont la faade est un service mtier unitaire. Un service mtier unitaire permet de manipuler et de fournir les informations portes par la catgorie (les attributs de lagrgat de classes qui constitue la catgorie). Il fournit galement les traitements lmentaires sur les classes de la catgorie. En dautres termes ces services forment une faade daccs aux classes de la catgorie. Ils sont donc rattachs des blocs construits autour dun partitionnement par les donnes. Ils permettent galement dimplmenter les encapsulations techniques. Un service mtier unitaire est medium grained . Un service mtier composite rend une fonction mtier par la composition doprations de services mtier unitaires. Un service mtier composite est coarse grain (grosse maille). Un processus instrument est la dmatrialisation dun processus mtier (ou dune partie dun processus) qui orchestre dynamiquement des oprations de services mtier composites et unitaires. Un service expose un contrat dutilisation qui permet un consommateur de comprendre son usage fonctionnel et technique. Un document mtier chang est une collection de points de vue sur les objets mtier. Il reprsente la vue partage dans le cadre du processus (vue pivot) et change dans un appel de service ou dans une synchronisation de donnes via EDA. Il est charg de sens mtier, et est orient message (document). Des conteneurs de services regroupent les services autour : dune proccupation homogne de gestion (typiquement autour dun progiciel), et/ou de qualit de service (disponibilit, temps de rponse par exemple) et/ou dexploitation, de dploiement 5.2.1 Principe de couplage faible
La mise en uvre de ces composants de larchitecture SOA respecte le principe durbanisme fondamental de couplage faible, savoir : Les oprations des services mtier composites ne sinvoquent pas entre elles. Ce sont les processus instruments qui assurent ce squencement. Les oprations de services mtier unitaires ne sinvoquent pas entre elles. Ce sont les processus instruments ou les services mtier composites qui assurent le squencement. Les services mtier composites nont pas accs la couche de persistance. Ce sont les services mtier unitaires qui assurent cet accs. La porte dun service mtier unitaire est la catgorie laquelle il est rattach. La porte dun service mtier composite est une proccupation homogne de gestion parmi lesquelles on retiendra : le primtre dun progiciel ou dune technologie ; une frontire physique comme la traverse dun pare-feu ; une frontire organisationnelle et mtier forte comme une business unit ; lexistence dactifs patrimoniaux . La porte dun processus instrument est la totalit du systme.
46
Historiquement le concept de catgorie a t introduit par Grady Booch.
49/87
Par ailleurs, il existe des catgories dupliques dont lorigine est externe au primtre du systme. Les oprations de service mtier unitaire qui mettent jour une catgorie duplique doivent tre mises en uvre uniquement dans le cadre dune synchronisation de donnes par vnement dEDA. Cette contrainte permet de sassurer quune donne rfrence en dehors du primtre du systme ne peut tre modifie que par et dans son systme dorigine. Il peut exister des processus ou des parties de processus qui ne soient pas implments par un processus instrument. Dans ce cas, la couche prsentation utilise directement les oprations des services mtier composites et unitaires. La Figure 29 illustre lurbanisation du SI selon un couplage faible.
Figure 29
Urbanisation du SI selon les principes de couplage faible
5.2.2
Couche daccs aux donnes (SDO)
Les intgrateurs peuvent proposer une couche daccs aux donnes qui permette de rendre la reprsentation des donnes indpendante des systmes de stockage sous-jacents. Ces services daccs aux donnes ne doivent pas tre assimils aux services mtier unitaires. Cest en fait une couche technique utilise dans limplmentation dune catgorie comme une alternative un ORM comme Hibernate. Elle devrait tre conforme la spcification SDO (Service Data Objects) qui standardise les accesseurs selon un couplage faible indpendamment de la couche de persistance et en consquence unifie la programmation dune catgorie par rapport aux sources de donnes.
50/87
5.2.3
Habilitations
Ni les services mtier composites, ni les services mtier unitaires nembarquent de rgles dhabilitations. Ces rgles sont loges dans un composant spcifique de scurit qui fournit les services : didentification (qui es-tu ?) dauthentification (es-tu celui que tu prtends tre ?) dhabilitation (es-tu autoris faire ce que tu demandes ?) de Single Sign On (SSO) : dans une SOA, les services sont indpendants. Il nest pas acceptable de devoir se re-authentifier sur chacun des services. Il faut donc propager les informations dauthentification et dhabilitation. Le contrle daccs doit sexercer par rapport au service lui-mme, mais galement par rapport aux donnes manipules par le service. Des restrictions daccs sur ces donnes doivent tre implmentes.
5.3
Dmarche de ltude durbanisme
Compte tenu de lorientation SOA du programme, ltude durbanisme consiste raliser un dcoupage en Services. Ce dcoupage est effectu au niveau fonctionnel et applicatif. Il est obtenu, dune part, par lanalyse des spcifications gnrales, du plan durbanisme et de la liste des objets mtier fournis par le programme et, dautre part, par la modlisation des processus mtier : Larchitecture fonctionnelle dcrite dans le plan durbanisme est restreinte au primtre du systme. Les objets mtier identifis donnent lieu des services mtier unitaires qui grent leur cycle de vie. Les fonctionnalits dcrites dans les spcifications gnrales dont le regroupement constitue un ensemble de traitements contigus, non interruptibles et rutilisables sont associes de manire constituer une opration de service mtier composite. In fine une opration de service mtier composite doit mapper une fonctionnalit. Cette premire identification des services est corrobore par la description des cas dutilisation qui supportent les principales procdures identifies dans la modlisation des processus mtier (architecture mtier). Un cas dutilisation est spcifi en dtail par un (ou plusieurs) diagramme(s) de squence (des diagrammes dactivits auraient pu tre raliss si les procdures avaient t dcomposes en activits enchanes). De ces diagrammes de squence mergent des services et des documents mtier changs (objets pivots) qui valident ou invalident lidentification faite partir de la liste des fonctionnalits dcrite dans les spcifications gnrales.
5.4
5.4.1
Dclinaison de la mthode sur un sous-ensemble du systme

Architecture mtier
Larchitecture mtier prsente les processus mtier structurs en processus, sous-processus et procdures. La Figure 30 prsente un exemple simple de processus mtier, sur lequel apparaissent acteurs, messages et enchanement de processus, sous-processus et procdures.
51/87
Figure 30
Exemple de processus mtier
Lidentification des processus mtier permet de faire merger les objets mtier mettre en uvre. Ensuite, chaque procdure mtier peut tre formalise par un ou plusieurs cas dutilisation. Ces cas dutilisation identifient les fonctionnalits attendues pour permettre lexcution des processus mtier. Les cas dutilisation supportant les processus mtier oprent chacun sur plusieurs objets mtier. Plus prcisment, au travers dune IHM excute pour un cas dutilisation, un acteur invoque des services qui prennent, en entre et en sortie, un ensemble dobjets mtier. On introduit ici les DME, i.e. les Documents Mtier Echangs (ou objets pivot, i.e. des agrgats dobjets mtier), afin daugmenter la lisibilit de lanalyse et faire en sorte que chaque opration excute par un service prenne en entre un unique objet et fournisse en sortie un unique objet. La spcification dtaille dun cas dutilisation nous permet de dfinir (cf. Figure 31) : les acteurs (humains ou systmes externes) qui interagissent avec le systme ; les services mtier unitaires (prfixs SMU) invoqus par les acteurs, ainsi que les oprations excutes et les DME en entre et en sortie de ces oprations ; les services mtier unitaires sur les catgories dupliques (prfixs CATDUP) invoqus par les acteurs, ainsi que les oprations excutes et les DME en entre et en sortie de ces oprations ; les services mtier composites (prfixs SMC) invoqus par les acteurs, ainsi que les oprations excutes et les DME en entre et en sortie de ces oprations.
Service mtier com posite, unitaire ou unitaire pour catgorie duplique
:SMU Programme de marche

Objet mtier:ProgrammeMarche
:CATDUP Programmes raliss

Objet mtier:ProgrammeRalis
IHM
Opration
:SMC Raccordement de rservoir
:CATDUP Programmes redclars

Objet mtier:ProgrammeAppelRedclar
:SMC Planning hydraulique de rfrence
:SMU Raccordement hydraulique

1-Objet mtier:ProgrammeTravail 2-Objet mtier:CoteVolumeRemplacement 3-Objet mtier:RaccordUsineHydro 4-Objet mtier:RaccordRservoir 5-Objet mtier:ApportRemplacement
: /Fournir planning travail(Demande:IdentificationOuvragePourModelisation,Rponse:ProgrammeTravail)
Si aucun programme de travail pour l'ouvrage
: /Fournir programme de marche(Demande:IdentificationOuvragePourModelisation,Rponse:ProgrammeMarche)
: /Fournir programme redclar(Demande:IdentificationOuvragePourModelisation,Rponse:ProgrammeRedclar)
: /Fournir programme ralis(Demande:IdentificationOuvragePourModelisation,Rponse:ProgrammeRalis)
Figure 31
Exemple de spcification dtaill dun cas dutilisation dans un processus mtier
52/87
5.4.2
Larchitecture fonctionnelle reprsente les blocs fonctionnels et les changes dinformation qui supportent la ralisation des processus mtier. Elle est dcrite la maille Zone/Quartier conformment au plan durbanisme et prsente la synthse du dcoupage, savoir : Les quartiers correspondant aux sous-systmes indpendants et autonomes, Les zones regroupant les quartiers homognes rpondant un mme niveau de proccupation, Les donnes mtier dont chaque quartier est responsable. La Figure 32 montre un exemple de tel dcoupage en zones et quartiers.
Figure 32
Exemple de dcoupage en blocs fonctionnels avec une maille Zone/Quartier
5.4.3
Architecture applicative
Dans la vision SOA, larchitecture applicative est lensemble des services, des processus instruments et des changes qui mettent en uvre les blocs fonctionnels. Un extrait de cette architecture est donn sur la Figure 33.
Figure 33
Extrait de larchitecture applicative du SI tudi
53/87
Un conteneur de catgories (cf. Figure 34) fournit les services mtier unitaires sur les catgories quil regroupe. Chacun de ces services fournit les oprations de manipulation des objets de la catgorie : Oprations de cration, modification et suppression Fonctions de recherche Traitements spcifiques
Conte neur des catgories des donnes de rfrence

<< Catgor ie >>
CAT Rf re ntiel des nomenclatures

<<Serv ic e Mtier Unitair e>>
SMU Nome nclature Oprationne lle

+Objet mtier:Identif ic ationOuv r agePour Modelis ation +Four nir tous les lments d'une lis te de nomenc latur e(Demande:( 1..1) Lis teNomenc latur e_DME,Rpons e:(1..n) Nomenc latur e_DME) +CUD lment de nomenc latur e opr ationnelle( Demande:(1..n) Nomenc latur e_DME) +Rec her c her lments de nomenc lature( Rpons e:( 1..n) Nomenc lature_DME) +Four nir la lis te des nomenc latur es ( Rpons e:( 1..1)Lis teNomenc latur e_DME) +CUD nomenc lature( Demande:( 1..1)Lis teNomenc latur e_DME)
<<Se r vi ce M tie r Un it air e> >
SMU Nomenclature Contractuelle

+1-Objet +2-Objet +3-Objet +4-Objet m tie r :Ide ntif ic at io nEntit m tie r :Ide ntif ic at io nEf f ac eme nt m tie r :Ide ntif ic at io nCo nt r at m tie r :Ide ntif ic at io nCro ss R f re nc e
+Four nir t ou s les l men ts d' un e l is te de n ome nc la tur e( De man de :( 1..1) Lis teNomenc latur e_DME,Rpons e:(1..n) Nomenc latur e_DME) +CUD lme nt de no men clat ur e co nt rac tuelle(D ema nd e:( 1..n) No menc lature_DME) +Four nir l a li ste d es cr o ss r f r e nc es ( Demande: ( 1.. n) Nomenc lat ure_DME,Rpons e:( 1..n) Identif ic ationCr os s Rf r enc e_DME) +Rec he r ch er lme nts d e n ome nc la tu r e( Rpons e: ( 1.. n) Nomenc lat ure_DME) +Four nir l a li ste d es no men cl at ur e s(R pons e: ( 1.. 1)L is teN ome nc la ture_DME) +CUD c r oss r f r en ce (De man de :(1. .n) Ident if ica tionC r os sRf r enc e_DME) +CUD nomen cl atu re( D ema nd e:( 1 ..1 ) Li st eNomenc lat ure _DME)
Figure 34
Exemple de conteneur de catgories pour larchitecture applicative
Par ailleurs, les services mtier composites oprent sur toutes les catgories, en fonction dun contexte dexcution. Ce contexte peut tre constant (par exemple le type de consommateur ou lenvironnement dexcution utilis) ou maintenu dynamiquement par le processus instrument. Dune manire gnrale, le comportement dun service doit pouvoir varier selon son contexte dutilisation. Un service mtier composite fournit des oprations qui implmentent des appels doprations de services mtier unitaires (portant potentiellement sur des objets mtiers appartenant des catgories diffrentes) et prennent en compte des rgles de gestion complexes. 5.4.4 Insertion dans le SI
Il est important de prsenter comment le nouveau systme peut sinsrer dans le systme dinformation actuel. Pour cela, les donnes changes entre lancien systme et toutes les autres applications du SI ont t identifies, de faon prvoir limpact du programme : Des documents mtier changs transitent au travers dchanges EDA : cest le cas lorsquun DME auquel a souscrit un composant est modifi par une application externe ou par un service du systme ou lorsquun DME auquel a souscrit le connecteur dune application est modifi par un service du systme.
54/87
Des documents mtier changs transitent galement lors dimports de donnes : cest le cas lorsquun processus instrument importe une information et la persiste sur un conteneur de catgorie. Des documents mtier changs transitent galement au travers dchanges SOA : cest le cas lorsquun processus instrument invoque une opration de service mtier externe au primtre du systme. Il est alors possible de dfinir un scnario dintgration qui prendra en compte les adhrences organisationnelles, mtier, fonctionnelles et applicatives de lancien systme par rapport lensemble du SI, ainsi que les dpendances entre ces adhrences. Le nouveau systme peut alors sinsrer dans le SI de faon matrise.
5.5
Bilan de cette tude
Nous pouvons tirer un certain nombre de leons partir de cette tude et ainsi dresser une liste de piges viter pour mettre en perspective ce type dintervention vis--vis des relations qui existent entre une DSI et ses fournisseurs. Tout dabord, concilier lapproche durbanisation top-down avec une dmarche SOA qui peut sapparenter une intgration de services permet de positionner la notion de service tous les niveaux darchitecture. Cette notion de service est vritablement une innovation dont il faut accompagner lacceptation. Ainsi, nous nous rendons compte que le dmantlement dapplications monolithiques au profit dune orchestration de services reprsente un changement culturel. Beaucoup de personnes continuent de raisonner en termes d outil portant sur des macros-blocs fonctionnels et/ou applicatifs, mme sils ont bien compris tout lenjeu de penser service . Parmi les enjeux de mise en place dune SOA dont, figure en bonne place la rutilisation des services, laquelle on portera une attention toute particulire. La rutilisation de lorchestration de services, quant elle, ne constitue pas un enjeu majeur. Elle parat en effet assez illusoire et est supporte actuellement par des outils aux fonctionnalits encore assez basiques (pour les algorithmes complexes, les appels rcursifs doprations ou la prise en compte de rgles de gestion complexes, on ne passe pas par une orchestration de services mais par une opration de service mtier composite). En revanche, on cherchera absolument mutualiser et rutiliser les formats dchange entre systmes, en privilgiant des types complexes conformes aux normes et standards de lindustrie. Ces changes entre systmes, notamment dans une approche de type EAI, constituent un volet cohrent avec lensemble de la dmarche qui prend en compte lurbanisation (dcomposition mtier/fonctionnelle/applicative/technique), la SOA (dcoupage en services), lEDA (dimension vnementielle) et lESB (orchestration de services). Cette dmarche permet ainsi de positionner la notion de service au cur de tous les sujets dintrt. Pour complte quelle soit, cette dmarche nen demeure pas moins la fois gnrique et facilement contextualisable : son mta-modle reste assez simple et son application sur la mission a fait lobjet de plusieurs runions de communication et a permis de rpondre bon nombre de questions. La mission sest droule dans le cadre dun palier du programme conduit en mode projet. A ce titre, on peroit quun SI volue au gr de projets vus comme des organisations ayant vocation prendre en compte des primtres fonctionnels et applicatifs et des contraintes de budget, de ressources, de plannings, de risques Pour autant et tout en restant pragmatique, le projet intgre des considrations durbanisation dont certaines sont prescriptives.
55/87
En effet, ltude durbanisme a tabli plusieurs principes et dcoupages prescriptifs. Par ailleurs, ralise en amont du projet, elle est alle assez loin dans lidentification des cas dutilisation, des services et des catgories et dans lamorce de lorchestration de services (invocation de services, gestion des messages asynchrones), sans pour autant tout dcrire, ltude durbanisme ne se substituant pas aux spcifications dtailles. La dmarche a pu tre mene par un nombre rduit dintervenants et offrir une couverture complte du primtre. Compare au cot du dveloppement du systme sous-trait un intgrateur, elle a reprsent un cot conomique assez faible et a constitu un appui dterminant de la DSI dans sa relation avec lintgrateur. Enfin, il reste encore dfinir la gouvernance SOA. En effet, avant que le systme ne soit dploy, il faudra dfinir les conditions dexploitation, le processus de maintenance volutive et corrective, les modalits dexposition des services, les prcautions prendre lors des montes de version ou lors des modifications apportes aux orchestrations de services Certains de ces sujets restent classiques mais tous prsentent des spcificits dues aux changements organisationnels et techniques occasionns par la SOA.
56/87
6 Rflexion sur la gouvernance SOA

6.1 Prambule
Parmi les projets dvolution de Systmes dInformation actuellement en cours, la plupart mne une rflexion sur les apports dune architecture oriente-service. En effet, la SOA est aujourd'hui considre comme la solution permettant de rconcilier les activits durbanisation et dintgration, en plaant le service la frontire des deux mondes. Comme nous lavons vu dans les prcdents chapitres, cest un style architectural dans lequel les processus mtier ne sont plus noys dans des applications monolithiques mais au contraire sont des composants clairement identifiables assurant une orchestration de services faiblement coupls. Un projet SOA commence souvent par la dfinition des principes didentification des services. En fonction des principes retenus et mis en vigueur, on peut aboutir des services de granularits diverses et rapidement des dizaines de services aux contours mal dfinis. La SOA rend encore plus cruciale la dfinition des besoins et des solutions apporter concernant les conditions dexploitation, les processus de maintenance volutive et corrective, les modalits dexposition des services, les prcautions prendre lors des montes de version ou lors des modifications apporter aux orchestrations de services. Par ailleurs, si la SOA nous amne rflchir sur les processus mtier et si la rutilisation des services semble de plus en plus raliste et accessible, encore faut-il se donner les moyens de disposer dindicateurs mtier ou techniques permettant de tirer un maximum de bnfices des efforts consentis pour la mise en uvre. Si une entreprise ne prend pas les dispositions pour tablir des rgles rpondant ces besoins, la SOA mise en uvre risque dtre victime de son succs : incapacit grer une monte en charge des utilisateurs, budgets non prvus pour les volutions fonctionnelles apporter aux services mis en exploitation ou pour le renouvellement de linfrastructure logicielle ou matrielle. Il faut en effet considrer que le SI nvolue plus seulement au rythme des projets dvolution partielle ou totale : la SOA amne le SI voluer en permanence, de manire flexible. Derrire ces nouvelles capacits rsident des enjeux se rapportant lintgration plus rapide des nouveaux composants, la rduction du time-to-market , lamlioration des relations entre les utilisateurs internes ou externes des applications et les projets de maintenance Cest pourquoi, pour continuer tirer les bnfices dun proof-of-concept SOA russi et pour tre en mesure de dployer cette architecture, les parties prenantes de la SOA doivent se poser un certain nombre de questions par rapport des aspects : Stratgiques : Quelle est la vision SOA de lentreprise ? Financiers : Quel est le modle de financement des services ? Contractuels : Quel est le cycle de vie dun service ? Quelles sont les diffrentes qualits de service proposes aux consommateurs de services ? Des contrats ont-ils t tablis entre les producteurs et les consommateurs de services ? Organisationnels : Y a-t-il un sponsor SOA ? Quel est le modle de proprit des donnes ? Quel est le modle de proprit des services ?
57/87
Les rponses ces questions dfiniront llaboration et lapplication par une organisation de principes, normes, rgles, procdures de prise de dcision et programmes communs propres modeler lvolution et lutilisation de la SOA. Cest pourquoi il est fondamental que les entreprises qui ont pris le virage de la SOA ne se contentent pas de mettre en place de nouvelles architectures mais poursuivent leurs efforts pour dfinir et suivre les bonnes rgles dexploitation de linfrastructure et des services.
6.2
Identification des interlocuteurs concerns et du primtre adresser
La formulation de gouvernance SOA est la mode aujourdhui, notamment travers celle du Gartner Group (20 janvier 2006) : SOA governance isnt optional its imperative. Without it, return on investment will be low and every SOA project out of pilot phase will be at risk. Pour rpondre ce besoin, les principaux diteurs de logiciels ont toff leurs offres en 2006 : HP/Mercury avec Systinet, webMethods avec Infravio ou encore BEA avec Flashline. Au-del de ce constat, nous observons aujourdhui que beaucoup dditeurs de logiciels et dintgrateurs prennent la gouvernance SOA dans une acceptation trs large qui les amne juste titre proposer des solutions compltes mais dont la mise en uvre est souvent longue et coteuse. Notre position est quelque peu diffrente. Nous cherchons ne pas perdre de vue les enjeux majeurs de la SOA (i.e. principes darchitecture souples et dmarches projet agiles) et nous tenons rester pragmatiques dans les rponses que nous apportons nos clients. Cette dmarche nous amne nous adresser principalement aux responsables oprationnels ou dexploitation (Directeurs de projet, Architectes des projets dinnovation, dvolution ou de maintenance) qui sont confronts, de faon trs concrte, aux problmatiques portant sur la granularit des services, la rutilisation des services, leur cycle de vie, la supervision des processus mtier, lexploitation des contrats de services. Il sagit donc maintenant daccompagner toutes les parties prenantes dans les changements organisationnels et techniques occasionns par la SOA, et selon les quatre axes suivants : Rgles respecter au cours du processus de dveloppement : on sappuie ici sur un rfrentiel darchitecture qui recense les applications et services dj existants et dj mis en exploitation et les changes de donnes ; Dfinition des processus de publication des services dont la finalit est de dployer les services, les rendre disponibles la consommation pour ainsi constituer progressivement un annuaire des services ; Dfinition et mise en application des rgles dexcution : la gouvernance dfinit qui peut accder quels services et quel moment, elle tablit les priorits entre les clients et les services en cas de conflit et choisit les informations disponibles en fonction des politiques tablies ; Dfinition de la gestion des contrats de service mettre en uvre dans les outils dadministration de la SOA, de faon suivre les alertes mtier ou techniques dclenches lorsque le contrat de service nest pas respect.
58/87
6.3
Ncessit dun organisme dtude et de dcision
De faon rester pragmatique, nous conseillons nos clients de sintresser la gouvernance SOA uniquement lorsque le premier service mtier mutualisable47est mis en production. En effet, la mise en uvre darchitectures SOA ncessite plusieurs pr-requis : Mise en place de linfrastructure technique (au minimum un conteneur de service, un orchestrateur, un framework de dveloppement associ) ; Proof Of Concept (au minimum une maquette ou prototype dun client connect un orchestrateur qui prend en compte les aspects vnementiels et invoque des services dont certains, via un pont objet/relationnel, enregistrent ou lisent des informations dans une base de donnes) ; Rflexion avec les utilisateurs sur les processus mtier48, les objets mtier49 et le patrimoine applicatif50 ; Comme nous le prconisons dans Think Service, rflexion sur la rconciliation entre lapproche bottom-up permettant de rutiliser les ressources existantes et lapproche top-down dont le but est de prendre en compte la vision mtier, les services tant l pour faire le liant entre les deux approches ; Principes didentification des services. Il peut se passer plusieurs mois avant que tous ces pr-requis ne soient atteints et il est bien souvent inutile voire contre-productif de se lancer dans une rflexion globale sur la gouvernance SOA, sans bien savoir o lon va et quelle cible on dsire atteindre. A partir du moment o un premier service mtier mutualisable est mis en production, il devient alors utile et ncessaire de se poser un certain nombre de questions : Comment sassurer que le service pourra tre rutilis dans un autre contexte ? Si un autre projet ncessite que des volutions fonctionnelles soient apportes au service, ces volutions doivent-elles tre prises en charge par ce nouveau projet ou au titre du maintien en conditions oprationnelles du service ? Comment grer la monte de version dun service potentiellement utilis dans plusieurs contextes et par plusieurs applications ? Les rponses toutes ces questions seront fournies par une organisation de type Club des Architectes (cf. illustration Figure 35) qui runira les architectes fonctionnels et techniques des projets et les responsables dexploitation. Il est, en effet, fondamental que des rponses soient apportes de faon centralise et collgiale par des personnes impliques dans les dcisions prendre et servant de relais pour la mise en application des dcisions prises : il faut tout prix viter lanti-pattern tour divoire , rester prs du terrain et trouver des compromis. Cette organisation disposera dune ligne budgtaire et sera conduite par un animateur dont le pouvoir de
Nous insistons sur le terme mutualisable car si le service a t dvelopp uniquement pour le besoin prcis dune application, alors la notion mme de gouvernance perd tout son intrt. 48 En toute rigueur, lidentification des services concerne essentiellement les vues fonctionnelle et applicative, comme nous le montrons dans notre approche Think Service. Toutefois, il est important de dcomposer les processus mtier en tches humaines (prises en charge dans des services d'interaction) et en tches automatiques (prises en charge dans des services mtier), de faon faire correctement merger une liste de services mtier avec le bon niveau de granularit. 49 De mme, il est important de rflchir aux objets mtier manipuls et ainsi orienter le dcoupage des services mtier autour de la gestion de ces objets. A ce niveau, il n'est gnralement pas ncessaire de faire une tude mtier dtaille car il est gnralement assez facile d'baucher un modle d'objets mtier sans trop entrer dans le dtail des processus. En revanche, il sera ncessaire de mener ultrieurement une tude dtaille au niveau fonctionnel pour dterminer les orchestrations mettre en place. 50 Avec ou sans processus mtier, il est parfois lgitime de chercher faader un certain nombre de ressources applicatives derrires des services mtier dcoups selon les objets mtier.
47
59/87
dcision et le positionnement dans la hirarchie seront clairement tablis. Selon le niveau de maturit des parties prenantes, lanimateur pourra choisir entre laisser chacun apporter sa contribution ou dfinir une grille de RACI51 tablissant les responsabilits de chacun. Ces responsabilits portent sur des actions qui relvent de la gouvernance SOA et qui seront imputes sur les projets dinnovation, dvolution ou de maintenance ou au titre dactivits rcurrentes (exploitation ou support/mthodes/outils) : dfinition des bonnes pratiques SOA et des rgles associes ; dveloppement des services pour un nouveau besoin ; adaptation des services pour un besoin dj existant ; mise en place et surveillance dindicateurs de performance mtier ou techniques et portant sur la qualit de service. Le Club des Architectes se runira rgulirement, afin de coordonner et suivre les actions et passer en revue les dossiers des projets dinnovation et dvolution, de faon : viter la redondance des services ; homogniser les livrables des projets, dun point de vue documentaire et applicatif ; valider les choix darchitecture des projets aux niveaux mtier, fonctionnel, applicatif et technique ; faciliter les analyses dimpact sur les processus mtier, les dcoupages fonctionnels, les applications en production et les technologies employes. Le Club des Architectes aura comme premier objectif lefficacit. Il devra prendre des dcisions pragmatiques et compatibles avec les contraintes des projets. Il pourra bien sr se raccrocher aux normes en vigueur (CMMi, ITIL) mais lon cherchera avant tout rpondre de faon concrte aux besoins oprationnels.
Figure 35
Le Club des Architectes
51
Responsible-Accountable-Consulted-Informed
60/87
Le Club des Architectes est l pour apporter un cadre aux projets sur les diffrents plans darchitecture. A contrario, les oprationnels permettent une alimentation suivant les standards dploys de ces diffrents plans, notamment en mettant au catalogue de nouveaux services. Ils compltent plus prcisment des portions de la vision transverse que le club gre.
6.4
La gouvernance SOA en pratique
Outre lvaluation des projets dinnovation ou dvolution, le club des architectes aura la mission de mener un certain nombre dactions qui relve de la gouvernance SOA et que lon peut positionner dans un modle de maturit durbanisation et dintgration. 6.4.1 Modle de maturit
A travers nos diffrentes interventions, nous avons dfini un modle de maturit permettant de dterminer le niveau de pratique dune dmarche durbanisation du systme dinformation. Ce modle est bas sur lexprience et le pragmatisme ; en complment de notre approche Think Service, ce modle permet de positionner les bonnes pratiques dune urbanisation oriente-service du SI, selon diffrents niveaux de proccupation. Un tel modle permet de conduire rapidement un audit et de dterminer les atouts et les faiblesses dune entreprise dans la maitrise de larchitecture de son systme dinformation. Par contre, il ne mesure en rien le niveau de maturit du systme dinformation en tant que tel, qui lui relve de laudit darchitecture. Notre modle de maturit illustr Figure 36 est une matrice organise verticalement selon six disciplines et horizontalement selon cinq niveaux de maturit (le niveau 1 correspond au niveau non-mesur). A chaque intersection correspondent des pratiques cls sur lesquelles il faut tre particulirement vigilant pour garantir le succs dune dmarche durbanisation.
Figure 36
Modle de maturit pour le processus durbanisation du SI
61/87
1 Non Mesure Au niveau 1, rien nest en place ou du moins aucune pratique nest clairement dfinie pour les diffrentes disciplines. Le succs dpend donc trs fortement des comptences et de limplication des personnes et non de lutilisation de pratiques prouves. 2 Emergence Au niveau 2, les activits darchitecture mergent des projets ; elles sont dfinies, planifies et excutes en accord avec la politique de lorganisation mais il ny a pas encore une relle unification des pratiques et de mutualisation au sein du SI. 3- Convergence Au niveau 3, les diffrentes activits darchitecture inities au niveau 2 convergent en une mme dmarche et en un modle mutualis darchitecture, standardise au niveau de lorganisation. La gestion de cette dmarche est assure de faon transverse. 4- Appropriation Lorganisation et les projets dfinissent des objectifs quantitatifs de qualit et de performance et les utilisent comme critres au niveau des processus de gestion. Ces objectifs quantitatifs sont bass sur les besoins des clients, utilisateurs, de lorganisation et des projets. Le devenir dun projet est prdictible grce ces indicateurs. 5- Optimisation Lorganisation amliore continuellement le processus de dveloppement par analyse quantitative des causes de variation de celui-ci. Les effets de lamlioration du processus sont mesurs et valus continuellement par rapport aux objectifs initiaux dfinis. Le schma propos ici a lavantage dtre indpendant du choix SOA. Il est valable pour toute mise en uvre dun processus dUrbanisation, mise en uvre que lon peut dfinir grce des objectifs identifis (par exemple, niveau 2 pour Archi Mtier, niveau 3 pour Archi Fonctionnelle, niveau 4 pour Trajectoires, etc.). En outre, il ne prsuppose pas de la mise en uvre faite derrire. Par exemple, on pourra faire une standardisation des pratiques au niveau de lArchitecture Mtier, avec BPMN ou des cas dutilisation mtier exprims en UML, avec plus ou moins de prcisions quant au modle du domaine. SOA reprsente un choix par rapport la mise en uvre qui va impacter toutes les disciplines sauf lArchitecture Mtier qui, rappelons-le, reste indpendante de toute solution de conception du systme dinformation et de son implmentation avec des systmes informatiques. A lapparition du premier service, on peut considrer tre au niveau 2 sur les architectures, et faire de ce premier projet un pilote utilis pour dfinir un processus de dveloppement SOA permettant dinitier la mise en place de lenvironnement ncessaire (le Club des Architectes, les infrastructures, etc.). Ici commence alors la pratique de Gouvernance qui doit galement dmarrer ds le niveau 2. Dans ce contexte, nous donnons dans les paragraphes qui suivent quelques pistes de rponses aux questions que nous rencontrons couramment lors de nos interventions. Ces rponses ne se veulent pas exhaustives, le sujet tant encore trs jeune et loin davoir atteint sa maturit. Elles constituent toutefois une base de rflexion pour le Club des Architectes, qui permet daborder la SOA au-del de ses aspects purement fonctionnels et techniques.
62/87
6.4.2
Si un service a t mis en production avec une qualit de service donne et si un consommateur souhaite une adaptation de celui-ci, peut-on rutiliser le service ou faut-il mettre en uvre un nouveau service ? La gestion des variantes est dterminante pour la matrise des cots et la flexibilit des systmes et permet dadapter un service dun point de vue fonctionnel. Elle est aujourdhui rendue possible par la technique de lobjet (interface, hritage) et par le pattern darchitecture Context-Aware. Ce pattern darchitecture sapplique aux systmes susceptibles de sadapter au contexte dutilisation et, ce titre, permet de spcifier et dimplmenter des services rutilisables mais capables, en fonction du contexte dutilisation, dexcuter des traitements spcifiques ou doffrir une qualit de service diffrente. Sagissant de la qualit de service, il suffit simplement de dployer un service sur une nouvelle infrastructure offrant une meilleure qualit de service, en plus de linfrastructure sur laquelle il tait dj dploy. 6.4.3 Architecture applicative
Comment dfinir la granularit adquate pour lexposition des services ? On rappelle dabord quun service peut exposer plusieurs oprations, une opration pouvant tre de type CRUD52 sur un objet mtier ou implmenter un traitement spcifique comme un calcul par exemple. Dans tous les cas, une opration nest pas interruptible et peut tre amene prendre en compte une problmatique transactionnelle. Par ailleurs, un service qui regroupe plusieurs oprations peut tre versionn et, pour tre invoqu, doit tre rfrenc dans un annuaire. On peut donc grer la granularit dexposition des oprations par ces deux biais : dune part, regroupement des oprations dans un ou plusieurs services, dautre part, gestion de versions et rfrencement des services. Dautres considrations sont prendre en compte comme notamment la performance des web services, le cot du service vis--vis de sa granularit et lidentification des consommateurs (B2B ou utilisateur interne). Selon lutilisateur, on pourra mettre en place plusieurs bindings, mettre en uvre plusieurs protocoles, passer par un proxy, invoquer un appel local ou distant. Il ny a pas ici de solution miracle, tous ces lments entrent en ligne de compte et ont une incidence sur la granularit des services, de la mme faon quils ont toujours eu une incidence quelle que soit la technologie employe Quelles sont les rgles mettre en pratique pour le versionnement des services ? Face la quantit de services de diverses granularits pouvant merger et face la combinatoire des appels de service qui peut en rsulter, il est important de limiter la dclinaison dun service dans de multiples versions. Cest pourquoi il est fortement recommand de proposer aux consommateurs au maximum deux versions pour chaque service et de prparer lobsolescence dune version dun service ds quune version suivante de ce service est dploye. Quels sont les outils mettre en uvre pour la gouvernance SOA ? Les outils mettre en uvre doivent couvrir les fonctions suivantes :
52
Create-Read-Update-Delete
63/87
rfrentiel des services, pour le recensement des services, des applications et des flux de donnes ; dploiement des services, pour la mise en production des services ; annuaire des services, pour les consommateurs ; administration des services, pour le suivi des indicateurs de performance mtier ou techniques. Il existe plusieurs outils qui couvrent tout ou partie de ces fonctionnalits. Les plus connus ont t mentionns ci-dessus (cf. 6.2). Il existe aussi des outils Open Source quil serait dommage dignorer : annuaire de service avec ApacheDS, moteur de workflow avec Tempo, orchestrateur avec ODE, ESB avec MuleSource et Apache ServiceMix, BAM avec Eclipse BIRT 6.4.4 Architecture technique
Comment grer les flux de donnes volumineux via des web services ? Il nest pas recommand dans ltat actuel de la technologie de grer des flux volumineux (plusieurs dizaines de Mo) via des web services, notamment parce que les appels de web services sont la plupart du temps synchrones et que les enveloppes SOAP ont tendance alourdir les changes. Les flux de donnes volumineux peuvent tre occasionns par des dcoupages inappropris : certaines solutions techniques sont alors disponibles (exemple : transfert des donnes via des attachements compresss) mais, si celles-ci ne suffisent pas, la dfinition des services devra tre revue. Dans dautres cas, la technologie des web services nest pas adapte : on doit alors abandonner lintgration oriente services et se reporter sur lintgration oriente donnes, pour laquelle dautres solutions techniques existent : EAI53, ETL54, MDM55 Comment exploite-t-on une SOA ? Lexploitation dune SOA est sans aucun doute un sujet dterminant si lon veut en tirer tous les bnfices. Elle permet de surveiller lexcution des services. Elle est rendue possible par des produits (solutions Amberpoint, Management Point de SOA Software, Infravio par exemple). Le principe consiste mettre en uvre, sur chaque service surveill, des sondes susceptibles de remonter les informations suivantes en XML : Identification du service : nom du service, version, description smantique ; Etat technique du service : inactif, occup, arrt, en erreur, satur ; Configuration du service : paramtres techniques et fonctionnels susceptibles de faire varier le comportement du service ; Mtriques sur le service : nombre de requtes, nombre de requtes en erreur, temps de rponse ; Dpendance du service avec dautres services. Ces indicateurs servent : comptabiliser les flux SOAP et ainsi constituer des reporting mtier ; dfinir des politiques dexcution des services permettant, lorsquun problme de disponibilit des ressources dexploitation apparat, de grer les priorits, rejeter une requte ou rediriger une excution sur un autre serveur ; exploiter les SLA56 (exemple : nombre de CPU alloues pour lexcution dun service) ;
53 54
Enterprise Integration Application Extract-Transform-Load 55 Master Data Management 56 Service Level Agreement
64/87
contrler les versions des services, partir des dates de fin de validit et des tats des services ; suivre les processus de bout en bout. En dautres termes, il sagit de mettre en uvre une Gestion des Services Mtier (en anglais BSM pour Business Service Management ) laide doutils de : BPM ( Business Process Management ) pour le suivi de lexcution des services et de leurs orchestrations ; BI ( Business Intelligence ) pour la constitution a posteriori de reporting et de tableaux de bord ; BAM ( Business Activity Monitoring ) pour le pilotage mtier en temps rel ; SLM ( Service Level Management ) pour la gestion des contrats de service et la surveillance des disponibilits. Ces indicateurs peuvent tre exploits, afin de : Garantir la qualit de services des architectures SOA : Taux de disponibilit (exemple : 99%) ; Temps de rponse (exemple : 2 ms) ; Scurit : cryptage, non-rpudiation Exploitabilit : gestion des capacits, gestion des incidents Superviser le SI : Processus mtier : performances mtier, flux de donnes, BAM ; Services : gestion contractuelle des SLA, performances applicatives ; Infrastructure : systme et matriel. Cette exploitation dune architecture SOA doit tre conduite par lexploitant. En sappuyant sur le club des architectes et, au besoin, en faisant intervenir les responsables mtier, lexploitant sera alors en mesure de : anticiper les montes en charge des utilisateurs ; organiser des campagnes de performance ; en cas de ressources insuffisantes, interrompre certains services pour certains consommateurs, en fonction des SLA ; proposer un modle de facturation bas sur la comptabilisation de lexcution des web services ; dployer un service sur plusieurs plates-formes en fonction des contrats de services proposs aux consommateurs. 6.4.5 Trajectoire
Quelle trajectoire peut-on se donner pour la gouvernance SOA ? On peut bien sr tablir des prospections sur lavenir de la SOA : maturation des normes et des standards, couverture des offres des diteurs, flexibilit du SI, changements organisationnels occasionns par des initiatives inter-dpartement bases sur les processus Quoi quil en soit, il est crucial qu court terme, le club des architectes surveille certains aspects dune faon pragmatique : rutilisation des services ; rduction des cots de dveloppement ; efficacit des processus ; non-prolifration des services. Pour cela, on sappuiera sur les indicateurs de performance mtier ou techniques mis en place.
65/87
6.4.6
Pilotage
Quels sont les projets ligibles la SOA ? Tout dabord, la SOA convient si les utilisateurs raisonnent en termes de processus mtier : les responsables dtudes et les exploitants sont alors en mesure de mettre en uvre des indicateurs de performance mtier et techniques sur les processus superviss et la SOA est alors susceptible de faire atteindre plusieurs objectifs viss (rutilisation des services, agilit du SI dans lalignement sur les processus). Sil nexiste pas de processus mtier, la SOA se rduira une collection de web services orients sur laccs aux donnes et le retour sur investissement sera bien moindre. Ces propos doivent toutefois tre attnus car une SOA peut aussi consister faader les principales sources de donnes dun SI, de faon normaliser les changes et faire merger des pivots drivant des objets mtier. La SOA est alors totalement lgitime et, dans ce cas, ne sappuie pas directement sur des processus, bien qu terme lalignement vers ceux-ci soit ncessaire. Quoi quil en soit, on peut donc dfinir des critres dligibilit la SOA, le premier critre tant la capacit dfinir un processus mtier. Dautres critres peuvent merger : capacit rutiliser les services (notamment vis--vis de lorganisation et de larchitecture technique du SI), capacit dresser linventaire et la cartographie des services et/ou des applications existants, existence dune infrastructure dj mise en place, niveau de maturit des parties prenantes vis--vis des impacts organisationnels de la SOA (tudes et exploitation) et vis--vis des techniques concernes (ESB, moteur de BPEL, UDDI), existence de progiciels Comment dfinir le cycle de vie dun projet SOA ? Un projet SOA doit comporter des activits prenant en compte les thmes qui composent la gouvernance SOA et qui ont t introduits ci-dessus (cf. 6.2) : Conception et construction des services ; Publication des services ; Intgration et dploiement. Le club des architectes doit intervenir des moments bien dtermins dans le projet pour sassurer que les rgles dfinies de manire collgiale et portant sur diffrents thmes sont mises en application : nommage et granularit des services ; sparation entre les contrats de service (WSDL), les modles des documents transports (XSD) et la description des protocoles employs (binding) ; structure des contrats de service ; indicateurs de performance mtier et techniques.
6.5
Conclusion
Comme nous avons pu le voir la vue des diffrentes questions que chacun peut se poser sur les services, lorganisme de gouvernance constitue un facteur important de la russite de la SOA dans une entreprise. Il garantit la prennit des efforts consentis dans la dfinition des architectures fonctionnelles, applicatives et techniques, apporte une visibilit de la trajectoire SOA suivie par lentreprise et contribue lefficacit des projets dinnovation, dvolution et de maintenance. Il ny a pas de dmarche unique de gouvernance, de la mme manire quil ny a pas de dmarche unique dans le dveloppement logiciel. Il est donc important de se concentrer sur les bonnes pratiques de base, simple mettre en place dans lorganisation, de faon ce que la SOA et la gouvernance associe ne deviennent pas un frein linnovation au sein de lentreprise. Do
66/87
lapproche pragmatique que nous avons prsent ici, qui sappuie avant tout sur les architectes prsents sur les projets et non sur une quelconque cellule transverse compltement dconnecte et fonctionnant dans un mode tour divoire .
67/87
7 Retour d'exprience en urbanisation & intgration

Nous vous rapportons ci-aprs lexprience mene pendant prs de 2 ans par une quipe de 4 consultants Valtech, responsables du pole intgration dans un grand projet de mise en place dun progiciel de ressource humaine. Tout dabord, nous situons le contexte de lexprience, puis nous dcrivons les livrables et le processus de travail de la dmarche LSC (Livret - Spcification - Contrat), dvelopp par Valtech pour traiter aisment des problmatiques dintgration. Ensuite nous dtaillons un des points important de cette exprience quest la mise en place dun serveur de rfrentiel. Enfin nous explorons des pistes dvolutions et damliorations de cette dmarche.
7.1
Problmatique et solution cible
Une grande entreprise de transport a comme projet de remplacer son systme informatique de Ressources Humaines et paie maison par un progiciel. Le systme actuel sappuie sur des solutions techniques obsoltes (Bull - GCOS 8) pour lesquelles les comptences sont rares. De plus lapplication est complexe (une cinquantaine de programmes), peu documente et larchitecture, construite sur 20 ans, nest pas optimise (deux systmes de calcul de paie). Tout ceci rend la maintenance et les volutions prilleuses. Le choix dun progiciel parmi les leaders du march, HR Access, est priori un gage de scurit pour la russite du projet. Cependant, la ncessit de nombreuses adaptations et surtout les changes entre les outils oprationnels grant le pointage, les affectations oprationnelles et les primes locales, entre les applications RH hors primtres et entre les tiers extrieurs (mutuelles, banques, caisse de retraite, ) rendent ce projet difficile concevoir. Sur le plan technique, les applications interfacer sont htrognes (Unix, Linux, Gcos8, Windows) et les quipes manquent dexprience dans les solutions dintgrations ce qui rend le client prudent sur les solutions techniques. Il prfre carter les solutions de type EAI pour utiliser un systme dchange par fichiers point point mieux matris techniquement et plus facile faire accepter dans lentreprise. De plus le nombre important dapplications ayant besoin des mmes informations conduit mettre disposition un entrept de donnes afin de limiter les flux directs. Les principes de larchitecture applicative cible sont montrs sur la Figure 37.
68/87
RH hors primtre
Appli A Appli A 13 applis
Contrle de gestion
Mutuelles & Prestations Familiales

Appli A
Appli A
Appli A
Appli A
3 applis
3 applis
RH oprationnels
Appli A Appli A Appli A Appli A 15 applis
Banques (virements, PEE, ) HR Access

Appli A
Appli A 2 applis
Serveur de Rfrentiel Ressources Humaines
Clients du serveur de rfrentiel

Appli A 40 applis
Figure 37
Architecture applicative cible (simplifie)
Une quarantaine dapplications communiquent par flux directs et une autre quarantaine vient chercher des informations dans le serveur de rfrentiel. Le client est conscient de lampleur de la tche accomplir mais ne sait pas trop comment attaquer le problme, il est sduit par la dmarche LSC (Livret - Spcification - Contrat) propose par Valtech qui lui offre une dmarche structure pour grer ses changes.
7.2
Description de la dmarche LSC
LSC dcrit les tapes, les livrables et le processus de travail permettant de spcifier les changes inter applicatifs. 7.2.1
7.2.1.1
Livrables
Processus et modle mtier
Avant de se lancer dans une telle refonte dans son Systme dInformation, il convient de faire une cartographie des processus et des termes mtier, comme montre Figure 38. La cartographie des processus permet de mettre plat toutes les oprations mtier, didentifier les acteurs participants et dinventorier les outils instrumentant ces processus.
69/87
Figure 38
Exemple de cartographie des processus
Cette activit permet aussi de constituer un glossaire mtier, premire tape la constitution dun modle mtier. La cration dun modle mtier RH de lentreprise permet de modliser les entits du mtier indpendamment de la solution apporte par un progiciel. Il est la rfrence quand viendra le temps de dcrire les changes et notamment les formats pivots. Ce modle, dont un extrait est montr Figure 39, est sous la responsabilit danalystes fonctionnels mais doit tre relu et valid par la matrise douvrage.
70/87
Figure 39
Exemple de modle mtier
7.2.1.2
Cartographie applicative
La cartographie applicative de lexistant, dont un extrait est montr Figure 40, nest pas toujours facile raliser et sapparente parfois de larchologie ! Elle est cependant indispensable pour se projeter dans lavenir et savoir quels sont les systmes faire voluer et ceux quil faudra couper le jour de dmarrage. La cartographie applicative cible permet formaliser les contours du SI, didentifier les zones de communications et de lister les systmes faire voluer. Cest galement un outil de communication et de rfrence lorsque des volutions sont tudier.
71/87
Figure 40
Exemple de cartographie applicative
7.2.1.3
Livret des changes
Une fois la cartographie applicative dessine, il faut tudier et formaliser les changes. Le livret des changes est le premier livrable de la dmarche LSC. Il permet, par organisation, de recenser les applications, les besoins de flux, les contraintes techniques ou fonctionnelles et les intervenants. Pour chaque application sont recenss : les systmes dexploitation, les plateformes logicielles et matrielles, les contraintes dexploitation, et aussi les noms et coordonnes des responsables MOA, MOE et dexploitation. Son objectif est pouvoir la suite sorganiser pour raliser les spcifications dtailles des changes.
7.2.1.4 Contrat de partenariat
Le contrat de partenariat est un document dcrivant le processus qui va permettre la description dtaille des changes. Par organisation, il indique les jalons, les responsabilits et les intervenants qui participeront la conception des flux. Ce contrat doit tre formellement approuv par les responsables des organisations.
7.2.1.5 Spcification Fonctionnelle des Echanges (SFE)
Cest le document principal de la spcification des changes qui fait le lien entre les diffrents livrables produits jusque l. Il dcrit fonctionnellement les changes entre 2 applications.
72/87
Tout dabord, il situe les flux par rapport aux processus mtier cartographis prcdemment et donne les clairages fonctionnels permettant de comprendre les tenants et aboutissants des flux. Pour chaque flux, il dtaille les rgles mtier (transcodification, changement de concepts,), la population concerne, la priodicit, les pr/post conditions, les critres de dclenchement, la volumtrie, la granularit dintgration, le mode dgrad, etc. Chaque Objet Mtier chang57 est dcrit fonctionnellement (cf. Figure 41) et les donnes changes sont mises en relation avec le modle mtier.
Figure 41
Diagramme de classes dun lOME
7.2.1.6
Contrat dInterface (CI)
Le contrat dinterface dcrit une interface, il y a donc au moins deux CI par SFE. Il prcise comment les fonctionnalits dcrites dans la SFE seront implmentes par la interface. Les critres permettant de slectionner la population peuvent par exemple tre dtaills jusquau niveau dune requte SQL de slection.
Objets Mtier Echangs = Objets Pivots de lapproche Think Service (cf. mtamodle Figure 4 du 2.1.3). OME est le terme retenu dans le contexte de cette mission.
57
73/87
Il dcrit prcisment lOME, on parle alors de format pivot, et surtout il spcifie le mapping entre les donnes sources/cibles et le format pivot. Si des transformations, des calculs doivent tre implments, ils sont dcrits prcisment. Le CI est le principal document qui permet au dveloppeur dimplmenter linterface.
7.2.1.7 Formats Pivots
58
Cest la description dtaille de lOME o lon prcise le nom technique, le type, la longueur, le caractre obligatoire et les valeurs par dfaut de chaque attribut.
7.2.1.8 Synthse des livrables
Lensemble des flux entre les applis A et B sont spcifis dans une Spcification Fonctionnelle des changes (SFE)
Format Pivot XML
Systme dchange
OME Appli A
Appli B
Demi interface spcifie dans un Contrat dInterface
CI
Lensemble des flux des applications dune organisation sont contractualiss dans un livret des changes LOME fait rfrence au modle mtier
Figure 42 Synthse des livrables
7.2.2
Dmarche de travail
Au-del des diffrents types de livrables documentaires caractriss par la dmarche LSC, celle-ci sinscrit dans une dynamique organisationnelle mettant contribution les diffrents acteurs du projet dintgration : MOE Progiciel : responsable de limplmentation technique du progiciel MOA Progiciel : responsable de limplmentation fonctionnelle du progiciel MOE Intgration : responsable de limplmentation technique des interfaces MOA Intgration : responsable de limplmentation fonctionnelle des interfaces MOE Application en interface : responsable de limplmentation technique de lapplication
58
Dans lapproche Think Service, ce format est quivalent la description XSD des objets pivots.
74/87
MOA Application en interface : responsable de limplmentation fonctionnelle de lapplication Intgrateur : responsable de la ralisation des travaux dintgration
Pour chaque application interface avec le progiciel une suite de runions est planifie. Cette dmarche pour but de dfinir les lments dterminants pour la rdaction des SFE et CI et leur validation par les diffrentes parties impliques.
7.2.2.1 Elaboration dune SFE
Le schma Figure 43 illustre lordre chronologique des runions mener en vue de llaboration dune Spcification Fonctionnelle dEchange.
Figure 43
Elaboration dune SFE
PE1 : Premire runion prparatoire runissant les MOE des applications en interface et les MOE Intgration. Elle a pour objectif de cadrer les flux et les OME utiliss dans le processus dintgration. Elle constitue la matire premire de la rdaction dune SFE v0.1 et permet den identifier les lments cls : types de donnes changs, priodicit, volumtrie... PE2 : Deuxime runion prparatoire runissant les mmes acteurs que la PE1 plus lintgrateur. Elle a pour but de valider les lments issus de la PE1 et dapporter une rponse aux points en suspens prcdemment soulevs. Une version 1.0 de la SFE est produite suite cette runion. RF2 : Runion de validation Fonctionnelle entre les MOE et MOA des applications en interface, les MOE et MOA du progiciel et les lintgrateur. Son objectif est la validation de la SFE. A lissue de la runion la plupart des points en suspens doivent tre rsolus. La validation consensuelle des diffrents acteurs aboutit une version 1.1 de la SFE.
7.2.2.2 Elaboration dun CI
Le schma Figure 44 illustre lordre chronologique des vnements en vue de llaboration dun Contrat dInterface.
75/87
Figure 44
Elaboration dun CI
RT2 : Runion Technique entre les MOE Intgration et lintgrateur qui a pour objectif de valider le Contrat dInterface. Pour rappel, le Contrat dInterface (CI) est le livrable technique de lchange caractris par la mise en correspondance des donnes au format pivot avec les donnes dune des applications en interface, ici le progiciel central. Le CI contient de fait toutes les rgles de transcodification et de transformation ncessaires lintgrateur pour raliser le flux.
76/87
7.3
7.3.1
Serveur de rfrentiel
Pourquoi ?
La mise en place dun progiciel de gestion administrative et paie rsout de facto la problmatique de dispersion et de rplication des donnes dans le systme dinformation, du moins pour les donnes issues des RH. Dans le projet que nous prsentons ici, la plupart des flux changs concerne des donnes de paie pour lesquelles ont t privilgies des connexions point--point. Cette solution prsente le gros inconvnient de multiplier les spcifications fonctionnelles pour certains types dinformation communs toutes les applications, essentiellement des donnes propres aux salaris comme, par exemple, leurs informations personnelles o leurs affectations dans lentreprise. Pour remdier cette problmatique nous avons adopt la solution de loperational data store , savoir un serveur de rfrentiels centralis et aliment essentiellement par le progiciel. Son contenu et son infrastructure technique sont spcifis dans un seul et unique document. De plus, cette architecture responsabilise davantage les applications qui ont dsormais un rle actif dans la rcupration des informations, la diffrence des flux point--point qui leur sont envoys directement. Le schma Figure 45 illustre le positionnement du serveur de rfrentiel dans larchitecture du systme dintgration.
Figure 45
Positionnement du serveur de rfrentiel dans le SI
7.3.2
Donnes mises disposition
Le primtre des donnes mises disposition est dtermin partir de plusieurs critres : Disponibilit des donnes dans le SIRH : seules les donnes issues du systme dinformation centralis des ressources humaines sont mises disposition Besoin des applications : afin de limiter la volumtrie du serveur de rfrentiels, les donnes qui ne sont utilises ou qui ne pourraient tre utilises par aucune application ne sont pas mises disposition Donnes multi-applications : le serveur de rfrentiels ne contient pas des donnes qui ne seraient destines qu une seule application. Le flux point point est privilgi pour ce type de besoin. Niveau de sensibilit des donnes : les donnes juges trop sensibles comme les donnes de paie ne sont pas diffuses. Les informations personnelles des salaris sont soumises quant elle une confidentialit minimum.
77/87
7.3.3
Format des donnes
Le serveur de rfrentiels contient des donnes reprsentes dans un modle pivot indpendant des modles des applications sources et mettrices. Ce choix permet de normaliser un langage commun transverse lentreprise pour les donnes issues du SIRH. Cette modlisation doit imprativement faire lobjet dune validation attentive de la part des matrises douvrage mtier. Le format pivot est quant lui la dclinaison physique du modle pivot. Il permet donc duniformiser et de normaliser les types et longueurs des donnes du SIRH. 7.3.4 Techniques de mise disposition
La principale difficult technique lie la mise en uvre dun serveur de rfrentiels vient de lhtrognit des applications en interface, comme rsum sur la Figure 46. En effet, les environnements les plus rcents ctoient souvent les systmes les plus anciens et il nest pas ais de trouver des solutions consensuelles. Dans notre projet, nous avions face nous des applications issues des systmes GCOS, UNIX et Windows. Les premires ne pouvant accder une base de donnes relationnelles nous avons choisi la mise disposition des donnes sous forme de fichiers plats de types CSV, colonnes fixes et XML par lintermdiaire dun serveur SFTP (Secure File Transfert Protocol). Bien entendu, laccs par SQL reste le mcanisme le plus souple et le plus robuste.
Figure 46
Offres de mises disposition par SQL et par FTP.
7.3.5
Alimentation
Lalimentation du serveur de rfrentiels revt une importance particulire dans la mesure o elle doit rpondre aux critres dexigences fixs par les applications consommatrices des donnes. Une de ces exigences, parmi les plus importantes, concerne la frquence dalimentation, qui doit tre
78/87
dtermine en cherchant un quilibre entre performances et qualit de service, on parle de frquence optimale. En effet, la frquence dalimentation doit tre suffisamment leve pour rpondre au besoin de mise jour le plus fin, sans compromettre la stabilit du systme. Si cette adquation savre difficile il peut tre envisag, par exemple, de lisser lalimentation sur une priode plus longue en isolant des lots dalimentation sur des frquences diffrentes. Il convient toutefois de garder une frquence optimale pour les lots de donnes critiques. Le dcoupage en lots est donc un exercice qui rpond non seulement des contraintes techniques mais aussi des contraintes dordre fonctionnel dtermines par une analyse prcise de la criticit des donnes dans les systmes en interface. Dans lancien systme de lentreprise, certaines donnes mises jour quotidiennement ntaient diffuses quen dbut de mois suivant, obligeant ainsi des applications consommatrices de ces donnes effectuer des saisies manuelles anticipes, sources derreurs et dincohrences. Afin de rduire ces erreurs et dans la mesure o le nouveau systme nous permettait techniquement de le faire, nous avons pu garantir une frquence dalimentation quotidienne pour lensemble des donnes mises disposition. Toutefois cette garantie ne sappliquait quau cas nominal car nous ne pouvions tre assurs en phase de conception dtaille que certains traitements ne bloqueraient pas le processus dalimentation durant des priodes indtermines. Cest le cas par exemple pour le calcul mensuel de la paie des 45 000 salaris de lentreprise, trs consommateur en ressources machine. Toutefois, ces modifications exceptionnelles dans la frquence dalimentation sont signales aux applications qui peuvent ds lors dclencher des processus dgrads pour mettre jour leurs propres donnes. Ainsi, le serveur de rfrentiels permet de saffranchir des modifications manuelles systmatiques. 7.3.6 Diffrentiel
La mise en place dun mcanisme de diffrentiel fut sans doute une des principales difficults auxquelles nous nous sommes confronts. Il ntait pas prvu initialement en raison des contraintes techniques quil imposait lextraction des donnes du progiciel. De plus les applications en interface nen avaient pas systmatiquement besoin ou, du moins, leurs besoins taient trop diffrents pour proposer une solution gnrique. Nous avons cependant du cder la demande pressante de certaines applications parmi les plus structurantes et rflchir une solution simple, suffisante et ne consommant pas trop de ressources systme. Le mcanisme que nous avons propos sarticule autour de deux attributs techniques prsents dans toutes les occurrences de tous les OME du serveur de rfrentiels, savoir un statut et une date de mise disposition. Le statut indique dans quel tat Cre, Modifi ou Supprim se trouve loccurrence la date de mise disposition. Les tableaux ci-dessous prsentent un exemple du mcanisme de diffrentiel sur une occurrence avant et aprs une alimentation la date J :
TABLE ETAT_CIVIL AVANT ALIMENTATION
ID 109087
NOM DUPONT
PRENO M Michel
NOM_CONJOIN T
STATU T C
DATE_MAD J-1
TABLE ETAT_CIVIL APRES ALIMENTATION
ID 109087
NOM DUPONT
PRENOM Michel
NOM_CONJOINT STATUT DATE_MAD MARTIN M J
79/87
On constate que la valeur de la colonne STATUT est passe Modifi (M) suite lajout du nom du conjoint sur cette occurrence. La date de mise disposition est donc gale la date de lalimentation. Ainsi, les applications en interface peuvent facilement dtecter les occurrences modifies entre deux ou plusieurs alimentations. Nous avons pu constater au travers de ces quelques lments que la mise en place dun serveur de rfrentiel ou entrept de donnes doit rpondre des contraintes techniques et fonctionnelles trs prcises et souvent sous-values. Le cadrage fin des besoins des applications en interface est le garant dune mise en uvre consensuelle. Pour ce faire, il est primordial dinstaurer un dialogue rgulier et dpourvu dambigits avec les diffrents acteurs du systme dinformation.
7.4
Bilan de cette tude
La dmarche LSC de Valtech a permis de spcifier des changes inter-applicatifs nombreux et complexes dans un environnement lui aussi complexe. La mthode et les livrables sont simples comprendre et utiliser, nous navons pas eu de rejet mme de la part dutilisateurs peu favorables au projet. Dun point de vue organisationnel, les runions demandent la prsence de beaucoup dintervenants et de ce fait doivent tre bien planifies et bien prpares. La multiplication des documents permet dadresser prcisment le besoin des diffrents intervenants mais demande un effort important de gestion documentaire. Les changes de fichiers correspondaient bien au besoin du client mais pour une approche oriente services il faudrait adapter les livrables et le processus.
80/87
8 Annexe : Mtmodle pour lapproche Think Service

Notre approche Think Service peut se dcliner en un mtamodle permettant de dfinir facilement les diffrents concepts et leurs relations. Ce mtamodle est organis selon les quatre niveaux de reprsentation de larchitecture du SI. Il na pas pour objectif de faire ici lexhaustivit des concepts ; son rle est plutt de disposer dune grille de lecture permettant de positionner les diffrents concepts par rapport aux autres travers les diffrents niveau de reprsentation du SI.
8.1
Synthse des concepts SOA dans Think Service
La Figure 47 montre la synthse des diffrents concepts SOA mis en avant par Think Service.
Figure 47
Synthse des concepts SOA
81/87
8.2
Complments EDA SOA dans Think Service
La Figure 48 montre les concepts propres EDA en complment dune SOA.
Figure 48
Complments EDA
82/87
9 Annexe : Aperu de BPMN

La modlisation des Processus Mtier a fait lobjet de nombreux travaux dans le domaine de lingnierie logiciel, bien que ce type de modlisation ait finalement t trs peu exploit jusqu prsent dans les projets informatiques. La vision SOA permet de replacer les processus mtier au cur de larchitecture du SI. Reste avoir une notation standard supporte par les diteurs de solutions SOA. Cest ce quapporte le BPMN59 (Business Process Modeling Notation), dont linitiative est soutenue par lOMG, et qui est support par les acteurs majeurs60 du march du logiciel. Lobjectif de BPMN est double : Fournir une notation graphique complte permettant de reprsenter un processus mtier en dcouplant les informations mtier des informations techniques qui fournit un cadre de travail commun aux utilisateurs mtier et techniques ; Fournir un mapping complet vers les langages dexcutions. Ainsi, une fois les processus modliss par les utilisateurs mtier, et les informations techniques renseignes pour rendre le processus excutable applications/services du SI appeler pour raliser les activits, rgles de transformation, etc. il est possible de gnrer automatiquement, et de manire standard, le processus BPEL excuter par le moteur de processus.
9.1
Les bases de BPMN
BPMN permet partir dun nombre limit dlments de base simples de tracer la reprsentation graphique dun processus mtier. Les symboles de base sont de quatre types (cf. Figure 49) : les "couloirs" (Swimlanes) les "objets de flux" (Flow Objects) les "objets de relation" (Connectivity Objects) les "artfacts" (Artifacts). Les Swimlanes, sont utiliss pour organiser les responsabilits au sein de la ralisation du processus, en regroupant toutes les activits concernant un mme participant. Un processus est modlis en connectant entre eux des "Flow Objects" laide de "Connectivity Objects". Il y a trois types de "Flow Objects" : des "activits" (Activities) des "vnements" (Events) des "portes" (Gateways) Et de plus il existe trois types de "Connectivity Objects" : des flux squence (Sequence flow) des flux message (Message flow) des Associations (Association)
59 60
http://www.bpmn.org/ http://www.bpmn.org/BPMN_Supporters.htm
83/87
Figure 49
Symboles de base
61
Les Events se produisent lors de lexcution dun Processus et affecte son droulement, ils ont trois statuts : Evnement initiateur du Processus (Start Event) Evnement Intermdiaire de Processus (Intermediate Event) Evnement terminal du Processus (End Event) Exemples : arrive dun message, chance dun Timer, exception, compensation (permettant de revenir dans un tat antrieur), etc. Les Activities reprsentent des actions raliser, et peuvent-tre simples (Task) ou complexes (Process / Sub-Process). Les Gateways reprsentent des synchronisations et/ou des dcisions dans le droulement du Processus vers lesquels les flux convergent ou depuis ils divergent en une ou plusieurs branches. Une condition est associe un flux squence, si elle est value Vrai, la porte souvre Lordonnancement est donc dfini par les Sequence Flux reliant les Flow Objets. Les Message Flux, quant eux, relient entre eux des acteurs du Processus et prcisent les messages changs. Les Artifacts permettent dajouter des informations additionnelles dans la description du Processus. Ils sont particulirement utiliss pour dfinir les objets de donnes transitant entre les activits du processus.
9.2
Le contrle du flot
Les figures qui suivent montrent les diffrents types de contrle du flot dans les diagrammes de processus BPMN.
Pattern-based Analysis of BPMN - an extensive evaluation of the Control-flow, the Data and the Resource Perspectives - Petia Wohed1, Wil M.P. van der Aalst, Marlon Dumas Arthur H.M. ter Hofstede, Nick Russell
61
84/87
Figure 50
Contrle du flot
62
Figure 51
Choix multiple
63
, Pattern-based Analysis of BPMN - an extensive evaluation of the Control-flow, the Data and the Resource Perspectives - Petia Wohed1, Wil M.P. van der Aalst, Marlon Dumas Arthur H.M. ter Hofstede, Nick Russell
62 6
85/87
Figure 52
Merge synchronis
64
Figure 53
Choix diffrs
65
9.3
Les Exemples
Figure 54
Exemple simple dun systme dachat en ligne
66
, Pattern-based Analysis of BPMN - an extensive evaluation of the Control-flow, the Data and the Resource Perspectives - Petia Wohed1, Wil M.P. van der Aalst, Marlon Dumas Arthur H.M. ter Hofstede, Nick Russell
64 8
66
2005 JavaOneSM Conference | Session TS-7121
86/87
Lacheteur envoie un ordre dachat, le vendeur le rceptionne et lui fait un retour que reoit lacheteur. Lacheteur peut alors modifier son ordre, ce qui le ramne la phase initiale. lannuler, le vendeur reoit un message dannulation et envoi la confirmation, on sarrte l. le confirmer, le vendeur reoit un message de confirmation, fin de lchange.
Figure 55
Exemple simple dun systme denchres en ligne
67
On peut voir la case + dans un tche signe dun Sub-Process. Un cadran de montre aussi signe dun Timer et des Flows de Data Object.
Popkin BPMN and Business Process Management, An Introduction to the New Business Process Modeling Standard by Martin Owen and Jog Raj, Popkin Software2003, www.popkin.com.
67
87/87

LivreOrange SOA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LivreOrange SOA

Uploaded by

Copyright:

Available Formats

---

Urbanisation & Intgration de Systmes THINK SERVICE

Table des matires

Think Service en action .......................................................................................................15

2.2.1 2.2.2 2.2.3 2.2.4 2.2.5

3 VERS UN MODELE SAAS _________________________________________________ 26

3.6.1 3.6.2 3.6.3 3.6.4

Perspectives offertes par le modle SaaS...........................................................................35 Les composants ..................................................................................................................37

4 SOA ET OPEN-SOURCE : ETAT DES LIEUX ____________________________________ 37

Prsentation des solutions slectionnes............................................................................39

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5

4.3 5.1 5.2

5 UN RETOUR D'EXPERIENCE EN URBANISATION & SOA____________________________ 47

Couche daccs aux donnes (SDO) .......................................................................................... 50 Habilitations.................................................................................................................................. 51

Dmarche de ltude durbanisme .......................................................................................51 Dclinaison de la mthode sur un sous-ensemble du systme............................................51

5.4.1 5.4.2 5.4.3 5.4.4

5.5 6.1 6.2 6.3 6.4

6 RFLEXION SUR LA GOUVERNANCE SOA _____________________________________ 57

6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6

6.5 7.1 7.2 7.3

7 RETOUR D'EXPERIENCE EN URBANISATION & INTEGRATION ________________________ 68

7.4 8.1 8.2 9.1 9.2 9.3

8 ANNEXE : METMODELE POUR LAPPROCHE THINK SERVICE ________________________ 81

9 ANNEXE : APERU DE BPMN _____________________________________________ 83

Dfinition des concepts sous-tendant une SOA

Illustration dun processus mtier

Illustration dun service

Les principes dune SOA (Architecture applicative)

Mtamodle synthtique des composants d'une SOA

Principe dusage mixte SOA+EDA

Complment EDA au mtamodle SOA

ESB (Enterprise Service Bus)

Java Connector Architecture Java Messaging Service

Intgration de lESB dans les principes dune SOA

Les quatre niveaux darchitecture du SI pour une SOA

Think Service en action

Processus mtier BPMN

Exemple de modle synthtique des objets mtier

Ce sont les KPI (Key Performance Indicator)

Dcoupage du SI en blocs fonctionnels pour prparer la SOA

Processus mtier dtaill dans larchitecture fonctionnel

Exemple de pattern de service Donne

Architecture Applicative et technique

Mapping de lapplicatif existant sur larchitecture fonctionnelle

Architecture Applicative cible SOA

3 Vers un Modle SaaS

Gestion des processus

Couches constitutives dune application composite adoptant le style SOBA

Les applications composites

Composants constitutifs dune application composite

Les services mtier (Web services)

La gestion des processus

Voir galement lannexe 9

Web services Web services Web services

Chorgraphie Vs. Orchestration

Intgration de la couche graphique

Exemple dapplication composite

Gestion des processus

service de gestion des absences

service de gestion des contrats

service de stockage des donnes

Service de validation des donnes saisies

Application A annuaire LDAP

Application B Gestion Ressources Humaines