La phase de description est nécessaire dans les intergiciels où les clients et serveurs ne se connaissent pas au préalable. Elle est pertinente en Architecture Orientée Service puisque la recherche du couplage lâche repose sur la définition publique de tous les requis du client par rapport à un serveur (cf. section 5 pour les aspects concernant la sélection de service).
La plupart des intergiciels de communication répartie décrivent les entités à l'aide d'interfaces, qui sont dites "interfaces de service" en orientation service. Une interface de service est un ensemble d'opérations abstraites. Une opération abstraite est une opération sans sont implémentation, c'est-à-dire la définition de son nom, de ses arguments typés dans un espace de nommage. Une interface de service mentionne généralement :
• Des espaces de noms utilisés : une interface peut importer des éléments – types, messages, etc. – depuis d'autres interfaces ou spécifications. C'est le cas des
Web Services [GDSD04] avec ses "namespaces" (traduction anglaise des espaces de noms). C'est aussi le cas de Jini [Wal99] où les interfaces sont des interfaces Java et les espaces de noms sont des packages. Dans cette dernière technologie, les imports sont nommés explicitement dans l'interface et se réfèrent à des classes et des interfaces définies par ailleurs.
• Des types : les arguments des opérations sont typés. Les types peuvent faire référence à des types d'un espace de nommage extérieur. Généralement, chaque technologie définit des types simples comme les entiers, les chaines de caractères, les booléens, etc. UPnP [UPnP06], par exemple, ne définit que des types simples, des types complexes (souvent XML) pouvant se cacher dans les variables de type "chaine de caractère" du format UPnP Template Language. Les Web Services, en revanche, distinguent et définissent les types simples et complexes explicitement dans l'interface de service dans le format WSDL (Web Services Description Language). Le Forum UPnP, conscient de l'imperfection des modèles de description actuels, apporte une correction dans la version 1.1 à venir de la spécification UPnP Device Architecture.
• Des messages : les messages sont définis par une liste ordonnée de variables typées qui peut être échangées entre un client et un serveur. Les Web Services, la technologie à services la plus générique, définit ce niveau de granularité. Dans d'autres technologies, ce niveau n'est pas visible; les listes d'arguments d'entrée et de retour sont alors définies directement dans les opérations.
• Des opérations : une opération est décrite par son nom dans l'espace de nom de l'interface, par un message d'entrée ou un message de retour ou par les deux types de messages. Les messages d'entrée et de retour définissent respectivement une liste ordonnée d'arguments d'entrée et de retour. Les Web Services les appellent opérations. UPnP les appellent "actions". Les opérations sont appelées de différentes manières selon les technologies. Dans les intergiciels liés à un programme orienté objet – par exemple Jini – les opérations sont appelées "méthodes". Quatre types génériques d'opérations se distinguent :
o request-response : ce mode opératoire est le plus commun. Le client envoie un message de requête, le serveur répond par un message de réponse. Les 2 types de messages sont donc définis dans cette opération.
o one-way : ce mode opératoire dérive du mode request-response. La différence est qu'aucun message de réponse n'est attendu après réception et traitement de la requête par le serveur.
o solicit-response : ce mode opératoire est un mode inverse au mode request-response. Le serveur prend ici l'initiative d'envoyer un message au client auquel celui-ci répond par un message. Ce mode nécessite la souscription préalable du client sur les événements adéquats du serveur (cf. section 2.6 pour les mécanismes de souscription). Il est disponible par exemple avec WSDL. L'ordre d'écriture des messages d'entrée et de retour dans la définition d'une opération indique implicitement le mode opératoire choisi. Dans le mode solicit-response, le message de retour – output – est écrit avant le message d'entrée – input (cf. Figure 3).
o notification : ce mode dérive du mode solicit-response. La différence est qu'aucun message de réponse n'est attendu par le serveur après notification du client. Il nécessite de même la souscription préalable du client sur les événements adéquats du serveur (cf. section 2.6 pour les mécanismes de souscription). Ce mode de notification est répandu dans la plupart des intergiciels de communication réparti au contraire du mode solicit-response.
<operation name="weatherUpdateRenew"> <output message="tns:RenewRequest"/> <input message="tns:RenewResponse"/> </operation>
Figure 3 Exemple d'opération solicit-response décrite dans le langage WSDL
• Des événements : les événements correspondent aux envois de message spontanés par le serveur au client, soient aux opérations de type solicit-response et notification décrites ci-dessus. L'émission d'événements d'un serveur vers le client nécessite la souscription du client à ceux-ci. Il existe plusieurs modes de souscription dont les principaux suivent les modèles d'observation classique et publish/subscribe.
D'autres éléments peuvent être disponibles :
• Des variables d'états : la définition de variables d'état permet de modéliser l'état et le comportement attendu de l'implémentation de l'interface. Une variable d'état peut être liée à un argument d'entrée ou de retour d'une opération. Le changement de valeur de la variable peut aussi être la source d'un événement. Les variables d'états sont par exemple définies et utilisées de cette manière dans le modèle UPnP. Cette notion d'état est naturelle pour les équipements d'un réseau local comme le réseau domestique. En effet, les équipements comme la machine à laver et la télévision, ne peuvent servir qu'un client à la fois et l'état de l'équipement est partagé par tous les clients potentiels. Toutefois, la notion de variables d'état n'est pas indispensable. Par exemple, DPWS [DPWS06] n'en définit pas, bien que la notion puisse apparaître implicitement lorsque que des opérations semblent liées à des événements par le partage de mots identiques dans la définition des messages et arguments échangés.
• Une liste prédéfinie de métadonnées : une liste de paramètres à évaluer par chaque implémentation peut être indiqué par l'interface de service. Par exemple, UPnP et DPWS standardisent des noms de propriétés pour la description des équipements – Manufacturer, FriendlyName, etc.
Un fournisseur de services annonce les interfaces qu'il implémente en précisant:
• Son adresse ou son nom sur le réseau : un fournisseur de service doit fournir une adresse ou un nom unique sur le réseau afin d'être utilisé par des clients.
• Les paramètres nécessaires afin d'appeler ses opérations et souscrire à ses événements : des adresses précises différentes de l'adresse principale peuvent être données pour l'accès aux opérations et à la souscription d'événements. C'est le cas par exemple dans la description des services UPnP.
• Les métadonnées distinguant son implémentation : chaque implémentation d'une interface de service est particulière et les particularités peuvent être déclarées selon une liste de propriétés. Plusieurs technologies telles que SLP et UPnP permettent l'ajout d'une liste libre d'attributs valeurs. Les Web Services permettent l'ajout de métadonnées décrits selon des schémas XML génériques. L'expression de métadonnées permet la sélection de services selon des critères applicatifs (cf. section 5 pour des exemples de métadonnées). Elle renforce le sens du couplage lâche [CuM03].
• Les protocoles selon lesquels ses opérations sont accessibles. Généralement, un serveur propose ses services selon seulement un seul protocole de communication et la transposition de l'interface sur ce protocole est indiquée par la technologie. Par exemple, le format des messages SOAP pour l'appel d'opérations décrites dans une interface de service se déduit de la lecture de la
spécification UPnP. En revanche, d'autres spécifications permettent le choix libre d'un ou plusieurs protocoles de communication. Le format des messages est alors indiqué pour chaque protocole dans la description, dite "concrète", du fournisseur de service. Les Web Services permettent théoriquement ces déclarations spécifiques appelées "bindings". En pratique, SOAP est souvent utilisé comme seul protocole de communication par les Web Services. De rares travaux montrent l'intérêt de déclarer des variantes multiples d'un même service selon des protocoles distincts [MKF02].
• Les variantes qu'il peut offrir pour un même service : les variantes peuvent différer non seulement selon les protocoles de communication mais aussi selon le niveau de propriétés non-fonctionnelles comme la sécurité, la qualité de service.