SOA facile !Pour le DSI et le développeur

en 10 pratiquesOutillées par

Marc Dutoo, Open Wide

19/04/2012 1

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…219/04/2012

A propos de l’intervenant

19/04/2012 3

I. IntroductionII. Pratiques

1. Découverte et audit

2. Documentation collaborative

3. Assainissement SOA

4. Tests et simulation

5. Et au-delà…

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 ?419/04/2012

SOA, simple ?

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 commepremiè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 obsolète, caché / non publié, ou autogénéré

519/04/2012

Découverte et audit

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)

619/04/2012

Découverte et audit - comment

719/04/2012

Découverte et audit - exemple

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 existant819/04/2012

Découverte et audit – avec EasySOA

20/04/2012 9

Découverte et audit – web, monitoring

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)1019/04/2012

Documentation collaborative

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 documentaire1119/04/2012

Documentation collaborative - 2

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 / Mangrove… 1219/04/2012

Documentation collaborative – EasySOA

20/04/2012 13

Documentation collaborative

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 sesutilisateurs métier directs par le biais de sa propre UI

1419/04/2012

Assainissement - problème

• 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és1519/04/2012

Assainissement – cas concret

Et SOA là-dedans ? N’est-il pas déjà la solution ?

• Si le responsible SOA du CRM n’en dit rien, le responsableSOA 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 plusqu’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

1619/04/2012

Assainissement - pourquoi

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,

» Schematron pour les définitions clairsemées (sparse)…1719/04/2012

Assainissement - API

• 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 couvrantdes é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

1819/04/2012

Assainissement - principe

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…

1919/04/2012

Assainissement - comment

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 initialepublié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

2019/04/2012

Assainissement – avec EasySOA

2120/04/2012

Assainissement – dashboard, report UI

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

– D’après des échanges « live » avec SOAPUI ; d’après des exemples, si c’est du XML, avec XMLBeans

2219/04/2012

Tests et simulation

• 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

2319/04/2012

Tests et simulation - 2

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…

• Et de simuler des services à l’aide de ces mêmes templates2419/04/2012

Tests et simulation - EasySOA

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– En correlant les types en entrées et sorties de toutes les opérations2519/04/2012

Tests et simulation – EasySOA - 2

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 !

2619/04/2012

Et au-delà…

27

www.easysoa.org

github.com/easysoa

easysoa-dev@googlegroups.com

19/04/2012

EasySOA – Get involved

2819/04/2012

BONUS

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 !

29

EasySOA - Fiche d’identité

19/04/2012

30

EasySOA – But

19/04/2012

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 faciliter la réimplémentation dans une plateforme SOA “classique”

3119/04/2012

EasySOA - But

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

EasySOA – Consortium

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

3319/04/2012

EasySOA – le programme Compagnons