O problema

Em um projeto pessoal recente precisei fazer a integração entre três sistemas distintos, na verdade os sistemas são distintos, mas não deveriam ser. Trata-se de um site e o que ocorre é que esse mesmo site possui três módulos (sistemas) que estão em plataformas, linguagens e lugares diferentes. Conclui-se que é um projeto que foi crescendo desordenadamente e que em nenhum momento ninguém pensou em uma maneira de organizar melhor os módulos e realizar as integrações. Como esses módulos foram feitos em linguagens e plataformas diferentes, o requisito número um do cliente era que esses módulos se comunicassem e que essa comunicação fosse transparente pra ele e para quem fosse administrar o sistema.

Cenário atual

O site é um pequeno site de e-commerce e dos três módulos existentes, um diz respeito ao frontend/backend do site e é feito com .NET/SQL Server, o outro módulo é o backend de vendas e é feito com PHP/MySQL e o último módulo é o de newsletter (mailing) que também está em PHP/MySQL. O módulo de vendas foi o último a ser desenvolvido e deveria ser mantido, o problema é que o administrador do sistema precisa “inputar” todas as vendas na mão, isso mesmo, na mão! Atualmente, quando um cliente tem interesse em algum produto do site, ele envia um email ao administrador informando qual(is) o(s) produto(s) ele tem interesse e os seus dados pessoais, e por sua vez o administrador entra no módulo de vendas, cadastra esse novo cliente, cria um pedido de venda, gera um login/senha para esse cliente e envia por email para que ele possa se autenticar no módulo de venda, concluir a compra e efetuar o pagamento.

Além de ser algo totalmente mecânico e nada prático, não há nenhuma relação entre os módulos do site e o administrador precisa reproduzir os dados do produto, que já existe em um módulo, em outro. Eram esses problemas que deveriam ser remediados.

Requisitos do cliente

Um dos requisitos do cliente, era de que o site (frontend e backend) deveria ser construído novamente, pois o atual além de ter sido construído em uma plataforma que ele não tinha mais interesse em manter, também estava incompleto e apresentando problemas, portanto o primeiro requisito era refazer todo o site com PHP/MySQL.

O segundo requisito era que o processo compra de produtos deveria ser todo feito através do site, pelo cliente, e não da forma arcaica como é atualmente e que foi descrita acima.

O terceiro requisito era que o módulo de vendas deveria ser mantido, pois ele atendia o que o cliente precisava, sendo assim o sistema que eu iria desenvolver deveria alimentar diretamente esse módulo de vendas.

Estrutura do módulo de vendas

Felizmente o módulo de vendas estava construído de uma maneira que facilitou o meu trabalho, quem o desenvolveu se preocupou em criar classes de modelo, uma camada de persistência e uma camada de negócio, portanto pude pensar em uma arquitetura simples em funcional muito em função disso.

Arquitetura pensada

Tentei pensar em algo que não criasse uma dependência entre os sistemas e que me fizesse mexer o minímo possível, ou nada, no módulo de vendas que seria mantido. Outros fatores que levei em consideração era que eu queria algo fácil de implementar, de dar manutenção e que de certa forma fosse rápido de desenvolver.

Conclui o desenvolvimento do (frontend/backend) e parti para pensar em uma arquitetura que me permitisse fazer tudo o que citei acima e que além disso me permitisse utilizar a boa estrutura que eu encontrei no módulo de vendas.

Para construir o site utilizei o Code Igniter, que é um framework que tenho prática, e também é leve e rápido de desenvolver, mas o que vale ressaltar é que arquitetura é algo que é independente de framework, portanto se eu tivesse utilizado qualquer outro framework, ou até mesmo se eu não tivesse utilizado nenhum framework, não faria a mínima diferença. Nesse caso os frameworks escolhidos só entram como facilitadores na implantação da arquitetura.

Mas voltando ao foco inicial, que é explicar a arquitetura, o que eu pensei foi em criar um Web Service com as operações específicas para tudo o que eu precisaria fazer no módulo de vendas, ou seja, eu precisaria identificar todas as ações que eu precisaria realizar para fazer essa integração e alimentar esse módulo. Na verdade, além de alimentar eu também precisaria recuperar algumas informações do módulo de vendas. Como os módulos (site, vendas, newsletter) ficariam provavelmente em servidores diferentes, em bancos diferentes e em estruturas diferentes essa era a forma mais limpa de realizar a integração sem causar dependência entre esses módulos e com isso dar manutenção seria bem mais fácil.

