SOA facile en 10 pratiques avec EasySOA - Alpes JUG
0 j'aime1,772 vues
Le document détaille des pratiques pour simplifier l'architecture orientée service (SOA) avec l'outil EasySOA, en mettant l'accent sur la découverte et l'audit des services, ainsi que la documentation collaborative. Il aborde également les défis de la gestion SOA dans des environnements complexes, notamment la nécessité d'assainir les services et de tester les API. EasySOA vise à rendre l'utilisation de SOA plus accessible et intégrée aux besoins métiers, tout en améliorant la collaboration entre les différents acteurs impliqués.
SOA facile en 10 pratiques avec EasySOA - Alpes JUG
- 1. SOA facile ! Pour le DSI et le développeur en 10 pratiques Outillées par Marc Dutoo, Open Wide 19/04/2012 1
- 2. A propos de l’intervenant Marc Dutoo • Leader EasySOA, responsable pôle R&D chez Open Wide • Expert SOA, BPM, ECM EasySOA • Simplifer SOA par le web et l’Open Source autour d’un registre et entrepôt de services collaboratif • Projet sur 2011-2012 - 4m€ - label System@tic • Dirigé par Open Wide, avec INRIA, Nuxeo, Talend, EasiFab, Bull Open Wide – architecte Open Source • ~ 90 employés sur Paris et Lyon, spin off de Thalès • Portail, gestion documentaire, Business Intelligence… 19/04/2012 2
- 3. I. Introduction II. Pratiques 1. Découverte et audit 2. Documentation collaborative 3. Assainissement SOA 4. Tests et simulation 5. Et au-delà… 19/04/2012 3
- 4. SOA, simple ? SOA est plus que jamais nécessaire • Cloud • Agilité et alignement de l’IT sur le métier • Mais aussi mobilité, Green IT... • … et va devoir passer à l’échelle ! Mais pour autant « simple » ?? • XML & SOAP hell • « solutions complètes / intégrées » vs overstandardization • Réunionite • … et pour vous ? 19/04/2012 4
- 5. Découverte et audit Pour le DSI • Pour gérer une SOA, il faut d’abord savoir quels services il y a ! • Visibilité, audit ; la liste des services et de leurs usages comme première métriques Pour le développeur • Pour utiliser un service, il faut d’abord le connaître ! • répondre une fois pour toute et de manière pratique à la question « où est ce WSDL / cet endpoint / cet échange etc. » – pour tous, tous les outils & cas d'usage, tous les projets – car il peut être dans les spécifications, à côté du source qu'il a généré, ou être généré lui-même au runtime par le moteur de services… – Pour éviter respectivement le WSDL "design-only" potentiellement 19/04/2012 obsolète, caché / non publié, ou autogénéré 5
- 6. Découverte et audit - comment Ce qui est à chercher • Endpoints : URLs, définition runtime – Les moteurs de service publient souvent une page avec des liens vers les WSDLs et endpoints de tous les services hébergés • Echanges : consommation / dépendance / référence – Par monitoring (ex. HTTP tunnel ou proxy) ou configuration / code • Configuration voire code : architecture technique – Par étude du source et notamment des fichiers de configuration : Spring / JEE CDI, EIP, définition de processus… • Spécifications métier : vue / processus / architecture métier – Par étude des spécifications, voire en versions formelles (Aris, UML) 19/04/2012 6
- 7. Découverte et audit - exemple 19/04/2012 7
- 8. Découverte et audit – avec EasySOA Découverte et enregistrement dans EasySOA • Endpoints : URLs, définition runtime – Découverte web : scraping des liens HTML vers des WSDLs… • Echanges : consommation / dépendance / référence – Découverte par monitoring des échanges HTTP (proxy) : SOAP, REST • Configuration voire code : architecture technique – Découverte par parsing dans les artefacts (SCA…), des artefacts par Maven ou à partir du classpath d’exécution… • Spécifications métier : vue / processus / architecture métier – Découverte par export depuis Eclipse SOA (BPMN…) • Tout ceci extensible ! Et aussi… – Accès aux infos découvertes universel par la GED, export bulk zip – Import depuis un registre / entrepôt / db / csv existant 19/04/2012 8
- 9. Découverte et audit – web, monitoring 20/04/2012 9
- 10. Documentation collaborative SOA est d'abord de la gestion d’informations! • (en plus de produire du code) • gérer la liste des services fournis / autorisés – à qui, en quelle version, sur quelle période (cycle de vie), avec quelles conditions et documentation d'usage – La versionner, la publier et la rendre accessible au plus prêt des acteurs • puis faciliter son évolution collaborative par les acteurs – Métier (!), architecte / développeur, également exploitants – Au-delà, pareil pour tout ce qui y est lié : besoins, spécifications, SLA… Pour le DSI : • gestion de ses assets, pérennisation, référence • source de métriques de sa SOA, communication ponctuelle ou flux d’information aux utilisateurs finaux (état des services) 19/04/2012 10
- 11. Documentation collaborative - 2 Pour le développeur : • avoir une référence : par exemple des WSDLs, pour éviter ou pallier à la redondance de WSDLs dans le source • et référencer côte à côte ses spécifications, endpoints, exemples, voire artifacts, tests... Pour tous : collaboration & communication ! • Pourquoi ? Comment impliquer les acteurs ? Quel workflow ? Voir présentation OpenWorldForum sur Slideshare Comment : outils • Du tableur (liste des services) & système de fichier partagé • En passant par SCM, wiki (« github ») • A gestion et portail documentaire 19/04/2012 11
- 12. Documentation collaborative – EasySOA Solution documentaire et collaborative pour le SOA • Basée sur la plateforme Nuxeo DM • Documents organisés selon un modèle SOA léger – Vues, recherche, contribution, workflow ; prévu : wiki – Commentaires, prévisualisation annotée, activité sociale, dashboard – Services publiés et documentés manuellement et automatiquement (apidoc) à l’aide des informations issues des découvertes • Ne remplace pas outils et applications de documentation de – conception, implémentation, exploitation, mais y lie ou s’y intégre • Intégration ouverte avec une gamme d’outils – Exemple : choisir le WSDL, plutôt que copier / coller son URL » Dans les outils embarqués (EasySOA Light) : service client… » dans les gammes d’outils intégrés : Eclipse SOA BPMN / 19/04/2012 12 Mangrove…
- 14. Assainissement - problème SOA se distingue par des responsabilités IT partitionnées • Entre plusieurs acteurs, chacun fournisseur de ses services • Les événements SOA sont donc transverses aux “Participants” – déploiement d’une nouvelle version d’un service ou d’une application, alerte d’exploitation, mais aussi décision à prendre, évolutions… Problème : • ce n’est pas le cadre de collaboration primaire de chacun des acteurs (leur propre département ou entreprise) – Pas les mêmes personnes, locaux, outils (y compris de collaboration) – Collaboration moins bien rodée, outillée, intégrée • Ce n’est pas l’usage primaire de leur application, qui est ses utilisateurs métier directs par le biais de sa propre UI 19/04/2012 14
- 15. Assainissement – cas concret • Donc plus difficile d’impliquer les autres acteurs si nécessaire • Et surtout, plus difficile d’en avoir le réflexe ! – Perte des alertes du niveau applicatif interne pouvant affecter la SOA : déploiement d’une nouvelle version d’une application, anticipation des pics d’usage, phasage… Un cas concret : • FlowerOrderService consomme CRMContactService, qui est exposé par le CRM dont l’usage primaire est pour les commerciaux par sa propre interface web • Une évolution du CRM peut casser l’intégration « en silence» : – Évolution du modèle du Contact, qui est directement exposé en service – La syntaxe ou sémantique change : contactId change de « 0x… » à « … » – Le comportement change, ex. les contacts peuvent être supprimés 19/04/2012 15
- 16. Assainissement - pourquoi Et SOA là-dedans ? N’est-il pas déjà la solution ? • Si le responsible SOA du CRM n’en dit rien, le responsable SOA de Flowers ne peut pas savoir que ça change ! • … dans la réalité, la gestion SOA est rarement parfaite – obtenir de son vis-à-vis, outre le respect des spécifications, un suivi des évolutions impactantes dans le temps est difficile, d’autant plus qu’elles ne concernent pas son application ni son coeur de métier • Il faudrait donc s’en passer ? – On peut l’outiller : registre collaboratif EasySOA Core, éventuellement aidé d’une supervision Jasmine. Mais oui… …Il faut supposer que la gestion SOA n’est pas parfaite ! • Il faut donc s’en protéger et l’assainir – détecter les changements d’API 19/04/2012 16
- 17. Assainissement - API Qu’est-ce qu’une API ? Une définition de service WSDL ! • Mais attention, il n’est pas suffisant, car : – Il peut être mal défini (tous les champs typés xs:string optionnels) => s’en protéger en le redéfinissant mieux et en le wrappant – Il gère peu syntaxe et sémantique (“0x…”) et pas comportements – REST est mieux (interface unifiée avec invariants), mais malgré tout • (bonus) en plus, le WSDL mélange tout – RPC, validation du flux côté client vs serveur, modèle de génération de code côté client et serveur, non fonctionnel… – Pour ceux qui ne veulent pas mélanger : utiliser un modèle plus souple tel REST, des services intermédiaires internes “proxy” pour séparer le non-fonctionnel et des briques plus spécifiques telles : » RxSchema pour la validation, » SPoRE dans le cas des clients REST scriptés, 19/04/2012 17 » Schematron pour les définitions clairsemées (sparse)…
- 18. Assainissement - principe • Des cas de données ou processus peuvent apparaître qui le prennent en défaut Solution : détecter les changements des APIs SOA • … une API est donc en fait garantie par l’ensemble couvrant des échanges qui l’utilisent dans une SOA – Ensemble par exemple issu d’un jeu de test couvrant, – d’une capture d’un scenario de test fonctionnel couvrant en recette – Tant que le scenario de test est couvrant et les echanges synchrones, une même API gardera la même “empreinte” Au-delà, de même pour garantir ses propres APIs • Comparaison de leur empreinte pour mesurer leur évolution • Validation par rapport aux APIs et tests mockés issus des specs 19/04/2012 18
- 19. Assainissement - comment Comment : “le BDD / CI du SOA” • Récupération et comparaison régulière des définitions (WSDL, WADL, voire JAXWS/RS) • Tests fonctionnels pour une API – Dans SOA complet (environnement d’intégration) ou simulé – Tests drivés depuis le frontend utilisateur (Selenium) ou des services intermédiaires, alimentés par des enregistrements (proxy HTTP, firebug, httpwatch ; ou SOAPUI) • Automatisés dans intégration continue (Jenkins / Hudson) Voire jusqu’à des tests de sécurité, performances… 19/04/2012 19
- 20. Assainissement – avec EasySOA Fonctionnement (à venir en 0.4) • Enregistrement d’une séance de découverte web par proxy, puis rejeu planifié de ces découvertes (brique HTTP Mining) • Comparaison du système découvert avec la version initiale publiée (interface Sanity Check Dashboard) et génération et mise à disposition d’un rapport Prévu : • intégration d’assertions sur tests outillés HTTP Mining, • voire de métriques d’exploitation SOA OW2 Jasmine 19/04/2012 20
- 21. Assainissement – dashboard, report UI 20/04/2012 21
- 22. Tests et simulation Créer des client et serveur de test • En utilisant les outils et modèles de programmation – classiques, ex. Java : junit, mockito, injection de services de test… – adapté aux échanges (en phase d’intégration au niveau de l’application ou de tout le système) : HTTP, SOAPUI, Citrus, RestFuse, FraSCAti… » Problème : les données variables (dates) => les fixer partout, ou ne faire que des vérifications partielles (patterns / contains) • On peut aussi s’en servir en TDD / BDD – développer d’abord des implémentations minimales validant les spécifications et leurs tests, les revalider sur l’implémentation finale • Si REST « pur » (pas de définition standard) : modéliser l’API – A la main d’après la doc en JAXRS, SPoRE / RxSchema… – Interactivement d’après exemples : REST Describe & Compile 19/04/2012 – D’après des échanges « live22 avec SOAPUI ; d’après des exemples, si »
- 23. Tests et simulation - 2 • Simuler un service – Car en test, appeler le « vrai » service (fourni par un autre acteur / participant au-dessus du Cloud, fut-ce pour le test) est une antipattern (sauf bien sûr pour l’intégration) – Utiliser son API (éventuellement modélisée) dans le langage / paradigme de programmation choisi – Ou bien enregistrer des échanges réels, fussent-ils eux-même générés par des tests, et les rendre propres et rejouables, voire les variabiliser (templates) pour pouvoir en simuler plusieurs usages » le meilleur client d'un service existant : son client métier naturel ! • SOAPUI – Test facile de services SOAP et REST : envoi de requêtes, réponses du serveur simulées voire scriptées, usage en HTTP proxy ou tunnel, CI… – Mais tout est sauvé dans un gros fichier de configuration XML, donc pas diffable, pas maintenable, pas partageable 19/04/2012 23
- 24. Tests et simulation - EasySOA HTTP Mining (sera dans 0.4) • valorisation et réutilisation des échanges existants • Enregistre les échanges HTTP – Format JSON issu de Firebug / HTTPWatch – par HTTP proxy ou tunnel à configurer côté client – Déployé dans Servlet, Filter, prévu : CXF / FraSCAti • Permet de les rejouer • Permet de jouer des échanges légèrement différents – En en générant des templates d’échanges, par heuristiques de correlation entre requête et réponse, ex. champs id ou query – ces templates sont modifiables, aujourd’hui dans le code (velocity) • d’exécuter des assertions sur les réponses – Contains, header / content assertions, champs XML ou json… 19/04/2012 24
- 25. Tests et simulation – EasySOA - 2 SOAPUI • Génération de configuration contenant tous les WSDLs d’une SOA ; prévu : réintégration versionnée après modifications Détection de changement d’API entre mocks et réel Modélisation d’API REST • Heuristiques : nombre d’appels d’un ordre de grandeur supérieur sur des nœuds « données » vs des nœuds « api » REST-iser un WSDL – le rendre navigable (pas fait): • Ou simplifier en divisant pour régner définition et données • En racine, afficher les résultats des opérations sans paramètres • Et pour tout résultat, proposer les opérations possibles 19/04/2012 – En correlant les types en entrées et sorties de toutes les opérations 25
- 26. Et au-delà… On peut faire du SOA avec les doigts ! • Il faut au moins connaître les enjeux et les risques • C’est mieux de s’équiper en conséquence • EasySOA veut apporter une réponse – Suffisamment générique pour HTTP et notamment Java – Intégrée avec une gamme de solutions : Talend, Jasmine, Eclipse SOA… Patterns EasySOA sur le site (à enrichir) • http://www.easysoa.org/the-box-o-patterns • http://www.easysoa.org/category/all/blog/pattern Merci de votre attention ! 19/04/2012 26
- 27. EasySOA – Get involved www.easysoa.org github.com/easysoa [email protected] 19/04/2012 27
- 28. BONUS 19/04/2012 28
- 29. EasySOA - Fiche d’identité Fiche d’identité EasySOA – 5 partenaires – budget : 4m€ sur 2 ans – Labellisé par System@tic – Et un objectif ambitieux… Rendre simples d’usage les Architectures Orientées Service (SOA), – Leur usage métier, leur développement, leur exploitation et supervision – Pour appuyer sur l’accélérateur du moteur SOA dans le Système d’Information de l’entreprise ! 19/04/2012 29
- 30. EasySOA – But 19/04/2012 30
- 31. EasySOA - But Le but : rajouter une couche SOA plus légère et agile autour du SOA “traditionnel” • Grâce à une approche en ligne, sociale et collaborative impliquant tous les acteurs du processus SOA : – utilisateurs métier, architectes et développeurs, exploitants • Permettant – La découverte ex nihilo des services existants, leur cartographie, leur documentation collaborative – L’assainissement et la protection des SOAs existantes, des développements en cours mais aussi vis-à-vis des SOAs consommées – Le prototypage rapide au-dessus des services et applications existantes, sans les impacter – La réutilisation des éléments produits (besoins, tests, mockup) pour 19/04/2012 faciliter la réimplémentation dans une plateforme SOA “classique” 31
- 32. EasySOA – Consortium Un consortium français de leaders de l’Open Source • INRIA labs : moteur de services (OW2 FraSCAti), modélisation SOA (Eclipse SOA) et monitoring (framework Galaxy, en sous-traitance par la startup EasiFab) • Talend (ETL) : connecteurs SOA et données aux données et solutions existantes, qu’elles soient métier ou SOA • Nuxeo (ECM) : plateforme de gestion de documents, pour gérer le modèle SOA et son contenu collaborativement • Bull (service et infrastructure) : administration et supervision du SOA avec OW2 Jasmine et un cas d’usage • Open Wide : coordinateur, architecture et intégration globale, BPM (avec Eclipse JWT / OW2 Scarbo), cas d’usage 32
- 33. EasySOA – le programme Compagnons Une approche proche du terrain, « guerilla » • pour faire émerger cas d’usage et besoins récurrents, autour du noyau projet, chez nous, nos clients, nos communautés • des personnes identifiées, qui nous font confiance, à qui nous demandons de partager leurs problématiques Le principe : un partage réciproque • Partagez vos problématiques avec nous, • Nous les analysons, puis enrichissons EasySOA (disponible en Open Source) pour adresser les plus prometteuses Ne payez que le spécifique • Si vous en voulez : installation et configuration, développements spécifiques 19/04/2012 33