Artigos Banco de Dados Artigo da SQL Magazine 34 - SQL Server 2005 - Service Broker

ustify>Capa SQl 33

Clique aqui para ler todos os artigos desta edição

SQL Server 2005 Service Broker

Gerenciamento de processamentos assíncronos

 

     Atualmente presenciamos em nossas corporações a total dependência de sistemas informatizados; seja na área administrativa com sistemas de gestão (ERP - Enterprise

Resource Planning), na área comercial com sistemas de relacionamento com clientes (CRM – Customer Relationship Management) ou até mesmo em áreas gerenciais e estratégicas com sistemas de planejamento e visão estratégica (BI - Business Intelligence). Em nossa vida particular isso também ocorre, afinal quem conseguiria

sobreviver sem “Internet Banking’s” ou então sem os Caixas Eletrônicos?

     Toda esta dependência tem conseqüências diretas na área de tecnologia da informação, onde existe uma pressão constante para produção de sistemas com alto grau de confiabilidade, segurança, disponibilidade, escalabilidade, agilidade e performance, entre outros. Todas essas questões estão diretamente relacionadas ou são profundamente influenciadas pelo SGBD, que representa o pilar de todos esses conceitos.

     Nesse artigo serão abordados os novos conceitos assim como todas as atividades necessárias para a criação de uma infra-estrutura de serviços para processamentos assíncronos utilizando o SQL Server 2005 Service Broker.

 

Processamento assíncrono

 

     Disponibilidade, escalabilidade e performance são muitas vezes requisitos apresentados durante a fase de concepção dos sistemas, mas o número de processadores ou mesmo o total de memória que teremos disponível em nosso ambiente de produção dependem essencialmente da arquitetura do sistema e das técnicas adotadas durante a fase de desenvolvimento.

     Basear itens críticos totalmente na infra-estrutura que os suportará pode inviabilizar a solução do ponto de vista financeiro; precisamos sim de uma arquitetura flexível e aderente ao processamento assíncrono que possa identificar quais são os processos ou atividades realizadas a partir do sistema que precisam responder às requisições de forma on-line (no menor tempo possível após a solicitação) ou então podem ser racionalizadas de tal forma a agendar/programar processamentos futuros. Com essa técnica, conseguimos uma distribuição melhor de recursos, otimizando o sistema, processos e recursos relacionados.

     Com uma análise mais detalhada do negócio, identificamos, por exemplo, que 75% das atividades dispostas em nosso sistema deverão ser entregues para o usuário final

de forma on-line e os outros 25% serão recebidos, mas não serão processados logo após o recebimento. Nesses casos, o processamento será em intervalos regulares, com agendamentos específicos – por exemplo, todos os pedidos recebidos das 13 até as 14:00 hs serão processados às 15:00 hs, e assim por diante (ver Figura 1).

 

Figura 1. Etapas envolvidas no processo assíncrono de recebimento e processamento de pedidos.

 

     Conceitualmente, o processamento assíncrono reflete a capacidade de receber uma determinada solicitação e garantir a sua execução sem informar com exatidão quando

isso ocorrerá. Podemos utilizar uma arquitetura assíncrona com outros objetivos tais como habilitar processamentos distribuídos, processamento em batch, priorização e

ordenação de tarefas.

 

SQL Server 2005 Service Broker

 

     O Service Broker é uma das novas características presentes no engine do SQL Server 2005 que através de novos objetos e extensões da linguagem T-SQL, disponibilizam uma plataforma robusta e confiável para a gestão de processos

e ambientes assíncronos.

     De forma geral, o desenvolvimento de uma solução assíncrona “dá mais trabalho”, se comparada à solução síncrona: no modelo síncrono, a linha de código 100 é executada somente após a conclusão da linha 99, que por sua vez é executada após o término efetivo da linha 98, e assim por diante. Numa solução assíncrona, as linhas são “disparadas” independente do término efetivo de suas predecessoras. Nesses casos, um mecanismo de controle especial é responsável pelo monitoramento das linhas que foram “disparadas” informando ao sistema o momento de sua conclusão.

     Ambientes assíncronos devem obrigatoriamente prever uma série de cenários de atuação (ver Tabela 1). A adoção do Service Broker centraliza e garante a confiabilidade em todo o ciclo do processamento, simplificando bastante a arquitetura

de um sistema aderente ao processamento assíncrono, não sendo mais necessário a utilização de produtos de terceiros (Microsoft Message Queuing ou MSMQ, IBM MQSeries, entre outros).

    

...

Quer ler esse conteúdo completo? Tenha acesso completo