Concept: Partitionnement de la solution
Dans ce concept, nous présentons les principes guidant le partitionnement d'un système en clusters logiques d'éléments sur la base de différentes questions relatives à l'organisation. Ces questions peuvent refléter des frontières métier, des frontières physiques et des frontières de nature plus abstraite.
Relations
Description principale

Introduction

On a beaucoup écrit sur la décomposition de conceptions logicielles en composants ou en sous-systèmes. De nombreux documents font également mention de la nécessité de comprendre la topologie de déploiement requise par une application dans les premiers stades de son cycle de vie, de façon à prendre des décisions pertinentes en matière d'architecture. Il existe cependant de nos jours très peu de mécanismes identifiés ou utilisés pour faciliter le partitionnement logique d'un système lors de l'analyse de l'architecture, permettant de prendre aisément, au niveau du modèle, des décisions concernant la topologie logique d'une solution et les contraintes établies par les exigences non fonctionnelles, avant de générer la conception détaillée et les produits d'implémentation. La page suivante présente un ensemble d'éléments de modèle simples permettant de tenir ce raisonnement. Bien que développées dans l'optique de solutions orientées services, ces techniques peuvent s'appliquer à tout type de modélisation d'architecture logicielle.

Partitions et couches

Les définitions ci-dessous, extraites du glossaire du processus RUP (Rational Unified Process), permettent de comprendre la différence existant entre les notions de couche et de partition. Etonnamment, le terme tier (niveau), pourtant courant dans la description de l'architecture logique d'une solution, n'apparaît pas dans le glossaire RUP.

Couche
(1) méthode spécifique de regroupement de packages dans un modèle au même niveau d'abstraction.
(2) organisation de discriminants ou de packages au même niveau d'abstraction. Une couche représente un segment horizontal de l'architecture, tandis qu'une partition correspond à un segment vertical.
Partition
(1) dans les diagrammes d'activités : partie d'un diagramme d'activités qui organise les responsabilités des actions. Voir aussi : ligne de séparation.
(2) dans une architecture : sous-ensemble de discriminants ou de packages au même niveau d'abstraction. Une partition représente un segment vertical d'une architecture, tandis qu'une couche correspond à un segment horizontal.

Une partition contient donc un ensemble d'éléments représentant une partie de l'architecture ; mais comment l'architecte logiciel segmente-t-il le modèle ? La réponse est apparemment simple : les partitions et les couches sont des constructions organisationnelles ; à un niveau d'architecture, elles ne représentent qu'une organisation logique. Quels aspects de l'organisation d'une solution souhaitez-vous alors représenter ? Par exemple, si la vue de modèle que vous développez est en rapport avec la sécurité, vous pouvez avoir l'intention de représenter les zones de confiance [JOHNSTON].

Pour plus d'informations, voir les concepts Répartition en couches et Patterns de distribution.

Que peut représenter une partition ?

Comme nous l'avons indiqué précédemment, une partition peut être utilisée pour représenter toute question relative à l'organisation que l'architecte peut vouloir traiter. Nous présentons ici des vues communes construites dans un modèle. Notez que l'une des principales caractéristiques des partitions consiste dans le fait qu'elles n'impliquent pas d'appartenance/confinement ; un service peut donc apparaître simultanément dans plusieurs partitions.

Organisation logique de la solution : dans ce cas, les partitions représentent la classification logique des éléments dans une solution donnée. Par exemple, dans le contexte d'une application métier, nous pouvons utiliser des partitions pour représenter la distinction établie entre les services d'interaction utilisateur, les services métier et les services d'infrastructure. Ce type de vue correspond davantage à l'utilisation de couches dans RUP pour décrire les niveaux d'une application. Cependant, la répartition en couches des services n'étant pas aussi aisée que celle des composants, nous avons recours aux partitions. Pour plus d'informations sur ces classifications de services, voir le Concept : Portefeuille de services.

Diagramme décrit dans le contenu textuel.

Distribution physique de haut niveau : dans ce cas, les partitions peuvent être utilisées pour distinguer les services locaux des services à distance, du moins lorsque la distance physique impose des contraintes à l'architecture. Par exemple, il est important de remarquer que les services client, compte et commande sont hébergés dans notre centre de données principal et que le portail d'échange de données informatisé (Electronic Data Interchange - EDI) est hébergé sur un centre de données secondaire, lorsque nous découvrons également que la connexion à bande passante entre ces deux centres est gérée et qu'il convient de contrôler attentivement la communication entre ces partitions.
Frontières de l'appartenance/application métier : dans ce cas, les partitions sont utilisées pour représenter l'appartenance des services à une zone métier ou une zone d'application. Nous pouvons par exemple observer que certains services "appartiennent" aux ressources humaines, d'autres au département ventes et d'autres encore au marketing. Il ne s'agit certes pas d'une question d'ordre architectural, mais la plupart des projets doivent traiter d'aspects n'impliquant ni technologie ni architecture, mais plutôt des considérations d'ordre social ou politique relatives à l'organisation. En ce sens, les partitions nous permettent de voir la façon dont les interactions existant entre les services traversent ces frontières et peuvent avoir un impact sur le processus de développement en nécessitant le support des parties prenantes en cas de changements affectant l'ensemble de l'organisation. Dans ce cas, l'Artefact : Systèmes métier, identifié pendant l'analyse métier, forme les catégories pour ce modèle.
Frontières du processus métier : dans ce cas, nous représentons des zones de processus de bout en bout à l'aide de partitions, en regroupant les services en fonction des processus qu'ils prennent en charge. Le diagramme ci-dessous oppose la vue de processus (ombrée) à la vue de systèmes métier, représentée par les barres verticales. Il est souvent important de lier ces deux vues de services déjà déployés et de services prévus dans un projet.

