Technologies

Service, Composant et Objet : La confusion

Publié le : Auteur: Hugues VAN EYLEN 3 commentaires
technologies

Voilà quelques temps déjà que je souhaitais écrire un billet sur la confusion qui règne autour des termes de service, composant et objet.  Ces trois notions possèdent en effet de nombreux points communs :

  • elles peuvent toutes réaliser des calculs,
  • elles sont toutes appelables par un code d’usage (consommateur)  leur demandant de réaliser ces calculs et de fournir le résultat en retour
  • Pour toutes, cet appel ressemble à un appel de méthode
  • Pour toutes, on les a présentés comme la solution au besoin de réutilisation logicielle

On serait tenté de dire qu’au commencement était l’objet bien que cela soit un peu prétentieux. Toutefois, ce paradigme qui a émergé en pleine lumière dans les années 80 avait pour objectif de maîtriser la complexité toujours accrue des systèmes logiciels. On regroupe dans un même élément logiciel des données (l’état de l’objet) et des traitements (les méthodes). Ainsi, un autre élément logiciel peut être consommateur d’une méthode d’un objet lui rendant … un service.  Dans le paradigme objet, tout est objet même des objets de taille extrêmement réduite comme des entiers ou encore des listes d’objet. La réalisation de ce paradigme se retrouve ainsi dans les langages de programmation objet où tout élément de calcul si petit soit-il peut être réalisé à l’aide d’une méthode.

Puis vint l’ère des composants. Ceux-ci sont apparus en réponse à une bonne pratique d’architecture : la séparation des préoccupations. Ainsi, le modèle des composants émergeant dans les années 90 avait pour objectif de séparer les préoccupations techniques dans un conteneur (conteneur de servlet, d’EJB, etc.) en laissant les préoccupations fonctionnelles aux composants accueillis par le conteneur. Dès lors, réaliser une application pouvait se faire par assemblage de composants. Toutefois, les conteneurs ainsi que les composants étaient réalisés dans un langage de programmation objet et par conséquent les composants étaient aussi des objets. Une première confusion survint alors qui mélangea le paradigme objet à celui des composants aboutissant entre autres à la norme EJB1.0 et son lot d’aberrations. Les composants sont souvent associés à un modèle de communication distribuée, or la granularité objet se marie mal en terme de performances avec les protocoles de distribution quelqu’ils soient (CORBA, RMI, DCOM, etc.).

Les années 2000 virent apparaître un nouveau paradigme possédant son acronyme vedette : SOA. Les architectures orientées services sont la dernière étape à la mode de cette quête du saint Graal qu’est la réutilisation logicielle. Un service est un élément logiciel offrant au système informatique de l’entreprise une fonctionnalité réutilisable dans plusieurs contextes issus de processus métier. A la différence des composants bâtis pour des raisons techniques, les services sont avant tout une affaire fonctionnelle.  Leur naissance dans le berceau des web services les a malheureusement teintés de technologie et apporté une confusion entre service et web service. Les web services apportent l’interopérabilité qui est facteur de réutilisation mais en aucun cas cette capacité est suffisante à établir un service au sens où la SOA l’entend.

Une autre confusion existe entre la notion UML d’opération et celle de service. Une opération est un service mais bien souvent, on voit un service comme étant un regroupement fonctionnellement cohérent d’opérations. Un service est alors défini par son contrat de service sous forme d’une interface UML  indiquant pour chaque opération les données en entrées, celles en sortie, les exceptions possibles interdisant la bonne exécution de l’opération, les règles de gestion allouées à l’opération ainsi que des contraintes de performance ou de charge souhaitées.

Ce rapprochement avec UML apporte aussi son lot de confusion, UML étant vu classiquement comme un standard du paradigme Objet. Et pour couronner le tout, un service peut être implémenté dans un langage de programmation objet ce qui le liera d’autant plus à cette notion.

Ce tour d’horizon effectué sur ces trois notions peut être résumé comme suit :

 

Service et composant peuvent être implémentés comme un ensemble d’objets collaborant dont l’un d’entre-eux (la façade) est la vision exposée du service ou du composant. Bien sûr, un service peut être implémenté comme un composant. La différence est ici que le service est une capacité, un actif du système informatique de l’entreprise rangé dans un référentiel d’entreprise. Un composant n’est pas exposé mais participe à l’implémentation d’un service. Un composant est affaire d’implémentation et est teinté de technologie, un service est affaire d’analyse fonctionnelle agnostique de l’aspect technologique dans sa spécification (contrat de service). Quant au paradigme objet, il est plus vaste et contient les paradigmes de service et de composant tout en ayant une réalité en tant que langage de programmation ce qui en fait un moyen de réalisation des composants et des services.

Pour conclure sur cet exposé des différences et points communs entre Service, Composant et Objet, prenons une métaphore du monde réel pour fixer les idées de manière plus concrète.

Quand je me rends au restaurant, je deviens consommateur du service de restauration offert et me conforme au contrat de service proposé sous la forme d’une carte de menu. Un composant du restaurant est sa cuisine avec son chef cuisinier et ses aides éventuels. Une recette de cuisine est une méthode qu’applique le chef pour réaliser certains plats, on se retrouve ici à un niveau Objet. En tant que consommateur, ce niveau de détail ne m’intéresse pas et je n’y ai pas accès. Imaginez ce qui se passerait si le niveau de granularité des services d’un restaurant me permettait d’agir en cuisine…