Como já estava definido que eu iria utilizar Web Service, eu optei por utilizar o formato RESTful, pois eles se encaixava perfeitamente na minha necessidade: me trazia simplicidade, praticidade, facilidade, além do que no meu caso a aplicabilidade de ROA, que é o conceito que Web Services RESTful utilizam, era muito mais evidente do que a abordagem de serviços.

O próximo passo era identificar os recursos necessários e criar as URI que eu utilizaria nos requests do meu Web Service REST, então ficou dessa forma:

• user/new
• user/retrieve/email
• user/retrieve/cpf
• order/new
• order/save/products
• order/retrieve/last
• shipping/calculate

Para desenvolver esse Web Service RESTful resolvi utilizar o Zend Framework, pois ele possui alguns componentes que me ajudariam a desenvolver esse Web Service mais rápido, como o suporte a Web Services RESTful, por exemplo, o ZF também tem uma API para trabalhar com JSON muito boa, então esse foi outro componente do ZF que eu resolvi utilizar.

Como no módulo de vendas já existiam classes de modelo que representavam as entidades do meu domínio, o que eu fiz foi criar uma estrutura JSON semelhante as essas entidades e que representaria os requests/responses do meu Web Service RESTful. Paralelo a isso criei algumas classes de apoio que serviriam como os Marshallers e Unmarshallers do Spring. Marshallers e unmarshallers são como data mappers, e no meu caso servem para eu mapear um objeto JSON para um objeto PHP (classes modelo) e também realizar o inverso.

Dessa forma com objetos JSON convertidos para objetos PHP que representavam as minhas classes modelo eu poderia usar a camada de persistência existente na aplicação para persistir todo objeto, então no caso de salvar um novo usuário, ficou assim:

function saveUser($user) {	
	$userObject = Unmarshaller::user(Zend_Json::decode($user));	
	$conn 	    = DB::getConnectionHandler();
 
	$result 	= $conn->user->save($userObject);	
 
	if ( $result )
		return array('status' => TRUE, 'response' => 'Usuário cadastrado com sucesso.');	
	else
		return array('status' => FALSE, 'response' => $conn->ErrorMsg());	 
 
}

Bem simples, né? No exemplo acima, criei algumas classes estáticas (utilitárias), a primeira me retorna um objeto de conexão com o banco de dados e a segunda classe representa o unmarshaller para transformar um Objeto JSON em uma classe de modelo que representa um usuário, após isso foi só persistir o usuário e retornar as mensagens correspondentes para quem está acessando recurso.

Visão geral

No fluxo de salvar um novo usuário, teríamos:

1) Site (módulo site) deseja salvar um novo usuário;
2) Site monta um objeto JSON com os dados que representam o novo usuário;
3) Site acessa o Web Service RESTful do módulo de venda através do recurso user/new;
4) No módulo de venda, o método mapeado para o recurso user/new, faz unmarshaller do objeto JSON mapeando os valores desse objeto JSON para uma classe de modelo;
5) O usuário é persistido através do objeto que foi mapeado no passo anterior;
6) O Web Service RESTful retorna a mensagem correspondente para o site.

Quando se fala em arquitetura é comum pensarmos em algo complexo, cheio de tecnologias, frameworks e etc, mas o foco de arquitetura não deve ser esse, o foco de arquitetura deve ser pensar em uma estrutura que prime pela organização, relacionamento e reuso dos componentes de softwares envolvidos em um sistema, onde o intuito deve ser facilitar e não complicar.

Web Services são componentes que permitem que duas aplicações troquem informações entre si utilizando um canal de comunicação (network), na maioria das vezes o protocolo HTTP. Existem alguns tipos de Web Services, mas os mais conhecidos e usados hoje em dia são: RPC, WS-* (WSDL/SOAP) e REST.

