Este artigo foi traduzido por máquina.

Sites do Azure

Conectividade híbrida: Conectar sites do Azure para aplicativos LOB usando o PortBridge

Erick Redkar

Baixar o código de exemplo

Ao contrário da crença popular, nem tudo vai para a nuvem, pelo menos não ainda. Assim como todos os carros ainda não híbrido e a maioria dos aparelhos ainda não são eficientes em termos energéticos, uma boa quantidade de software ainda será executado no local por anos para vir. Investimentos do fundo são difíceis de abandonar, e a maioria das empresas exige uma justificativa de negócio significativos para modernizar uma aplicação existente. Tem painéis solares em sua casa? Apesar das poupanças de energia a longo prazo e benefícios fiscais, as pessoas estão relutantes em investir nelas, devido os custos iniciais. Não é tão diferente para as organizações, quando se trata de mover-se para a nuvem.

Felizmente, no entanto, conectividade híbrido permite modernizar suas aplicações explorando o poder da nuvem, enquanto ainda plugando existente software serviços que são executados no local em seu data center. Neste artigo, mostrarei como criar um Web site que utiliza o barramento de serviço Azure para conexão com os serviços de software rodando em datacenters non-Azure. Em vez de usar a API de barramento de serviço diretamente, vou usar um utilitário popular chamado PortBridge para conectar o Azure Web Sites com serviços no local.

Conectividade de híbrido no Azure

Azure inclui uma série de serviços para a construção de aplicativos híbridos. Para conectividade de híbrido, os dois mais comumente usados são a rede Virtual Azure e Azure Service Bus. Azure rede Virtual permite que você estender a sua rede local em Azure, assim, esculpindo uma rede privada híbrido entre Azure e do datacenter. A extensão entre Azure e seu datacenter acontece na camada de rede, ao invés de camada de aplicativo no barramento de serviço. Porque este artigo é sobre conectividade de aplicativos usando o serviço de ônibus, eu não estar cobrindo Azure rede Virtual aqui. Para obter mais informações, visite bit.ly/QAODgX.

O serviço de retransmissão de barramento de serviço permite que você conecte dois aplicativos que residem por trás de um firewall. Os aplicativos podem ser residentes no Azure ou seus centros de dados ou ambos. Relé de barramento de serviço dá-lhe a capacidade de registrar pontos de extremidade do seu aplicativo Windows Communication Foundation (WCF) para o registro de barramento de serviço em datacenters Azure. Invocações de método podem ser firmemente trocadas entre o cliente e o servidor dentro da infra-estrutura de barramento de serviço e então comunicadas aos respectivos aplicativos executando em seu data center. Isto é ideal, por exemplo, para um cenário em que uma empresa precisa acessar o HVAC ou medidor de energia para a coleta de dados e enviar eventos importantes para estes dispositivos de um servidor central, executado no Azure. Figura 1 ilustra este exemplo, onde a empresa concessionária tem um cabeça-end rodando no Azure e dispositivos em edifícios.

Figura 1 cenário de retransmissão de autocarro de serviço em uma empresa de serviços públicos

O gateway de controle é um dispositivo executando em edifícios que é responsável por controlar dispositivos elétricos. Cada gateway controle tem um ponto de extremidade do WCF registrado com o registro de barramento de serviço com um identificador exclusivo. Sempre que o serviço de ponta cabeça, correndo em um dos serviços de computação do Azure, quer se comunicar com um gateway de controle específico, ele abre uma conexão com o ponto de extremidade exclusivo no barramento de serviço e começa a enviar ou recuperar mensagens para ou a partir do gateway de controle. Normalmente, a porta de entrada de controle reside atrás de firewall do edifício. Mas se você tiver um serviço WCF não (por exemplo, um banco de dados do SQL Server ) executando no local que você deseja se conectar a um Site do Azure?

Introdução PortBridge

