J’ai assisté à un séminaire d’IBM sur le thème: Mettre en oeuvre aujourd’hui une Architecture Orientée Services

J’ai trouvé les interventions très pertinentes et je suis d’accord avec cette vision. Voici une retranscription de mes notes. En italique mes réflexions perso.

Pour introduire le séminaire la directrice Websphere nous a parlé d’évolutions imposées par la compétition et de l’exigence du marché: la flexibilité. Mon dieu j’ai bien cru qu’on allait enchaîner sur le traité constitutionnel! Mais non, ouf, c’est le système d’information qui doit être flexible… Quoi que, une architecture orienté citoyen pour notre nouveau gouvernement, ça serait une idée 😉 Désolé, je m’égare. Les intervenants ont ensuite abordé la question sous différents angles. SOA, la notion de Service elle-même, Web services, BPEL et ESB sont les thèmes qui sont revenus. J’ai donc regroupé mes notes selon ces thèmes.

SOA

Soa est un style d’architecture
Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité.
On mesure le succès de la mise en place d’une SOA par le % de réutilisation des services.

Le but d’une SOA est de raccourcir les cycles de développement.
Le but d’une SOA est l’alignement de l’informatique sur le métier. Flexibilité dans le métier et dans le SI
Il faut augmenter le recouvrement entre le métier et l’informatique.
Il faut revisiter le métier pour le modéliser. Ce model doit être accepté et compris par les gens du SI et du métier.

SOA est une évolution technologique et une révolution dans la relation fonctionnel/ technique.
Un projet SOA doit être rattaché à la stratégie de l’entreprise sinon il n’a aucune chance de succès.

Le point départ de la démarche SOA est le constat suivant:
Les systèmes d’informations actuels sont trop souvent organisés par silos produits. Cette organisation offre peu de possibilités de réutilisation et ne permet pas de faire évoluer suffisamment rapidement le SI.

Principes fondamentaux derrière l’architecture SOA:
– Les ressources doivent être indépendantes de qui les utilisent
– Les évolutions technologiques ne doivent pas remettre en cause l’existant
– Découplage entre fournisseur et consommateur de services.

Il n’existe pas une recette pour garantir le succès de la mise en place d’une SOA mais des principes à respecter:
– discussion entre IT et métier
– se baser sur des use case métier
– s’appuyer sur les standards

Bref rien de nouveau par rapport à un développement sans SOA.

Service

Un service n’est pas technologique mais métier (Importance des uses case). On trouvera la technologie dans l’implémentation du service métier.
Les services peuvent être combinés pour satisfaire à des processus. Ce qui permet de casser les silos.
Un service peut être appelé et peut appeler lui-même d’autres services

Un service est caractérisé par :
– Neutralité vis-à-vis des protocoles de transport
– Couplage faible entre consommateur et fournisseur
– Une granularité importante

Identifier les services

C’est sans doute le problème central pour mettre en œuvre une SOA.

Seul les business analysts sont capables d’identifier un service réutilisable.

2 approches sont à considérer: (voir ce billet)

– Approche top-down:
La mise en place d’une SOA doit s’inscrire dans le cadre d’un plan directeur et d’une démarche d’urbanisation.

– Approche bottom-up:
La SOA est un moyen de réutiliser l’existant, on part des morceaux, on rassemble les bouts.
Mais une application legacy qui n’a pas été conçu dans le cadre d’une SOA est rarement réutilisable telle quelle. Il faut la modifier ou l’encapsuler.

IBM s’appuie sur 2 méthodologies pour mettre en place une SOA (c’est-à-dire identifier les services réutilisable):
– Component Business Modeling (CBM)
Le but est d’obtenir une cartographie du métier de l’entreprise.
A partir de cette carte on peut identifier les composants critiques selon les critères suivants:
Composant normal, compétitif ou différenciateur
Composant source de coûts ou de bénéfices

Un composant métier est délimité par les services qu’il consomme et ceux qu’il expose.

