Serviços Web - O Paradigma RESTful

Existem muitas definições para o termo Serviços Web. Para motivar nossa discussão, vamos nos basear inicialmente na definição publicada pelo W3C, como segue: “Um serviço web é um sistema de software projetado para suportar a interação entre máquinas de forma interoperável em uma rede de computadores. Este serviço possui uma interface descrita em um formato processável por máquina (especificamente o WSDL). Outros sistemas interagem com o serviço web de acordo com esta interface, utilizando mensagens SOAP, tipicamente enviadas via HTTP com uma serialização em XML”.

Tal definição é perfeitamente realizável e amplamente adotada. Grandes empresas como Microsoft e IBM participaram ativamente do desenvolvimento desta abordagem através do lançamento de produtos e publicação de artigos. O problema existente nesta definição é que ela trata de um grupo específico de tecnologias, mais precisamente o protocolo SOAP e as linguagens WSDL e XML.

Segundo Leonard Richardson e Sam Ruby em seu livro “RESTful Web Services”, existem na verdade três grupos de serviços web, distintos em termos de arquitetura e tecnologias adotadas. São eles: Serviços RESTful, Serviços RPC, e Serviços REST-RPC. Cada grupo deve responder duas questões relativas à sua arquitetura:

1. Qual a ação a ser executada?
2. Qual o escopo de execução desta ação?

Serviços RESTful são os mais fiéis ao HTTP, pois utilizam todo o potencial oferecido por este protocolo. A ação a ser executada é definida pelo método HTTP (também conhecido como verbo HTTP). O protocolo oferece cinco métodos principais: GET, HEAD, POST, PUT, e DELETE. Todos os métodos são aplicados em recursos, ou seja, nos objetos gerenciados pelo serviço. Por este motivo, uma arquitetura RESTful é dita orientada a recurso.

O método GET trata da recuperação real de recursos, ao passo que HEAD retorna apenas os cabeçalhos (ou meta-dados) que descrevem os recursos afetados pela requisição HTTP.

Já os métodos POST e PUT tratam da inserção e atualização de recursos. A especificação HTTP é um tanto abrangente na comparação entre estes dois métodos. Alguns serviços web utilizam PUT para inserção, enquanto outros utilizam POST. A discussão é polêmica realmente. Após rever a especificação oficial, entendo que POST deve ser utilizado para a inserção de recursos aninhados. De acordo com esta interpretação, o método PUT seria usado tanto para a inserção, quanto para a atualização de recursos completos/independentes. Independentemente da sua interpretação, seja coerente na utilização destes métodos quando for criar seus próprios serviços, e documente suas decisões. Caso você esteja apenas consumindo serviços já disponíveis na Internet, tenha o cuidado de verificar qual a interpretação do provedor deste serviço.

Por fim, o método DELETE deve ser enviado para a remoção do recurso. Alguns serviços preferem executar uma técnica conhecida como soft-delete, onde o recurso não é efetivamente removido da base, mas apenas inativado. Outros preferem executar o hard-delete, o que faz com que o recurso nunca mais possa ser acessado, pois já não existe na base. Novamente, a especificação do serviço deve cobrir esta decisão.

Agora, sobre a definição do escopo de execução do método, o paradigma RESTful defende a utilização da URI presente na requisição HTTP para este fim. Nesta abordagem, a URI contém não apenas o caminho do serviço em questão, mas também qualquer parâmetro necessário para identificação única do recurso a ser afetado.

Observe o primeiro exemplo a seguir, onde uma aplicação cliente envia uma mensagem HTTP utilizando o método GET, e uma URI que identifica a foto de número 123. Neste cenário fictício, gallery.com seria uma aplicação de gerenciamento de fotos, que oferece uma API pública de acordo com os princípios RESTful. Neste momento, a aplicação quer recuperar/obter a foto armazenada em gallery.com.

GET /photo/123 HTTP /1.1
Host: gallery.com

No segundo exemplo, a requisição HTTP enviada utiliza o método DELETE, o que significa que a foto 123 será removida da base em gallery.com.

DELETE /photo/123 HTTP /1.1
Host: gallery.com

