FICHE CONCEPT 03 ARCHITECTURE ORIENTEE SERVICE

Transcription

1 FICHE CONCEPT 03 ARCHITECTURE ORIENTEE SERVICE BIEN GERER SES REFERENTIELS DE DONNEES : UN ENJEU POUR MIEUX PILOTER LA PERFORMANCE DE SON ETABLISSEMENT Version 1.0 octobre 2008 GMSIH 44, Rue de Cambronne Paris. Tel : Fax :

2 Copyright 2008 GMSIH Permission vous est donnée de copier et distribuer ce document selon les termes de la Licence D-GMSIH, Version 2.0 ou ultérieure publiée par le GMSIH. Une copie de cette licence peut être consultée à l adresse : Versions du document : Date Version Commentaires Statut Octobre Publication de l étude Validé 08/10/08 2/11 P132_FConcept03_SOA_V1.0

3 Sommaire 1. Introduction Pourquoi les architectures orientées service? Qu est-ce que la SOA? Premières définitions Qu est-ce qu un service? Le Découpage modulaire L ESB (Enterprise Service Bus) Référentiels transverses : Applications composites : Urbanisation et SOA Orchestration de services Liste des Figures Figure 1 : La SOA s'articule autour de 3 grands rôles : le client, le fournisseur et l'annuaire des services Figure 2 : L'architecture de référence SOA... 7 Figure 3 : Un exemple de processus métier : Gestion d'une venue /10/08 3/11 P132_FConcept03_SOA_V1.0

4 1. INTRODUCTION Le système d information hospitalier (SIH) est aujourd hui largement plus complexe qu il y a 20 ans. En parallèle, les demandes d évolution s accélèrent : informatisation du circuit du médicament, mise en place du dossier patient partagé, serveur d identité, traçabilité, systèmes d information décisionnels, mise en place des réseaux de santé, etc. Les architectures orientées service (SOA pour Service Oriented Architecture) sont destinées à faire face à ces demandes d évolution. Elles s inscrivent dans l ensemble des solutions destinées à assurer l intégration entre les applications, et constituent en quelque sorte la cristallisation des bonnes pratiques en matière d urbanisation et d intégration du SIH. Au-delà des aspects technologiques qui sont décrits dans cette fiche, la SOA est une démarche qui s aligne sur les besoins métiers. L approche SOA permet de passer d une culture applicative à une culture tournée vers les processus et les services. 08/10/08 4/11 P132_FConcept03_SOA_V1.0

5 2. POURQUOI LES ARCHITECTURES ORIENTEES SERVICE? Les architectures orientées service s imposent aujourd hui pour les raisons suivantes : Leur mise en œuvre peut être progressive ; Les applications patrimoniales (legacy) peuvent être conservées en ajoutant une couche qui expose leur interface fonctionnelle de façon standard et facilement accessible ; Ce modèle d architecture, dans lequel une couche spécifique prend en charge la logique d intégration, est plus évolutif : on peut découpler les exigences d évolution les unes des autres. La maintenance est par conséquent facilitée ; La tolérance aux pannes est plus importante grâce au découplage : un service peut tomber en panne avec un impact minimal sur le SI.. Les autres fonctions sont faiblement couplées donc peu impactées. La possibilité de fonctionner de manière asynchrone autorise par exemple à attendre que le service soit redémarré pour terminer les tâches qui lui auront été demandées. Les interfaces sont standardisées et orientées métier, ce qui facilite leur (ré)utilisation ; l interopérabilité du SI est ainsi améliorée et il devient plus facile de l ouvrir à des partenaires externes. La mise en œuvre d une architecture orientée service contribue à "l intégration métier", c'est-à-dire à l implication grandissante des utilisateurs dans la conception et la construction du SIH et par conséquent à l alignement du SIH à la stratégie de l. Elles permettent d assurer la pérennité des solutions mises en œuvre, grâce au découplage et à l utilisation de standards largement adoptés Elles permettent donc de mieux répondre aux nouveaux besoins et exigences, de façon pragmatique, c'est-à-dire progressivement et sans remettre en cause l existant. 1 Avant la SOA le SI est : Après la SOA, le SI est en silos, hermétique, monolithique, fragile et vulnérable. partagé, collaboratif, inter opérable, intégré. 1 Source : site de Sun 08/10/08 5/11 P132_FConcept03_SOA_V1.0

