Déjà Membre?
 La référence technique on-line des professionnels de l'informatique |
|
Appréhender de nouveaux concepts et s’assurer de la bonne direction des projets informatiques nécessitent au préalable un arrêt sur ce qu’on désigne couramment comme les « bonnes pratiques ». Celles-ci sont généralement issues de la longue tradition des prédicateurs de nos temps, les « leads architects », respectables par leurs contributions à la discipline d’ingénierie du logiciel. Aussi est-il commun de vérifier auprès de nos équipes, si celle-ci ont été bercées par des patterns du « GoF », de Martin Fowler, Jacobson ou plus récemment de Thomas Erl.
Aujourd’hui, ne pas disposer de connaissance des grands principes, et ne pas l’exiger de ces équipes d’architectes constitue une véritable prise de risque. Il est salutaire de prendre le temps de considérer, à la lumière des précédentes expériences, ce qui a été mal interprété des différents enseignements, ce qui n’a pas fonctionné, puis de constater sans fard « tout le mal que l’on ne souhaitait pas faire ».
Sous le vocable ESB se cachent 2 concepts différents :
Dans une démarche SOA, les concepts de « Médiation » et d’« Exposition » font corps afin de fournir au reste du SI les services gages de stabilité et d’évolutivité.
Puisque l’on aborde très souvent les bonnes pratiques, pourquoi ne pas se pencher sur quelques mauvaises pratiques communément recensées autour de la mise en place d’un ESB ?
Suite à la mise en place d’une méthodologie d’identification de service, il peut arriver que le message initial de « rationalisation des services du SI » soit mal interprété, aboutissant à une situation opposée à celle recherchée ; une tentative de rationalisation du nombre d’interfaces exposées pour un domaine fonctionnel, en fournissant des services de forte granularité. Nous tombons alors dans l’excès inverse, à savoir : la fourniture d’un nombre limité de services, qui répondent à un périmètre fonctionnel trop large.
Tentative de rationalisation des services exposés au sein du SI sans prendre en compte les cas d’usages métiers. Peur de l’anti-pattern « Tout est Service ». Démarche SOA portée isolément par l’IT.
Les effets négatifs concernent la complexité fonctionnelle portée par ces services, qui répondent à de nombreux cas fonctionnels (tous les langages d’implémentation ne sont pas aussi élégants que les prédicats Prolog pour adresser les clauses multiples…) ou bien une signature de service à tiroir, permettant la saisie de paramètres d’entrée à géométrie variable.
La gouvernance d’un tel service s’avère des plus délicates, puisqu’il adresse de nombreuses problématiques, et donc en servant un dessein aussi large, est susceptible de subir de nombreuses évolutions. Nous risquons alors de produire de multiples versions, qui n’intéressent qu’un nombre limité de consommateurs, voire de multiplier les interfaces pour un même service, faisant alors porter l’adaptation fonctionnelle par l’ESB.
Un corollaire, qui va généralement de pair avec les éléments décrits précédemment concerne les performances d’un tel service. Il n’est en effet pas rare de le voir remonter une grappe d’objet d’une profondeur importante afin de fournir à ces nombreux consommateurs toute l’étendue des informations qu’ils sollicitent.
Généralement, celle-ci est à rechercher du côté des cas d’usages auquel doit répondre ce service (s’il est de niveau Tache) ou bien sur l’identification précise de la classe métier/catégorie qu’il manipule (s’il s’agit d’un service de type Entité). L’objectif est de mieux délimiter le service offert, en proposant un nouveau découpage, permettant ainsi de séparer les populations consommatrices et ainsi, d’être plus en phase avec les besoins. Si le service est découpé plus fin, le risque de remonter l’intégralité des informations du domaine fonctionnel à chaque appel est plus limité.
La solution est donc plutôt à rechercher sur la granularité du service à exposer, plutôt que sur une adaptation fonctionnelle portée par les capacités de l’ESB.
Il est commun dans une démarche SOA de tomber dans une exposition systématique en services Web, notamment en ce qui concerne les éléments du patrimoine applicatif existant.
Il est bien de la prérogative de l’ESB de porter cette fonctionnalité d’exposition ; pour autant l’exposition systématique sur un ESB de même typologie de services pose à la fois un problème de gouvernance ainsi que de performance, le protocole SOAP sur HTTP étant bavard. La mise en oeuvre d’une architecture SOA est alors communément confondue avec une démarche Web Service qui vise à remplacer les API ou les appels de procédure distante par l’usage d’un seul et unique protocole.
Leitmotiv souvent entendu « Nous avions déjà une démarche Service, il n’y a plus qu’à les exposer en Web services».
Cette déviation de la démarche apparait maladroitement comme une solution de rationalisation des interfaces applicatives. Pour autant, dans certains cas, la couche d’exposition en Web Service n’est pas forcément portée par une brique applicative performante et dégrade peu à peu le niveau de service du SI. Lorsque cet anti-pattern intervient dans un environnement possédant un ESB de type logiciel et non de type « Appliance », le goulet d’étranglement n’en est que plus évident.
Par ailleurs, l’ESB devient dans cette vision le nouveau « Single Point Of Failure » du SI. Certains détracteurs mentionneront que c’est souvent le cas, puisqu’il constitue le point d’acquisition de l’interface des services. Cependant, le risque est particulièrement renforcé avec une démarche ou tout service technique ou purement applicatif serait exposé.
Ce biais entraine une forte complexité de gouvernance des services. Dans une démarche SOA, il faut conserver comme objectif de construire et d’exposer des services qui ont une véritable plus value métier. Le décommissionnement des protocoles existants, voire natifs, ne doit pas intervenir de manière systématique, mais doit toujours être motivé par un besoin avéré d’interopérabilité.
La question doit également se poser dans le cadre de la démarche d’identification des services : un service dit « Utilitaire » (1), bien qu’identifié en terme de service SOA, porte une implémentation qui ne systématise pas l’usage d’un web service.
Cet anti-pattern s’avère d’autant plus nocif à moyen terme pour le SI lorsque la démarche d’exposition du SI en service n’est pas adossée à un référentiel de service (qui n’est pas un simple annuaire UDDI !).
(1) Service proposant des fonctionnalités d’administration, de supervision fonctionnelle ou technique, de gestion de l’infrastructure. Voir Référentiel méthodologique GO-ON pour plus d’information sur la démarche SOA préconisée.
Partager |
|
 Claude-Emmanuel Drexler,  Logica est l’entreprise du service en business et technologie. Elle réunit 39 000 collaborateurs. Elle propose conseil en management, intégration de technologies et externalisation à ses clients du monde entier, dont les plus grandes entreprises en Europe. |
