Planejando o desenvolvimento do Service Broker
Examine o seguinte à medida que você projeta um aplicativo do Service Broker:
A métrica referente ao tipo e volume de entrada e saída esperados de seu aplicativo.
Os requisitos para o aplicativo proposto.
Se você compreender esses fatores, poderá desenvolver um sistema que satisfaça as metas de negócios.
Lista de verificação de planejamento
Considere as seguintes perguntas ao planejar seu aplicativo:
Qual a função do Agente de Serviços em seu aplicativo?
A resposta a essa pergunta ajuda a planejar os tipos de mensagem que seu aplicativo usa, a estrutura do aplicativo e as necessidades de armazenamento e processamento do seu aplicativo.
Por exemplo, seu aplicativo pode usar o Service Broker para lidar com valores elevados em taxas de chegada de mensagem, armazenando as mensagens em filas até que haja recursos disponíveis para processá-las. Nesse caso, os tipos de mensagem que seu aplicativo usa deve corresponder à entrada e saída do aplicativo existente. É possível estimar as necessidades de armazenamento e processamento do aplicativo, dependendo da carga de trabalho existente.
Em contraste, se você projetar um novo aplicativo, considere cuidadosamente quais operações podem se beneficiar mais do Service Broker. O uso do Service Broker geralmente compensa tempos de processamento previsíveis, na melhor das hipóteses, por segurança quando um aplicativo convencional falha completamente.
Por exemplo, um aplicativo de entrada de pedido online pode não ter de processar completamente o pedido e fornecer uma confirmação final no momento em que o pedido é enviado. Em vez disso, o aplicativo pode enviar o pedido para um serviço que processa o pedido e fornecer uma confirmação final por email. Usando esse design, o aplicativo de pedidos pode continuar aceitando pedidos, mesmo se problemas na rede impedirem que o aplicativo confirme o pedido. Quando os problemas de rede estiverem resolvidos, o aplicativo processará os pedidos. Nesse caso, as necessidades de armazenamento e processamento do aplicativo dependem do número de pedidos esperados, do tamanho de cada mensagem de pedido e o tempo necessário para o processamento de cada pedido.
Quais informações serão necessárias em uma conversação para concluir a tarefa desejada? Quais são os esquemas de mensagens que os pontos de extremidade trocarão para fornecer essas informações um ao outro?
A maioria dos serviços troca informações semi-estruturadas. Portanto, codificação XML é uma boa escolha. Uma codificação binária é útil para trocar arquivos binários como imagens. Quando uma mensagem comunica só o fato de que a mensagem chegou, use uma mensagem vazia.
Selecionando o tipo de mensagem correto, é menos provável que você tenha de atualizar seu aplicativo mais tarde. Dependendo da codificação do tipo de mensagem, as atualizações podem incluir qualquer coisa, desde atualizações em um arquivo de esquema XML a alterações de codificação significativas em seu aplicativo. Se houver itens de dados que você não precisa no momento, mas espera precisar futuramente, poderá fazer sentido incluí-los. Se desde o começo você incluir esses elementos no esquema, não precisará alterar o esquema quando oferecer suporte a ele.
Onde sua lógica de processamento de mensagem será executada?
Você pode projetar seu aplicativo como um procedimento armazenado que é ativado pelo Service Broker, como um serviço em segundo plano, como um evento programado ou como um aplicativo externo. A decisão final depende da função que o Service Broker desempenha em seu aplicativo. Por exemplo, se seu aplicativo processa um fluxo contínuo de mensagens que chegam em uma taxa previsível, você poderá usar um serviço em segundo plano. Se seu aplicativo deve ser dimensionado dinamicamente com base no número de mensagens que chega, você poderá usar um procedimento armazenado ativado por uma fila. Se seu aplicativo mantém mensagens em fila e processa todas as mensagens em um momento definido, você poderá usar um evento agendado para iniciar o aplicativo.
Você poderá usar um aplicativo externo se seu programa necessitar de acesso a recursos fora do banco de dados, como páginas da Web ou arquivos. O uso de um aplicativo externo pode aprimorar a escalabilidade de seu aplicativo, porque o processamento ocorre em servidores de nível intermediário e não no servidor do banco de dados. É fácil dimensionar um aplicativo que usa o Service Broker, porque o Service Broker fornece acesso transacional remoto a filas. Qualquer aplicativo que pode enviar comandos Transact-SQL ao banco de dados e processar os resultados pode usar o Service Broker.
Cada programa externo está isolado de outros programas que usam a fila. Portanto, os programas externos não precisam de precauções especiais para gerenciar acesso à fila. Além disso, se a conexão falhar enquanto o aplicativo estiver processando uma mensagem, a transação será revertida e o Service Broker retornará a mensagem para a fila. Problemas de rede não podem fazer com que o aplicativo perca uma mensagem.
Que tecnologia você planeja usar para implementar seu aplicativo?
Você pode implementar um aplicativo externo com qualquer tecnologia que possa se conectar ao banco de dados e executar instruções Transact-SQL no SQL Server. Entretanto, aplicativos são geralmente desenvolvidos em uma linguagem compatível com .NET Framework e ADO.NET. Você pode implementar um procedimento armazenado em Transact-SQL ou em uma das linguagens compatíveis com o .NET Framework. O Transact-SQL pode fornecer melhor desempenho no Mecanismo de Banco de Dados. As linguagens compatíveis com CLR podem fornecer melhor flexibilidade, controle mais restrito do fluxo do programa, melhor desempenho a aplicativos de processamento intensivo e acesso direto ao .NET Framework.
Que componentes de servidor seu aplicativo usará com mais freqüência?
Trabalhe com seu administrador de sistema para assegurar que você tenha recursos suficientes para alcançar desempenho otimizado do aplicativo. Saiba quais componentes você usará com mais freqüência. Por exemplo, se seu aplicativo usa filas para manter a carga de trabalho consistente ou ativa retenção de mensagens, verifique se há espaço em disco suficiente para que a fila cresça. Inversamente, um aplicativo que tem altos volumes de mensagem, mas tempo curto de espera em fila poderá usar mais largura de banda de rede, mas consumirá menos espaço em disco
Suas mensagens terão prioridades diferentes?
Em sistemas altamente carregados, as prioridades de conversação do Service Broker ajudam a garantir que trabalhos importantes não sejam bloqueados por grandes quantidades de trabalho menos importante. As prioridades de conversação também habilitam designs que oferecem suporte a níveis diferentes de serviço.