Planification du développement Service Broker
Vérifiez les points suivants lorsque vous concevez une application Service Broker :
La mesure du type et du volume des entrées et des sorties attendus de votre application.
Les conditions requises auxquelles doit satisfaire votre application.
Si vous maîtrisez ces facteurs, vous pouvez développer un système qui satisfait aux objectifs de l'entreprise.
Planification d'une liste de vérification
Pensez aux points suivants lorsque vous planifiez votre application :
Quel rôle le Service Broker joue-t-il dans votre application ?
La réponse à cette question vous aide à planifier les types de message que votre application utilise, la structure de votre application, et les besoins de stockage et de traitement de votre application.
Par exemple, votre application peut utiliser Service Broker pour traiter les pique-notes des taux d'arrivée de messages en stockant les messages dans les files d'attente jusqu'à ce que les ressources soient disponibles pour les traiter. Dans ce cas, les types de message que votre application utilise doivent correspondre étroitement aux entrées et aux sorties de l'application existante. Vous pouvez estimer les besoins de stockage et de traitement de votre application, en fonction de la charge de travail existante.
Par opposition, si vous concevez une nouvelle application, considérez soigneusement aux opérations qui peuvent tirer le meilleur parti de Service Broker. L'utilisation de Service Broker adapte souvent les temps de traitement prévisibles dans le meilleur des cas en échange de fiabilité quand une application classique échoue complètement.
Par exemple, une application d'enregistrement de commandes en ligne peut ne pas avoir à traiter complètement la commande et à fournir la confirmation finale au moment où la commande est soumise. À la place, l'application peut soumettre la commande à un service qui la traite et fournit la confirmation finale par courrier électronique. En utilisant cette conception, l'application peut continuer à accepter les commandes même si les problèmes de réseau empêchent l'application de confirmer la commande. Lorsque les problèmes réseau sont résolus, l'application traite les commandes. Dans ce cas, les besoins en stockage et en traitement de l'application dépendent du nombre de commandes attendu, de la taille de chaque message de commande et de l'heure à laquelle chaque commande requiert d'être traitée.
Quelles informations sont requises dans une conversation pour compléter la tâche désirée ? Quels sont les schémas des messages que les points de terminaison échangent pour fournir ces informations aux uns et aux autres ?
La plupart des services échangent des informations semi-structurées. Par conséquent, le codage XML constitue un bon choix. Un codage binaire est utile pour échanger des fichiers binaires tels que les images. Lorsqu'un message communique uniquement le fait que le message est arrivé, utilisez un message vide.
En sélectionnant le type de message correct, vous risquez moins d'avoir à mettre à jour votre application ultérieurement. Selon le codage du type de message, les mises à jour peuvent inclure aussi bien la mise à jour d'un fichier schéma XML que d'importantes modifications de programmation dans votre application. S'il existe des éléments de données dont vous n'avez pas besoin actuellement, mais que vous prévoyez d'utiliser dans le futur, leur inclusion peut se justifier. Si vous définissez ces éléments dans le schéma dès le départ, vous n'aurez pas à modifier le schéma lorsque vous les prendrez effectivement en charge.
Où exécuter la logique de traitement de vos messages ?
Vous pouvez concevoir votre application comme une procédure stockée activée par Service Broker, comme un service d'arrière-plan, comme un événement planifié ou comme une application externe. La décision finale dépend du rôle que Service Broker joue dans votre application. Par exemple, si votre application traite un flux continu de messages qui arrivent selon une fréquence prévisible, vous pouvez utiliser un service d'arrière-plan. Si votre application doit évoluer dynamiquement selon le nombre de messages arrivés, vous pouvez utiliser une procédure stockée activée par une file d'attente. Si votre application conserve les messages dans une file d'attente et traite tous les messages à une heure définie, vous pouvez utiliser un événement planifié pour démarrer l'application.
Vous pouvez utiliser une application externe si votre programme requiert l'accès à des ressources externes à la base de données, comme les pages Web ou les fichiers. L'utilisation d'une application externe peut améliorer l'évolutivité de votre application, parce que le traitement se produit sur les serveurs de couche intermédiaire, et non sur le serveur de base de données. Il est facile d'effectuer une montée en puissance parallèle d'une application qui utilise Service Broker, parce que Service Broker fournit l'accès transactionnel distant aux files d'attente. Une application que peut envoyer des commandes Transact-SQL à la base de données et traiter les résultats peut utiliser Service Broker.
Chaque programme externe est isolé des autres programmes qui utilisent la file d'attente. Par conséquent, les programmes externes n'ont pas besoin de précautions spéciales pour gérer l'accès à la file d'attente. En outre, si la connexion échoue pendant que l'application traite un message, la transaction est restaurée et Service Broker retourne le message à la file d'attente. Les problèmes réseau ne peuvent pas provoquer la perte d'un message par l'application.
Quelle technologie prévoyez-vous d'utiliser pour implémenter votre application ?
Vous pouvez implémenter une application externe en utilisant une technologie qui peut se connecter à la base de données et exécuter les instructions Transact-SQL dans SQL Server. Toutefois, les applications sont généralement développées dans un langage compatible avec le .NET Framework et ADO.NET. Vous pouvez implémenter une procédure stockée en Transact-SQL ou dans un langage compatible avec le .NET Framework. Transact-SQL peut offrir de meilleures performances par rapport au Moteur de base de données. Les langages conformes à CLR peuvent fournir une meilleure souplesse, un contrôle plus strict du déroulement du programme, de meilleures performances pour les applications sollicitant le processeur de manière intensive, et un accès direct au .NET Framework.
Quels composants serveur votre application utilisera-t-elle le plus intensément ?
Travaillez avec votre administrateur système pour garantir que vous avez les ressources suffisantes pour obtenir les performances optimales pour l'application. Sachez quels composants vous allez utiliser le plus fréquemment. Par exemple, si votre application utilise les files d'attente pour répartir la charge de travail du traitement ou qu'elle active la rétention des messages, vérifiez qu'il existe un espace disque suffisant pour que la file d'attente puisse croître. Inversement, une application qui possède des volumes de messagerie élevés, mais des temps d'attente de file d'attente inférieurs, peut utiliser une plus grande bande passante tout en consommant moins d'espace disque.
Vos messages ont-ils des priorités différentes ?
Dans les systèmes très chargés, les priorités de la conversation Service Broker aident à garantir que le travail important n'est pas bloqué par de grandes quantités de travail de moindre importance. Les priorités de conversation autorisent aussi les conceptions qui prennent en charge différents niveaux de service.