Arquitetura de armazenamento de dados com o SQL Server 2005 Compact Edition

  • Artigo

Artigos técnicos do SQL Server 2005 Compact Edition

Publicado em: 29 de março de 2007

Por Brian Noyes

IDesign, Inc.

Revisores técnicos:

Sitaram Raju, Sachin Sinha

Microsoft Corp.

Aplica-se a:

Arquitetura de armazenamento de dados do SQL Server 2005 Compact Edition

Resumo: O SQL Server 2005 Compact Edition (SSCE) oferece um mecanismo de armazenamento de dados leve mas eficiente para a criação de diversos tipos de aplicativos. Este artigo apresenta as questões relacionadas com o armazenamento de dados em aplicativos cliente e aplicativos de servidor de pequena escala. Ele discute o conjunto de recursos do SSCE e como esses recursos solucionam as questões relativas ao armazenamento de dados. São abordadas diferentes arquiteturas de aplicativos para as quais o SSCE pode ser uma boa opção, destacando os atributos dos tipos de aplicativos e como o SSCE pode atender aos requisitos de cada tipo de aplicativo. (17 páginas impressas)

Clique aqui para baixar a versão deste artigo no formato de documento do Word, DataArchSSCE.doc.

Conteúdo

Nesta página

Introdução Introdução
Desafios do armazenamento de dados Desafios do armazenamento de dados
Visão geral do armazenamento de dados Visão geral do armazenamento de dados
Aplicativos de armazenamento de dados Aplicativos de armazenamento de dados
Opções de armazenamento de dados Opções de armazenamento de dados
Visão geral do SQL Server 2005 Compact Edition Visão geral do SQL Server 2005 Compact Edition
Conclusão Conclusão
Sobre o autor Sobre o autor

Introdução

A seleção da arquitetura de armazenamento de dados correta para seus aplicativos pode se tornar uma tarefa desanimadora. O número de opções de tecnologias de armazenamento de dados é grande e cresce a cada dia. A escolha da tecnologia de armazenamento de dados depende de vários fatores. É necessário analisar as compensações entre os requisitos da plataforma, tamanho, desempenho, facilidade de implantação, facilidade de acesso aos dados e recursos de armazenamento de dados.

Para aplicativos de servidor que atendem a um grande número de usuários, a opção é clara: usar o SQL Server 2005. A edição do SQL Server 2005 baseada em servidor a ser utilizada depende da escala e do escopo de seu aplicativo, mas a lista de recursos facilita bastante a decisão de qual versão será ideal para você. Além disso, a alteração da versão consiste em uma decisão simples sobre o licenciamento e geralmente não exige uma mudança na arquitetura.

Com relação aos aplicativos do lado do cliente ou aplicativos de servidor de pequena escala, a seleção da tecnologia de armazenamento de dados representa um desafio um pouco maior. Para aplicativos cliente, não faz sentido colocar uma instância completa do SQL Server 2005 em cada computador cliente, devido a fatores como custo, complexidade, requisitos da plataforma e vários outros. Para aplicativos de servidor de pequena escala, a potência extra do SQL Server 2005 pode não ser necessária e talvez os custos de licenciamento sejam proibitivos para projetos pequenos. Para aplicativos de dispositivos móveis, não há suporte à versão completa do SQL Server na plataforma.

Este white paper discute os desafios, os cenários e as soluções da arquitetura de armazenamento de dados usando o novo SQL Server 2005 Compact Edition (SSCE). São abordadas as semelhanças e diferenças entre o SSCE, outras edições do SQL Server 2005 e outras tecnologias de banco de dados relacionais, incluindo o mecanismo de banco de dados incorporado EDB em dispositivos móveis.

Desafios do armazenamento de dados

Para aplicativos cliente ou aplicativos de servidor de pequena escala, é necessário resolver vários desafios relacionados ao armazenamento de dados:

  • Local do armazenamento de dados. Se você estiver criando um aplicativo cliente distribuído e puder armazenar os dados em um servidor back-end e recuperá-los pela rede, poderá usar o SQL Server 2005 no servidor. Se estiver criando um aplicativo cliente ou de dispositivo móvel, provavelmente precisará de um armazenamento de dados local no cliente para armazenar os dados em cache quando estiver offline. O cache no cliente também pode ser necessário para evitar a recuperação repetida de grandes conjuntos de dados, como um catálogo de produtos, na rede. Para aplicativos cliente, os dados podem ser necessários apenas localmente; nesse caso, o armazenamento em um servidor back-end não faz sentido.

  • Facilidade de acesso aos dados. A produtividade é uma etapa muito importante na colocação dos aplicativos no mercado de acordo com os cronogramas e orçamentos. Sua tecnologia de armazenamento de dados deve tornar muito fácil a leitura e gravação dos dados no local de armazenamento.

  • Facilidade de consulta. Uma tecnologia de armazenamento de dados robusta permite que você pesquise e selecione registros individuais ou coleções de registros de maneira fácil e rápida.

  • Capacidade de sincronizar armazenamentos de dados. Para aplicativos cliente móveis, os dados offline armazenados localmente devem ser sincronizados com armazenamentos de dados back-end. A criação de mecanismos de sincronização a partir do zero é uma tarefa demorada e propensa a erros. A tecnologia de armazenamento de dados deve dar suporte à sincronização de vários armazenamentos de dados.

  • Segurança. Especialmente no caso de dispositivos móveis ou computadores cliente portáteis, a segurança é muito importante em termos de proteção dos dados armazenados, de forma que, se o computador for roubado, eles não possam ser acessados por um usuário não autorizado. Além disso, ao sincronizar, os dados em trânsito devem estar protegidos.

  • Integridade dos dados. Ao ler e gravar dados em seu armazenamento, é necessário garantir que os dados sejam armazenados consistentemente e que estejam livres de danos. Isso é assegurado pelos mecanismos fornecidos por armazenamentos de dados transacionais, que devem ter prioridade em relação aos armazenamentos de dados não transacionais.

  • Facilidade de implantação. Para aplicativos cliente, um processo de fácil instalação e poucos requisitos de espaço é crítico para a capacidade de manutenção e suporte. A configuração exibida no aplicativo cliente também deve ser minimizada na ligação do aplicativo ao armazenamento de dados.