Note que apenas o método HTTP foi alterado, enquanto que a URI permaneceu intacta. Esta é uma característica marcante dos serviços RESTful. Aquela URI sempre identifica o mesmo recurso, ou seja, a foto 123. Este é o escopo de execução. Já o método HTTP apenas diz qual a ação a ser executada (recuperação no primeiro exemplo, e deleção no segundo).

Portanto, podemos perceber que é tranquilamente possível a criação de serviços web sem a utilização do SOAP, protocolo utilizado na definição publicada pelo W3C. Na realidade, diversas empresas emergentes já oferecem interfaces RESTful para que outras empresas/aplicações possam se conectar a elas.

Como visto neste post, o paradigma RESTful utiliza apenas o HTTP, protocolo padrão da Web, e sem o qual a Web não existiria como a conhecemos hoje. Na prática, os desenvolvedores rapidamente percebem que o protocolo REST é mais leve e portável que o SOAP.

Nos próximos posts, pretendo tratar das outras duas arquiteturas para serviços web: Serviços RPC (SOAP como principal exemplo) e Serviços REST-RPC. Até lá!

Engenharia de Software com Processos Ágeis – Desenvolvimento de Aplicações para a Internet

Olá pessoal, já faz algum tempo que não escrevo por aqui, e desta vez eu gostaria apenas de divulgar um novo projeto.

Venho trabalhando com um grupo de professores da PUC - São Paulo, e recentemente criamos um curso de especialização que será oferecido pela própria Universidade. Trata-se de um curso inovador na área de Ciência da Computação, que agrega conceitos de Engenharia de Software, Orientação a Objetos, Internet, e Processos Ágeis.

O curso acaba de ser lançado sob o nome "Engenharia de Software com Processos Ágeis – Desenvolvimento de Aplicações para a Internet". Oito módulos serão oferecidos, sendo que cada um será completamente independente dos demais, não havendo pré-requisito entre eles. Isto fará com que o aluno possa trilhar um caminho de acordo com suas necessidades. Adicionalmente, não será necessário que o aluno se inscreva em todos os módulos, somente nos que julgar adequado ao seu perfil. Este formato é realmente novo e flexível.

Segue a lista de módulos:

1. Processos Ágeis
2. Engenharia de Requisitos
3. Desenho Lógico com Objetos
4. Implementação de Aplicações para a Internet
5. Programação com Objetos para Internet
6. Análise com Objetos
7. Desenho Físico com Objetos
8. Teste de Aplicações para Internet
   

Uma descrição mais detalhada pode ser encontrada no site da Coordenadoria Geral de Especialização, Aperfeiçoamento e Extensão da PUC-SP.

Atalho: http://tinyurl.com/eng-sw-puc/

Qualquer dúvida, por favor entre em contato, ou escreva um comentário neste post. Forte abraço!

Crítica Rápida ao Active Record

Resumidamente, Active Record é um padrão encontrado em alguns projetos de software que armazenam dados em bases relacionais. Neste padrão, uma tabela é "encapsulada" por uma classe, portanto cada instância desta classe estará diretamente acoplada à uma linha da tabela.

Crítica: Caso a classe em questão seja um conceito do domínio, obviamente suas instâncias serão objetos de negócio. Ao aplicarmos o padrão Active Record, criamos uma dependência a partir negócio para a tecnologia!

No post Inversão de Dependências, apresento pelo menos quatro consequências geradas por esta dependência. Discussão polêmica... ;-) Comentários?

Abraços!

Inversão de Dependências

A forte dependência entre classes (ou componentes) é o principal vilão de uma boa arquitetura de software! Evidentemente, não existe uma arquitetura completamente desacoplada, pois desta forma os objetos não poderíam trocar mensagens uns com os outros. A idéia é minimizar a existência destas dependências, e inserir no modelo apenas dependências bem planejadas. Particularmente, costumo chamar estas dependências bem planejadas de dependências saudáveis, afinal de contas, trazem muitos benefícios para o sistema como um todo.

No post Princípios Fundamentais do Processo Unificado, apresento o conceito Processo Centrado em Arquitetura. Resumidamente, o processo de desenvolvimento é guiado pela evolução da arquitetura, e o arquiteto preocupa-se em estabelecer um alto grau de modularidade para facilitar a expansão e a manutenção do sistema. Com módulos bem planejados, e dependências saudáveis entre eles, minimizamos três propriedades internas indesejáveis: Rigidez, Fragilidade, e Imobilidade. Vale a pena dar um pulo naquele post para entender cada uma destas três propriedades.

