Olá pessoal, tudo certo?

Nos últimos posts, falamos de algumas arquiteturas de referência e modelos que podemos aplicar para a organização de componentes em nossas soluções.

Hoje, estive conversando sobre arquiteturas de referência e o assunto SOA retornou. Mantendo a linha dos posts anteriores, temos o desenho abaixo, que representa um modelo de 4 camadas para a orientação a serviços:

Vejamos os componentes dessa arquitetura:

• Primeiro, notamos uma camada de aplicações compostas, destinada para as interfaces de composição e consumidores de serviços e processos da solução;
• Abaixo, temos a camada de composição de negócios ou processos, onde orquestrações de negócio podem consumir serviços ou tratar regras de negócio, de acordo com as necessidades da solução;
• Na sequência, a camada de serviços atômicos ou de composição, que implementam as interfaces de serviços propriamente ditas. Baterias de Web Services ou serviços implementados com WCF e hosteados em IIS são exemplos para essa camada;
• Suportando os serviços acima, encontramos os componentes de serviços que podem ser componentes legados, exportando funcionalidades existentes de nossa infra-estrutura;
• Por último, a camada de integração ou legado, onde encontamos nossos sistemas nativos, bancos de dados e solução que serão exportadas pela infra-estrutura de serviços.

Atendendo todas as camadas encontramos as bibliotecas comuns, necessárias para a manutenção, administração e operação da solução. Assim, vemos as camadas verticais do desenho, que implementam monitoração, autorização, segurança, controle de acesso, logging, etc. São bibliotecas básicas, construídas ao longo do projeto ou fornecidas por alguma ferramenta de operação de serviços. Em muitos casos, barramentos de serviços (ou ESB - Enterprise Service Bus) oferecem essas funcionalidades de forma nativa, economizando algum tempo de desenvolvimento para o projeto.

Para relembrar, podemos definir uma arquitetura SOA como sendo um estilo de arquitetura onde funcionalidades implementadas pelas aplicações existentes são disponibilizadas na forma de serviços. Serviços são componentes de software que suportam características multi-protocolo e multi-host, sendo orientados a mensagens e fornecendo um desacoplamento entre consumidores e funcionalidades da aplicação.

Finalmente, vale sempre perguntar: sua solução necessita de uma organização de serviços, com múltiplas camadas, orquestração de processos e composição de funcionalidades? ou sua solução necessita mesmo é de um middleware de alta performance? Fazer essa diferenciação é muito importante!

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

Waldemir.