Visão geral do armazenamento de dados

Existem várias opções disponíveis para o armazenamento de dados. Pouco tempo atrás, vários aplicativos serializavam os dados em formatos proprietários, em arquivos simples no disco. O XML oferece uma forma mais estruturada e mais fácil de usar para o armazenamento de dados arbitrários em arquivos, mas não soluciona muitos dos desafios descritos na seção anterior. As tecnologias de bancos de dados relacionais são realmente a única tecnologia de armazenamento de dados amplamente disponível para atender a todos os requisitos necessários para um armazenamento de dados robusto.

Mesmo estreitando seu escopo de forma a englobar somente as tecnologias de bancos de dados, existem várias opções disponíveis. É necessário usar outros critérios para selecionar a tecnologia apropriada e selecionar a tecnologia de banco de dados correta com base na maneira como cada opção responde aos desafios discutidos na seção anterior. Além disso, você precisa considerar se o banco de dados será executado como um banco de dados cliente para um único usuário ou um banco de dados de servidor multiusuário.

Em aplicativos cliente, você deve estreitar seu escopo para uma ou duas opções, dependendo de tratar-se de um aplicativo de desktop ou de dispositivo móvel. Para aplicativos de desktop (executados em uma estação de trabalho desktop, um laptop ou um Tablet PC), inclua o SQL Server 2005 Compact Edition (SSCE) ou o SQL Server 2005 Express Edition (SSE). Para dispositivos móveis que executam os sistemas operacionais Microsoft Windows CE ou Mobile, você pode optar entre o SSCE ou o mecanismo de banco de dados incorporado EDB.

Por diversos motivos discutidos com mais detalhes posteriormente neste white paper, o SSCE fornece uma solução ótima e fácil de usar para a maioria dos aplicativos cliente comerciais. O SSE é necessário apenas para aplicativos do lado do cliente especializados, mas trata-se de uma excelente opção para aplicativos de servidor de pequena escala que dão suporte a uma carga de usuários moderada e que precisam de uma arquitetura mais robusta e escalonável. O EDB poderá ser uma boa opção se você precisar de suporte nativo no dispositivo e estiver preocupado com o impacto da instalação do SSCE no dispositivo com relação ao disco e à memória, mas for necessário pesar isso com a maior produtividade e os recursos do SSCE.

O SSCE ou o SSE podem ser adequados para aplicativos do lado do servidor de pequena escala e necessidades de cache. Para um aplicativo Web com algum potencial futuro de crescimento e dimensionamento, o SSE é uma opção melhor, pois dá suporte a uma variedade maior de recursos, em comparação com o SSCE.

Aplicativos de armazenamento de dados

Os aplicativos são fornecidos em várias formas e tamanhos. Como mencionado anteriormente, os aplicativos de servidor de grande escala precisam realmente do SQL Server 2005 Workgroup, Standard ou Enterprise Edition, não se enquadrando no escopo deste white paper. Os aplicativos cliente e aplicativos de servidor de pequena escala podem ser categorizados em vários tipos. Esses tipos incluem:

  • Aplicativos de força de campo. São os aplicativos cliente usados por usuários móveis em campo. Normalmente, eles são executados em computadores portáteis ou Tablet PCs, mas também podem ser executados em dispositivos móveis. Eles oferecem interação e apresentação interativa de dados para trabalhar com equipamento ou clientes distribuídos.

  • Aplicativos de gerenciamento de informações pessoais (PIM). São aplicativos cliente usados para armazenar e acessar coleções de itens de informação, como contatos, agendas, tarefas, anotações e assim por diante. Eles podem ser executados em desktops, computadores portáteis ou dispositivos cliente móveis, mas cada vez mais esses tipos de aplicativos são desenvolvidos para uma instalação com poucos requisitos em dispositivos móveis.

  • Aplicativos Web de pequena escala. São aplicativos cliente simples de presença na Web para a apresentação de informações dinâmicas na Web a uma pequena audiência de usuários. Alguns exemplos seriam pequenas empresas, organizações comunitárias e sem fins lucrativos ou clubes. Eles exigem a exposição de um servidor Web, mas possivelmente poderiam ser executados em um sistema operacional de desktop, como o Windows Vista ou o Windows XP Professional.

  • Aplicativos de cache. Quer um aplicativo cliente tenha sido criado para trabalhar offline ou não, geralmente não faz sentido fazer uma ida e volta completa ao banco de dados cada vez que você precisa obter informações de pesquisa, como cidade, estado, CEP, listagens de catálogos de produtos e assim por diante. A implementação de um cache de dados no cliente resulta em aprimoramentos significativos no desempenho de apresentações de listas ou da pesquisa em tabelas com alterações pouco freqüentes. Além disso, alguns aplicativos podem ser criados com uma arquitetura distribuída, envolvendo aplicativos smart client, de dispositivos móveis ou cliente Web que se comunicam com um servidor de aplicativos back-end centralizado. Talvez o servidor de aplicativos precise armazenar os dados localmente para evitar idas e voltas ao servidor do banco de dados. A necessidade de armazenar os dados em cache na máquina local não garante a compra ou a sobrecarga de instalar uma instância completa do SQL Server localmente no servidor de aplicativos.

Opções de armazenamento de dados

Para tomar decisões acertadas sobre a arquitetura, aborde a solução objetivamente, após compreender claramente as opções disponíveis. Com relação às necessidades de armazenamento de dados da sua arquitetura, existem várias opções que devem ser examinadas. Novamente, este artigo aborda o armazenamento de dados do lado do cliente e em servidores de pequena escala. Para essas partes da arquitetura, suas principais opções são o armazenamento de arquivos, EDB, SSCE e SSE. Para fazer a escolha certa, analise os recursos e limitações de cada opção, pesando-os de acordo com seus requisitos.

Arquivos simples ou XML

