Cadres pour la conception d une SOA Module BPM & SOA SI5/Master IFI Extraits des meilleures pratiques Softeam et de la méthode Praxème Merci à Fabien Villard - 1 -
Conception SOA : Etapes, méthodes - 2 -
Phase d'urbanisation Deux phases de conception Une première phase doit SOAisé progressivement l existant L'ensemble du SI est urbanisé en s'appuyant sur la cartographie des domaines métiers de l'entreprise et sur le code existant Réalisation incrémentale basée sur un modèle de maturité Phase post-urbanisation Au démarrage de chaque nouveau projet, il est nécessaire de s'appuyer sur les processus et services répertoriés précédemment afin d étendre correctement l architecture mise en place Abandon de la vision «projet» au profit de la vision d entreprise - 3 -
Exemple de modèle de maturité SOA (OMG) La maturité d'une organisation est le degré auquel celle-ci a déployé explicitement et de façon cohérente des processus documentés, gérés, mesurés, contrôlés et continuellement améliorés (modèle de référence CMMI : Capability Maturity Model + Integration) Un modèle de maturité SOA fournit des objectifs et des conseils sur la façon de mettre en place progressivement l architecture source : http://soa.omg.org/uploaded%20docs/soa/soa_maturity.pdf - 4 -
La gouvernance en quelques questions Qui définit et modifie les services? Qui peut y accéder? Quelle est la qualité de service offerte? Qui paie pour ces services? Qui est responsable de l infrastructure? Comment empêcher la duplication de services? Comment exposer les services aux entreprises partenaires? Quand et comment passer au niveau de maturité supérieur? - 5 -
Gouvernance et organisation Analyste métier Architecte Définit les processus métiers et les KPI associées Identification des services métier Optimise les processus via la simulation Assemble les services Tout ce monde est en interaction avec le comité Intégrateur de pilotage et le centre de compétences qui assurent la gouvernance SOA Publie les services Gère le cycle de vie des services Contrôle la qualité de service Définit les services pour les use cases Modélise les services Implémente les services Gestionnaire Développeur - 6 -
Conception et cadre de travail Les ateliers de modélisation (Rational Software Architect, Modelio, MagicDraw, Poséidon, Together,...) fixent une partie des questions de forme Mais pas de réponse aux questions de définition des modèles, de qualité, d organisation du travail, etc boîte à outils dont il nous manque le mode d emploi Utilisation de bonnes pratiques pour guider les décisions Utilisation de méthode pour ne pas ré-inventer systématiquement les façons de faire Répondre à la question «comment nous y prendre?» Garantir que la chose produite respecte les besoins et contraintes exprimés initialement - 7 -
Problèmes rencontrés sans cadre de travail Accumulation anarchique de services non réutilisables ou redondants mauvaises pratiques d identification des services Incohérence d alignement métier/si Les services exposés par les applications ne permettent pas d exécuter le processus métier ou de le rendre agile Incapacité à évaluer la pertinence du resultat Difficultés à articuler toutes les compétences impliquées par le développement d'une architecture orientée services Pas de répétabilité ni de traçabilité - 8 -
Méthodes de conception SOA Praxeme (Unilog Management et Orchestra Networks) SOMA (IBM) Méthode De Gamma + les méthodes maison + toutes les formations proposées par les éditeurs tels que Softeam (SEA), DreamSoft, etc sur leur savoir-faire Autant d offres que de méthodes différentes! - 9 -
Points d entrée et approches de conception 3 points d entrée Démarche orientée métier (cartographie des processus) Démarche orientée applications (cartographie des échanges de flux inter applicatifs) Démarche orientée données (cartographie des référentiels) Points d entrée non exclusifs Approche itérative et par rapprochements Approche bottom-up Déduire la conception SOA par la synthèse de l existant technique Facilite l intégration et la réutilisation de l existant Approche top-down Réaliser la conception SOA par la décomposition des objectifs métier Garantit la forte valeur métier des services - 10 -
Identification des services : quelques bonnes pratiques - 11 -
Rappel sur les services & composants Un service est l unité de construction/réutilisation par laquelle le système fournit une réponse à un besoin d information, d action ou de transformation une fonction du SI rendue publique, disponible et invocable par une interface (contrat) pour être mutualisée ou orchestrée Un service doit garantir une qualité de service associée Un composant est un fournisseur/consommateur de services - 12 -
Quid de l identification des services Un des problèmes centraux pour mettre en œuvre une SOA La granularité des services est fondamentale détermine en grande partie la réutilisabilité des services Or le succès SOA dépend en partie du % de réutilisation des services Éviter une granularité trop fine qui entraîne : beaucoup d interactions des problèmes de performance On recommande des services à gros grain attention à une granularité trop épaisse un service qui fait trop de choses (perimètre fonctionnel étendu), risque de ne pas être réutilisable Trouver le juste milieu - 13 -
Quid de l identification des services Pour obtenir une granularité pertinente des services, il est nécessaire de : Faire décomposition Top-down Faire la synthèse Buttom-up Comparer les services remontés avec ceux descendus Faire les compromis nécessaires pour réutiliser le maximum de code en sacrifiant au minimum la valeur ajoutée métier - 14 -
Quid de l identification des services Les services identifiés ne doivent pas être tous publiés : Chaque service a un coût Il faut éviter la prolifération des services Par exemple le Service Litmus Test d'ibm aide à trouver les bons services à exposer grace à certains critères Candidate Services Business Alignment Composability Externalized Service Description Redundancy Elimination SLT Services (exposed) - 15 -
Quelques critères d' exposabilité Le potentiel d'un service est d'autant plus important qu'il : permet d'automatiser un processus métier critique est réutilisable par plusieurs domaines métiers supporte des besoins non fonctionnels (sécurité, logging, monitoring,...) Les services non exposés ne sont pas jetés! - 16 -
Isomorphisme du processus 1 tâche = 1 service Facilite l alignement métier/it et donc l agilité métier Rend plus difficile l intégration de l existant - 17 -
Services : verbes ou noms? Service en tant que nom requête de création d une nouvelle police d assurance requête d approbation de la police n 222 Policy Service réponse avec le n de police 222 réponse succès/échec interface au sens de la POO Service en tant que verbe requête de création d une nouvelle police d assurance CreateNewPolicy Service réponse avec le n de police 222 requête d approbation de la police n 222 ApprovePolicy Service réponse succès/échec philosophie SO source : http://www.zapthink.com/ - 18 -
Services : verbes ou noms? Les services «entités» permettent de faire le lien avec l existant (code objet, BD) Les services «taches» supportent les processus métier et les rendent flexibles (isomorphisme) Les deux types de services sont utiles! Legacy source : http://www.zapthink.com/ - 19 -
Identification des services : La méthode Praxème - 20 -
Choix de la méthode Doit être suffisamment répandue pour servir de référence commune aux différents acteurs des projets (internes ET externes) : Pour une entreprise, il n est pas envisageable d adopter des cadres méthodologiques différents selon les prestataires retenus Il n est pas raisonnable non plus qu une entreprise finance la formation lourde de ses prestataires, pour qu ils puissent se couler dans son propre cadre propriétaire Découverte d une méthode publique : Praxeme - 21 -
L'approche Praxeme en deux mots Plusieurs sociétés (Sagem, SMABTP, ) à l'origine de cette démarche Propriété du Praxeme Institute (association créée en 2006) mais diffusion publique Objectifs de l'approche Supporter les problématiques des divers intervenants Offrir des représentations adaptées à chaque acteur Assurer une continuité entre équipes métier et techniques Supporter la cartographie applicative Assurer la traçabilité entre les modèles Différents aspects pour traiter toutes les dimensions de l'entreprise Séparation des préoccupations & liens entre elles - 22 -
Les aspects Praxeme - 23 -
Principales activités liées à la méthode Analyse des objectifs, des règles métier, de l existant Définition du cadre métier Définition du savoir faire de l entreprise en particulier les processus et cas d utilisation Déduction de l architecture logique et accostage avec l existant decouverte des composants et des services à ce stade Passage du logique au technique ex : fédération d ESB, Progressivité & continuité : Nécessité de partir d un sous ensemble pour améliorer selon les priorités (c) 2011-2012, Occello Audrey, module SOA - 24 -
Objectifs de l'analyse Aspect intentionnel Collecter les information disponibles Structurer ces informations Commencer à découvrir les éléments importants Sert à fixer la cible de la transformation/conception et à la redéfinir progressivement en fonction des avancées - 25 -
Aspect Sémantique Détecter les vrais objets métier Ceux qui ne dépendent que du métier pratiqué et pas de la façon dont il est pratiqué Les objets métier servent donc de socle naturel au reste de la conception - 26 -
Aspect Sémantique : Extrait de l etude de cas - 27 -
Aspect pragmatique Les orchestrations des cas d'utilisation se fait grâce au cycle de vie de les objets métier principaux Permet de trouver le bon gabarit pour les processus! La séparation temporaire du savoir et des savoir-faire permet de remettre ces derniers en cause sans impacter les premiers - 28 -
Réunion de l'ensemble de la réalité perçue dans les modèles amont Architecture du système Aspect logique Modèle pivot entre modèles amont et modèles techniques : Limitation des impacts entre les deux cycles de vie! - 29 -
Construction du modèle logique SOA Règles de dérivation spécifique au style d architecture choisi (fonctionnel, SOA, REST, agents, ) Dérivations SOA à partir du sémantique La dérivation de chaque classe produit un composant La dérivation de chaque opération publique de classe/transitions d'états produit un service Dérivations SOA à partir du pragmatique La dérivation de chaque cas d utilisation/couloirs de processus produit un composant La dérivation de chaque activité produit un service La dérivation répond à la question : quels sont les bons services? Par production automatisable Avec rigueur et répétabilité - 30 -
Gestion de la communication entre les couches - 31 -
Orchestration versus propagation des services Réduire la propagation et lui substituer l orchestration Mais arbitrer entre : préserver la logique métier, d un côté simplifier la structure du système, de l autre Assemblages de composants / interaction objets Workflows/ Orchestrations - 32 -
Périmètre des composants, catégories & stabilité Les couches logiques de stabilité croissante établissent la règle de base de dépendance accès polarisé (couches supérieures vers inférieures) Ex : un composant Entité ne doit pas utiliser un composant Fonction ou Processus - 33 -
Périmètre des composants, catégories & stabilité Les couches logiques de stabilité croissante établissent la règle de base de dépendance accès polarisé (couches supérieures vers inférieures) Ex : un composant Entité ne doit pas utiliser un composant Fonction ou Processus Démarche orientée métier Démarche orientée application Démarche orientée donnée - 34 -
Notations pour la modélisation des applications Modélisation des applications orientées objets UML 1.X Diagrammes statiques (cas d'utilisation, classes, ) Diagrammes dynamiques (séquence, état-transition, ) Modélisation des applications à base de composants UML 2.0 Ajout de la modélisation des composants comme des entités de première classe Modélisation des applications SOA Modélisation des processus métier et des services Diagramme BPMN supporté par la majorité des modeleurs Nouveau standard de l OMG SoaML, extension de UML pour les architectures orientées services, en cours d intégration dans la plupart des modeleurs - 35 -
Quelques références... Méthode publique Praxeme http://www.praxeme.org/ Meilleures pratiques Softeam http://www.slideshare.net/zubin67/soa-architecture-logique SOA anti-patterns http://www.infoq.com/articles/soa-anti-patterns Portail OMG dédié à la modélisation SOA http://soa.omg.org/ Voir la bibliographie complète sur le site web du module - 36 -