Notion de connecteur

La notion de connecteur recouvre l’ensemble des moyens nécessaires pour assurer l’interaction entre les composants par la connexion des interfaces requises et offertes (Projet Accord, 2002). Un connecteur relie une interface requise d’un composant à une interface fournie d’un autre composant (Tournier, 2005). Les connecteurs sont proposés principalement pour faciliter l’assemblage des composants en jouant le rôle d’intermédiaires entre les composants non compatibles. Les connecteurs sont des entités architecturales de communication qui modélisent de manière explicite les interactions (transfert de contrôle et de données) entre les composants. Ils contiennent des informations concernant les règles d’interactions entre les composants. Ils s’occupent de gérer les interactions (communication /coordination) entre les composants (Hadjab, 2003). Les connecteurs sont classifiés (Mehta et al, 2000) selon les services qu’ils offrent, donc on trouve les services de communication, de coordination, de conversion et de facilitation. Par ailleurs d’autres services peuvent être offerts par les connecteurs, par exemple, la notion de MVC (Multi-Versioning Connector) (Rakic et al, 2001), qui permet l’utilisation simultanée de plusieurs versions d’un même composant, ce connecteur redirige les appels aux services vers la version du composant la plus adéquate. Les connecteurs peuvent aussi être utilisés comme moyen de détection et de réparation (self-healing mechanism) des anomalies au niveau des objets et des interactions des tâches dans les composants (Shin et al, 2005).

Notion de service :

La notion de service constitue le concept de base de l’approche à service. Dans la littérature, plusieurs définitions sont citées, nous présentons les suivantes : “Services are self-describing, platform-agnostic computational elements….” (Papazoglou,2003). “Services are autonomous, platform-independent entities that can be described, published, discovery, and loosely coupled in novel way.”(Papazoglou et al, 2007). Dans ces définitions, (Papazoglou, 2003) et (Papazoglou et al,2007) , l’auteur présente un service comme une entité logicielle possédant une description clairement spécifiée et qui est indépendante de sa plateforme d’exécution. De cette manière, un service ne connaît pas son contexte d’utilisation. En plus, il peut être mis à disposition par un fournisseur et un utilisateur peut l’utiliser en ayant connaissance uniquement sa description, sans connaître réellement les détails liés à la technologie utilisée lors de sa réalisation, ce qui offre un couplage faible entre les fournisseurs et utilisateurs de services. « A service is a mechanism to enable access to one or more capabilities, where the access is provided by using a prescribed interface and is exercised consistent with constraints and policies as specified by the service composition.

A service is accessed by means of a service interface where the interface comprises the specifics of how to access the underlying capabilities. There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider. A service is opaque in that its implementation is typically hidden from the service consumer except for (1) the information and behaviour models exposed through the service interface and (2) the information required by service consumers to determine whether a given service is appropriate for their needs. » (Oasis, 2006). Pour le consortium OASIS (Oasis), un service fournit un ensemble de fonctionnalités décrites dans une spécification, appelée interface, ainsi qu’un ensemble de contraintes et de politiques d’accès aux fonctionnalités offertes. L’implantation du service n’est pas visible pour l’utilisateur. Seules les informations qui peuvent permettre de savoir si le service correspond aux besoins de l’utilisateur sont disponibles. Nous pouvons noter qu’il est cependant difficile de discerner une information utile d’une information inutile pour le choix d’un service. (Arsanjani, 2004) apporte une autre définition de service. A la différence des autres, il met en avant les principales interactions qui permettent l’utilisation des fonctionnalités du service : « A service is a software resource (discoverable) with an externalized service description. This service description is available for searching, binding, and invocation by a service consumer. Services should be ideally be governed by declarative policies and thus support a dynamically reconfigurable architectural style. »(Arsanjani, 2004). Cette définition s’intéresse à l’utilité de la description du service. Dans un premier temps, le client recherche le service correspondant à ses besoins en fonction de la description de service fournie. Ensuite, il fait la liaison avec lui et il l’invoque. Ces actions peuvent être réalisées avant ou pendant l’exécution de l’application à services. En résumé, un service possède les caractéristiques suivantes :

Un service possède une description rendue accessible par des fournisseurs pour des éventuels utilisateurs.

