Exemple : Exemple de modèle d'architecture SOA

Description du problème Haut de la page

Cet exemple traite des problèmes rencontrés par une enseigne commerciale qui a choisi de réimplémenter en tant que services certaines fonctions utilisées par les applications de ses Terminaux Points de Vente (TPV). Actuellement, l'application commerciale est une application monolithique aux composants étroitement couplés, mais certains d'entre eux résident sur les serveurs en magasin et certaines requêtes sont même réacheminées depuis ces serveurs vers les serveurs centraux de l'entreprise. Tout le problème réside dans les difficultés de maintenance de l'infrastructure de vente en général et de l'application commerciale en particulier, en raison du couplage étroit entre les composants et du recours à une technologie et à des protocoles propriétaires lors du développement des composants et de leur connexion.

Dans les générations précédentes, les machines utilisées par les TPV étaient propriétaires et à faible capacité, et la bande passante était restreinte aussi bien en magasin qu'en dehors (ces restrictions ont aujourd'hui entièrement disparu). Compte tenu de cet aspect et du recours de plus en plus fréquent à l'architecture orientée services dans les systèmes expéditeurs de l'entreprise, il a été décidé que certaines capacités offertes par les serveurs en magasin et par les serveurs centraux devaient être décrites en tant que services dans l'application commerciale.

Portée et objectifs du projet Haut de la page

Initialement, les capacités envisagées ont été choisies parce qu'elles possédaient un pattern commun. En effet, elles nécessitent actuellement, dans l'application commerciale, une logique qui leur permette d'interroger plusieurs magasins de données. Par conséquent, les services proposés fournissent non seulement une interface commune, mais dispensent également l'application commerciale de connaître explicitement l'emplacement des données et d'avoir à gérer plusieurs protocoles. L'accès à ces services s'effectuera par le biais d'une invocation RMI depuis l'application commerciale vers le service en magasin, et à l'aide du protocole SOAP par le biais de la messagerie JMS depuis le service en magasin vers le service central.

Identification des services Haut de la  page

Cette section résume les étapes effectuées par l'équipe d'architecture, composée à la fois de membres du service informatique de l'enseigne commerciale et de consultants externes appelés en tant qu'experts en développement de solutions orientées services. Notez que les étapes indiquées ci-dessous n'ont pas pour but de représenter une série d'activités RUP recommandées ; elles ne font qu'énumérer les activités d'un projet réel.

Il est important de noter que ce projet consiste à améliorer l'implémentation technique de fonctions existant à l'heure actuelle ; il exclut donc une grande quantité de temps consacrée à la modélisation ou à l'analyse métier, car les modèles créés pour l'application originale sont réutilisables. L'ensemble de modèles actuel (sur la gauche dans le diagramme ci-dessous) suit la structure ci-après, en présentant un modèle de cas d'utilisation RUP, un modèle d'analyse pour les composants courants de l'application commerciale, le modèle de conception détaillée, et enfin, un ensemble de modèles d'implémentation pour les équipes de développement Java.

Diagramme décrit dans le contenu textuel.

Le modèle de service (sur la droite du diagramme ci-dessus) a été introduit en tant qu'amélioration du modèle d'analyse décomposé en un ensemble de services possédant leurs propres modèles d'implémentation. La conception de l'application commerciale peut désormais être modifiée pour indiquer l'utilisation de ces services courants et représenter la relation entre l'application et les modèles de service Java.

Création de modèles de service

Le modèle de service d'assistance en magasin a été créé conformément au profil UML pour les services logiciels et à un modèle canevas (inclus dans Rational Software Architect), comme décrit dans le diagramme ci-dessous. Ce modèle a été identifié comme une amélioration du modèle d'analyse, comme illustré ci-dessus. Comme vous pouvez le voir, cette structure est présentée dans un diagramme de vue d'ensemble qui montre les dépendances entre les vues recommandées par le canevas.

Diagramme décrit dans le contenu textuel.

Les liens du diagramme, en regard des packages de vue, permettent d'effectuer une navigation rapide dans le modèle ; ils seront complétés dans les sections suivantes.

Pour plus d'informations, reportez-vous au guide d'utilisation de l'outil Création d'un modèle de service dans RSA.

Identification des partitions de service (emplacement)

D'après la description du problème ci-dessus, il apparaît clairement que le partitionnement du système peut être abordé de différentes manières. Par exemple, nous pouvons introduire des partitions qui représentent la gestion des stocks, la gestion des services et des garanties et les opérations du point de vente (recherche de prix, de clients, etc.), bien qu'elles ne constituent pas la première préoccupation de l'architecte. Les partitions ajoutées au modèle représentent donc les emplacements logiques des services fournis en magasin ou au niveau de l'entreprise.

Diagramme décrit dans le contenu textuel.

En utilisant le terme "partitions logiques", nous indiquons que la partition Services en magasin contient un ensemble de services instanciés au niveau du magasin. Nous n'affirmons rien sur le déploiement physique de ces services (serveur unique, cluster, etc.). Ces partitions logiques permettent à l'architecte de représenter les aspects importants de la solution.

