Leitura Recomendada: The Fractal Nature of Web Services
Não é um artigo novo, mas vale a pena dar uma olhada (http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=4134008&isnumber=4133979&punumber=2&k2dockey=4134008@ieeejrns&query=%28fractal+%3Cin%3E+ti%29+%3Cand%3E+%282+%3Cin%3E+punumber%29&pos=0 - requer uma conta de usuário no IEEE).
Christoph Bussler, da Cisco Systems, escreveu um artigo bem interessante sobre a natureza fractal dos web services. O que ele quer dizer com isso? No atual contexto em que, para muitos, SOA é a "bala de prata" para todos os problemas de TI, Bussler discorre sobre a situação em que muitos serviços (funcionais ou não) começam a invocar uns aos outros, misturando contexto transacionais e não-transacionais, gerando o que ele chama de uma situação fractal (http://en.wikipedia.org/wiki/Fractal). Bussler faz uma boa descrição sobre a autonomia de serviços, a possibilidade de se fazer composições de aplicações de forma declarativa, levando à tão sonhada agilidade no desenvolvimento de novas soluções. Segundo ele, a uniformidade no design de serviços e de sua implementação leva a um pattern no qual "tudo deveria ser um serviço", não apenas a lógica de negócios mas também serviços não funcionais como logging, monitoração e transformação de dados.
A partir desta premissa, o artigo discorre sobre o uso dos serviços nào funcionais em um ambiente 100% SOA de uma empresa.
Em seu racional, que às vezes chega a assustar (mas não é muito fora da realidade de muitos projetos), ele analisa o que pode acontecer numa situação muito simples, quando um serviço S1 envia uma mensagem ao serviço S2, aguardando uma resposta. Num mundo simples, isso pode simplesmente corresponder à transmissão de apenas duas mensagens na infra-estrutura de TI. Porém, à medida em que o autor do artigo coloca os serviços não funcionais no panorama geral (sistemas de filas, transações, transformação de mensagens, logging e monitoração), chega-se rapidamente a um total de 14 mensagens transportadas no sistema. Uau, para um simples esquema de request-reply, há realmente um perigo oculto por aqui.
O artigo leva a um certo exagero (salutar, na minha opinião) na questão dos serviços não funcionais. Pelo menos para dois dos serviços sobre os quais ele discorre (logging e monitoração), não considero muito real a necessidade de expô-los como servíços em ambiente distribuído. Aqui, até por força da análise fria do artigo, o uso de agentes de monitoração e logging residentes nos servidores auxilia, em muito, a diminuição desta complexidade e deste efeito multiplicativo no número de mensagens que trafegam pela infra-estrutura.
Em modelos mais pé-no-chão, os serviços de logging e monitoração não são, efetivamente, serviços invocados remotamente, mas sim serviços locais à maquina que hospeda o serviço requisitante. Neste caso, não há transporte efetivo de mensagens pela infra-estrutura a cada invocação e sim o transporte de um lote de dados a intervalos regulares entre a máquina monitorada e a console (ou banco de dados) central de monitoração, muitas vezes apenas uma versão condensada ou já pré-processada de informação. O uso desses serviços em forma de invocação remota apresenta, conforme exposto adequadamente no artigo, um efeito multiplicador de tráfego além de ser um gargalo acompanhado de um calcanhar de Aquiles da infra-estrutura. Se todo serviço funcional precisar invocar um serviço não funcional como uma ativação remota, a possivel (e muitas vezes provável) indisponibilidade dos serviços não funcionais pode causar a indisponibilidade completa de todos os sistemas que participam deste meio-ambiente.
Vale a pena dar uma olhada e verificar quanto o uso inadequado de qualquer tecnologia pode se tranformar em uma boa dor de cabeça.
Atualização: erros de digitação e melhoria de frases.
Fernando Gebara Filho
