L’architecture orientée services

Les technologies des services web (SOAP, WSDL, UDDI, BPEL,…etc.) sont présentées comme le moyen d’implémentation des architectures orientées services. Cette architecture introduit la relation de service et les rôles de clients et de prestataires joués par les applications participantes. L’architecture orientée services (AOS) est le terme utilisé pour désigner un modèle d’architecture pour l’exécution d’applications logicielles réparties. Dans ce modèle d’architecture, le concept service joue le rôle primaire, contrairement aux autres environnements reparties (CORBA, DCOM,…etc.) qui sont généralement des architectures par composants logiciels repartis plutôt que des architectures orientées services [4]. Construire une architecture orientée services signifie d’abord concevoir une architecture en réseau de relations de services, entre applications réparties. La description d’une relation de services est formalisée par un contrat de services. Ce contrat décrit les engagements réciproques du prestataire et du client du service.

La notion de service est le produit d’une démarche d’abstraction par rapport au logiciel qui l’implémente, au processus qui l’exécute et au port qui le localise. La réalisation d’un service passe par des messages échangés, des transitions d’état et des actions que l’application cliente suppose assurés de la part de l’application prestataire du service [7]. Les échanges se font par contrat : Un service ne donne aucune indication sur la manière dont il est implémenté, de la technologie avec laquelle il est créé, ou de la plateforme sur la quelle il est déployé. Il expose simplement un contrat qui stipule se que sont les formats de données échangés, les points d’entrée, quelles informations sont acceptée en entrée pour chaque point d’entrée, et quelles informations sont données en réponse.

Les éléments du service

La description d’une relation de service est formalisée par un contrat de service. Ce contrat décrit les engagements réciproques du prestataire et du client du service. Toute application pouvant satisfaire les engagements du prestataire peut interpréter le rôle de prestataire (Idem pou le Client). Ce contrat doit être facilement extensible, aussi doit être lisible par des agents humains et exploitable par des agents logiciels (généré, interprété, agrégé, indexé, mémorisé,…, etc.). Donc le choix d’un format universel et extensible de structuration de documents comme XML s’impose.  Fonctions du service : Un système en générale peut être décrit en termes d’objectifs (à quoi il sert), de moyens d’interactions (comment on s’en sert), d’informations et de règles de fonctionnement du service (connaissance permettant au prestataire de service d’accomplir sa tache). La définition des fonctions du s ervice est la définition de l’objet du c ontrat. C’est-à- dire ce que l’application prestataire fait en termes de restitution d’information, de gestion d’états, de gestion des effets de bord, d’échange d’actes de communication) et ce que les données qu’elle échange signifient [4]. Dans le modèle fonctionnel, le système utilise les informations et les règles en sa possession pour sélectionner les actions qui lui permettent d’accomplir ses objectifs. Ce modèle est différent de celui de l’implémentation qui est une description technique de l’application logiciel qui met en œuvre les fonctions du service. Il faut noter qu’il est incorrect d’inclure les modèles d’implémentation des applications prestataires dans les contrats de service. L’implémentation de l’application prestataire est donc une boîte noire par rapport au contrat de service, sauf pour ce qui touche l’implémentation de la communication .

Le base de l’AOS

Faiblement couplée : Un service est en couplage faible quand il n’est pas autorisé à appeler directement un autre service. Il délègue cette responsabilité à un traitement spécialisé que l’on nomme fonction d’orchestration. Grâce au couplage faible, on peut réutiliser un service sans devoir reprendre des services qui lui sont liés. A partir de cette première définition, on ajoute d’autres principes techniques qui contribuent à découpler les services entre eux :La cible des technologies de service Web est bien les architectures orientées services. Un service Web est naturellement une application orientée services. Mais l’inverse ce n’est pas vrai. Selon la définition du W 3C, une application orientée services peut être qualifiée de service Web si elle exhibe le profil technologique suivant : 1. Tout d’abord, le fournisseur crée le service Web. Ce service doit s’inscrire auprès d’un référentiel UDDI en indiquant plusieurs de ses caractéristiques (l’interface ainsi que les informations d’accès au service), y compris sa description WSDL .