Cartographier le SI et faire correspondre cette cartographie avec celle du métier (urbanisation)

– Service Oriented Modeling & Architecture SOMA
Permet de faire le lien entre le métier et le SI

Décomposition en domaine (avec CBM)
Analyse de l’existant
Constitution d’un portefeuille de services candidats
Sélection et tri des services
Analyse des messages échangés

IBM recommande une approche MDD Model Driven Developpement pour la mise en place d’une SOA.

Ces méthodologies ne sont viables qu’en utilisant des outils. Les outils Rational bien sûr.

Granularité des services

La granularité des services est fondamentale dans une SOA. C’est elle qui va en grande partie déterminée la réutilisabilité des services. Il faut éviter une granularité trop fine car cela entraîne beaucoup d’interaction et donc des problèmes de performance en mode distribué. On recommande donc des services à “gros grain” (coarse grain) pour une SOA. Mais attention une granularité trop “épaisse”, un service qui fait trop de chose, risque de ne pas être réutilisable. Tout est question d’équilibre, il faut trouver le juste milieu.

Web Services
Une SOA peut se mettre en œuvre sans Web Services mais c’est aujourd’hui la meilleure solution disponible.
On peut utiliser les Web Services sans faire de SOA. Il s’agit alors d’une architecture point à point sans réutilisation.

Les Web service s’articule autour de 3 éléments: WSDL, SOAP, UDDI.
Seul WSDL est indispensable pour mettre en œuvre une SOA. Car c’est WSDL qui décrit le service

UDDI permet un binding dynamique des services (Le consommateurs découvre dynamiquement les services et leur fournisseurs). En pratique c’est très peu utilisé, la plus part des services sont consommés de manière statique: le consommateur connaît à l’avance le fournisseur.

BPEL
Norme permettant de décrire en xml des processus
Un processus est le résultat d’une orchestration de service. Le processus peut lui-même être accessible en tan que service.

On peut mettre en place une SOA sans orchestration de service. Mais à mon avis c’est passer à côté d’une grande partie de la valeur ajoutée d’une SOA.

ESB
Couche d’infrastructure qui optimise les échanges entre consommateurs et fournisseurs de services.
Le but d’un ESB est de permettre de communiquer de manière simple et standardisé entre des applications disparates.

C’est l’ESB qui fourni le service end-point. C’est le point d’entrée vers un service. Il doit être normalisé mais on ne sait pas qui fourni le service et comment il le fourni. On peut comparer le service end-point à une prise électrique. On peut brancher n’importe quel appareil qui respecte la norme (220 Volt, format de prise…) et la prise fournira du courant (le service) mais on ne sait pas d’où vient ce courant (centrale nucléaire, hydrolyque…)

Infrastructure SOA = middleware = ESB = Web Service + messaging (JMS) + integration Bref c’est de l’EAI

Mais il y aurait une différence avec l’EAI:

Dans un EAI on trouve une architecture en hub ou en étoile autour de connecteurs propriétaires liés au moteur d’intégration.
L’ESB est un EAI mais de part l’utilisation des web services les connecteurs sont dissociés du moteur d’intégration. On a donc plus de souplesse et d’ouverture. Je ne suis pas très convaincu, pour moi l’ESB reste un rebranding de l’EAI

Divers
On nous a aussi rapidement parlé de SDO, ça ressemble à du JDO ça a le goût de de JDO mais ce n’est pas du JDO…

IBM veut aussi faire un lien entre SOA et portails… Hum je ne vois pas bien… SOA pour accéder au contenu… Bof, REST ne serait pas plus adapté pour de la lecture de donnée??

On a aussi eu droit à une démo de Rational software architecte Ca à l’air pas mal pour faire de la modélisation UML. Mais on n’a pas eu les caractéristiques de la machine sur laquelle cela tournait…
Bon et bien sûr pour chacun de ces nombreux acronymes et concepts il existe un produit IBM qui va bien…