Compartilhar via

Como implantar o Sync Framework no Windows Azure

  • Artigo

Este tópico mostra como implantar componentes do Sync Framework para um serviço hospedado pelo Windows Azure. Ele também inclui sugestões sobre como criar um aplicativo de N camadas que sincroniza dados de um banco de dados SQL Azure para um banco de dados SQL Server em outro computador.

Noções básicas sobre a sincronização do SQL Azure

O armazenamento de seus dados no Banco de dados do SQL Azure permite que você aproveite vários benefícios, como o acesso seguro aos seus dados a partir de qualquer computador que possa se conectar à Internet. Entretanto, às vezes você pode ser forçado a usar uma rede que é lenta ou não confiável. Ao usar o Sync Framework para sincronizar dados entre um banco de dados SQL Azure e um banco de dados do SQL Server no seu computador local, você pode trabalhar com dados no seu computador local em vez de trabalhar com dados na Internet. Isso permite que você reduza o tráfego na rede, aumentando a confiabilidade do acesso aos seus dados, até mesmo para trabalhar sem uma conexão de rede e que, ao mesmo tempo, mantenha seu banco de dados local atualizado com seu banco de dados SQL Azure.

O uso da arquitetura de 2 camadas ou de uma arquitetura de N camadas são duas maneiras típicas de estruturar um aplicativo que sincroniza um banco de dados SQL Server com um banco de dados SQL Azure.

  • Arquitetura de 2 camadas:: Sync Framework executada em seu computador local e utiliza um objeto SqlSyncProvider para se conectar ao seu banco de dados SQL Azure, bem como a qualquer outro banco de dados do SQL Server. Para obter mais informações sobre como fazer isso, consulte Como configurar e executar a sincronização com o SQL Azure.

  • Arquitetura de N camadas:: um provedor de banco de dados Sync Framework é executado em um serviço hospedado do Windows Azure e se comunica com um provedor proxy executado no seu computador local. O aplicativo de sincronização é executado no seu computador local e se conecta a um provedor de banco de dados que representa seu banco de dados local com um provedor proxy que se comunica com seu serviço do Windows Azure. O serviço Windows Azure consiste basicamente em um provedor de banco de dados SqlSyncProvider que é executado em uma função Web ou função de trabalhador do Windows Azure e representa seu banco de dados SQL Azure.

Para obter mais informações sobre a arquitetura de sincronização, consulte Arquitetura e classes para sincronização de bancos de dados.

Preparando para a sincronização de dados do SQL Azure

Há diversas etapas a serem concluídas antes da sincronização com um banco de dados SQL Azure.

  1. Provisione seu banco de dados SQL Azure para sincronização. Isso cria tabelas de rastreamento e procedimentos armazenados no seu banco de dados que são necessários para a sincronização. Como esta é uma tarefa administrativa, ela não precisa ser incluída no serviço do Windows Azure. Em vez disso, você pode provisionar o banco de dados conectando-se ao banco de dados SQL Azure a partir do seu computador, usando os métodos de provisionamento do Sync Framework. Para obter um exemplo de como provisionar um banco de dados SQL Azure, consulte Como configurar e executar a sincronização com o SQL Azure.

  2. Defina sua interface de serviço o Windows Azure. Crie um componente que implementa essa interface, é executado em uma função Web do Windows Azure e chama um objeto SqlSyncProvider para executar tarefas de sincronização. Crie um provedor proxy que é executado no seu computador local e se comunica com seu serviço do Windows Azure.

  3. Implante seu aplicativo de serviço, incluindo componentes do Sync Framework, em um serviço hospedado pelo Windows Azure.

  4. Conecte o provedor de banco de dados local ao provedor proxy e sincronize.

Definindo e implementando a interface de serviço e o provedor proxy

Em uma arquitetura de N camadas, o serviço hospedado pelo Windows Azure é a camada intermediária que se comunica entre o provedor proxy no computador local e o banco de dados SQL Azure. A maneira como o provedor proxy se comunica com o aplicativo de serviço é definida por você, assim como na implementação do provedor proxy e na implementação do componente do aplicativo de serviço que chama o provedor de banco de dados SqlSyncProvider no seu serviço hospedado pelo Windows Azure. Este é um design típico desses componentes:

  1. Defina uma interface de contrato de serviço WCF (Windows Communication Foundation) que inclui todos os métodos necessários para sincronização, como GetChangeBatch e ProcessChangeBatch.

  2. Crie um componente que implementa os métodos do contrato de serviço e chama um objeto SqlSyncProvider para operar no banco de dados SQL Azure.

  3. Implante este componente e os componentes do Sync Framework exigidos para uma função Web em um serviço hospedado no Windows Azure. Você também pode optar por criar uma função de trabalhador que realize parte do processamento para o aplicativo e se comunique diretamente com os componentes na função da Web. Também implante esses componentes agora.

  4. Crie um provedor proxy que implemente KnowledgeSyncProvider, seja executado no seu computador local e faça chamadas para a interface de serviço implementada pelo seu serviço hospedado pelo Windows Azure.

