Do Windows DNA para o mundo orientado a serviços : uma proposta para estudo.

Olá pessoal, tudo certo?

No último post, começamos nosso papo sobre evolução de uma arquitetura WinDNA para uma plataforma mais atual. Vimos que antes de tudo, precisamos ter uma visão clara sobre os cenários envolvidos, assim como conhecer as novas tecnologias oferecidas pelo mercado. Nesse aspecto, novos frameworks estão disponíveis na plataforma Microsoft e cabe a nós, arquitetos, conhecê-los e exercitá-los, afim de melhor decidir sobre cada alternativa de evolução para nossas aplicações.

Considerando a disposição de componentes na plataforma WinDNA, podemos estudar uma alternativa de solução, conforme a figura a seguir:

image

Camada de apresentação : ASP.NET com Microsoft AJAX versão 1.0 e Silverlight 2.0.

Para uma aplicação tipicamente Web, a construção de uma interface rica (RIA - Rich Internet Application), que traga as funcionalidades e recursos da Web 2.0 é recomendável. E sobre recursos pensamos não somente em wikis, fóruns, webparts, controles gráficos, streaming, etc, mas também em novas abordagens de apresentação e UX - User Experience. Pensando ainda na composição de serviços e workflows, conceitos de aplicações compostas ou mashups também é uma capacidade que deve ser avaliada para nossa arquitetura.

Nesse ponto, a infra-estrutura ASP.NET com AJAX e Silverlight 2.0 oferece essa gama de recursos para a construção de interfaces poderosas em .NET. Claro, devemos avaliar qual a aderência de nossa aplicação para todas essas inovações. Mas os novos recursos de administração do IIS 7.0 devem ser avaliados, independente do grau de ousadia de nossa nova interface. O IIS 7.0 seria nossa infra-estrutura de suporte às páginas e requisições HTTP/HTTPS, etc. sobre o Windows Server 2008.

Para saber mais sobre o IIS 7.0 e esses recursos, não deixe de ver a série especial sobre o produto no blog do Danilo Bordini, onde temos:

  • IIS 7.0 (Internet Information Services): Parte 7: Delegação
  • IIS 7.0 (Internet Information Services): Parte 6: Configuração
  • IIS 7.0 (Internet Information Services): Parte 5: Extensibilidade
  • IIS 7.0 (Internet Information Services): Parte 4: Segurança
  • IIS 7.0 (Internet Information Services): Parte 3: Pilares
  • IIS 7.0 (Internet Information Services): Parte 2: Evolução da Plataforma
  • Série Especial - IIS 7.0 (Internet Information Services)

Ref.: https://blogs.technet.com/dbordini/archive/tags/Internet+Information+Services+_2800_IIS_2900_/default.aspx 

e para saber mais sobre o Silverlight 2.0 e o AJAX 1.0, veja os links:

Ref.: https://silverlight.net/

Ref.: https://www.asp.net/ajax/

E sempre é bom acompanhar como está a evolução do modelo ASP.NET MVC Framework, ainda em Preview 2 (Model-View-Controller). Veja aqui:

Ref.: https://www.microsoft.com/downloads/details.aspx?FamilyID=38CC4CF1-773A-47E1-8125-BA3369BF54A3&displaylang=en

Camada de colaboração de processos : Windows Workflow Foundation (.NET 3.5)

Em alguns cenários, podemos pensar na implementação de processos de negócio através de fluxos de controle ou mesmo máquinas de estado. Quando falamos em fluxos de controle (ou workflows), pensamos num cenário onde a execução de atividades é sequencial, a partir de eventos que são tratados numa ordem esperada. Temos uma atividade inicial e uma atividade final bem definida. Quando falamos em máquinas de estado, a execução das atividades é orientada por eventos, que podem ocorrer numa ordem aleatória. Assim, nosso desenvolvimento é baseado no estado corrente, com transições por eventos, sendo mais flexível para mudanças externas.

A implementação de um processo de negócio através de um workflow ou máquina de estados pode ser feita através do WF - Windows Workflow Foundation. Como vimos em posts anteriores, podemos ainda integrar esses processos com serviços do WCF - Windows Communication Foundation, ou ainda outros processos de negócio.

Finalmente, lembre-se que um processo pode ter interação humana para aprovações ou submissões, o que pode caracterizar execuções de longa duração. A interação de serviços ou outras camadas com esse tipo de processo precisa ser bem pensada e sinalizada para toda a arquitetura.

