Métodos Ágeis em Serviços Compartilhados de Arquitetura de TI e Integração de Aplicações


Atualmente é raro encontrar alguém que não reconheça os benefícios dos métodos ágeis de gestão desenvolvimento de software. Métodos ágeis têm sido utilizados por uma quantidade cada vez maior de empresas, pessoas e áreas. Além disso, eles têm sido adotados nos mais diversos tipos de projetos de desenvolvimento de software.

Apesar da existência de tal diversidade, geralmente as práticas ágeis são adotadas na íntegra, sem levar em conta particularidades relacionadas ao tipo do projeto e suas entregas. Age-se “by the book”, usando conceitos e ferramentas que não foram criadas para resolver os problemas que estão sendo enfrentados. É nesse momento que discussões e questionamentos internos e externos a uma equipe surgem, podendo colocar em xeque não só a gestão mas o trabalho da equipe.

Comecei a praticar métodos ágeis (Extreme Programming) entre 2002 e 2003, pouco antes de trabalhar como revisor do livro Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. Desde então, tive a oportunidade não só de vivenciar diferentes situações, mas também pude estudar muitos casos como parte da minha pesquisa no Mestrado e no Doutorado na UFRJ.

Listei abaixo, alguns pontos curiosos ou que julguei serem relevantes ao longo dessa trajetória de praticante e estudioso de métodos ágeis, seja como Arquiteto de Integrações ou como gestor de equipes de desenvolvimento.

O que você entrega?

O SAFe utiliza o termo Potentially Shippable Increment (PSI). O Incremental Funding Method utiliza Minimum Marketable Feature (MMF). O LeSS utiliza o termo Potentially Shippable Product Increment. Outros usam Minimum Viable Product (MVP), User Stories, Features, etc. Seja qual for o nome, uma característica comum é que em todos eles o resultado do trabalho será entregue ao usuário final, seja com o objetivo de gerar retorno financeiro – como é o caso das MMFs – ou com o objetivo de melhor direcionar a visão do produto aprendendo o que realmente o usuário final necessita – como é o caso do MVP.

Em se tratando de entregas de uma equipe de Arquitetura/Integração, só deveríamos chamar de PSI, MMF, MVP etc, se o que estiver sendo desenvolvido for uma API com fins de comercialização. O mesmo se aplicaria no caso do setor público, para projetos de e-gov em que as entregas estejam relacionadas a Open Government Data. Isso por que, nesses casos, uma API pode ser considerada realmente como um produto, no sentido de algo que pode ser oferecido ao mercado para satisfazer um desejo ou uma necessidade.

Trata-se de um cenário bem diferente de integrações, APIs ou serviços (SOA) desenvolvidos com fins de integrar aplicações corporativas, por exemplo. Para esses casos, por exemplo, o Incremental Funding Method utiliza o termo Architectural Elements (AE). Tratam-se de entregas que, apesar de não serem capazes de gerar nenhum retorno financeiro, elas são pré-requisitos para que as que geram retorno financeiro (MMFs) possam ser desenvolvidas. Isso faz todo sentido se considerarmos que integrações, APIs e serviços tornam possível a execução de partes de um processo de negócio de forma mais eficiente.

Histórias de (qual) usuário?

Geralmente assisto apresentações, em congressos de desenvolvimento de software, sobre escrita de histórias. Por diversas vez ao final da apresentação perguntei: “E se o que está sendo desenvolvido é uma API ou um serviço (SOA), ou seja, não é algo que está em uma tela de uma aplicação, de um app ou de um site? Que ‘usuário’ eu coloco no nome da história ao escrever “Eu como <usuário>…“? Invariavelmente a resposta que ouço é para utilizar o nome do sistema que irá consumir a API ou o serviço.

