Partager via


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.

Comments

  • Anonymous
    April 21, 2008
    The comment has been removed

  • Anonymous
    April 23, 2008
    Bom d+!!! Uma visão geral do que usar em cada uma das camadas de acordo com o que temos de mais novo. Acrescentaria apenas, na camada de apresentação, a opção de utilização de Smart Clients utilizando ou não WPF (não podemos esquecer que a camada de apresentação não precisa ser apenas ASPX). Antigamente, o principal problema do Smart Client era a distribuição de uma nova versão quando a tela era atualizada agora, com o ClickOnce este problema pode ser facilmente resolvido e acho que vale a pena considerar esta alternativa para alguns cenários. Além disso, na minha opinião, o desenvolvimento de Windows Forms é muito mais rápido e fácil do que Web Forms.

  • Anonymous
    April 23, 2008
    Olá Marcondes, tudo certo? Obrigado pelos comentários! Com certeza, o assunto tem sido uma constante em algumas empresas, que questionm quais são as alternativas de tecnologias e o roadmap de evolução para uma plataforma WinDNA. E o cenário de serviços WCF hosteados no WAS sobre o Windows Server 2008 precisa ser avaliado nesse contexto. Ainda, um outro post que fala um pouco mais de WAS é este aqui: Windows Process Activation Service (WAS) - Um mecanismo de ativação de processos e serviços. Ref.: http://blogs.msdn.com/wcamb/archive/2008/04/10/windows-process-activation-service-was-um-mecanismo-de-ativa-o-de-processos-e-servi-os.aspx Grande Abraço! Waldemir.

  • Anonymous
    April 23, 2008
    Olá Fábio, tudo certo? Obrigado pelos comentários também! Sem dúvida, como a idéia era uma primeira visão de cenário, não havia falado sobre o SmartClient. Mas com certeza é uma opção sim. E pensar em fábricas de software é mais do que pertinente. Veja que tanto para a construção da interface da aplicação, através da SmartClient Software Factory, como para a construção de serviços WCF, através da Service Factory, o ganho de produtividade e padronização no desenvolvimento de software será grande. E falando sobre isso, fechamos o leque de tecnologias que temos hoje disponíveis para a construção de nossas arquiteturas. Além das várias opções de frameworks, bibliotecas, templates, visões para 3 e 4 camadas e também estratégias de evolução de tecnologias mais antigas, precisamos pensar no modelo de desenvolvimento que melhor adere a nossa tripla recurso-tempo-custo disponível para o projeto. O uso de fábricas de software e guias de automação para essa padronização e produtividade na geração de código sem dúvida é uma discussão importante, seja para a camada de apresentação, para workflow, para serviços ou para a camada de persistência e acesso a dados. Abraço! Waldemir.

  • Anonymous
    May 29, 2008
    Olá pessoal, tudo certo? Em posts anteriores, falamos um pouco sobre a evolução da arquitetua WinDNA

  • Anonymous
    October 23, 2008
    Como fica o ADO.Net Data Service, ele substitui de alguma forma o uso do WCF? Em quais casos será melhor utilizá-lo?

  • Anonymous
    October 23, 2008
    Olá Lobo, O ADO.NET Data Services é apenas uma interface REST para um banco de dados local ou no enterprise, que será navegado por uma aplicação Web, por exemplo. O WCF - Windows Communication Foundation - é um framework completo para as questões de comunicação entre sistemas e processos. Até o .NET 2.0, você tinha diversos mecanismos de comunicação independentes, como .NET Remoting, Pipe, MSMQ, Web Services, HTTP, etc. O WCF veio para unificar esses vários mecanismos num único modelo de programação. Desse modo, não existe overlap entre as duas tecnologias. Você até poderia construir um serviço em WCF que implementa a mesma funcionalidade do Data Services, mas agora não precisa mais... :) Veja mais detalhes nos posts sob o TAG [WCF] aqui no blog: http://blogs.msdn.com/wcamb/archive/tags/WCF/default.aspx ...e ainda, um pouco sobre cenários com WCF: http://blogs.msdn.com/wcamb/archive/tags/Cen_26002300_225_3B00_rios+de+servi_26002300_231_3B00_os+WCF/default.aspx Um abraço! Waldemir.