O uso de arquivos simples ou XML pode parecer atraente na superficialidade do ponto de vista de sua simplicidade: a maioria dos desenvolvedores já sabe como usar a serialização do XML ou o Microsoft .NET para ler e gravar dados em arquivos, ou usar os recursos de um conjunto de dados para sua leitura e gravação como XML a partir de um arquivo. Entretanto, os arquivos apresentam problemas em termos de consistência e confiabilidade. Se um aplicativo for interrompido ou desligado sem concluir corretamente as operações de E/S e fechar o arquivo, os dados contidos poderão ser danificados e o bloqueio do arquivo pode impedir que o aplicativo se comporte corretamente. Esses problemas podem ser resolvidos por meio de manipulação de erros e codificação disciplinadas, mas essa solução descarta a simplicidade inicial que tornou os arquivos simples atraentes.

Além disso, não existe uma capacidade inerente de consulta de arquivos e, em geral, é necessário ler o arquivo inteiro ou grande parte dele nas estruturas de dados da memória para poder utilizar os dados. Como resultado, os arquivos simples e XML não são apropriados para dados que serão consultados, lidos e gravados durante toda a execução do aplicativo. Para dados simples, como preferências e definições de configuração, os arquivos de configuração XML são adequados. Também pode ser preferível armazenar documentos e arquivos grandes como arquivos simples com metadados no banco de dados, dependendo dos padrões de acesso. Mas a maioria dos dados de leitura/gravação de acesso aleatório para os aplicativos deve ser armazenada e acessada através de um mecanismo de banco de dados.

EDB

O mecanismo de banco de dados incorporado EDB é uma parte nativa dos sistemas operacionais Windows CE 5.x, 6.x e Mobile 6.x. O EDB é um mecanismo de dados relacionais simples que permite que você armazene dados tabulares com um sistema de tipos e recursos de consulta limitados. O EDB é uma opção atraente quando se deseja um recurso nativo no dispositivo ou que possa ser instalado com sobrecarga e requisitos mínimos no dispositivo. O EDB pode ser mais rápido que o SSCE para determinados tipos de recuperação de dados simples, mas também poderá ser mais lento, se forem necessárias operações de consulta complexas. Uma das maiores desvantagens de usar o EDB é que você terá acesso a ele somente usando uma API de nível inferior no Microsoft Visual C++. Se o aplicativo for criado usando o .NET Compact Framework de forma a obter os benefícios de produtividade associados com o desenvolvimento de código gerenciado, crie um componente de acesso a dados separado que funcione com o banco de dados EDB usando o C++ e, então, será necessário interoperar com esse componente a partir de seu código gerenciado. Provavelmente, a complexidade envolvida nesse processo sobrepuja os benefícios do uso do EDB. O EDB deverá ser considerado somente se o aplicativo já estiver sendo criado com o C++ incorporado e você estiver empenhado em minimizar os requisitos e maximizar o desempenho do aplicativo.

SQL Server 2005 Compact Edition (SSCE)

O SSCE é um mecanismo de banco de dados relacionais leve (< 2 MB) e gratuito que pode ser instalado em qualquer sistema operacional Windows atual. Como o SSCE é o principal foco deste white paper, seu conjunto de recursos completo é descrito em uma seção posterior. Em um nível superior, o SSCE dá suporte a tabelas, relações, restrições, processamento de consultas complexas, transações, replicação e segurança de dados. Para fazer uma programação com o SSCE, é usado um provedor gerenciado pelo ADO.NET com padrões de codificação de acesso a dados semelhantes aos usados com outros provedores gerenciados, como o do SQL Server SQLClient. Também é possível acessar o SSCE de clientes não gerenciados usando o OLE DB. O SSCE é executado em processo como um conjunto de bibliotecas referenciadas pelo aplicativo em uso, sendo fácil de implantar com as bibliotecas de aplicativos ou como uma instalação com MSI separada. O SSCE pode ser implantado facilmente com aplicativos ClickOnce ou, em dispositivos móveis, pelo Xcopy. Ele também será instalado nativamente no Windows Mobile 6.0 ou posterior.

O sistema de tipos do SSCE é um subconjunto do sistema de tipos do SQL Server 2005 e não dá suporte aos mesmos recursos que uma instância completa do SQL Server. Os recursos comumente usados pelo SQL Server para aplicativos de servidor que não estão presentes no SSCE incluem procedimentos armazenados, disparadores, exibições, funções, tipos de dados definidos pelo usuário e a capacidade de participar de mensagens do SQL Server Service Broker.

SQL Server 2005 Express Edition (SSE)

O SSE é um serviço de mecanismo de banco de dados gratuito com requisitos bastante reduzidos (< 55 MB) que pode ser instalado em qualquer sistema operacional de desktop ou servidor Windows atual. Como o SSE é executado como um Serviço do Windows, ele exige uma instalação com Windows Installer (MSI) na máquina de destino. O SSE pode ser implantado por meio do ClickOnce Bootstrapper para possibilitar seu uso por aplicativos implantados pelo ClickOnce. Ele dá suporte ao isolamento de instâncias do usuário, o que facilita a implantação do ClickOnce, assegurando que os dados de um usuário sejam automaticamente protegidos dos dados de outros usuários.

O SSE dá suporte à maioria dos recursos de uma instância completa do SQL Server, incluindo tabelas, exibições, procedimentos armazenados, disparadores, funções e SQL CLR. Os dados são acessados em uma instância do SSE a partir do código gerenciado, da mesma forma que em uma instância completa do SQL Server, usando o provedor gerenciado do SQLClient. Você também pode acessá-lo de aplicativos não gerenciados, usando um provedor do OLE DB.

As limitações do SSE, em comparação com uma instância completa do SQL Server, são bastante fáceis de entender. O SSE usa somente um processador no computador, mesmo que existam outros presentes; apenas 1 GB de memória é usado e os bancos de dados podem crescer somente até 4 GB. Além disso, o SSE pode ser um Subscriber (Assinante), mas não um Publisher (Editor) em todos os tipos de replicação, podendo enviar e receber mensagens do SQL Server Service Broker, desde que elas passem por uma instância completa do SQL Server (ou seja, sem mensagens ponto a ponto entre instâncias do SSE sem uma instância completa na cadeia).

Visão geral do SQL Server 2005 Compact Edition

Em um nível conceitual, é possível pensar no SSCE como uma versão significativamente diminuída do mecanismo de banco de dados do SQL Server 2005. Entretanto, trata-se de um mecanismo de banco de dados separado criado de forma a maximizar os principais recursos necessários para um armazenamento de dados relacionais transacionais simples e seguro, que minimiza os requisitos de disco, memória e instalação do aplicativo host.

