Não sei se você conhece WCF, rodando uma enquete eu percebi que uma parcela considerável sequer conhece WCF. Hoje vamos costurar o assunto com um outro post para que eu possa mostrar como fazer uma migração de WCF pra Web API no ASP.NET Core, rodando em containers Linux.
Nosso cenário de teste é super simples, uma API de Cálculo, que só tem uma operação de SOMA. Sem acesso a dados, uma API tão simples quanto isso.
O WCF, Windows Communication Foundation é framework pra a construção de aplicações orientadas a serviço. A distribuição de serviços possui desafios próprios e WCF que abstrai os principais muitas coisas nessa jornada. Foi desenvolvida sobre o ponto de vista de ser algo extremamente flexível e versátil, endereçando os principais problemas da computação distribuída, como resiliência, flexibilidade, interoperabilidade, segurança, durability e um mundo a parte de configurações e oportunidades de uso. Enfim, muito robusto, porém complexo.
Se você quer um bom overview sobre WCF | https://docs.microsoft.com/pt-br/dotnet/framework/wcf/whats-wcf
WCF chega ao .NET em Novembro de 2006. Sim, 14 anos atrás. E muitos projetos contam com WCF rodando em produção até hoje. O problema é que WCF tende a morrer de inanição, junto com o .NET Framework. Já que não temos uma implementação de hosting no .NET Core.
Vale lembrar que esse texto é escrito dia 30/01/2020 e como sabemos, tudo pode mudar. Mas de fato, até hoje não há nenhuma implementação oficial de hosting WCF, apenas consumo que sinceramente, não sei como está.
Enquanto a recomendação direta ao uso de ASP.NET Core Web API’s e gRPC. Eu já abordei gRPC diversas oportunidades e posts aqui e nesse post abordo outra alternativa.
https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/
WCF Contract Packages
Se assim como eu, você está familiarizado com WCF, é possível que você esteja usando Contract Packages. É simples, mas poderoso. Consiste em não usar Service References (geradas geralmente pelo Visual Studio) e em vez disso utilizar assemblies .NET que possuem somente os contratos dos serviços. São DTO’s e Interfaces:
Os contratos dos serviços.
Há alguns vários benefícios, mas o principal, e talvez isso possa te motivar mais, é que esses assemblies podem virar pacotes Nuget.
Se podem virar pacotes nuget, manter atualizado e notar que uma mudança ocorreu é algo substancialmente mais simples do que:
- Abrir o projeto
- Achar cada referência
- Clicar com botão direito
- Pedir para regerar o proxy
Aliás, para fazer update de uma nova versão da service reference, você precisa de um serviço UP and Running.
Pacotes de Contrato:
- Produz menos artefatos
- Mais fácil de rastrear
- Menor dependência da IDE
- Podem virar pacotes nuget
- Pode seguir o fluxo de update de dependências comuns.
- Se configurado corretamente, um simples dotnet restore que pegue a versão mais recente que tenha break changes acusa erros no build. Isso pode ser automatizado.
- Estando na mesma solution (serviço e seu consumidor)
- Atualização é automática.
- Divergências são identificadas no build, junto com a construção do serviço.
Esses são alguns argumentos. E sim, você quer falhar o quanto antes, para poder corrigir o quanto antes.
Se você quer saber mais sobre Contract Packages, sugiro o post:
O uso das interfaces
Interface Segregation é um dos princípios do SOLID. Para ser mais exato é o I do SOLID. E é um conceito que se bem empregado, faz você economizar muito, mas muito tempo nesse tipo de refactoring. Claro que em 2006 você não imaginaria que estaria migrando um WCF em 2020, mas se tivesse pensado exclusivamente pela perspectiva do SOLID: teria sim usado as interfaces.
Se você sim, produziu seus serviços usando as interfaces e as reaproveitou no client eu te encorajo a tentar mandar um presente pra o teu EU do passado! Ele merece no mínimo um tapinha nas costas e um “Well done”!
De fato, nessas horas sinto muita falta das interfaces nos projetos que não fazem uso dela.
E olha que sequer sou radical ao ponto de aplicar Interface Segregation em tudo. Mas definitivamente se há um lugar que merece, são nos serviços.
Regra que uso para Interface Segregation:
- Julguem-me. Eu não aplico Interface Segragation em tudo.
- Se vislumbro que uma classe, pode, por ventura ter uma segunda implementação. Com certeza terá sua interface de contrato.
- Se extensibilidade é um fundamental para uma tarefa as dependências que são extensíveis em geral tem interfaces.
- Elementos da minha modelagem podem ser simplificados em uma generalização? Então provavelmente posso produzir também uma interface para eles (se terão uma classe base ou não, é outro assunto e tem a ver com a modelagem e o problema).
- É um serviço (boundary do meu contexto de negócio)?
- É um ponto de extensibilidade para o meu contexto de negócio ou arquitetura?
Talvez essa lista cresça com a lembrança de novos elementos, mas em geral são esses os pontos.
Aliás, para consumir um serviço WCF, você só precisa de 2 linhas de código em C# (que dá para simplificar em 1 só)
public static class Factory
{
public static T Create<T>()
{
var channelFactory = new ChannelFactory<T>("tcp");
return channelFactory.CreateChannel();
}
}
Link para o arquivo | https://github.com/luizcarlosfaria/WcfRefactoring/blob/master/WcfRefactoring.NetFrameworkClient/Factory.cs
Já ia me esquecendo de dizer isso: Acho que fui infeliz com o nome Factory. Ficaria melhor WCFClientFactory ou simplesmente ServiceFactory.
WCF Hosting – Service Host vs SVC no IIS
Enquanto o caminho natural é você olhar a documentação Microsoft, produzir SVC’s no IIS e depois de algum tempo descobrir formas mais eficientes de hospedagem, como o uso do System.ServiceModel.ServiceHost. Eu fiquei sabendo de uma transformação em 2019 no caminho inverso!
Usar o service host te dá total controle sobre o ciclo de vida do serviço, deixando de lado as automações do IIS. Em vez disso você sabe quando está rodando e o que está rodando. Sem recycle do IIS.
Aqui vai uma dica importante:
Se por acaso você usar alguma estratégia que consista em adicionar o serviço como Windows Service ou algo assim. Sua única preocupação durante o upgrade, é garantir que o processo de fato tenha morrido.
SE MORREU, BASTA UMA CÓPIA DE FILE SYSTEM para realizar o upgrade dos assemblies.
Nenhuma reinstalação é necessária, nada. Somente um shutdown do serviço, aguardando o fim do processo. Se o processo morreu, basta copiar novos assemblies e realizar o start novamente do serviço.
Já para hospedar nosso serviço, o código também é simples:
class Program
{
static void Main(string[] args)
{
var serviceHost = new ServiceHost(typeof(Calc));
serviceHost.Open();
Console.ReadKey();
serviceHost.Close();
}
}
Esse código é uma simplificação do código que está em https://github.com/luizcarlosfaria/WcfRefactoring/blob/master/WcfRefactoring.NetFrameworkServer/Program.cs
A criação do legado
Note que o uso dessas estratégias a respeito do WCF tem uma função, tem um propósito: Simplicidade.
Nas primeiras versões do WCF não era tão simples, mas já faz mais de 10 anos que é simples assim.
Tanto no hosting quanto no consumidor temos Web.Config/App.Config com configurações específicas na seção Service.Model. Essa é uma característica que até toleramos.
Daqui pra frente vamos falar do refactoring. A criação do legado chega ao fim. Até aqui o que fizemos foi produzir um legado, usando uma tecnologia antiga.
O hosting ASP.NET Core
O ASP.NET Core Web API nem sempre permitiu que fizéssemos o que eu demonstrei nesse exemplo, usar interfaces agnósticas para sua implementação. No passado os API Controllers precisavam lidar mais com Web. E a tendência é que isso cada vez ocorra em menor quantidade. Nesse nosso exemplo, conseguimos reaproveitar a interface AS-IS, e isso é muito poderoso.
Para facilitar o entendimento do que foi feito, aproveitei para hospedar nossa API com Docker. E por isso eu já produzi tanto serviço quanto contrato, em assemblies baseados em .NET Standard, vislumbrando seu reaproveitamento.
Já que falei sobre serviços agnósticos…
Agnostic Services
Quando eu escrevi o post Oragon Design Guide – Agnostic Services eu não estava pensando em refactoring ou nesse post que escrevo agora. Eu estava pensando nas responsabilidades de cada camada. Hoje, nós vimos a troca de WCF para HTTP, mas e se fosse WCF para Filas com RabbitMQ ou Kafka?
E pior, imagine que ao invés de fazer uma migração, simplesmente surgissem outros consumidores outras formas de exposição do mesmo serviço e o problema agora são os diversos protocolos que devemos suportar.
Embora a maioria esmagadora dos frameworks, que abstraem um pedaço grande da comunicação com um ator externo, ofereçam implementações baseadas em AOP para a interceptação do fluxo, usá-las exclusivamente representar uma falha, inclusive de segurança.
Essas implementações transversais geralmente são feitas para que nós possamos implementar tratamentos genéricos. Desde um simples try/catch a um controle mais sofisticado. O uso de AOP se dá pela capacidade de seus frameworks entregarem um modelo de injeção que casa muito bem com qualquer implementação agnóstica.
Esse é um assunto legal e abordo de forma direta e indireta em diversos posts.
Vídeo Apresentação Completa
Nesse vídeo, de quase 1 hora e 1/2, apresento de ponta-a-ponta:
- Criação do Core
- Criação do Contrato
- Criação do Server WCF .NET Framework
- Criação do Client WCF .NET Framework
- Criação do novo Backend ASP.NET Web API com Docker no Linux.
- Refatoração do Factory com a adição de AOP para
Continua…
Ainda falta detalhar outros pontos como o projeto ASP.NET Core, o reaproveitamento do core de negócio e principalmente como também usei AOP para criar um client proxy do meu serviço. Essa é uma questão incrível que pode parecer confuso na primeira vez que se tem contato, mas tua cabeça explode na primeira vez que você entende.
Se tem mta gente que não conhece o WCF, imagina fazer perguntar quem conhece COM+ RS.
Excelente artigo