6 3. QU EST-CE QUE LA SOA? 3.1 PREMIERES DEFINITIONS L approche SOA consiste à présenter les différentes fonctions et informations du SIH sous la forme de services, qui peuvent être utilisés de manière homogène grâce à des méthodes communes et standards. Figure 1 : La SOA s'articule autour de 3 grands rôles : le client, le fournisseur et l'annuaire des services. Une architecture SOA est caractérisée principalement par les concepts clés suivants : Le service : composant technique qui encapsule une ou plusieurs fonction(s) liés autour d'un objet pivot (ou métier), que l on peut interroger et qui renvoie une réponse ; Exemple : le service Rechercher Identité patient répond si oui ou non, l'identité du patient, fournie en paramètre d'entrée du service, est connue du SIH. La description des services : elle permet de préciser les paramètres utilisables lorsqu on sollicite un service et le format de la réponse ; Exemple : la description de la réponse fournie par le service Rechercher Identité patient est de type booléen. Les annuaires (registres) de services : un service est publié dans un registre afin de le rendre disponible et de permettre sa recherche ; Exemple : une application composite (voir explication plus loin) gérant les venues est composée du service Rechercher Identité patient Le couplage lâche : la méthodologie de construction d'une SOA permet à chaque bloc fonctionnel d'évoluer le plus indépendamment possible des autres blocs, conférant ainsi une agilité certaine au SIH. Les référentiels transverses : pour qu un service soit réutilisable, il faut que les messages qu il délivre soient compréhensibles de la façon la plus large possible. L utilisation de référentiels transverses est donc indispensable : par exemple, les notions d unité fonctionnelle ou d acte véhiculées dans un message doivent être compréhensibles de façon non ambiguë par tous les utilisateurs du service. 08/10/08 6/11 P132_FConcept03_SOA_V1.0

7 La mise en place d une architecture SOA s'appuie notamment sur : L utilisation de standards, Le découpage fonctionnel des services qui permet la réutilisation, La possibilité de fonctionner de manière asynchrone (découplage temporel), L'appel à un service sans en connaître sa localisation exacte, Les concepts de service, de description ou de registre de services ne sont pas nouveaux. La nouveauté réside dans la conception axée sur l interopérabilité et la réutilisation des services au travers de l adoption de standards de plus en plus nombreux : qui sont supportés en conséquence par les éditeurs dont la portée est démultipliée grâce à l extension des réseaux intra et extra entreprise dont Internet par exemple. Une définition précise du concept de SOA est malgré tout difficile : le concept est encore en cours de construction, les visions peuvent varier d un acteur à l autre, et les technologies et standards sont en voie de maturation. Quoiqu il en soit, l adoption des principes généraux SOA va grandissante car ils sont identifiés comme capables de mieux répondre aux problématiques de rigidité et de complexification des systèmes d information. Figure 2 : L'architecture de référence SOA 08/10/08 7/11 P132_FConcept03_SOA_V1.0

