Como o SQL Server 2005 habilita arquiteturas de bancos de dados orientadas a serviço

Publicado em: 16 de janeiro de 2006

Autor: Don Kiely

Aplica-se a: SQL Server 2005

Resumo: Os bancos de dados são uma parte estratégica de uma arquitetura distribuída criada com a SODA (Service-Oriented Database Architecture). Este documento explora os conceitos por trás da SODA e como o SQL Server 2005 se encaixa nessa arquitetura.

Nesta página

Introdução
Dados em uma arquitetura orientada a serviço
Recursos da SODA do SQL Server 2005
Topologias de computação da SODA
Conclusão
Referências

Introdução

As arquiteturas de aplicativos cliente/servidor e de várias camadas, dominantes nos anos 90, deparavam-se com problemas sérios de escalabilidade e disponibilidade quando usadas para implementar grandes sites de comércio eletrônico. Um dos maiores problemas era que os dados tendiam a ser armazenados em enormes bancos de dados centralizados, aos quais todos os componentes cliente tinham acesso. Praticamente toda a comunicação com o banco de dados era feita na forma de instruções SQL ou de lotes de instruções em um procedimento armazenado, de forma que o cliente recebia um conjunto de dados para a tarefa específica.

Surgiram outros problemas ao se tentar incorporar sistemas “herdados” a aplicativos mais novos. Após décadas de implantação de uma grande variedade de sistemas usando diversas tecnologias e plataformas proprietárias, o mundo estava repleto de sistemas que faziam seu trabalho perfeitamente bem, mas não havia um caminho claro para interagir com outros aplicativos em um ambiente cada vez mais conectado. Atingir a agilidade necessária aos aplicativos atuais foi extremamente difícil. As interações B2B (Business-to-Business) complicam ainda mais as coisas, exigindo formas padronizadas e confiáveis de conduzir negócios eletronicamente. Obviamente, os sistemas em evolução que atendem às necessidades do ambiente de negócios global de hoje exigem uma arquitetura que use sistemas herdados de maneira eficiente e forneçam uma infra-estrutura de comércio ágil.

Em resposta a essas necessidades, nos últimos três a cinco anos, surgiu uma arquitetura de sistema distribuída, de grande escala e flexível, principalmente com a transformação dos sites de comércio eletrônico na Internet em grandes operações comerciais. A SOA (Service-Oriented Architecture) surgiu como a arquitetura dominante, flexível e focada em serviços. Os aplicativos baseados na SOA são mais resistentes a falhas e mais facilmente dimensionáveis pela adição de recursos usando uma variedade de métodos, conforme necessário, para atender às mudanças de demanda. Além disso, eles permitem a integração de sistemas herdados ao B2B e a outros sistemas.

Os provedores de serviços, consumidores e outros componentes da SOA manipulam os dados como um recurso natural de suas funções em um aplicativo SOA. Normalmente, um aplicativo SOA ainda usa bancos de dados centrais para armazenar e proteger dados, mas é muito provável que ele possua muitos bancos de dados grandes que mantêm classes de dados, como o armazenamento separado de dados de vendas, fabricação e operações, e subconjuntos especializados de cada uma dessas classes. Cada provedor de serviços e consumidor pode ter uma necessidade localizada de dados armazenados em cache em seu próprio armazenamento de dados especializados. E as mensagens que trafegam entre as partes distantes do aplicativo são, elas próprias, dados que freqüentemente precisam ser arquivados para usos variados.

Os dados podem ser particionados de quatro maneiras gerais, com base em suas características no sistema:

• Dados de referência são usados para criar solicitações de serviço, como um catálogo de produtos. Eles devem estar em um formato que possa ser usado por todas as partes e são identificados de uma maneira que não é alterada com o tempo, como a data de um catálogo.

• Dados de atividades são dados efêmeros usados para executar uma atividade específica, como uma lista de seleção utilizada para recuperar itens comprados do estoque. Como eles são específicos do serviço, o formato não precisa ser compreendido por outras partes.

• Dados de recursos são dados de vida útil longa utilizados internamente por um serviço, como SKUs, dados de clientes e dados de contas.

• Dados de interação de serviços são usados para a comunicação entre os serviços. Eles devem estar em um formato que seja compreendido por todas as partes e devem permanecer constantes ao longo do tempo. Por exemplo, um formulário de pedido é comunicado entre os serviços. Se o pedido for perdido, ele deve poder ser regenerado no mesmo formulário que o original e retransmitido.

A Figura 1 mostra alguns dos pontos de extremidade que podem compor um aplicativo flexível criado usando os princípios da SOA. Um consumidor de serviços — que pode ser um aplicativo cliente, um aplicativo servidor, como um servidor Web, ou qualquer outro tipo de aplicativo — envia uma mensagem para um provedor de serviços. Em sistemas complexos, um roteador de mensagens pode inicialmente receber a mensagem e aplicar alguma lógica para rotear a solicitação para o provedor de serviços apropriado. Em seguida, o provedor de serviços recebe a mensagem, talvez a desempacote e a reformate, faz qualquer trabalho que seja necessário e, em seguida, pode enviar uma resposta para o consumidor de serviços.

Figura 1:  Pequena parte de um aplicativo SOA

O detalhe importante da Figura 1 é que cada nó da transação está recebendo, armazenando e transmitindo dados de várias formas. Algumas vezes, os dados são transitórios, outras, cada nó pode persistir os dados para um cache ou para seu próprio banco de dados local. (Para ver uma discussão polêmica que aborde as mensagens como “dados interessantes” que devem ser persistidos, consulte “Queues Are Databases” (em inglês), de Jim Gray, da Microsoft Corporation. Uma lista de referências é incluída no final deste white paper.)

