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.
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.
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.
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.
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.
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.
-
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.
|