Notez également que, dans la figure ci-dessus, l'architecte a introduit un élément supplémentaire, l'application commerciale, afin de permettre les descriptions de communication entre l'application et les services. L'application commerciale est un composant UML 2.0 possédant le stéréotype Service Consumer (Client d'un service).

Pour plus d'informations, voir le concept Partitionnement de la solution.

Analyse des fonctions existantes

L'étape suivante consiste à analyser l'implémentation actuelle de l'application commerciale et à examiner les détails de l'accès à la base de données identifié dans la description du problème. Cette analyse a produit le tableau suivant (notez qu'il ne contient que les détails des recherches de clients et de stocks).
 
Nom Technologie Entrées Sorties Commentaires
sp_get_custlist_by_phone Procédure stockée serveur SQL numérodetéléphone (10 car.) Liste de :
idclient (ID)
nomclient (40 car.)
Cette procédure stockée renvoie une liste de détails clients en fonction du numéro de téléphone. Cette liste peut être présentée au client pour sélection. L'appel sp_get_cust_details est utilisé pour renvoyer un seul enregistrement client.
sp_get_cust_details Procédure stockée serveur SQL idclient (id) Enregistrement client Cet appel renvoie les informations détaillées d'un client : nom, adresse, informations de contact, etc.
CUST_QUERY IBM MQSeries numérodetéléphone (10 car.)
nom-de-la-file-d-attente-de-retour (120 car.)
id-corrélation (120 car.)
S/O Dans cette file d'attente, l'application place les informations détaillées des clients à interroger et le message est livré au serveur central qui envoie le message de réponse dans la file d'attente de retour identifiée.
<nom-de-la-file-d-attente-de-retour> IBM MQSeries S/O id-corrélation (120 car.)
Liste d'enregistrements client
En renvoyant les enregistrements client, le message de retour indique également l'identificateur de corrélation afin que la réponse puisse être associée à une requête donnée. Ainsi, le serveur en magasin peut posséder une seule file d'attente de retour pour tous les terminaux, et le terminal interroge cette file pour y rechercher un message de réponse comportant son identificateur de corrélation.
sp_get_invstate_for_sku Procédure stockée serveur SQL sku (stock keeping unit) (13 car.) Enregistrement stock
INVENTORY_QUERY IBM MQSeries sku (stock keeping unit) (13 car.)
nom-de-la-file-d-attente-de-retour (120 car.)
id-corrélation (120 car.)
S/O
<nom-de-la-file-d-attente-de-retour> IBM MQSeries S/O Enregistrement stock

Comme vous pouvez le constater, ces entrées représentent l'implémentation existante. Une nouvelle implémentation s'y substituera, mais l'objectif et la fonction resteront inchangés.

Développement de la spécification de service initiale

L'activité Identification des services présente un certain nombre de techniques permettant d'identifier les services et les opérations sur les services nécessaires à la prise en charge d'une solution. En l'occurrence, nous cherchons à renouveler la conception existante, par la transformation des fonctionnalités existantes en un modèle de service, et en particulier par l'utilisation d'une technologie d'implémentation des services. Pour ce faire, le premier volet consiste à développer l'ensemble des Spécifications de service, qui fourniront les contrats des services qui implémentent les fonctions décrites ci-dessus. Le diagramme suivant illustre les trois spécifications de service, actuellement vides, créées au cours de cette étape. Chacune d'elles correspond à l'un des services décrits en introduction.

Diagramme décrit dans le contenu textuel.

Nous analysons ensuite les patterns d'utilisation possibles pour ces services. Par exemple, nous pourrions avoir deux services, l'un en magasin et l'autre au niveau de l'entreprise, et la logique de l'accès à la base de données et celle de l'accès à l'entreprise peuvent être toutes les deux encapsulées dans le service en magasin. Sinon, nous pouvons choisir d'utiliser un service de façade en magasin qui encapsule la logique et appelle deux services identiques, l'un qui encapsule l'accès à la base de données locale, l'autre qui encapsule l'accès à celle de l'entreprise. En changeant la logique d'accès aux deux bases, la seconde option ajoute une certaine flexibilité, mais entraîne également une surcharge et des coûts de communication supplémentaires, alors que la fonction considérée est relativement simple. Ainsi, pour la recherche de clients et la vérification des stocks, c'est la première solution qui a été choisie. Les détails de la répartition des services et des fournisseurs de services n'étant pas encore fixés, l'identification des services est bien plus efficace si elle est axée uniquement sur les spécifications de service.

Pour identifier les rôles et responsabilités de ces services, nous utilisons une Collaboration de services, et plus particulièrement un diagramme de structure composite UML 2.0 qui représente la configuration des services pour la recherche de clients. Ce diagramme de structure est présenté ci-dessous. Il contient des composants UML 2.0 qui représentent chaque élément de la collaboration. Notez que les connecteurs situés entre l'application commerciale et le service en magasin, et ceux situés entre ce service et les services d'entreprise, possèdent le stéréotype Service Channel (canal de service) et indiquent les liaisons à utiliser (RMI ou JMS, comme décrit ci-dessus). La liaison du connecteur situé entre le service en magasin et la base de données locale (plus tard) est indéfinie.

Diagramme décrit dans le contenu textuel.

Il faut remarquer ici un élément clé : LocalCustomerLookupProvider est un service généré. Il s'agit d'un service encapsuleur léger entourant une requête de base de données. Il contient une seule opération, qui représente une instruction SQL SELECT. Nous avons privilégié cette approche, au détriment de l'accès direct à la base de données par le service en magasin de recherche de clients, afin que le service local puisse inclure des règles métier supplémentaires ou devenir plus complet par la suite.

Cependant, ce diagramme ne présente que la structure de la collaboration. Le diagramme d'interaction suivant (diagramme de séquence UML 2.0) représente les communications réelles entre les services. Notez que nous avons ajouté l'opération getCustomerByPhone à la spécification de service. Notez également que l'architecture UML 2.0 permet de spécifier un "fragment" facultatif d'un diagramme de séquence. Dans notre cas, elle permet d'indiquer que nous communiquons uniquement avec le service d'entreprise en cas d'échec de la recherche locale.

Diagramme décrit dans le contenu textuel.

En combinant le diagramme de communication et le diagramme de structure statique, nous pouvons documenter la composition et la collaboration des services et identifier en l'occurrence la nécessité d'une seule opération sur la spécification de service.

Pour plus d'informations, voir l'activité Identification des services.

Conception des services Haut de la  page

En suivant le modèle de l'activité Identification des services, nous effectuons une transition de l'identification d'un ensemble de services candidats vers la conception détaillée des services que nous souhaitons construire. La première étape consiste à mapper les spécifications de service qui réalisent les spécifications ci-dessus ; comme vous pouvez l'imaginer, les modalités de réalisation de ces spécifications nécessitent des prises de décision. En l'occurrence, nous disposons d'une structure raisonnablement simple, mais qui sera sans doute commune à un grand nombre de projets. Dans notre cas, un seul fournisseur de services présente un service unique, qui est la réalisation d'une seule spécification. Toutefois, il peut sans aucun doute exister plusieurs services par fournisseur. Ce modèle contient également quelques relations d'utilisation entre les services. Ces dépendances sont importantes pour comprendre l'évolution des services au cours du temps.

Diagramme décrit dans le contenu textuel.

Cette structure nous permet désormais de nous diriger davantage vers la distribution, bien que le modèle constitue encore une vue logique des services (les fournisseurs de services représentent les unités de déploiement du modèle de service). Les fournisseurs de services sont également nécessaires à la définition des services composites, car un service (un port UML 2.0) ne peut posséder la structure requise pour décrire la composition.

Conception des messages

Dans l'activité Identification des services, nous n'avons pas abordé les messages réels échangés entre les opérations décrites sur les spécifications de service. Une approche assez courante peut consister à enregistrer les responsabilités des services en termes d'opérations, en remettant à plus tard la conception détaillée des messages. Dans certains cas, cette approche est inversée (lorsque les structures de message sont connues à l'avance, puis intégrées dans un ensemble d'opérations).

En l'occurrence, nous avons la possibilité d'optimiser un modèle de domaine qui a été développé dans le cadre d'un modèle d'analyse de composant (actif développé précédemment). Ainsi, notre modèle de message n'est pas construit à partir de rien, mais il identifie un sous-ensemble du modèle de domaine à réutiliser. L'exemple ci-dessous montre cette relation. Les classes de domaine sont entièrement indépendantes des technologies et des plateformes, et nos messages sont considérés comme des structures ou des objets de transfert de données transmis entre les services. Ainsi, plutôt que de changer le modèle de domaine, nous créons les messages à "l'extérieur" de la structure de classe, avec des éléments provenant de l'intérieur.

Diagramme décrit dans le contenu textuel.

Pour plus d'informations, voir le concept Conception des messages.

Réalisation des services Haut de la  page

Dans cet exemple, nous nous concentrerons sur la réalisation du service en magasin de recherche de clients ; ce service est couramment rencontré lors de la transformation du modèle de service en modèle de conception. Documentée dans des instructions, cette transformation aboutit à la structure de modèle suivante.

Diagramme décrit dans le contenu textuel.

Alors qu'il s'agit toujours d'un modèle de conception, nous pouvons, à l'aide d'outils, le transformer davantage de façon à obtenir l'implémentation d'EJB ci-dessous. Cette implémentation est transformée depuis la classe CustomerByPhone ci-dessus et les messages qui détaillent le client sont transformés en un bean entity utilisé pour interroger la base de données.

Diagramme décrit dans le contenu textuel.

Pour plus d'informations, voir les instructions Des services aux composants de service.