Em um primeiro momento isso pode parecer satisfatório, mas depois de um tempo praticando essa recomendação, acabei percebendo que ela se tornou, digamos, chata. Por exemplo, em um dos projetos que trabalhei estávamos implementando mais de 70 integrações com um determinado sistema de gestão. Imagine você olhar o seu quadro diariamente e vê-lo tomado de histórias “Eu como sistema NomeDoSistemaDeGestão…“. Dependendo do nome sistema, se você usa Post-it, só essa parte do nome da história ocupará a metade do espaço do papel. Se você usa um sistema como o Rally ou Jira Agile, o mesmo acontecerá com os cartões ou issues. A consequência foi que simplesmente deixarmos de escrever essa parte no nome da história, passando a escrever apenas a parte do “o que fazer” e do “por que fazer/qual benefício“.

Uma evolução dessa abordagem seria identificar junto ao sistema de gestão qual o papel dos usuários que estão utilizando a funcionalidade acionou a requisição à API ou serviço. Então, seria utilizado nas histórias de integração esse papel, ao invés do nome da aplicação.

A história foi entregue ou está impedida?

Existem casos em que a API ou serviço é desenvolvida em paralelo ao desenvolvimento de consumidores e provedores. Por mais estranho que isso possa parecer, é possível. Trata-se da abordagem Contract First.

Nessa abordagem todas as partes envolvidas na integração acordam qual será a interface do serviço e iniciam seus desenvolvimentos usando Mocks. Quando todos estiverem prontos, faz-se um teste integrado.

Logicamente que essa abordagem pode levar a retrabalho em todas as equipes de desenvolvimento. Por isso, é importante acompanhar ao longo do projeto se ela está valendo a pena ou não.

Atenção especial deve ser dada à definição do Critério de Pronto das histórias. Isso por que se o critério exigir a comunicação com o(s) provedor(es), pode ser que sua história já entre no Sprint impedida, por ser dependente da entrega desses provedores e/ou da realização de um teste integrado.

Quem é o Product Owner?

Não é incomum ver equipes de desenvolvimento de arquitetura/integrações atenderem a vários projetos em paralelo. Nesse cenário em que a equipe presta “serviços compartilhados” dentro de uma organização, pode ficar difícil definir apenas um único Product Owner. Afinal de contas, como ter apenas 1 pessoa definindo requisitos, critérios de aceite e apoiando os cenários de teste de diferentes serviços de vários projetos ao mesmo tempo? Simplesmente esse é um cenário de gestão que não parece ser escalável.

Em cenários complexos como esse, uma opção é considerar os Arquitetos de TI, Arquitetos de Soluções ou Arquitetos de Integração, como sendo os Product Owners. Eles teriam a responsabilidade não apenas de escrever as histórias mas também validar as entregas feitas pelas equipes de integração. Essa abordagem tenho utilizado com sucesso há 100 (cem) Sprints (de 2 semanas cada)!

Que documentação deverá ser gerada (se é que alguma)?

Essa questão é bastante recorrente entre os praticantes iniciantes de métodos ágeis. Quando tal pergunta é feita, geralmente a resposta é “O método não diz que você não deve gerar nenhuma documentação” ou “Gere apenas a documentação necessária, que vai ser realmente utilizada“. Tudo muito genérico e superficial, o que não responde a pergunta.

No caso do desenvolvimento de APIs e serviços, existem pelo menos 3 “artefatos” que acredito serem essenciais:

  1. Um diagrama mostrando uma visão de alto nível sobre as partes envolvidas na integração (Ex: localização dos consumidores, middleware, provedores etc). Esse diagrama pode mostrar também algumas informações sobre a infraestrutura;
  2. Um mapeamento de dados para especificar como os dados enviados pelo consumidor serão tratados pela API ou serviço e enviados ao provedores (e vice-versa). Tanto esse mapeamento quanto o diagrama apoiarão o desenvolvimento da API ou serviço;
  3. Um guia de como a API ou serviço deverá ser utilizado. Isso inclui parâmetros de entrada e saída, informações no cabeçalho e corpo das requisições e respostas, códigos de status (HTTP) e respectivas mensagens. Uma dica para esse caso seria utilizar o Swagger.

