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.
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.
Pour plus d'informations, reportez-vous au guide d'utilisation de l'outil Création d'un modèle de service dans RSA.
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.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) |
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 |
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.
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.
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.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.
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.
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.
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.
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.
Pour plus d'informations, voir les instructions Des services aux composants de service.