• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SOA facile en 10 pratiques avec EasySOA - Alpes JUG
 

SOA facile en 10 pratiques avec EasySOA - Alpes JUG

on

  • 1,137 views

L'approche SOA (architectures orientées services) est partout dans les Systèmes d'Informations. Mais quel projet SOA ne s'est pas perdu dans le XML, les "solutions complètes" ou la ...

L'approche SOA (architectures orientées services) est partout dans les Systèmes d'Informations. Mais quel projet SOA ne s'est pas perdu dans le XML, les "solutions complètes" ou la réunion-ite...
Changeons donc d'angle d'attaque : échangeons nos pratiques !

Statistics

Views

Total Views
1,137
Views on SlideShare
1,136
Embed Views
1

Actions

Likes
1
Downloads
19
Comments
0

1 Embed 1

https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    SOA facile en 10 pratiques avec EasySOA - Alpes JUG SOA facile en 10 pratiques avec EasySOA - Alpes JUG Presentation Transcript

    • SOA facile ! Pour le DSI et le développeur en 10 pratiques Outillées par Marc Dutoo, Open Wide19/04/2012 1
    • A propos de l’intervenantMarc Dutoo • Leader EasySOA, responsable pôle R&D chez Open Wide • Expert SOA, BPM, ECMEasySOA • 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, BullOpen 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
    • 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
    • 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
    • Découverte et auditPour 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étriquesPour 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 dusage, tous les projets – car il peut être dans les spécifications, à côté du source quil 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" potentiellement19/04/2012 obsolète, caché / non publié, ou autogénéré 5
    • Découverte et audit - commentCe 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
    • Découverte et audit - exemple19/04/2012 7
    • Découverte et audit – avec EasySOADé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 existant19/04/2012 8
    • Découverte et audit – web, monitoring20/04/2012 9
    • Documentation collaborativeSOA est dabord 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 dusage – 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
    • Documentation collaborative - 2Pour 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 SlideshareComment : outils • Du tableur (liste des services) & système de fichier partagé • En passant par SCM, wiki (« github ») • A gestion et portail documentaire19/04/2012 11
    • Documentation collaborative – EasySOASolution 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…
    • Documentation collaborative20/04/2012 13
    • Assainissement - problèmeSOA 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 UI19/04/2012 14
    • 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és19/04/2012 15
    • Assainissement - pourquoiEt 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’API19/04/2012 16
    • Assainissement - APIQu’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)…
    • Assainissement - principe • Des cas de données ou processus peuvent apparaître qui le prennent en défautSolution : 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 specs19/04/2012 18
    • Assainissement - commentComment : “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
    • Assainissement – avec EasySOAFonctionnement (à 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 rapportPrévu : • intégration d’assertions sur tests outillés HTTP Mining, • voire de métriques d’exploitation SOA OW2 Jasmine19/04/2012 20
    • Assainissement – dashboard, report UI20/04/2012 21
    • Tests et simulationCré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 & Compile19/04/2012 – D’après des échanges « live22 avec SOAPUI ; d’après des exemples, si »
    • 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 dun 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 partageable19/04/2012 23
    • Tests et simulation - EasySOAHTTP 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
    • Tests et simulation – EasySOA - 2SOAPUI • Génération de configuration contenant tous les WSDLs d’une SOA ; prévu : réintégration versionnée après modificationsDétection de changement d’API entre mocks et réelModé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 possibles19/04/2012 – En correlant les types en entrées et sorties de toutes les opérations 25
    • 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
    • EasySOA – Get involved www.easysoa.org github.com/easysoa easysoa-dev@googlegroups.com19/04/2012 27
    • BONUS19/04/2012 28
    • 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
    • EasySOA – But19/04/2012 30
    • EasySOA - ButLe 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) pour19/04/2012 faciliter la réimplémentation dans une plateforme SOA “classique” 31
    • EasySOA – ConsortiumUn 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
    • EasySOA – le programme CompagnonsUne 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ématiquesLe 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 prometteusesNe payez que le spécifique • Si vous en voulez : installation et configuration, développements spécifiques19/04/2012 33