Self-Hosting com SignalR e integração via ASP.NET MVC

O ASP.NET SignalR é um framework de comunicação em tempo real que pode ser utilizado para diversas funcionalidades, inclusive para integração de comunicação entre sistemas de diferentes plataformas.

Caso não conheça o ASP.NET SignalR aprenda em detalhes neste artigo e nesta palestra.

Integração de Comunicação em Tempo Real com ASP.NET SignalR

O ASP.NET SignalR vem sendo amplamente utilizado em diversos cenários de comunicação em tempo real. Muitas vezes a própria solução Web implementa os Hubs e gerencia o recebimento e distribuição de mensagens.

Existem outros cenários em que é necessário desacoplar o lado server do SignalR da aplicação Web. Muitas vezes a informação a ser distribuída pode vir de outros serviços, outras plataformas e etc. É possível utilizar SignalR nesses casos? Sim, é possível!

O SignalR é implementado seguindo a especificação do OWIN e pode trabalhar em uma aplicação Web ou no modo Self-Host em um Windows Service ou aplicação console.

Proponho um cenário hipotético: Existem N broadcasts sendo distribuídos de diversas aplicações independentes da Microsoft e é necessário que a comunicação seja transmitida em tempo real para outras plataformas (Web, Desktop, Mobile). É necessário utilizar uma solução única para atender esta demanda e com baixo esforço de desenvolvimento.

Este cenário é muito similar ao da imagem utilizada no início do artigo e segue o fluxo a seguir:

  1. O Windows Service implementa uma forma de receber a comunicação vinda das demais aplicações.
  2. Os Hubs do SignalR no Windows Service distribuem as informações recebidas à todos os clientes conectados.
  3. Os clientes conectados recebem a comunicação em tempo real e se necessário podem encaminhar novas informações para o Windows Service.
  4. O Windows Service recebe as informações de um cliente e redistribui para todos novamente (como num chat).

Desenvolvi a solução deste cenário utilizando um Windows Service gerando dados de tempo, dados aleatórios de valores e trabalhando com uma comunicação via chat.

Aplicação ASP.NET MVC recebendo em tempo real as informações do Windows Service no Chrome e no Edge.

A solução está publicada em meu GitHub

  • Para testes de desenvolvimento não é necessário instalar o serviço (Windows Service), basta setar os dois projetos para iniciarem juntos e realizar um Debug.
  • É possível implementar autenticação para transmitir a comunicação apenas para clientes com a devida permissão.
  • É possível implementar algum Retry Pattern como o Polly caso haja alguma falha na entrega da comunicação.

Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações Web com arquitetura baseada em DDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade inscreva-se em meu curso:


Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

Debugando Windows Services no Visual Studio

Um colega de trabalho me questionou como debugar um Windows Services, geralmente isso é uma tarefa chata, precisamos instalar o serviço e ativar a interação para depois iniciar o Visual Studio em modo debug atachando o processo do serviço instalado.

Veja bem, não precisa ser complicado assim. Basta definir no próprio código o comportamento. Acredito que isso veja a ajudar bastante o nosso dia-a-dia então ai vai:

No seu arquivo Program.cs em seu estado original encontraremos o código a seguir:

namespace ServicoEduardo
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        static void Main()
        {
            ServiceBase[] ServicesToRun;
            ServicesToRun = new ServiceBase[]
			{
				new Service1()
			};
            ServiceBase.Run(ServicesToRun);
        }
    }
}

No código a seguir estamos deixando o serviço apto a ser debugado pelo Visual Studio sem a necessidade de instalação ou demais configurações:

namespace ServicoEduardo
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        static void Main()
        {
#if (!DEBUG)
            ServiceBase[] ServicesToRun;
            ServicesToRun = new ServiceBase[]
			{
				new Service1()
			};
            ServiceBase.Run(ServicesToRun);
#else
            // Debug code: Permite debugar um código sem se passar por um Windows Service.
            // Defina qual método deseja chamar no inicio do Debug (ex. MetodoRealizaFuncao)
            // Depois de debugar basta compilar em Release e instalar para funcionar normalmente.
            Service1 service = new Service1();
            // Chamada do seu método para Debug.
            service.MetodoRealizaFuncao();
            // Coloque sempre um breakpoint para o ponto de parada do seu código.
            System.Threading.Thread.Sleep(System.Threading.Timeout.Infinite);
#endif
        }
    }
}

O que fizemos? Simples, informamos no próprio código o seu devido comportamento, assim quando estiver em modo Debug no Visual Studio ao dar um F5 seu código iniciará na chamada do método que foi definida.

Para testarmos as rotinas é muito prático, pois evitamos a necessidade de instalar e atachar o processo do serviço, que na maioria das vezes se torna o grande problema para testarmos as funcionalidades desenvolvidas.

Espero ter ajudado, em caso de dúvidas deixe um comentário.