Instructions: Patterns de composant de service
Ces instructions détaillent un ensemble de patterns pouvant être utilisés dans le développement des composants de service, dans le cadre de la réalisation de services.
Relations
Description principale

Introduction

En identifiant les éléments techniques et fonctionnels constitutifs d'un composant de service, nous avons délégué les responsabilités fonctionnelles du sous-système à la fonctionnalité fournie par le composant de service. Les composants fonctionnels offrent la fonctionnalité métier requise alors que les composants techniques fournissent une fonctionnalité générique telle que l'authentification, le traitement des erreurs, l'audit, la consignation, etc. qui sont des fonctions opérationnelles et non fonctionnelles.

Un modèle de services est un artefact produit lors de la phase de conception. En tant que tel, il n'est pas directement lié à l'implémentation des services. Cependant, c'est la réalisation d'une spécification de service par un composant de service qui implémente véritablement un service ou un ensemble de services. La spécification de service fournit le contrat d'implémentation ; la/les technique(s) utilisée(s) pour implémenter le service n'ont pas d'importance tant que ce contrat est rempli. Dans le concept Architecture orientée services, nous avons inséré l'image suivante pour montrer la relation entre les services identifiés et les composants et objets qui réalisent leur implémentation.

 Diagramme décrit dans le texte d'accompagnement

Ainsi, nous pouvons voir comment le modèle de conception RUP peut être utilisé pour enregistrer la conception des couches composant et objet, grâce à des modèles et des artefacts d'implémentation qui enregistrent les détails de la couche objet, ainsi qu'à des artefacts de déploiement et d'implémentation associés. La relation entre le modèle de service et le modèle de conception de composant possède des caractéristiques importantes : l'ensemble des spécifications de service représente les contrats à remplir ; les opérations identifiées sur les spécifications doivent être implémentées telles quelles ; enfin, les clients des services utilisent ce même modèle pour comprendre l'interface et le comportement des services qu'ils prévoient d'utiliser. Il existe ainsi une relation directe, et en général un-un, entre la spécification de service et un artefact d'implémentation qui agit comme point d'entrée initial d'implémentation pour le service.

Considérons par exemple le diagramme suivant, représentant un fournisseur de services, qui illustre les détails des éléments de modèle utilisés dans sa définition.

Diagramme décrit dans le contenu textuel.

Il est primordial que le composant de service soit directement traçable depuis le modèle de services . Le procédé le plus simple consiste à exploiter la nature de l'élément de spécification de service : il s'agit d'une interface UML pouvant être réalisée par le composant de service, ce qui garantit sa conformité à la spécification structurelle. Le résultat obtenu serait alors le suivant :

Diagramme décrit dans le contenu textuel.

Il incombe maintenant à l'implémenteur de composants de définir un ensemble de composants et de classes qui établissent le comportement du composant obtenu.

Types des composants de service

Composants fonctionnels

