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