Modèle d'application

Le modèle d'application se compose d'un service Web et d'une API RESTful décrits et régis dans WSRR. Un domaine DataPower est configuré avec WSRR pour jouer le rôle de passerelle, et un client Web exemple est fourni pour exercer les services.

Le scénario de base du modèle d'application est une application d'inventaire pour un magasin (entrepôt) et un service RESTful qui duplique l'une des opérations pour la version mobile. Le service Web de magasin compte trois opérations :
  • purchase
  • findInventory
  • returnProduct
La dernière opération, findInventory, est également disponible en tant que service RESTful.

Service Web exemple

La définition de niveau de service (SLD) de base contient deux règles de médiation jointes :
  • Validation par rapport à Store.wsdl. L'exemple suppose que la validation DataPower est désactivée.
  • Rejet s'il y a plus de 5 messages en 90 secondes. Ce seuil est bas pour simplifier la démonstration.

Le consommateur du service Store est l'application StoreConsumer, qui a pour ID Consommateur CEO. Ce consommateur possède deux accords sur les niveaux de licence (SLA) : Gold et Anonymous. Si DataPower reçoit une requête avec l'ID Consommateur CEO et l'ID de contexte Silver, la requête est autorisée car le SLA Silver est en place. Si l'ID Consommateur est CEO et que l'ID de contexte est Gold, le SLA Gold est utilisé. Ce SLA possède une règle rattachée de sorte que la requête est réacheminée vers un point de terminaison alternatif défini dans la règle.

En cas de réception d'une requête ayant un ID Consommateur autre que CEO, il n'existe pas de version d'application avec cet ID Consommateur. Par conséquent, un SLA ne correspond, car il s'agit d'un consommateur anonyme. En tant que telles, les règles rattachées au SLA anonyme sont appliquées. Dans ce cas, une notification figure dans les journaux. Notez que l'exemple ne comporte pas de procédure d'envoi d'une demande avec un ID Consommateur autre que CEO.

Le scénario exécute également l'autorisation pour l'opération findInventory, selon l'appartenance à un groupe d'utilisateurs. Un serveur LDAP est fourni avec l'exemple pour mapper les données d'identification utilisateur avec le groupe approprié.

L'organigramme de flux d'application fourni en exemple affiche le flux de l'application avec chaque zone représentant une passerelle DataPower différente.

Figure 1. Le diagramme du flux du modèle d'applicationLa demande entrante dispose d'un ID d'unité de stockage et d'une authentification de base, la sécurité s'applique à StoreAddLTPA, puis à StoreWSP où la demande est authentifiée à l'aide d'un jeton LTPA. S'il s'agit d'un utilisateur Gold, la demande est envoyée à StoreAlternateMockService, sinon elle est envoyée à StoreMockService. Si l'utilisateur est un gestionnaire (manager), la réponse contient l'ensemble des données, sinon la réponse contient les données de prix rédigées.

Service RESTful fourni en exemple

Le service RESTful est gouverné de façon similaire au service Web, sauf en ce qui concerne l'utilisation des règles. Comme avec le service Web, on compte deux SLA : l'un pour les consommateurs Silver, l'autre pour les consommateurs Gold. Pour le service REST, cependant, aucune règle n'est rattachée au niveau du SLD (appliqué à toutes les requêtes). Au lieu de cela, une règle est rattachée à chaque SLA. Le SLA Gold comporte une règle qui rejette les messages quand plus de cinq requêtes ont eu lieu en 90 secondes, tandis que le SLA Silver autorise plus de deux requêtes en 90 secondes avant de rejeter les messages reçus.


Concept Concept

Commentaires


Icône d'horodatage Dernière révision: Thursday, 13 March 2014


http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr25.doc/topics/csoa2_samples.htm