Em face dessas novas maneiras de manipular dados em um aplicativo, os bancos de dados centrais dos aplicativos SOA enfrentam um conjunto de desafios diferente daquele que era enfrentado pelos aplicativos monolíticos de várias camadas. A integridade dos dados tem a mesma importância de sempre, mas existem agora requisitos adicionais:

• O banco de dados deve operar em um ambiente onde as solicitações sejam recebidas via mensagens baseadas em XML e não via conexões dedicadas

• Os repositórios de dados armazenados em cache precisam saber quando atualizar os dados de forma mais eficiente do que fazendo uma atualização programada

• O banco de dados precisa participar de diálogos que devem ocorrer em uma seqüência definida

• Há uma lógica complexa que precisa ser hospedada no banco de dados ou próxima a ele

O XML cria um bom formato de mensagem para sistemas amplamente distribuídos. Ele é facilmente analisado por quase todos os sistemas e tem uma linguagem de modelagem de esquema para definir a estrutura apropriada dos dados. Os sistemas que trocam mensagens podem anexar informações a uma mensagem XML para que os dados se acumulem na mensagem conforme ela flui pelo sistema. Os sistemas podem analisar e processar aquilo que compreendem e ignorar o restante. Simplificando, o XML foi projetado como um formato adaptável para oferecer suporte a sistemas distribuídos.

Os arquitetos da Microsoft reconheceram essas tendências arquitetônicas e criaram o Microsoft® SQL Server™ 2005 para atender aos novos desafios e continuar a oferecer suporte a muitos aplicativos não-SOA existentes. Este white paper discute o acesso a serviços da Web nativos, as notificações de alterações de bancos de dados, o Service Broker e o SQLXML no contexto de uso do SQL Server 2005 em um aplicativo SOA. Ele não fornece uma introdução à SOA, nem uma visão geral de todos os novos recursos do SQL Server 2005, mas supõe que você esteja familiarizado com esses tópicos. Para obter mais informações sobre esses tópicos, consulte as referências no final do documento.

Dados em uma arquitetura orientada a serviço

Ao explorar os conceitos da SOA, rapidamente torna-se claro que cada componente do sistema geral está recebendo, processando e transmitindo dados como uma de suas funções principais. Mesmo que a resposta de um provedor de serviços a uma mensagem enviada por um consumidor de serviços seja simplesmente mudar um bit para ativar ou desativar algo sem a interação com um banco de dados, o provedor precisa processar os dados da mensagem para determinar o trabalho a ser feito. Mas os aplicativos comerciais modernos lidam com os dados de maneira extensiva, portanto, é comum que um componente da SOA tenha acesso a um banco de dados local ou centralizado ou, freqüentemente, a ambos.

Muitos dos novos recursos do SQL Server 2005 fazem parte de um design arquitetônico integrado que oferece suporte ao uso do banco de dados como um provedor de serviços da SOA. A equipe do SQL Server na Microsoft chama isso de Service-Oriented Database Architecture ou SODA.

Existem vários motivos convincentes para implementar recursos da SOA diretamente no mecanismo de banco de dados, incluindo:

• Aumento ou redução da dimensão. Até mesmo no maior aplicativo de negócios SOA, um serviço individual pode ser instanciado em quase qualquer escala; um serviço pouco usado pode ter menos atividade que um pequeno banco de dados de departamento típico. A integração com o SQL Server significa que um programa de serviço pode tirar proveito de todo o suporte nativo para dimensionar desde dispositivos incorporados até o maior servidor de banco de dados corporativo, sem aumentar a complexidade administrativa. O código da lógica do serviço pode ser executado em qualquer escala, e qualquer implementação pode ser dimensionada para uma camada intermediária separada no momento da implantação. Com o SQL Server 2005, a lógica do serviço pode ser executada na camada de dados ou ser implantada na camada intermediária. Se você projetar um aplicativo cuidadosamente, o método de dimensionamento poderá ser uma decisão de implantação em vez de uma decisão de design ou desenvolvimento.

• Dimensionamento. É possível dimensionar a computação focada em dados de várias maneiras, geralmente dimensionando o banco de dados ou distribuindo o processamento usando a SOA. O dimensionamento do banco de dados resulta em um cluster de bancos de dados que é relativamente rígido, ao passo que a solução orientada a serviço é mais flexível. A incorporação do suporte à SOA diretamente no banco de dados reduz os processos de componentes necessários para uma solução de grade autêntica.

• Mensagens são dados. As várias mensagens de solicitação e de resposta são “dados interessantes” que podem ter valor suficiente para serem arquivadas em um banco de dados. Manter as mensagens disponíveis ao longo do tempo fornece um histórico que permite auditar e analisar transações. Como as mensagens são armazenadas em tabelas e têm modos de exibição de catálogo do sistema disponíveis, é possível usar facilmente o Transact-SQL para ver o status de qualquer parte do sistema.

Existem benefícios enormes na implementação de recursos da SOA no SQL Server para que ele possa atuar como um provedor de serviços autônomo em um aplicativo SOA. Mas, para isso, ele deve ser capaz de atuar como um provedor de serviços, o que exige um conjunto de recursos mínimo.

Requisitos para um provedor de serviços da SOA

Para que o SQL Server 2005 ou qualquer mecanismo de banco de dados assuma uma função como um programa de serviço da SOA autônomo, ele deve implementar vários recursos além de sua habilidade nativa para manipular dados:

