fbpx
[deprecated]Oragon Architecture – Application Hosting

[deprecated]

Olá, como foi sua páscoa?

Espero que tenha sido muito boa, com muitos doces e família. Já por aqui essa páscoa teve muito doce e muito trabalho. Consegui implementar algumas mudanças no Oragon Architecture, espero que goste! Nesse post vou falar um pouco sobre o novo host de aplicações, o subsistema Application Hosting. Muita coisa mudou nessa versão, e agora não exigimos mais que use Spring.Net, embora tenha suporte prioritário.

Overview

O desenvolvimento de aplicações corporativas exige que você faça integrações, serviços e construa diversos artefatos que precisam de um EntryPoint que não estejam no IIS. Aliás, hospedar WCF no IIS já é coisa do passado, há muito tempo. A decisão pela forma como seus serviço serão publicados geralmente é tomada antes do desenvolvimento, pois implica na criação de códigos específicos para cada deploy strategy. By the way a Microsoft se propõe a ajudar criando projetos específicos para cada tipo de deploy o que atrapalha mais ainda. O resultado é aterrorizante para quem gosta de uma solução enxuta. Vários projetos destinados exclusivamente para o deploy de serviços e outros vários projetos para deploy de consoles.

Desde o início do desenvolvimento do projeto, me pré-dispus a prover abstrações necessárias para que as decisões de deploy possam ser tomadas o mais tarde possível. A BRQ e no iMusica, foram os principais clientes que usaram o Oragon Architecture assim, e o resultado é muito satisfatório. Vos apresento Oragon Architecture Application Hosting.

 

Mas qual é sua finalidade?

O projeto tem a finalidade de abstrair e assumir a responsabilidade pela hospedagem de seus serviços. Com base em configurações, toda a lógica de publicação é definida e XML, restando para o desenvolvedor que construa serviços usando o padrão Service Facade, usando as marcações de WCF (ServiceContract/OperationContract e DataContract/DataMember). Todo o resto, implementação do Console, ServiceBase, ServiceInstaller, é responsabilidade do Oragon Architecture Application Hosting.

 

Mas por onde começar?

Essa arquitetura favorece a implementação de MicroServices, descrito por Martin Fowler no artigo Micro Services. Embora não seja algo novo, é um anseio do SOA, e bem disseminado com outros nomes, ganha força com esse nome desde o início do ano.

Para entender melhor, você precisa conhecer os 3 pacotes que acompanham a solução:
oragon architecture application hosting dependences

 

Oragon.Architecture.ApplicationHosting.dll

Possui as abstrações de hospedagem Windows Services e Console e fornece os pontos de configuração para a criação das aplicações dinamicamente, implementando a base para a hospedagem de aplicações usando isolamento de escopo em AppDomains para cada aplicação hospedada. Dessa forma o gerenciamento de memória e consumo é muito mais eficiente.

Oragon.Architecture.ApplicationHosting.HostProcess.exe

Projeto Console Application que possui somente duas classes HostProcessRunner e o inicializador padrão para aplicações console, o Program, com o método main, que chama diretamente o HostProcessRunner. Toda a dependência com o Spring.Net para a inicialização da aplicação ficou a cargo desse processo. A dependência é necessária para a execução do HostProcessRunner. Movi essa classe do pacote Oragon.Architecture.ApplicationHosting para o executável para que o pacote não precisasse do Spring.Net.

Embora haja uma dependência entre o HostProcess e o Spring.Net, este não se propaga para a sua aplicação, já que a inicialização da sua aplicação se dá em um path diferente e em um domínio de aplicação diferente. O resultado é que você tem uma infra totalmente isolada para realizar a configuração de sua aplicação.

 

Conclusão

Com 2 projetos, e poucas classes, conseguimos desacoplar completamente o Oragon Architecture dos demais

É isso, resolvi quebrar o post em 2, para que no próximo possa falar exclusivamente de um exemplo real.

Grande abraço e obrigado pela leitura!

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.