De même la granularité d’un service forme un tout fonctionnel. On va au restaurant pour commander un plat, pas pour une simple sauce.

Méfiance donc car réaliser une architecture de services est bien différent de la mise en place d’une architecture objet. Et il ne suffit pas de changer le terme objet par service pour avoir réalisé une bonne architecture de services.

  • Mes deux centimes Hugues ;D
    Heu… La confusion règne aussi au sein de l’article.
    De mon point de vue on ne peut pas comparer ou opposer les notions d’objet, de composant et de service si on s’en tient au niveau « notion », ie concept. Le principal lien entre ces trois notions est certainement la notion de couplage, et donc d’encapsulation.
    Le concept objet, avant même la réutilisation, vise à factoriser et à isoler, encapsuler, pour reproduire assez fidèlement d’ailleurs des caractéristiques des « objets » de la vie réelle pour les retrouver dans la vie virtuelle et faciliter ainsi le mapping besoin/solution.
    Décliné en artefact du SI, un objet « conceptuel » aurait du devenir un composant. Pour un certain nombre de raisons, dont une mauvaise compréhension des implications de la déclinaison concrète de la notion d’héritage, l’approche « pure » objet amenait souvent à des composants, ie artefacts unitaires de déploiement, trop gros et trop couplés entre eux ce qui aboutissait à l’effet inverse, en pratique, de celui recherché initialement avec l’encapsulation. On s’est donc concentré sur la notion de « composant » en mettant l’accent sur l’organisation physique du SI et en cherchant le découplage à ce niveau.
    Et puis finalement, en s’intéressant cette fois à l’utilité, la notion de service est apparue. D’abord chez Microsoft, puis avec Java, via la notion d’interface (et même de versions d’interface) : une interface est en synthèse un contrat de service et on s’est rendu compte qu’un composant (ie l’artefact unitaire) pouvait tout à fait avoir plusieurs interfaces. L’idée de web-services est venue à nouveau rendre les choses confuses puisqu’il s’agit ni plus ni moins que d’une interface appelable au travers du web et rendant le service prévu. En gros, le préfixe « web » n’apporte pas grand chose technique puisque le principe d’appel distant existait depuis longtemps (RPC). Par contre c’était bon pour le buzz.
    Au final, un bon SI nécessite certainement d’intégrer l’approche objet dans la conception applicative (et donc de l’exprimer au moins en partie avec le langage UML ou équivalent), d’intégrer la notion d’urbanisme jusqu’à une granularité fine : organisation/architecture des composants (artefacts déployables), d’exploiter la notion de services « à faible empreinte organisationnelle » qui permet d’invoquer un service à distance sans nuire à l’encapsulation garante de l’évolutivité du tout.
    Ou quelque chose comme ça !! ;D

  • Franck Vallée

    Je pense qu’il y a effectivement confusion de pratiques, mais UML définit pour autant clairement les notions :
    « A component represents a software module (source code, binary code, executable, DLL, etc.) with a well-defined interface. »
    Le composant impose clairement l’existence d’une trace physique et déployable sur une unité de calcul.
    « A class represents a cohesive unit of Attributes and Operations. » Il s’agit ici d’une vue abstraite ou logique qui n’explicite pas la façon dont elle est implémentée. Idem pour les objets qui sont très souvent des instances de classes.
    UML ne définit pas directement ce qu’est un service, mais on le retrouve dans la définition d’une interface : « An interface declares a set of public features and obligations that constitute a coherent service offered « .
    La confusion provient des définitions SOA et WEB-Services fournis par l’OASIS et qui ne cadrent pas avec les concepts UML. Cette divergence permet à chacun d’adopter le vocabulaire de son choix et au mieux de redéfinir des glossaires méthodologiques spécifiques. Pour autant, les efforts et les leviers de normalisation sont bien fournis par l’OMG.

  • Dans la vie de tous les jours, un fournisseur offre un service à un client le consommant dans une relation de confiance établie entre les deux parties. En général, le client s’intéresse uniquement au résultat produit du service sans avoir le besoin ni le souci de savoir comment ce dernier est obtenu. La SOA suit ce même principe. Le service est une action exécutée par un « fournisseur » (ou « producteur ») à l’attention d’un « client » (ou « consommateur »), cependant l’interaction entre consommateur et producteur est faite par le biais d’un médiateur (qui peut être un bus) responsable de la mise en relation des composants. Le service étant à grandes mailles, il englobe et propose les fonctionnalités des composants du système. Ces systèmes peuvent aussi être définis comme des couches applicatives. L’architecture orientée services est une réponse très efficace aux problématiques que rencontrent les entreprises en termes de réutilisabilité, d’ interopérabilité et de réduction de couplage entre les différents systèmes qui implémentent leurs systèmes d’information. Les SOA ou AOS ont été popularisées avec l’apparition de standards comme les Services Web dans l’ e-commerce (commerce électronique) ( B2B , inter-entreprise, ou B2C , d’entreprise à consommateur), fondés sur des plates-formes comme J2EE ou .NET . Elles mettent en application une partie des principes d’ urbanisation . Au sein de l’architecture orientée services, on distingue les notions d’annuaire, de bus, de contrat et de service, ce dernier étant le noyau et le point central d’une architecture orientée services. La déclinaison ou plus précisément la mise en œuvre de la SOA qui repose entièrement sur Internet est appelée la WOA (Web Oriented Architecture).