• Suporte a ponto de extremidade. O provedor da SODA deve dar suporte à comunicação para receber e transmitir mensagens, normalmente como um soquete TCP, HTTP GET ou PUT, ponto de extremidade do protocolo SOAP ou outro tipo de ponto de extremidade.

• Processamento das solicitações de serviço. A maioria das mensagens na SOA é formatada usando XML, portanto, o provedor de serviços deve ser capaz de processar e, possivelmente, transformar os dados incluídos em outros formulários, conforme a necessidade dos componentes do serviço. Ele também deve ser capaz de participar de diálogos e conversações complexos à medida que mensagens interdependentes são recebidas e enviadas a outros componentes.

• Host da lógica do serviço. O provedor deve ser capaz de executar qualquer lógica complexa exigida para o processamento da mensagem e fornecer a resposta necessária, assim como, provavelmente, coordenar a entrada de vários outros serviços. Isso pode exigir tarefas comuns de servidor de aplicativos, como recursos de pool, ativação e processamento da lógica do dimensionamento.

Os vários novos recursos do SQL Server 2005 dão suporte a essas funções, além de muitas outras infra-estruturas para oferecer suporte ao gerenciamento de dados. Por exemplo, um provedor de serviços deve participar de maneira segura de um sistema SOA e ser capaz de autenticar clientes e, em troca, fornecer credenciais para autenticar-se com outros sistemas, fornecer durabilidade, participar de conversações e transações e outros recursos no nível dos aplicativos.

O SQL Server 2005 amplia os recursos do mecanismo de banco de dados relacional do SQL Server 2000, bem como de versões de novas tecnologias surgidas desde seu lançamento original, como SQLXML 3.0, Notification Services e outras ferramentas, para tirar proveito completamente da SODA (Service-Oriented Database Architecture).

Recursos da SODA do SQL Server 2005

O SQL Server 2005 inclui os recursos para implementar a SODA de forma que um único processo do SQL Server possa funcionar como um provedor de serviços completo em um aplicativo distribuído e flexível. A Microsoft espera que recursos semelhantes acabem se tornando tão comuns em sistemas de bancos de dados corporativos quanto as comunicações em rede, os pools de threads e os procedimentos armazenados ou seus equivalentes. Esses novos recursos do SQL Server 2005 são discutidos nesta seção:

• Acesso a serviços da Web nativos, para permitir a comunicação baseada em mensagens no SOAP e em outros protocolos que tiram proveito do driver de modo de kernel HTTP do Windows Server 2003, o Http.sys.

• Service Broker, uma nova classe de middleware transacional que é focada em serviços, e não em mensagens, para oferecer suporte a serviços escalonáveis.

• Notificações de consulta, que permitem que caches dependentes de dados recebam uma notificação de que os dados precisam ser atualizados devido a uma alteração no banco de dados de base. A notificação é gerada com base na consulta original que foi usada para criar e popular o cache.

• SQLCLR, que integra totalmente o processamento de lógica sofisticado ao banco de dados para reduzir latências devidas ao acesso remoto aos dados.

Acesso a serviços da Web nativos: HTTP e outros pontos de extremidade

Durante anos, a única forma real de comunicação entre um cliente e um servidor executando o SQL Server era por meio do protocolo proprietário TDS (Tabular Data Stream). O TDS ainda é o meio de acesso a dados mais rápido e eficiente, mas, para se comunicar com o servidor, o cliente precisa ter as bibliotecas apropriadas instaladas. Para que o SQL Server 2005 seja um provedor de serviços da SOA completo, ele deve oferecer suporte a protocolos baseados em padrões para fornecer pontos de extremidade que auxiliam na aceitação e no processamento de solicitações de qualquer tipo de consumidor. As extensões do SQLXML para o SQL Server 2000 criaram a base para esse recurso incluindo um filtro ISAPI para uso com o IIS (Serviços de Informações da Internet), a fim de permitir a comunicação baseada em serviços da Web em HTTP com o SQL Server.

O SQL Server 2005 oferece suporte a uma abstração de ponto de extremidade formal que pode ser usada para dar suporte a uma variedade de tipos de ponto de extremidade, incluindo TDS, espelhamento de bancos de dados, serviços da Web e Service Broker. O tipo de ponto de extremidade HTTP permite que a instância do SQL Server funcione como um provedor de serviços para qualquer tipo de aplicativo em qualquer tipo de dispositivo que tenha suporte a serviços da Web sobre HTTP e os protocolos WS-Security em uma solução SOA.

O acesso a serviços da Web nativos requer que o SQL Server 2005 esteja instalado no Windows Server 2003 para tirar proveito do ouvinte HTTP do modo de kernel do Windows Server. O SQL Server pode se registrar com o ouvinte HTTP para reservar partes do namespace da URL. A Figura 2 mostra a alta integração e a conexão direta entre o driver e o banco de dados. Quando o ouvinte HTTP recebe uma solicitação HTTP por meio de uma porta 80 (por padrão), ele roteia a solicitação diretamente para o ponto de extremidade que você define dentro do SQL Server. Em seguida, o SQL Server executa qualquer processamento necessário e retorna uma resposta por meio do Windows.

Figura 2:  Integração do SQL Server 2005 com o driver Http.sys do Windows Server 2003

Como a instalação não requer o IIS, e como as solicitações são enviadas diretamente do driver Http.sys no modo de kernel para o SQL Server, a administração dessas solicitações é simples e eficiente. O Http.sys fornece o isolamento de processos baseado em kernel entre os vários aplicativos que podem possuir diferentes partes do namespace da URL, para que diferentes pontos de extremidade na mesma e em outras instâncias do SQL Server não possam interferir uns com os outros.

