Instructions: Service
Ces instructions détaillent la définition d'un service en tant que ressource logicielle identifiable comportant une spécification de service externalisée.
Relations
Eléments connexes
Description principale

Introduction

Un service est un artefact clé dans une architecture orientée services (architecture SOA) ; mais de quoi s'agit-il au juste ? Citons l'une des entrées du glossaire Rational Unified Process (RUP).

Un service est une ressource logicielle (identifiable) qui comporte une spécification de service externalisée. Cette spécification permet au client du service d'effectuer des recherches et des appels et d'établir des liaisons. Le fournisseur de services réalise l'implémentation de la spécification et livre les exigences de qualité du service au client. Les services doivent être régis par des règles déclaratives et prendre ainsi en charge un style d'architecture dynamiquement reconfigurable.

Si la section suivante présente certaines expressions clés de cette entrée, il convient de souligner une caractéristique supplémentaire qui permet d'opérer une réelle distinction entre les services et les éléments de conception des technologies précédentes : le niveau de granularité des services permet à ces derniers d'être identifiés depuis un niveau métier. C'est la raison pour laquelle nous allons également aborder la correspondance entre les services et le métier.

Identifiable

Les services ne rentrent pas dans le cadre d'une architecture d'application monolithique. Au cours de l'exécution, ils existent indépendamment de tout autre service dans une solution donnée. Une méthode est donc nécessaire pour enregistrer et identifier les services en fonction de critères tels que l' Artefact : Spécification de service qu'ils réalisent, leur Artefact : Fournisseur de services, ainsi que d'autres classifications métier et techniques. Ce processus d'identification peut avoir lieu au cours du développement pour faire correspondre certains services à leur prise en charge, ou au cours de l'exécution pour permettre la fourniture dynamique de services (appel avec médiation). Pour être identifiable, un service doit fournir un ensemble de métadonnées permettant sa catégorisation. Ces métadonnées font partie de la spécification externe.

Pour plus d'informations, voir le Concept : Portefeuille de services et les Instructions : Médiation de services.

Spécifié de manière externe

La spécification externe permet à un service de publier ses informations détaillées, entre autres l'interface, l'emplacement, les règles et les classifications, sans que le client ait besoin d'accéder à ce service. Ces informations sont habituellement stockées dans un emplacement connu ou dans un registre de service spécialisé qui prend en charge les requêtes sur les métadonnées. Dans le monde des services Web, la norme actuellement admise pour la description des interfaces de service est la norme WSDL (Web Services Description Language), créée par le consortium World Wide Web.

Cependant, le produit Spécification de service est en réalité formé de trois éléments : la spécification d'interface, la spécification de comportement et la spécification de règle. La réalisation de ces différentes facettes nécessite bien plus que la seule définition des interfaces offerte par la norme WSDL.

Pour plus d'informations sur les registres de service, voir le Concept : Portefeuille de services.

Fondé sur un contrat

Dans la définition du glossaire citée ci-dessus, nous avons souligné que la spécification de service présentait une vue au fournisseur de services et une vue au client du service. Ces vues correspondent aux deux parties d'un contrat qui permet d'effectuer une distinction nette entre la spécification et l'implémentation.

Le tableau suivant décrit la manière dont les différentes facettes d'une spécification de service affectent aussi bien le fournisseur que le client de la spécification.

Rôle Spécification d'interface Spécification de comportement Spécification de règle
Pour le fournisseur Définit l'ensemble des opérations et des messages auxquels doit répondre le service. Toutes les opérations doivent répondre aux et avec les bons messages. Définit le comportement que ce service doit prendre en charge. Si la spécification de comportement est formelle et exhaustive, il est possible de tester la conformité d'une implémentation à cette spécification. Définit un ensemble de contraintes auxquelles peut être soumise l'implémentation du service, et un ensemble de qualités de service qui doivent être réalisées.
Pour le client Définit l'ensemble des opérations susceptibles d'être appelées. Définit les exigences de protocole que le client doit réaliser (ordre des opérations, flux de données, etc.). Indique également les opérations que le client doit implémenter pour prendre en charge les collaborations. Définit les contraintes, telles que les exigences de sécurité, que le client doit connaître lorsqu'il communique avec ce service. Identifie également les qualités de service qu'un client peut obtenir d'un fournisseur donné.

Cette spécification de service, qui peut être considérée comme une mise en oeuvre de la conception par contrat, est une étape nécessaire à l'obtention de services identifiables et dynamiquement reconfigurables.

Relié au métier

En général, s'il existe une relation entre les modèles métier qui représentent les opérations du métier et les modèles de conception des applications informatiques qui les prennent en charge, le lien établi est au mieux très lâche. Le plus souvent, ces modèles sont totalement déconnectés l'un de l'autre. Si le processus RUP offre des conseils sur la transition des modèles métier vers les modèles de cas d'utilisation du système (voir les instructions Des modèles métier aux systèmes), la mise en correspondance de ces deux modèles nécessite un certain nombre de transformations à mesure que le niveau de granularité et d'abstraction passe de la perspective métier à la perspective technologies de l'information.

