Aquele blog de SOA

Em um post relativamente antigo do ZapThink [1], o autor, Ronald Schmelzer, fala sobre desacoplamento de serviços, e esclarece alguns mitos e problemas. Talvez o conceito mais interessante do artigo (cuja leitura recomendo) seja o seguinte: muita gente acha que serviços ou são acoplados, ou são desacoplados, sem um meio-termo.

Alto acoplamento.

Acontece que na prática as coisas não são tão booleanas assim. Tal como a questão de granularidade, existe toda uma escala de acoplamento; tornar seus serviços 100% desacoplados é algo “difícil e caro, se não impossível“. O desafio então está em achar “o grau de desacoplamento que permite maior flexibilidade ao compor serviços e que não impõe um custo elevado” (eu costumo incluir “complexidade de uso” como um custo; ou seja, se a solução final tem baixíssimo acoplamento mas eu preciso passar por uma dúzia de camadas antes de obter um resultado, o custo final é elevado).

No artigo, são levantados sete aspectos de desacoplamento: uma solução pode estar bem desacoplada quanto a alguns deles, mas ainda fortemente acoplada em outros. Tomei a liberdade de resumir esses aspectos:

1. Desacoplamento de Implementação: Este é o mais básico. Todos já sabemos que um consumidor de serviço não deve conhecer os detalhes de sua implementação. Próximo!

2. Desacoplamento de Contrato: Quando a implementação muda, os consumidores não mudam, se a interface de serviço se mantiver. Mas, e quando o contrato é que muda? Segundo o autor, a forma de atacar este desacoplamento é governança. As diferentes versões de um contrato de serviço devem ser controladas e conhecidas, os impactos devem ser rastreáveis, e planos de transição devem ser elaborados. Além disso, intermediários como ESBs podem auxiliar a conter o impacto de uma mudança, transformando ou roteando chamadas a serviços antigos em chamadas a serviços novos, quando possível.

3. Desacoplamento de Service Policies (Políticas de Serviço) : O contrato rege os aspectos funcionais, enquanto as políticas regem aspectos não-funcionais, como tempo de resposta, abrangência de dados retornados, SLAs, etc. Vimos que mudanças no contrato podem afetar profundamente os consumidores; apesar de não ser óbvio, mudanças na política também. Os mesmos cuidados de governança, versionamento, e migração vistos no item 2 devem também se aplicar a variações na política de acesso aos serviços.

4. Desacoplamento de Processos: O item 1 desta lista fala que quando a implementação de um serviço muda, os consumidores não devem ser afetados. O mesmo deveria se aplicar quando um processo de negócio muda. Isto é relativamente fácil de atingir; atualmente, uma boa prática em uso é compor processos usando serviços, e depois expor este processo também como um serviço (usando BPM, por exemplo). Esta “exposição como serviço” já garante o desacoplamento 1.

5. Desacoplamento de Estrutura de Dados: A mudança de um contrato pode ser necessária por várias razões, e, pelo item 2, deve ser tratada com governança. Uma das razões pode ser alterações na estrutura de dados comunicados entre os serviços (por exemplo, um campo novo em uma entidade); como essa estrutura é comum entre os dois serviços, é um ponto de acoplamento. O que deveria ocorrer, portanto, para que uma alteração em algumas tabelas não se propagasse demais por todo o resto do sistema?

Novamente, a solução 2 entra em cena: governança das diferentes versões de serviço. Algumas outras abordagens sugeridas pelo autor são o uso de serviços específicos para acesso a dados (i.é, camada de acesso a dados, CRUD), que podem ser gerenciados independentemente dos serviços de mais alto nível que fazem uso deles.

Um bom ponto levantado é que os responsáveis pela definição das estruturas de dados (leia-se DBAs) são tão responsáveis pela iniciativa SOA quanto os arqitetos de software. Eles devem, portanto, fazer parte do time de arquitetura, e não ser um órgão separado que ajuda a arquitetura.

6. Desacoplamento de Infraestrutura: Você pode ter desacoplado muitos aspectos do seu sistema pelos pontos acima, mas se as coisas só funcionam em uma plataforma, e migrar para outra seria (para citar a terminologia em voga) “um parto“, então ainda existe um acoplamento neste aspecto. Para termos verdadeiro desacoplamento de infraestrutura, seria necessário desenvolver os serviços exclusivamente em cima de padrões estabelecidos e respeitados de fato.

Infelizmente, alguns padrões não são definidos o bastante, ou, quando são, não são suportados inteiramente por todos os vendors (ex: ESB). O que acontece é que o vendor da plataforma se torna o único fornecedor de infraestrutura, e todo o resto da organização deve rodar em cima dele. Isto pode não ser um problema real para algumas empresas, mas certamente não é desejável.

7. Desacomplamento Semântico: Esta é uma das viagens idéias mais ousadas do artigo, com a qual eu não concordo muito. De acordo com o autor, de nada adianta os desacoplamentos acima se o comportamento dos serviços precisa ser conhecido de antemão por provedores e consumidores; ele sugere que formas de definição dinâmicas dos contratos do serviço sejam ser inventadas.

Na minha humilde opinião, isto é (hoje) uma complexidade desnecessária. Tornar os serviços independentes da semântica, e criar linguagens para que uns e outros expressem seu comportamento, seria como tentar fazer que os serviços se conectassem sozinhos. Não acho necessário e nem mesmo desejável, mas admito que estou pensando apenas no futuro próximo.

No final da história, o ponto que mais prevalece, a meu ver, é a governança eficaz dos serviços de uma organização. Usar WebServices provê o primeiro grau de desacoplamento apenas; usar BPM provê o grau 4; usar um ESB ajuda nos graus 2, 3 e 5, mas pode ser um empecilho para o 6 (principalmente porque não existe um padrão real de ESB). Mas, sem um conhecimento profundo dos serviços existentes e sua história, e dos serviços futuros e em desenvolvimento, nenhuma dessas tecnologias consegue atingir seu melhor potencial.

- José Ventura

[1] Artigo original: http://www.zapthink.com/report.html?id=ZAPFLASH-20071128