Dos padrões citados, provavelmente o formato mais conhecido e usado hoje em dia é o WS-*, que define que um serviço deve receber/responder mensagens no formato XML (SOAP) e deve possuir um contrato que defina os seus serviços (WSDL). Só que esse formato, principalmente depois da popularização do REST, vem sofrendo pesadas críticas de toda comunidade de desenvolvimento, que alega que esse formato é burocrático e complicado, enquanto o REST é um formato mais simples e objetivo.

Minha opinião é que tanto o padrão WS-* como o padrão REST não se substituem, pelo menos não por enquanto, e que tentar fazer essa comparação ainda não agrega, pois existem casos específicos onde REST é muito bem-vindo, assim como existem casos onde o padrão WS-* é muito bem-vindo.

WS-* – Vantagens e desvantagens

Uma das principais reclamações em relação a esse formato é que o mesmo possui N especificações e que isso o torna complexo e burocrático, e de certa forma eu concordo. Só para se ter uma idéia existem mais de 15 especificações para esse formato e conhecer todas é humanamente impossível e inviável.

Outra reclamação é em relação ao overhead que a troca de mensagens de um serviço no padrão WS-* pode causar, pois todas as mensagens precisam ser envelopadas dentro de um pacote SOAP, que nada mais é que um XML padronizado. Esse overhead é causado, pois dentro de um envelope SOAP, o que é usado é a menor parte do conteúdo que está ali contido, dessa forma há muito “lixo”.

Essas duas reclamações citadas acima, são as maiores reclamações dos desenvolvedores em relação a serviços WS-*, contudo no meu modo de ver existem também muitas vantagens no uso do formato WS-*, principalmente no que diz respeito a integração entre aplicações corporativas e também em relação a SOA.

Por exemplo, eu trabalho em um ambiente onde existem muitos serviços, muitos mesmos, e esses serviços são desenvolvidos por N fornecedores, em N plataformas distintas e são usados por N por aplicações. É um cenário bem complexo e eu não imaginaria esse cenário sem o uso do formato WS-*. E por quê? Em primeiro lugar porque ter um contrato formal desses serviços é totalmente necessário, afinal eu preciso saber o nome desses serviços, preciso saber o que eles estão esperando receber, o que eles irão me responder e como serão esses dados. Imagine se um serviço desses mudar o caos que seria?

Outro fator muito importante são as ferramentas de apoio, afinal elas além de facilitar o trabalho, trazem também produtividade. Existem N ferramentas que ajudam na simulação, testes, geração de Mock’s, teste de carga, debug e tantas outras atividades necessárias no desenvolvimento/acesso a esses serviços. A principal ferramenta free usada hoje em dia é o soapUI.

Em relação a SOA, o formato WS-* também se mostra a melhor opção. SOA é uma maneira de se construir softwares baseado no conceito de serviços, onde esses serviços devem possuir um contrato formal, devem ser independentes (possuir baixo acoplamento) e devem ser reutilizáveis. Outro princípio de SOA diz que esses serviços devem ter a capacidade de serem descobertos e nesse ponto o WS-* mais uma vez sai na frente, pois o mesmo possui o protocolo UDDI, que é um método utilizado para publicar e descobrir diretórios de serviço em uma arquitetura SOA.

REST – O que é, vantagens e desvantagens

REST é o acrônimo de Representational State Transfer, que é um modelo de arquitetura baseado no protocolo HTTP e que utiliza URI para identificação dos seus serviços. REST é uma maneira de construir serviços usando o protocolo HTTP como ele foi concebido, ou seja, usando: POST, GET, DELETE e PUT.

Serviços RESTful (serviços REST) partem do princípio que o protocolo HTTP é rico o suficiente para que seja criada uma abstração – no caso WS-* seria uma abstração – para construção de serviços.

Uma das vantagens em utilizar serviços REST sem dúvida nenhuma é a simplicidade, afinal criar serviços REST é usar de maneira parecida o protocolo HTTP como usamos atualmente no desenvolvimento de aplicações Web, ou seja, se você usa o método POST em um formulário, você consequentemente está usando REST, a única diferença é que o submit desse formulário devolveria um conteúdo HTML, quando que em um serviço RESTful o indicado seria devolver uma estrutura mais padronizada, no caso um XML ou um JSON, por exemplo.

Outra vantagem no uso de serviços REST é a performance, pois os seus request/response são infinitamente menores se comparados com os do formato WS-*, e são menores, porque não precisam ser envelopados dentro de um pacote SOAP, serviços REST apenas recebem o que precisam e consequentemente respondem o que é necessário.