Histórico do SSCE

A herança do SSCE leva ao SQL Server CE 1.0, que foi lançado em 2001. Esse foi o primeiro mecanismo de dados relacionais lançado pela Microsoft para sistemas operacionais de dispositivos móveis, baseado nos recursos de banco de dados do SQL Server 2000. Seguiram-se as versões 1.1 e 2.0, que aprimoravam a experiência do usuário, sendo que a 2.0 fornecia integração com aplicativos do .NET Compact Framework. Juntamente com o .NET 2.0 e o SQL Server 2005, o SQL Server 2005 Mobile Edition foi lançado como o mecanismo de banco de dados móvel da próxima geração. O SQL Server 2005 Mobile Edition oferecia vários novos recursos, incluindo confiabilidade e desempenho aprimorados, melhores opções de sincronização e mais integração com o SQL Server 2005 e o Microsoft Visual Studio 2005.

Quando o SSCE foi anunciado pela primeira vez no TechEd 2006, o novo nome dessa versão foi anunciado como SQL Server 2005 Everywhere Edition. Esse nome existiu apenas por um breve período, entre sua primeira divulgação e o momento em que a Microsoft refinou seus planos e lançou os recursos do SSCE, anunciando-os e o novo nome no TechEd Europe 2006, em novembro de 2006. Assim, é possível encontrar material que permanecerá por algum tempo na Web com o nome de SQL Server 2005 Everywhere Edition ou, abreviadamente, SQL Everywhere; ambos são sinônimos de SSCE. É importante observar que o SSCE consiste em um mecanismo de dados completamente diferente e significativamente mais capacitado que as edições anteriores do SQL Server CE; assim, é necessário diferenciá-los cuidadosamente.

Principais recursos do SSCE

A principal função do SSCE é permitir o armazenamento e o acesso seguros a dados relacionais transacionais. Você pode executar consultas SQL que incluem consultas DDL (Data Definition Language) e DML (Data Manipulation Language) através do mecanismo do SSCE. Com o SSCE, a instância do banco de dados é criada como um único arquivo.sdf. Nesse banco de dados, você pode definir tabelas com chaves primárias e restrições. O SSCE dá suporte à integridade referencial completa por meio de restrições de chaves estrangeiras, exclusões e atualizações em cascata.

Além disso, o SSCE dá suporte aos seguintes recursos:

  • Várias conexões simultâneas para acesso a dados multithread.

  • Proteção por senha e criptografia de 12 bits do arquivo de dados .sdf do SSCE.

  • Uma grande variedade de tipos de dados de coluna.

  • Cursores atualizáveis e roláveis para um acesso rápido e fácil aos dados conectados.

  • Bancos de dados que podem crescer até 4 GB.

  • Sincronização com o SQL Server por meio de replicação de mesclagem e RDA (Remote Data Access).

Novos recursos do SSCE

Na verdade, todos os principais recursos do SSCE faziam parte do SQL Server 2005 Mobile Edition, que foi lançado com o SQL Server 2005 e o .NET 2.0 em outubro de 2005. O SSCE possui vários recursos periféricos adicionais que o distinguem do Mobile Edition:

  • Agora, o SSCE pode ser executado em qualquer sistema operacional Windows com suporte, incluindo dispositivos móveis, Tablet PCs, computadores portáteis, desktops e servidores.

  • O SSCE pode ser atualizado com o Microsoft Update, o Systems Management Server ou o Microsoft Windows Server Update Services.

  • O SSCE pode ser implantado usando o ClickOnce.

Sincronização de dados com o SSCE

Quando o SSCE é usado como cache de dados local para um aplicativo cliente ou de camada intermediária em uma arquitetura de aplicativos distribuída, geralmente é necessário sincronizar o banco de dados do SSCE com um servidor de banco de dados back-end. Talvez seja necessário preencher as tabelas do banco de dados do SSCE inicialmente a partir de um banco de dados back-end, além de enviar registros novos ou atualizados por push do cliente para o banco de dados do servidor.

Com o SSCE, você possui várias opções de sincronização. Existem duas opções de sincronização interna: a replicação de mesclagem e o RDA. Os dois recursos permitem que você sincronize dados nas duas direções: de um banco de dados do SSCE para um SQL Server 2005 ou um banco de dados SQL Server 2000 por HTTP. Além desses recursos, você poderia implementar uma solução de sincronização personalizada fazendo chamadas para os próprios pontos de extremidade do serviço Web exposto, permitindo passar os dados por meio de camadas lógicas comerciais personalizadas nas duas direções do lado do servidor. Além disso, em breve, com a próxima versão do Visual Studio (intitulado Orcas), haverá um novo subsistema de sincronização chamado estrutura de sincronização OCS (Occasionally Connected Systems).

A replicação de mesclagem é a opção de sincronização interna mais eficiente, pois permite a atualização autônoma e independente de registros nos bancos de dados do cliente (SSCE) e do servidor (SQL Server) ao mesmo tempo. O SSCE participa da replicação de mesclagem como um assinante, podendo inscrever-se em publicações de replicação de mesclagem expostas do SQL Server 2000 ou do SQL Server 2005. A replicação de mesclagem trata vários clientes com facilidade, porque também dá suporte à detecção e resolução de conflitos no lado do servidor. A configuração da replicação de mesclagem é um pouco mais complicada e exige recursos específicos de design de banco de dados, além da configuração no lado do servidor.

O RDA é a opção de sincronização interna mais fácil de ser usada. Com o RDA, não há requisitos específicos no banco de dados do lado do servidor. Para sincronizar dados com o RDA, você recebe um conjunto de resultados inteiro no banco de dados do SSCE do lado do servidor para inicializar uma tabela com os dados atuais do servidor. Em seguida, é possível enviar as alterações por push (inserções, atualizações e exclusões) de volta ao servidor no momento escolhido para a sincronização. Para obter as alterações que foram feitas do lado do servidor desde que os dados foram recebidos inicialmente, é necessário receber o mesmo conjunto de resultados novamente (após enviar as alterações por push de forma que os dados recebidos contenham as alterações). O RDA não possui nenhuma detecção ou resolução de conflitos de simultaneidade. Assim, se for usado com um aplicativo no qual vários clientes podem modificar diferentes registros ao mesmo tempo, o último cliente a gravar alterações em um registro poderia substituir as alterações recentes de outro cliente (last-in-wins).

