Responsabilidades do desenvolvedor com o Service Broker

O desenvolvedor de aplicativos é responsável por projetar o aplicativo Service Broker e criar elementos que necessitam de programação. O administrador de sistema é responsável por configurar e gerenciar o Service Broker. Desenvolvedores e administradores precisam trabalhar juntos ao planejar o sistema, para assegurar que ele seja desenvolvido e gerenciado de forma otimizada para seu ambiente específico e propósitos de negócio.

As tarefas envolvidas na criação de um aplicativo individual dependem das necessidades do aplicativo. O que segue é uma seqüência comum de tarefas para desenvolver um aplicativo Service Broker:

  1. Planeje o aplicativo. Crie um esboço das tarefas que o aplicativo deve realizar. Descreva as conversações que ocorrem durante cada tarefa. Quais pontos de extremidade precisam fornecer informações e em que ordem? Que processamento deve ocorrer? Quais prioridades devem ser atribuídas às conversações? Todas as informações subseqüentes dependem desse esboço.

  2. Determine o formato e a estrutura de cada mensagem em cada conversação. Planeje a seqüência esperada de troca de mensagens e como cada participante na conversação deve responder a erros e mensagens enviadas em ordem inesperada.

  3. Se a conversação usar mensagens XML, crie um esquema para cada mensagem XML. Os esquemas são usados durante o desenvolvimento, teste e solução de problemas. Quando seu serviço está em produção, você pode remover a validação de esquema de seus tipos de mensagem para aprimorar o desempenho.

  4. Crie um tipo de mensagem para cada mensagem em cada conversação.

  5. Crie um contrato para cada conversação. O contrato identifica os tipos de mensagem que podem ser usados por cada ponto de extremidade na conversação.

  6. Crie uma fila para armazenar as mensagens que serão recebidas pelo aplicativo.

  7. Crie um serviço para expor a funcionalidade definida pelo contrato e implementada pelos procedimentos armazenados que você criou. Ao criar um serviço, associe-o à fila que você criou na etapa anterior. Assim, você informa ao Agente de Serviços que todas as mensagens que chegarem direcionadas para aquele serviço devem ser colocadas na fila identificada.

  8. Examine os planos de prioridade estabelecidos na etapa 1. Crie prioridades de conversação que abranjam todos os pontos de extremidade de conversação projetados para usar níveis de prioridade diferentes da prioridade padrão. Se os níveis de prioridade forem usados quando as mensagens forem transmitidas de um banco de dados, verifique se a opção HONOR_BROKER_PRIORITY naquele banco de dados está definida como ON.

  9. Crie um aplicativo que implemente o padrão de troca de mensagem esperado e os requisitos de processamento identificados na etapa 1. Se seu aplicativo usar ativação interna, o aplicativo será um procedimento armazenado.

  10. Se seu aplicativo usar ativação interna, altere a fila para habilitar a ativação. Especifique o procedimento armazenado criado na etapa 8 como o procedimento armazenado de ativação.

  11. Identifique os serviços que usam o serviço recém-criado. Se quaisquer desses serviços existirem fora da instância local do SQL Server, crie rotas para eles.

  12. Verifique os serviços remotos que você identificou na etapa anterior e determine os requisitos de segurança para comunicação com eles. Se necessário, crie certificados para impor esses requisitos e crie os usuários de banco de dados para os certificados. Associe os certificados a esses logons. Os administradores ou desenvolvedores de outros serviços devem criar associações de serviço remoto para habilitar a segurança de diálogo em tráfego para esse serviço.

  13. Durante o desenvolvimento e teste, é geralmente conveniente que um aplicativo funcione com nomes de usuários que o aplicativo usará na produção, mas associe esses nomes de usuários a certificados que são usados somente no ambiente de desenvolvimento e teste. Quando o aplicativo se mover para a produção, use certificados criados para o ambiente de produção. Usando certificados diferentes você pode reduzir o esforço envolvido na implantação do aplicativo e ainda manter a segurança entre o ambiente de desenvolvimento e o ambiente de produção.