De volta ao básico: A Vingança

Gebara — Mon, 09 Mar 2009 19:28:12 GMT

No meu último post da série De Volta ao Básico (veja também os posts 1 , 2 , 3 e 4 ), escrevi que a federeção de identidades seria uma das tábuas de salvação para o caos das identidades e para a interoperabilidade entre plataformas. Mas, infelizmente,...(read more)

Esgotamento de recursos naturais

Gebara — Wed, 21 May 2008 15:57:16 GMT

Este deveria ser o pensamento que norteia a vontade de ser "verde". Mas parece que continua não sendo. A onda do pensamento "verde" vem do fato, sempre bem escondido para a manutenção de nosso conforto, de que...(read more)

Interoperabilidade e portabilidade

Gebara — Tue, 20 May 2008 21:43:08 GMT

Dois termos: um que está na moda (interoperabilidade) e um que já está na fase madura (portabilidade). Apesar da ordem imposta pelo título, quero falar primeiro de portabilidade, com dois de seus modelos básicos: binária...(read more)

Causa ou consequência?

Gebara — Thu, 27 Mar 2008 20:51:00 GMT

Este é um blog em homenagem à Simone Bormann e ao Rodrigo Dias , com quem estive conversando na semana passada. A Simone é responsável por divulgar em clientes nossa visão de Dynamic Systems Initiative (DSI) e como nossa linha de produtos usa esta visão...(read more)

Leitura Recomendada: The Fractal Nature of Web Services

Gebara — Thu, 20 Sep 2007 17:35:00 GMT

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

Pensando sobre Tecnologia da Informação : opinativo

De volta ao básico: A Vingança

Esgotamento de recursos naturais

Interoperabilidade e portabilidade

Causa ou consequência?

Leitura Recomendada: The Fractal Nature of Web Services