Présentation du test de service asynchrone

Les services asynchrones utilisent un pattern d'interaction de rappel pour les communications entre objets. Ces services peuvent être utilisés, par exemple, dans les systèmes de publication-d'abonnement fournis par les logiciels transitaires orientés message ou dans les domaines de gestion d'unités.

Services WS-Notification

Les services asynchrones sont normalisés dans les spécifications WS-Notification :

WS-BaseNotification définit les interfaces de services Web pour les spécifications NotificationProducers et NotificationConsumers. Cette spécification inclut des échanges de messages standard qui sont implémentés par les fournisseurs de services qui souhaitent activer ces rôles ainsi que les conditions de fonctionnement connexes.
WS-BrokeredNotification définit l'interface de services Web pour NotificationBroker. NotificationBroker est une spécification intermédiaire qui, entre autres, permet aux entités qui ne sont pas des fournisseurs de services de publier des messages. Cette spécification inclut des échanges de messages standard qui sont implémentés par les fournisseurs de services NotificationBroker ainsi que les conditions de fonctionnement connexes des fournisseurs de services et des demandeurs qui sont inclus dans les notifications de type Brokered.
WS-Topics définit un mécanisme d'organisation et de catégorisation des éléments utiles pour les abonnements appelé rubriques. Les rubriques sont utilisées conjointement avec les mécanismes de notification définis dans les spécifications WS-BaseNotification et WS-BrokeredNotification.

Vous pouvez tester les services Web et XML qui implémentent la spécification WS-Notification en créant une demande asynchrone dans un test. La demande asynchrone contient les interfaces de la spécification WS-Notification correspondante ainsi qu'une structure de rappel.

Services asynchrones de propriété

Vous pouvez tester les services asynchrones de propriété qui n'implémentent pas les spécifications WS-Notification. Pour tester ces services, créez manuellement une demande de service contenant les interfaces de ce service, puis ajoutez la structure de rappel asynchrone à l'appel.

Les données XML de la demande asynchrone doivent contenir un noeud final qui spécifie l'URL du récepteur de rappel. Au cours du test, ce noeud final est utilisé pour rediriger le rappel vers le testeur plutôt que vers le récepteur réel.

Structure de rappel

Pour tester les services asynchrones, vous devez créer une structure de demande asynchrone dans votre test comme indiqué dans le diagramme suivant :

Exemple de structure de demande asynchrone

Une demande de service Web ou une demande XML standard fournit l'action d'abonnement et contient un élément de rappel qui décrit le comportement du test en trois étapes :

Parallèle contient les éléments de test exécutés après la demande d'abonnement, en attendant la notification.
Réception contient les éléments de test qui sont exécutés lorsque la notification a été reçue du service.
Délai d'attente contient les éléments de test qui sont exécutés si la notification n'est pas reçue après le délai défini dans l'élément de rappel.

Lorsque tous les éléments contenus dans les éléments parallèles, de réception et de délai d'attente ont été exécutés, l'exécution se poursuit avec l'élément suivant dans le test après la demande asynchrone.

La méthode permettant de générer la structure d'appel asynchrone dans le test varie selon si le service asynchrone utilise la spécification WS-Notification :

Services WS-Notification : la demande asynchrone est créée dans le test.
Services propriétaires : une demande de service Web ou XML est créée manuellement dans le test, puis la structure de rappel asynchrone est ajoutée à la demande.

Retour d'informations