La constitution de ces composants fonctionnels en un composant de service à granularité plus élevée n'est pas simplement structurelle ; elle implique également la définition d'un flux, c'est-à-dire, la collaboration des composants fonctionnels afin de fournir une fonctionnalité prenant en charge les processus métier. Comme nous l'avons vu plus haut, la fonctionnalité de ces composants métier est activée via les services (implémentés par l'objet de niveau le plus faible du composant ou la structure de systèmes existante) définis.

Il est important de noter que cette étape inclut des activités OOAD traditionnelles. La conception d'objet cible un cadre centré et correctement partitionné. La conception orientée objet traditionnelle tend à créer des graphiques d'objet plus dépendants et plus grands alors que si l'analyse des sous-systèmes respecte l'identification des domaines fonctionnels au sein de l'entreprise, il est possible de mettre l'accent et de diriger l'effort de conception vers un cadre très clairement défini. L'on obtient alors un ensemble de modèles d'objet dont l'association est plus souple (diagrammes de classe et diagrammes de séquence déclenchés par des cas d'utilisation système).

Composants techniques

La constitution des composants techniques en composants de service à granularité plus élevée est identique à celle des composants fonctionnels. Les composants techniques tels que l'authentification, la consignation et la génération de rapports, peuvent être utilisés sur les processus métier.  Ces composants communs sont nécessaires pour former l'infrastructure prenant en charge les composants fonctionnels.  L'un des écarts clés des processus métier est dû aux règles métier, comme indiqué dans la figure ci-dessous "Pattern de composant d'entreprise". Ces écarts sont généralement capturés pendant la tâche Conception orientée vers les écarts.

Patterns de composant de service

Nous avons indiqué que le composant de service réalisait simplement la spécification de service. Toutefois, cette déclaration n'est pas d'une grande aide à l'implémenteur, lequel doit transformer une définition de service à granularité grossière en un ensemble de classes d'implémentation et d'artefacts à granularité fine pour fournir le comportement du service. Pour ce faire, il s'appuie généralement sur des patterns qui offrent une structure au composant de service obtenu, en les utilisant soit comme infrastructure de départ, soit comme patterns spécifiques pour traiter des exigences de règle particulières.

Choix du pattern, choix guidé par les exigences non fonctionnelles, architecture [plus]

Notez que les stéréotypes supplémentaires insérés ici sont décrits dans l'Artefact : Composant de service.

Pattern initial de composant de service

Lors de la définition de la structure initiale d'un service, le pattern suivant peut servir de point de départ en vue d'être personnalisé et étoffé.

Diagramme décrit dans le contenu textuel.

Les éléments du pattern sont les suivants :

  • Composant de façade : la façade réalise la même interface que le composant de service et offre des capacités de base pour valider le message avant l'exécution d'une requête sur les composants spécifiques à une opération. Pour des raisons de clarté, nous ajoutons alors le stéréotype <<facade>> à ce composant.
  • Composant spécifique à une opération : le plus souvent, étant donné la granularité des services, il s'avère utile de disposer d'un composant ou d'une classe à part pour l'implémentation de chaque opération fournie par le service.

Le diagramme suivant montre la vue de structure composite de ce pattern. En l'occurrence, le composant de service délègue ses fonctions à la façade : les clients qui appellent des opérations sur le composant de service sont en réalité servis par le composant de façade. Notez qu'il est également possible d'utiliser des ports UML 2.0 pour exposer les interfaces et expliciter cette délégation à l'aide de connecteurs.

Diagramme décrit dans le contenu textuel.

Pattern de composant de service à opération unique

Dans certains cas, lorsque les services identifiés dans le modèle de services comportent plusieurs opérations, il est plus approprié d'implémenter les opérations une à une, en tant que services autonomes, en distinguant la vue de service logique de la vue physique. Un tel pattern comporte plusieurs avantages (flexibilité de sourçage, bonne disponibilité, meilleure gestion des versions, possibilités d'évolution), mais fait disparaître la notion d'ensemble d'opérations associées, habituellement propre à l'interface d'un service.

La modélisation des composants de service selon ce pattern contient un seul <<Service Component>> (Composant de service) ; celui-ci réalise une seule interface qui comporte une seule opération. Tous ces éléments sont nommés selon les conventions usuelles et représentés ci-dessous.

Diagramme décrit dans le contenu textuel.

Dans ce cas, comme nous l'avons déjà mentionné, aucun élément du pattern ci-dessus ne réalise directement la spécification de service initiale. Par conséquent, il semble intéressant d'insérer dans le modèle un élément qui mette en évidence le lien de traçabilité vers la spécification de service. Dans l'exemple ci-dessous, nous avons inséré un composant qui comporte le stéréotype <<subsystem>>, et qui, selon la notation, implémente la spécification de service et possède les éléments décrits ci-dessus.

Diagramme décrit dans le contenu textuel.

Ce pattern n'inclut pas le composant <<facade>>, car ce sont les clients qui doivent identifier les services qu'ils utilisent.

Pattern d'opération avec médiation

Lorsque la requête d'un client du service peut être acheminée pour exécution vers l'un des composants d'opération, il est possible d'ajouter au pattern un médiateur qui acheminera ces messages, comme illustré ci-dessous. Notez que la classe ou le composant ajouté comporte le stéréotype <<mediator>> pour plus de clarté. Le mécanisme exact de la médiation est indéfini. Il se peut qu'un ensemble statique d'implémentations soit connu à l'avance, et qu'un quelconque registre soit utilisé pour le mappage vers l'implémentation particulière en fonction du client, du contenu du message de requête, etc. Ce pattern n'est pas destiné à être utilisé avec le pattern à opération unique illustré ci-dessus.

Diagramme décrit dans le contenu textuel.

Il affecte également la vue de structure composite du composant de service. Comme vous pouvez le constater ci-dessus, le lien du médiateur part de la façade, qui l'utilise pour diriger les appels vers les composants d'opération.

Diagramme décrit dans le contenu textuel.

Si un registre externe au médiateur est utilisé, il n'est pas toujours possible d'indiquer les dépendances statiques d'utilisation depuis le médiateur vers les composants d'opération ou d'insérer des connecteurs entre les éléments du diagramme de structure composite. Comment modéliser alors une dépendance du médiateur vers les composants d'opération ? Dans le diagramme suivant, nous avons inséré une interface qui doit être implémentée par chaque composant d'opération. Ainsi, nous pouvons modéliser l'utilisation du médiateur vers l'interface, comme indiqué ci-dessous.

Diagramme décrit dans le contenu textuel.

Nous changeons également les relations dans le diagramme de structure composite, en ajoutant un nouvel élément saisi par l'interface, et indiquons sur le connecteur la multiplicité entre le médiateur et les composants d'opération (voir ci-dessous).

Diagramme décrit dans le contenu textuel.

Composants d'accès aux données

Eventuellement, lorsque des opérations de service partagent des exigences de données communes, il peut s'avérer utile de mettre en évidence les composants spécifiques qui offrent à l'implémentation des capacités de gestion de données. Notez que la classe ou le composant concerné comporte le stéréotype <<data access>> pour plus de clarté.

Diagramme décrit dans le contenu textuel.

Pattern de composants d'entreprise

Le pattern de composants d'entreprise ci-dessous montre le composant de service jouant le rôle de façade pour les composants fonctionnels et techniques sous-jacents. Les services sont exposés à la limite du composant de service, sur la façade du composant. Les demandes de services sur la façade sont transmises à un médiateur qui achemine alors le message vers le composant fonctionnel ou technique approprié.

Diagramme décrit dans le texte d'accompagnement

Pattern de composants d'entreprise

Les dépendances et les besoins entre les composants fonctionnels et les composants techniques, pour une agence de location de véhicules par exemple, sont décrits ci-dessous.

Diagramme décrit dans le texte d'accompagnement

Composant de service de réservation d'une agence de location de véhicules utilisant le pattern de composants d'entreprise

La collection de modèles de composant de sous-système est rassemblée dans le modèle de composant fonctionnel qui montre la dépendance des composants fonctionnels par rapport aux composants techniques et les relations existant entre les composants fonctionnels. Les sous-processus au niveau noeud qui sont affectés à la façade du sous-système doivent être spécifiés en tant que service qui seront fournis par le sous-système. Ces sous-processus sont pris en charge et implémentés via un ensemble de cas d'utilisation système plus détaillé, encapsulé dans la structure du sous-système. La réalisation des cas d'utilisation est dépendante des composants fonctionnels. A leur tour, les composants fonctionnels dépendent des composants techniques et des utilitaires pour leurs besoins en infrastructure.