Sobre esse último ponto, vale a pena ficar atento à iniciativa de unificação da Open API Initiavive – OAI.

Usar métodos ágeis em equipes que prestam serviços compartilhados e que não controem um produto (no sentido de algo que pode ser oferecido ao mercado para satisfazer um desejo ou uma necessidade) sem dúvida é um desafio diferente de utilizá-los quando todos estão voltados a um único e mesmo objetivo.

Seja qual for o método ágil que você utiliza ou como você chama as coisas que estão a sua volta, o importante é não perder a essência ágil representada pelo Manifesto Ágil. Seja qual for seu tipo de projeto ou entrega, o importante é não deixar de seguir os 12 princípios do Manifesto.

Para refletir mais sobre o assunto, recomendo a leitura do post “Do We Really Need Another Method?” de Ron Jeffries, um dos pais do Manifesto Ágil.

Ferramentas de Gestão de APIs e Barramentos de Serviços: O que você precisa na sua Arquitetura para resolver suas integrações de maneira “Lean”


Baseado num estudo das soluções de API Management (API-M) de 5 fornecedores cheguei a conclusão que um Enterprise Service Bus (ESB) consegue suprir a necessidade de gerir APIs, mas que, obviamente,  depende de cada caso. Essa dependência está relacionada não somente à situação atual (As-is) da sua Arquitetura mas também aonde você quer chegar (To-be). Justifico abaixo alguns pontos que julgo relevantes e que podem favorecer o uso de um ESB com o papel de uma solução de API-M.

Em primeiro lugar, no meu caso, isso foi possível pois desde quando adotamos um ESB optamos por não trabalhar com SOAP. A maioria dos nossos serviços são baseados em REST+JSON para facilitar a vida dos consumidores uma vez que eles não necessitariam utilizar “frameworks de webservices” para gerar automaticamente classes que a maioria dos desenvolvedores não consegue entender e manter. Então, o discurso dos fornecedores de soluções de API-M de que suas soluções “modernizam a infraestrutura” possibilitando “padrões e formatos mais modernos e ‘democráticos’” não se encaixa no cenário que vivencio. Prova disso é que alguns serviços que tínhamos puderam ser acessados facilmente tanto por front-ends de aplicações web (JavaScript) quanto por aplicativos (tablets e celulares) sem nenhum esforço.

Um segundo ponto que tornou isso possível foi a existência, desde o início da minha trajetória com Arquitetura Orientada a Serviços (SOA), de 2 infraestruturas integradas para o ESB. Uma dessas infraestruturas tem como foco integrações internas tais como sistemas de gestão (CRM, ERP e Call Center). A outra, que inclusive fica hospedada em um data center diferente do outro ESB por ter uma dependência maior da Internet, tem como foco principal é atender a necessidade de sites web e aplicativos. Vale ressaltar que esses 2 ESBs funcionam  de maneira integrada se comunicando tanto através de serviços (um consome serviço do outro) quanto através de mensageria (JMS).

Voltando à questão do REST+JSON, um terceiro ponto que contribuiu no meu caso, foi a existência de uma documentação acessível e executável para uso dos serviços. Acessível por que, ao invés de documentos do MS Word que ficam “escondidos” em servidores de arquivos dificultando sua localização e navegação, optamos por criar sites que chamamos de Guias de Uso. E executável pois dentro desses sites usamos o Swagger, uma excelente ferramenta que quebra barreiras, permitindo que desenvolvedores possam conhecer e usar os serviços e APIs sem escrever nenhuma linha de código. Sites e o Swagger são justamente o que as soluções de API-M possuem.

Um quinto fator está relacionado à visualização de informações (incluindo estatísticas de acesso/uso) e monitoração. Alguns ESBs  não possuem funcionalidades adequadas nessas 2 áreas, e precisam de outras ferramentas para completar a solução. Isso, de certa forma, não acontece com as soluções de API-M pois, algumas (eu disse “algumas”!) já vem com essas capacidades “integradas” e você não precisa pagar mais (seja licença ou subscrição) para tê-las. Entretanto, é possível integrar ESBs com ferramentas tais como Splunk (Visualização e Dashboards) e Nagios (Monitoração), através da simples leitura de arquivos de liga gerados pelos sevicos/APIs e pela infraestrutura do ESB. É possível que a sua equipe de Infraestrutura já utilize essas ferramentas, o que ajudaria a viabilizar a solução.