A implementação da interface de serviço e do provedor proxy pode ser bem complexa. Para obter um exemplo de um aplicativo de sincronização que usa o WCF para se comunicar com um serviço hospedado pelo Windows Azure e que sincroniza com um banco de dados SQL Azure, consulte Code Gallery.

Implantando componentes do Sync Framework para o Windows Azure

Um aplicativo de serviço hospedado pelo Windows Azure usa componentes do Sync Framework como assemblies particulares. Isso garante que seu aplicativo de serviço use apenas um conjunto de componentes do Sync Framework exigidos e que seu aplicativo de serviço não seja afetado por componentes do Sync Framework usados por qualquer outro aplicativo. Após a configuração do seu aplicativo de serviço para usar assemblies particulares do Sync Framework, implante seu aplicativo da mesma forma que implanta qualquer serviço hospedado para o Windows Azure.

Observação sobre segurançaObservação sobre segurança

Assemblies particulares não obtêm atualizações de segurança automáticas; portanto, o proprietário do serviço deve instalar todas as atualizações necessárias de componentes do Sync Framework.

Para configurar seu aplicativo de serviço para que utilize componentes do Sync Framework como assemblies particulares, conclua as etapas a seguir.

  1. Instale o Sync Framework 2.1 SDK no seu computador local. O SDK se encontra em: MSDN Sync Framework Developer Center. A pasta de instalação padrão para os assemblies do Sync Framework 2.1 em uma plataforma x64 é C:\Program Files\Microsoft SDKs\Microsoft Sync Framework\2.1\Runtime\x64.

  2. Copie os assemblies gerenciados do Sync Framework usados pelo seu aplicativo para a pasta que contém seus assemblies do aplicativo de serviço. Como os assemblies do Sync Framework não estão no cache de assembly global no servidor do Windows Azure, o .NET Framework procura-os na pasta onde seu assembly de aplicativo reside. Os assemblies gerenciados usados para a sincronização do banco de dados são:

    • Microsoft.Synchronization.dll

    • Microsoft.Synchronization.Data.dll

    • Microsoft.Synchronization.Data.SqlServer.dll

  3. Crie uma pasta denominada "synchronization.assemblies” na pasta raiz do aplicativo do seu aplicativo de serviço. Copie os assemblies não gerenciados que seu aplicativo requer da pasta de instalação do Sync Framework na pasta sincronization.assemblies. O assembly não gerenciado usado para a sincronização do banco de dados é:

    • Synchronization21.dll

  4. O Sync Framework usa o COM para carregar os assemblies não gerenciados. COM costuma se basear no Registro para localizar assemblies. Em vez de usar o Registro no Windows Azure, inclua dois arquivos de manifesto para ajudar o COM a localizar os assemblies particulares não gerenciados.

    Crie o primeiro arquivo de manifesto criando um arquivo de texto denominado “synchronization.assemblies.manifest” na pasta synchronization.assemblies. Copie as seguintes informações neste arquivo:

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>

<assemblyIdentity
   type="x64"
   name="synchronization.assemblies"
   version="2.1.0.0"
/>

  <file name = "synchronization21.dll">
    <comClass clsid="{EC413D66-6221-4ebb-AC55-4900FB321011}" threadingModel="Both"/>    
  </file>

</assembly>

    Crie o outro arquivo de manifesto criando um arquivo de texto denominado “webapp.manifest” na pasta raiz do aplicativo. Copie as seguintes informações neste arquivo:

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <assemblyIdentity name="webapp" version="8.0.0.0" type="x64"/>

  <dependency>
    <dependentAssembly>

      <assemblyIdentity name="synchronization.assemblies" version="2.1.0.0" type="x64"/>
    </dependentAssembly>
  </dependency>


</assembly>

    Para obter mais informações sobre assemblies COM particulares, consulte Isolated Applications and Side-by-Side Assemblies.

  5. Crie um contexto de ativação no seu aplicativo que é usado para carregar os assemblies COM em tempo de execução. Para fazer isso, crie uma classe como a mostrada a seguir no seu projeto e chame o método CreateActivationContext quando seu aplicativo iniciar. Um exemplo é a substituição do método Microsoft.WindowsAzure.ServiceRuntime.RoleEntryPoint.OnStart:

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Runtime.InteropServices;
using System.IO;

namespace Microsoft.Samples.Synchronization
{
    public class ActivationContext
    {
        // Activation Context API Functions 

        [DllImport("Kernel32.dll", SetLastError = true)]
        private extern static IntPtr CreateActCtx(ref ACTCTX actctx);

        // Activation context structure 
        private struct ACTCTX
        {
            public int cbSize;
            public uint dwFlags;
            public string lpSource;
            public ushort wProcessorArchitecture;
            public ushort wLangId;
            public string lpAssemblyDirectory;
            public string lpResourceName;
            public string lpApplicationName;
        }