Diagramme décrit dans le contenu textuel.

Cette relation entre la zone métier verticale et le processus intermétier est une notion clé pour la compréhension de la façon dont chaque zone métier fournit des services aux processus qui exécutent réellement le métier. Pour notre exemple, cette vue regroupe les services identifiés précédemment en nouvelles partitions, comme indiqué ci-dessous.

Diagramme décrit dans le contenu textuel.

Pour plus d'informations sur le lien entre la modélisation de processus et l'identification de services, voir l'Activité : Analyse des actifs existants.

Partitions du modèle de service

Dans le modèle de service, un élément de modèle spécifique, la partition de service, est utilisé pour modéliser les partitions logiques. La représentation UML 2.0 des partitions est basée sur l'utilisation de l'élément de modèle de classe (alors que certains utilisateurs préfèrent utiliser des sous-types de classe tels que le composant ou le noeud lorsqu'ils sont plus adaptés à leurs besoins) et utilise une structure composite pour définir les services dans une partition et la communication entre ces services. L'élément Partition de service est représenté dans les figures ci-dessus et peut contenir non seulement des instances deFournisseurs de services mais également des instances d'autres partitions ; sa composition peut donc être plus poussée si nécessaire. Une partition de service peut également définir une ou plusieurs passerelles de service nommées et saisies en tant que ports UML 2.0. Ces ports sont saisis par les Spécifications de service de la même façon qu'un Service et peuvent donc être considérés comme des services virtuels définissant l'interface d'une partition.

Ainsi, il peut par exemple être pertinent de remarquer que la zone de processus de gestion des commandes est accessible via la même interface que le fournisseur de services de saisie des commandes dans le diagramme ci-dessus. Nous appelons cela remonter l'interface depuis le service jusqu'à la partition. Le diagramme ci-dessous, qui suit cette règle, montre comment le fournisseur de services de saisie des commandes communique avec les autres services de la partition.

Diagramme décrit dans le contenu textuel.

L'une des fonctionnalités de la passerelle de service consiste dans la capacité de créer des vecteurs de communication entre les clients, situés hors d'une partition, et les services, qui se trouvent à l'intérieur. Cela permet aux services de ne traiter que certaines liaisons de protocole au sein d'une partition ; ils utilisent par exemple un protocole offrant de meilleures performances ou un meilleur niveau de sécurité au sein des frontières de la partition et exposent certaines fonctionnalités aux clients sur un protocole différent. Pour plus d'informations, voir les instructions Médiation de services.

Notez également que, les partitions étant fondées sur des structures composites UML 2.0, il n'existe pas de relation de "confinement" entre la partition et les services ; il est donc possible, comme indiqué plus haut, de représenter les mêmes services dans plusieurs partitions ou vues. Si cette flexibilité est liée à la fonctionnalité des passerelles de service, l'architecte logiciel et le concepteur peuvent organiser les services en clusters, en les regroupant de façon logique, et permettre aux passerelles de service d'exposer pour les clients uniquement les interfaces pertinentes.

Définition de partitions strictes

Une partition stricte est une partition dont tous les services sont accessibles uniquement par des clients/services situés hors de la partition, via des passerelles de service. Cela implique que la partition de service dispose de son propre ensemble d'interfaces ; on peut donc la considérer comme un fournisseur de services logique de niveau supérieur. Cela se révèle particulièrement utile dans le cas de partitions représentant des frontières d'application métier ou des frontières de processus métier. Cela permet également de faire en sorte que le processus représenté identifie les interfaces qu'il expose au reste du métier, ainsi que les services publiquement disponibles prenant en charge la zone de processus. La partition de gestion des commandes représentée ci-dessus est une partition stricte, mais ce concept de "rigueur" ne peut être jugé qu'en évaluant une partition et n'est pas une propriété de l'élément de modèle en lui-même.

Dans l'exemple ci-dessous, la partition de gauche peut être considérée comme stricte car le client (hors de la partition) peut uniquement communiquer avec le fournisseur de saisie de commande (dans la partition) via une passerelle. La partition représentée dans la partie droite du diagramme n'est pas considérée comme une partition stricte car le client communique directement avec le fournisseur de saisie de commande, dans la partition.

Il est important d'être conscient que la modélisation de partitions strictes, y compris l'utilisation même de passerelles, est facultative et doit être considérée simplement comme un outil permettant la modélisation de communications explicites entre les partitions (quels que soient les éléments qu'elles représentent) ; en outre, pour de nombreuses fonctions, le temps système supplémentaire peut ne pas être garanti.

Références

[JOHNSTON] Simon Johnston, Modeling Security Concerns in Service-Oriented Architecture (Modélisation de questions de sécurité en architecture orientée services). IBM developerWorks 2004.