As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Serviços web ASP.NET baseados em SOAP (ASMX)
Quando você moderniza um serviço web ASP.NET legado (ASMX) para uma API REST ativadaAWS, ele pode ter consumidores dependentes que não podem, e provavelmente não deveriam, devido aos riscos associados, ser atualizados ao mesmo tempo. A ilustração a seguir mostra um serviço web ASMX que tem três consumidores dependentes.
Como esses consumidores chamam o serviço ASMX usando o protocolo SOAP, substituir o serviço ASMX por uma API REST faria com que esses consumidores falhassem. Além disso, refatorar o serviço ASMX em uma API REST enquanto você converte o sistema de uma arquitetura monolítica em microsserviços provavelmente envolverá a remodelação do comportamento do sistema e do modelo de domínio. É provável que isso crie mudanças adicionais significativas para os consumidores.
Para manter a compatibilidade com versões anteriores do serviço antigo para que o sistema possa ser modernizado de forma incremental, você pode implementar a orientação da abordagem do estrangulador fig. Na abordagem do estrangulador, os riscos associados à modernização de um importante sistema legado são, em parte, gerenciados substituindo gradualmente o sistema legado por um novo.
Branch by abstraction é outra abordagem introduzida por Martin Fowler que é uma técnica eficaz para implementar o padrão de figo estrangulador. Assim como na abordagem do estrangulador, o branch by abstraction ajuda os engenheiros a fazer mudanças incrementais e graduais nos sistemas quando as principais funcionalidades precisam ser substituídas ou modernizadas. Nessa abordagem, uma camada de abstração é introduzida entre o código que implementa uma funcionalidade específica e o código que consome essa funcionalidade (ou seja, o código do cliente). Essa camada de abstração não precisa ser um tipo abstrato que possa ser herdado por classes concretas. Em vez disso, pode ser qualquer implementação que capture o contrato funcional entre o consumidor e o fornecedor.
No caso de serviços web ASP.NET legados baseados em SOAP, você pode permitir a migração gradual de consumidores de serviços antigos para novos mantendo a compatibilidade, por meio de uma abordagem inspirada na técnica de ramificação por abstração. No entanto, a abordagem para serviços web ASP.NET baseados em SOAP usa delegação em vez de herança. A compatibilidade com os consumidores do ASMX é obtida por meio da refatoração do serviço ASMX legado para delegar sua implementação à nova API REST. A ilustração a seguir mostra o serviço ASMX legado que está delegando sua implementação à nova API REST. Essa delegação permite que o consumidor de serviço 3 atualize para a nova API REST, enquanto os consumidores de serviços 1 e 2 são atualizados de forma independente.
A natureza da refatoração do serviço ASMX depende dos requisitos funcionais e não funcionais (multifuncionais) desse serviço. Em alguns casos, a refatoração pode envolver a tradução dos mecanismos de autenticação e autorização antigos para os novos, transformar a carga útil do serviço ASMX de XML para JSON e, em seguida, invocar a API REST com a carga útil transformada. Em cenários mais complexos, o serviço ASMX refatorado pode precisar orquestrar chamadas para várias APIs REST e manter o estado.
O processo de migração dos consumidores de serviços do antigo serviço ASMX para a API REST modernizada continua de forma incremental até que todos os consumidores de serviços tenham sido atualizados para fazer referência à nova API. A ilustração a seguir mostra o estado totalmente modernizado, em que todos os consumidores de serviços fazem referência à API REST, e o serviço ASMX foi desativado porque não é mais necessário.
Arquitetura de exemplo
A arquitetura de estado final do serviço ASMX baseado em SOAP mostra todos os consumidores de serviços usando a API REST modernizada, levando ao descomissionamento do serviço web ASMX legado. No entanto, o foco desse padrão não é a arquitetura do estado final, mas a arquitetura provisória necessária durante a migração, enquanto os consumidores estão sendo atualizados. Esse estado provisório está ilustrado no diagrama a seguir Nessa arquitetura provisória, os consumidores de serviços 1 e 2 ainda estão usando o serviço ASMX legado, que foi refatorado para delegar sua implementação à API REST modernizada. O serviço refatorado do Windows é implantado como um contêiner do Windows no Amazon ECS, configurado em três zonas de disponibilidade para alta disponibilidade e acessado por meio de um Application Load Balancer. O Service Consumer 3 foi atualizado para usar a nova API REST diretamente por meio do API Gateway.
