Produit: Modèle de services
Le modèle de services est un modèle des éléments de base d'une architecture orientée services (SOA). Le modèle de services est utilisé en tant qu'entrée principale pour les tâches d'implémentation et de test.
Objet

Le modèle de services est une abstraction des services informatiques implémentés au sein d'une entreprise et prenant en charge le développement d'une ou plusieurs solutions orientées services. Il est utilisé pour mettre en place et documenter la conception des services logiciels. Il s'agit d'un produit exhaustif et composite qui englobe tous les services, fournisseurs, spécifications, partitions, messages, collaborations et les relations entre ces différents éléments. Il permet les opérations suivantes :

  • Identifier des services candidats et capturer des décisions sur les services qui seront exposés
  • Spécifier le contrat entre le fournisseur de services et le consommateur des services
  • Associer des services aux composants nécessaires pour réaliser ces services
Relations
RôlesResponsable: Modifié par:
Description
Bref aperçu

Le modèle de services est souvent une collection hétérogène d'actifs physiques, y compris des modèles UML, des documents et éventuellement des entrées dans un outil de gestion des exigences. Toutefois, le modèle de services doit contenir les éléments logiques suivants (voir la description principale).

  • Portefeuille de services
  • Hiérarchie de services
  • Exposition de services
  • Dépendances de service
  • Composition et flux des services
  • Exigences non fonctionnelles de service
  • Messages de service
  • Décisions de gestion des états
  • Décisions de réalisation
Description principale

Le modèle de services capture les détails d'un ensemble de services sur des itérations multiples, en élaborant progressivement les détails. Le modèle de services peut être utilisé à différents niveaux de portée :

  • Développement axé service, dont la portée du projet consiste dans le développement du service indépendamment (dans la mesure du possible) des autres services. La modélisation devrait donc englober les cas d'utilisation, l'architecture et les modèles de conception et d'implémentation en tant que segment vertical pour ce service.
  • Développement axé projet, dans lequel un projet implique la spécification d'un certain nombre de services afin de prendre en charge un ensemble d'exigences d'application ; dans ce cas, la portée est étendue au niveau application et peut impliquer un certain nombre de services. Il existe en effet un ensemble de modèles de niveau application pour les cas d'utilisation et l'architecture, ainsi qu'un ensemble de modèles de conception et d'implémentation spécifiques au service.
  • Développement axé entreprise, ou gestion de portefeuille de services, dont la portée consiste uniquement dans l'enregistrement des spécifications de service et du partitionnement logique, mais portant sur l'ensemble de l'entreprise. Cela permet aux concepteurs et aux architectes de prendre des décisions de grande ampleur concernant la totalité du portefeuille, mais des projets distincts restent nécessaires pour développer les modèles de conception et d'implémentation pour les services identifiés (et les applications client).

Le diagramme suivant illustre les aspects clés du modèle de services et les relations entre ces aspects et les activités d'identification, de spécification et de réalisation.

 

Eléments d'identification

La première élaboration commence par une liste de services candidats dans le Portefeuille de services créé pendant l'Activité : Analyse des actifs existants, à l'aide de techniques telles que la décomposition de processus (voir Concept : Décomposition de processus métier). Ces services sont catégorisés en fonction de leur domaine fonctionnel et de la technique utilisée pour les identifier. Il est important de noter que le portefeuille de services que nous décrivons ici est un portefeuille spécifique d'un projet et qu'il contient les services candidats identifiés à l'aide des différentes techniques d'analyse décrites dans l'Activité : Analyse des actifs existants. Les services identifiés à ce stade sont souvent uniquement fournis en tant que nom et éventuellement en tant que description fonctionnelle. Un simple document contenant cette liste de services peut souvent suffire, toutefois si l'approche UML est utilisée, le portefeuille est géré en tant que collection d'Artefact : Spécification de service et peut être créé à l'aide du Rapport : Portefeuille de services.

Dès que possible, les services de la liste sont organisés en Hiérarchie à l'aide d'un schéma de classification fonctionnelle (généralement basé sur des domaines fonctionnels identifiés pendant la décomposition de domaine). Cette hiérarchie montre un schéma de classification principal pour les services - ce schéma de dépendance des appels de processus est donc important pour comprendre les relations entre les services identifiés pendant les activités de décomposition. La représentation de la hiérarchie peut être sous forme de document, de tableur ou de modèle UML (auquel cas, il convient d'utiliser l'Artefact : Partition de service pour modéliser les domaines fonctionnels).

Notez qu'il est également possible que le terme portefeuille de services représente le portefeuille de services à l'échelle de l'entreprise (comme exprimé dans Concept : Portefeuille de services) qui a une durée de vie supérieure au portefeuille spécifique d'un projet. Il existe en effet une relation entre le portefeuille de l'entreprise et celui d'un projet, comme illustré dans la figure ci-dessous.

Eléments de spécification

L'une des premières étapes de l'Activité : Effectuer la spécification de service est de décider et de documenter l'exposition des services - c'est-à-dire de documenter les services candidats qui doivent être développés et exposés en tant services réels. Une technique clé est la Tâche : Appliquer les tests Litmus de services qui fournit des instructions spécifiques sur le mode d'évaluation des services devant être exposés. En termes de représentation UML du modèle de services, les spécifications de service qui ont été développées pendant l'identification sont marquées, à l'aide de la propriété d'état, comme étant exposées, puis sont détaillées plus avant dans le modèle. Pendant l'analyse des services pour l'exposition, il est possible de commencer à regrouper des services en offres logiques et de les modéliser au format UML à l'aide de l'Artefact : Fournisseur de services.