OK, vamos ao que realmente interessa: Como modelar apenas dependências saudáveis? Resposta bate-pronto: Utilizando interfaces para a inversão de dependências! Interface é uma definição parcial de algum conceito do domínio tratado por sua arquitetura. Certamente é a maior aliada do arquiteto de software! Vamos apelar para a UML para entender como inverter dependências.

O esquema acima poderia ser parte integrante da arquitetura de um comércio eletrônico, onde pedidos são armezenados na base de dados. É natural pensar que um objeto da classe Pedido envie mensagens para um objeto da classe MSSQL. Entretando, a dependência existente a partir de Pedido para MSSQL é indesejável. Algumas consequências podem ser observadas:

• O negócio passa a depender da tecnologia. Como sabemos, a tecnologia está em constante evolução, e cada mudança tecnológica potencialmente provoca uma mudança nas classes de negócio, como a classe Pedido neste exemplo. Regras de negócio tendem a ser mais estáveis ao longo do tempo.


• A arquitetura assume que, invariavelmente, o armazenamento dos dados será realizado por um banco de dados. É importante lembrarmos que o armezenamento baseado no sistema de arquivos vem ganhando algum destaque, e mostra bom desempenho.


• Caso a classe de acesso aos dados tenha sido desenvolvida para trabalhar com um banco de dados específico (MSSQL neste exemplo), então a classe de negócio deverá ser constantemente modificada para cobrir eventuais novos provedores de dados (MySQL por exemplo).


• Cria um acoplamento que dificulta testes unitários.

Como alternativa, poderíamos fazer com que a classe Pedido dependesse de uma interface que teria por objetivo prímário desacoplar o negócio das questões de armezenamento e recuperação dos dados.

Repare que, neste momento, a dependência é invertida, e todos os pontos negativos citados são removidos da arquitetura! Porém, o objeto de negócio ainda precisa enviar a mensagem para o objeto que manipula a base de dados. Como realizar isso nesta nova arquitetura? Simples! Interfaces não existem em tempo de execução, apenas objetos. Desta forma, o lugar da interface é ocupado pelo objeto de alguma classe que realiza esta interface. Podemos ter uma classe para MSSQL, outra para MySQL, uma terceira para FileSystem, e assim por diante.

Visualizar a inversão de dependência é ainda mais fácil quando tratamos com componentes, e não classes, como segue.

No próximo diagrama a dependência é invertida com o advento da interface.

A notação caixa-preta torna tudo ainda mais evidente, como segue:

E, novamente, a inversão da dependência:

É isso aí pessoal, espero ter colaborado com mais essa! Até a próxima, abraços!

Pacote de posts sobre o Processo Unificado

Meu esforço inicial neste canal de comunicação foi apresentar o Processo Unificado, um framework de apoio ao desenvolvimento de software. Foram apresentadas as cinco disciplinas e as quatro fases do processo.

Na realidade seria possível escrever posts mais detalhados e amplos, mas acredito que não seria o mais adequado para um canal deste tipo. A idéia principal é incentivar a leitura e o debate dos tópicos que formam este processo.

Pacote de posts:

Processos Iterativos de desenvolvimento de software
Princípios Fundamentais do Processo Unificado
A estrutura do Processo Unificado
A disciplina de Requisitos
A disciplina de Análise
A disciplina de Projeto
A disciplina de Implementação
A disciplina de Teste
A fase de Concepção
A fase de Elaboração
A fase de Construção
A fase de Transição

A partir de agora, discutiremos outros temas, como modelagem orientada a objetos! Espero que tenha contribuido, um abraço!

A fase de Transição

Consiste basicamente em entregar uma versão operacional do sistema ao cliente.

Deve-se preparar uma divulgação e uma documentação de usabilidade para o usuário final; ajustar o software no ambiente e, por fim, ministrar treinamentos que sejam necessários.

Como as disciplinas atravessam a fase

As cinco disciplinas podem ocorrer nesta fase, mas o Processo Unificado não se refere especificamente a este tópico. No momento em que o sistema atingir este ponto, ele funcionará comprovadamente.

Avaliação

