Archive

Articles taggués ‘Udi Dahan’

QCon London 2010 – Udi Dahan – Avoid a Failed SOA

“Business & Autonomous Components to the Rescue”

image Malgré un sujet pas très original, avec peu d’idées réellement neuves, probablement la meilleure présentation à laquelle j’ai assisté aux QCon 2010 de Londres. J’y ai été particulièrement sensible, du fait que j’ai moi-même réalisé et animé des séminaires sur des sujets similaires. Et j’ai pris une leçon, sur la forme comme sur le fond.

Sur le fond, finalement, un seul message simple est véhiculé par Udi Dahan : une condition nécessaire à la réussite d’une SOA c’est l’émergence de composants très faiblement couplés. Pas vraiment une surprise. Mais c’est grâce à une forme étudiée que son discours (simple mais pas simpliste) amène à se poser des questions profondes.

Sur la forme donc, un discours extrêmement clair sans utilisation d’aucun buzz, et un enchaînement logique des idées qui mène inexorablement l’auditoire à ses conclusions inéluctables. Quand la vidéo de cette présentation sera en ligne sur InfoQ (malheureusement, ils les distillent pendant six mois), ne la ratez pas.image

Je vais tenter de résumer.

Le sujet c’est le projet d’intégration. Pourquoi ça rate souvent, et comment faire que ça rate moins :-) On a le droit de se tromper plusieurs fois, mais à chaque fois différemment !

La présentation oscille autour de l’architecture entre la vision métier et la vision technologique.

SOA et couplage faible

Un des objectifs de la SOA est d’atteindre un couplage faible entre composants métiers autonomes. Tout le monde est d’accord là-dessus. Mais ce couplage faible doit être une exigence à la fois métier et technique qu’il faut prendre en compte à la conception comme à l’exécution.

imageUdi part d’un SI théorique plutôt bien aligné sur le métier (avec une véritable architecture fonctionnelle explicite) dont on pourrait se dire qu’il est facilement “SOAisable”.

Il montre qu’une intégration des applications par des services (une SOA) peut, en fait, mener facilement à des applications très fortement couplées qui amènent, en production, leur lot de contentions (mémoire, threads, locks base de données…) .

So what ? Qu’est-ce qu’on a loupé ?

On a oublié que pour obtenir le découplage à l’exécution il faut des communications asynchrones (d’un point de vue fonctionnel et pas seulement technique). Et il y a de fortes conséquences sur… la conception.

Il faut donc basculer du requête/réponse à la publication/abonnement (d’une architecture orientée services vers une architecture orientée événements). C’est la succession d’émission d’événements qui matérialise le processus et non l’orchestration d’appel de services. Et c’est l’émetteur qui définit le contrat de service et non le receveur. On parle d’Event Driven Architecture (EDA).

Mon avis

Même si ce qui vient d’être dit est parfaitement logique en terme d’affectation de responsabilités, la plupart des démarches de conception travaillent dans l’autre sens : le contrat de service est défini à partir du besoin du client du service (c’est ce qu’on fait quand on fait de la conception d’application : c’est le scénario d’utilisation qui définit les services publiés par le serveur métier). Il faut donc changer radicalement son mode dimagee conception lorsqu’on fait de la SOA/EDA : les contrats de service doivent être définis uniquement par les changements d’état des objets métier et non par les “clients” de ces changements d’état.

Autre réflexion que m’inspire cette vision (originale) de ce qu’est un processus SI : un enchainement infini d’événements. On ne peut plus définir un Processus avec un début (l’Evénement déclencheur) et une fin (un Produit de sortie) créant de la valeur pour son Client. C’est une révolution conceptuelle (on remet en cause la définition d’un processus selon l’ISO !) et surtout, ça pose un gros problème. Comment appliquer la doctrine millénaire du consultant en processus : “centrer les processus de l’entreprise sur le client”, si le client de l’entreprise n’est plus le client du processus ? Je n’ai pas de réponse pour le moment :-)

Composants métier autonomes

Udi Dahan évoque ensuite une autre question délicate. Comment partitionner les services en composants autonomes ? A nouveau, une réponse évidente est : aligner les composants sur le métier. Un composant métier par bloc fonctionnel. Un rêve d’urbaniste !

Il montre qu’en fait, ce partitionnement “idéal” ne répond pas toujours au besoin et  imageparticulièrement aux exigences non fonctionnelles. Il donne l’exemple des SLA différents en fonction du type de client et propose donc des composants métier autonomes techniquement (potentiellement très différents dans l’implémentation), définissant les mêmes contrats de service mais implémentés différemment.

Mais à nouveau, comment éviter un couplage si, finalement le routage des événement doit se faire en fonction de leur contenu (l’événement contenant un “petit client” doit être routé vers le composant dédié petit client, l’événement “gros client” vers le composant dédié gros client).

Le fonctionnement EDA précédent permet, à nouveau, à chaque composant d’être autonome dans la prise de décision : tous les composants d’un même métier sont abonnés aux mêmes événements et chacun décide de manière autonome de traiter ou non un événement particulier en fonction de son contenu.

A bientôt pour d’autres conférences QCon.

Categories: Web Services - SOA Tags: , , , ,