Aquele blog de SOA

O que é “SOA Enabled” e o que é “SOA Based” ?

Bom, para pensar em situações aplicadas, vamos falar rapidamente sobre integração. A necessidade de usar SOA para facilitar a integração de sistemas tem se destacado e usa bastante estes conceitos (based e enabled), facilitando a vida de fornecedores e evoluindo a forma das aplicações conversarem.

Sempre que visitamos uma empresa que trabalha com linha de produtos, vejo que um dos nortes das preocupações é evoluir a maturidade de integração com outros produtos e pacotes! A necessidade de integração existe não é de hoje, a diferença é que não estamos mais querendo disponibilizar “aquela view no oracle” para que um sistema converse com o outro. Alguns clientes apresentam, inclusive, restrições técnicas para estas conversas através de Banco de Dados.

Fornecedores vêm se movendo, criando camadas e mais camadas nos seus produtos, para que a integração seja através de serviços. Não é viável reimplementar o produto, não agora! Então, o que eu estou fazendo? Gambiarra ou SOA? Para que especialistas possam responder esta questão sem se comprometer , surgiu até o conceito de SOA Enabled e SOA Based!

• SOA Enabled: O núcleo da aplicação é o mesmo, mas inserimos uma ou duas camadas de abstração, para publicar algumas funcionalidades como serviços. Muitas vezes, os problemas arquiteturais persistem! Mas, agora a integração é mais bonita e posso falar que disponibilizo serviços. Ok, tudo bem que os serviços surgem por demanda (feio né?!), mas tenho visto esta abordagem ser positivamente aplicada em diferentes empresas. É importante usar um processo de reengenharia e identificação de serviços legados, sendo possivel descobrir e criar serviços totalmente alinhados às necessidades de negócio, mesmo tendo que abrir mão de algumas características técnicas que vão continuar rodando por baixo dos panos.
• SOA Based: A aplicação é feita tendo a Arquitetura “Orientada a Serviços” (bingo!). Ou seja, os serviços não vão surgir depois, eles são identificados no início do projeto, através de um processo de identificação de serviços que orienta o design arquitetural. Show de bola! Mas, é necessário que seja uma nova aplicação ou um refactoring arquitetural (talvez até traumático) para conseguirmos aplicar SOA Based efetivamente. Uma grande vantagem é que, descobrindo os serviços logo no início do projeto, potencializamos o poder de reúso sem precisar criar serviços genéricos e a arquitetura é voltada para estes serviços identificados.

Três considerações antes da conclusão:

1. Primeiro: Bom mesmo seria se só existisse SOA Based.
2. Segundo: SOA enabled não é, obrigatoriamente, uma má prática! Mas a Arquitetura não foi Orientada a Serviços.
3. Terceiro: O que as duas abordagens têm em comum? Para ambas, é necessário estabelecer um processo de identificação de serviços! Que esteja alinhado às demandas de negócio. E o processo vai rodar para criar uma nova aplicação, ou para descobrir serviços em produtos existentes. A abordagem deve ser top-down! Não estarei apenas “disponibilizando alguns web services”, o que é bastante comum.

Enfim, para SOA based e SOA enabled, o mais importante é que surjam serviços de negócio disponibilizados no produto, que possam ser evoluídos, integrados, reutilizados, rastreados e, inclusive, governandos e monitorados em runtime.

Ou seja, não esqueçamos da governança dos serviços. Para garantir diversas diretrizes SOA, como desacoplamento, seria necessário sujar as mãos. Mas cá entre nós, mesmo sem isso, os benefícios de utilização de serviços de negócio para tornar meu produto SOA Enabled são reais.

[]s
Marcilio