Um sexto ponto está relacionado a questões de escalabilidade, mas que afetam tanto ESBs quanto soluções de API-M: Cache e Mensageria. Tanto ESBs quanto API-M geralmente não possuem capacidades de Cache e Mensageria embutidas e, por esse motivo, você tem que recorrer a outros produtos. Uma possibilidade é utilizar uma implementação de JMS open-source (existem várias confiáveis e amplamente utilizadas). Talvez os desenvolvedores da sua empresa estejam usando um desses produtos e sua equipe de Infraestrutura já dê suporte. Para o caso de Cache, também existem soluções open-source que possivelmente os desenvolvedores web da sua empresa já estejam utilizando. Uma que venho usando com bastante sucesso é o Memcached.

Do ponto de vista financeiro, um sétimo ponto está relacionado ao investimento necessário para se adquirir uma solução de API-M. Na maioria dos casos que analisei, tais soluções requereriam um investimento maior do que o feito para adotar um ESB. Então, podemos estar falando de investir em torno de milhão de Reais, tanto em software quanto hardware, em um momento de crise, sendo que praticamente tudo que uma solução de API-M faz pode ser feito com um ESB. Mas para isso deve-se pensar não com uma cabeça de EAI, mas sim com uma cabeça de API Economy.

Por que “praticamente tudo”? Por que geralmente as soluções de API-M possuem uma capacidade que é ausente em um ESB: o Portal ou Store. Apesar disso, é perfeitamente possível alocar uma equipe interna, composta por UX/Design e desenvolvedores web, para desenvolver um Portal e a Store que tenha a cara e os padrões da sua empresa ou produto. Ou seja, apesar de um ESB ganhar de lavada do Gateway em uma solução de API-M. O que falta é o Portal/Store que deveria ser um sites “simples”.

Um sétimo ponto, dá vantagem às soluções de API-M e referem-se à existência de funcionalidades como o controles de vazão, controle de acesso e, autenticação e autorização. Praticamente todas as soluções de API-M que avaliei já vem com essas capacidades e você pode usá-las facilmente com apenas alguns cliques. Isso é possível inclusive para quem precisa de OAUTH. No meu caso já havíamos desenvolvido no nosso ESB um framework para isso. Então, no meu caso, API-M seria uma solução para problemas que já foram resolvidos, ou que ainda não tínhamos. Se você está avaliando uma solução de ESB, vale avaliar se ela já vem com componentes que atendam tais requisitos. Esses pode ser um critério de avaliação importante.

Não estou querendo dizer que soluções de API-M não são adequadas. Estou levantando a bola e relembrando o motivo pelo qual geralmente se adota um ESB. Não foi para tornar a TI mais flexível e fácil de mudar? A API Economy representa uma dessas mudanças, no caso de negócio. Se você projetou corretamente o uso do seu ESB ele deveria suportar tal mudança, o que aumentaria consideravelmente o ROI de um ESB.

Acredito que soluções de API-M são muito mais adequadas àquelas organizações que não possuem uma arquitetura baseada em um componente central, como um ESB, ou que possuem serviços web espalhados por diversos sistemas e aplicações. Note que, ainda assim, talvez será necessário um orquestrador desses diversos serviços, coisa que as soluções de API-M não fazem. A propósito, um tipo de produto muito interessante para quem não tem um ESB e pensa em adotar uma solução de API-M é o chamado Data Services. Um excelente exemplo desse tipo de ferramenta é o WSO2 Data Services Server.

