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 !

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…

13. Documentation collaborative
20/04/2012 13

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
easysoa-dev@googlegroups.com
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