Depois que o ouvinte HTTP no Windows é configurado para enviar solicitações ao SQL Server, um administrador de banco de dados (DBA) pode definir pontos de extremidade e ligar procedimentos armazenados e funções de valor escalar a um ponto de extremidade como métodos da Web. A instrução CREATE ENDPOINT requer que você especifique uma URL exclusiva que será usada para ouvir solicitações HTTP recebidas. Normalmente, essas solicitações serão feitas no formato “http://meuServidor.com/meuPontoDeExtremidade” de forma que o sistema DNS possa direcionar a solicitação para o servidor apropriado. Por sua vez, o servidor roteia as solicitações para o ponto de extremidade definido apropriado e, em seguida, para a camada de processamento do SOAP dentro do SQL Server. Cada instância do SQL Server pode ter vários pontos de extremidade, e cada um deles pode ter vários métodos da Web ligados a ele.

Um método da Web ligado a um ponto de extremidade HTTP pode ser um procedimento armazenado ou uma função de valor escalar definida pelo usuário. O nome do método dentro do SQL Server não precisa ser o mesmo que o nome do método da Web definido publicamente. O SQL Server executará o código correto definido para o método da Web. A implementação do método da Web não precisa ter nenhum código para analisar a solicitação ou formatar o resultado para devolução ao consumidor de serviços, porque o SQL Server 2005 gerencia essas funções para você. É possível permitir a execução de lotes de instruções SQL em relação a um ponto de extremidade. No entanto, isso provavelmente não é útil em um aplicativo SOA, e não é aconselhável por motivos de segurança, a não ser em ambientes altamente controlados.

Um ponto de extremidade pode ser configurado para gerar e fornecer automaticamente dados em WSDL (Web Service Definition Language) que especificam a interface dos métodos da Web do provedor. Também é possível configurar o servidor para fornecer WSDL personalizado se você precisar ajustar manualmente as informações fornecidas ou se optar por não fornecer a WSDL de forma nenhuma.

Os pontos de extremidade oferecem suporte à autenticação básica, Digest, integrada (NTLM ou Kerberos) e do SQL Server, mas não oferecem suporte a solicitações anônimas. Essa seleção de métodos de autenticação dá suporte a praticamente qualquer cliente em um aplicativo SOA de plataforma mista. É possível usar a autenticação integrada com consumidores do Windows e a autenticação do SQL Server para todos os outros consumidores, por exemplo. O SQL Server oferece suporte à especificação WS-Security, portanto, você pode passar credenciais usando os cabeçalhos do token do nome de usuário para a autenticação do SQL Server. Você pode restringir ainda mais ou permitir solicitações com base no endereço IP do consumidor.

Os pontos de extremidade HTTP são desativados por padrão, para que uma instância recém-instalada do SQL Server esteja protegida por padrão. Isso significa que os ataques não são possíveis a não ser que os pontos de extremidade HTTP sejam habilitados explicitamente por um administrador. Apenas os membros da função de servidor fixa sysadmin ou o criador do ponto de extremidade podem se conectar inicialmente ao ponto de extremidade, até que eles concedam permissão explicitamente, usando a instrução GRANT CONNECT, para permitir que outros usuários se conectem. Assim como em qualquer conexão HTTP, é possível proteger o canal usando o SSL para proteger quaisquer credenciais de texto não criptografado transmitidas por alguns dos métodos de autenticação.

Sistema de transmissão de mensagens confiável: Service Broker

Um dos principais requisitos de um programa de serviço da SOA é que ele seja capaz de se comunicar com outros componentes do aplicativo. Uma infra-estrutura de transmissão de mensagens robusta deve ser segura, assíncrona, confiável e escalonável. Como a SOA é incorporada ao sistema transmissão de mensagens, o SQL Server 2005 deve oferecer suporte ao sistema de transmissão de mensagens, se ele for utilizado como um provedor de serviços.

O Service Broker do SQL Server 2005 é um recurso do sistema de transmissão de mensagens que recebe, processa e envia mensagens. Ele é altamente integrado ao mecanismo de banco de dados. O Service Broker facilita a troca de mensagens entre programas de serviço da SOA. O Service Broker fornece uma variedade de recursos para aplicativos que necessitam da entrega garantida de mensagens ordenadas:

• Assíncrono. Com o enfileiramento de mensagens, os programas de serviço podem manipular a carga de trabalho de forma eficiente, sem bloqueios severos durante os picos de carga.

• Ordenado. Em uma conversação entre um consumidor e um provedor de serviços, a ordem das mensagens é sempre importante. Um sistema deve respeitar a ordem das mensagens enviadas e garantir que o processamento ocorrerá na ordem correta.

• Confiável. Com sua alta integração ao mecanismo de banco de dados, o Service Broker tira total proveito das transações de mensagens e diálogos para garantir que mensagens críticas sejam recebidas exatamente uma vez.

• Durável. Quer uma mensagem e seu processamento sejam bem-sucedidos ou não, a mensagem ou os resultados devem sobreviver a uma falha do sistema. Se houver falha no processamento, a mensagem deverá ser colocada de volta na fila de recebimento.

Objetos e processamento do Service Broker

O Service Broker introduz vários novos objetos de banco de dados, como tipos de mensagens, contratos de serviço, filas, serviços, diálogos, grupos de conversação e programas de serviço. A criação de um provedor de serviços envolve várias etapas para criar e configurar alguns ou todos esses objetos, usando várias novas formas da instrução Transact-SQL CREATE. Assim que esses objetos são implementados, você pode enviar mensagens formatadas em XML usando a instrução Transact-SQL SEND e um programa de serviço pode extraí-las de uma fila de recebimento com a instrução RECEIVE.