Quando lançada, a estrutura de sincronização OCS permitirá que você escolha entre os recursos de sincronização de um banco de dados a outro semelhantes ao RDA e à replicação de mesclagem ou uma abordagem mais orientada por serviços na qual você conecta os pontos de extremidade do seu serviço ao pipeline de sincronização. A primeira abordagem é mais simples de configurar, pois exige menos código personalizado. A segunda é um pouco mais complexa, mas permite que você insira lógica comercial entre o cliente e o servidor, além de também poder direcionar outras fontes de dados que poderiam ser dispostas em um serviço de sincronização apropriado. A Figura 1 mostra a arquitetura da nova estrutura de sincronização OCS.

Figura 1. Estrutura de sincronização OCS

 

A estrutura OCS oferece uma solução pronta para sincronização de dados orientada por serviços, além de vários pontos de extensibilidade de forma a permitir um controle mais explícito do processo de sincronização. O cliente faz a chamada por meio de um provedor de sincronização para executar a sincronização dos dados. O provedor pode chamar uma lógica personalizada, como a lógica de validação, se necessário. Em seguida, o provedor de sincronização faz a chamada, por meio de um agente de sincronização, para o serviço de sincronização no servidor. O serviço exposto pode ser fornecido com a estrutura ou um serviço personalizado exposto por você. O serviço faz a chamada por meio de um provedor de sincronização do lado receptor, que também pode chamar a lógica personalizada. A sincronização é expedida através de um adaptador de sincronização apropriado e seus comandos de banco de dados associados. Os adaptadores e comandos seguem uma arquitetura semelhante à dos TableAdapters associados com os conjuntos de dados tipados do ADO.NET 2.0.

Simultaneidade no SSCE

O SSCE permite várias conexões do mesmo aplicativo ou até de vários aplicativos no mesmo computador com um único banco de dados (arquivo .sdf). Isso possibilita uma maior liberdade para estruturar seu aplicativo conforme o necessário, permitindo, por exemplo, que o usuário continue interagindo com os dados enquanto executa a sincronização com um banco de dados back-end ou que haja vários aplicativos na mesma máquina compartilhando um armazenamento de dados do SSCE. O mecanismo de banco de dados faz bloqueios de simultaneidade transacional para evitar que conexões simultâneas acessem os mesmos registros ao mesmo tempo. O limite técnico para conexões simultâneas em um único banco de dados é 256, mas 70-80 é um limite prático melhor do ponto de vista do desempenho.

Segurança do SSCE

Não há suporte para permissões e segurança baseada em funções no SSCE. Os bancos de dados do SSCE destinam-se ao uso com um mecanismo de armazenamento de dados simples para o armazenamento de dados local e o acesso em um computador cliente, ou para cache de dados persistentes simples em um servidor de aplicativos. Como resultado, as permissões e a segurança baseada em funções no nível de tabela não foram incluídas com o intuito de manter o mecanismo do banco de dados tão pequeno e rápido quanto possível. O controle de acesso ao banco de dados como um todo pode ser aplicado através do acesso protegido por senha. A proteção dos dados enquanto armazenados em disco pode ser feita facilmente criptografando o banco de dados.

Acesso de código não gerenciado do SSCE

O SSCE também permite que você acesse facilmente o armazenamento de dados de aplicativos não gerenciados. O SSCE inclui um provedor OLE DB, de forma que os aplicativos que usam o Microsoft Access, o Microsoft Visual Basic 6, o C++ ou outra formas de código não gerenciado ainda podem acessar e usar dados que foram colocados em um banco de dados do SSCE. Isso pode ajudar na migração de aplicativos não gerenciados e armazenamentos de dados herdados, de maneira a avançar de forma incremental para o SSCE e o código gerenciado, por exemplo.

Desempenho do SSCE

O desempenho do SSCE é muito bom para todos os cenários de utilização descritos neste documento. Se você comparar o desempenho do SSCE com o do SSE, EDB ou Microsoft Access, não haverá um vencedor claro em todos os cenários. Para cada combinação de tamanho de consulta, padrão de armazenamento e outras variáveis, o desempenho de um produto pode parecer melhor que o de outro, mas é possível medir consistentemente algumas tendências.

Se você fizer uma comparação entre o SSCE e o SSE, aparecerão vários padrões nos testes de desempenho. O início e a confirmação das transações são pouco mais rápidos no SSCE que no SSE, mas apenas por uma fração de uma porcentagem (20 %). O SSCE é mais rápido que o SSE em consultas parametrizadas que inserem muitas linhas (> 100), mas o SSE é mais rápido na inserção de uma linha ou de poucas linhas. O SSCE é aproximadamente duas vezes mais lento que o SSE na seleção de uma única linha, sendo comparável para 100 linhas ou mais, com o modelo conectado de SqlCeResultSet. Contudo, com a API SqlCeConnection, a primeira abertura e o último fechamento são significativamente mais lentos no SSCE que no SSE (> 1000 vezes, em alguns casos), devido à expressiva sobrecarga de iniciar e desligar o mecanismo de armazenamento. Uma otimização para um melhor desempenho é abrir uma SqlCeConnection antes das transações e fechá-la bem no final. Nesse caso, o desempenho será comparável ao da API SqlCeResultSet.

Se você comparar o desempenho do SSCE com o EDB em um dispositivo, o EDB pode ser significativamente mais rápido (100 % ou mais) em determinados cenários, como na determinação do tamanho do banco de dados e ao fazer inserções e atualizações. Entretanto, a maioria das operações de pesquisa e consulta favorece o SSCE em 20-30 % ou é aproximadamente equivalente em termos de desempenho.

Arquitetando soluções com o SSCE

Para entender como integrar o SSCE em sua arquitetura de aplicativos, é melhor discutir seu uso no contexto dos quatro tipos de aplicativos resumidos anteriormente neste white paper: aplicativos de força de campo, aplicativos de gerenciamento de informações pessoais (PIM), aplicativos cliente Web de pequena escala e cache de servidor de aplicativos.

Aplicativos de força de campo