Isso tudo é possível e funciona? Parece que sim. É o que estamos praticando até momento com bastante sucesso. Conseguimos fazer tudo isso seguindo as práticas de Continuous Delivery e usando ferramentas como Jenkins, Nexus, SVN etc. A parceria entre as Equipes de Arquitetura, Integração, Infraestrutura e, principalmente, Qualidade são fundamentais para esse sucesso. Tudo isso, em momento de crise e orçamentos apertados – como estamos vivendo – se torna ainda mais atrativo.

E aí, o que você precisa?

O que não pode faltar para o Nexo das Forças


Ao longo da história, o surgimento de novas tecnologias permitiram a criação de serviços e produtos que até então eram inimagináveis.  Na década de 90, o surgimento da Internet e dos telefones móveis criaram novos canais de comunicação entre empresas e pessoas. Nos anos 2000, o comércio eletrônico e a infinidade de sites surgidos durante a chamada “bolha da internet” revolucionaram as relações de comércio. Logo em seguida, vieram as redes sociais criando uma nova forma de relacionamento entre pessoas e também entre empresas e seus clientes. Recentemente, tecnologias de Big Data habilitaram o processamento de grandes quantidades e variedades de dados quase que instantaneamente. Todas essas novas tecnologias têm uma coisa em comum. Elas mudaram radicalmente as nossas vidas e das empresas.

O Gartner anualmente faz uma pesquisa sobre tecnologias consideradas prioritárias na opinião de CIOs de empresas do mundo inteiro. Nessa pesquisa, os CIOs apontam temas que eles julgam como mais importantes e com maior poder de impacto para o sucesso dos negócios de suas organizações. Na lista de prioridades geralmente eram encontrados temas como Segurança, Gestão de TI, Sistemas de ERP, CRM dentre outros. Acontece que nas pesquisas realizadas nos últimos 7 anos alguns itens dessa lista foram ganhando importância simultaneamente e recentemente passaram a figurar em conjunto no topo da lista. São eles: Social, Cloud Computing, Mobile e Information. À junção desses 4 temas o Gartner denominou “O Nexo da Forças”, em Inglês The Nexus of Forces.

Cada vez mais vemos pessoas compartilhando experiências, buscando respostas e, participando e se engajando em comunidades que compartilham as mesmas preferências, filosofias ou estilos. Essa é a força denominada Social. Pessoas querem se conectar a outras pessoas ou empresas usando os dispositivos que elas escolheram por serem mais adequados a determinada situação, momento ou circunstância. Essa é a força Mobile. Muitas vezes essas pessoas vezes usam mais de um dispositivo, em alguns casos simultaneamente, e desejam fazê-lo sem interromper a experiência de uso ao passar de um dispositivo para outro. Essa é a força Cloud. Tudo isso consumindo e gerando informações relevante e no tempo certo. O que importa é o objetivo do uso da informação e não a maneira, em termos técnicos, que elas são processadas.  Essa é a força Information.

Quando essas 4 forças são usadas em conjunto por uma organização de forma a incrementar e aprimorar seus produtos ou serviços, esta organização, segundo o Gartner, é considerada uma  Digital Enterprise. Organizações desse tipo sabem quais informações devem ser analisadas para planejar suas ações e direcionar seus produtos e serviços (Information). Elas sabem como reduzir custos e serem mais ágeis para atenderem as necessidades de seus negócios (Cloud). Tais empresas se preocupam com a maneira como clientes e usuários percebem seus produtos e suas marcas (Social). Além disso, elas sabem como melhorar o desempenho dos seus processos e oferecer experiências de uso que surpreendam seus clientes ao consumirem produtos ou serviços (Mobile).

O “o que” já sabemos, o Nexo das Forças representa 4 áreas para direcionar investimentos ao se implementar a estratégia de cada organização. O segredo do sucesso está no “como” e no “quanto” investir em cada força. Nesse cenário, algumas coisas parecem certas no momento. Sem uma Arquitetura de TI, que contribua para a criação de uma visão estratégica da adoção e do uso de novas tecnologias, a área de TI da organização não saberá aonde deverá chegar. Sem Métodos Ágeis de gestão de projetos e de desenvolvimento de software a TI não conseguirá entregar de forma contínua e não saberá se o que está entregando é o que o usuário e/ou cliente espera. Sem uma Gestão de APIs e das integrações entre as diversas aplicações, sistemas, sites e aplicativos, a organização não estará preparada para mudar quando nada disso que falei nesse post parecer verdade e as forças do “Nexus” forem outras.