As mensagens são enviadas a um serviço que você define, que coloca as mensagens em uma fila para aguardar o processamento por um programa de serviço, conforme mostrado na Figura 3. Quase sempre, um programa de serviço é um procedimento armazenado que atua como a transferência de mensagens do Windows, separando e processando as mensagens e enviando respostas. O Service Broker usa um modelo que é algo entre os modelos de recebimento e de eventos, ativando o programa de serviço que está ligado a uma fila, conforme necessário, para processar mensagens recebidas. O Service Broker pode ativar programas de serviço adicionais até um limite predefinido, conforme necessário, para evitar afunilamentos e manipular picos de carga de maneira eficiente.

Figura 3:  Estrutura e diálogo simples do Service Broker

A fila do Service Broker é o meio principal de oferecer suporte ao processamento de mensagens confiável e assíncrono. Como uma fila é uma tabela do banco de dados, as mensagens enfileiradas recebem os mesmos benefícios que outros dados relacionais, incluindo recuperação em caso de falha do banco de dados e entrega garantida para a fila usando transações com os mesmos benefícios de ACID (atomicidade, consistência, isolamento, durabilidade) de outros dados.

No entanto, o Service Broker faz mais do que simplesmente gerenciar filas. Ele fornece uma estrutura completa para oferecer suporte a aplicativos que exigem um sistema transmissão de mensagens confiável. Além de economizar a criação da infra-estrutura complexa do sistema de transmissão de mensagens para os desenvolvedores — uma tarefa hercúlea, na melhor das hipóteses — o Service Broker gerencia as mensagens de forma que elas sejam entregues na ordem correta. Ele também gerencia conversações, contratos, roteamento e ligações de serviços remotos.

Quando um aplicativo tradicional orientado a mensagens vai além de um simples padrão de sistema de transmissão de mensagens de solicitação/resposta, ele precisa lidar com problemas de correlação e controle da concorrência entre as mensagens destinadas para a fila. Isso pode ser um problema quando há vários programas de serviço recebendo mensagens de uma fila. O Service Broker usa o bloqueio de grupos de conversação para lidar com problemas de concorrência. Um grupo de conversação é a coleção de todos os diálogos usados para uma determinada tarefa. Um diálogo é a troca de mensagens entre programas de serviço, cada um agindo alternadamente como consumidor e provedor de serviços.

Grupos de conversação

A Figura 4 mostra um grupo de conversação típico em resposta ao recebimento de uma mensagem de Processar Pedido em um sistema simples de entrada de pedidos. Quando a mensagem de Processar Pedido é recebida, o Serviço de Processamento de Pedidos envia mensagens para os Serviços de Crédito e de Verificação de Estoque. Nesse ponto, enquanto aguarda as respostas na conversação em andamento, o estado pendente pode ser confirmado no banco de dados. Em seguida, as respostas dos dois serviços podem chegar, individualmente ou quase simultaneamente, o que ativa o grupo de conversação.

Figura 4:  Grupo de conversação que consiste em vários diálogos

A ativação do grupo de conversação — e não a chegada de uma mensagem em uma fila — é que solicita aos programas de serviço que eles processem as mensagens. Um grupo de conversação ativo é processado dentro de uma transação que pode ser processada apenas por um único programa de serviço. Isso tem várias implicações em diferentes cenários:

• A resposta da Verificação de Crédito é recebida enquanto um programa de serviço está processando a resposta da Verificação de Estoque. Nesse caso, a resposta da Verificação de Crédito não é processada até que o grupo de conversação tenha sido confirmado e reativado por outro programa de serviço.

• As duas respostas chegam antes que qualquer programa de serviço consuma o grupo de conversação ativo. O programa de serviço recebe as duas mensagens, em lote. Além disso, o programa de serviço ativo pode verificar mensagens adicionais na fila e processá-las antes de concluir seu trabalho.

No segundo caso, o processamento em lote pode levar a soluções escalonáveis, já que o trabalho associado a um grupo de conversação pode se acumular em resposta à latência do processamento dos programas de serviço. Os grupos de conversação também podem otimizar a recuperação de estado quando as informações de estado são salvas e associadas à GUID que identifica o grupo. Qualquer programa de serviço que processe mensagens associadas ao grupo de conversação pode recuperar o estado do grupo de conversação uma vez, e não para cada mensagem.

O grupo de conversação inteiro precisa ter seu trabalho totalmente confirmado ou não confirmado. Se tudo correr bem, o estado do grupo de conversação pode ser permanentemente confirmado no banco de dados, processando o pedido de forma eficiente, o que, por sua vez, faz com que mais mensagens sejam enviadas, como para um serviço de entrega, por exemplo. Se algo sair errado, a mensagem original será colocada de volta na fila original do Serviço de Processamento de Pedidos e o estado do banco de dados será restaurado ao estado anterior ao recebimento da mensagem.

Quando um programa de serviço retira uma mensagem de uma fila que faz parte de um grupo de conversação, o grupo é bloqueado de forma que as mensagens da conversação sejam processadas na ordem especificada pelo consumidor de serviços. O Service Broker usa esse mecanismo para garantir que as mensagens sejam processadas na ordem correta.

Integração com banco de dados

O Service Broker é incorporado ao mecanismo de banco de dados do SQL Server 2005. Ele não usa um middleware transacional separado ou uma infra-estrutura de filas de mensagens, como o Microsoft Message Queue. Isso fornece vários benefícios (alguns dos quais são totalmente aproveitados apenas quando o consumidor e o provedor de serviços estão no mesmo banco de dados):