PortBridge é um utilitário construído no topo da API de barramento de serviço que permite a comunicação entre quaisquer pontos de extremidade do serviço baseado em TCP correndo no local e no Azure. O conceito de núcleo de PortBridge e o protótipo foram desenvolvidos pela Clemens Vasters (bit.ly/SI93GM). Eu modifiquei um pouco para este artigo e é compilado com a versão recente do SDK do serviço de ônibus. Quando você criar aplicativos para o serviço de retransmissão de ônibus, você é forçado a criar uma interface WCF para todas relevantes de extremidade que você deseja expor na nuvem. Quando você tem um grande número de pontos de extremidade ou pontos de extremidade plataforma genérica, como bancos de dados e motores de busca, isso pode ficar chato e inconveniente. Adicionar outra abstração WCF em cima destes serviços não faz sentido. Em vez disso, você pode usar PortBridge para expor pontos de extremidade do WCF não - TCP para conectividade de relé de barramento de serviço. Aplicativos front-end como o Azure Web Sites então podem tirar vantagem de se conectar a qualquer fonte de dados TCP que residem no seu datacenter atrás de um firewall. Conceitualmente, PortBridge cria uma interface genérica do WCF, como mostrado em Figura 2.

Figura 2 a Interface do Windows genérico de PortBridge comunicação

namespace Microsoft.Samples.ServiceBus.Connections
{
  using System;
  using System.ServiceModel;
  [ServiceContract(Namespace="n:",
    Name="idx", CallbackContract=typeof(IDataExchange),
    SessionMode=SessionMode.Required)]
  public interface IDataExchange
  {
    [OperationContract(Action="c", 
      IsOneWay = true, IsInitiating=true)]
    void Connect(string i);
    [OperationContract(Action = "w", IsOneWay = true)]
    void Write(TransferBuffer d);
    [OperationContract(Action = "d", 
      IsOneWay = true, IsTerminating = true)]
    void Disconnect();
  }
  public interface IDataExchangeChannel : 
    IDataExchange, IClientChannel { }
}

Com apenas três métodos genéricos, PortBridge atua como um proxy entre os pontos de extremidade do cliente e servidor e encaminha todas as chamadas TCP para o servidor designado em um serviço de ônibus Relay. A maior vantagem do uso de PortBridge é que você não precisa criar uma interface WCF para cada ponto de extremidade no local que você deseja habilitar para conectividade de híbrido.

PortBridge é composto por dois componentes:

1. Um agente que executa mais perto para o aplicativo cliente, ou em uma máquina virtual (VM) em infraestrutura Azure como um serviço (IaaS).
2. Um serviço do Windows (ou um aplicativo de console) que é executado no local e atua como um proxy para pontos de extremidade do serviço em execução no mesmo ambiente.

Alguns casos de uso comum para PortBridge são:

• Conectando-se a quaisquer dados baseados em TCP armazenar no local
• Conectando-se aos serviços da Web de terceiros que não podem ser migrados para o Azure
• Conexões de área de trabalho remota

Neste artigo, você aprenderá como implantar e configurar o PortBridge para permitir a comunicação entre Sites de Azure e um banco de dados SQL Server rodando na sua máquina local.

Uma solução híbrida

Azuis Web Sites forma tipicamente o front-end da Web ou serviços da Web da sua camada de aplicativo. Mas em muitas situações, você não pode migrar algumas das fontes de dados que o Web site o poder para o Azure. Em tais casos, a PortBridge é uma solução ideal para conexão Azure Web Sites com bancos de dados sendo executado no local. Azuis Sites da Web se comunica com o agente de PortBridge, que por sua vez, se comunica com o serviço de PortBridge através do barramento de serviço. O serviço de PortBridge, em seguida, encaminha a chamada para o banco de dados de destino. Figura 3 ilustra a arquitetura do site do híbrido que vai construir neste artigo e mostra uma troca de mensagem típica em um ambiente de PortBridge (ou relé de barramento de serviço):

