AppFabric in a Box : Uma visão sobre soluções baseadas em serviços

Olá pessoal, tudo certo?

Como primeiro post da série AppFabric in a Box, vamos rever uma arquitetura de aplicação orientada a serviços, o que muitos arquitetos chamam de LITTLE SOA, ou SOA no escopo da aplicação. O desenho a seguir ilustra esse tipo de composição:

A figura acima mostra 3 camadas simples de uma aplicação:

• O Front-End, onde interfaces clientes Web, Desktop e Mobile oferecem uma porta de entrada para dados e respostas para o usuário. Independente do modelo rico no desktop ou rico no browser, através de aplicações RIA – Rich Internet Applications, temos uma separação clara entre as funcionalidades de navegação mais interação do usuário com as camadas internas da aplicação, responsáveis pela lógica da aplicação e acesso a dados. 
• Vemos ainda uma camada Middle-Tier, que oferece funcionalidades como o hosting da lógica de navegação, tarefas executada no server-side ou mesmo consolidação de chamadas para outros serviços externos da solução.
• Finalmente, a camada Back-End, que oferece os serviços de negócio, acesso ao modelo de dados e lógica da aplicação.

Se você concorda com essa divisão exemplo, podemos focar a partir de agora somente os serviços no Back-End, onde podemos reconhecer dois tipos básicos:

• Serviços implementados via WCF com acesso via SOAP
• Serviços implementados via WF e exportados com interfaces WCF.

O desenho abaixo ilustra esse ambiente, veja:

Vemos acima que para serviços implementados via WCF – Windows Communication Foundation, definimos seus métodos e funcionalidades através de codificação, utilizando um modelo de programação bem definido, com suporte para diversos tipos de comportamentos, como transação, multi-threading, isolamento, criptografia, etc. Ainda, para um serviço WCF podemos definir contratos de serviços e contratos de dados, o que permite controle sobre o versionamento dos serviços disponíveis no Back-End da aplicação. Um desenho geral de serviço WCF é visto abaixo:

Finalmente, vemos também que serviços podem ser implementados visualmente através do WF – Windows Workflow Foundation. A grande vantagem desse modelo de programação está na legibilidade de código, além de suporte para processo de longa duração e um modelo de serviços baseado em tarefas que podem ser compostas de facilmente. Um desenho geral de serviço Workflow é visto a seguir:

Uma pergunta que surge com frequência é: quando devo optar por um serviços WCF puro e quando deve usar um serviço WF com interface WCF? Uma resposta simples seria:

Utilize um serviço WCF WORKFLOW SERVICES somente se você identifica a necessidade de processos de longa duração, ou seja, processos que serão persistidos por algum tempo, sendo descarregados da memória para mais tarde serem carregados novamente a partir de um determinado evento. Além do aspecto de persistência de longa duração, se legibilidade de código e desenvolvimento visual forem requisitos desejados, WCF WORKFLOW SERVICES é a melhor escolha. Acrescente ainda o comportamento como máquina de estado, flowchart, suporte para eventos capturados em paralelo (como lista de aprovações, retorno de emails, etc), coordenação de tarefas, etc. ou seja, cenários comuns de aplicações orientadas a workflows.

Para todos os demais cenários sem aspectos de workflow como descritos acima, utilize serviços com WCF SOAP SERVICES simples. Claro, SOAP é uma escolha interessante como Binding de comunicação para cenários inter-redes ou que atravessam Firewalls existentes, pois estamos falando de uma porta 80 conhecida, porém ainda estamos trafegando dados em XML sobre SOAP. Para soluções que exigem melhor desempenho, escolha Bindinds binários e compactos, como netTCP, NamedPipe, etc, assim como bindings voltados para mensageria como MSMQ, quando comunicação assíncrona for um requisito.

Importante notar que com serviços WCF SOAP SERVICES, temos uma interface codificada em .NET, sem os aspectos visuais de programação que temos usando o WF framework. Isso oferece maior controle sobre a codificação, mas também exigirá maior codificação.

Finalmente, novos protocolos e cenários de serviços estão se tornando populares como WCF DATA SERVICES, onde a interface de entrega é via protocolos ODATA e REST. Esse tipo de cenário também é interessante e podemos adicioná-lo como alternativa quando nossa aplicação deseja oferecer uma interface para consumo de dados mais legível pela Web.

Para saber mais sobre WCF DATA SERVICES, veja uma bela introdução feita no blog do Luciano Lima:

WCF Data Service
Ref.: https://www.lucianolima.com.br/post/2010/06/23/WCF-Data-Service.aspx

Ainda sobre WCF, confira os posts do Israel Aece

WCF
Ref.: https://www.israelaece.com/category/WCF.aspx

Finalmente, o especialista Rafael Godinho tem falado bastante sobre serviços com workflow services, veja:

Workflow Services
Ref.: https://blogs.msdn.com/b/rafaelgodinho/

Finalmente, veja um template para serviços WCF Data Services sobre AppFabric. Vamos falar mais disto em breve:

AppFabric WCF Data Services
Ref.: https://code.msdn.microsoft.com/afWCFDataService/Release/ProjectReleases.aspx?ReleaseId=4973

No próximo post, vamos avançar nos aspectos de administração e monitoração de serviços do Back-End sobre o Windows Server AppFabric. Por enquanto é só! Até o próximo post :)

Waldemir.