La description d’un service peut contenir l’ensemble des fonctionnalités fournies par ce service, et ainsi que ses propriétés.

Services Web : Le terme service est de plus en plus associé aux services Web (Malloy et al, 2006) qui sont devenus un standard de fait. Ce succès est du au fait que les services Web abordent un domaine où le besoin est très fort, en effet les services Web permettent à des applications hétérogènes s’exécutant au sein de différentes entreprises de pouvoir interopérer à travers des services offerts par les applications. Or l’utilisation de standards tels que XML facilité l’encapsulation et par conséquent l’interopérabilité (Motahari et al, 2006). Pourtant, bien que la plateforme à services web soit fondée sur les concepts de l’approche à services, l’interaction propre à cette approche n’est pas toujours suivie de façon systématique. Il faut aussi souligner que l’interaction de services dans les services web est réalisée sur une échelle de temps différente des autres plateformes présentées dans cette étude. C’est une des raisons qui fait que certaines organisations n’utilisent pas le registre pour publier leurs services. La description des services web est réalisée dans un langage appelé WSDL (Web Services Description Language). WSDL est basé sur une grammaire XML et permet de décrire l’interface du service, les types de données employés dans les messages, le protocole de transport employé dans la communication et des informations permettant de localiser le service spécifié.

Le registre de services, appelé UDDI (The Universal Description, Discovery and Integration) supporte l’enregistrement de descriptions de services (appelés types de services) ainsi que de fournisseurs de services (des entreprises). UDDI fournit des moyens de publier un fournisseur de service (typiquement une entreprise) à travers des pages blanches, jaunes et vertes. Les pages blanches contiennent le nom du fournisseur et sa description, les pages jaunes catégorisent un fournisseur et les pages vertes, plus techniques, décrivent les moyens d’interaction avec un fournisseur: description de services fournis en WSDL ou processus métiers. UDDI est un registre distribué dans lequel l’information est répliquée sur plusieurs sites, en conséquence, un fournisseur de services ne doit publier sa description de service que vers un seul noeud du réseau de registres. Le protocole de communication par défaut est SOAP (Simple Object Access Protocol). SOAP enveloppe le message dans un format XML. Il est la plupart du temps utilisé sur la couche de transport HTTP. L’interaction est schématisée par la Figure 6.

Synthèse : Pour conclure, l’approche à services est un paradigme qui a pour but de faciliter la construction d’applications à partir de services. Elle favorise ainsi la réutilisation des services existants pour la construction d’applications. L’approche à services aborde spécialement la phase d’exécution de services : la composition d’applications est centrée instance (objet de service). Une propriété importante de l’approche est le faible couplage entre les consommateurs et les fournisseurs de services. En effet, la seule information partagée entre ces acteurs est la spécification de service, permettant ainsi l’évolution indépendante des services, ainsi que le masquage de l’hétérogénéité et de la distribution des services aux consommateurs. De plus, l’approche à services permet d’établir les liaisons entre les consommateurs et les fournisseurs de services de façon tardive : la liaison entre les fournisseurs et les consommateurs a lieu seulement lorsqu’un fournisseur est trouvé et lorsque le consommateur le demande. Grâce aux propriétés de faible couplage et de liaison tardive, l’approche à services permet la construction d’applications flexibles et dynamiques. Néanmoins, les applications construites par composition de services sont difficiles à administrer.

En effet, il existe une dissociation entre le développement et l’exécution d’applications : les informations présentes lors du développement d’une application, notamment les concepts d’implémentation, de dépendance, d’architecture, ne sont pas connus à l’exécution. Du point de vue d’une application, les services sont des entités logicielles « boite noire » et les concepts d’implémentation et de dépendance de services sont inconnus à l’exécution. L’application a donc une vue « utilisateur de services » ignorant leur mise en oeuvre, tandis que les composants ont une vue « fournisseur de services » ignorant l’application à laquelle ils participent. Cette séparation de la connaissance entre le développement et l’exécution rend difficile de contrôler et de garantir l’exécution des applications. L’approche à composants à services vise à résoudre les problèmes liés à la construction d’applications à services en associant les concepts de composant et de service.