Normalmente, os aplicativos de força de campo (FFAs) são aplicativos cliente criados para serem executados em um dispositivo móvel, Tablet PC ou computador portátil como parte de um sistema distribuído maior que consiste em várias camadas, serviços bancos de dados, e outros elementos de arquitetura. Geralmente, os FFAs compartilham um ou mais dos seguintes atributos:

  • Eles permitem que o usuário execute suas funções de trabalho desconectado da rede back-end, em um local do cliente, em viagem, em um aeroporto ou em casa. Geralmente os FFAs são criados para conectividade ocasional, o que significa que quando os usuários executam o aplicativo cliente, não precisam de uma conexão de rede de qualquer tipo.

  • Freqüentemente os FFAs envolvem vários clientes que podem acessar e usar dados simultaneamente do banco de dados back-end, em modo conectado ou desconectado.

  • Para o suporte offline, é necessário que os FFAs possam replicar dados do banco de dados back-end nos bancos de dados do cliente. Eles também precisam conseguir replicar registros de dados modificados, adicionados ou excluídos do cliente para o servidor quando o aplicativo puder se conectar à rede.

  • Os FFAs devem ser implantáveis pelo ClickOnce, permitindo atualizações freqüentes da funcionalidade e do banco de dados usado para armazenamento local.

Exemplos de FFAs incluem:

  • Aplicativos de vendas de ponto de contato (POC) para os segmentos de varejo, seguros, imóveis, gerenciamento financeiro e muitos outros.

  • Aplicativos de gerenciamento de recursos do cliente (CRM) com alcance estendido para equipes distribuídas por meio de dispositivos móveis, computadores portáteis e Tablet PCs.

  • Aplicativos de provedores da área de saúde que fornecem acesso ao histórico médico, manutenção de registros da interação provedor-paciente, pedidos de prescrição de medicamentos, testes laboratoriais e diagnósticos, e coleta de dados de dispositivos de medição.

  • Aplicativos de gerenciamento de inventário para armazéns, departamentos de remessa, serviços de gerenciamento de escritórios comerciais, suprimentos de manutenção e outros aplicativos que envolvem o registro e o controle de contagem de itens, disponíveis em campo.

  • Aplicativos de medição e coleta de dados, como aplicativos para empresas de utilitários, telecomunicações, pesquisas, censos e votações.

As arquiteturas das soluções FFA podem variar bastante, dependendo do número e do tipo de plataformas cliente e da escala do aplicativo. Uma arquitetura típica está descrita na Figura 2. Geralmente, os FFAs consistem em vários clientes, envolvendo plataformas PDA/Telefone, Tablet PCs, computadores pessoais ou uma mistura delas. Geralmente, se conectam aos serviços back-end por meio conexões seguras de serviços Web ou de redes virtuais privadas (VPNs), de forma que possam sincronizar os dados back-end de qualquer conexão com a Internet disponível, em vez de precisar retornar à rede doméstica. Freqüentemente, o front-end exposto a eles é colocado em uma rede de perímetro (também conhecida como DMZ, zona desmilitarizada e sub-rede filtrada) de forma a limitar o número e o tipo de portas abertas a partir dele, e as conexões na rede back-end são limitadas. Para aplicativos de maior escala, o servidor Web da rede de perímetro pode estar conectado a um servidor de aplicativos no qual são executados os componentes de lógica comercial e acesso a dados, e esse servidor de aplicativos se comunica diretamente com o banco de dados back-end.

Figura 2. Arquitetura de aplicativos de força de campo

 

Para fins de sincronização de dados, freqüentemente é adotada uma rota mais direta para limitar a complexidade do aplicativo. Ao usar o RDA ou a replicação de mesclagem, a arquitetura de sincronização tem uma aparência mais semelhante à da Figura 3. Nesse caso, os aplicativos cliente se conectam por HTTP ao banco de dados back-end, com o Internet Information Services (IIS) expondo o ponto de extremidade HTTP por meio do qual são feitas as comunicações de sincronização.

Figura 3. Arquitetura de sincronização de força de campo

 

Para executar o acesso a dados no lado do servidor, podem ser usadas abordagens normais de acesso a dados desconectado do ADO.NET, como na utilização de conjuntos de dados tipados e seus adaptadores de tabela associados para ler e gravar dados de um armazenamento de dados local do Northwind do SSCE, conforme mostrado exemplo de código a seguir. Como se pode ver, o conjunto de dados tipado abstrai todos os detalhes do armazenamento subjacente e esse código de consumidor de dados não é diferente do que seria se os dados estivessem no SQL Server, no SSE ou em outro armazenamento de dados acessado através de um provedor do ADO.NET gerenciado para o qual houvesse suporte. No CustomersTableAdapter, os objetos SqlCeConnection e SqlCeCommand são definidos pelo designer do Visual Studio e fazem todo o trabalho de recuperação e atualização dos dados no banco de dados do SSCE usando padrões normais de acesso a dados do ADO.NET.

Exemplo de código: Acesso a dados de leitura/gravação com conjuntos de dados tipados

private NorthwindDataSet LoadDataSet()
{
    NorthwindDataSet nwData = new NorthwindDataSet();
    CustomersTableAdapter adapter = new CustomersTableAdapter();
    adapter.Fill(nwData.Customers);
    return nwData;
}

private void SaveChanges(NorthwindDataSet nwData)
{
    CustomersTableAdapter adapter = new CustomersTableAdapter();
    adapter.Update(nwData);
}

O SqlCeResultSet também permite um modelo de acesso a dados conectado, como mostrado no próximo exemplo de código. Neste método, é criada uma SqlCeConnection juntamente com um SqlCeCommand para recuperar uma linha de dados (apesar de ele também funcionar com conjuntos de resultados com várias linhas). Em seguida, abrimos a conexão, executamos o comando para recuperar o SqlCeResultSet e atualizamos o registro de dados utilizando-o. Neste exemplo simples, a conexão é fechada através do bloco using, mas normalmente você usaria um SqlCeResultSet, se fosse mantê-lo cobrindo um escopo mais longo de código e desejasse poder ler e gravar no banco de dados sem precisar abrir e fechar a conexão. Nesse caso, você não fecharia a conexão imediatamente após usar o conjunto de resultados; a deixaria aberta e fecharia o SqlCeResultSet quando tivesse terminado de usá-lo.