Algumas perguntas: Quais são os processo de longa duração e de curta duração presentes em nossa arquitetura? Podemos implementar parte da lógica e regras de negócio em processos com WF?

Para saber mais sobre WF e processos, veja:

Ref.: https://msdn2.microsoft.com/en-us/netframework/aa663322.aspx

Camada de serviços e negócicos : Windows Communication Foundation e serviços hosteados no WAS - Windows Process Activation Service

Surge então a discussão sobre a camada de serviços. O que é mesmo um serviço? :)

Podemos pensar na implementação de classes de negócio, com suas business entities e business process, utilizando a infra-estrutura do WCF para sua exportação e publicação de interfaces. Quando surge o WCF em nossa arquitetura, precisamos discutir alguns pontos importantes:

Qual será o template de serviço que usaremos? Nesse template, precisamos considerar o tratamento de exceção, a propagação de mensagens de erro, exportação de contadores de performance, e também aspectos de comportamento do serviço, contrato de dados, suporte transacional, mensagens tratadas, etc.

Qual será o transporte tratado pelo serviço? A definição do binding (para nosso endpoint) é tão importante quanto a definição do próprio serviço. Através do binding correto, garantimos a melhor performance para a interação entre camadas, processos e serviços.

Qual será o host para execução de serviços? Aqui, surge o WAS, já comentado em posts anteriores. Veja:

Windows Process Activation Service (WAS) - Um mecanismo de ativação de processos e serviços.
Ref.: https://blogs.msdn.com/wcamb/archive/2008/04/10/windows-process-activation-service-was-um-mecanismo-de-ativa-o-de-processos-e-servi-os.aspx

A importância da definição do host está associada ao processo de execução, mas também de administração, governança, distribuição e monitoração dos serviços em nossa arquitetura. Sem dúvida, cuidado muito especial é exigido.

Camada de negócio e aplicações LOB : COM+ 1.5 e MSDTC

Um ponto importante nessa arquitetura para estudo é que ainda podemos conviver com componente publicados no COM+, isto é, componentes COM que estão hosteados no Component Services  (veja comexp.msc) e ainda aproveitam o MSDTC - Distributed Transaction Coordinator para o suporte transacional. Esses componente podem e devem permanecer em nossa arquitetura. Isso significa que é possível conviver com esse legado, seja através de camadas de interoperabilidade (interop .NET) ou simplemente consumindo esses componentes através de Web Services. Para alguns casos, teremos traduções entre ambiente gerenciado .NET e não-gerenciado, o que deve causar um certo delay, que deve ser avaliado.

A questão sempre será sobre a viabilidade (de custo, recursos e tempo) para a migração desses componentes (COM+ WinDNA) para .NET.

Camada de acesso a dados e LOB : bancos de dados legado e aplicações LOB

E para o acesso aos dados temos algumas alternativas, como:

  • ADO.NET 2.0, quando usamos o .NET 2.0 e seus recursos como Dataset, DataReader, Datatable, DataAdapter, DbConnection, DbCommand, etc.;
  • LINQ TO SQL, quando usamos .NET 3.5 e estamos falando com servidores da família SQL Server;
  • LINQ TO ENTITY, quando usamos ADO.NET Entity Framework (ainda em Beta 3), para falar com outros servidores de bancos de dados, através do providers oferecidos no mercado.

Já falamos sobre LINQ e Entity Framework em alguns posts anteriores, veja aqui:

Ref.: https://blogs.msdn.com/wcamb/archive/tags/LINQ/default.aspx

A decisão entre as tecnologias de acesso a dados e camadas de persistência acima vai depender da orientação do projeto, entre a especialização para um middleware de alto desempenho, focado num único banco, ou um middleware de abstração e mapeamento, que permitirá trocas futuras de bancos de dados sem impacto na aplicação, porém, com um custo de mapeamento de traduções que deve ser avaliado quanto a performance.

Mais uma vez, é importante lembrar que cada caso é um caso, sempre!

A estrutura em camadas acima foi colocada apenas como pretexto para a discussão dos frameworks e tecnologias disponíveis. Caberá a cada equipe de arquitetura avaliar internamente a aderência às suas próprias aplicações.

Porém, tenha em mente que sua nova plataforma precisa estar antenada com as tendências de colaboração e integração de Software + Serviços que temos observado.

Construir preparado para a mudança, já que tudo se move, tudo flui, é uma prática cada vez mais desejada, já dizia Heráclito de Éfeso, uns 500 a.C. :) Panta hrei!

Por enquanto é só! Até o próximo post :)

Waldemir.