Palavras-chave: Arquitetura de TI, Métodos ÁgeisEntrega Contínua, e Gestão de APIs e Integrações.

Como entender as ferramentas que suportam DevOps


Muito interessado no assunto DevOps e suas ferramentas, andei pesquisando nos últimos dias e achei alguns materiais bem interessantes e outros nem tanto. Nesse segundo grupo, que foi a grande maioria, achei muita coisa vaga que após ler/assistir você tem mais perguntas do que respostas, mais dúvidas do que certezas.

Então, resolvi não explicar as ferramentas e conceitos que aprendi e estou praticando, mas sim reunir links para materiais realmente úteis.

Espero que nos links abaixo, assim como aconteceu comigo, você possa realmente começar a entender do assunto, indo direto ao que interessa, mas sem perder de vista os fundamentos. Você irá entender sobre Virtual Environments e sua diferença em relação a Virtual Machines, o que são Linux Containers e vai fazer começar a fazer sentido o papel das ferramentas Puppet e o Chef e como elas se relacionam com as demais.

Primeiro, os fundamentos. Assumindo que você entende de Linux, aprenda o que são Linux Containers (LXC)

Depois você já terá condições de facilmente entender a ferramenta Docker, que é um LXC:

Em seguida, já sabendo que Containers são Virtual Environments, é hora de entender as diferenças entre as ferramentas Docker e o Vagrant. Um bom começo é esse post:

Apenas com essas rápidas leituras, você começará a visualizar cenários de uso viáveis dessas ferramentas que podem ser usadas de maneira combinada ou não, dependendo da necessidade do seu projeto ou dos seus objetivos: (Nota: Na esquerda temos o nível mais baixo enquanto na direita o mais alto)

  • Cenário sem Virtual Machines:
    • Docker -> Puppet ou Chef;
  • Cenários com Virtual Machines:
    • Vagrant->LXC (“Nativo” do Linux)->Puppet ou Chef
    • Vagrant->Docker->Puppet ou Chef;

Nesse ponto, lembrei de uma apresentação que o Mathieu Depriee (Octo Technology) fez lá na Infoglobo sobre DevOps, mais especificamente esse slide:
Apresentação completa em: http://www.slideshare.net/OCTOTechnology/introduction-to-devops-28779951

Se fossemos categorizar e posicionar o Vagrant e o Docker no diagrama do slide acima, acho que o Vagrant se encaixaria mais no quadro vermelho. Já o Docker estaria na interseção entre a vermelha e a verde, mas mais para a verde.

Subversion: O que acontece com o espaço em disco do servidor SVN ao criar Branch, Tag e Revisions?


Hoje comecei o dia batendo um papo sobre como o Subversion trata a questão do armazenamento de espaço em disco ao criar diferentes Revisions, diferentes Tags e diferentes Branches. Então resolvi registrar nesse post as conclusões e comparações que fiz entre o Subversion e o CVS.

Internamente para o Subversion, Branches e Tags são a mesma coisa. Então, o que vou comentar vale para ambos, ok?

Quando um arquivo é incluído em um repositório e sofre modificações, o Subversion armazena apenas o “diff” entre as versões e não 2 vezes o arquivo inteiro. Nesse caso não se gasta espaço desnecessariamente no lado do servidor.

Na criação de Branches e Tags, o Subversion usa “hard links“. Então, não há duplicação de conteúdo no lado do servidor, o que economiza espaço. Esse é o conceito de “Cheap copies” que o Subversion possui.

O mesmo vale para arquivos binários.