Exemplo de código: Acesso a dados de leitura/gravação com o SqlCeResultSet

private void UpdateCompanyName(string custId, string companyName)
{
    // Set up connection, just need path to sdf file 
    SqlCeConnection conn = 
        new SqlCeConnection(
           @"Data Source ='.\Northwind.sdf'");
    
    // Set up select query that brings rows into the result set
    string selQuery = 
       "SELECT * FROM Customers WHERE [Customer ID] = @CustID";
    SqlCeCommand getCustCmd = new SqlCeCommand(selQuery, conn);
    getCustCmd.Parameters.Add("@CustID", custId);

    using (conn)
    {
        conn.Open();
        // Pull the row into the result set, 
        // using options to allow connected, random, read-write access
        SqlCeResultSet resultSet = 
            getCustCmd.ExecuteResultSet(
               ResultSetOptions.Scrollable | 
               ResultSetOptions.Updatable);
        // Move to first record
        if (resultSet.ReadFirst())
        {
            // Get the column position
            int ordinal = resultSet.GetOrdinal("Company Name");
            // Set the value
            resultSet.SetString(ordinal, companyName);
            // persist
            resultSet.Update();
        }
        else // No match
        {
            throw new ArgumentException("Customer not found");
        }
    }
}

Aplicativos de gerenciamento de informações pessoais

Os aplicativos PIM são aplicativos de dados simples executados em armazenamentos de dados locais em plataformas móveis para um fácil acesso e armazenamento de informações pessoais. Geralmente, os aplicativos PIM compartilham um ou mais dos seguintes atributos:

  • São executados em plataformas móveis, incluindo telefones, PDAs, Tablet PCs e computadores pessoais.

  • Fornecem pesquisa e entrada de dados simples em armazenamentos de dados locais para dados de aplicativos.

  • Exigem requisitos mínimos para disponibilidade em dispositivos móveis.

Exemplos de aplicativos PIM incluem:

  • Entrada, armazenamento e recuperação de anotações, tarefas, contatos, mensagens instantâneas e email.

  • Leitor de notícias, agregação RSS.

  • Contagem de calorias, gerenciamento de tempo, registro de exercícios.

  • Tutor de idiomas, treinador de vocabulário, dicionário, dicionário de sinônimos.

  • Lista de compras, coleção de CDs/DVDs.

A arquitetura da solução de aplicativos PIM é bastante simples, como mostrado na Figura 4. Ela segue um design cliente-servidor clássico, no qual o servidor é um mecanismo de banco de dados local no dispositivo ou computador portátil. O EDB poderia ser usado para dispositivos móveis, mas o SSCE representa uma opção simples de usar, eficiente e leve para qualquer plataforma Windows, incluindo os dispositivos móveis. Por exemplo, o SSCE oferece um suporte a consultas melhor que o do EDB, sendo mais fácil desenvolver aplicativos usando o SSCE em código gerenciado.

Figura 4. Arquitetura de aplicativos PIM

 

Provavelmente, um aplicativo PIM que usa o SSCE como mecanismo de banco de dados usará a API SqlCeResultSet para tornar a recuperação e o armazenamento de dados mais simples possível. O código para isso teria uma aparência muito semelhante ao segundo exemplo de código na seção anterior.

Aplicativos Web de pequena escala

Para sites simples com baixas expectativas de tráfego, não há necessidade de comprar softwares de servidor caros ou pagar por opções de hospedagem com custo alto que envolvem uma instância de banco de dados apenas para ter um site dinâmico controlado por dados. O SSCE e o SSE fornecem uma opção simples e gratuita para o armazenamento de dados dinâmicos, que pode ser usada para processar conteúdo em páginas da Web. Quer o site use o ASP.NET ou alguma outra tecnologia da Web capaz de acessar os dados por meio de um provedor OLE DB, os dados que alimentam as páginas do site podem ser atendidas pelo SSCE ou pelo SSE.

Os aplicativos Web adequados para o SSCE ou o SSE são aqueles que possuem uma pequena base de usuários; o número total de usuários pode ser grande, mas o número de solicitações simultâneas por segundo deve ser bem pequeno.

Exemplos de aplicativos Web que podem ser candidatos para o SSE ou o SSCE incluem:

  • Sites de entusiastas/clubes com uma pequena base de membros.

  • Organizações de pequenos grupos de usuários.

  • Aplicativos Web internos para pequenas empresas

A menos que a utilização esperada do aplicativo Web seja extremamente baixa, com pequeno potencial de crescimento para mais usuários, geralmente o SSE é uma opção melhor que o SSCE para aplicativos Web de pequena escala. Se o aplicativo permanecer como um aplicativo Web de processo único com um número muito baixo de solicitações por hora (< 300-500 solicitações por hora, por exemplo), o SSCE ou o SSE devem conseguir tratar a taxa de transferência exigida.

Contudo, conforme cresce a complexidade do aplicativo e/ou aumenta o número de solicitações por segundo, o SSE oferece opções melhores para dimensionar o aplicativo incrementalmente de forma a atender à demanda aumentada. Conforme descrito anteriormente neste artigo, o SSE dá suporte a procedimentos armazenados, funções e outros recursos em nível empresarial que podem fornecer uma arquitetura mais sobreposta e dissociada para aplicativos complexos. Além disso, devido ao SSE ser executado como um serviço, o acesso simultâneo de vários processos de aplicativos Web tem um suporte melhor no mesmo ou até em computadores diferentes. Há mais opções para segurança baseada em funções no SSE, e o caminho de atualização para uma versão completa do SQL Server é direto; não devem ser necessárias alterações no código de acesso a dados, pois o SSE e o SQL Server usam o mesmo provedor de dados. Além disso, os formatos de arquivo do SSE e do SQL Server são iguais, de forma que o banco da dados do SSE pode ser simplesmente anexado a uma instância completa do SQL Server e estará pronto. A mudança do SSCE para o SSE ou para uma versão completa do SQL Server exige uma migração de dados, além da recodificação de parte da lógica de dados, pois o SSCE usa um provedor de dados diferente do SSE ou do SQL Server.

Se você optar por usar o SSCE para aplicativos Web, precisará configurá-lo para permitir que seja hospedado no processo do aplicativo Web.