A avaliação desta fase consiste basicamente em observar se os clientes não tiveram dificuldades na instalação e na usabilidade básica do sistema.

Nesta altura, o Plano de Projeto e os seis principais modelos devem estar finalizados. A documentação completa do processo de desenvolvimento deve ser armazenada e utilizada como base caso um novo ciclo seja necessário.

A fase de Construção

Neste momento do ciclo de vida pode-se dizer que apenas questões técnicas são tratadas. A modelagem, a codificação e os testes dos componentes marcam esta fase.

É a fase onde o Modelo de Implementação e o Modelo de Teste tendem a ser bastante trabalhados, consequentemente, é o momento onde os desenvolvedores e os testadores mais atuam.

É comum que o Modelo de Casos de Uso, o Modelo de Análise, o Modelo de Projeto e o Modelo de Instalação estejam concluídos, apesar de ainda serem refinados nesta fase com eventuais detalhes.

Terá sucesso e poderá ser considerada concluída quando se atinge uma maturidade considerável nos artefatos das disciplinas de Implementação e Teste.

Como as disciplinas atravessam a fase

Os parágrafos a seguir apresentam uma breve descrição de como cada uma das disciplinas atravessa a fase de Construção em termos de tarefas:

• Requisitos: Esta disciplina freqüentemente não é trabalhada nesta fase, os requisitos devem estar claros para todos na equipe.


• Análise: Esta disciplina também é pouco trabalhada nesta fase, a arquitetura candidata já cedeu espaço para uma mais sólida.


• Projeto: Refinar os artefatos relativos à arquitetura e à instalação do sistema.


• Implementação: Modelar e codificar os componentes.


• Teste: Verificar os componentes através dos diversos tipos de teste.

Avaliação

Existe apenas uma questão ao final desta fase: O sistema está pronto para ser entregue aos clientes? Caso a resposta seja negativa, será necessário adicionar uma iteração para os ajustes finais.

A fase de Elaboração

O núcleo desta fase é a busca por uma boa arquitetura. No post "Princípios Fundamentais do Processo Unificado" fica clara a preocupação deste processo em prover meios para alcançar altos graus de manutenibilidade, flexibilidade, expansibilidade e reuso.

Esta fase também é marcada pelo gradativo afastamento dos clientes e, conseqüentemente, pela gradativa aproximação de questões mais técnicas.

Lembrando que são as disciplinas que possuem artefatos associados e não as fases, é perfeitamente comum que alguns documentos produzidos com bastante intensidade na fase de Concepção sejam refinados nesta fase, como é o caso do documento de Requisitos Não-Funcionais, pertencente à disciplina de Requisitos.

Porém, de forma mais intensa que a disciplina de Requisitos, as disciplinas de Análise e Projeto são as mais evidentes. Ao longo da fase, espera-se que uma arquitetura candidata seja substituída gradativamente por uma arquitetura mais concreta, ou seja, uma fundação sólida para o sistema.

Como as disciplinas atravessam a fase

Os parágrafos a seguir apresentam uma breve descrição de como cada uma das disciplinas atravessa a fase de Concepção em termos de tarefas.

• Requisitos: Refinar os artefatos referentes aos requisitos funcionais e não-funcionais.


• Análise: Refinar os artefatos relativos à arquitetura candidata.


• Projeto: É a principal disciplina desta fase. As tarefas-chave são criar uma arquitetura sólida, tendo como base os diagramas produzidos na disciplina de Análise, e estruturar o cenário da instalação do sistema em componentes de hardware.


• Implementação: Iniciar, ainda que superficialmente, a modelagem de componentização de acordo como o que foi produzido na disciplina de Projeto.


• Teste: Necessária somente se algum componente tiver sido implementado, o que é pouco provável.

Avaliação

Existem algumas questões que auxiliam na avaliação da fase quando se imagina que está concluída:

• Todos entendem e concordam com os requisitos detalhados?


• Existe uma base arquitetônica sólida que possa evoluir à medida que os requisitos são explorados e mais funcionalidades são adicionadas no sistema?


• As estimativas de tempo e custo foram cumpridas?

Se as respostas satisfizerem à maioria dos interessados, a fase pode ser considerada concluída com êxito. Caso contrário, talvez o melhor seja acrescentar mais uma iteração a esta fase para aparar arestas e finalizar o que estiver pendente.