• Os aplicativos do Service Broker são desenvolvidos usando o Transact-SQL e o SQLCLR. Você cria um aplicativo de Service Broker usando procedimentos armazenados, funções definidas pelo usuário e código do .NET Framework, todos com suporte das extensões do Service Broker para o Transact-SQL. Você pode utilizar suas habilidades existentes ao criar um provedor de serviços com o SQL Server.

• O bloqueio do grupo de conversação oferece suporte a vários leitores de fila. O Service Broker usa um bloqueio especial de banco de dados que permite que vários programas de serviço processem mensagens em uma única fila.

• Administração simplificada. Como as mensagens e os dados estão localizados no mesmo banco de dados, qualquer atividade de recuperação restaura mensagens e dados. Se eles estiverem separados, poderão ficar facilmente fora de sincronização, e poderá ser extremamente difícil descobrir quais mensagens foram processadas. Se o banco de dados usar espelhamento, clusters ou outros recursos de proteção de dados do SQL Server, as mensagens terão a mesma proteção que outros dados. Além disso, você precisa configurar opções de segurança em um local apenas, embora tenha a flexibilidade de definir permissões no Service Broker e em objetos de dados conforme necessário.

• Processamento mais eficiente. Embora o Service Broker ofereça suporte à troca de mensagens com outros serviços de agente de serviços, se os serviços do consumidor e do provedor estiverem no mesmo banco de dados, uma mensagem poderá ser enviada diretamente para a fila de recebimento, ignorando assim a fila de envio e economizando tempo significativo de processamento. E, como o Service Broker tem uma visão global de todas as filas em uma instância do banco de dados, ele pode gerenciar mensagens, filas e a infra-estrutura de maneira eficiente.

• Suporte a ferramentas e linguagens comuns. Você usa as mesmas ferramentas e linguagens — como Transact-SQL, Microsoft Visual Basic® .NET, Microsoft Visual C#® — para manipular dados no banco de dados e para gerenciar o Service Broker. Os desenvolvedores e administradores podem usar as ferramentas com as quais estão familiarizados para desenvolver e gerenciar aplicativos de sistemas de transmissão de mensagens.

O Service Broker é diferente de outros middlewares transacionais de outra maneira importante: ele é focado em serviços e não em mensagens. Isso permite que o SQL Server manipule o controle complexo de concorrência de mensagens recebidas de vários programas de serviço concorrentes e permite otimizações no processamento de transações.

Notificações de consulta

Uma das maneiras mais úteis de aprimorar o desempenho de aplicativos amplamente distribuídos e flexíveis é armazenar os dados em cache. O armazenamento em cache de dados que raramente são alterados e podem ser facilmente atualizados em um provedor ou consumidor de serviços remoto em relação ao banco de dados de origem permite que as mensagens sejam mais leves e usem menos largura de banda.

Um sistema desse tipo precisa de uma forma para atualizar os dados quando eles são alterados na origem. Existem muitas maneiras de se fazer isso. Provavelmente, o método mais fácil do ponto de vista da programação é definir um cache para expirar periodicamente, de alguns minutos a algumas semanas, dependendo do tipo de dados. Mas os esquemas desse tipo são aproximações e tendem a fazer as atualizações com muita freqüência, fazendo com que os dados sejam desnecessariamente enviados pela rede, ou com freqüência insuficiente, tornando os dados obsoletos. Em muitas situações, o método mais eficiente é simplesmente notificar o guardião de cada cache de que os dados foram alterados e extrair os dados do banco de dados de origem ou recebê-los do programa de serviço. Um programa de serviço pode usar sua própria lógica e optar por ignorar a notificação, por exemplo, se ele determinar que os dados não precisam ser atualizados ou se a atualização puder ser adiada para um horário fora do pico.

Este é o fluxo de trabalho geral para uma notificação de consulta:

1. Um aplicativo de serviço envia uma consulta SQL ao servidor de banco de dados e inclui uma anotação especial de que o serviço solicita notificação quando os dados da consulta forem alterados.

2. O SQL Server gera uma solicitação de assinatura e a registra para a consulta. Em seguida, ele cria um plano de execução otimizado e o executa.

3. Os resultados da consulta são retornados para o cliente, normalmente destinados a um cache que é gerenciado pelo cliente.

4. O banco de dados monitora qualquer alteração que modifique os dados da consulta ou sua estrutura. Quando ele detecta esse tipo de alteração, gera uma notificação de alteração e a envia para a fila.

5. A notificação é processada e enviada ao aplicativo de serviço cliente.

   

   Figura 5:  Fluxo de trabalho da notificação de consulta

Independentemente de quantas alterações são feitas nos dados de base, o aplicativo cliente recebe uma única notificação de consulta. Para receber outra notificação de dados alterados, o aplicativo cliente deve consultar o banco de dados novamente, mais uma vez incluindo a anotação de solicitação de notificação. Geralmente, isso é feito durante a execução da consulta que atualiza o cache de dados.

Host da lógica do serviço: SQLCLR

Todos os recursos discutidos até agora fornecem uma infra-estrutura crítica para que o SQL Server 2005 funcione como um participante viável de um aplicativo SOA. O ingrediente crítico remanescente é a lógica — a capacidade de executar código de alto nível para controlar todos os aspectos do sistema, processar as entradas e responder a mudanças das condições do ambiente. O SQL Server há muito tempo inclui o Transact-SQL, uma extensão da Structured Query Language baseada em conjuntos, além de extensões, como os procedimentos armazenados estendidos e a capacidade de invocar aplicativos externos, como componentes do COM que usam os procedimentos armazenados do sistema sp_OA.