        private const int ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID = 0x004;
        private const int ACTCTX_FLAG_SET_PROCESS_DEFAULT = 0x00000010;
        private IntPtr m_hActCtx = (IntPtr)0;
        public const UInt32 ERROR_SXS_PROCESS_DEFAULT_ALREADY_SET = 14011;

        /// <summary>
        /// Explicitly load a manifest and create the process-default activation 
        /// context. It takes effect immediately and stays there until the process exits. 
        /// </summary>
        static public void CreateActivationContext()
        {
            string rootFolder = AppDomain.CurrentDomain.BaseDirectory;
            string manifestPath = Path.Combine(rootFolder, "webapp.manifest");
            UInt32 dwError = 0;

            // Build the activation context information structure 
            ACTCTX info = new ACTCTX();
            info.cbSize = Marshal.SizeOf(typeof(ACTCTX));
            info.dwFlags = ACTCTX_FLAG_SET_PROCESS_DEFAULT;
            info.lpSource = manifestPath;
            if (null != rootFolder && "" != rootFolder)
            {
                info.lpAssemblyDirectory = rootFolder;
                info.dwFlags |= ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID;
            }

            dwError = 0;

            // Create the activation context 
            IntPtr result = CreateActCtx(ref info);
            if (-1 == result.ToInt32())
            {
                dwError = (UInt32)Marshal.GetLastWin32Error();
            }

            if (-1 == result.ToInt32() && ActivationContext.ERROR_SXS_PROCESS_DEFAULT_ALREADY_SET != dwError)
            {
                string err = string.Format("Cannot create process-default win32 sxs context, error={0} manifest={1}", dwError, manifestPath);
                ApplicationException ex = new ApplicationException(err);
                throw ex;
            }
        }
    }
}

    Imports System
Imports System.Collections.Generic
Imports System.Linq
Imports System.Text
Imports System.Web
Imports System.Runtime.InteropServices
Imports System.IO

Namespace Microsoft.Samples.Synchronization
    Public Class ActivationContext
        ' Activation Context API Functions 

        <DllImport("Kernel32.dll", SetLastError := True)> _ 
        Private Shared Function CreateActCtx(ByRef actctx As ACTCTX) As IntPtr
        End Function

        ' Activation context structure 
        Private Structure ACTCTX
            Public cbSize As Integer
            Public dwFlags As UInteger
            Public lpSource As String
            Public wProcessorArchitecture As UShort
            Public wLangId As UShort
            Public lpAssemblyDirectory As String
            Public lpResourceName As String
            Public lpApplicationName As String
        End Structure

        Private Const ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID As Integer = &H4
        Private Const ACTCTX_FLAG_SET_PROCESS_DEFAULT As Integer = &H10
        Private m_hActCtx As IntPtr = DirectCast(0, IntPtr)
        Public Const ERROR_SXS_PROCESS_DEFAULT_ALREADY_SET As UInt32 = 14011

        ''' <summary>
        ''' Explicitly load a manifest and create the process-default activation 
        ''' context. It takes effect immediately and stays there until the process exits. 
        ''' </summary>
        Public Shared Sub CreateActivationContext()
            Dim rootFolder As String = AppDomain.CurrentDomain.BaseDirectory
            Dim manifestPath As String = Path.Combine(rootFolder, "webapp.manifest")
            Dim dwError As UInt32 = 0

            ' Build the activation context information structure 
            Dim info As New ACTCTX()
            info.cbSize = Marshal.SizeOf(GetType(ACTCTX))
            info.dwFlags = ACTCTX_FLAG_SET_PROCESS_DEFAULT
            info.lpSource = manifestPath
            If rootFolder IsNot Nothing AndAlso "" <> rootFolder Then
                info.lpAssemblyDirectory = rootFolder
                info.dwFlags = info.dwFlags Or ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID
            End If

            dwError = 0

            ' Create the activation context 
            Dim result As IntPtr = CreateActCtx(info)
            If -1 = result.ToInt32() Then
                dwError = DirectCast(Marshal.GetLastWin32Error(), UInt32)
            End If

            If -1 = result.ToInt32() AndAlso ActivationContext.ERROR_SXS_PROCESS_DEFAULT_ALREADY_SET <> dwError Then
                Dim err As String = String.Format("Cannot create process-default win32 sxs context, error={0} manifest={1}", dwError, manifestPath)
                Dim ex As New ApplicationException(err)
                Throw ex
            End If
        End Sub
    End Class
End Namespace

  6. Seu aplicativo agora está pronto para ser implantado para o Windows Azure!

    Para obter mais informações sobre como implantar seu aplicativo para o Azure, consulte Deploying a Service.

Consulte também

Outros recursos

Sincronizando o SQL Server e o SQL Server Compact