E-Budget vers une Architecture Orientée Service

1. E-Budget vers une Architecture Orientée Service Présentation du rapport pour l’avancement au grade d’ingénieur en chef Par : Touzani Samir, Ingénieur d’état grade principal MEF\DB\DB2\DSI\SDSM

2. Objectifs et Contexte • Objectifs : • Vulgariser SOA • Proposer une solution SOA pour doper l’agilité du système e-Budget • Contexte : • Evolution du système e-Budget • L’agilité d’e-Budget, enjeu majeur pour la DB

3. Plan • Introduction Générale à SOA • Les Technologies SOA • Principes de construction de services autonomes et combinés • Présentation du Système e-Budget • Le système e-Budget face aux changements métiers • Transformation d’e-Budget vers SOA • Facteurs clés pour une migration réussie vers SOA

4. INTRODUCTION GENERALE A SOA • Le Concept SOA : Définitions, Acteurs, Composants et Cycle de vie • Urbanisation des systèmesavecSOA: EA, Approches et gouvernance SOA • Enjeux métiers deSOA : Agilité, Processus collaboratifs B2B et pilotage des processus métiers • Avantages métiers, économiques, techniques et organisationnelles de SOA

5. Concept SOA : Définitions • Définition primitive Registre de services Contrat de service Recherche 2 3 Sollicite 1 Enregistre Consommateur Fournisseur 5 Envoie la réponse 4 Exécute

6. Concept SOA : Définitions avancées • Définition Avancée (1) • SOA se définie de deux points de vues: Métier et SI. • Du Point de vue Métier : Processus Métiers Services fournis par le SI local Services externes fournis par des systèmes Géographiquement Distants et de plateformes hétérogènes Application Application Base de données

7. Concept SOA : Définitions avancées • Définition Avancée (2) • Du Point de vue SI : c’est un ensemble de motifs de conception et d’implémentation permettant de conférer aux applications existantes certaines caractéristiques • Synthèse des deux définitions • SOA est une démarche particulière d’urbanisation de SI puisqu’elle permet de rationaliser celui ci et de le rendre plus agile face aux exigences métiers. Néanmoins, la particularité de la démarche SOA par rapport aux autres méthodologies d’urbanisation réside dans la notion de « service » qui en constitue une caractéristique déterminante.

8. Concept SOA : Composants de SOA • Topologie de SOA : Contrôle : BSC, KPIs, BAM, SLA, QoS… Fournisseur : Application1, Service1 Contrat1 Médiateur : Proxy, Registre, Annuaire, ESB, ISB… Consommateur: Application, service Contrat2 Fournisseur : Application1, Service2

9. Concept SOA : Cycle de Vie SOA • Stratégie d’Adoption • Déterminer les KPIs et la BSC cibles de l’entreprise ainsi que l’envergure de la transformation • Gouvernance • Déterminer les structures et les modalités de gestion et de contrôle • Cycle de vie des services • Développer, tester, déployer, gérer, utiliser, analyser

10. Urbanisation des systèmes et SOA : Architecture d’Entreprise (EA)

11. Urbanisation des systèmes et SOA : Urbanisation, EA et SOA Urbanisation de Systèmes EA SOA

12. Urbanisation des systèmes et SOA :Approches et Gouvernance SOA • Approche Top Down:

13. Enjeux Métiers et Avantages de SOA:Agilité, B2B et BPM • Enjeux Métiers • Agilité • B2B • BPM • Avantages • Métiers • Economiques • Techniques • Organisationnels

14. Les Technologies SOA • Les services Web:Standards, Avantages et limitations • Technologies Avancées pour SOA: 1- Composants Fournisseurs: Technologie WCF de Microsoft, Le modèle SCA, 2- Composants Médiateurs ESB : Structure, Fonctionnalités 3- Composants Consommateurs : Consommation par code et par orchestrations 4- Composants de gestion et de contrôle: Registre SOA, Superviseur SOA

15. Les Services Web: Standards

16. Technologies Avancées pour SOA:les Composants Fournisseurs • La technologie WCF : • Technologie Microsoft apparue en 2003 basée sur .Net Framework • Flexibilité par rapport aux protocoles de transports • Permet d’avoir différents niveaux de service • Modèle service : Adresse, Binding et Contrat • Le modèle SCA: • Modèle issu du monde Open Source (OSAO) en réponse à WCF • Modèle d’assemblage : structure d’une application composite • Modèle de programmation : comment développer des services • Modèle de gestion : ajouter de l’infrastructure aux services

17. Technologies Avancées pour SOA:Composant Médiateur ESB

18. Technologies Avancées pour SOA:Composant Médiateur ESB • ESB JBI • Certifiés JBI: ServiceMix, PEtALS, Open ESB • Compatibles JBI : Mule, Sonic ESB, Artix… • ESB Non JBI • Solutions Oracle : ALSB, OSB • BizTalk de Microsoft • ….

19. Technologies Avancées pour SOA:Composant Consommateur • Solutions de consommation dans le code: • Java: Axis , utilitaire WSDL2Java • .Net : génération à partir l’IDE • PHP : pas de processeur SOAP donc nécéssite des fonctionnalités externes nuSAOP, pear SOAP • Solutions d’orchestration: • Oracle BPEL • Biz Talk • IBM WebSphere Process Choreographer

20. Technologies Avancées pour SOA:Composants de gestion et de contrôle • Registre SOA: • Publication recherche et découverte de services • Collection et gestion des données sur les services • Gouvernance de l’utilisation des services • BEA AquaLogic Registry Repository, Sun Service Registry, IBM WebSphere Service Registry • Superviseur SOA: • Supervision des activités métiers • Supervision des services • Supervision des données et des flux • Tivoli composite application manager for SOA d’IBM, Galaxy de Mule Source …

