[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.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!