Gerenciamento de URIs

No processo de criação do conjunto de dados, a aplicação Web realiza comunicação com o servidor para criar um identificador persistente para o conjunto de dados. Assim, é enviado o título do conjunto de dados e o sistema devolve o identificador a partir dele. Dessa forma, esse identificador é utilizado para gerar as URIs de acesso para cada conjunto de dados e seus respectivos itens, como distribuições e versões, tanto por meio da interface Web quanto por meio da API. A Figura 6.14 exemplifica o processo de criação de identificador automático.

Figura 6.14: Exemplo de criação de identificador automático. Fonte: o autor

6.2.2.2 Gerenciamento de Distribuições

Para as distribuições, conforme informado anteriormente, por uma decisão arquitetural, optamos por gerar as distribuições logo após a recuperação dos dados e nos três formatos disponíveis. Com a estrutura adotada no desenvolvimento da prova de conceito, novos formatos podem ser facilmente adicionados e também é possível conceder a opção para o produtor selecionar os formatos desejados dentre os disponíveis.

Na Figura 6.16 é possível visualizar as distribuições disponíveis após o cadastro de um conjunto de dados. Assim como os demais itens da interface, o acesso às distribuições também é gerado dinamicamente consumindo a API e verificando os formatos disponíveis.

6.2.3

Gerenciamento de metadados

Conforme descrito anteriormente e apresentado na Figura 6.13 (criação de conjunto de dados), nesta prova de conceito utilizamos um subconjunto de metadados do DCAT e DCMI. Este subconjunto compreende tanto metadados descritivos quanto metadados de licença, proveniência, cobertura e de atualização. Vale salientar que é necessário informar todos os metadados para realizar o cadastro de um conjunto de dados. Na Figura 6.16 são ilustrados os metadados armazenados no MongoDB e os metadados que são exibidos por meio da API, ambos no formato JSON.

Figura 6.16: Metadados exibidos por meio de uma consulta no MongoDB (a) e os metadados recuperados por meio da API pública do sistema (b). Fonte: o autor

6.2.4

Gerenciamento de Versões

Desenvolvemos um gerenciamento de versões automatizado que considera cada alteração em um conjunto de dados como uma nova versão do mesmo. Assim, tornou-se possível manter um histórico com todas as versões geradas do conjunto de dados, bem como possibilitar a recuperação dos dados das respectivas versões.

Dado que o gerenciamento é automático, o sistema utiliza, como código indicador de versão, uma tag com um timestamp gerado a partir da data e hora do momento em que o conjunto

6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 101

de dados foi alterado. Além disso, a menos que seja especificada uma versão, o sistema sempre retornará os dados mais recentes do conjunto de dados quando ele for referenciado. Ao acessar a descrição de um conjunto de dados via interface Web, o sistema lista todas as versões geradas, conforme pode ser visto na Figura 6.17.

Figura 6.17: Histórico das versões geradas de um conjunto de dados. Fonte: o autor

Desejando recuperar os dados de alguma versão específica, é possível realizar filtros no histórico de versões acima e acessar a versão desejada clicando na descrição da versão. Dessa forma, o sistema vai permitir acesso a versão desejada, possibilitando visualizar os metadados da versão e recuperar os respectivos, conforme pode ser visto na Figura 6.18.

Figura 6.18: Acesso a uma versão específica de um conjunto de dados. Fonte: o autor

6.2.5

Gerenciamento de Atualizações

Este serviço garante que o conjunto de dados permanece atualizado de acordo com a frequência de atualização definida na criação do conjunto de dados. Para tanto, este serviço faz uso do agendador de tarefas do Spring, por meio da anotação @Schedule, que permite especificar

Figura 6.19: Método que implementa o agendador de tarefas automático. Fonte: o autor

Além da atualização automática dos conjuntos de dados a partir de sua frequência de atualização, também é possível efetuar a atualização manual. Assim, sendo necessário refletir alterações das fontes de dados no conjunto de dados publicado antes da atualização automática, o produtor pode acessar o conjunto de dados e informar que deseja processar uma atualização, conforme mostra a Figura 6.20.

Figura 6.20: Atualização manual (não programada) de um conjunto de dados. Fonte: o autor

6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 103

6.2.6

Gerenciamento de Acesso

Nesta versão da solução, o serviço de gerenciamento de acesso permite que os dados armazenados no MongoDB sejam recuperados por meio de download em massa e por meio de APIs. Apesar de ainda não ser possível definir os subconjuntos de dados ao criar um conjunto de dados, é possível recuperar subconjuntos a partir da API, assim como utilizá-la para realizar o download dos dados no formato indicado. A interface Web do produtor e consumidor fornece links que permitem acessar os dados e metadados por meio da API de forma fácil.

Com o uso deste serviço, sempre que o produtor realizar o cadastro de um conjunto de dados, o sistema automaticamente permitirá a recuperação deles por meio da API, assim como permitirá o download dos dados nos formatos configurados no sistema. A Figura 6.21 mostra tais opções a partir das interfaces Web.

Figura 6.21: Métodos de acesso aos conjuntos de dados

Também utilizamos o Spring para construir a API com os padrões arquiteturais REST. De modo geral, o Spring permite construir uma API usando a anotação @RestController em uma classe Java, definindo os mapeamentos entre as rotas da API e ações, além do verbos HTTP necessários para processar as requisições.

Figura 6.22: Exemplo de método e rota da API. Fonte: o autor

A API AdminREST é acessível por <http://sgdw.azurewebsites.net:8080/admin>. Uma vez que ela é voltada para atividades de cadastro e gerenciamento dos conjuntos de dados pelo produtor, para acessá-la é necessário fornecer um token que é obtido após o login. Conforme pode ser visto na Figura 6.22, o token deve ser enviado juntamente com os demais dados, ou seja, no exemplo ilustrado o token é enviado junto aos dados do novo conjunto de dados e o Spring se encarrega de mapeá-los na classe NovoDataset. Se o token informado for válido, o conjunto de

Figura 6.23: API AdminREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor

Figura 6.24: API OpenREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor

A documentação foi construída com o auxílio do Swagger29 que é um framework de

6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 105

código aberto criado para auxiliar a projetar, construir, documentar e consumir APIs. Além de usar o Swagger para documentar a API, também utilizamos para possibilitar a execução de testes de consumo. Assim, por meio da documentação, uma rota pode ser acessada e testes podem ser processados, como mostra a Figura 6.25.

Figura 6.25: Testes da API a partir da documentação. Fonte: o autor

Por fim, acessando a URI <http://sgdw.azurewebsites.net:8080/api-docs> é possível obter metadados da API, incluindo sua versão. Para o desenvolvimento da API, assumimos como premissa que todas as alterações nas rotas, métodos ou ações devem ser encapsuladas em novas versões. Dessa forma, é previsto a manutenibilidade e preservação da API e, consequentemente, sem necessidade de alterações ou quebras dos consumidores que estiverem usando-a.