Architecture

Réutilisation avec SOA

Publié le : Auteur: Anteo Consulting Un commentaire
architecture

La réutilisation est une vieille promesse des architectures logicielles qui a connu une progression lente mais continue… En récapitulant mes expériences en la matière, je constate qu’à chaque nouvelle vague de middleware, de nouvelles tentatives sont menées dans l’optique d’obtenir la réutilisation logicielle.

La réutilisation reste cependant souvent vaguement spécifiée alors qu’elle implique des attentes à différents niveaux :

  • quel doit être le contexte technique d’exécution qui inclut la compatibilité technologique et les protocoles liés aux contraintes des transactions ?
  • le contexte fonctionnel n’implique-t-il pas des prérequis nécessaires à l’utilisation d’un service ?
  • quel niveau de documentation et quelle qualité de conception sont attendus par les bénéficiaires de la réutilisation ?
  • comment le composant réutilisable est-il physiquement déployé et quelle performance en attendre ?
  • qui est en charge de sa maintenance et comment pouvoir suivre ses possibles évolutions ?

Si j’en juge par l’évolution des middlewares du monde ouvert, les questions liées aux aspects techniques ont été résolues en priorité. La question du déploiement et de la performance a connu des premières réponses avec les environnements TUXEDO, RPC, CORBA et JAVA-RMI qui ont introduit les concepts du n-tiers, du routage et de la redondance de services. La question de l’interopérabilité a été ensuite traitée, d’abord par CORBA, avec une portée toutefois très limitée et un framework technique complexe, puis par les WEB Services avec le succès que l’on connaît aujourd’hui.

La question des protocoles techniques est longtemps restée un épineux problème. D’abord formalisés sous la forme de services techniques dans CORBA puis JAVA/JEE (services de sécurité, transaction, persistance, événement, etc.) ils connaissent une autre approche avec l’orchestration de services.

En complément de ces progrès, les WEB Services offrent une nouvelle possibilité, dénommée « service entitlement », qui permet d’étendre un service sans remettre en cause les configurations dans lesquelles il a été précédemment validé. Par cette approche, s’ouvre une dimension permettant de gérer simplement la diversité des contextes fonctionnels.

En définitive, l’alliance d’une approche SOA, de l’ESB et des WEB Services regroupe aujourd’hui :

  • l’interopérabilité  (pouvant être apportée indifféremment par l’ESB ou les WEB Services) qui résout les questions de la compatibilité technique
  • les possibilités d’orchestration de l’ESB (orchestration au sens large) qui permettent de gérer les contextes techniques
  • l’extension de services qui apporte la souplesse fonctionnelle.

Le SOA est donc légitimement vecteur de réutilisation, comme constaté par les rapports du Gartner et de Forrester, et comme nous l’avons également mis en œuvre chez nos clients. Il reste cependant encore à traiter des questions d’organisation, de gestion du catalogue des services réutilisables, de méthodologie, et de montée en compétence des équipes tant fonctionnelles que techniques, ce qui n’est pas un challenge toujours gagné d’avance.

  • Girardot

    Effectivement, la réutilisation semble toujours un peu le même problème que décrocher la lune en montant sur un tabouret. Pour ma part, il me semble qu’il faut aborder la question par la factorisation : tout ce qui est factorisé est réutilisé, du fait même de sa factorisation. Et le bénéfice n’est pas une autre hypothétique réutilisation, mais la localité des modifications du composant factorisé (ce qui est finalement ce que l’on recherche : l’évolutivité). Diverses techniques de factorisation au niveau d’une simple application sont :

    1) l’affectation à une variable locale le résultat d’un calcul intermédiaire, et l’utilisation en de multiples points du programme de cette variable…
    2) la boucle, qui réutilise du code, l’itération pouvant se faire sur des entiers, des clés, une liste homogène…
    3) la fonction et la procédure, qui factorise du code
    4) la programmation générique (qui factorise en plus sous forme de fonctions des traitements identiques sur des données de types variables)
    5) les classes (qui factorisent la déclaration de bouts de noms de variables)
    6) l’héritage (qui factorise les déclarations d’attributs)
    7) la liaison dynamique et le polymorphisme (qui renvoient au compilateur la problématique du choix de la fonction à exécuter selon le type des arguments)

    et le correspondant dans les données : la struturation relationnelle normalisée.

    Une fois cela fait, la seule vraie question est la répartition sur des ressources matérielles…

    Bon, là, le vrai problème commence.

    Rappel : une fonction n’est réutilisable dans un autre contexte (non prévu initialement, dans une autre application), que si elle est « pure », c’est-à-dire sans effet de bord. Or, en programmation objet, les méthodes sont a effet de bord, et c’est voulu, les classes étant là, comme leur ancètres, les modules, pour limiter leur effet de bord. C’est voulu car cela rend rationnel le passage d’arguments, mais cela limite la réutilisabilité pour un autre contexte applicatif. Il ne faut alors pas voir la réutilisabilité comme à l’identique, mais avec adaptations.

    C’est peut-être pour cela que beaucoup de gens proposent des services et des bibltiohèques, et que beaucoup moins les réutilisent…