Figura 3 arquitetura de amostra PortBridge

1. O aplicativo de console de PortBridge no local (ou o serviço do Windows) registra o ponto de extremidade do banco de dados TCP (1433 para SQL Server) dentro do registro de nomenclatura Service Bus com um URI exclusivo. Serviço de autocarro relé abre uma conexão de saída de bi-direcional com o aplicativo de console.
2. Quando uma solicitação de HTTP ou HTTPS para Sites Web de Azure, o site abre a conexão de banco de dados como de costume, mas com o endereço IP do agente PortBridge VM em vez disso.
3. A VM de agente PortBridge atua como o proxy de banco de dados na nuvem e tem duas interfaces de comunicação — para receber solicitações TCP e para se conectar ao ponto de extremidade de serviço ônibus relé PortBridge do console.
4. O agente PortBridge roteia a solicitação de banco de dados para o serviço de retransmissão de barramento de serviço. A beleza da solução é que para Sites da Web de Azure, é negócio como de costume. A API de banco de dados não mudou, apenas o endereço IP tem.
5. Serviço de autocarro relé roteia a chamada para a aplicação de PortBridge em execução no seu localhost (ou datacenter).
6. Finalmente, a chamada atinge o banco de dados, e os dados são recuperados usando a mesma conexão.

Observe que há um número de componentes envolvidos na comunicação sobre PortBridge, e você precisa de uma VM extra que possa não ser necessária se usando diretamente o serviço de ônibus. Como mencionado anteriormente, a vantagem aqui é a generalização de expor quaisquer pontos de extremidade TCP — você pode reutilizar o mesmo VM de agente PortBridge para se conectar com várias fontes de dados executando em diferentes locais. Agora que eu já te mostrei a arquitetura de sistema da solução, eu vou começar a construi-lo.

Criando um serviço Web RESTful

Para manter este artigo simples, eu vou projetar um serviço RESTful ASP.NET Web API chamado países que recupera uma lista de todos os países de uma tabela de banco de dados do SQL Server . No processo de desenvolvimento, eu recomendo sempre construindo e testando localmente antes de implantar para a nuvem. Figura 4 mostra o código para o serviço da Web de países.

Figura 4 países Web Service

public class CountriesController : ApiController
{
  private string DatabaseConnectionString { get; set; }
  public CountriesController()
  {
    try
    {
      DatabaseConnectionString =
        ConfigurationManager.
ConnectionStrings["DatabaseConnectionString"].
ConnectionString;
      }catch(Exception ex)
      {
        Trace.TraceError(ex.Message);
      }
  }
  // GET: api/Countries
  public IEnumerable<Country> Get()
  {
    return CountryService.GetCountries(DatabaseConnectionString);
  }
  // GET: api/Countries/AD
  public Country Get(string id)
  {
    return CountryService.GetCountry(DatabaseConnectionString, id);
  }
}

O serviço da Web tem apenas dois métodos — e (id de seqüência de caracteres). O método Get recupera todos os países da tabela de banco de dados e o método Get(id) recupera um objeto do país pelo código do país. Figura 5 ilustra a tabela de banco de dados do país no banco de dados local do SQL Server .

Figura 5 tabela de banco de dados de países

Figura 6 mostra a classe CountryService que recupera os dados do banco de dados e retorna objetos do país.

Depois que o banco de dados e o serviço da Web estiverem prontos, você pode rapidamente testar o serviço da Web localmente pressionando F5 para executá-lo de Visual Studio. Se tudo correr bem, você tem um serviço Web que funciona localmente. Agora você quer movê-la para a nuvem, mas você não pode migrar o banco de dados para a nuvem, porque ele é compartilhado com outras aplicações que ainda podem ser executados no local. PortBridge se encaixa perfeitamente neste cenário, com mínimo ou nenhum código muda para seu serviço da Web.

Figura 6 a CountryService classe

