LivreOrange SOA

---

Urbanisation & Intgration de Systmes THINK SERVICE Valtech septembre 2007 Version 1.2

1/87 Valtech V1.2 - septembre 2007

Table des matires1 PREAMBULE ___________________________________________________________ 4 2 THINK SERVICE ________________________________________________________ 52.1 Dfinition des concepts sous-tendant une SOA.....................................................................5Processus 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 _________________________________________________ 263.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....................................................................................................29Modlisation 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 ................................................................33SOA 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 ..................................................................................................................37Interaction 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 ____________________________________ 374.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 .............................................................................47Principe de couplage faible.......................................................................................................... 49 2/87 Valtech V1.2 - septembre 2007

5 UN RETOUR D'EXPERIENCE EN URBANISATION & SOA____________________________ 475.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............................................51Architecture 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 .......................................................................................61Modle 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 .........................................................................................69Livrables....................................................................................................................................... 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 ________________________ 687.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


1 PrambuleCe 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 : [email protected]


2 Think ServiceLe 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.


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 Valtech V1.2 - septembre 2007

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)


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.

3


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.


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 composants10/87 Valtech V1.2 - septembre 2007

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


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 Valtech V1.2 - septembre 2007

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.

7

Le contrle des SLA est une des fonctionnalits pouvant tre offerte par un ESB


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 Valtech V1.2 - septembre 2007

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.

8


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.


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.

9

Ce sont les KPI (Key Performance Indicator)


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 interactions18/87 Valtech V1.2 - septembre 2007

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


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


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.


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 Valtech V1.2 - septembre 2007

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 Valtech V1.2 - septembre 2007

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.


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


3 Vers un Modle SaaSLe 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

3

Gestion des processus

2

Web services

Web services

Web services

Web services

Web services

1

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.


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 Valtech V1.2 - septembre 2007

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)


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


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.


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.


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.


Utilisateurs

Interface Utilisateur

Gestion des processus

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.


Portal QOS / Security / Management / Monitoring

Execution layer

SOA Metadata RepositoryUI Model Services Model Business Model

Organizational Model

Corporate ServicesFigure 22

Service MarketplacesArchitecture 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 Valtech V1.2 - septembre 2007

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).


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.

AgilitExternalisation 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.0Figure 23 Niveaux dimplmentation vers le modle SaaS 2.0


4 SOA et Open-Source : Etat des lieuxLessor 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 des37/87 Valtech V1.2 - septembre 2007

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


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 cet

LivreOrange SOA

Documents

Transcript of LivreOrange SOA