Uma Aplicação da Arquitetura Orientada a Recursos
Uma Aplicação da Arquitetura Orientada a Recursos
Orientador:
Luiz Fernando Bier Melgarejo
Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciência da Computação.
Prof. M. Sc. Luiz Fernando Bier Melgarejo Orientador
Banca Examinadora
Prof. Dr. José Mazzucco Jr.
Resumo
Muito esforço tem-se empregado em pesquisas sobre serviços web, e grande parte des-tas pesquisas ignora completamente o estilo de arquitetura proposta originalmente para a web. Buscou-se com este trabalho resgatar um estilo arquitetural desenvolvido para sistema distribuí-dos de hipermídia, REST, que foi introduzido por um distribuí-dos idealizadores da web, Roy Fielding, e estudar uma arquitetura que segue esse estilo, a Arquitetura Orientada a Recursos (ROA), pro-posta por Leonard Richardson e Sam Ruby em 2007 a partir de observações pragmáticas sobre o emprego de REST na web. Tendo como objetivo, o emprego destas teorias no desenvolvimento de uma aplicação de apoio a seminários, utilizando-se de técnicas agéis tais como Programação Orientada por Comportamento como metodologia. Como resultado, criou-se um sistema web orientado a recursos, o sistema Disseminário de apoio a seminários.
Palavras-chave: REST, Arquitetura Orientada a Recursos, Desenvolvimento Guiado por Comportamento, Desenvolvimento Guiado por Testes, Seminários.
A big effort has been done on web services research and most of these researches com-pletely ignore the originally proposed web architecture. In this work we tried to bring back an architectural style built for distributed hypermedia systems, REST, introduced by one of the web idealizers, Roy Fielding, and study an architecture that follows this style, the Resource-Oriented Architecture (ROA), proposed by Leonard Richardson and Sam Ruby on 2007 based on pragmatic observations of REST on the web. Our goal is to apply these theories to develop a seminars management system, using agile techniques as Behaviour-Driven Development as our development methodology. As result, a resource-oriented seminar system has been built, the Disseminário seminars management system.
Keywords: REST, Resource-Oriented Architecture, Behaviour-driven Development, Test-Driven Development, Seminars.
Sumário
Lista de Figuras Lista de Tabelas
Lista de abreviaturas e siglas
1 Introdução p. 18 1.1 Objetivo Geral . . . p. 18 1.2 Objetivos Específicos . . . p. 18 2 REST p. 20 2.1 Derivação de REST . . . p. 20 2.1.1 Cliente/Servidor . . . p. 21 2.1.2 Sem-Estado . . . p. 21 2.1.3 Cache . . . p. 22 2.1.4 Interface uniforme . . . p. 23 2.1.5 Camadas . . . p. 23 2.1.6 Código sob demanda . . . p. 25 2.2 Elementos Arquiteturais . . . p. 25 2.2.1 Elementos de Dados . . . p. 25 2.2.2 Componentes . . . p. 27 2.2.3 Conectores . . . p. 28
3.1.2 Identificadores de Recursos . . . p. 29 3.1.3 Representações . . . p. 30 3.2 Propriedades . . . p. 31 3.2.1 Endereçabilidade . . . p. 31 3.2.2 Sem-estado . . . p. 31 3.2.3 Conectividade . . . p. 33 3.2.4 Interface Uniforme . . . p. 34 4 Metodologia p. 36 4.1 Resumo do Procedimento . . . p. 36 4.1.1 Identificação dos dados do domínio . . . p. 37 4.1.2 Definição dos recursos . . . p. 38 4.1.3 Definição dos nomes dos recursos . . . p. 39 4.1.4 Definição das operações sobre os recursos . . . p. 41 4.1.5 Representações aceitas pelo servidor . . . p. 43 4.1.6 Definição das representações oferecidas pelo servidor . . . p. 43 4.1.7 Interligação dos recursos . . . p. 44 4.1.8 Definição das respostas bem sucedidas . . . p. 44 4.1.9 Definição das respostas mal sucedidas . . . p. 46 4.2 Desenvolvimento Guiado por Comportamento . . . p. 46 4.2.1 Histórias . . . p. 47 4.2.2 BDD no Disseminário . . . p. 48
5 Disseminário p. 51
5.1.2 Autenticação . . . p. 54 5.1.3 Criação de Proposta de Seminário . . . p. 57 5.1.4 Aprovação de Proposta de Seminário . . . p. 57 5.1.5 Participação em Seminário . . . p. 59 5.1.6 Publicação de Apresentação . . . p. 59 5.2 Papéis de Usuários . . . p. 65 5.2.1 Visitante . . . p. 65 5.2.2 Usuário . . . p. 66 5.2.3 Coordenador . . . p. 66 5.2.4 Administrador . . . p. 66 6 Implementação p. 67 6.1 Disseminário . . . p. 67 6.1.1 Arquitetura . . . p. 67 6.1.2 Camada de serviços . . . p. 67 6.1.3 Modelo de negócios . . . p. 69 6.1.4 Camada de Persistência . . . p. 70 6.2 Verificação das especificações . . . p. 71
7 Conclusões p. 72
7.1 Resultados Alcançados . . . p. 73 7.2 Trabalhos Futuros . . . p. 73
Referências Bibliográficas p. 74
Anexo A -- Código-fonte das Especificações p. 76
C.2 JSON . . . p. 249 C.3 XML . . . p. 249 C.4 XHTML com Marcações Descritivas . . . p. 250 Anexo D -- Artigo: Uma Aplicação da Arquitetura Orientada a Recursos p. 251
Lista de Figuras
2.1 O estilo cliente servidor [1] . . . p. 21 2.2 O estilo Sem-Estado [1] . . . p. 22 2.3 O estilo Cache [1] . . . p. 23 2.4 Interface Uniforme [1] . . . p. 24 2.5 Sistema em Camadas [1] . . . p. 24 2.6 Código sob demanda [1] . . . p. 25 3.1 Aplicação Sem-Estado . . . p. 32 3.2 Aplicação Com-Estado . . . p. 32 3.3 Pesquisa sobre Buracos Negros . . . p. 33 3.4 Uma aplicação conexa . . . p. 34 4.1 Diagrama entidade relacionamento do Disseminário . . . p. 37 4.2 Diagrama da Interligação de Recursos . . . p. 45 4.3 O ciclo TDD [2] . . . p. 47 5.1 Primeira etapa do cadastramento . . . p. 52 5.2 Mensagem de confirmação de cadastramento . . . p. 52 5.3 Segunda etapa do cadastramento . . . p. 53 5.4 Mensagem de conta criada . . . p. 54 5.5 Página de um usuário do Disseminário . . . p. 54 5.6 Lista de usuários do Disseminário . . . p. 55 5.7 Enlace de autenticação . . . p. 55 5.8 Janela de autenticação . . . p. 56 5.9 Usuário navegando autenticado . . . p. 56
5.12 Página de uma proposta de seminário . . . p. 59 5.13 Página de um seminário . . . p. 60 5.14 Página principal do Disseminário . . . p. 61 5.15 Opção para participar de um seminário . . . p. 61 5.16 Página de um participante de um seminário . . . p. 62 5.17 Lista de participantes de um seminário . . . p. 62 5.18 Enlace para publicação de apresentação . . . p. 63 5.19 Página de publicação de apresentação . . . p. 63 5.20 Lista de apresentações de um seminário . . . p. 64 5.21 Uma apresentação publicada em um seminário . . . p. 64 5.22 Hierarquia de papéis de usuários . . . p. 65 6.1 Arquitetura do Disseminário . . . p. 68 6.2 Comunicação entre um cliente e o Disseminário . . . p. 68 6.3 Diagrama das classes dos recursos . . . p. 70
Lista de Tabelas
2.1 Componentes . . . p. 28 2.2 Conectores . . . p. 28 3.1 Segurança e Idempotência . . . p. 35 4.1 URIs de Recursos . . . p. 41 4.2 Métodos implementados nos Recursos . . . p. 42
4.1 Representação XHTML com Marcações Descritivas . . . p. 43 4.2 História: Usuário Participando de Seminário . . . p. 49 A.1 Arquivo: Teste.java . . . p. 76 A.2 Arquivo: PublicadorDaHistoriaDaPsicologiaLatinoAmericana.java . . . p. 76 A.3 Arquivo: TesteRepresentacaoXHTML.java . . . p. 78 A.4 Arquivo: RepresentacaoNula.java . . . p. 79 A.5 Arquivo: RepresentacaoXHTML.java . . . p. 80 A.6 Arquivo: Enlace.java . . . p. 83 A.7 Arquivo: Microformato.java . . . p. 83 A.8 Arquivo: TesteMicroformato.java . . . p. 87 A.9 Arquivo: TesteHistoriaDePsicologiaLatinoAmericana.java . . . p. 89 A.10 Arquivo: TesteRecursoSeminario.java . . . p. 95 A.11 Arquivo: TesteDeRecurso.java . . . p. 97 A.12 Arquivo: TesteRecursoSeminarios.java . . . p. 99 A.13 Arquivo: ClienteHTTPComAutenticacao.java . . . p. 101 A.14 Arquivo: ClienteHTTPAdministrador.java . . . p. 102 A.15 Arquivo: QuandoFoiFeitaUmaPropostaDeSeminario.java . . . p. 104 A.16 Arquivo: QuandoApresentacaoENova.java . . . p. 114 A.17 Arquivo: QuandoUsuarioEVisitante.java . . . p. 121 A.18 Arquivo: QuandoOSeminarioENovo.java . . . p. 123 A.19 Arquivo: QuandoExisteOSeminario.java . . . p. 131 A.20 Arquivo: QuandoExisteOCadastramento.java . . . p. 135
A.22 Arquivo: ClienteHTTPNaoBloqueante.java . . . p. 143 A.23 Arquivo: QuandoCadastramentoENovo.java . . . p. 144 B.1 Arquivo: Data.inc.php . . . p. 148 B.2 Arquivo: BasePropostaDeSeminario.php . . . p. 149 B.3 Arquivo: BaseParticipante.php . . . p. 150 B.4 Arquivo: BaseApresentacao.php . . . p. 151 B.5 Arquivo: BaseCadastramento.php . . . p. 152 B.6 Arquivo: BaseCadastrosTemporariosDeUsuarios.php . . . p. 153 B.7 Arquivo: BaseSeminario.php . . . p. 153 B.8 Arquivo: BaseUsuario.php . . . p. 155 B.9 Arquivo: Apresentacoes.inc.php . . . p. 156 B.10 Arquivo: Seminarios.inc.php . . . p. 157 B.11 Arquivo: Usuarios.inc.php . . . p. 158 B.12 Arquivo: Apresentacao.inc.php . . . p. 160 B.13 Arquivo: PropostaDeSeminario.inc.php . . . p. 161 B.14 Arquivo: Cadastramento.inc.php . . . p. 161 B.15 Arquivo: Usuario.inc.php . . . p. 161 B.16 Arquivo: Participante.inc.php . . . p. 163 B.17 Arquivo: Cadastramentos.inc.php . . . p. 163 B.18 Arquivo: Seminario.php . . . p. 164 B.19 Arquivo: Participantes.inc.php . . . p. 165 B.20 Arquivo: PropostasDeSeminarios.inc.php . . . p. 165 B.21 Arquivo: MensagemDeConfirmacaoDeCadastramento.inc.php . . . p. 166 B.22 Arquivo: MensagemHTML.inc.php . . . p. 167 B.23 Arquivo: MensagemDeCorreioEletronicoAbstrata.inc.php . . . p. 168
B.26 Arquivo: MensagemDePropostaCriada.inc.php . . . p. 170 B.27 Arquivo: MensagemDeContaCriada.inc.php . . . p. 171 B.28 Arquivo: MimeTypes.inc.php . . . p. 171 B.29 Arquivo: Disseminario.inc.php . . . p. 172 B.30 Arquivo: RecursoUmaPropostaDeSeminario.inc.php . . . p. 173 B.31 Arquivo: RecursoPropostasDeSeminario.inc.php . . . p. 177 B.32 Arquivo: RecursoAdministradores.inc.php . . . p. 179 B.33 Arquivo: RecursoUmaApresentacao.inc.php . . . p. 179 B.34 Arquivo: RecursoAdministrador.inc.php . . . p. 186 B.35 Arquivo: RecursoPropostaDeSeminario.inc.php . . . p. 188 B.36 Arquivo: RecursoUsuario.inc.php . . . p. 189 B.37 Arquivo: RecursoCoordenador.inc.php . . . p. 191 B.38 Arquivo: RecursoCadastroDeUsuario.inc.php . . . p. 191 B.39 Arquivo: RecursoApresentacao.inc.php . . . p. 192 B.40 Arquivo: RecursoCoordenadores.inc.php . . . p. 193 B.41 Arquivo: RecursoParticipantes.inc.php . . . p. 193 B.42 Arquivo: RecursoApresentacoes.inc.php . . . p. 194 B.43 Arquivo: RecursoCadastramento.inc.php . . . p. 196 B.44 Arquivo: RecursoSeminarios.inc.php . . . p. 200 B.45 Arquivo: RecursoUmArquivoDeApresentacao.inc.php . . . p. 201 B.46 Arquivo: Recurso.inc.php . . . p. 202 B.47 Arquivo: RecursoUsuarios.inc.php . . . p. 206 B.48 Arquivo: RecursoUmParticipante.inc.php . . . p. 207 B.49 Arquivo: RecursoSeminario.inc.php . . . p. 209
B.51 Arquivo: MensagemNaoPodeSerEnviada.inc.php . . . p. 213 B.52 Arquivo: Mensageiro.inc.php . . . p. 213 B.53 Arquivo: Requisicao.inc.php . . . p. 214 B.54 Arquivo: ArquivoDeConteudo.inc.php . . . p. 218 B.55 Arquivo: Arquivo.inc.php . . . p. 218 B.56 Arquivo: AutenticacaoBasica.inc.php . . . p. 219 B.57 Arquivo: AutenticacaoCondicional.inc.php . . . p. 219 B.58 Arquivo: Roteador.inc.php . . . p. 220 B.59 Arquivo: Rota.inc.php . . . p. 221 B.60 Arquivo: index.php . . . p. 222 B.61 Arquivo: PropostaDeSeminarioComFormulario.tpl.php . . . p. 224 B.62 Arquivo: Enlace.inc.php . . . p. 225 B.63 Arquivo: FormularioEnvioDeApresentacao.tpl.php . . . p. 225 B.64 Arquivo: Participante.tpl.php . . . p. 229 B.65 Arquivo: Cadastramento.tpl.php . . . p. 229 B.66 Arquivo: FormularioDeConfirmacaoDeCadastro.tpl.php . . . p. 229 B.67 Arquivo: FormularioPropostaDeSeminario.tpl.php . . . p. 232 B.68 Arquivo: Usuario.tpl.php . . . p. 236 B.69 Arquivo: UmaApresentacao.tpl.php . . . p. 236 B.70 Arquivo: TemplateXHTML.inc.php . . . p. 237 B.71 Arquivo: Mensagem.tpl.php . . . p. 238 B.72 Arquivo: Seminario.tpl.php . . . p. 238 B.73 Arquivo: Rodape.tpl.php . . . p. 240 B.74 Arquivo: Colecao.tpl.php . . . p. 241 B.75 Arquivo: Cabecalho.tpl.php . . . p. 242
Lista de abreviaturas e siglas
SOA Service-Oriented Architecture, p. 18 REST Representational State Transfer, p. 20 BDD Behaviour Driven Development, p. 46
TDD Test-Driven Development, p. 46
1
Introdução
Atualmente grande parte dos sistemas web são projetados baseados em uma arquitetura ori-entada a serviços (), muitas vezes inapropriada dada sua complexidade, que apresenta recursos avançados proveitosos apenas em contextos específicos.
Como alternativa tem-se o estilo arquitetural no qual a web foi projetada, REST, e uma série de boas práticas para o desenvolvimento de um sistema web que sigam as restrições REST, a arquitetura orientada a recursos.
Estas teorias foram aplicadas no desenvolvimento de um sistema web de apoio a seminários, o Disseminário, utilizando-se também de técnicas ágeis, como o desenvolvimento guiado por comportamento como metodologia.
Esta monografia é dividida em seis capítulos, no primeiro trata-se de REST, os estilos do qual se derivou e seus elementos arquiteturais. No segundo capítulo é tratado sobre Arquitetura orientada a recursos, seus conceitos, propriedades. O terceiro capítulo descreve a metodologia utilizada no projeto de sistemas orientados a recursos.No quarto é abordado o sistema Dissemi-nário de apoio a semiDissemi-nários. No quinto são expostos aspectos da implementação e no capítulo final, são apresentadas conclusões, resultados e propostas de trabalhos futuros.
1.1 Objetivo Geral
Compreender o estilo arquitetural REST e a Arquitetura Orientada a Recursos e aplicar estes conceitos no desenvolvimento de um sistema de apoio a seminários.
1.2 Objetivos Específicos
• Compreender o estilo arquitetural REST • Compreender a arquitetura orientada a recursos
• Desenvolver um sistema de apoio a seminários • Aplicar técnicas de desenvolvimento ágil
2
REST
Rest é um estilo arquitetural híbrido, derivado de vários estilos arquiteturais de software em rede. Ele foi proposto por Roy Fielding em 2000, na sua dissertação de doutorado[1], que buscou uma combinação de estilos arquiteturais de forma a compor um estilo que reunisse as melhores características1para um sistema distribuído de hipermídia.
Um estilo arquitetural é um conjunto coordenado de restrições arquiteturais, que recebe nome por facilidade de uso, sendo composto por restrições arquiteturais e elementos arquitetu-rais, estes, divididos em elementos de dados, conectores e componentes.
Estilos arquiteturais podem ser criados, sem o reuso de estilos pré-existentes, ou criados a partir de composição de estilos já existentes, REST se encaixa na última.
A cada adição de uma restrição a um estilo arquitetural, pode ocasionar a derivação de um novo estilo. O espaço de todos estilos arquiteturais pode ser visto com uma árvore, em que a raiz é o estilo nulo ou sem restrições, e a cada adição de uma restrição é criado um novo estilo, que por sua vez, pode dar origem a outro, caso seja adicionada a ele uma nova restrição.
2.1 Derivação de REST
REST foi derivado dos seguintes estilos: • Cliente/servidor
• Sem estado • Cache
• Interface Uniforme
1Performance em rede, performance percebida pelo usuário, eficiência, escalonabilidade, simplicidade, evolu-tividade, extensibilidade, personabilidade, configurabilidade, reusabilidade, visibilidade, portabilidade e confiabi-lidade.
• Sistema em Camadas • Código sob-demanda
2.1.1 Cliente/Servidor
A primeiro estilo arquitetural utilizado na derivação de REST foi o Cliente/Servidor. Nele são definidos dois papéis: o do servidor, que disponibiliza um conjunto de serviços, e do cliente, que faz uso destes serviços.
O servidor aguarda por requisições de clientes para uso de serviços, e ao recebê-las, toma a decisão de aceitá-las ou não.
Fielding considera a separação de preocupações como sendo o princípio por trás desta ar-quitetura. Um exemplo é o serviço de correio eletrônico. De um lado têm-se o leitor de correio eletrônico, que assume o papel de cliente, e do outro o servidor de correio eletrônico.
O leitor tem a preocupação de facilitar o gerenciamento e leitura de mensagens, através de uma interface gráfica operada pelo usuário. O servidor tem preocupações diferentes, como o armazenamento eficiente das mensagens e a rapidez no acesso as mesmas.
Fazendo-se tal separação, resta entre os dois uma interface comum, facilitando a portabili-dade do cliente e a simplificação do servidor, aumentando a escalonabiliportabili-dade.
A figura 2.1 ilustra o estilo arquitetural após a primeira restrição aplicada.
Figura 2.1: O estilo cliente servidor [1]
2.1.2 Sem-Estado
Na restrição Sem Estado o servidor não armazena qualquer informação de contexto, qual-quer informação necessária para atender a uma requisição deve estar contida nela mesma. Isto torna o servidor mais simples, pois ele não precisa levar em consideração o contexto atual para tomar decisões, toda informação necessária será enviada a ele a cada requisição.
. Pode-se citar a autenticação via cabeçalho HTTP como um exemplo da aplicação da restrição sem estado.
Numa primeira requisição enviada pelo cliente, o servidor responde com um cabeçalho exigindo autenticação, esse deve enviar as credenciais e aguardar pelo resultado, caso forem aceitas o servidor atenderá a requisição. O processo não se altera nas requisições seguintes, porém, o cliente poderá optar por armazenar as credenciais, para evitar que o usuário tenha de digitá-las novamente a cada requisição.
Pode-se dizer que com a inclusão desta restrição a escabilidade aumenta, pois o servidor não precisa armazenar dados de contexto entre requisições, podendo assim, liberar recursos. Como cada requisição porta todos os dados necessários para reconhecê-la, a visibilidade é aumentada.
A figura 2.2 evidencia o estilo arquitetural cliente/servidor sem estado.
Figura 2.2: O estilo Sem-Estado [1]
Algumas desvantagens do estilo Sem-Estado são a redundância dos dados, que precisam ser enviados novamente a cada requisição e a redução do controle por parte do servidor do funcionamento correto da aplicação, pois o cliente que efetua o controle do estado da aplicação.
2.1.3 Cache
A restrição arquitetural cache evita que dados já tenham sido enviados anteriormente ao cliente, sejam re-enviados. Para tanto, deve haver uma indicação implícita ou explícita em cada requisição, informando se deve ser utilizado cache ou não.
Segundo [1], a vantagem de se utilizar cache é a eliminação parcial ou total de algumas in-terações entre cliente/servidor. Melhorando a eficiência (menos dados trafegando com a mesma funcionalidade), escalabilidade (menos processamento e E/S) e a performance percebida pelo usuário (servidor menos carregado, menor tempo de resposta). Contudo, a confiabilidade é
Figura 2.3: O estilo Cache [1]
reduzida, pois pode acontecer de dados obtidos diretamente do servidor (sem uso de cache), se-rem substancialmente diferentes dos dados obtidos anteriormente com cache, isso depende da política adotada pelo cliente, que pode expirar uma requisição depois de n tempo ou trabalhar com requisições ’se modificado depois de’. O resultado da aplicação da restrição cache ao estilo Cliente/Servidor, Sem-Estado, pode ser visualizado na figura 2.3
2.1.4 Interface uniforme
A principal distinção entre REST e outros estilos arquiteturais para web é a enfâse no uso de uma interface uniforme entre seus componentes [1].
Com o uso de uma interface uniforme, a visibilidade de cada interação é aumentada pois o conjunto de métodos para cada elemento do sistema é conhecido, sendo assim, a cada execução de um método sua semântica é sempre conhecida. O sistema se torna mais simples, pois cada componente implementa os mesmos métodos.
Aplicando-se a restrição interface uniforme ao REST, verificamos o seguinte estilo 2.4
2.1.5 Camadas
Na restrição camadas, o sistema é dividido em camadas e a cada camada conhece apenas a fachada da camada seguinte, criando-se vários subsistemas. Essa restrição diminui a aco-plamento, pois cada camada tem acesso apenas a interface da camada seguinte, sem saber os detalhes de implementação desta.
Figura 2.4: Interface Uniforme [1]
à sua API, isso permite sua substituição, caso torne-se necessário.
2.1.6 Código sob demanda
O código sob demanda é a utilização de lógica armazenada no servidor, a ser executada pelo cliente. Desta forma, partes do cliente ficam pré-implementadas no servidor. Applets e código JavaScript armazenados no servidor, são exemplos de código sob demanda.
O código sob demanda é a única restrição arquitetural opcional de REST.
Figura 2.6: Código sob demanda [1]
2.2 Elementos Arquiteturais
2.2.1 Elementos de Dados
Os elementos de dados de um estilo arquitetural são os elementos de informação que são trocados entre componentes, via conectores. Rest possue três elementos de dados: Recursos, Identificadores de Recursos e Representações.
Recursos
Um recurso é qualquer informação que possa ser nomeada: um documento, uma imagem, um serviço metereológico, uma coleção de outros recursos, um recurso não virtual (por exemplo
uma pessoa) e assim por diante. Em outras palavras, qualquer conceito que possa ser sujeito a uma referência hipertextual se encaixa na definição de recurso [1].
Formalmente um recurso R é uma função de pertinência, que tem como domínio o tempo e como imagem um conjunto de entidades ou valores que são equivalentes, os valores neste conjunto podem ser representações de recurso e/ou identificadores de recurso. Um recurso pode mapear para o conjunto vazio, o que permite que referências sejam feitas antes de que qualquer implementação do conceito exista [1]. Um recurso é considerado dinâmico caso o conjunto de entidades ao qual mapeia varie com o tempo, ou estático caso contrário.
O recurso se refere ao mapeamento em si, e não ao conjunto de entidades ao qual ele mapeia. Por exemplo um recurso que corresponde a última versão de um software qualquer e outro que corresponde a versão 1.0 deste mesmo software, em um determinado instante de tempo podemos ter a versão 1.0 coincidindo com última versão, ambos os recursos estarão mapeando para a mesma entidade, mas estes recursos são diferentes pois suas semânticas são diferentes, podendo ser identificados e referenciados de forma independente.
Recursos generalizam várias fontes de informação, sem distinguir por tipo ou implementa-ção e permitem uma ligaimplementa-ção tardia entre recurso e representaimplementa-ção, permitindo que o conteúdo da resposta seja definido através de características da requisição e permitindo que o autor de uma referencia aponte para um conceito, e não uma representação única do mesmo, desta forma quando a representação for alterada não será necessário alterar as referências ao seu recurso (assumindo que o autor utilizou o identificador correto). [1]
Identificadores de recursos
A função do identificador de recurso é a identificação de um recurso envolvido em uma determinação interação. Todo recurso é referenciado por meio de um identificador de recurso, o responsável pelo identificador também é responsável por manter a validade semântica do mape-amento, garantindo que o identificador estará referenciando o recurso correto. O identificador de recurso utilizado na Web é a URI.
Representações
Componentes REST manipulam recursos usando uma representação para descrever o es-tado atual ou desejado do recurso e transferindo esta representação entre os componentes. Uma representação é uma sequência de bytes e meta-dados(informação sobre informação) para des-crever estes bytes [1]
Meta-dados são enviados como pares de nome-valor e podem descrever dados sobre o re-curso, uma de suas representações ou mesmo sobre outros meta-dados (esta referencia cíclica é geralmente utilizada para verificar a integridade de mensagens).
Dados de controle definem o propósito de uma mensagem entre os componentes como a ação requisitada ou o significado de uma resposta, estes dados tambem são utilizados para parametrizar uma requisição e alterar o comportamento padrão dos elementos conectados. Por exemplo o comportamento da cache pode ser modificado por dados de controle embutidos em uma requisição.[1]
O tipo de dados de uma representação é conhecido como tipo de mídia, uma representação pode ser entregue através de uma mensagem e processada pelo destinatário de acordo com os dados de controle e o tipo de mídia, tipos de mídia compostos podem envolver várias represen-tações em uma única mensagem.[1]
Podemos realizar a negociação de conteúdo baseada nos tipo de mídias disponíveis de uma representação, por exemplo um recurso ata de reunião pode ser representada por um documento, uma imagem da ata manuscrita ou mesmo uma gravação em um arquivo de áudio, a represen-tação pode conter meta-dados como: o número de páginas no caso do documento, tamanho em pixeis na imagem ou duração em segundos na gravação.
2.2.2 Componentes
Um componente é uma unidade abstrata de software, e um estado interno, que executa transformações em dados através de sua interface [1]. Pode-se definir também, como o elemento de um sistema que efetua computações [3]. Os componentes são os extremos nas interações, fazendo interface com o usuário. Exemplos de componentes estão expostos na tabela 2.1.
O componente agente de usuário utiliza um conector cliente para fazer requisições a um servidor de origem e receber respostas. Ele pode também, conectar-se a um proxy e fazer requi-sições a este, a fim encapsular a API de outros serviços, traduzir dados, melhorar a performance ou melhorar a aspectos de segurança [1]. Um gateway é um proxy inverso, imposto pelo agente servidor de origem, utilizado pelos mesmos motivos que levam o agente de usuário a utilizar um proxy.
Componente Exemplo WEB Atual servidor de origem apache
agente do usuário Firefox
gateway Squid
proxy Squid
Tabela 2.1: Componentes Conector Exemplo WEB Atual
cliente libwww servidor libwww
cache cache do navegador resolvedor libDNS
túnel SOCKS
Tabela 2.2: Conectores
2.2.3 Conectores
Os conectores são mecanismos abstratos de software que mediam comunicação, coordena-ção ou cooperacoordena-ção entre componentes[1]. REST possui uma série deles, como pode ser visto na tabela 2.2, com a finalidade de encapsular o acesso a recursos e a transferência de repre-sentações entre componentes. Por causa da interface uniforme de REST, os conectores podem ser facilmente substituídos, uma vez que compartilham da mesma interface, abstraindo-se os detalhes de implementação.
3
Arquitetura Orientada a Recursos
A arquitetura orientada a recursos é uma arquitetura que segue o estilo arquitetural REST, herdando dele, todas as restrições e elementos arquiteturais. Foi desenvolvida através de diver-sas observações empíricas por Sam Ruby e Leonard Richardson em [4].
ROA é uma arquitetura voltada para serviços web, sendo implementada a partir de tecnolo-gias da web como o protocolo HTTP[5] e a linguagem de marcação XML[6].
ROA também define algumas propriedades que uma aplicação que segue esta arquitetura deve possuir: Endereçabilidade, Sem-estado, Conectividade e Interface Uniforme.
3.1 Conceitos
Os conceitos de ROA são mais especificos que suas definições em REST, pois são utilizadas tecnologias web especificas nas definições.
3.1.1 Recursos
Em ROA a interface uniforme de cada recurso é definida pelo conjunto de métodos utiliza-dos no protocolo HTTP.
3.1.2 Identificadores de Recursos
Os identificadores de recursos devem ser URIs(Uniform Resource Identifiers)[7], que é o formato de identificadores utilizado na web. Além disso, as URIs devem ser descritivas e seguir uma certa estrutura.
A justificativa para a descritividade das URIs é que elas são intuitivas para o usuário, que deve poder lê-las e saber facilmente à que se referem.
URIs devem ter uma estrutura, variar de maneira previsivel, para facilitar seu uso por clien-tes sejam eles humanos ou máquinas.
Por exemplo, considere as seguintes URIs: Exemplo:
• /animal/Gato • /bicho/Tainha
Na listagem acima, há dois endereços para recursos com a mesma semântica informal: /bicho e /animal. Um usuário que acessar /animal/Gato pode querer acessar /animal/Tainha, caso o recurso endereçado por /animal/Tainha não esteja acessível teremos um problema, pois impedimos o usuário de acessar um recurso que é semânticamente válido mas não está acessível, pois não foi seguida uma estrutura previsível ao endereçar os recursos.
3.1.3 Representações
Representações são trocadas entre cliente e servidor através dos métodos HTTP.
Negociação de conteúdo pode ser efetuada através de meta-dados enviados nos cabeça-lhos das requisições, por exemplo o cabeçalho Accept pode ser usado em uma requisição para restringir o tipo de mídia (MIME Type) obtido na resposta.
Uma alternativa a utilização de meta-dados nos cabeçalhos das requisições é endereçar cada representação do recurso através de uma URI, por exemplo:
Um usuário acessando: /animal/Gato, utilizando o cabeçalho Accept na requisição um cli-ente pode decidir se deseja receber uma imagem ou informações textuais sobre gatos, como alternativa a isto podemos ter duas URIs /animal/Gato.txt designando informações textuais so-bre gatos e /animal/Gato.svg como uma imagem.
A vantagem de utilizar diferentes URIs para diferentes representações de um mesmo re-curso é que a informação está explicita na URI, este endereço pode ser copiado e passado adiante por um usuário.
A desvantagem é que os recursos endereçados por /animal/Gato.svg e /animal/Gato.txt pa-recem recursos diferentes, mas ambos descrevem o mesmo conceito, apenas com um formato diferente, uma solução para este problema é criar um URI canônica em /animal/Gato, nesta URI existiria uma representação que teria enlaces para todas as representações possíveis do recurso em questão.
3.2 Propriedades
3.2.1 Endereçabilidade
Uma aplicação é endereçavel quando um usuário pode acessar os dados, os recursos da aplicação, através de URIs.
Esta propriedade garante aspectos interessantes, por exemplo um usuário que queira procu-rar sobre buracos negros acessa a URI:
http://www.google.com.br/search?q=buraco+negro
Sua busca está endereçada, a URI pode ser copiada e passada adiante para que outros inte-ressados possam realizar a mesma busca.
Com endereçabilidade também é possível fazer cache de requisições, em uma rede local podemos ter uma máquina recebendo todas as requisições(um proxy HTTP), quando uma re-quisição é repetida podemos enviar um resultado salvo ao invés de consumir banda realizando a mesma requisição duas vezes, sem endereçabilidade não é possível saber quais requisições já foram efetuadas.
3.2.2 Sem-estado
Sem-estado significa que cada requisição HTTP ocorre em completo isolamento.
Quando o cliente envia uma requisição HTTP, ele inclue toda a informação necessária para que o servidor satisfaça a requisição. O servidor nunca se vale de informações de requisições anteriores.[4].
Por exemplo, um usuário que esteja na página dois da sua pesquisa sobre buracos negros, caso ele queira que outro usuários acesse a mesma busca, com os mesmos resultados ele pode copiar a URI:
http://www.google.com.br/search?q=buraco+negro&start=2
Neste caso a própria URI contém o estado da aplicação, e não o servidor, o que é evidenci-ado pela figura 3.1 que representa um diagrama de estevidenci-ados.
Caso esta informação estivesse no servidor este teria de gerenciar a informação do número da página de cada cliente da aplicação, e um novo cliente teria de efetuar transições realizando
Figura 3.1: Aplicação Sem-Estado
operações no servidor até chegar ao estado desejado, conforme pode ser verificado na figura 3.1.
3.2.3 Conectividade
Conectividade é a propriedade que permite que um cliente navegue por entre os recursos da aplicação através de enlaces hipermídia embutidos nas representações.
Quando um usuário acessa: http://www.google.com.br/search?q=buraco+negro ele recebe uma série de enlaces pelos quais pode navegar, podendo acessar um dos resultados da pesquisa, mudar de página, entre outras funcionalidades, conforme a figura 3.3.
Quando o servidor envia uma representação com enlaces, ele está enviando para o cliente uma série de URIs com estados possíveis da aplicação, é possível mostrar esta propriedade através de um grafo, onde os nodos são os recursos e as arestas enlaces ligando-os, conforme a figura3.4.
Figura 3.4: Uma aplicação conexa
3.2.4 Interface Uniforme
A interface uniforme define o conjunto de operações possíveis para cada recurso.
Estas operações são restritas aos métodos do protocolo HTTP, e são listadas abaixo, com a semântica associada:
• GET: Obtêm a representação de um recurso, assim como os meta-dados associados. • DELETE: Remove um recurso.
• PUT: Cria ou atualiza um recurso na URI especificada.
• POST: Cria um recurso subordinado ou anexa informações a um recurso, respondendo com a URI do novo recurso.
• OPTIONS: Lista quais os métodos que podem ser executados no recurso. • HEAD: Idêntico ao GET, mas omitindo a representação.
Idempotência e Segurança dos métodos da Interface Uniforme
Os métodos da interface uniforme de ROA, podem ser classificados quanto a sua idempo-tência e segurança.
Mtodo Seguro Idempotente GET X X PUT X POST DELETE X HEAD X X OPTIONS X X
Tabela 3.1: Segurança e Idempotência
Um método é idempotente quando a execução dele mais de uma vez consecutiva tem o mesmo efeito da execução do mesmo uma única vez, todo método seguro é também idempo-tente.
Os métodos GET, HEAD e OPTIONS são seguros e idempotentes, pois não alteram o estado do recurso.
PUT e DELETE não são seguros mas são idempotentes, uma sequência de requisições PUT idênticas irão manter o estado do recurso, assim como a requisição DELETE, que remove o recurso na primeira requisição e este continua não existindo se outras requisições DELETE forem efetuadas.
O método POST é o único método não-seguro e não-idempotente. Estas informações podem ser verificadas na tabela 3.1.
4
Metodologia
A metodologia de projeto foi baseada no procedimento descrito em [4] que descreve deta-lhadamente como desenvolver uma aplicação orientada a recursos.
Também foi utilizada a técnica ágil conhecida como Behavior Driven Development[8] na elaboração especificações executáveis que garantem o funcionamento do sistema e também podem ser usadas como documentação, pois descrevem todas as regras do negócio em uma linguagem próxima da natural.
4.1 Resumo do Procedimento
O procedimento proposto em [4] é dividido em nove passos: 1. Identificação dos dados do domínio
2. Definição dos recursos
3. Definição dos nomes dos recursos
4. Definição das operações sobre os recursos
5. Definição das representações aceitas pelo servidor 6. Definição das representações oferecidas pelo servidor 7. Interligação dos recursos
8. Definição das respostas bem sucedidas 9. Definição das respostas mal sucedidas
4.1.1 Identificação dos dados do domínio
Nesta etapa são identificadas quais as informações que serão fornecidas aos clientes do serviço, baseando-se no domínio da aplicação.
No Disseminário, temos diversos dados nos quais um cliente pode estar interessado, tais como: • Usuários • Seminários • Coordenadores de seminário • Participantes de um seminário • Apresentações
Podemos visualizar a relação entre os dados de domínio através de um diagrama entidade-relacionamento 4.1
4.1.2 Definição dos recursos
Com o conjunto de dados definido o próximo passo é definir como serão expostos como recursos HTTP, um recurso é qualquer coisa importante o suficiente para ser alvo de um hyper-link[4]. Nesta etapa são detalhados os dados do domínio para escolher como expô-los para o cliente.
Cada entidade de domínio possuí informações, seus atributos, por exemplo um seminário possuí um título e um tema, um usuário possuí um endereço de correio eletrônico, estas são informações que podem ser de interesse de um cliente, recursos acessíveis por ele.
Foi estabelecida uma relação direta entre as entidades e recursos, um recurso para cada entidade do domínio:
• Usuário • Seminário • Apresentação
Entidades derivadas de relações também podem ser referenciadas, tornando-as recursos. Um coordenador pode ser referenciado, assim como um participante, tornando-os endereçáveis. Quando uma proposta de seminário é feita ela deve ter um endereço, para que o administrador possa acessa-lá e decidir se irá aprovar ou não.
• Coordenador
• Participante de um seminário • Proposta de seminário
Um cliente pode estar interessado na lista de seminários, para publicar em seu blog, ou na lista de usuários, para entrar em contato com eles através de mensagens de correio eletrônico.
A lista de seminários e a lista de usuários são recursos de coleção, foram criados recursos de coleção para cada recurso de entidade:
• Usuários • Seminários
• Coordenadores
• Participantes de um seminário • Apresentações de um seminário • Propostas de seminários
Como os usuários interagem com o serviço através do navegador é preciso prover formulá-rios que possam ser renderizados pelo navegador, tais como 5.11, para que possam ser preen-chidos pelo usuário em enviados novamente ao servidor, tais formulários também são recursos.
• Formulário de cadastramento 5.1
• Formulário de confirmação de cadastramento 5.3 • Formulário de criação de proposta de seminário 5.11 • Formulário de envio de apresentação 5.19
Outro recurso criado foi o de cadastramento, que representa uma operação de criação de conta que ainda não foi concluída. O que motivou a criação deste recurso foi o fato da criação de conta ser feita em duas etapas, sendo criado o recurso na primeira etapa e tendo que persistir e ser endereçável para a confirmação na segunda, este recurso foi criado baseado na idéia de transação, exposta em [4].
4.1.3 Definição dos nomes dos recursos
Todo recurso deve ter um nome, estabelecido através de uma URI[4], além disso cada URI deve ser descritiva, de fácil entendimento para humanos, e seguir uma certa estrutura que varie o mínimo possível, evitando ambiguidades.
Na URI raiz do Disseminário são listados todos os seminários abertos ao público, os demais recursos de coleção são denotados pelo nome da coleção.
Abaixo podemos visualizar algumas URIs e as semânticas dos recursos identificados por cada uma delas, as URIs foram abreviadas para ficarem relativas ao endereço completo do Disseminário.
• /propostasDeSeminario : Coleção de propostas de seminário • /usuarios : Coleção de todos os usuários
• /administradores : Coleção de usuários que são administradores • /coordenadores : Coleção de usuários que são coordenadores
Foram criadas recursos relativos a outros recursos, todos os recursos estão vinculados ao recurso raiz mas podemos aprofundar estas relações, como por exemplo a coleção de partici-pantes ou as apresentações de um seminário, a barra neste caso fornece a idéia de escopo onde o recurso do lado direito da barra está vinculado ao recurso do lado esquerdo, como pode ser visto abaixo:
• /ArteBarroca : Seminário de arte barroca
• /ArteBarroca/participantes : Coleção de participantes do seminário de arte barroca • /ArteBarroca/apresentacoes : Coleção de apresentações do seminário de arte barroca
Um recurso que merece destaque é o arquivo da apresentação (que pode ser do formato odp,ppt ou pdf), usuários poderiam enviar sua apresentação em vários formatos para evitar pro-blemas relacionados a diferentes versões do software de visualização de apresentações, existem duas opções para representar tipos de mídia específicos, para possibilitar esta funcionalidade.[4]. Uma opção é a inclusão da informação do tipo de mídia no cabeçalho HTTP da resposta através da propriedade Content-Type, desta forma uma mesma URI pode servir representações de tipos diferentes de mídia, um cliente acessaria /ArteBarroca/Aleijadinho/apresentacao po-dendo escolher qual tipo de mídia quer receber na resposta, informando no cabeçalho de sua requisição a propriedade Accept.
A outra opção é estabelecer URIs diferentes para cada tipo de mídia, tais como: • /ArteBarroca/Aleijadinho/apresentacao.pdf
• /ArteBarroca/Aleijadinho/apresentacao.odp
Nesta opção o tipo de mídia fica explícito na URI, tornando mais claro para o usuário o que está sendo requisitado. Esta foi a opção escolhida no Disseminário.
/ Todos os seminários públicos /propostasDeSeminario Propostas de seminário
/usuarios Todos os usuários
/coordenadores Usuários que são coordenadores /ArteBarroca Seminário de arte barroca
/ArteBarroca/participantes Participantes do seminário de arte barroca /ArteBarroca/apresentacoes Apresentações do seminário de arte barroca /ArteBarroca/participante/[email protected] Participante do seminário de arte barroca
/ArteBarroca/Aleijadinho/apresentacao.pdf Arquivo pdf da apresentação de título Aleijadinho /ArteBarroca/Aleijadinho/apresentacao.odp Arquivo odp da apresentação de título Aleijadinho /ArteBarroca/apresentacao Formulário de envio de apresentação
/ArteBarroca/apresentacao/Aleijadinho Apresentação de título Aleijadinho /usuario/[email protected] Usuário
/administrador/[email protected] Usuário administrador /coordenador/[email protected] Usuário coordenador de /cadastramento Formulário de cadastramento
/cadastramento/[email protected] Processo de cadastramento do usuário /propostaDeSeminario Formulário de proposta de seminário /propostaDeSeminario/2 Proposta de seminário de código dois
Tabela 4.1: URIs de Recursos
4.1.4 Definição das operações sobre os recursos
Neste ponto, é necessário decidir quais os métodos da interface uniforme serão permitidos em cada recurso. Esta escolha é uma decisão de projeto e guiada pelo poder que se deseja conferir aos clientes.
Como descrito na seção 3.2.4, a interface uniforme de ROA é composta pelos métodos HTTP. A decisão de implementar ou não um método pode ser tomada a partir de perguntas, relativas as ações que os clientes poderão efetuar em um determinado recurso:
• Os clientes poderão ler o recurso? Se sim, implementar GET
• Os clientes poderão criar novos recursos deste tipo? Caso afirmativo. Quem está encar-regado de saber onde ficarão os novos recursos criados? Se o cliente, implementar PUT, caso seja o servidor, implementar POST.
• Os clientes irão atualizar dados do recurso? Em caso afirmativo, implementar PUT • Os cliente irão remover recursos deste tipo? Se sim, implementar DELETE
Os outros dois métodos da interface uniforme, HEAD e OPTIONS, provêm dos métodos já definidos. O método HEAD, por diferenciar-se do método GET apenas por não enviar o corpo
Recurso URI GET POST PUT DELETE Administradores /administradores X
Apresentações /{seminário}/apresentacoes X Arquivo de apresentação /{seminário}/{apresentação}/{arquivo} X
Coordenadores /coordenadores X Participantes /{seminário}/participantes X Raiz ou Seminários / X Usuários /usuarios X Administrador /administrador/{correioEletronico} X X X Apresentação /{seminário}/{apresentação} X X X Cadastramento /cadastramento/{correioEletronico} X X X Coordenador /coordenador/{correioEletronico} X X X Participante /participante/{seminário}/{correioEl..} X X X Proposta de Seminário /propostaDeSeminario/{codigo} X X X Propostas de Seminários /propostasDeSeminario X X
Usuário /usuario/{correioEletronico} X X
Tabela 4.2: Métodos implementados nos Recursos da representação, será implementado somente caso o método GET o seja.
O método OPTIONS tem a função de informar quais métodos são permitidos no recurso, sendo implementado em todos eles.
A tabela 4.1.4 evidência as decisões tomadas para cada recurso. Recursos que somente implementam GET são somente leitura. Para este tipo de recurso, tomou-se a decisão de não dar o poder ao cliente de apagar ou atualizar coleções inteiras.
Um recurso de somente leitura particularmente interessante é o Arquivo de Apresentação, criado a partir do momento em que um recurso Apresentação é criado, sendo seu ciclo de vida vinculado a um recurso de Apresentação.
A vários recursos que implementam um mesmo conjunto de operações que o recurso de Administrador, estes são atualizáveis e deléveis, sendo escolhido o cliente como o responsável por saber onde um novo recurso do tipo fica ao ser criado, razão do PUT para criação.
No recurso Propostas de Seminários, decidiu-se que o servidor seria o encarregado de saber onde ficariam os novos recursos, já que podem haver várias propostas criadas por usuários, inclusive com mesmo nome, justificando-se a implementação de POST.
O recurso Usuário não possuí método PUT/POST, portanto não é possível para um cliente criar um usuário com uma operação, o que se deve ao fato da criação de usuários dar-se em duas etapas, efetuadas através de um transação de cadastramento.
4.1.5 Representações aceitas pelo servidor
O principal critério na escolha de representações é o tipo de representação que os clientes desejam consumir. A metodologia ROA propõe que sejam utilizadas representações comuns a web, como codificação de formulário, XML, JSON e XHTML.
Como nossos clientes são o navegador web e um cliente automatizado, é necessário utilizar representações de entrada que possam ser facilmente geradas por eles. Por isso, decidiu-se optar pela codificação de formulário, que é uma representação nativa nos navegadores e com suporte no cliente verificador de especificações.
4.1.6 Definição das representações oferecidas pelo servidor
Como já dito na seção 4.1.5, a escolha de representações depende dos clientes.
Buscou-se uma representação de saída que pudesse ser renderizada por um navegador e apresentasse fácilidade para um cliente automatizado extrair as informações de que precisa.
Foi escolhido o formato XHTML[9], por ser XML[6], o que garante boa formação e facili-dade extração de informações através de um parser e também renderizável em um navegador. Além disto é uma representação hipermídia, permitindo a ligação entre recursos. Por tais vanta-gem, o formato XHTML foi adotado como representação de saída de todos os recursos, exceto o Arquivo de Apresentação. Neste recurso, a representação é o próprio arquivo de uma apre-sentação enviada por um participante de seminário.
A listagem 4.1 é um exemplo de representação XHTML.
Listagem 4.1: Representação XHTML com Marcações Descritivas < u l c l a s s =" s e m i n a r i o s "> < l i > <a h r e f =" h t t p : / / d i s s e m i n a r i o . e d u g r a f . u f s c . br / S u r r e a l i s m o " c l a s s =" s e m i n a r i o "> S u r r e a l i s m o </ a> </ l i > < l i > <a h r e f =" h t t p : / / d i s s e m i n a r i o . e d u g r a f . u f s c . br / Realismo " c l a s s =" s e m i n a r i o "> Realismo </ a>
</ l i > </ ul >
4.1.7 Interligação dos recursos
Um dos aspectos mais importantes no projeto ROA é a propriedade de conectividade, que é obtida durante esta fase do projeto. Busca-se interligar os recursos de maneira que se tenha uma navegabilidade ótima no sistema, com o critério de que as ligações entre recursos façam sentido.
Não se busca um grafo totalmente conexo como o resultado das interligações entre os re-cursos, mas sim, o máximo de ligações coesas.
Observando-se o grafo da modelagem das interligações de recursos no Disseminário, na figura 4.2, verifica-se uma boa conectiviade no sistema. Pois, a partir de qualquer recurso, consegue-se chegar a outro recurso que tenha alguma relação com esse.
Como exemplo de boa modelagem, pode-se citar a ligação entre o seminário “História de Arte” e Participantes, Apresentações e Coordenador. Todas estas informações são realmente pertinentes ao seminário em questão, e, além de conseguir chegar até elas a partir do recurso do seminário, é possível voltar ao seminário posteriormente, caso se queira.
4.1.8 Definição das respostas bem sucedidas
Nesta etapa é definida a interação entre cliente e servidor nos casos normais, aqueles em que nenhum erro ocorreu.
Deve ser respeitado o protocolo HTTP, que define códigos de resposta de acordo com a requisição que foi feita, além de estabelecidas quais serão as representações enviadas em cada resposta.
Requisições GET e DELETE, quando efetuadas com sucesso, devem receber no cabeçalho da representação da resposta o código 200 ("OK"), e no seu corpo as informações desejadas, por exemplo no Disseminário um GET em Usuários obtém uma lista de usuários, uma opera-ção DELETE nas propostas de seminário retorna uma página informando que a proposta foi removida com sucesso.
Requisições PUT e POST, quando efetuadas com sucesso, devem receber no cabeçalho da representação da resposta o código 201 ("Criado"), no caso de uma requisição POST é incluído
um paramatro Location contendo a URI de onde o recurso foi criado, por exemplo, o endereço de uma proposta de seminário quando é efetuado um POST no recurso Propostas de Seminários. Neste ponto também são consideradas questões de cache, um cliente pode ignorar repre-sentações de recursos que não tenham sido atualizadas depois de um determinado periodo para economizar tempo e largura de banda, mas cabe ao servidor verificar se o recurso foi atualizado, repondendo com a representação toda caso tenha sido, ou então respondendo com o código 304("Não Modificado") e omitindo o corpo da representação. Todavia não foi implementado mecânismo de cache no Disseminário.
4.1.9 Definição das respostas mal sucedidas
Quando algo ocorre de errado na interação entre as partes comunicantes o servidor deve responder com códigos HTTP nas faixas: 3xx, 4xx, ou 5xx.
Códigos de erros são importantes pois explicitam o motivo do erro, por exemplo, caso um cliente envie uma representação com erros em uma requisição PUT, o servidor deve responder com o código 400("Requisição Incorreta") de forma que o cliente identifique a causa pela qual sua requisição não teve o efeito desejado.
Além dos códigos de erro no Disseminário são enviadas páginas XHTML que descrevem o motivo do erro e possuem ligações hipermídia, para que o usuário possa contornar esta situação. Uma documentação completa descrevendo os códigos de resposta do protocolo HTTP 1.1 pode ser encontrada em ??.
4.2 Desenvolvimento Guiado por Comportamento
O Desenvolvimento Guiado por Comportamento (Behaviour Driven Development) é uma técnica de desenvolvimento ágil que tem ênfase na descrição do comportamento da aplicação. Ela foi criada por Dan North [8], que enfrentava problemas ao ensinar Programação Guiada por Testes para seus alunos: o que testar, como dar nome aos testes e como entender porque um teste falhou [8].
O foi criado a partir do , que é uma técnica de desenvolvimento ágil na qual todo o código é originado a partir de testes, uma inversão do paradigma tradicional de codificação.
A cada ciclo de TDD o programador assume diversos papéis, o de testador quando cria testes, o de analista quando busca formas de resolver o problema utilizando testes, o de projetista
Figura 4.3: O ciclo TDD [2]
quando fatora o código para melhorar o projeto e de programador quando faz o código para passar nos testes. O ciclo TDD pode ser observado na figura 4.3.
No Desenvolvimento Guiado por Testes normalmente se tem para cada classe do modelo uma classe de testes [10], que possui uma série de métodos.
No Desenvolvimento Guiado por Comportamento a palavra ”teste” é abolida. Ela é substi-tuida por Histórias, Cenários e Expectativas. O que torna mais fácil saber onde e o que testar, pois as histórias e cenários são as próprias especificações do sistema, que vêm diretamente do cliente do software e definem o ponto de partida. Desta maneira, não dependendo da criativi-dade do programador, como acontece em TDD.
O uso de uma linguagem próxima da natural facilita a criação da especificação, pois, pode-se usar uma linguagem muito parecida com a do cliente, que em pode-seguida, pode-se tornará código executável.
4.2.1 Histórias
As histórias são descrições de funcionalidades, os cenários são contextos para a ocorrência das histórias e as expectativas são o que se espera que aconteça em determinados cenários de uma história. Sendo assim, as histórias são compostas de cenários, estes, compostos por pré-condições e expectativas.
Assim como o [11], o BDD propõe que se faça uso de linguagem ubíqua[8]. Escolheu-se o Escolheu-seguinte modelo para a escrita de histórias, oque culminou no estabelecimento de uma linguagem comum:
História: {Título da história} Eu como {um papel}
Quero {ação}
Para {resultado esperado} Cenário: {Título do cenário} Dado que {pré-condição} Caso {ação}
Então {expectativas}
A partir do momento que se tem a história escrita, ela pode ser transformada em código executável.
4.2.2 BDD no Disseminário
No Disseminário, todas as histórias foram escritas em linguagem natural e depois passadas para código executável. Em termos de código foi utilizada a linguagem Java e o arcabouço JUnit, além de adotada a seguinte estrutura para representar as especificações:
• pacote: nome corresponde ao nome da história
• classes do pacote: nomes correspondentes aos cenários da história • métodos das classes: pré-condições e expectativas dos cenários
Abaixo, segue um exemplo de história “Usuário Participando de Seminário” que foi imple-mentada no Disseminário:
História: Usuário Participando de Seminário Eu como um usuário
Quero participar de um seminário Para poder publicar uma apresentação
Cenário: Quando existe o Seminário
Dado que existe o usuário [email protected] e que existe o seminário de nome “Um Seminário”
Caso o usuário [email protected] envie uma solicitação de partici-pação para o seminário “Um Seminário”
Então Deve ser criado um participante em /UmSeminario/participante/[email protected]
de nome “Fulano”
de endereço de correio eletrônico “[email protected]” Deve existir um enlace em “/UmSeminario/participantes/”
apontando para “/UmSeminario/participante/[email protected]”. A história acima foi transformada em código Java1, como pode ser observado na listagem
4.2.
Listagem 4.2: História: Usuário Participando de Seminário
package u s u a r i o P a r t i c i p a n d o D e S e m i n a r i o ; p u b l i c c l a s s QuandoExisteOSeminario extends I n f r a E s t r u t u r a D e E s p e c i f i c a c a o { p u b l i c s t a t i c void considerandoQue ( ) { e x i s t e O U s u a r i o _ u s u a r i o D o D i s s e m i n a r i o _ a r r o b a _ e d u g r a f _ ufsc_br_de_nome_Fulano ( ) ; existeUmSeminario_de_nome_UmSeminario ( ) ; } p u b l i c s t a t i c void caso ( ) { o U s u a r i o _ u s u a r i o D o D i s s e m i n a r i o _ a r r o b a _ e d u g r a f _ u f s c _ b r _ e n v i e U m a S o l i c i t a c a o D e P a r t i c i p a c a o P a r a O S e m i n a r i o _UmSeminario ( ) ; } p u b l i c void e n t a o ( ) { d e v e S e r C r i a d o U m P a r t i c i p a n t e E m _ s e m i n a r i o _ U m S e m i n a r i o _ p a r t i c i p a n t e _ u s u a r i o 1Todas as histórias estão no anexo A
D o D i s s e m i n a r i o _ a r r o b a _ e d u g r a f _ u f s c _ b r ( ) ; deNome_Fulano ( ) ; d e E n d e r e c o D e C o r r e i o E l e t r o n i c o _ u s u a r i o D o D i s s e m i n a r i o _ a r r o b a _ e d u g r a f _ u f s c _ b r ( ) ; d e v e E x i s t i r U m E n l a c e E m _ s e m i n a r i o _ U m S e m i n a r i o _ p a r t i c i p a n t e s _ deTexto_Fulano ( ) ; a p o n t a n d o P a r a _ s e m i n a r i o _ U m S e m i n a r i o _ p a r t i c i p a n t e _ u s u a r i o D o D i s s e m i n a r i o _ a r r o b a _ e d u g r a f _ u f s c _ b r ( ) ; }
Uma vez que a história é transformada em código, não há mais necessidade de manter a história em texto, pois é possível obter o texto a partir da história em código. E essa é uma das grandes vantagens de se ter especificações executáveis: a sincronia que mantida entre elas e o código. Qualquer alteração que se faça na especificações é registrada diretamente no código, já que a especificação é código, mantendo as especificações sempre atualizadas.
5
Disseminário
O Disseminário é uma aplicação de apoio a seminários, que permite aos seus usuários se cadastrarem, criarem e participarem de seminários e publicarem apresentações.
Como cliente e interface com o usuário, foi utilizado o navegador web, cabendo ao servidor fornecer representações que pudessem ser renderizadas e manipuladas pelo navegador.
Também foi desenvolvido um cliente para realizar testes automatizados que verificam se o sistema está de acordo com as especificações, como descrito na seção 4.2.
5.1 Descrição das funcionalidades
Nesta seção iremos detalhar as funcionalidades do Disseminário, descrevendo-as e mos-trando algumas imagens de telas do sistema.
5.1.1 Criação de conta
Para participar de um seminário ou publicar uma apresentação é necessário que o usuário possua uma conta no sistema. Cada conta de usuário é identificada por um endereço de correio eletrônico, para garantir a autenticidade de uma conta o cadastro se dá em duas etapas.
Na primeira etapa o usuário informa seu endereço de correio eletrônico e uma mensagem é enviada para o endereço informado, como pode ser observado nas figuras 5.1 e 5.2 respectiva-mente.
Na segunda etapa, o usuário acessa a URI que recebeu na mensagem de correio eletrô-nico, esta URI contém um código criado através da aplicação de uma função hash a um dado pseudo-aleatório, desta forma somente um usuário que tenha recebido a mensagem de correio eletrônico poderá continuar com o processo de cadastramento, garantindo sua responsabilidade pelo endereço de correio eletrônico informado.
Figura 5.1: Primeira etapa do cadastramento
Ao acessar esta URI, é requisitado ao usuário o preenchimento de seu nome e senha, con-forme observado na figura 5.3.
Figura 5.3: Segunda etapa do cadastramento
Ao finalizar seu cadastramento, o usuário recebe uma mensagem de correio eletrônico in-formando que sua conta foi criada e contendo sua senha, para acesso posterior, oque pode ser visto na figura 5.4.
O cadastramento agora foi finalizado, e o usuário pode se autenticar no sistema utilizando sua conta.
Também é incluído um enlace para sua página de usuário 5.5 na lista de usuários do Disse-minário5.6.
Figura 5.4: Mensagem de conta criada
Figura 5.5: Página de um usuário do Disseminário
5.1.2 Autenticação
Muitas funcionalidades só estão disponíveis para usuários autenticados, tais como a publi-cação de apresentações em um seminário.
Para se autenticar, o usuário necessita acessar o enlace de autenticação, que está presente nas páginas do sistema 5.7.
Figura 5.6: Lista de usuários do Disseminário
Figura 5.7: Enlace de autenticação
Após acessar uma URI de autenticação o usuário necessita de informar seu endereço de correio eletrônico e sua senha para efetuar a autenticação5.8.
Depois de autenticado, o usuário poderá navegar pelo sistema acessando funcionalidades até então indisponíveis, podendo desautenticar quando desejar para voltar a navegar como um visitante, conforme a figura 5.9.
Figura 5.8: Janela de autenticação
5.1.3 Criação de Proposta de Seminário
Para criar uma proposta de seminário, o usuário deve se autenticar e clicar no enlace que irá aparecer, como na figura 5.10, preencher um formulário com dados sobre o seminário que deseja criar conforme a figura 5.11, quando enviar este formulário, será criada uma proposta em uma URI baseada no nome do seminário, e enviada uma mensagem de correio eletrônico para o administrador do Disseminário.
Figura 5.10: Enlace de proposta de seminário
5.1.4 Aprovação de Proposta de Seminário
Depois que uma proposta de seminário é feita, o administrador do Disseminário recebe uma mensagem de correio eletrônico, nesta mensagem esta o endereço para que ele acesse a proposta que foi criada.
Ao acessar o endereço da proposta, o administrador terá de se autenticar, podendo então visualizar as informações da proposta, como na figura 5.12, tendo a opção de aprovar a proposta ou deixa-lá pendente.
Quando o administrador aprova uma proposta, um seminário é criado e seu proponente é avisado através de uma mensagem de correio eletrônico.
O seminário criado, figura 5.13, passa a ser listado na página principal do Disseminário, a exemplo da figura 5.14.
Figura 5.12: Página de uma proposta de seminário
5.1.5 Participação em Seminário
Um usuário pode participar de um seminário se estiver autenticado e acessar o seminário, onde estará disponível a opção de participar do mesmo, como pode ser visto na figura 5.15.
Após participar de um seminário o usuário é incluído um enlace para sua página de partici-pante, como na figura 5.16 e na lista de participantes do seminário a exemplo da figura 5.17.
5.1.6 Publicação de Apresentação
Para publicar uma apresentação em um seminário, o usuário deve estar autenticado e ser um dos participantes do seminário.
Ao acessar o enlace de publicação de apresentação como o observado na figura 5.18, o usuário é levado a página de publicação como observada na figura 5.19, onde deve fornecer um título e enviar um arquivo da apresentação, ao enviar o formulário será publicada a apresentação. Após publicada, a apresentação ficará disponível na lista de apresentações do seminário, como pode ser visto na figura 5.20, onde poderá ser acessada por outros usuários 5.21.
Figura 5.14: Página principal do Disseminário
Figura 5.16: Página de um participante de um seminário
Figura 5.18: Enlace para publicação de apresentação
Figura 5.20: Lista de apresentações de um seminário
5.2 Papéis de Usuários
As funcionalidades disponíveis a um usuário são determinadas pelo seu papel no sistema. Existem quatro papéis diferentes:
• Visitante • Usuário • Coordenador • Administrador
A relação entre um papel e suas permissões pode ser descrita através de uma hierarquia, onde as permissões de um papel são herdadas pelo papel acima na relação hierárquica, repre-sentada na figura 5.22, onde a seta representa a relação de herança de permissões, por exemplo o administrador herda todas as permissões do coordenador, além de possuir permissões as quais o coordenador não possuí.
Figura 5.22: Hierarquia de papéis de usuários
5.2.1 Visitante
Um usuário não autenticado é um visitante, um visitante pode acessar as seguintes funcio-nalidades:
• Criação de conta de usuário
• Acesso a página principal, listando todos os seminários • Acesso a lista de usuários
• Acesso a página de um usuário
• Acesso aos participantes de um seminário • Acesso as apresentações de um seminário • Acesso a uma apresentação de um seminário
5.2.2 Usuário
Um usuário que tenha uma conta e esteja autenticado tem as seguintes permissões: • Propor um seminário
• Participar de um seminário
• Publicar uma apresentação em um seminário do qual participe
5.2.3 Coordenador
Quando um usuário tem sua proposta de criação de seminário aprovada ele se torna coor-denador de seminários, podendo criar seminários sem precisar de aprovação do administrador.
5.2.4 Administrador
Quando uma proposta de criação de seminário é feita o administrador a recebe, ele é res-ponsável por julgar se a proposta é válida aprovando-a ou deixando-a pendente.
6
Implementação
Este capítulo descreve a implementação do Disseminário, explicitando a organização de seus módulos e as tecnologias utilizadas na implementação.
6.1 Disseminário
A implementação do Disseminário foi realizado utilizando-se a linguagem de programação PHP, uma linguagem interpretada e fracamente tipada, criada em 1995 para a criação de páginas web dinâmicas, podendo ser embutida em páginas HTML[12].
Foi utilizada a versão 5 da linguagem, que possuí um suporte mais completo a orientação a objetos que sua predecessora.
6.1.1 Arquitetura
O disseminário é um sistema em camadas, conforme pode ser visto na figura 6.1 cada camada á um subsistema que oferece serviços somente para a camada imediatamente superior.
As requisições HTTP são tratadas pela camada de serviços, ocasionando chamadas as ca-madas subsequentes e por fim uma resposta contendo uma representação á enviada para o cli-ente que originou a requisição, desta forma a camada de serviços é a única interface do sistema para com o cliente, reduzindo-se o acoplamento com o mesmo. Esta interação entre cliente e servidor pode ser visualizada na figura 6.2.
6.1.2 Camada de serviços
A camada de serviços foi implementada de forma a receber todas as requisições HTTP feitas para o servidor, direcionando-as para uma fachada.
Figura 6.1: Arquitetura do Disseminário
camada de negócios, a estes tratadores é dado o nome de Recurso.
Na modelagem foi utilizada uma metáfora de roteamento, onde uma Rota é a ligação entre uma fámilia de URIs e o Recurso responsável pelo seu tratamento, sendo a responsabilidade de identificar a qual rota corresponde uma requisição delegada a classe Roteador.
Outro aspecto importante da camada de serviços foi a autenticação, alguns recursos não podem ser acessados por usuários não autenticados, outros tem seus métodos restringidos de-pendendo do papel do usuário que o esta acessando.
Como forma de autenticação foi utilizada a autenticação HTTP do tipo Basic, de maior facilidade de implementação.
Algumas dificuldades foram encontradas ao utilizar autenticação HTTP pura, sem Cookies e sem uso sessão. Certos recursos tem representações diferentes quando um usuário esta auten-ticado, por exemplo ao acessar um seminário sem autenticação um usuário só poderá visualizar as informações do seminário, mas se estiver autenticado ele terá possibilidade de participar do mesmo, mudando a representação que agora terá um botão, o problema é que não é possível determinar se um usuário está autenticado a não ser que o servidor peça autenticação a ele, ne-gando o acesso caso o usuário não possua conta no sistema mesmo que o recurso acessado seja público para leitura.
Este problema foi resolvido utilizando um parâmetro adicional nas URIs, ao se autenticar um usuário passa a navegar com um parâmetro “?autenticar=verdadeiro” no sufixo de todas as URIs que visitar.
O outro problema foi relativo a desautenticação no sistema, infelizmente os navegadores não possuem uma forma padrão de desautenticar(via JavaScript por exemplo), alguns acabam guardando em cache as credenciais do usuário, fazendo que o único modo de desautenticar seja fechando o navegador ou limpando manualmente o cache, a solução encontrada[13] foi utilizar requisições AJAX(Asynchronous Javascript And XML) para enviar uma requisição com credenciais falsas para um recurso protegido, o que tem como efeito colateral a remoção das credenciais gravadas no cache do navegador.
6.1.3 Modelo de negócios
No cerne do modelo de negócios estão os Recursos, cada recurso definido em 4.1.2 corres-ponde a uma classe de Recurso, que implementa os métodos da interface uniforme definidos para ele em 4.1.4, conforme pode ser visto no diagrama de classes parcial em 6.3 que mostra a