21. Principes de construction de services autonomes et combinés • Introduction : Insuffisances de l’AOO par rapport à SOA • Le service brique fondamentale de SOA: 1- Propriétés : Frontières, Contrat, Autonomie, Compatibilité 2- types de services : Atomiques, Composites et Collaboratifs 3- Construction et versionning : Création, Enregistrement et versionning

22. Introduction:l’OO par rapport à SOA • Insuffisances de l’OO par rapport à SOA • Ne prévoit pas la stabilité des interfaces des services existants • Limitée à des cas d’usage prédéterminés, mais pas SOA • Pas de notion de SLA • Pas de concepts d’agencements de services • SOA permet le fonctionnement de plusieurs versions d’un service, donc intègre le changement

23. Le service brique fondamentale de SOA:Propriétés et Types de services • Propriétés: • Frontière • Contrat • Autonomie • Compatibilité • Types de services: • Atomique • Composite • Collaboratif

24. Le service brique fondamentale de SOA:Construction et versionning • Création: • Enregistrement • Versionning

25. Présentation du système e-Budget • Périmètre fonctionnel d’e-Budget • Caractéristiques techniques

26. Fonctions et Caractéristiques techniques • Périmètre Fonctionnel : • Elaboration des Morasses Budgétaires, gestion des mouvements de crédits, prises en charge du référentiel budgétaire, prise en charge des tableaux d’indicateurs, élaboration des budget et des programmes SEGMA et CST, gestion des tableaux des effectifs et des mouvements de postes budgétaires,…etc. • Caractéristiques techniques: • Technologie .Net, et SQL Server • Architecture en couches • Séparation d’aspects métiers et techniques • Gestion de configuration

27. Le système e-Budget face aux changements • Principales réformes • Motivation de la transformation d’ e-Budget vers SOA par les changements

28. Principales Réformes • Gestion axée sur les résultats • Déconcentration administrative • Programmation multi annuelle CDMT • Introduction de la dimension genre • Réforme de la nomenclature • …

29. Motivation de la transformation d’ e-Budget vers SOA par les changements • Analyse du coût de changement : Changement Nouvelle configuration de déploiement Duplication de composants Modifications à porter sur plusieurs endroits Coût de maintenance élevé • Avec SOA: Changement Nouvelle configuration de déploiement composants réutilisés à distances Modifications à porter Sur un seul endroit Coût de maintenance moins élevé

30. Motivation de la transformation d’ e-Budget vers SOA par les changements • Exemple : service Windows pour la validation et le chargement de données budgétaires Machine 1 Machine 2 Service Windows Interfaces e-Budget Sans SOA Composants Métiers et technique Composants Métiers et technique Redondance de composants Machine 2 Machine 1 Interfaces e-Budget Avec SOA Service Windows Composants Métiers et technique Service Appel SOA

31. Transformation du système e-Budget vers SOA • Analyse détaillée du système (AsIs): Limitations de l’architecture d’e-Budget, Faisabilité, envergure et risque de la migration vers SOA, • Définition de l’architecture SOA cible du système e-Budget (ToBe) • Urbanisation du système e-Budget avec SOA (Plan de transition)

32. Analyse détaillée du système (AsIs):Limitations de l’architecture d’e-Budget • Nombre croissant de fonctions : risque de duplication de fonctionnalités élémentaires • Pas de possibilités d’échanges B2B avec les partenaires de la DB • Chaque changement métier induit un nouveau cycle de développement : risque d’explosion de coût

33. Analyse détaillée du système (AsIs):Faisabilité, risque et envergure de la migration • Faisabilité: • Architecture en composant: favorise la stabilité et la composition des services • Plate forme technologique (.Net) offre la possibilité de créer différent types de services • Envergure du développement SOA: • Couches services destinées aux développeurs • Couche service destinée aux analystes, aux programmes internes et externes à la DB • Risque de la migration vers SOA: • Sécurité • Nombre important de services • Non sauvegarde des acquis du système e-Budget

34. Définition de l’architecture SOA cible du système e-Budget (ToBe) • Fonctionnalités exposées en services : • Services métiers transverses et réutilisables localement, à distance et sous n’importe quelle plate forme • Fonctionnalités métiers flexibles • Services avec des niveaux SLA adaptées • Architecture distribuée du système e-Budget: • Configuration optimale et non duplication de composants • Cohabitation de plusieurs versions d’un service • Composants d’infrastructure accessibles via des services

35. Urbanisation du système e-Budget avec SOA (Plan de transition) • Implémentation des nouvelles réformes avec une approche Top Down : • Couche métier cible • Couches applications et données cibles • Plan de transition • Développement • Cohabitation avec les fonctions existantes d’e-Budget: • Garantir une transparence totale vis-à-vis les utilisateurs • A terme, le système sera transformé en totalité vers SOA

36. Urbanisation du système e-Budget avec SOA (Plan de transition) • Transformation des services d’infrastructure vers SOA • Services d’authentification, d’autorisation et de journalisation • Choix Technologiques • Technologie WCF : cohabitation avec la version actuelle d’e-Budget, niveaux SLA adaptés • Preuve de concept • Développement de services Web au sein d’e-Budget et leur utilisation dans MS Office

37. Facteurs Clés pour réussir une migration vers une architecture SOA • Analyser et cartographier l’existant SI • Penser en projet transverse • Penser Métier • Sensibiliser • Bien définir la granularité des services • Considérer différents niveaux SLA • Prévoir le monitoring de SOA

38. Facteurs Clés • Analyser et cartographier l’existant SI • Penser en projet transverse • Penser Métier • Sensibiliser • Procéder par itération • Bien définir la granularité des services • Considérer différents niveaux SLA • Prévoir le monitoring de SOA

39. Q & A