8 3.2 QU EST-CE QU UN SERVICE? Un service est un composant technique qui encapsule une ou plusieurs fonctions liées autour d'un objet pivot (ou métier), que l on peut interroger et qui renvoie une réponse. Dans une architecture SOA, on utilise des standards qui permettent de décrire le service, de le publier dans un registre, de l invoquer, d échanger des messages, etc. XML, HTTP, WSDL, UDDI ou SOAP sont des exemples de standards les plus connus. Le service permet de masquer au consommateur tous les aspects internes et de renvoyer de l information dans un langage transverse. La localisation du service est elle-même transparente à partir du moment où le service est disponible sur le réseau (annuaire). En revanche, il propose une interface connue et pérenne. Un service a une forte dimension métier et un propriétaire du service doit être désigné dans un domaine métier. Il sera responsable de la définition métier du service et de son évolution. La mise en œuvre d un service doit s attacher à gérer les problématiques : De sécurité, en autorisant ou non l accès à une fonctionnalité ou à des données, en cryptant les données, etc. La réutilisation des services implique une attention particulière à ce niveau. De transaction : les transactions distribuées doivent être possibles. Par exemple, la transaction "création d un nouveau professionnel de santé" doit mettre à jour des informations dans des bases RH, paie, gestion des patients, etc. De qualité de service : disponibilité, performance De cycle de vie : gestion des évolutions du service et de la mise en œuvre des nouvelles versions Ces problématiques sont en général formalisées dans un "contrat de service". Les Web Services constituent une catégorie particulière de services, qui respectent un certain nombre de standards tels que HTTP et XML. 3.3 LE DECOUPAGE MODULAIRE Une architecture orientée service est par définition modulaire : on ne conçoit plus les applications de façon monolithique, mais on les découpe en services réutilisables et "orchestrables". Une application est donc finalement un assemblage de services (une nouvelle notion apparaît alors : les mashup). La granularité d un service est une notion primordiale qui aura un impact sur ses performances, ses capacités de réutilisation, et sa valeur ajoutée métier. Si le niveau de détail est trop fin, il ne sera pas pertinent du point de vue métier et on devra assembler de trop nombreux services pour répondre à un besoin. 3.4 L ESB (ENTERPRISE SERVICE BUS) De façon très synthétique, le rôle de l ESB est d assurer la connexion et la médiation entre les services. Il permet, de plus, le suivi et la fiabilisation de l activité des services. On se reportera à la fiche concept EAI ESB afin de disposer d un niveau d information plus détaillé. 3.5 REFERENTIELS TRANSVERSES : Les services doivent être réutilisables. Les messages doivent donc s appuyer sur des référentiels transverses, compréhensibles par tous les utilisateurs du service. Des outils spécifiques permettent de gérer ces référentiels transverses (on parle d outils MDM pour Master Data Management). On se reportera à la fiche concept MDM pour plus d informations. 08/10/08 8/11 P132_FConcept03_SOA_V1.0

9 3.6 APPLICATIONS COMPOSITES : Une architecture SOA, grâce à l adoption généralisée de standards, permet de construire rapidement de nouvelles applications par agrégation de différents services ou processus. On parle d applications composites. 3.7 URBANISATION ET SOA L'urbanisation s'est longtemps vu opposer deux approches : La première, théorique, s'inscrivait dans une démarche de construction ex-nihilo en proposant d'aligner le SI sur le métier en partant de la définition des processus (approche "Top-down"). La seconde, pragmatique, proposait au contraire d'analyser l'existant pour en dégager les services à créer (approche "Bottom-Up"). Si, à ce jour, le débat autour de la meilleure approche d'urbanisation n'est pas clos, d'autres approches composites ont émergé tentant ainsi de les réconcilier. Le tableau ci-dessous compare les différentes approches de mise en place d'une SOA. Approche Description Avantages Inconvénients Top-Down Aligner le SI sur le métier de l entreprise en partant de la définition des processus métiers afin de définir les services nécessaires à la réalisation de ces processus (en commençant par la définition des services de plus au niveau, c est-à-dire offrant le plus de valeur ajoutée métier). La meilleure en théorie car elle permet de piloter la SOA par les besoins métiers, et minimise la redondance de services. Rarement possible car elle signifie une refonte de tout ou partie du SI, jugée bien souvent trop coûteuse et trop risquée. Elle rend difficile l adhésion à la démarche des équipes MOE. Bottom-Up Analyser l existant en déterminant les fonctions existantes du SI. Ainsi cartographiées, il est possible d identifier les fonctions du SI qui sont éligibles au rang de service. Elle précise une cartographie du SI qui, si elle est tenue à jour et publiée, facilitera la réutilisation de services. Elle semble moins coûteuse que la démarche Top-Down (attention néanmoins aux coûts de maintenance). Elle bloque le pilotage de la SOA par les besoins métiers et ne favorise pas la mise en place d un effort transverse et ne permet pas de sortir de la "culture projet" en silos. Elle rend très difficile la justification de l investissement auprès du métier (bénéfices visibles très tard). Elle se limite à une mise en mode service de fonctions existantes sur le SI et tend à reconduire une autre forme d architecture spaghetti. 08/10/08 9/11 P132_FConcept03_SOA_V1.0

