Création de types de messages Service Broker
Un type de message définit le nom d'un type de message spécifique et la validation que Service Broker effectue sur ce type de message. Pour déterminer les types de messages que votre application utilisera, vous devez avant tout planifier les tâches que votre application doit effectuer, ainsi que les données qui sont nécessaires pour effectuer chaque tâche.
L'approche la plus courante pour une application consiste à structurer les messages de sorte que chaque message inclue les informations requises pour une étape de la tâche. Lorsque chaque message contient les informations pour une étape de la tâche, l'application peut aisément recevoir le message, effectuer l'étape et envoyer une réponse au sein d'une même transaction. Par conséquent, pour nombre d'applications, la méthode la plus simple pour déterminer les types de messages et le contenu du message consiste à définir les limites de transactions des tâches effectuées par l'application. Chaque étape distincte est une transaction, et chaque transaction correspond à un type de message échangé entre les services. Les informations d'état, les résultats ou la sortie sont également des types de messages.
Les protocoles de communication de Service Broker sont conçus pour fonctionner avec ce style de messagerie. Le protocole de dialogue fragmente les messages volumineux pour leur transit et garantit que les messages volumineux n'empêchent pas la transmission des messages de petite taille.
Choix d'un type de validation
La validation spécifiée pour le message dépend du contenu du message. Il existe une pratique courante qui consiste à utiliser la validation la plus restrictive disponible durant le test, puis à choisir une validation moins restrictive pour améliorer les performances lorsque l'application est déployée. Par exemple, il est possible d'échanger un document XML typé comme corps d'un message qui spécifie l'option de validation NONE. Dans ce cas, votre application valide le message lors du traitement du XML.
Le format réseau d'un message inclut le nom du type de message. Par conséquent, les noms de types de messages sont souvent choisis pour éviter les problèmes de classement et les conflits de noms. Pour plus d'informations sur l'attribution de nom, consultez Attribution de noms aux objets Service Broker.
Indication de la réussite et de l'échec
En règle générale, une application ne définit pas de nouveaux types de messages pour indiquer la réussite ou l'échec. Vous devez utiliser l'instruction END CONVERSATION pour indiquer que la conversation est terminée et que la tâche s'est correctement déroulée. Si la tâche n'a pas abouti, incluez l'option WITH ERROR pour retourner un message d'erreur sur la conversation.
En général, un seul des participants à la conversation doit mettre un terme à la conversation lorsque la tâche est achevée. L'autre participant émet une instruction END CONVERSATION uniquement en réponse à un message End Dialog ou Error. La documentation d'un service spécifie généralement le participant qui met fin à la conversation si la conversation se termine correctement. Le fait de disposer de cette documentation contribue à éviter les problèmes lorsque aucun participant ne met fin à la conversation ou lorsqu'un participant met fin à la conversation alors que l'autre participant est encore en train d'effectuer des tâches. Les deux points de terminaison doivent être en mesure de traiter les messages d'erreur car les messages Service Broker internes sont remis aux deux points de terminaison. Par exemple, si la durée de vie du dialogue expire avant la fermeture du dialogue, les deux points de terminaison reçoivent un message d'erreur Service Broker.
Les deux participants peuvent mettre un terme à une conversation à tout moment par le biais d'une erreur. Pour obtenir des informations complémentaires sur la gestion des messages d'erreur Service Broker, consultez Gestion des messages d'erreur de Service Broker.
Voir aussi