Service Broker et la notion de classement
Service Broker est conçu pour permettre aux services et aux applications de communiquer facilement et en toute efficacité dans les instances présentant des configurations de classement différentes. La base de données hébergeant un service à l'origine de l'envoi d'un message peut ne pas utiliser le même classement que celui de la base de données hébergeant le service qui réceptionne le message. Par conséquent, Service Broker utilise une forme de classement homogène pour les noms, sans tenir compte du classement de la base de données qui héberge le service. Pour supprimer les informations de classement du processus de communication, Service Broker utilise une comparaison octet par octet pour faire correspondre les noms de services, les noms de contrats et les noms de types de messages entre eux. En faisant concorder les noms sous la forme de séquences d'octets, Service Broker facilite l'échange correct des messages entre les services sans la surcharge dégagée par l'échange des informations de classement.
La correspondance octet par octet est, en réalité, une comparaison binaire qui ne prend pas en considération le classement actif. Pour cette raison, de nombreux services de broker la trouvent pratique pour suivre les recommandations données dans Naming Service Broker Objects. Une application qui suit ces directives et traite tous les noms en respectant la casse devrait fonctionner correctement, sans que les différences de classement soient prises en compte entre la base de données hébergeant le service cible et la base de données hébergeant le service initiateur.
Remarques sur le classement en vigueur dans les files d'attente
Les files d'attente utilisent un classement homogène, peu importe le classement par défaut de l'instance SQL Server ou celui de la base de données qui héberge la file d'attente. Si une file d'attente constitue la cible d'une instruction SELECT comportant une instruction de se joindre (JOIN) à une autre table dans la base de données (par exemple une table utilisée pour gérer l'état), vous serez peut-être amené à spécifier explicitement le classement pour la comparaison.
Par exemple, une application qui utilise la rétention de messages peut avoir besoin de conserver certains messages pour une conversation avant que l'application mette un terme à cette conversation. L'exemple de code Transact-SQL suivant enregistre, pour une conversation donnée, tous les messages qui possèdent un nom de type de message dans la table AuditedMessageTypes.
IF @messageTypeName =
'https://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
INSERT INTO dbo.AuditRecord
SELECT q.message_type_name, q.message_body
FROM dbo.ApplicationQueue AS q
JOIN dbo.AuditedMessageTypes AS am ON
am.message_type_name = q.message_type_name
COLLATE Latin1_General_BIN
AND
q.conversation_handle = @conversationHandle
END CONVERSATION @conversationHandle
END
L'instruction SELECT précise explicitement une comparaison binaire pour faire correspondre les noms de types de messages. Dans la mesure où une file d'attente n'utilise pas le classement par défaut de la base de données, la clause COLLATE est obligatoire pour que la comparaison am.message_type_name = q.message_type_name réussisse. L'instruction indique un classement binaire, Latin1_General_BIN, afin de faire correspondre le comportement de la comparaison interne que Service Broker utilise pour associer les noms de services.
Remarques sur le classement en vigueur dans les applications
Service Broker transmet le corps du message sous forme de données binaires et ne modifie pas le contenu du message. Si les applications échangent des données respectant la notion de classement, elles doivent gérer toutes les différences de classement qui en résultent. Les applications qui échangent du texte utilisent généralement des types Unicode pour réduire au minimum les problèmes de classement.
Voir aussi
Autres ressources
Utilisation des classements
Programmation côté serveur avec Unicode