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