System of Systems, REST, Hypermedia e HATEOAS /ou: Um dia na vida de um integrador de sistemas...

Há alguns meses fui chamado, junto com o Julio, para revisar a arquitetura da nossa plataforma de publicação e gerenciamento de conteúdo, que é responsável desde a criação de sites até a autorização de usuários e busca de conteúdo pelos editores. Resumindo (muito) a história, encontramos alguns sistemas monolíticos que represavam os requisitos de uma empresa formada por muitas unidades de negócio com necessidades variadas, muitas vezes até conflitantes. Se a lei de Conway é inevitável, tentar trapaceá-la não foi uma boa idéia. O modelo monolítico estava na nossa mira e pronto para ser derrubado.

Precisávamos de um modelo distribuído, com sistemas menores, de baixo acoplamento e alta coesão (já tinha ouvido falar que outros estavam indo nessa direção). O Julio cunhou o termo "System of Systems" e todos entenderam a idéia de uma forma geral. Um sistema que é formado por outros sistemas, onde um requisito de negócio era dissolvido em requisitos menores para sistemas menores, mas que juntos criavam a funcionalidade que o negócio esperava.

Mas isso não é um modelo de desenvolvimento baseado em componentes tão popular nos anos 90 ou um nome diferente pra Web-services? Quase. Sim, existe um trabalho de separação de interesses (separation of concerns), assim como nos componentes e em WS. Porém, diferente dos componentes ou WS, não tínhamos o protocolo comum entre os sistemas, como nos componentes distribuídos (SOAP, CORBA, DCOM, etc). Precisávamos de um protocolo que pudesse acolher nossos requisitos:

• Distribuído e descentralizador
• Escalabilidade: lidamos com milhões de requisições/dia. Escalar é preciso!
• Tolerante a falhas: não queremos deixar de mostrar uma página para o internauta só porque um dos sistemas esta fora. E sim, eles ficam fora.
• Fracamente acoplados: quanto menos souber de suas dependências e dos que dependem dele, mais utilizado e fácil de evoluir é um sistema.
• Facilidade de implementação: trabalhamos com diferentes linguagens e tecnologias. Protocolos abertos, com uma boa base de usuários e libs estáveis é essencial.
• BASE (Basically Available, Soft state, Eventually consistent): privilegiamos a disponibilidade sobre a consistência dos dados (assim como um sistema para web deve ser)
• Relacionamento entre recursos: queríamos criar uma rede de sistemas, quase caótica (do ponto de vista de governança) e sem repositório central. Pra isso, a informação sobre a relação entre recursos deveria existir no protocolo de comunicação entre os sistemas e ser entendida por qualquer sistema da plataforma.

Estávamos de olho no REST e parecia o caminho natural, mesmo com suas limitações. Sabíamos que é natural fazer CRUD com o REST, mas e o restante? Um sistema não é formado apenas por CRUD dos dados. Existem perguntas complexas que um sistema deve responder, começando por uma busca de uma palavra num texto até cálculos ou transformações de dados específicos de negócio. RPC? Talvez...

Nessa época caiu na minha mão (via @Dimas) a apresentação "REST in Practice - A Tutorial on Web-based Services", do Jim Webber, Savas Parastatidis e Ian Robinson, nomes que já tinha ouvido falar ao pesquisar sobre SOA e REST. Numa primeira visita, eu pensei que a apresentação era sobre a história das tentativas de Web-services e seus formatos para depois exaltar o quão bom o REST é. Na segunda olhada, com mais cuidado (afinal são 302 slides), me chamou a atenção o conjunto dos conceitos de REST com Hypermedia, HTTP como o protocolo de aplicação, Atom e como tudo isso deveria ser a base para uma arquitetura de um sistema distribuído. Afinal, isso tinha dado certo uma vez: a web funciona assim! Aliás, se olhar os requisitos da nossa plataforma ali em cima, vai ver que a semelhança é grande. Ou seja, parecia que eu tinha encontrado o que estava procurando.

Hypermedia é um conceito que foi citado como parte fundamental do REST no doutorado de Roy Fielding (foi neste trabalho que o termo REST apareceu), mas que foi esquecido no meio do caminho. O foco dado foi exclusivamente sobre o recurso, porém, ao esquecer o conceito de hypermedia, deixou-se de lado como conhecer e navegar nesses recursos.

Utilizar o HTTP como protocolo de aplicação e não apenas como protocolo de transporte (discussão antiga do pessoal do SOAP vs REST) já era algo que desejávamos, mas ao olhar o HTTP de perto, encontramos muito mais do que GET, POST, PUT e o DELETE. Ao entender os verbos, os códigos de retorno e os media types, tem-se um protocolo muito mais complexo e pronto para sistemas distribuídos.

E quando menos se esperava, eis que um padrão XML aparece na nossa frente: Atom. Ali no Atom é que se encontram as ferramentas para tornar o hypermedia viável entre sistemas, pois o conceito de links faz parte do padrão.

Parecia que tínhamos encontrado o que queríamos. Bom, pelo menos no campo teórico... Ao tentarmos implementar, esbarramos em alguns problemas com as libs que dão suporte a esses conceitos. Por exemplo, a especificação Atom dá suporte a uma série de features que não encontramos implementadas em nenhuma lib (Ruby ou Java) e que seriam importantes para nós. E se o HTTP é completo (e, como disse antes, complexo) ao dar suporte a sistemas distribuídos, por outro lado as libs acabam escondendo informações ou bagunçando a idéia do protocolo na tentativa de simplificá-lo.

Para nossa sorte, encontramos o Guilherme Silveira, que já estava envolvido nas discussões sobre REST, Hypermedia e HATEOAS (Hypermedia as the Engine of Application State) e estava implementando o Restfulie, uma lib que busca o REST no seu conceito original, ou seja, com os conceitos de hypermedia e transição de estado, além de ser amigável com o protocolo HTTP em toda sua complexidade.

A história ainda não terminou. Na verdade está apenas no início. Estamos começando a implementar esses conceitos nos novos sistemas, refatorando os antigos sistemas monolíticos para sistemas menores, e ainda começamos a ajudar o Guilherme na evolução do Restfulie. Temos um longo caminho pela frente na construção da nova plataforma, que vai inclusive colocar todas essas idéias a prova. Porém, mais do que nunca, acredito que estamos no caminho certo.