Arquitetura de serviços e capacidades de SOA na plataforma Microsoft.
Olá pessoal, tudo certo?
Esses dias estive em algumas discussões sobre os vários serviços de uma arquitetura de referência SOA e como podemos mapear os produtos e recursos da plataforma Microsoft. A importância dessa discussão é enorme: seja qual for o fornecedor de sua plataforma, é importante o mapeamento correto de recursos e funcionalidades disponíveis, que irão atender as necessidades de sua solução, respeitando o SLA esperado pelo negócio.
Como o assunto é orientação a serviços, vamos fazer uma rápida revisão. Uma definição simples sobre SOA pode ser:
"um estilo de arquitetura onde funcionalidades de aplicações de negócio existentes (LoB - Line of Business) são disponibilizadas e publicadas na forma de serviços".
Muito bem! E o que seria serviço? Podemos citar uma rápida definição para ele também:
"são componentes de software que expõem funcionalidades de aplicações numa arquitetura SOA, respeitando algumas características importantes:
- serviços são autônomos;
- serviços são orientados a mensagens;
- serviços podem suportar diferentes protocolos e mecanismos de transporte;
- serviços podem ser publicados ou hosteados em diferentes tipos de hosts;
- serviços suportam contratos de operação, interfaces e tipos de mensagens;"
Respeitando as características acima, nossa solução caminha para um modelo de arquitetura desacoplada entre cliente e serviço, criando um ambiente propício para o reuso de funcionalidades, assim como a composição de funcionalidades em uma dada aplicação. Esses são elementos essenciais de uma arquitetura de serviços ou SOA.
Veja que não falei nada sobre granularidade de serviços, governança de serviços, versionamento de interface e mensagens, administração e deployment, controle de exceções, roteamento de mensagens, rastreabilidade, monitoração, controle de níveis de serviços, etc. Portanto, a discussão sobre SOA é muito maior e pode ter abordagens diversas, algumas mais técnicas, outras mais de negócio. Estou focando a visão técnica.
A partir dos pontos acima, vejamos um mapa de serviços geral de uma arquitetura SOA:
A figura acima destaca serviços comuns de uma arquitetura SOA, como serviços de apresentação, colaboração, integração entre sistemas, persistência de dados, serviços de orquestração de processos, entre outros. Podemos tratar esses vários serviços como capacidades de SOA. Na verdade, avaliando capacidades de serviços, podemos identificar quais são os aspectos que realmente precisamos para o sucesso de nossa solução. Existem cenários onde segurança e monitoração de serviços é crítico, assim como a orquestração de processo. Para outros cenários, a capacidade mais importante é integrar diferentes plataformas e ambientes de linhas de negócio, que estarão envolvidos na arquitetura SOA. Avaliar quais são as principais capacidades que precisamos é fundamental para a condução de um projeto de SOA.
Com base nesse desenho, vejamos quais produtos de uma infra-estrutura Microsoft atendem quais capacidades de serviços:
Vemos então que alguns produtos podem atender capacidades específicas, assim como várias capacidades ao mesmo tempo. É o caso do WF - Windows Workflow Foundation, que pode ser usado tanto para a construção de serviços de interação entre sistemas como para orquestração de processo. Da mesma forma o BizTalk Server oferece capacidades de integração, assim como de processos e orquestração de serviços.
A conclusão é que não teremos um único produto ou infra-estrutura de software que irá implementar toda a visão de SOA.
Uma orientação a serviços é formada por diferentes capacidades. Identificar quais capacidades são importantes para nosso cenário de negócio é tão crítico para o projeto quanto a própria escolha do fornecedor ou infra-estrutura de software que será adotada.
Por enquannto é só! Até o próximo post :)
Waldemir.