public class CountryService
{
  public static IEnumerable<Country> GetCountries(string connectionString)
  {
    IList<Country> countries = new List<Country>();
    using (IDataReader reader = 
      SqlHelper.ExecuteReader(connectionString,
      System.Data.CommandType.Text, "SELECT CountryId, CountryName,
      CountryCode FROM Country"))
    {
      while(reader.Read())
      {
        Country c = new Country()
        {
          CountryId = Convert.ToInt32(reader["CountryId"]),
          CountryCode = Convert.ToString(reader["CountryCode"]),
          CountryName = Convert.ToString(reader["CountryName"]),
        };
        countries.Add(c);
      }
    }
    return countries;
  }
  public static Country GetCountry(string connectionString, 
    string countryCode)
  {
    Country c = new Country();
    using (IDataReader reader = 
      SqlHelper.ExecuteReader(connectionString,
      System.Data.CommandType.Text,
      "SELECT CountryId, CountryName, CountryCode FROM Country WHERE
      CountryCode=@countryCode",
      new SqlParameter("@countryCode", countryCode)))
    {
      if (reader.Read())
      {
        c.CountryId = Convert.ToInt32(reader["CountryId"]);
        c.CountryCode = Convert.ToString(reader["CountryCode"]);
        c.CountryName = Convert.ToString(reader["CountryName"]);
      }
    }
    return c;
  }
}
  [DataContract]
    public class Country
    {
      [DataMember]
      public int CountryId { get; set; }
      [DataMember]
      public string CountryName { get; set; }
      [DataMember]
      public string CountryCode { get; set; }
}

Criação de PortBridge

Antes de mover o serviço da Web para a nuvem, você precisa configurar e testar a PortBridge. Porque existem vários níveis na arquitetura, é importante para obter a configuração de todos os componentes bem no início. Eu costumo criar uma tabela que lista os pontos de extremidade de entrada e de saída para cada componente (ver Figura 7).

Locais e pontos de extremidade Figura 7

Componente de solução	Ponto de extremidade de entrada	Ponto de extremidade de saída	Ponto de extremidade de saída
Serviço de Web de países	80		Azure Web Site
Agente de PortBridge	1433	1433	Azure máquina Virtual
PortBridge	1433	1433	Azure máquina Virtual
S Server	1433		Azure máquina Virtual

Esta tabela neste caso pode parecer trivial, mas para aplicações com centenas de pontos de extremidade, uma tabela como esta irá ajudá-lo configurar serviços corretamente. Como discutido anteriormente, o agente de PortBridge reside em uma VM e tem duas interfaces de ponto de extremidade — entrada de saída e a aplicação de um ponto de extremidade do serviço ônibus relé. Da mesma forma, o serviço de PortBridge rodando na sua máquina local tem dois pontos de extremidade — entrada do serviço de retransmissão de ônibus e saída para o banco de dados do SQL Server . Depois de ter anotados os parâmetros de configuração, você pode iniciar o processo de implantação.

Criando um Namespace de barramento de serviço

Porque o backbone de comunicação desta solução é o serviço de retransmissão de ônibus, tenho que primeiro criar um namespace de barramento de serviço do portal do Azure (manage.windowsazure.com), como mostrado em Figura 8.

Figura 8 criando o serviço de autocarro Namespace

O namespace de países em Figura 8 é exclusivo e será usado para criar um ponto de extremidade exclusivo para os serviços. Uma vez que o namespace que você criou, clique no botão informações de conexão na parte inferior da página para ver informações de acesso do namespace­mação. Você vai precisar do emitente padrão e a chave padrão para acessar o espaço para nome, mostrado no Figura 9, então tome nota destes.

Figura 9 serviço ônibus Namespace credenciais

O agente de PortBridge e o PortBridge aplicativo exigem essas credenciais para conectar-se ao namespace.

Configurando o aplicativo PortBridge

A aplicação de PortBridge tem uma seção de configuração personalizada:

<portBridge serviceBusNamespace="countries" 
  serviceBusIssuerName="owner"
  serviceBusIssuerSecret="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">
  <hostMappings>
   <!-- Open HTTP, SQL Server, RDP and ElasticSearch ports-->
     <add targetHost="TREDKAR-W530" allowedPorts="1433" />
  </hostMappings>
</portBridge>

O namespace, o nome do emitente e o segredo são necessárias para se conectar ao namespace relé de barramento de serviço que criei anteriormente. A seção de mapeamento de host lista o host do serviço de destino. No meu exemplo, é a máquina local e a porta 1433. Você pode adicionar portas separados por vírgulas para externar a vários pontos de extremidade no mesmo host. Você também pode adicionar vários hosts de destino, enquanto eles estão acessíveis a partir da máquina de aplicação de PortBridge. Quando a configuração estiver concluída, inicie a aplicação de PortBridge em sua máquina local. Se tudo correr como esperado, você deve ver uma tela semelhante de Figura 10.

Figura 10 PortBridge aplicação rodando

O aplicativo PortBridge cria uma conexão de saída para o serviço de retransmissão de barramento de serviço sobre o namespace de países e cria um nome exclusivo com o formato PortBridge / [target host], onde [host de destino] é o parâmetro targetHost no arquivo de configuração do aplicativo PortBridge, como mostrado no Figura 11.

Ligação de relé Figura 11 Service Bus

A parte PortBridge do nome é codificado, Considerando que as alterações do host de destino dependendo do número de hosts que criaste. É importante notar que, para manter o nome dentro do namespace exclusivo, cada host de destino terá apenas uma entrada na seção hostMappings do arquivo de configuração.  Também note que se você não configurar o parâmetro targetHost corretamente, o ponto de extremidade criado não irá corresponder ao serviço que você deseja representar e comunicações irão falhar.

Para obter mais informações sobre portas de saída exigido por ligações de retransmissão de barramento de serviço, visite bit.ly/1l8lncx.

Configurando o agente PortBridge

Como a aplicação de PortBridge, o agente de PortBridge também tem uma seção de configuração personalizada:

<portBridgeAgent serviceBusNamespace="countries" 
  serviceBusIssuerName="owner"
  serviceBusIssuerSecret=" XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ">
<portMappings>
<port localTcpPort="1433" targetHost="TREDKAR-W530" 
      remoteTcpPort="1433">
<firewallRules>
  <rule source="127.0.0.1"/>
  <rule sourceRangeBegin="208.0.0.0" 
        sourceRangeEnd="208.255.255.255"/>
...
</firewallRules>
</port>
</portMappings>

O agente de PortBridge tem uma seção de mapeamento de porta onde você mapear cada porta de entrada de ponto de extremidade (localTcpPort) para o porto de ponto de extremidade do Service Bus relé (remoteTcpPort). O valor de host de destino deve coincidir com o valor de host de destino que você criou anteriormente na configuração do aplicativo PortBridge. Esse valor é usado para conexão com o ponto de extremidade do namespace de barramento de serviço apropriado. Se estes dois valores não coincidirem, o aplicativo não funcionará.

Na seção de regras de firewall, você pode explicitamente listar os endereços IP de máquinas a partir do qual o agente PortBridge aceitará solicitações. Porque minha PortBridge agente vai ser aceitar solicitações de um Web Site do Azure, preciso adicionar os intervalos de IP de datacenters da Azure para as regras de firewall. Você pode baixar os intervalos de IP Azure datacenter de bit.ly/1l8yDxV.

Para implantar o agente PortBridge em Azure, navegar no portal do Azure, criar uma nova VM do Windows, copie os arquivos do agente PortBridge e executar PortBridgeAgent.exe. Como criar a VM, certifique-se de que abrir o ponto de extremidade 1433 para acesso externo para que o Site do Azure possa acessar essa porta na VM PortBridge agente.

Outra opção para a implantação do agente de PortBridge é através de aplicativos para o Azure, uma maneira fácil de implantar aplicativos Windows Store. Aplicativos para o Azure é um aplicativo gratuito com pré-embalados VMs prontamente disponíveis para a implantação, e tem uma VM PortBridge pré-embalados, conforme mostrado no Figura 12. Você pode instalar Apps para Azure de appsforazure.com.

Figura 12 Apps para Azure para implantar o agente PortBridge

A VM de agente PortBridge pré-embalados por padrão abre as portas de ponto de extremidade de 1433 e 80 para comunicação. Se você quiser personalizar, configurar o agente de PortBridge, você precisará modificar o arquivo PortBridgeAgent.exe.config na pasta C:\ddapplications. Depois de configurar o arquivo, você terá que reiniciar a dinâmica­DeployInitService serviço do Windows.

Testando e implantando o serviço de Web de países

Uma vez que os componentes do PortBridge estão instalado e em execução, você precisará modificar a seqüência de conexão de banco de dados do serviço Web para apontar para o PortBridge agente VM:

<add name="DatabaseConnectionString"
  connectionString=
  "Server=tejaswisvm1.cloudapp.
net;
  Database=cf10292013;
  Trusted_Connection=True;"/>

Observe que o nome do host, além de todos os outros parâmetros permanecem as mesmas. Com essa alteração na configuração, você vai estar apontando para a VM de agente PortBridge em vez de banco de dados diretamente. Em seguida, publicar o serviço países Web API para Azure Web Sites e testá-lo navegando para os URIs seguintes:

1. http://[Azure Web site host] / api/países, para recuperar todos os países.
2. http://[Azure Web site host] / api/países / [código do país], para recuperar um determinado país por país código.

Se está trabalhando a comunicação de fim-de-final, ambos os URIs irá retornar objetos JSON para as chamadas de método. Agora você pode chamar o serviço Web de países de todo o dispositivo e a chamada vai atravessar do Site do Azure para agente de PortBridge e alcance o banco de dados do SQL Server através da aplicação de PortBridge. Os dados serão recuperados do banco de dados rodando na sua máquina local (ou datacenter).

Considerações sobre desempenho

Porque PortBridge é uma camada de indirection, ele causa latência quando comparado com as arquiteturas que envolvem a comunicação direta de dados ou conectividade de rede virtual híbrida. PortBridge recomenda-se apenas em cenários onde rede virtual e comunicação direta não é viável. No momento da redação deste texto, Azure Web Sites não suportam rede virtual e, portanto, o barramento de serviço é a única opção para a construção de conectividade híbrido. Durante o meu teste, eu vi as latências variando de 50ms a 300ms para o serviço Web de países. Para alguns cenários, eu recomendo apenas periodicamente a pedir os serviços executando em datacenters remotos e armazenamento em cache os dados na nuvem.

Considerações sobre segurança

PortBridge conta com os recursos de segurança do serviço de retransmissão de ônibus. Por padrão, o PortBridge usa a segurança de conexão para conectar-se ao namespace de barramento de serviço, mas não emprega recursos de criptografia de transporte ou de mensagem. O agente PortBridge fornece um endereço IP personalizado mecanismo de filtragem, mas isto não deve ser considerado tão robusto como os mecanismos de segurança interna de barramento de serviço Azure. Eu recomendo realizar discussão detalhada modelagem antes de implantar a solução em produção.

Dimensionamento de PortBridge

A arquitetura em Figura 3, parece que o agente de PortBridge é um ponto único de falha. Mas você pode escalar para fora o agente PortBridge, adicionando um balanceamento de carga de ponto de extremidade ao VM e criando várias instâncias do agente PortBridge VM. As chamadas no Site da Azure irá então ser carga balanceada através de vários agentes de PortBridge. Mesmo que você pode escalar para fora agente PortBridge, o ponto de extremidade de destino final (o banco de dados) deve ser projetado para lidar com esta escala para fora. Não queres escalar fora da Web e camada intermediária mas falham na camada de dados. Seu projeto deve ser elástico até o fim.

PortBridge no mundo Real

Nos últimos dois anos, com base em vários pedidos de cliente, nossa equipe construiu um hub de mensagens na nuvem para integrar aplicativos de terceiros com serviços Azure. O objetivo era criar um modelo de plug-and-play fácil para coletar dados de fontes de dados díspares e então os dados agregados de superfície para os usuários finais em dispositivos de diferentes tamanhos. A equipe decidiu usar PortBridge como a espinha dorsal para criar este modelo de plug-and-play, porque permitia a abstração necessária para conectar serviços não WCF com aplicações rodando no Azure. Temos modificar o código de PortBridge para melhor diagnóstico, desempenho e cache. Alguns dos cenários que implementamos com sucesso foram:

1. Criando um serviço de mensagens unificado que integra as 19 diferentes fontes de dados de uma empresa da Fortune 50 e fornecendo um mashup de dados contextuais no trabalho para os funcionários de campo do cliente. Acesso rápido a infor necessário­mação no campo foi o principal objetivo desta solução.
2. Recuperando dados de milhares de instâncias do aplicativo usadas para gerenciar o estoque de veículos comerciais e armazenando os dados em um repositório central de dados na nuvem. Os dados capturados foi utilizados para manutenção preditiva e estudando comportamento do comprador. Sem serviço de ônibus (e PortBridge), um aplicativo teria levado 10 vezes o custo e o esforço.
3. Proporcionando o processo de gestão de informações e de quadro de horários para milhares de advogados em seus dispositivos móveis em qualquer lugar. Antes desta aplicação, os advogados tiveram que viajar de volta para o escritório após cada processo judicial para registrar seu tempo. Com o app móvel, eles podem registrar suas entradas diretamente do tribunal.

Conclusão

Azure Service Bus e Sites da Web se complementam na construção de aplicações Web de híbrido. PortBridge é apenas uma camada de abstração em cima do serviço de retransmissão de ônibus para convenientemente expor pontos de extremidade do WCF não na nuvem. Eu tenho lidado com vários cenários que exigia a construção de agregação mashup Web sites onde os dados são recuperados de vários serviços Web em execução em diferentes locais. Usando PortBridge, esses aplicativos podem ser projetados, testados e construídos sem alterações significativas para o código do aplicativo original. Uma vez que a configuração inicial de PortBridge é testada, a conectividade funciona consistentemente enquanto os barramento de serviços e Web services estão disponíveis. Apesar de PortBridge permite que você rapidamente construir aplicações híbridas, tenha em mente que apresentar latência em suas chamadas de serviço. Se seu aplicativo é sensível ao tempo de resposta, PortBridge pode não ser a escolha certa e você deve avaliar Azure rede Virtual ou migrar serviços no local para a nuvem. Depois de caminhar através da solução descrita neste artigo, você deve ser confortável, exteriorizando qualquer ponto de extremidade local em Azure e então chamá-lo de um Site do Azure. Código-fonte para o PortBridge e o acompanhamento países Web service está disponível no GitHub em github.com/dynamicdeploy/portbridge.

Tejaswi Redkar é um autor e um desenvolvedor de software. Ele atualmente trabalha para a Microsoft como um diretor de estratégia de plataforma de aplicativo e comunidades. Seu livro, "Windows Azure Web Sites: Criando aplicativos de Web em um ritmo rápido"(Dynamic implantar LLC, 2013), é a mais abrangente e best-seller sobre o tema. Redkar também é o criador do appsforazure.com e dynamicdeploy.com, onde ele experiências em primeira mão executando aplicativos de produção na nuvem. Você pode alcançá-lo no tejaswi_redkar@hotmail.com e segui-lo no Twitter em twitter.com/tejaswiredkar.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Equipe de gerenciamento de produto Microsoft Azure