Quem trabalha com Scrum e está na dúvida se deve, por exemplo, criar Branches por Sprints ou um bracnh mais genérico de “desenvolvimento”, parece que o genérico não é a melhor escolha. Isso se você estiver pensando em fazer merges (reintegrate) mais de uma vez a partir do mesmo branch para o trunk. Aqui vale a mesma preocupação que usuários do CVS tinham ao fazer múltiplos merges de um mesmo branch para o trunk. Então, embora possível, a gestão fica mais complicada e por isso a documentação do Subversion recomenda evitar fazer isso. É mais simples, após o merge, criar um novo branch ao invés de continuar o trabalho no branch antigo.

Durante os vários anos que trabalhei com o Subversion eu fazia o mais complicado, ou seja, múltiplos merges de um mesmo branch para o trunk. Isso tinha uma razão, que escreverei em um novo post.

Até lá!

RESTful web services: When to use HTTP PATCH method


HTTP is a very interesting method but just a few application, SOA or Enterprise Integration developers use all of its capabitities. POST and GET among all HTTP Methods are the most used Method followed by PUT. Yet not very used the PATCH method is very useful and it plays a so specific role that it worth understanding its semantics.

In order to better understand HTTP’s PATCH method let’s have a real-world inspired example. The following figure is a simplified version of a integration project that I’ve been working on.

Users  connect to the cloud-based Payroll System in order to do many activivies such as employee data management.  This system holds the “master data” for employees.

Now imagine everytime an employee data is created or edited in the Payroll System we have to send this new/edited data  (the “1” in the figure) to other systems such as a Sales/Remuneration system (the “2” in the figure), a Performance Appraisal System (the “3” in the figure) and so on (the “4” in the figure).

As described in one of my last posts When to use HTTP Post and HTTP PUT, both POST and PUT create or edit a full Resource Representation, i.e., when you have all of its data.

Bringing it to our Payroll example it means we would create a RESTful web service – in our Tibco ESB – based on POST/PUT  method if the Payroll would send not only the edited Employee data but all its data (all attributes). But that was not the case of the Payroll system I was integrating with. The Payroll sends only the edited data, I mean, if a employee move to another apartment in the same building the payroll would send just the Address’ complement without the street name, city, postal code and so on so forth. That’s why HTTP PATCH was created for!

While in a PUT/POST request, the enclosed entity is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.

Therefore, the final result of the RESTful web services created in Tibco ESB for this project was:

  • POST /employee/id:  Creates a employee in the Payroll system;
  • PUT /employee/id: Broadcasts a message  so that all other systems replace a full employee data. Actually, this will only be used in the future in my project and we did not created it;
  • PATCH /employee/id: Broadcasts a message  so that all other systems update just a set of a employee’s data.

That’s all for today. I hope you now are able to make a better decision on when to use POST, PUT and PATCH when designing RESTful web services.

Tchau!

noSQL and SQL databases: Not an exclusive decision


When trying to find real-world noSQL modeling cases to get some inspiration I ran into the NoSQL Data Modeling Techniques from Highly Scalable Blog. After reading the post and its comments I remembered the discussions around one Semantic Web class I attended last year at NCE-UFRJ. During that class we discussed the future of Triple Stores and that maybe OLTP systems would never leave the relational model and start using Triple Stores. Maybe representing data as RDF would be just another way of representing data the way OLAP systems do.

Almost everytime people talk about noSQL database they end up comparing it to SQL database and the relational model. My opinion at the moment is that it’s not an exclusive (XOR) decision. Since everybody say noSQL databases are better in high traffic/load evironments and SQL databases are better in OLTP env (where data change very frequently), we should take advantage of both at the same time. I mean, let’s have a noSQL database be another form of  data representation that is also in relational databases.

I will try to find how Facebook, Foursquare, Twitter etc use noSQL and SQL/Relational databases. If you see any article, presentation or post that talks about how the use such databases types, or if you have used both together please, share it here by posting a comment. It would be better if it shows an end-to-end architecture using both and not just a peace of it, ok?!

Keep in touch!