Laurent Broudoux présente une approche pour l'intégration d'applications au sein du groupe Covéa, soulignant l'importance d'un Enterprise Service Bus (ESB) léger et adaptable en utilisant Apache Camel et JBoss Fuse. Il met en évidence les limites des notations UML pour spécifier des comportements d'intégration et propose l'utilisation des Enterprise Integration Patterns (EIP) pour cette tâche, en développant un outil pour faciliter cette spécification. Ce document aborde également la transition vers une architecture orientée domaine, visant à améliorer la cohérence et réduire le couplage entre les différents systèmes.

1. Spécification par les EIP
Une passerelle entre EA et Développement ?
Laurent Broudoux
Architecte Technique - Groupe Covéa
23 Mars 2016

2. Qui suis-je ?
Laurent Broudoux
Le jour …
Architecte IT Senior chez Covéa
Mots-clés : EA, SOA, Modeling, Java, Agile, Software factories
La nuit …
Coder, geek, open source committer (http://github.com/lbroudoux)
Me joindre / suivre
@lbroudoux
laurent.broudoux@gmail.com
http://lbroudoux.wordpress.com

3. Groupe Covéa
1 groupe
3 marques
Afin de profiter pleinement des bénéfices
de l’effet de groupe, les mutuelles MAAF,
GMF et MMA ont confié à Covéa la
coordination du pilotage stratégique de
l’ensemble économique constitué des
enseignes et de leurs filiales communes.
16,5 milliards € CA (IARD et Vie)
+11 millions sociétaires
+26300 collaborateurs

4. Enterprise Integration

5. Clients
Contexte Covéa
L’ESB n’est pas un nouveau composant !
- Chaque marque possède son propre Bus
- selon une approche monolithique
Usages Médiation Cœur Métier
Portail
X
Portail
Y
App Z
Comp
A
Comp B
Comp
C
IARD
Sin.
Vie
Workflow
- Une rupture forte entre le Cœur Métier et la
SOA (technologie => responsabilité)
- Un risque de dérive vers les Usages pour les
composants de Médiation

6. Contexte Covéa
Une transition vers SI convergé, orienté Domaine
- Vers une architecture de domaine hexagonale
- Une couche Exposition & Orchestration + ou – importante
Sin.
Clients
IARD
Vie
Usages
E&O
Cœur
Métier
Domaine X
Un mot d’ordre : « Cohérence forte, couplage
lâche » des domaines
Besoin d’un ESB léger, adaptable et en proximité
avec les technos Cœur Métier cibles ;
d’où notre choix Apache Camel / JBoss Fuse !

7. Comment spécifier
le comportement de l’intégration ?
? ??
??
?
?

8. UML ?

9. UML peut faire mal…
Des manques ou limites importants dans le
contexte de l’intégration :
-La possibilité de qualifier un traitement
(Transformation de données ? Filtre ?
Eclatement / Agrégation ?),
-La lisibilité réduite lorsqu’on augmente le
nombres de partenaires,
-L’accessibilité. Qui comprend ces
notations en dehors d’un Architecte ??

10. Des alternatives ?
BPMN ?
OK pour montrer options, séquencement et parallélisme.
KO pour qualifier les typologies de traitement à mettre en œuvre
Visio ou PowerPoint ?
OK à condition d’avoir défini son propre formalisme
Difficilement partageable (pensez prestation …)
Non exploitable
Word ?
Ambigüe
Non exploitable

11. Orientation Covéa :
Les Enterprise Integration Patterns
Gregor Hohpe & Bobby Woolf en 2003
65 patterns pour décrire des problèmes récurrents

12. Support d’EIP dans la pratique
Un « standard de fait » supporté par les vendeurs majeurs
- Un mapping peu explicite sinon
…
- Toujours un lien fort avec le code
source !
- Des implémentations natives :
Apache Camel et Red Hat JBoss
Fuse

13. Nos besoins
Un outil simple, indépendant d’un vendeur pour spécifier
le comportement d’une intégration en utilisant les
patterns EIP,
Un outil utilisable par les experts en proximité des
métiers, compréhensible par tous.

14. Mais …
designer for EIP
designer for EIP
EIP n’est pas un langage, n’a pas de méta-
modèle. C’est une simple notation …

15. Choix de construire un outil

18. Enterprise Architecture

19. La vision Services en EA
Service
Application
Service
Application
Function
consumes
usesrealizes
Service et consommations utilisés par la plupart des
méthodologies EA …
Mais ces méthodologies ne descendent pas sur la question du
« comment » ?

20. Des activités complémentaires
Service / API Behaviour
Specification Décrire les traitements internes
et les interactions partenaires
Service / API Realization
Enterprise Architecture activities
Service / API Interface
Specification
Décrire les données échangées
(IN / OUT)
… pour combler le fossé avant la réalisation.

21. Certaines simples à outiller
Service / API Realization
Enterprise Architecture activities
Service / API Interface
Specification
Service / API Behaviour
Specification
Nombreux méta-modèles et
artifacts techniques
?
… d’autres moins explorées !

22. Utilisation d’EIP pour le comportement
Service / API Realization
Enterprise Architecture activities
Service / API Interface
Specification
Service / API Behaviour
Specification
Un outillage EIP pour
réaliser la transition !
Insufler de la continuité dans les activités

23. PDE Model transformation
Model to Text generation
Enrichissement de l’outil

27. Utilisation d’EIP pour le comportement
Service / API Realization
Enterprise Architecture activities
Service / API Interface
Specification
Service / API Behaviour
Specification
Dans la vraie vie, le
processus n’est jamais
uniquement top-down !
Intégrer une boucle de retour

28. Model ComparisonPDE
Enrichissement de l’outil

30. EIP Designer
Une façon simple, indépendante d’un vendeur, de
spécifier le comportement d’un Service,
Des accélérateurs pour générer des squelettes pour les
solutions de mise en œuvre les plus communes,
Des outils de contrôle pour vérifier une mise en œuvre,
Un système de bridge pour étendre d’autres designers
notamment orientés Architecture d’Entreprise

31. EIP Designer
Spring
Integration
Obeo TOGAF
Designer
SwitchYard /
SCA
Basé sur les technologies
Eclipse
Open Source, hosted on
GitHub
(http://github.com/lbroudoux/eip-
designer)
Avec le support de 1ers
standards ouverts

32. Perspectives
EIP Model
EIP
Designer
Parsers
EA activities
Utilisation pour la migration de patrimoine !
Expérimentation Covéa depuis T4 2015
Legacy
ESBs
EIP
Designer
Generators
Red Hat
JBoss Fuse