Pendant les spécifications de service, il est important de capturer toutes les dépendances de services pour différentes raisons - par exemple, les services dont le nombre de dépendances est élevé sont plus difficiles à réutiliser dans des environnements différents alors que les services possédant de nombreux éléments dépendants indiquent des capacités de base. Les dépendances de service peuvent être capturées au format texte, souvent dans un format tabulaire (voir Rapport : Dépendances de service) ou elles peuvent être modélisées à l'aide de la représentation UML du modèle de services. Il est également important de savoir que certaines dépendances sont dues à des communications interservices et qu'il existe alors des détails spécifiques, associés à cette dépendance (protocoles de communications obligatoires, sécurité, etc) qui peuvent être documentés à l'aide du modèle UML et plus particulièrement de l'Artefact : Canal de service dans les modèles de collaboration.

Dans la définition de services, il est courant de reconnaître des services composites qui ne sont là que pour chorégraphier un ensemble de services à la granularité plus fine ; cette rubrique Composition et flux doit décrire la relation entre les services composites et les services composés ainsi que les dépendances entre les services, exprimées par le flux qui les parcourt. Dans la représentation UML, cette composition peut être décrite de manière appropriée (classes composites) ainsi que le flux (activités, interactions) et les techniques sont décrites dans le Concept : Composition et chorégraphie des services.

Il est essentiel de capturer également les exigences non fonctionnelles pour les services (alors de nombreuses rubriques ci-dessus mettent davantage l'accent sur les exigences fonctionnelles) et de capturer autant de détails que possible sur la qualité de service, les règles, etc. Dans ce domaine, il est possible d'exprimer les exigences dans un document textuel ; il peut être plus difficile de les exprimer directement en langage UML mais elles peuvent éventuellement être exprimées plus facilement à l'aide d'un produit de gestion des exigences. Lors de l'utilisation de la représentation UML du modèle de services, nous recommandons l'utilisation de l'Artefact : Document d'architecture logicielle RUP existant et de l'Artefact : Spécifications supplémentaires afin de capturer les exigences non fonctionnelles. L'un des aspects de l'architecture de solution non fonctionnelle concerne la Distribution et la disponibilité des services qui peuvent être documentés à l'aide du modèle UML et, notamment, de l'Artefact : Partition de service et l'Artefact : Passerelle de service.

Il est évident que l'analyse détaillée des Messages de service est essentielle pour le développement de spécifications de services réutilisables. Ces messages peuvent être dérivés de modèles de haut niveau ou peuvent être directement exprimés dans un format spécifique d'une technologie (par exemple XML Schema). Que ces messages soient décrits textuellement, dans un langage de schéma ou dans le modèle UML, ces définitions de message doivent tenir compte des considérations importantes énoncées dans la Tâche : Conception de messages et les Instructions : Pièces jointes de message correspondantes.

Il est vrai que, dans une architecture SOA, nous nous efforçons d'obtenir des services sans état, mais il n'est pas toujours possible ni même préférable d'en faire une idée fixe ; la rubrique Décisions de gestion des états doit permettre au concepteur de réfléchir sur les compromis, le coût et les avantages de la gestion des états dans les services. Pour aider ces décisions, la rubrique Instructions : Gestion des états pour les services fournit des exemples de types d'état qui doivent souvent être gérés par un service.

Eléments de réalisation

La réalisation des services concernent principalement trois domaines : les décisions concernant la réalisation réelle des services, l'identification des sous-systèmes et des composants pour réaliser les spécifications de service et enfin le développement de ces composants.

Lors de la documentation des décisions de réalisation, il est important de disposer d'une justification raisonnée et détaillée du choix de l'approche de sourçage et de développement, tel que cela est décrit dans la Tâche : Décisions de réalisation de services de document. De même que pour les exigences non fonctionnelles décrites plus haut, il est souvent difficile d'exprimer ces décisions (et de les détailler) dans la représentation UML. Les choix effectués pour chaque service devront donc être documentés séparément.

Propriétés
Facultatif
PlanifiéYes
Illustrations
Personnalisation
Incidence de l'absenceSans ce produit, il serait difficile de définir correctement des services et de spécifier les composants nécessaires à leur réalisation.  Cela pourrait entraîner des écarts dans le portefeuille de services, une prolifération de services inutiles, des incohérences liées à l'exposition des services et des incohérences dans la conception des composants nécessaires à la réalisation des services.
Causes justifiant le manque de nécessitéCe produit est inutile s'il n'est pas nécessaire d'externaliser des descriptions de service à la limite d'une frontière organisationnelle significative (c'est-à-dire à la limite d'un secteur d'activité majeur au sein d'une entreprise ou à la limite de l'entreprise).
Options de représentation

Le modèle de services est un produit de travail volumineux et il est généralement développé à l'aide d'un certain nombre de techniques ; par exemple, des modèles UML sont utilisés pour décrire des éléments de service, toutefois la présentation du produit de travail peut être un document contenant des diagrammes provenant du modèle UML. Le niveau auquel un projet spécifique repose sur les modèles UML dépend des compétences et de l'expérience du personnel impliqué et également des attentes des intervenants dans le projet. En général, nous recommandons de développer la plus grande partie possible du modèle à l'aide de la représentation UML, de l'intégrer à l'aide d'un contenu supplémentaire (notamment d'un texte de description) et de la présenter dans sa forme finale en tant que document.

Pour la représentation UML, voir Canevas : Modèle de services en langage UML.

Pour la représentation de documentation, voir Canevas : Modèle de services sous Word.

Plus d'informations