Mas, para ser um provedor de serviços da SOA viável, deve ser possível executar código integrado, de alto nível e com bom desempenho, capaz de materializar abstrações altamente complexas da lógica comercial. O Transact-SQL é ideal para manipular dados relacionais baseados em conjuntos, mas não está à altura da tarefa de elaboração de lógica comercial. O Microsoft .NET Framework e as linguagens compatíveis com o .NET fornecem exatamente a infra-estrutura de programação e a sintaxe necessárias. O .NET Framework versão 2.0 tem uma API de hospedagem de CLR que permite que os desenvolvedores executem aplicativos CLR (common language runtime) dentro de um processo de host, como o SQL Server 2005. Você pode usar esse recurso SQLCLR do SQL Server para escrever código do .NET Framework que é executado dentro do processo do SQL Server, está próximo dos dados e de outros recursos da SODA e está integrado à segurança do banco de dados. Os assemblies de código são armazenados e carregados diretamente do banco de dados, e não do sistema de arquivos. Isso aumenta a eficiência e reduz a complexidade administrativa.

Você pode usar o SQLCLR para escrever funções como substituições de procedimentos armazenados estendidos e para escrever funções definidas pelo usuário. Ele tem uma variedade de outros usos dentro do banco de dados para aplicativos mais tradicionais (embora não substitua todos os aplicativos do Transact-SQL). Em um aplicativo baseado na SODA, a hospedagem do CLR fornece um ambiente de execução de código que dá suporte a várias linguagens de programação, ao gerenciamento de memória de coleção de lixo, ao pool de recursos, ao gerenciamento de recursos do sistema e à segurança de acesso ao código.

A Figura 6 mostra como o SQLCLR se integra ao sistema existente e aos procedimentos armazenados estendidos em um processo comum de sistema operacional. O processo principal do SQL Server trabalha com o CLR para controlar recursos do processo global, como memória, primitivos de concorrência e threads.

Figura 6:  Camada de hospedagem do SQLCLR

A integração do SQLCLR altera e expande radicalmente o paradigma de programação dentro do SQL Server. Ela permite o desenvolvimento de tipos e agregações personalizados, disparadores, funções definidas pelo usuário, procedimentos armazenados de lógica intensa e outros objetos de código que superam as limitações de uma linguagem e um mecanismo de execução baseados em SQL. Essa sofisticação é necessária para um programa de serviço dentro de uma arquitetura orientada a serviço. Você pode colocar parte ou toda a lógica dentro do banco de dados em vez de desenvolver e implantar um componente de aplicativo separado e externo ao banco de dados para o processamento da lógica. Para aplicativos mais tradicionais de três ou várias camadas, a linha entre a hospedagem do código de processamento de dados no banco de dados e da lógica dos negócios em uma camada intermediária é indistinta. Mas agora é relativamente fácil desenvolver uma base de código que pode ser implantada no banco de dados ou em um servidor de aplicativos de camada intermediária conforme as exigências em relação ao sistema mudam.

O conjunto de recursos do SQLCLR pode ser usado para estender a função do SQL e a biblioteca de agregações disponível para a linguagem SQL. Interfaces estão disponíveis para implementar funções definidas pelo usuário, funções de valores de tabelas e agregações definidas pelo usuário. Depois de instaladas, essas funções ficam disponíveis para uso dentro de qualquer consulta de usuário. Como as funções do CLR são compiladas na IL (linguagem intermediária) e finalmente nas instruções nativas da máquina, as funções podem ser executadas muito mais rapidamente do que as funções equivalentes escritas em Transact-SQL, que são interpretadas em tempo de execução em vez de compiladas previamente. Em muitos cenários do mundo real, a velocidade dos aplicativos aumentou em 10 vezes ou mais quando as funções do Transact-SQL ou as funções de valores de tabelas foram reescritas em SQLCLR.

O SQLCLR também fornece uma biblioteca de acesso a dados do SQLClient que pode ser executada dentro do mecanismo relacional. Quando o código de acesso a dados do SQLCLR é executado dentro do processo do SQL Server, conforme mostrado na Figura 6, as latências e os custos de transação da conexão a um banco de dados remoto e da aquisição de dados são consideravelmente reduzidos. Os dados necessários para processar uma solicitação de serviço de um servidor externo não precisam viajar por uma parte da rede ou mesmo de uma máquina adjacente no rack do servidor. Por outro lado, o código do SQLCLR compete com outras funções gerais do banco de dados pelos recursos de processamento do servidor. É necessário um design criterioso para determinar a melhor arquitetura para qualquer aplicativo em particular.

Topologias de computação da SODA

A incorporação da SOA a um banco de dados apresenta algumas topologias interessantes, pois o SQL Server é dimensionado de um único laptop para servidores de classe empresarial, com lógica hospedada dentro do processo do SQL Server ou em outros recursos da rede. Por exemplo, o SQL Server 2005 oferece suporte a cenários ocasionalmente conectados, onde os dados são armazenados em cache em um laptop durante o dia, quando ele está desconectado da rede, e atualizados quando ele é conectado. E o melhor de tudo é que o dimensionamento de um aplicativo SOA não requer a alteração do contrato de serviço. Um aplicativo SOA flexível não se importa com a forma e o local de implementação da lógica de um componente específico.