Serviços construídos no formato REST também são mais humanos, ou seja, são mais compreensíveis que serviços WS-*. Isso se deve ao fato de que para construir um serviço REST não é necessário conhecer N especificações, não é necessário saber o que é WSDL, assim como também não é necessário conhecer um pacote SOAP. São mais humanos também, pois são identificados através de URI’s.

Dentre outras vantagens de serviços RESTful destaco a possibilidade de fazer cache das operações, possibilidade de criar camadas intermediárias (proxy, gateway, cache servers) com o intuito de aumentar a performance ou segurança e possibilidade de usar HTTPS nativamente.

Pensando em um ambiente corporativo, em aplicações enterprise e em arquitetura SOA, começam a surgir alguns problemas em relação a adoção de serviços REST, a começar pelo fato de que REST não possui um padrão oficial para descrição dos seus serviços, até existe uma frente interessada em criar esse padrão utilizando WADL, mas ainda não existe nada oficial, portanto essa é uma grande desvantagem.

Serviços REST também não possuem estado, são stateless, ao contrário de serviços WS-*, pois os mesmos podem possuir estado entre uma chamada e outra. Serviços REST também não permitem requisições assíncronas e utilizando o formato WS-* é possível fazer requisições sem que seja necessário esperar uma resposta.

Pensando em SOA, REST não é a melhor opção, afinal, conforme citado anteriormente, REST não possui um contrato formal para definir a interface dos seus serviços, assim como também não possui uma maneira para que esses serviços possam ser publicados e descobertos.

Outra desvantagem no meu modo de ver, é que para construção de um processo BPEL, se faz por necessário que os serviços possuam uma interface que os descreva (WSDL), nesse caso serviços REST não seriam os mais indicados para serem usados dentro de um processo BPEL, contudo existem algumas maneiras de realizar esse workaround para usar serviços REST dentro de um processo BPEL. Dependendo da ferramenta escolhida, algumas fornecem soluções como a criação de Partner Links HTTP, ou seja, são Partner Links próprios para serviços REST, ou então, algumas outras ferramentas fornecem maneiras um pouco mais trabalhosas como a criação de um WSDL que descreva o serviço HTTP (REST).

Afinal, qual devo usar?

Sinto lhe frustrar, mas a resposta para essa pergunta é: depende, cada caso é um caso.

Não é inteligente ignorar uma ou outra opção, ou ser cego a ponto de desconsiderar os benefícios e vantagens de cada uma. Na minha opinião, fomentar essa discussão é cair no mesmo de discutir “qual linguagem é melhor”, afinal cada uma tem seu propósito.

Os fanáticos por REST costumam dizer que o formato WS-* só existe, pois os grandes players do mercado (Oracle, IBM, Microsoft, etc) estão envolvidos, já que esses grandes players desenvolvem ferramentas específicas para facilitar a criação e a manutenção a serviços construídos dessa maneira. Quem faz essa afirmação está completamente equivocado, pois por mais burocrático que serviços WS-* possam ser, eles ainda possuem uma enorme utilidade que serviços REST ainda não satisfazem.

Agora, no caso de serviços para celulares, PDA’s, e outros dispositivos móveis, onde cada dado enviado/recebido tem um custo alto, utilizar serviços REST é sem dúvida a melhor opção. Da mesma maneira que para prover serviços de aplicativos web, como mashups, REST também é a melhor opção, a maior prova disso é que em serviços como Twitter, Facebook, Amazon e até mesmo o Google, estão usando REST em larga escala.

Mas também existe o outro lado da moeda, pois pensando em um ambiente complexo, com muitos serviços, repositórios, ainda não dá para pensar em outro formato que não seja WS-*.

Enfim, mais uma vez volto ao ponto de que devemos conhecer as opções para tomar a decisão de escolher o que é mais adequado, REST não substitui WS-* e vice-versa, insistir nessa rixa não agrega e quem não enxerga dessa maneira, precisa rever seus conceitos, ou então estudar mais.

Aproveito para deixar o link para download de uma apresentação sobre REST, que fiz no meio do ano passado, na empresa que eu trabalho: clique para fazer download.