Aplicativos de cache

Os aplicativos de cache podem estar no lado do cliente ou podem ser aplicativos do servidor de aplicativos que precisam manter um cache de dados local de valores de pesquisa ou de dados que são alterados raramente para evitar idas e voltas desnecessárias ao banco de dados back-end. O cache é usado para permitir que o aplicativo recupere os dados necessários do computador local para aprimorar o desempenho e reduzir o tráfego de rede. Exemplos de uso de aplicativos de cache incluem o acesso freqüente a listas de registros de dados relativamente estáticos usados para fins de apresentação (seleção suspensa ou listas de referência) ou em pesquisas em servidores de aplicativos na lógica comercial.

Para uma recuperação de dados mais rápida, os dados podem ser armazenados em cache na memória e retornados diretamente quando os valores do cache forem necessários. Contudo, você pode não desejar ou conseguir atualizar o cache do servidor sempre que o aplicativo for reiniciado, talvez seja necessário um armazenamento de dados local para os valores do cache. Além disso, se as listas de valores armazenados em cache forem muito grandes, como um catálogo de produtos, talvez você não queira manter todo o catálogo na memória do aplicativo, pois os itens da coleção são acessados esporadicamente. Por qualquer desses motivos, o uso do SSCE como um local de armazenamento em cache de dados locais pode ser uma boa opção para sua arquitetura.

Os dados em cache precisam ser inicializados do servidor na primeira vez em que o aplicativo é executado e, freqüentemente, possuem uma data ou hora de vencimento associadas a ele quando é necessário atualizar o cache a partir da origem. O tempo limite associado com o cache é determinado pelos requisitos do aplicativo, pela freqüência de alteração dos dados e pela latência nos dados em cache que o aplicativo e os usuários podem tolerar.

Ao criar um cache de dados em um aplicativo, é necessário escolher entre uma estratégia de cache de dados passiva ou ativa. Com o cache passivo, o aplicativo tenta obter os dados necessários do cache de dados local. Se os dados não estiverem presentes, a lógica do aplicativo recuperará os dados do servidor e armazenará os resultados no cache para recuperações subseqüentes. Quando o cache se torna inválido devido a um limite de tempo ou outros critérios, o aplicativo deve atualizá-lo a partir da origem. O cache ativo é mantido atualizado ativamente com base em alguns critérios, como uma atualização programada a partir do servidor. Ao usar uma estratégia de cache ativa, o código do aplicativo é mais simples, pois ele sempre pode se referir simplesmente ao cache local para obter seus dados. Entretanto, é necessário um código adicional para inicializar o cache ativo e mantê-lo atualizado.

Para um aplicativo de cache, talvez você deseje fazer um cache em dois níveis. Você pode armazenar os dados em cache em um armazenamento persistente, como o SSCE, para permitir que o cache fique residente na máquina local de forma a sobreviver aos reinícios do aplicativo ou a evitar precisar carregar todos os dados do cache na memória. Todavia, você também pode armazenar em cache alguns dos dados do cache persistente na memória para fornecer o tempo de recuperação mais rápido possível quando os dados forem necessários (por exemplo, para direcionar a lógica de autocompletar nos controles de entrada de listas suspensas ou caixas de texto). Para esses dois níveis de cache, você poderia ter estratégias de cache iguais ou diferentes (ativa ou passiva).

A Figura 5 mostra uma arquitetura de aplicativos de cache de exemplo, com caches no aplicativo cliente e no servidor de aplicativos da camada intermediária. O aplicativo cliente armazena os dados em cache no armazenamento persistente do SSCE e na memória, porque geralmente o consumo de memória não é uma preocupação em um aplicativo cliente. O cache do servidor de aplicativos armazena grandes listas de pesquisa, como um catálogo de produtos, persistentemente, a fim de evitar o consumo de memória por motivos de escalabilidade, mas evita o impacto sobre o desempenho pelas idas e voltas ao banco de dados sempre que uma pesquisa do catálogo de produtos for necessária, por exemplo, na localização de todos os produtos em um determinado intervalo de preços. A principal diferença entre um aplicativo de cache e outro que faz a sincronização (como um aplicativo de força de campo) é que os dados são puxados do servidor para o cache de dados locais somente em um aplicativo de cache. Com a sincronização, os dados do cache também são sincronizados com o banco de dados back-end depois de feitas as edições.

Figura 5. Arquitetura de aplicativos de cache

 

Conclusão

Vários aplicativos precisam de um armazenamento de dados confiável, transacional, persistente e eficiente, mas não exigem, necessariamente, toda a variedade de recursos oferecidos pelo SQL Server 2005. O SSCE oferece um mecanismo de banco de dados gratuito eficiente e fácil de usar que pode ser usado em vários cenários e arquiteturas de aplicativos. Ele pode ser usado para aplicativos de força de campo, aplicativos de gerenciamento de informações pessoais, pequenos aplicativos Web ou cache de dados de aplicativos. São fornecidas várias opções de sincronização de dados atuais e emergentes que permitem que ele seja parte de uma arquitetura de aplicativos distribuída maior, envolvendo bancos de dados SQL Server 2005 back-end. O SSCE deve ser uma das tecnologias de banco de dados consideradas para qualquer aplicativo que precise de um armazenamento de dados relacional leve.

Sobre o autor

Brian Noyes é chefe de arquitetura na IDesign (http://www.idesign.net/), uma empresa de consultoria e treinamento em arquitetura e design de .NET. Ele é diretor regional da Microsoft e Microsoft Most Valuable Professional (MVP), sendo um escritor e palestrante conhecido internacionalmente. Seu livro mais recente, Implantação do Smart Client com o ClickOnce, parte da série Desenvolvimento no .NET de Addison Wesley, foi lançado em dezembro de 2006. Seu livro anterior, Ligação de dados com o Windows Forms 2.0, continua na lista de mais vendidos. Você pode entrar em contato com ele pelo email brian.noyes@idesign.net ou por seu blog em http://www.softinsight.com/bnoyes.

Para obter mais informações:

https://www.microsoft.com/sql/editions/compact/default.mspx

 

© 2007 Microsoft Corporation. Todos os direitos reservados. Termos de uso.