Por exemplo, a Figura 7 mostra um programa de serviço que está completamente contido em um processo do SQL Server, expondo um acesso a serviços da Web nativos para receber e enviar mensagens. Esse cenário reduz a latência entre a lógica do aplicativo e os dados, mas consome recursos do servidor que, de outra forma, estariam disponíveis para o trabalho do banco de dados.

Figura 7:  Processo de serviço típico da SODA

Não existe nenhum requisito para que o programa de serviço seja hospedado dentro do processo do SQL Server. Em vez disso, ele pode ser executado em outro processo na mesma máquina ou em uma máquina completamente diferente, como mostra a Figura 8. Isso oferece suporte ao dimensionamento da lógica do serviço, enquanto o mecanismo de banco de dados lida com as mensagens de processamento para manipular solicitações e respostas de serviço e funções regulares do mecanismo de banco de dados.

Figura 8:  Dimensionamento do processo de serviço

Quando utilizada em aplicativos altamente dimensionados, a arquitetura de agente de serviços permite a implementação de roteadores de serviço sofisticados que cuidam dos diálogos de roteamento através de uma camada de serviços dimensionados. Isso pode tirar proveito dos recursos de roteamento de um aplicativo SOA e é demonstrado na Figura 9.

Figura 9:  Serviços dimensionados usando um Roteador de Serviços

A SOA oferece suporte a topologias muito flexíveis, e a SODA amplia esses recursos para permitir dimensionamento e topologias apropriados, até mesmo dentro de um único programa de serviço hospedado no SQL Server 2005.

Conclusão

A Service-Oriented Database Architecture permite que o SQL Server desempenhe um papel importante no desenvolvimento de aplicativos baseados em arquitetura flexível e orientada a serviço. O SQL Server 2005 inclui acesso a serviços da Web, notificação de alterações de bancos de dados, middleware transacional e recursos integrados do SQLCLR porque esses recursos são uma maneira eficiente de implementar um programa de serviço em um aplicativo SOA. Outros mecanismos de banco de dados são integrados a esses recursos. No entanto, a inclusão desses recursos diretamente no mecanismo de banco de dados se beneficia da capacidade nativa do SQL Server de gerenciar dados e dar suporte a uma variedade de métodos de dimensionamento, de aumento ou redução, bem como a uma variedade de topologias de computação. Todos os recursos descritos neste documento podem ser usados independentemente. No entanto, quando usados em conjunto em um programa de serviço, eles formam uma plataforma sinérgica que pode ser usada para criar componentes de serviço independentes e autônomos.

A SODA fornece uma alternativa aos servidores de aplicativos tradicionais e habilita uma nova classe de aplicativos focados em serviços.

Referências

Service-Oriented Database Architecture

• David Campbell, “Service Oriented Database Architecture: App Server-Lite?” (em inglês), atas da conferência internacional da ACM SIGMOD de 2005 sobre gerenciamento de dados, https://research.microsoft.com/research/pubs/view.aspx?tr_id=983. Documento original do qual este white paper é derivado.

• Jim Gray, “Queues Are Databases” (em inglês), Microsoft Research, dezembro de 1995, https://research.microsoft.com/research/pubs/view.aspx?pubid=496 . Uma breve análise da função que os bancos de dados podem desempenhar no MOM (message-oriented middleware) que usa filas.

• Pat Helland, “Data on the Outside vs. Data on the Inside: An Examination of the Impact of Service Oriented Architectures on Data” (em inglês), https://msdn.microsoft.com/library/en-us/dnbda/html/dataoutsideinside.asp . Explora as diferenças dos dados dentro e fora dos limites de serviço.

Service Oriented Architecture

• Site da Microsoft Service Oriented Architecture (em inglês): https://msdn.microsoft.com/architecture/soa/default.aspx

• Sessão TechEd de 2005 de David Campbell, “DAT470—Service Oriented Data Architecture (SODA): How SQL Server 2005 Fits into the Service-Oriented Architecture (SOA) World” (em inglês), junho de 2005.

• Aaron Skonnard, “SOA: More Integration, Less Renovation” (em inglês), edição de fevereiro de 2005 da MSDN Magazine, https://msdn.microsoft.com/msdnmag/issues/05/02/servicestation/.

• Douglas K. Barry, Web Services and Service-Oriented Architectures: The Savvy Manager's Guide (em inglês), Morgan Kaufmann Publishers, 2003, ISBN 1558609067. Uma excelente visão geral da Service-Oriented Architecture pelo ponto de vista independente de plataforma.

SQL Server 2005

• Site do Microsoft SQL Server 2005: https://www.microsoft.com/brasil/sql

• Peter DeBetta, Introducing Microsoft SQL Server 2005 for Developers * * (em inglês), Microsoft Press, 2005, ISBN 073561962X. Baseado em versões CTP anteriores do SQL Server 2005, portanto, já ocorreram algumas mudanças. Grande quantidade de códigos e detalhes sobre como usar os novos recursos.

• Bob Beauchemin et alli, A First Look at Microsoft SQL Server 2005 for Developers * *(em inglês), Addison-Wesley, 2004, ISBN 0321180593. Publicado em meados de 2004 e, portanto, baseado em versões beta iniciais. Já ocorreram muitas mudanças depois disso. No entanto, essa continua sendo uma ótima visão geral dos novos recursos do SQL Server 2005 pelo ponto de vista de um desenvolvedor.

• Michael Otey, Microsoft SQL Server 2005 New Features * *(em inglês), Osborne, ISBN 0072227761. Uma boa visão geral dos novos recursos, pelo ponto de vista de um administrador de bancos de dados.

Para obter mais informações:

https://www.microsoft.com/technet/prodtechnol/sql/default.mspx (em inglês)