N style="mso-spacerun: yes">
Clique aqui para ler todos os artigos desta edição
Microsoft SQL Server 2005
Integração com o CLR - Common Language Runtime
Helio Sa Moreira
Codename Yukon ou Microsoft SQL Server 2005, já há alguns meses temos nos deparado com uma grande movimentação relacionada à nova versão do Microsoft SQL Server, com o lançamento pré-anunciado para o último trimestre deste ano. Diversos artigos introdutórios, workshops e eventos de divulgação vêm alimentando nossa ansiedade com novos conceitos, tecnologias, ferramentas, serviços e muitos detalhes sobre esta nova versão.
Graças a estas iniciativas, atualmente uma grande parte dos profissionais ligados direta ou indiretamente ao SQL Server tem capacidade de descrever, ao menos superficialmente; características, melhorias e um pouco das novidades que acompanham esta nova versão.
Chegou então a hora de aprofundarmos nossos conhecimentos e iniciarmos juntos uma grande viajem por dentro dos detalhes e novidades desta revolução anunciada. É com esta missão que me apresento aos leitores da SQL Magazine e coloco em nossa pauta a integração do SQL Server 2005 com o CLR.
Boa leitura e sejam bem-vindos a este novo mundo chamado Yukon.
CLR – Common Language Runtime
Para entendermos Onde, Como e de Qual Forma definitivamente a integração entre SQL Server 2005 e o CLR se concretiza, temos como principal pré-requisito saber interpretar o significado da sigla CLR e listar algumas das suas principais características.
O CLR é a base para a implementação do .Net Framework (ver Figura 1), e tem como principal atribuição a disponibilização de um ambiente de execução para os códigos .Net, provendo uma serie de benefícios: gerenciamento de memória e ciclo de vida dos objetos, tratamento de erros e exceções, gerenciamento de threads, compilação just-in-time, gerenciamento de segurança e contexto, gerenciamento de tipos de dados, e outras mais. Todo código executado sobre este ambiente é automaticamente classificado como código gerenciado ou Managed Code.
Figura 1. Microsoft .Net Framework.
A presença deste ambiente de execução dentro do SQL Server possibilita o desenvolvimento de stored procedures, triggers, user-defined functions, user-defined types e user-defined aggregates utilizando tecnologias e ferramentas .Net; herdando portanto importantes características tais como programação orientada a objetos (OOP), acesso completo ao BCL (Base Class Library) com melhorias significativas - manipulação de strings, operações matemáticas avançadas, acesso ao sistema de arquivos, criptografia e todas as outras extensas características do .Net Framework.
Um outro ponto interessante está relacionado à produtividade das equipes, que poderão usufruir de todos os benefícios característicos de uma ferramenta RAD (Rapid Application Development). Em nosso caso, o Visual Studio .Net 2005 com recursos de codificação, distribuição e depuração integrados ao SQL Server 2005.
Apesar de representar um avanço muito grande, a integração com o CLR não substitui o T-SQL, que permanece ainda como linguagem padrão e mais indicada para o acesso e/ou manipulação de dados.
Arquitetura da integração entre o SQL Server 2005 e o CLR
Neste momento é importante entendermos alguns detalhes sobre a integração do CLR com a engine do SQL Server 2005. Esta integração se baseia em uma característica chamada “CLR hosted”, onde o CLR é executado no mesmo processo do SQL Server 2005, compartilhando os mesmos recursos e evitando chamadas ou sincronizações entre diferentes processos. Com a implementação do “CLR hosted”, todas as funcionalidades do BCL do .Net Framework estão disponíveis para serem utilizadas por objetos criados com linguagens .Net e armazenados no SQL Server 2005.
Esta grande extensão de recursos através do CLR também sinaliza novas preocupações. Não seria muito complicado imaginar que em um código escrito em C#, compilado e adicionado posteriormente como um objeto no SQL Server 2005, utilize-se acidentalmente de alguns recursos do namespace System.Diagnostics (ver Nota 1) para finalizar o processo responsável por sua execução. Para qualquer outro tipo de desenvolvimento baseado em .Net, este código seria perfeitamente normal e inofensivo, sinalizando a finalização do processo após a execução das suas atividades. Porém, no contexto do SQL Server 2005, onde a instrução está sendo executada pelo CLR no mesmo nível do processo responsável pelo serviço do banco, podemos concluir que o processo a ser finalizado seria o próprio serviço do SQL Server 2005, o que não seria nem um pouco conveniente. Se essa situação de fato se concretizasse, outras preocupações seriam geradas: acesso e controle ao sistema de diretórios e arquivos do servidor ou, ainda, o acesso a blocos de memória em utilização ou reservados a outros serviços e aplicações.
Nota 1. Namespace System.Diagnostics
Pode-se considerar um namespace como uma espécie de repositório para programas e/ou rotinas. Dentro de um namespace, os programas e ou rotinas devem possuir nomes únicos a fim de evitar que ocorram conflitos. O namespace System.Diagnostics possibilita interação com o sistema operacional através de diversas classes, obtendo informações de processos (system processes), log de eventos (event logs) e contadores de performance (performance counters).
Por estas e outras ações indesejadas, vamos atentar para dois detalhes importantes:
...