En général, deux catégories possibles de services apparaissent clairement : les services métier et les services liés à l'infrastructure. Voir le Concept : Portefeuille de services pour plus d'informations sur la classification des services.

Les architectures SOA possèdent une caractéristique importante : le niveau de granularité des services décrits dans une solution orientée services est tel que les opérations effectuées par ces services sont souvent identifiables à partir d'un niveau métier. En raison de cette hausse du niveau de granularité lors de la prise en charge informatique, les tâches identifiées dans les modèles de processus métier sont souvent directement réalisables en tant qu'opérations sur des services. Par conséquent, les utilisateurs métier de solutions informatiques font davantage partie du processus d'analyse et de conception. Il est également intéressant de noter que ce lien plus étroit établi avec le modèle de processus métier associe plus directement les services en tant que produits informatiques aux objectifs métier modélisés dans la discipline RUP de modélisation métier.

Pour obtenir des informations plus détaillées sur le lien entre les modèles métier et de service, voir l'Activité : Analyse des actifs existants.

Modélisation d'un service

Lors de la modélisation du service, utilisez le Profil de langage UML pour les services logiciels et les conseils livrés pour chaque élément du profil. En général, les éléments qui forment la vue statique des services et les spécifications de service dans un modèle de services figurent dans le diagramme ci-dessous.

Diagramme décrit dans le contenu textuel.

  • Le fournisseur de services "UpdateCustomerAddressLegacyProvider" (Fournisseur existant Mise à jour adresse client) fournit un service "UpdateCustomerAddress" (Mise à jour adresse client).
  • Le service "UpdateCustomerAddress" implémente la spécification de service "IUpdateCustomerAddress".
  • La spécification de service "IUpdateCustomerAddress" comporte une seule opération : "execUpdateCustomerAddress".
  • L'opération "execUpdateCustomerAddress" admet un seul message d'entrée : "UpdateCustomerRequest" (Requête mise à jour client).
  • L'opération "execUpdateCustomerAddress" renvoie un seul message de sortie : "UpdateCustomerResponse" (Réponse mise à jour client).

La vue de structure et la vue de composition du modèle enregistrent la communication entre les services et le partitionnement de la solution. Cet aspect est abordé dans Concept : Composition et chorégraphie des services et Concept : Partitionnement de solution.

Méthodes alternatives

Comme cela est souvent le cas en modélisation, il existe d'autres méthodes pour modéliser la même structure logique et, dans certains cas, les techniques peuvent être utilisées pour représenter des détails techniques supplémentaires. Par exemple, lorsque vous modélisez la notion de fonctions fournies et requises pour un service, vous pouvez choisir de stéréotyper les interfaces qui décrivent ces fonctions en tant que spécifications de services et utiliser une classe non stéréotypée pour représenter le type combiné ou vous pouvez décider de stéréotyper la classe même et non pas les interfaces. Ces deux options sont représentées dans la figure ci-dessous.

En général, vous devez stéréotyper les interfaces si elles doivent être utilisées par d'autres services dans un contexte différent ; la méthode empirique consiste donc à stéréotyper tout élément considéré comme étant la description réutilisable. Lorsque vous créez un service sur un fournisseur de services (en termes UML, un port sur une classe ou un composant), vous devez sélectionner la classe ServiceType ou MyService en tant que type du port stéréotypé, comme illustré ci-dessous.

Notez que la structure obtenue sera identique pour la classe ServiceType ou la classe MyService, le port indique une interface requise et une interface fournie - éventuellement une interface de rappel que le client doit obligatoirement fournir. Toutefois, dans certains cas, il est utile de séparer explicitement les fonctions requises et les fonctions fournies dans des descriptions de service distinctes. Dans ce cas, deux classes sont nécessaires pour réaliser les spécifications de services présentées plus haut. La figure ci-dessous illustre ces classes.

Lors de la création du fournisseur de services, deux ports stéréotypés sont nécessaires, comme illustré ci-dessous, un pour représenter la fonction d'appel et l'autre pour représenter la fonction de rappel.

Le besoin de ces fonctions supplémentaires dépend de la tâche exécutée et du niveau de formalité que vous devez inclure dans les modèles. Le dernier exemple indique très clairement qu'il existe des notions distinctes d'une interface d'appel et d'une interface de rappel ; que se passe-t-il, toutefois, si le même fournisseur implémente un certain nombre d'extrémités de service ? La multiplication des ports peut rendre le résultat final illisible et incompréhensible.

Pour plus d'informations sur la conception et l'implémentation des services, voir la Tâche : Décisions de réalisation de services de document.