Escolhendo uma estratégia de inicialização
Este tópico descreve opções para ativação do Service Broker.
O Service Broker dá suporte ao sistema de mensagens assíncronas e enfileiradas. Como as conversações podem durar por dias, meses ou anos, muitos aplicativos usam a ativação para serem dimensionados dinamicamente. Esta seção descreve algumas estratégias comuns para iniciar um aplicativo que usa o Service Broker.
Estratégias de inicialização
As estratégias para iniciar um aplicativo enquadram-se em quatro grandes categorias:
Ativação interna
Ativação baseada em eventos
Tarefa agendada
Tarefa de inicialização
Cada estratégia de ativação tem diferentes vantagens. Um aplicativo pode combinar essas estratégias. Por exemplo, um aplicativo pode usar ativação interna com um número pequeno de leitores de fila a maioria do tempo. Mas, em determinados momentos do dia, pode iniciar mais leitores de fila.
Ativação interna
Com Service Broker ativação interna, um monitor de fila do Service Broker ativa um procedimento armazenado diretamente quando for necessário. Essa é freqüentemente a abordagem mais simples. Usando a ativação direta de um procedimento armazenado, você não tem que gravar um código adicional no aplicativo para gerenciar a ativação. Porém, a ativação interna requer que o aplicativo seja gravado como um procedimento armazenado do SQL Server. Ao usar a ativação interna, você grava o aplicativo para sair quando não existir mais mensagens para processar.
Ativação baseada em eventos
Alguns aplicativos são executados em resposta a um evento específico. Por exemplo, você pode executar um aplicativo quando o uso da CPU no computador ficar abaixo de um determinado nível. Ou você pode executar um aplicativo de log quando uma nova tabela for criada.
A ativação externa do Service Broker é um caso especial de ativação baseada em evento. Para a ativação externa, o aplicativo é iniciado em resposta ao evento QUEUE_ACTIVATION.
Para eventos que podem ser ativados através de notificações de eventos, a ativação baseada em evento pode ser combinada com a ativação internado Service Broker. Nesse caso, você usa a ativação interna na fila que recebe a notificação de eventos. O procedimento armazenado de ativação recebe a mensagem notificação e inicia o aplicativo.
Para outros eventos, você pode usar o SQL Server Agent para iniciar trabalhos no mesmo computador como o computador em que o SQL Server é executado. Você pode gravar um aplicativo que monitore os eventos WMI (Windows Management Instrumentation, Instrumentação de Gerenciamento do Windows) de um computador remoto. O aplicativo pode iniciar uma tarefa quando um evento WMI ocorrer no computador que executa o SQL Server.
Ao usar a ativação baseada em evento, um aplicativo normalmente é encerrado quando não há mais mensagem para processar.
Tarefa agendada
Com uma tarefa agendada, um aplicativo é ativado de acordo com uma agenda fixa. Essa estratégia é conveniente para aplicativos de processamento em lotes. Um aplicativo que é executado como uma tarefa agendada pode ser encerrado quando não existirem mais mensagens para processar ou o programa poderá ser encerrado em um momento determinado.
Por exemplo, um aplicativo que processa pedidos para um fornecedor pode armazenar mensagens durante o dia e, em seguida, processar as mensagens durante a noite para gerar uma única ordem para o fornecedor. Nesse caso, o aplicativo pode usar um trabalho do SQL Server Agent para iniciar o aplicativo em um momento específico a cada noite.
Tarefa de inicialização
Alguns aplicativos iniciam uma vez, normalmente quando o computador é iniciado ou quando o SQL Server é iniciado. Exemplos dessas tarefas são um procedimento armazenado de inicialização no SQL Server, um aplicativo no grupo de inicialização do Windows ou um serviço do Windows. Nesse caso, o aplicativo permanece em execução e processa as mensagens assim que elas chegam. Um aplicativo que é executado continuamente não requer tempo de inicialização quando uma mensagem chega na fila. Entretanto, como o aplicativo não é encerrado quando não existe mensagens, o programa consome recursos mesmo quando não há trabalho para o programa executar.
Essa estratégia pode ser útil para um aplicativo que processe um fluxo constante de mensagens e que consuma relativamente muitos recursos durante a inicialização.
Consulte também