10 Approche Description Avantages Inconvénients Outside In (Meet In The Middle) Mener en parallèle : un chantier Top-Down définissant les processus métiers, un chantier Bottom-Up afin de cartographier l existant. Elle réunit les bénéfices des approches Top-Down et Bottom-Up en permettant de piloter la SOA par les besoins métiers tout en facilitant la réutilisation de services et la capitalisation sur l existant. Difficile à mener car elle induit des risques d effet tunnel et nécessite une coordination étroite des chantiers Top-Down et Bottom-Up très en amont de sa réalisation. Une fois ces deux chantiers en phase finale, réconcilier les résultats des deux approches afin de déterminer comment seront réalisés les processus métiers en croisant les besoins en services et le patrimoine applicatif. Middle Out Commencer In the middle, c est-à-dire là où le métier et les IT parlent le même langage (ou presque). Une fois les différentes parties d accord sur un premier socle de services métiers nécessaires : la MOA engage un chantier Middle-Up pour spécifier les processus métiers. la MOE engage un chantier Middle Down pour spécifier le socle de services de plus bas niveau permettant la réalisation des services métiers. Elle fait la part belle au dialogue entre métier et IT et pose la compréhension mutuelle comme pré-requis à la mise en œuvre d une SOA. Demi-objectif car elle limite le pilotage de la SOA par les besoins métiers, puisque le point de départ est l identification des services métiers nécessaires et non la définition des processus réalisant le métier de l entreprise. 3.8 ORCHESTRATION DE SERVICES L'efficience et l'agilité, que peut offrir la SOA, dépendent de la capacité à modéliser les processus métier (voir approche d'urbanisation "Top-Down" décrite ci avant). Un processus métier est l'ensemble des activités que l' de santé doit mener pour répondre à un événement métier qui lui est adressé. 08/10/08 10/11 P132_FConcept03_SOA_V1.0

11 Figure 3 : Un exemple de processus métier : Gestion d'une venue Une architecture orientée service met à disposition, de façon standardisée, un ensemble de services donnant accès à des fonctions métier. Le processus métier est ainsi vu comme un chef d'orchestre enchaînant une suite d'appel de services métiers (voir figure : Un exemple de processus métier : ) Cette orchestration des services a donné lieu à différentes solutions logicielles complémentaires : BPM (Business Process Management ou en français Gestion des Processus Métier) dont le rôle est de gérer les processus, c'est-à-dire : modéliser les processus à l'aide de langages formels graphiques (BPMN pour Business Process Modeling Notation) ou non (BPEL4WS ou plus simplement BPEL pour Business Process Execution Language) 2, exécuter les processus à partir d'un moteur BPEL. BAM (Business Activity Monitoring ou en français Suivi de l'activité Métier) dont le rôle est de suivre, en temps réel, des processus permettant de répondre à des interrogations du type : "quels sont les temps de passage dans les différentes étapes d un processus de gestion des malades aux urgences?" par exemple. 2 Des détails supplémentaires sont donnés dans le glossaire. 08/10/08 11/11 P132_FConcept03_SOA_V1.0