Architecture

La SOA = la mort de l’objet ?

Publié le : Auteur: Anteo Consulting Un commentaire
architecture

SOA component UML schema

Cet article expose mes réflexions sur la relation entre les deux concepts logiciels clés qui sont la  SOA et l’orienté objet, et qui concernent à la fois les méthodes et l’architecture des systèmes. Il fait suite à une de ces phrases assassines entendues au cours d’une réunion de travail : « le SOA c’est la mort de l’objet« . Afin de faire la part des choses, il convient de replacer les mots dans leur contexte et de préciser les différents points de vue selon lesquels cette opinion peut être considérée…

Prétendre la mort de l’objet, c’est d’abord tirer un trait sur plus de 20 ans de recherche et d’amélioration effective des approches logicielles. Les technologies objet regroupent en effet un ensemble de méthodes, d’outils et de langages visant en premier lieu le génie logiciel. Lorsque l’on parle objet, il faut en effet inclure : capacités d’abstraction, modularisation, composants réutilisables, programmation par contrat et alignement métier. Au-delà de ces aspects, l’approche orientée objet a également connu ses échecs. Je pense tout particulièrement aux bases de données orientée-objet ainsi qu’à l’objet distribué.

Dans le premier cas, l’encapsulation des données objet dans une structure opaque a tenté d’imposer aux fonctions du support et de la production, les concepts d’encapsulation initialement conçus pour le développement logiciel. Supprimer les possibilités d’accéder simplement aux données en vue de les corriger ou de les agréger différemment, était en soit une erreur stratégique, puisque la dure loi du marché en a décidé autrement, en confirmant du même coup la simplicité et la non-encapsulation proposées par SQL.

Dans le second cas, les objets distribués sont une façon de décentraliser la gestion des données distribuées, dans l’optique d’améliorer les performances transactionnelles et la synchronicité des états. Cette technologie a souffert d’un mauvais départ lié aux performances et à la complexité de mise en œuvre (pour ceux qui se souviennent de CORBA/C++ notamment). Par ailleurs, les limites imposées par la taille mémoire des serveurs, cadrent mal avec la perspective théorique de disposer d’objets restant en veille. C’est enfin la difficulté de répondre au besoin de scalabilité avec des états mémoire devant être gérés en parallèle, qui ont fini d’achever le champs d’application des objets distribués. Très vite, les EJB entité ont été proscrits au profit des EJB session et cette tendance reste tenace malgré les efforts réalisés pour gommer les imperfections d’architecture, tant par l’évolution des normes (EJB et CORBA 3.0) que par les efforts des éditeurs d’infrastructure JEE.

Quelles leçons tirer de ces échecs ? Il convient en premier lieu de se souvenir du périmètre d’application des technologies orientées objet : l’ingénierie du logiciel. Autrement dit l’objet est une réponse – et je pense de loin la meilleure – pour aborder, modéliser et développer une problématique logique par la programmation. L’objet n’est cependant ni une architecture, ni un modèle de production informatique ; et les tentatives d’extension dans ces domaines en ont prouvé l’inadéquation.

La SOA est-elle la mort de l’objet ? En soi non, puisque comme précisé ci-dessus, l’objet n’a pas de place dans les architectures techniques. L’approche par objets distribués n’est pas encore mûre pour répondre aux exigences du transactionnel lourd, et elle ne le sera peut être jamais ; dans ce contexte on devrait donc plutôt déclarer que la SOA exclut les objets distribués au profit des architectures sans état plus adaptées aux protocoles connectionless (je pense particulièrement au mariage de raison entre REST et HTTP).

Par extension, la SOA permet-elle d’oublier l’approche orientée objet ? Les deux domaines sont relativement indépendants : de la même façon que rien n’empêche de développer en JAVA comme on écrirait du COBOL, rien n’empêche d’exposer comme service n’importe quelle fonction logicielle avec des variables globales et des paramètres déstructurés. Il faut cependant garder en mémoire les leçons du passé, de sorte que les risques de complexités par évolutions successives, d’impacts non maîtrisés et de de rigidité des systèmes, sont toujours bien réels, y-compris avec la SOA. La SOA doit ainsi être employée comme un moyen d’architecture technique et l’orientée objet comme approche d’ingénierie logicielle pour viser l’agilité du SI.

En d’autres termes, la SOA doit s’articuler autour de facilités de gestion et de réutilisation. Dans ce contexte, les notions de composants et d’interfaces sont indispensablement connectés aux objets métier de l’entreprise. L’alignement métier par l’étude des processus et la modélisation objet confère justement une grande stabilité de définition aux services, et elle permet d’en dégager l’agencement optimal. Car une fois les questions d’architecture technique évacuées, c’est bien d’architecture logicielle dont il s’agit, et c’est bien là que l’approche orientée objet y trouve pleinement sa justification.

 

  • Philippe Noel

    Bonjour,
    Je pense qu’il faut distinguer l’héritage fonctionnel de l’héritage technique. L’héritage technique est extrêmement puissant et a montré ses vertus dans de nombreux cas, comme par exemple les composants graphiques ou la sérialisation XML.
    L’héritage fonctionnel est à mon sens beaucoup plus dangereux et mènent bien souvent à des constructions en plats de spaghettis qui peuvent mener jusqu’à une refonte de solutions complètes dues à des difficultés insurmontables de maintenance. La modélisation confiée à des mains peu expertes (et c’est souvent le cas sur de nombreux projets) peut mener à des constructions intellectuellement très complexes dont la plus-value en terme de maintenance est inversement proportionnelle au gain apporté en terme de modélisation. Les profondeurs d’héritage, les dépendances cycliques, la modélisation allant bien au-delà des spécifications demandées par le métier, autant de pièges qu’apportent la modélisation objet. Donc à mon sens la modélisation objet, oui pour le technique, non pour le fonctionnel.
    C’est à mon sens un juste milieu entre le tout objet et le tout fonction : prenons le meilleur des deux !