• Nenhum resultado encontrado

Dados abertos @ UA

N/A
N/A
Protected

Academic year: 2021

Share "Dados abertos @ UA"

Copied!
166
0
0

Texto

(1)

2012

Pedro Miguel

Gonçalves Ferreira

(2)
(3)

Universidade de Aveiro

2012

Departamento de Electrónica, Telecomunicações e Informática

Pedro Miguel

Gonçalves Ferreira

DADOS ABERTOS @ UA

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orientação científica do Prof. Doutor Cláudio Teixeira, Professor do Departamento de Electrónica, Telecomunicações e Informática da Universidade de Aveiro e do Prof. Doutor Diogo Gomes, Professor do Departamento de Electrónica, Telecomunicações e Informática da Universidade de Aveiro

(4)
(5)

Dedico este trabalho aos meus pais, Carlos e Filomena, à minha irmã, Ana Rosa, e à Raquel, pelo incansável apoio.

(6)
(7)

o júri

presidente Doutor Osvaldo Manuel da Rocha Pacheco

Professor Auxiliar da Universidade de Aveiro

Doutor Alfredo Miguel Melo Matos Investigador Sénior na Caixa Mágica S.A.

Doutor Cláudio Jorge Vieira Teixeira

Professor Auxiliar Convidado da Universidade de Aveiro

Doutor Diogo Nuno Pereira Gomes

(8)
(9)

agradecimentos

Em primeiro lugar gostaria de agradecer aos meus orientadores, o Professor Doutor Cláudio Teixeira e Professor Doutor Diogo Gomes, por todos os conselhos e partilha de conhecimentos que me transmitiram durante a realização deste trabalho.

Agradeço ao Francisco Gouveia pela sua disponibilidade, sugestões e colaboração, indispensáveis para ultrapassar algumas dificuldades encontradas.

Agradeço aos meus pais pela possibilidade de realização deste trabalho. O seu incentivo e apoio incondicional são a base do meu sucesso académico e pessoal.

Por fim deixo o meu agradecimento à minha namorada Raquel, por toda a paciência e compreensão.

(10)
(11)

palavras-chave

Open data, Serviços web, SOAP, REST, Portal web, Web services security, Identidade, OAuth

resumo

Hoje em dia vivemos numa sociedade de informação. Qualquer pessoa ou entidade pode aceder, através de inúmeros meios de comunicação, a fontes de informação. Com a evolução tecnológica, a Internet transformou-se num dos principais meios de divulgação de conhecimento, permitindo o acesso a inúmeros recursos. Acompanhando este progresso surgiram novos termos e conceitos referentes à divulgação de informação, sendo o open data um dos principais.

O conceito open data aplica-se a dados disponibilizados publicamente por organizações e instituições. Este movimento está cada vez mais presente em instituições governamentais, que publicam os seus conjuntos de dados e bases de dados em portais web. Os benefícios do cruzamento de dados e implementação de mashups, assegurando a criação de novo conhecimento, são bastante evidentes, tanto a nível social como a nível económico.

A divulgação de dados através da Internet deverá obedecer a normas e padrões da indústria. Os serviços web assumem-se neste contexto como um método importante de transmissão de dados e informação devido, sobretudo, à sua vasta utilização por diversas aplicações e entidades.

Paralelamente à divulgação de informação pública, existem fontes de informação cujo seu conteúdo é privado. Neste contexto o protocolo OAuth surge como uma solução tecnológica que permite a divulgação de informação privada após a devida autorização pelo detentor dos conteúdos.

O objectivo desta dissertação passa por aplicar os conceitos acima referidos na Universidade de Aveiro. Numa primeira fase foi realizada uma triagem e categorização dos serviços web já existentes, assim como das fontes de informação com potencialidade para o desenvolvimento de um serviço. Após a implementação dos serviços identificados, foi desenvolvido um portal web agregador dos múltiplos serviços da Universidade de Aveiro, PT Inovação e SAPO.

Por fim foi implementado um servidor OAuth com o intuito de providenciar um mecanismo de autorização para o acesso a serviços web cuja informação é considerada sensível ou privada.

(12)
(13)

keywords

Open data, Webservices, SOAP, REST, Web portal, Web services security, Identity, OAuth

abstract

Nowadays we live in an information society. Every person or entity is able to access, through endless communication methods, to information sources. As technology evolved, Internet has become one of the most important ways of spreading knowledge, allowing access to several resources. As this progress continued, some new concepts about information sharing started to arise, being open data one of the most important.

The open data concept refers to data made publicly available by organizations and institutions. This concept is gaining importance on governmental parties, which publish their datasets and databases in web portals. Crossing data and implementation of mashups, providing new knowledge, comes with great social and economic benefits.

Spreading data through the Internet must follow industry standards and protocols. Webservices can be faced, in this context, as an important method of data and information transmission, essentially because of its high utilization. Simultaneously there are some information sources that carry sensitive and private data. In this context, OAuth protocol stands as a technologic solution to share private contents.

The objective of this thesis is to implement the concepts described above in The University of Aveiro. On a first approach it was gathered information about existing webservices as well as potential information sources to create new webservices. After the implementation of the identified webservices, a web portal was developed to aggregate webservices from the University of Aveiro, PT Inovação and SAPO.

Finally an OAuth server was developed in order to provide an authorization mechanism to access private data webservices.

(14)
(15)

Lista de Figuras . . . . iv Lista de Tabelas . . . . v Lista de Acrónimos . . . . vi 1 Introdução . . . . 1 1.1 Contextualização . . . 1 1.2 Motivação . . . 2 1.3 Objectivos . . . 3 1.4 Organização da Dissertação . . . 3 2 Estado da Arte. . . . 7 2.1 Open Data . . . 7

2.1.1 O que é Open Data . . . 7

2.1.2 Licenças . . . 9

2.1.3 Open Data em Portugal . . . 14

2.1.4 Open Data na Europa . . . 15

2.1.5 Open Data no Mundo . . . 15

2.1.6 Cronologia do Lançamento de Portais Open Data . . . 18

2.1.7 Representação de Dados . . . 19

2.2 Single Sign-On . . . 27

2.2.1 Security Assertion Markup Language . . . 27

2.2.2 Shibboleth . . . 29

2.2.3 OpenID . . . 30

2.2.4 Microsoft Account . . . 31

2.2.5 BrowserID . . . 32

2.3 Autorização . . . 35

2.3.1 eXtensible Access Control Markup Language . . . 35

2.3.2 Open Authorization Protocol . . . 36

2.4 Service Oriented Architecture . . . 43

2.5 Serviços Web . . . 43

2.5.1 Simple Object Access Protocol . . . 44

2.5.2 Representational State Transfer . . . 45

2.6 Web 2.0 . . . 48

3 Serviços Web . . . 51

3.1 Identificação de Serviços Web na UA . . . 52

3.1.1 Biblioteca da UA . . . 52

3.1.2 Code.UA . . . 52

3.1.3 Guia de Acesso Online . . . 53

3.1.4 Jornal Online UA . . . 53

3.1.5 PACO . . . 53

3.2 Novos Serviços Web na UA . . . 54

(16)

3.2.4 Operações dump, help e licence . . . 67

3.3 Outras Fontes de Informação Identificadas . . . 69

4 Autenticação e Autorização . . . 71

4.1 Protocolo OAuth 1.0a . . . 71

4.1.1 Modelo de Acesso a Recursos. . . 71

4.1.2 Modelo Proposto . . . 72

4.1.3 Implementação do Protocolo OAuth 1.0a . . . 73

4.1.4 OAuth em Aplicações Móveis/Desktop . . . 77

4.2 Portal de Gestão . . . 77

4.2.1 Aplicações . . . 78

4.2.2 Autorizações . . . 79

4.3 Web Services Security . . . 79

4.3.1 Contextualização. . . 80

4.3.2 Segurança ao Nível da Mensagem . . . 81

4.3.3 Implementação do WSS no myPersonas . . . 88

4.3.4 Testes e Resultados . . . 89

4.3.5 Considerações Finais. . . 91

5 Academic Playground & Innovation . . . 93

5.1 Visão Geral . . . 93

5.1.1 Autenticação . . . 94

5.2 Serviços . . . 98

5.2.1 Wiki . . . 99

5.3 Aplicações . . . 100

5.4 Redes Sociais e Serviço de Tickets . . . 101

5.5 Área Administrativa. . . 102

5.6 Dados Estatísticos . . . 103

5.6.1 Portal APIn . . . 103

5.6.2 Servidor services.web.ua.pt . . . 105

6 Conclusões e Trabalho Futuro . . . 107

6.1 Trabalho Futuro . . . 107

6.1.1 Portal APIn . . . 108

Referências . . . 109

A Serviços Web Identificados . . . 115

A.1 Biblioteca da UA . . . 115 A.1.1 Find . . . 115 A.1.2 Present . . . 116 A.1.3 Finddoc . . . 118 A.2 Code.UA . . . 120 A.2.1 Ocorrências . . . 120 A.2.2 Ocorrência . . . 121 A.2.3 Projectos . . . 122 A.2.4 Projecto. . . 122

A.2.5 Entradas Temporais . . . 123

A.2.6 Notícias . . . 123

A.2.7 Notícias do Projecto . . . 124

A.3 Guia de Acesso. . . 124

A.3.1 Cursos . . . 125

A.3.2 Cursos Param . . . 125

A.3.3 Curso . . . 126

(17)

A.3.7 Graus . . . 131

A.4 Jornal Online UA . . . 131

A.4.1 Conteúdos . . . 131 A.4.2 Linguagens . . . 132 A.4.3 Categorias. . . 133 A.4.4 Departamentos . . . 133 A.4.5 Banners . . . 134 A.4.6 Pesquisa. . . 135 A.4.7 Eventos . . . 136 A.5 PACO. . . 137

A.5.1 Horário do Aluno . . . 137

A.5.2 Horário do Docente . . . 138

A.5.3 Turmas do Aluno . . . 138

A.5.4 Turmas do Docente . . . 139

A.5.5 Disciplinas do Aluno . . . 139

A.5.6 Disciplinas do Docente . . . 140

A.5.7 Dados do Aluno . . . 140

A.6 Ementas SASUA . . . 141

A.7 Senhas SAC . . . 142

B Licenças dos Serviços Web . . . 143

B.1 Ementas SASUA . . . 143

(18)

2.1 Camadas das licenças CC. Fonte: [Commons 2003] . . . 9

2.2 Creative Commons CC0 Mark . . . 11

2.3 Exemplo de um triple da framework RDF . . . 11

2.4 Cronologia do lançamento de portais open data . . . 18

2.5 Objecto em JSON. Fonte: [JSON 2006] . . . 21

2.6 Array em JSON. Fonte: [JSON 2006] . . . 21

2.7 Valor em JSON. Fonte: [JSON 2006] . . . 22

2.8 String em JSON. Fonte: [JSON 2006] . . . 22

2.9 Número em JSON. Fonte: [JSON 2006] . . . 22

2.10 Exemplo de Same-Origin Policy . . . 24

2.11 Exemplo de Cross-Origin Resource Sharing . . . 26

2.12 Relação entre os diferentes blocos SAML. Fonte: [Ragouzis 2008] . . . 29

2.13 Funcionamento do Shibboleth . . . 30

2.14 Autenticação através de OpenID . . . 31

2.15 Autenticação através de Microsoft Account . . . 32

2.16 Aprovisionamento de certificado no BrowserID . . . 33

2.17 Geração de alegações no BrowserID . . . 34

2.18 Workflow de uma autorização através de XACML . . . 35

2.19 Componentes da linguagem de políticas . . . 36

2.20 Diagrama de sequência do processo OAuth . . . 39

2.21 Processo de invocação de um serviço web. Fonte: [Booth 2004] . . . 43

2.22 Estrutura de uma mensagem SOAP . . . 44

3.1 Comunicações envolvidas na invocação do serviço ementas . . . 56

3.2 Diagramas de sequência da invocação do serviço ementas . . . 57

3.3 Diagrama de actividade da cache no serviço ementas . . . 58

3.4 Tempos de acesso ao serviço das ementas, recurso 1 . . . 59

3.5 Tempos de acesso ao serviço das ementas, recurso 2 . . . 60

3.6 Diagrama da primeira versão do daemon . . . 62

3.7 Diagrama da segunda versão do daemon . . . 62

3.8 Upload de um ficheiro no serviço File Bucket, primeira versão . . . 64

3.9 Diagrama de sequência do upload de ficheiro(s) para o serviço File Bucket, primeira versão 65 3.10 Diagrama de sequência do upload de ficheiro(s) para o serviço File Bucket, segunda versão 65 3.11 Página inicial do servidorhttp://services.web.ua.pt/. . . 68

3.12 Diagrama de actividade da operação dump . . . 69

4.1 Modelo de acesso a recursos na versão 1.0(a) do OAuth . . . 71

4.2 Modelo proposto de acesso a recursos para o protocolo OAuth . . . 72

4.3 Mapeamento de serviços/recursos no protocolo OAuth . . . 73

4.4 Formulário de autorização no protocolo OAuth . . . 75

4.5 Código de verificação de um pedido no OAuth . . . 77

4.6 Página inicial do portal OAuth . . . 78

4.7 Aplicações no OAuth . . . 78

4.8 Autorizações no OAuth. . . 79

4.9 Estrutura de uma mensagem SOAP que implementa WSS . . . 82

(19)

4.13 Tempos de execução de diversos testes aos mecanismos de segurança implementados

pelo WSS . . . 89

4.14 Tamanhos das mensagens SOAP dos testes aos mecanismos de segurança implementa-dos pelo WSS . . . 90

5.1 Página inicial do portal APIn . . . 94

5.2 Esquema dos servidores APIn e comunicação com o IdP da UA . . . 95

5.3 Diagrama de sequência do processo de autenticação no portal APIn . . . 95

5.4 Página web de autenticação no IdP da UA . . . 96

5.5 Diagrama de sequência do processo de logout no portal APIn . . . 97

5.6 Página web de logout no IdP da UA . . . 97

5.7 Página web dos serviços no portal APIn . . . 98

5.8 Permissões de publicação de serviços . . . 99

5.9 Wiki do serviço OAuth da UA . . . 99

5.10 Guardar wiki de um serviço . . . 100

5.11 Aplicações publicadas no portal APIn. . . 100

5.12 Últimas notícias no portal APIn . . . 101

5.13 Barra de ligações de um utilizador normal . . . 102

5.14 Barra de ligações de um administrador . . . 102

5.15 Página de estatísticas do portal APIn . . . 102

5.16 Browsers utilizados no acesso ao portal . . . 103

5.17 Acessos vs número de utilizadores registados . . . 104

5.18 Visitas e percentagem de novas visitas ao portal . . . 104

5.19 Gráfico visitantes únicos vs número de visitas . . . 105

5.20 Relação entre os tipos de browsers utilizados . . . 105

Lista de Tabelas

2.1 Lista de licenças CC . . . 10

2.2 Comparação das diversas licenças . . . 13

(20)

AJAX Asynchronous JavaScript and XML

AMA Agência para a Modernização Administrativa API Application Programming Interface

APIn Academic Playground & Innovation Atom Atom Syndication Format

CC Creative Commons

CC0 CC Zero

ccREL Creative Commons Rights Expression Language

CORS Cross-Origin Resource Sharing CRUD Create, Retrieve, Update and Delete CSS Cascading Style Sheets

CSV Comma Separated Values

DETI Departamento de Electrónica, Telecomunicações e Informática DoS Denial of Service

FAQ Frequently Asked Questions

HMAC-SHA1 Hash-based Message Authentication Code with Secure Hash Algorithm 1 HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

IdP Identity Provider

IETF Internet Engineering Task Force ISBN International Standard Book Number ISSN International Standard Serial Number IT Instituto de Telecomunicações

JAX-WS Java API for XML Web Services

JS JavaScript

JSON JavaScript Object Notation

JSONP JSON with Padding

JWT JSON Web Token

MD5 Message-Digest Algorithm

MIME Multipurpose Internet Mail Extensions

(21)

ODC Open Data Commons

ODC-By Open Data Commons Attribution Licence

ODC-ODbL Open Data Commons Open Database Licence

OGL Open Government Licence PACO Portal Académico Online PAP Policy Administration Point PDDL Public Domain Dedication Licence PDP Policy Decision Point

PEP Policy Enforcement Point PIP Policy Information Point

PTin PT Inovação

RDF Resource Description Framework REST Representational State Transfer RFC Request For Comments RFID Radio-Frequency Identification

RP Relying Party

RSS Really Simple Syndication SAC Serviços Académicos

SAML Security Assertion Markup Language

SAPO Servidor de Apontadores Portugueses Online

SASUA Serviços de Acção Social da Universidade de Aveiro

SGML Standard Generalized Markup Language SIC Sistemas de Informação Computorizados SMTP Simple Mail Transfer Protocol

SOAP Simple Object Access Protocol SOP Same-Origin Policy

SP Service Provider

SSL Secure Sockets Layer

SSO Single Sign-On

STIC Serviços de Tecnologias de Informação e Comunicação TCP Transmission Control Protocol

TLS Transport Layer Security UA Universidade de Aveiro

(22)

UE União Europeia

URI Uniform Resource Identifier URL Uniform Resource Locator

UTF-8 Unicode Transformation Format-8

W3C World Wide Web Consortium WAYF Where are you from?

WS-Security Web Services Security

WSD Web Service Description

WSDL Web Service Definition Language WSS Web Services Security

WSS4J Web Services Security for Java

WWW World Wide Web

WYSIWYG What You See Is What You Get

XACML eXtensible Access Control Markup Language

XML eXtensible Markup Language

XML-RPC eXtensible Markup Language-Remote Procedure Calling

(23)

Este capítulo começa por enquadrar o trabalho realizado. De seguida é apresentada a motivação para a sua realização e enumerados os objectivos propostos. Por fim é resumida a estrutura da dissertação.

1.1

Contextualização

A informação é parte integrante dos alicerces da sociedade do século XXI. Vivemos numa época em que a informação nos chega das mais variadas formas e formatos: rádio, televisão, jornais e, sobretudo, através da Internet. No entanto, o que de facto é a informação? O termo informação é aplicado a um conjunto de dados que sofreram um processo de transformação. Esses dados foram organizados, manipulados e seleccionados com o objectivo de produzir um conjunto de premissas úteis e de valor acrescentado. Essas premissas devem conter certas características que influenciam o seu valor, das quais se podem destacar a sua exactidão, relevância, totalidade e fidedignidade [Stair 2012]. O valor da informação para uma instituição é crucial, tanto a nível económico como competitivo. É imperativo que uma dada entidade disponha de informação correcta e actual por forma a que as suas decisões estratégicas sejam o mais acertadas possível.

Com o avançar da tecnologia, os computadores vieram revolucionar o modo como a informação é gerada, distribuída e consumida. Os Sistemas de Informação Computorizados (SIC) são parte integrante das empresas de hoje em dia. Estes sistemas permitem obter dados de diversas fontes, processá-los e gerar um conjunto de informação relevante para a área de negócio da instituição.

Numa instituição de dimensões consideráveis, tal como uma Universidade, que está dividida em diver-sos departamentos e serviços, é comum haver um certo isolamento. Cada serviço tem as suas próprias fontes de dados, internas e externas, sendo a informação processada e consumida internamente e em virtude das necessidades. Este método proporciona que diversas fontes de informação departamentais estejam circunscritas, impedindo a partilha de informação com potenciais entidades, incluindo entidades da própria instituição.

Recentemente surgiu uma iniciativa denominada Open Data, introduzida pela Administração Obama nos Estado Unidos da América. Esta iniciativa tem como principal premissa a de que os dados recolhidos pelo governo são de interesse público e devem ser disponibilizados de um modo faseado [Obama 2010], permitindo assim que qualquer cidadão tenha acesso a esses dados.

Da mesma forma que a iniciativa open data é aplicada a um Estado, esta também pode ser aplicada a qualquer instituição de cariz público. No entanto, surgem certas questões com bastante relevância:

• De que forma devem ser organizadas, estruturadas e publicitadas as fontes de informação?

(24)

• A informação pessoal deve ser disponibilizada? Se sim, de que forma e através de que métodos?

• Que mecanismos de segurança devem estar envolvidos na partilha de dados e informação?

A segurança e o controlo de acesso a fontes de dados e informação é uma problemática de extrema importância, principalmente quando esses dados são de natureza pessoal. Devido a este facto, muitas empresas colocam a decisão e controlo de partilha desses dados nas mãos do utilizador.

Numa sociedade de informação como a que presenciamos actualmente, os métodos de manuseamento de dados e, principalmente, de informação não devem ser tratados levianamente. É necessário criar mecanismos e técnicas de partilha de informação sensível de modo a salvaguardar a privacidade dos intervenientes. Este paradigma acentua-se cada vez mais com a evolução tecnológica, dificultando a distinção da informação pública da privada.

1.2

Motivação

Na Universidade de Aveiro (UA) é possível identificar facilmente um conjunto de fontes de informação de carácter público: as senhas dos Serviços Académicos (SAC), as ementas das cantinas e restaurantes universitários, diversas feeds de notícias (Jornal Online) e de informações académicas e institucionais (Guia de Acesso), entre outras. Estas fontes de informação estão divididas por serviços e/ou departa-mentos, não havendo um ponto comum entre as mesmas.

Cada uma das fontes de informação identificadas anteriormente serve apenas, e só, o propósito para as quais foram desenvolvidas. Por exemplo, a informação das senhas SAC apenas está disponível através do ecrã presente nos SAC ou, mais recentemente, através do Portal Académico Online (PACO -http: //paco.ua.pt/). Não está construída nem definida nenhuma Application Programming Interface (API) que permita a terceiros desenvolver aplicações que usufruam desta fonte de informação. O mesmo acontece para as ementas das cantinas e restaurantes universitários. É, portanto, facilmente detectável uma lacuna referente à partilha de informação de um modo transparente e padrão, tanto a nível interno da própria instituição como para entidades exteriores.

No âmbito da necessidade identificada anteriormente, surge a oportunidade de aperfeiçoar os métodos de distribuição de informação existentes na UA. A criação destes novos endpoints proporcionará uma melhor organização e estruturação das fontes de informação da UA. A estruturação de algumas fontes de informação numa instituição com as proporções da UA exige um estudo cuidado, tanto das tecnologias envolvidas, como da arquitectura a ser implementada ou das licenças sob as quais os dados podem ser divulgados.

No entanto, nem todas as fontes de informação presentes na UA são de carácter público. Existe in-formação de natureza pessoal e institucional que deve ser disponibilizada de uma forma controlada e autorizada. É, portanto, pertinente estudar a melhor arquitectura a ser implementada de modo a que a in-formação pessoal possa ser divulgada a terceiros, salvaguardando sempre a livre vontade do proprietário em autorizar e, posteriormente, cancelar a divulgação dos seus dados pessoais.

(25)

Com a criação de novos endpoints de serviços web há igualmente oportunidade para a criação de um portal web agregador de todos os endpoints, públicos e privados, referentes à UA.

1.3

Objectivos

Com esta dissertação pretende-se identificar e caracterizar as diferentes fontes de informação da UA e, caso seja necessário, construir APIs ou serviços web de acesso à informação. Estas fontes de informação devem ser devidamente categorizadas em função do tipo de informação que representam.

De modo a disponibilizar os endpoints já existentes e os que irão ser criados, será também necessário a implementação de um portal web agregador. Devido ao enquadramento desta dissertação no projecto de investigação Academic Playground & Innovation (APIn), o portal web contará não só com serviços da UA, como também da PT Inovação (PTin) e do Servidor de Apontadores Portugueses Online (SAPO). Devido à vertente académica do projecto APIn é bastante importante a disponibilização de uma wiki para cada serviço que contenha todas as informações necessárias para o consumo do serviço em causa: documentação, exemplos, descrição concisa das possíveis mensagens de erro assim como referências aos métodos de autenticação e/ou autorização, caso sejam aplicáveis.

Para além da disponibilização dos serviços no portal, serão disponibilizados servidores virtuais para a criação de projectos, um local para a divulgação de aplicações desenvolvidas no âmbito do APIn e uma página com Frequently Asked Questions (FAQ) para a ajuda nas diversas interacções com o portal.

Como já foi referido anteriormente, as fontes de informação presentes na UA estão repartidas quanto ao seu carácter: público ou privado. Esta condição implica colocar um nível de autorização e autenticação de forma a que o acesso à informação privada seja o mais controlado possível. A solução encontrada passa pela implementação do protocolo Open Authorization (OAuth) como middleware no acesso a re-cursos considerados sensíveis [RFC 5849]. Existem algumas variáveis inerentes ao protocolo OAuth que necessitam de ser controladas. Por exemplo, deve ser dada a possibilidade de um utilizador revogar au-torizações concedidas a uma aplicação externa para o acesso aos seus dados pessoais e institucionais. Assim como deve ser possível a um administrador gerar chaves de acesso para uma nova aplicação que necessite de utilizar o protocolo OAuth. Ou suspender a utilização deste serviço a uma aplicação com comportamentos abusivos. Surge, então, a necessidade de implementação de um portal web que permita a gestão do protocolo OAuth e de todos os parâmetros inerentes.

1.4

Organização da Dissertação

No sentido de estruturar esta dissertação num documento coerente, foram redigidos seis capítulos, sendo o primeiro dedicado à contextualização da problemática, motivação e objectivos do trabalho desen-volvido. O segundo capítulo é dedicado ao estudo do estado da arte, onde será discutida uma abordagem às tecnologias e arquitecturas utilizadas na elaboração desta dissertação. Irá ser explorado o conceito Open Data e o impulsionar do mesmo para que instituições de cariz público disponibilizem as suas fontes

(26)

de informação. Veremos de que forma as instituições, tanto nacionais como internacionais, começam a ceder os seus dados e sob que condições. Posteriormente, será feita uma análise das arquitecturas utilizadas para a disponibilização de informação através de serviços web: a arquitectura Representational State Transfer (REST) e a arquitectura Simple Object Access Protocol (SOAP). São igualmente analisa-das algumas arquitecturas e conceitos no que respeita ao desenvolvimento de portais web, assim como o modelo Web 2.0. São também apresentadas soluções de autenticação e autorização web. Será também feito um breve estudo da disseminação do protocolo OAuth em aplicações web, desktop e móveis, assim como uma análise do impacto deste na forma como a identidade do utilizador é gerida e partilhada por diferentes domínios.

O terceiro capítulo é iniciado com uma caracterização dos serviços existentes actualmente na UA, as-sim como a identificação das potencias fontes de informação para as quais ainda não está disponibilizada uma API. Depois de identificadas as fontes de informação que carecem de um modelo programático de acesso computorizado, será exposto o método de implementação e criação de novos serviços. Em al-guns serviços, nomeadamente nas senhas dos SAC, foi necessário uma prévia implementação de um middleware, devido à forma como a aplicação que gere as senhas nos SAC disponibiliza os dados. Será também analisada a forma como o serviço das ementas da UA está implementado e quais os mecanis-mos de cache que são utilizados com o objectivo de evitar invocações desnecessárias ao serviço. Um outro serviço implementado denomina-se de File Bucket. Este serviço permite o armazenamento e parti-lha de ficheiros de pequenas dimensões, garantindo que o detentor do ficheiro é uma pessoa com conta na UA. Por fim serão discutidas algumas fontes de informação que poderão originar novos serviços.

Devido à confidencialidade de algumas informações disponibilizadas por certos serviços, é necessária a adopção de mecanismos de autenticação e autorização. No quarto capítulo são exploradas estas duas componentes. A solução implementada para o acesso a recursos privados foi o protocolo OAuth. Neste capítulo é realizado um estudo sobre este protocolo, a sua arquitectura e o modo utilizado para agilizar o processo de acesso à informação pessoal e institucional do utilizador. De forma a controlar todas as variáveis envolvidas num servidor OAuth, foi desenvolvido um portal para a gestão deste protocolo, tanto a nível administrativo como pessoal. Posteriormente, é detalhada a implementação do padrão Web Services Security (WSS). No âmbito do projecto myPersonas, da PTin, foi necessário a aplicação de uma camada de segurança nos serviços web. O WSS é uma extensão do protocolo SOAP que permite a transacção, de uma forma segura e confidencial, de mensagens assinadas através deste protocolo [IBM 2002]. Será estudada a forma como o WSS pode ser implementado com recurso à linguagem de programação JAVA.

No quinto capítulo é abordado o projecto APIn. São descritas todas a tecnologias utilizadas no desen-volvimento do portal APIn, assim como a melhor forma de interligar os diversos recursos necessários à elaboração de um portal agregador de serviços web. Para a criação deste portal, e devido à natureza sen-sível sobre o acesso a alguns serviços, foi necessária a implementação de um sistema de autenticação. O sistema de autenticação escolhido foi o Identity Provider (IdP) da UA.

(27)

desenvolvido no âmbito deste projecto. É realizado um balanço do trabalho implementado e o impacto que teve numa melhor estruturação e disseminação das fontes de informação na UA. Posteriormente são expostas algumas directrizes para uma eventual continuação do trabalho desenvolvido, tanto a nível de identificação de novos serviços da UA, como a nível de desenvolvimento do portal APIn.

(28)
(29)

Neste capítulo é realizada uma introdução e análise de alguns conceitos relacionados com a temática do open data. São estudadas as diferentes licenças existentes e como estas podem suportar legalmente a livre distribuição de dados e conjuntos de dados (datasets). Embora instituições definam os seus dados como públicos e de livre acesso, são necessárias ferramentas para a distribuição, através de padrões abertos e bem conhecidos, dos dados. Assim como o acesso a dados públicos é realizado de uma forma livre, sem que seja necessário nenhum controlo específico, o acesso a dados privados deverá ser realizado sob uma vigilância mais rigorosa. Para o acesso a um recurso privado, o detentor deste deverá sempre controlar a partilha, retirando permissões de acesso se achar pertinente. Este tipo de controlo é definido através do protocolo OAuth.

De modo a que um sistema tenha a capacidade de garantir o acesso a dados por parte de uma en-tidade, esta necessita de estar informada sobre a entidade que pretende aceder aos recursos. Estas informações podem ser partilhadas entre várias entidades na Internet, recorrendo a sistemas de Single Sign-On (SSO).

2.1

Open Data

Introduzido nos finais da década de 2000, o conceito open data generaliza a acessibilidade da infor-mação que pode ser pública e facilmente alcançável por qualquer pessoa [Hoxha 2011]. Esta secção é reservada ao estudo da importância da abertura de dados para utilização pública. Com a disponibilização de dados de uma forma aberta, é prudente ter associada uma licença que defina concretamente os ter-mos de utilização dos mester-mos, assim como as regras que devem ser cumpridas na reutilização destes. Tendo em conta que os dados são disponibilizados digitalmente, é necessário especificar o formato em que estes podem ser consumidos. Com a disseminação do conceito open data e dos seus benefícios (principalmente económicos), vários governos, administrações locais e entidades públicas começaram a disponibilizar, através da Internet, os datasets ou bases de dados dos seus serviços.

2.1.1

O que é Open Data

O tema principal desta dissertação é open data. Mas o que é, na realidade, open data? De um ponto de vista técnico, o open data “refere-se a datasets que podem ser reutilizados sem quaisquer restrições por parte de licenças ou patentes, dados esses que devem ser bem estruturados, facilmente acessíveis e reutilizáveis por instituições, cientistas ou pela comunidade web” [Hoxha 2011]. Segundo o Open Defini-tion, o termo open data aplica-se a “dados que podem ser usados, reutilizados e redistribuídos livremente por qualquer pessoa, estando sujeitos, no máximo, à identificação da fonte e conservação dos direitos de autor” [Dietrich 2010]. Esta definição pode ser detalhada, caracterizando especificamente os conceitos que devem ser inerentes aos dados distribuídos como open data. Um desses conceitos é oacesso e

(30)

disponibilidade dos dados. Estes devem ser disponibilizados como um todo e, preferencialmente, atra-vés da Internet sem custos associados. Os dados também devem ser disponibilizados de uma forma conveniente e facilmente personalizável, contribuindo para outro conceito do open data: a possibilidade dereutilização e redistribuição da informação. Este conceito determina que os dados devem ser aces-síveis sob termos que permitam a reutilização e redistribuição dos mesmos, assim como o cruzamento com dados de fontes distintas. A licença de reutilização e redistribuição dos dados não deve requerer quaisquer taxas ou custos. Com a abertura dos dados publicamente, aparticipação universal é outro dos conceitos inerentes ao open data: todos devem ter a possibilidade de utilizar, reutilizar e redistribuir. Não deve existir discriminação contra pessoas, grupos ou ramos de actividade. Por exemplo, restrições de “não-comercialização” que poderiam impedir o uso dos dados para fins comerciais, ou restrições contra determinadas áreas de aplicação (educação, saúde, banca, etc).

As características acima descritas são fundamentais para tornar viável o cruzamento de dados, confe-rindo interoperabilidade ao sistema em causa. A interoperabilidade de um sistema é definida como a ca-pacidade de trocar, reutilizar e interpretar dados por diferentes arquitecturas, através de padrões abertos [Kaplan 2005]. A capacidade de poder agregar componentes diferentes é essencial para a construção de sistemas complexos e, sobretudo, escaláveis. A interoperabilidade de um sistema ou organização permite que as suas fontes de dados possam ser cruzadas através de mashups, permitindo assim a transformação de dados em informação de valor acrescentado.

O conceito open data tem sido bastante impulsionado por parte dos governos de diversos países, tendo inclusive sido bastante apoiado pela União Europeia (UE). Este facto deve-se essencialmente a várias oportunidades que a abertura de dados pode vir a proporcionar [Comission 2011]. Do ponto de vista económico, asoportunidade de negócio surgem como um factor determinante para a implementação de mashups inovadoras que originem novos serviços e/ou produtos informativos. Como consequência, surge a possibilidade de criação de novos postos de trabalho e riqueza. Do ponto de vista informativo, a abertura de dados governamentais proporciona uma maior transparência na administração pública, impulsionando a visibilidade de informação que antes era privada. Ao permitir um melhor conhecimento por parte de pessoas e empresas sobre políticas aplicadas, financiamento público e despesas, a partilha deste tipo de informação governamental poderá incitar à criação de novas empresas e investimentos com menos riscos associados. Do ponto de vista governamental, o open data incentiva a melhores decisões políticas baseadas em dados reais e eficiência administrativa. A disponibilização destes dados poderá resultar em melhores serviços públicos para o cidadão, aplicados directamente a focos de necessidades.

O factor económico é de extrema importância para a disponibilização de dados. Um estudo recente indica que o mercado total para o sector informativo na UE foi de 28 mil milhões de Euros em 2008. O mesmo estudo também realça que os ganhos económicos, directos e indirectos, da reutilização de infor-mação pública na UE será de 140 milhões de Euros anuais [Vickery 2011]. Embora os dados disponibi-lizados de forma pública e aberta não representem, em primeira instância, qualquer valor, o cruzamento destes poderá gerar informação com valor económico.

(31)

Surge, no entanto, a necessidade de definir formatos e licenças de partilha de dados. Quais os me-lhores métodos para uma partilha padronizada da informação? E que tipo de regulamentações jurídicas são aplicadas a estes dados? Nas próximas secções serão discutidas algumas tecnologias de partilha e licenças a aplicar a conjuntos de dados e bases de dados.

2.1.2

Licenças

Embora a disponibilização de dados seja impulsionadora de uma maior transparência, interoperabili-dade e desenvolvimento académico, social e económico, a não especificação de termos de utilização dos dados poderá ter um efeito contra-produtivo. A forma como diferentes jurisdições tratam a utilização de dados em diferentes contextos é, por vezes, de difícil compreensão. Este aspecto poderá dificultar a partilha de dados entre organizações, sendo assim criada uma barreira legal à utilização e redistribuição de dados [Ball 2011]. Desta forma é essencial aplicar uma licença para o uso e redistribuição dos dados. A licença a ser aplicada deverá ser standard : além de melhorar a eficiência organizacional e proporci-onar a poupança de custos, o uso de licenças padrão permite aumentar a interoperabilidade dos dados facultados. A utilização de licenças bem conhecidas é igualmente benéfica para as entidades consumi-doras dos dados, devido a uma melhor compreensão das regras que são aplicadas [Korn 2011].

2.1.2.1

Creative Commons

A Creative Commons (CC) é uma organização sem fins lucrativos fundada em 2001. O objectivo desta organização é o de produzir licenças standard simples, mas robustas, que permitam aplicar direitos de autor aos trabalhos de uma entidade [Korn 2011, Ball 2011].

Figura 2.1: Camadas das licenças CC. Fonte: [Commons 2003]

As licenças da CC estão divididas em três camadas [Commons 2003]: ocódigo legal, que proporciona uma camada formal e técnica da licença, oCommons Deed, que é definida como a camada não formal da licença, responsável por sumarizar os termos e condições mais importantes através de uma

(32)

lingua-gem leiga e, na última camada, está presente aLinguagem Máquina, que sumariza os pontos cruciais da licença, sendo estes disponibilizados num formato que permita a sistemas de software, motores de pesquisa e outros tipos de tecnologias a sua compreensão.

Estão disponíveis seis licenças CC. Todas as licenças tem por base uma única licença: attribuition. Isto significa que as propriedades da licença attribuition são herdadas pelas restantes cinco licenças.

Attribution CC BY Esta licença permite que terceiros distribuam, copiem, exponham e alterem o tra-balho desde que o autor seja devidamente referenciado. Também prevê a utilização do tratra-balho para fins comerciais. O autor deve especificar a forma como deve ser referenciado. Esta licença é comum nas restantes licenças do CC.

Attribution-ShareAlike CC BY-SA Todos os trabalhos baseados no trabalho que detém esta licença devem manter a licença. Ou seja, qualquer trabalho que tenha por base um trabalho com esta licença deverá referenciar o seu autor original, e assim sucessivamente.

Attribution-NoDerivs CC BY-ND Licença que permite a redistribuição, comercial ou não comercial, desde que não sejam feitas alterações no trabalho base.

Attribution-NonCommercial CC BY-NC Esta licença determina que os trabalhos derivados deste ape-nas devem ser utilizados para fins não comerciais.

Attribution-NonCommercial-ShareAlike CC BY-NC-SA Licença que determina que os trabalhos re-sultantes apenas devem ser utilizados para fins não comerciais. Além disso, esta licença deve ser mantida nos trabalhos resultantes.

Attribution-NonCommercial-NoDerivs CC BY-NC-ND À semelhança da licença CC BY-NC, esta li-cença especifica que os trabalhos derivados devem ser usados apenas para fins não comerciais. Também não devem ser feitas alterações no trabalho original.

Licença Nomenclatura Logótipo

Attribution CC BY Attribution-ShareAlike CC BY-SA Attribution-NoDerivs CC BY-ND Atributivo-NonCommercial CC BY-NC Attribution-NonCommercial-ShareAlike CC BY-NC-SA Attribution-NonCommercial-NoDerivs CC BY-NC-ND

Tabela 2.1: Lista de licenças CC

Embora as licenças CC sejam bastante usadas hoje em dia, estas não são indicadas para o licenci-amento de dados, datasets e bases de dados. Uma base de dados representa um ou vários datasets,

(33)

muitas das vezes provenientes de fontes ou autores distintos. Como já foi analisado anteriormente, todas as licenças da CC baseiam-se na licença de atribuição: trabalhos derivados devem conter referência ao autor original. Visto que um conjunto de dados (ou base de dados) pode ter inúmeros autores e contri-buidores, surge um problema denominado attribution stacking: todos os autores devem ser referenciados [Vollmer 2011].

2.1.2.2

CC Zero

A licença CC Zero (CC0) é uma ferramenta desenvolvida pela CC com o objectivo de facilitar a disponi-bilização de conteúdos, dados, datasets e bases de dados no domínio público. Esta licença permite que o detentor dos dados mantenha todos os direitos de autor, assim como o direito de ser identificado como o respectivo autor. O detentor destes direitos mantém todos os direitos sobre a base de dados e deverá ser identificado como o seu criador. Quando tal não é possível, a licença CC0 dispõe de mecanismos para que o detentor dos direitos sobre os dados tenha a possibilidade de permitir o uso destes para qualquer fim, por qualquer entidade e sem ser aplicado nenhum condicionalismo ou taxa [Korn 2011].

Esta licença prevê colmatar o problema attribution stacking identificado nas licenças Creative Commons (2.1.2.1), tornando-se ideal para o universo open data.

Os dados, conjuntos de dados ou bases de dados que apliquem esta licença podem ser identificados através da figura 2.2.

Figura 2.2: Creative Commons CC0 Mark

2.1.2.3

Representação de Licenças CC

As licenças CC estão divididas em três níveis de representação: código legal, common deads e lingua-gem máquina. O último nível tem o objectivo de permitir a interpretação da licença por parte de aplicações de software. Para tal, a CC desenvolveu uma linguagem própria para a descrição das suas licenças: a Creative Commons Rights Expression Language (ccREL). Descrita pela primeira vez em Março de 2008, esta linguagem é baseada no formato Resource Description Framework (RDF), devido sobretudo à inte-roperabilidade e universalidade associados a este formato.

O RDF é uma framework utilizada para descrever entidades na web. Este formato assenta sobre uma estrutura de descrição atómica denominada de “triples”. Cada “triple” consiste num sujeito, uma propriedade e um valor para a propriedade do sujeito. Por exemplo, consideremos que se pretende aplicar a licença CC BY ao websitehttp://api.web.ua.pt/.

http://api.web.ua.pt/

http://www.w3.org/1999/xhtml/vocab/#license

http://creativecommons.org /licenses/by/3.0/

(34)

O “triple” resultante está representado na figura 2.3. Ao website http://api.web.ua.pt/ (sujeito) é aplicada a licença CC BY (valor) através da propriedade vocab#licence. Esta estrutura de ligações forma um grafo, onde os vértices representam uma ligação nomeada entre dois recursos, representados pelos nós do grafo. Ou seja, um modelo RDF é uma colecção de “triples” que podem ser visualizados através de grafos.

A conversão do grafo da figura 2.3 para um modo textual é realizado através da linguagem de marcação eXtensible Markup Language (XML). Por exemplo, o “triple” representado anteriormente pode ser descrito da seguinte forma:

1 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

2 xmlns:xhtml="http://www.w3.org/1999/xhtml/vocab#">

3 <rdf:Description rdf:about="http://api.web.ua.pt/">

4 <xhtml:license rdf:resource="http://creativecommons.org/licenses/by/3.0/" />

5 </rdf:Description>

6 </rdf:RDF>

Como é possível reparar, todos os identificadores são representados por Uniform Resource Locator (URLs). Isto permite obter uma descrição detalhada sobre a propriedade ao aceder ao URL, possibili-tando também a formulação de propriedades por qualquer entidade. Neste seguimento, a CC desenvol-veu duas propriedades para representar as suas licenças: a propriedadework , que permite descrever aspectos específicos de um trabalho, incluindo sob que licenças este é distribuído, e a propriedade li-cence, que permite descrever os aspectos da licença.

Nas propriedadeswork , a CC recomenda a utilização de pelo menos quatro propriedades:

• dc:title: representa o título do documento (dc é a abreviatura para o vocabulário Dublin Core, disponível no endereçohttp://purl.org/dc/elements/1.1/).

• cc:attributionName: descreve o nome a citar quando o trabalho é redistribuído ou modificado (cc é a abreviatura para o endereçohttp://creativecommons.org/ns#).

• cc:attributionURL: o endereço de ligação a ser citado.

• dc:type: define o tipo do recurso a licenciar.

As propriedadeslicence podem ser divididas em seis categorias: a cc:permits, que define as permis-sões a aplicar ao trabalho, para além das que são aplicadas por defeito pela licença, a cc:prohibits, que permite revogar permissões, a cc:requires, que permite requerer algumas acções por parte do utilizador quando aplica as permissões definidas em cc:permits, a cc:jurisdiction, que associa a licença a uma jurisdição particular, a cc:deprecatedOn, que indica a data na qual a licença deixou de ser válida, e a cc:legalCode, que referencia o texto legal correspondente à licença. A utilização destas propriedades implica a criação de novas licenças por parte de quem as aplica, mas sempre baseadas nas licenças CC [Abelson 2008].

(35)

2.1.2.4

Open Data Commons

O projecto Open Data Commons (ODC), financiado pela fundação Open Knowledge, foi iniciado em Março de 2008 e tem como objectivo providenciar soluções legais para open data. Ao contrário das licenças disponibilizadas pelo CC, que podem ser aplicadas a qualquer trabalho, as licenças do ODC estão vocacionadas especialmente para dados, datasets e bases de dados. O ODC dispõe de três licenças:

ODC Attribution Licence (ODC-By) Esta licença, compatível com a licença CC BY, prevê a livre cópia, distribuição, modificação, transformação e produção de trabalhos baseados numa base de dados ou conjunto de dados. Requer igualmente que o autor seja devidamente identificado. Esta licença deverá ser mantida para qualquer trabalho derivado.

ODC Open Database Licence (ODC-ODbL) Semelhante à licença anterior (ODC-By), esta licença prevê igualmente que qualquer trabalho derivado a herde. No caso de a base de dados ser redistribuída, é necessário manter uma versão da mesma sem ser aplicada qualquer restrição. Esta licença aplica-se apenas a dados, datasets e bases de dados e é comparável à licença CC BY-SA. Public Domain Dedication Licence (PDDL) Esta licença mantém todas as propriedades definidas pela

ODC-By. Além disso, prevê que a base de dados a que a licença é aplicada passe para o domínio público, mantendo os autores todos os direitos reservados. Esta licença é comparável à licença CC Zero (2.1.2.2).

Licença Ideal para

open data Utilização Comercial Modificação Recurso Conservação Licença Atribuição CC: BY BY-SA BY-NC BY-ND BY-NC-SA BY-NC-ND CC0 ODC: By ODbL PDDL

(36)

Na tabela 2.2 é exposta uma comparação das licenças descritas anteriormente. Excepto a licença CC0, todas as restantes licenças da CC não são indicadas para o licenciamento de datasets e/ou bases de dados, devido ao problema de attribution stacking. As licenças CC caracterizam-se por permitirem quase todo o tipo de combinações possíveis, desde a utilização para fins comerciais, modificação do recurso às quais se aplicam e conservação da licença em produtos derivados. Estas licenças estão bastante divulgadas no mundo digital e são aplicadas sobretudo a ficheiros audiovisuais, artigos e publicações.

As licenças do projecto ODC foram desenvolvidas especificamente para o licenciamento de dados, datasets ou bases de dados. Bastantes comuns entre si, estas licenças caracterizam-se pela permissão de utilização comercial dos recursos às quais são aplicadas. A licença PDDL destaca-se das restantes pela proibição de alteração das fontes do trabalho e por não exigir a manutenção da licença nos produtos derivados.

Em todas as licenças referidas, tanto provenientes da CC ou do ODC, é exigida a identificação do autor das fontes em que os produtos se baseiam.

Para além das licenças estudadas anteriormente, alguns governos desenvolveram as suas próprias clausulas a aplicar a dados open data. Por exemplo, os dados disponibilizados pelo governo do Reino Unido estão sob a licença Open Government Licence (OGL). À semelhança das licenças ODC e CC0, a OGL aplicasse a dados, datasets, bases de dados e também a conteúdos. Permite a utilização dos recursos para uso comercial e deve ser aplicada a datasets relativamente pequenos, de modo a limitar o attibution stacking [Korn 2011]. Os pormenores sobre esta licença podem ser consultados no endereço

http://www.nationalarchives.gov.uk/doc/open-government-licence/.

2.1.3

Open Data em Portugal

2.1.3.1

Dados.gov

Em Junho de 2011 foi lançado em Portugal o portal Dados.gov (http://www.dados.gov.pt/). O portal Dados.gov tem como objectivo a divulgação de dados partilhados por instituições da Administração Pú-blica, assim como reunir uma série de aplicações que utilizam esses dados. De entre os fornecedores de dados presentes no portal, é possível destacar-se a Agência para a Modernização Administrativa (AMA), a Comissão Nacional de Eleições e a Fundação para a Computação Científica Nacional, que contam com o maior número de dados disponibilizados. Este portal está sob a alçada da AMA.

2.1.3.2

Open Data Lx

O Open Data Lx (http://www.lisboaparticipa.pt/pages/smartlx.php) é uma iniciativa promovida pela Câmara Municipal de Lisboa e pela AMA, com o objectivo de disponibilizar colecções de dados sobre a cidade de Lisboa. À semelhança do portal Dados.gov, é solicitada a utilização por parte dos cidadãos dos datasets disponibilizados, assim como a implementação de aplicações mashup.

(37)

2.1.3.3

Academic Playground & Innovation

O portal APIn (http://api.web.ua.pt/) resultou de um projecto de investigação financiando pela PTin e SAPO, em parceria com a UA. Este portal visa reunir um conjunto de serviços web de carácter público de três fornecedores: PTin, SAPO e UA. Contando com 75 serviços, este portal público incentiva ao desenvolvimento de aplicações com base nos serviços publicitados. Devido a informações sensíveis disponibilizados por alguns dos serviços, estes são considerados privados e apenas estão disponíveis para os alunos e funcionários da UA. À semelhança dos portais Dados.gov (2.1.3.1) e Open Data Lx (2.1.3.2), também estão disponíveis algumas aplicações que utilizam serviços públicos.

2.1.4

Open Data na Europa

Os portais open data europeus começaram a surgir no início de 2010, com a lançamento do portal data.gov.uk (http://data.gov.uk/) pelo governo do Reino Unido. Neste portal estão publicados cerca de 5400 datasets originários de departamentos governamentais, sectores públicos e autoridades locais. Nos temas mais populares encontram-se a saúde, transparência e finanças. Este portal reúne dados de Inglaterra, Irlanda do Norte, Escócia e País de Gales. Os dados disponibilizados neste website estão protegidos pela licença OGL.

Pela mesma data surgiu oLondon Datastore (http://data.london.gov.uk/). Dedicado a conjun-tos de dados da cidade de Londres, este portal disponibiliza inúmeros datasets e incentiva os cidadão a desenvolverem aplicações mashup. Em Abril de 2010 foi lançado o portal open data Austríaco. À seme-lhança dos portais já descritos, oData.gv.at (http://www.data.gv.at/) conta com inúmeros datasets, acessíveis em vários formatos. Este portal apenas está disponível na língua Alemã. A partir desta data começaram a surgir portais open data nacionais, como oData.overheid.nl (http://data.overheid.nl/) da Holanda, oDati.gov.it (http://www.dati.gov.it/) de Itália, o Data.gov.be (http://data.gov.be/) da Bélgica e, mais recentemente, oData.gouv.fr (http://www.data.gouv.fr/) de França, como também portais open data de cidades europeias, como oHelsinki Region Infoshare (http://www.hri.fi/en/), oOpen Data - Manchester City (http://www.manchester.gov.uk/opendata) ou oParis Data (http: //opendata.paris.fr/).

Todos estes portais partilham o mesmo conceito: divulgação do seus datasets e bases de dados e incentivo à implementação de aplicações que cruzem estes dados. Citando o portal London Datastore, “a disponibilização dos dados é apenas metade da batalha. Queremos encorajar Londrinos talentosos a transformarem linhas de texto e números em aplicações, websites ou produtos móveis de utilidade pública”.

2.1.5

Open Data no Mundo

Um pouco por todo o mundo foram surgindo portais governamentais de open data. Os grandes impulsi-onadores deste conceito, os Estados Unidos da América, foram os pioneiros no lançamento de um portal open data: oData.gov (www.data.gov). Neste portal é possível encontrar centenas de milhares (mais de

(38)

445 mil) datasets, que variam entre a educação, saúde, energia e segurança. Lançado em Maio de 2009, este portal conta com mais de 1500 publicações governamentais ou desenvolvidas por cidadãos.

Após o lançamento deste portal, diversas cidades dos EUA começaram a lançar os seus próprios website de open data: o San Francisco Data (https://data.sfgov.org/, oWashington Data Cata-log (http://data.dc.gov/), oCity of Chicago Data Portal (https://data.cityofchicago.org/) ou o NYC Open Data (https://nycopendata.socrata.com/), da cidade de Nova Iorque.

Paralelamente forma surgindo portais open data por outros países. Em Novembro de 2009 foi lançado o portalData.govt.nz (http://www.data.govt.nz/) da Nova Zelândia. De entre os datasets mais con-sultados, destacam-se as categorias geográfica, ambiental e desportiva. Em Maio de 2011, foi a vez do Canadá lançar o portalData.gc.ca (http://www.data.gc.ca/). Contando com cerca de 13 mil datasets, este website reúne informações de diversos departamentos e agências estatais.

Na continente Asiático também foram surgindo alguns portais open data. Em Junho de 2011 foi lan-çado o portalData.gov.sg (http://data.gov.sg/) do governo de Singapura, que disponibiliza mais de 5000 datasets provenientes de 50 ministérios e agências. Este portal tem como objectivos o acesso con-veniente a dados governamentais por parte dos cidadãos, a criação de valor através do desenvolvimento de aplicações e facilitar a investigação baseada nos dados fornecidos. Na Arábia Saudita foi lançado o portal SAUDI Open Data (http://saudi.gov.sa/) em Setembro de 2011. Contando com inúmeros datasets, estes estão divididos por várias categorias, como condições atmosféricas, serviços sociais ou indústria. Embora este website disponibilize bastantes informações, maior parte destas são relativas a anos anteriores a 2010.

Em África também existem iniciativas open data. Por exemplo, o governo queniano lançou a 8 de Julho de 2011 o portalKenya Open Data (https://opendata.go.ke/). Considerado o primeiro portal open data de uma país em vias de desenvolvimento, e o segundo do continente Africano, os primeiros datasets publicados foram referentes ao census de 2009 e exportações regionais e nacionais. O primeiro portal open data do continente Africano foi o Data.gov.ma (http://data.gov.ma/), do governo de Marrocos. Este portal conta com inúmeros datasets, principalmente sobre educação e finanças. Todos os dados contidos neste portal são disponibilizados ao abrigo da licença ODbL.

Além de países, também algumas instituições lançaram os seus portais open data. Em Março de 2010 o Google lançou oPublic Data Explorer (http://www.google.com/publicdata/directory). Este por-tal permite explorar e visualizar datasets de interesse público, assim como o desenvolvimento de gráficos mashup de várias fontes de dados. Posteriormente, em Abril de 2010, o Banco Mundial inaugurou o portalThe World Bank Data (http://data.worldbank.org/). Neste portal é possível aceder a dados do Banco Mundial, que se encontram categorizados por país, tópico e indicadores. Em Junho de 2010, a UE lançou o portalPublicData.EU (http://publicdata.eu/). Este portal partiu da iniciativa de agregar num único local datasets europeus que se encontram divididos por diversos websites.

Na figura 2.4 estão representadas as datas de lançamento dos portais open data descritos anterior-mente. É possível constatar que a maioria deste websites foram lançados em 2011, o que prova a recente

(39)

divulgação do conceito open data. À medida que alguns regimes são substituídos e mentalidades altera-das, há lugar para a divulgação de dados de interesse público que podem permitir melhorar sistemas e processos governamentais ou institucionais.

(40)

2. EST ADO D A AR TE

2.1.6

Cronologia do Lançamento de Portais Open Data

Janeiro 2010

Data.gov.uk

London Datastore

Fevereiro 2010

Washington Data Catalog

Maio 2011

City of Chicago Data Portal

Outubro 2011

Dati.gov.it

NYC Open Data

Academic Playground

& Innovation

Julho 2011

Dados.gov.pt

Kenya Open Data

Agosto 2009

San Francisco Data

Junho 2010

PublicData.EU

Helsinki Region Infoshare

Setembro 2011

Data.gov.be

Open Data Berlin

SAUDI Open Data

Novembro 2009

Data.govt.nz

Toronto Open Data

Março 2010

Google Public Data Explorer

Abril 2010

Data.gv.at

The World Bank Data

Maio 2009

Data.gov (EUA)

Dezembro 2011

Data.gouv.fr

Open Data Lx

OpenData BCN

2009

2010

2011

2012

Junho 2011

Data.gov.sg

Dezembro 2010

Open Data - Manchester City

Data.overheid.nl

Paris Data

Março 2011

Data.gov.ma

Data.gc.ca

Figura 2.4: Cronologia do lançamento de portais open data

(41)

2.1.7

Representação de Dados

Neste secção é tratada a problemática da disseminação de dados. Com a disponibilização de dados e datasets através da Internet, é necessária a utilização de formatos padrão e livres para a sua trans-missão. Hoje em dia o formato mais utilizado é o XML, seguido de perto do JavaScript Object Notation (JSON). Devido ao problema de acesso a dados presentes em domínios diferentes através de uma página web, surgiu a necessidade de implementação de um formato JavaScript (JS), para a representação de dados JSON, denominado de JSON with Padding (JSONP). Também será estudado o formato Comma Separated Values (CSV), utilizado para a transmissão de grandes quantidades de informação.

2.1.7.1

eXtensible Markup Language

A XML é uma linguagem de marcação desenvolvida com o intuito de transportar dados. Derivada da metalinguagem Standard Generalized Markup Language (SGML), a primeira versão (1.0) do XML foi especificado pelo World Wide Web Consortium (W3C) em 1996 e surgiu devido à complexidade do SGML. O consórcio W3C é uma organização internacional com o intuito de desenhar e desenvolver standards web, protocolos e guias que permitam que o World Wide Web (WWW) seja um canal de comunicação seguro, tanto para providenciar serviços como para criar conteúdos.

O XML é um formato aberto e foi desenvolvido com o intuito de ser uma linguagem simples, concisa, legível e de fácil utilização através da Internet [Bray 2008].

A informação que é estruturada através de um ficheiro XML pode conter vários tipos de dados, tais como texto e imagens. A estruturação da informação é essencial num ficheiro XML, pois especifica o contexto dos dados presentes e o seu papel no conjunto. É também importante especificar a codificação dos caracteres presentes neste tipo de ficheiros [RFC 3023].

1 <?xml version="1.0" encoding="utf-8"?> 2 <filmes>

3 <filme>

4 <titulo>The Avengers</titulo>

5 <ano>2012</ano>

6 <duracao metrica="min">142</duracao>

7 <resumo>Nick Fury of S.H.I.E.L.D. brings together a team of super humans to form The Avengers to help save the Earth from Loki and his army.</resumo>

8 <actores>

9 <actor>Robert Downey Jr.</actor>

10 <actor>Scarlett Johansson</actor>

11 <actor>Jeremy Renner</actor>

12 <actor>Tom Hiddleston</actor>

13 </actores> 14 <categorias> 15 <accao /> 16 <aventura /> 17 </categorias> 18 </filme> 19 </filmes>

No exemplo anterior é possível identificar várias características inerentes a um ficheiro XML:

Codificação: Na linha (01), o atributo encoding=”utf-8” especifica que o documento está codificado no formato Unicode Transformation Format-8 (UTF-8).

(42)

Elementos: Os elementos são cadeias de caracteres delimitadas pelos caracteres menor (<) e maior (>), e permitem identificar a natureza dos dados que contêm. Os elementos podem ser, ou não, vazios. Por exemplo, nas linhas (15) e (16) existem dois elementos vazios. Os elementos também são muitas vezes apelidados de tags.

Atributos: Os atributos são pares nome-valor declarados após o nome do elemento. Normalmente são usados para indicar informação adicional ao elemento. Por exemplo, na linha (06), o elemento duracaocontem o valor indicativo da duração do filme. O atributo metrica permite especificar as unidades da duração do filme (neste caso em minutos).

Estruturas de dados: No exemplo anterior é possível identificar algumas estruturas de dados que permitem contextualizar a informação a ser transmitida. Por exemplo, a estrutura filme contém seis elementos filho que, no seu todo, representam um filme: titulo, ano, duracao, resumo, actorese categorias. A mesma analogia pode ser aplicada às estruturas de dados actores e categorias.

A elasticidade na representação de informação através de ficheiros XML leva a que muitas outras tecnologias web utilizem este meio para o transporte de informação. Por exemplo, o XML é utilizado para a representação de webfeeds, tanto através do formato Atom Syndication Format (Atom) como também do Really Simple Syndication1(RSS). É igualmente bastante utilizado em serviços web, tanto na

arquitectura SOAP como na arquitectura REST. O protocolo de comunicações eXtensible Messaging and Presence Protocol (XMPP), bastante utilizado para serviços de chat (GTalk, Facebook Chat, etc), utiliza o XML como formato das mensagens.

O XML também é utilizado no protocolo XML-Remote Procedure Calling (XML-RPC). O XML-RPC define um formato XML para mensagens que são transmitidas entre clientes e servidores, através do protocolo HyperText Transfer Protocol (HTTP) [RFC 3529].

Vantagens do XML

• Flexibilidade, acessibilidade e portabilidade.

• O formato e linguagem de um ficheiro XML é definido pelo utilizador, proporcionando uma fácil adaptação e legibilidade.

• Possibilidade de representar relações complexas, como estruturas em árvore e herança.

• Suporte de Unicode, permitindo transmitir quase todos os caracteres em diversas codificações.

• Suporta schemas e namespaces.

Desvantagens do XML

• Necessidade de existir uma aplicação middleware que processe o ficheiro XML.

(43)

• Susceptibilidade a redundância.

• Linguagem muito expressiva: maior overhead.

• Inexistência de tipos de dados (integer, boolean, etc).

2.1.7.2

JavaScript Object Notation

À semelhança do XML, o formato JSON é baseado em texto e foi desenhado com o intuito de trans-portar e representar dados. Definido como um subconjunto da linguagem de programação JS, o JSON permite tanto uma leitura como escrita bastante simples. Embora tenha sido oferecida alguma resistência à adopção deste formato para a transmissão de dados, o JSON começa a rivalizar com o XML para a transmissão de informação, devido principalmente ao processamento e utilização mais simples e eficaz por parte de sistemas computacionais [Severance 2012]. O JSON assenta sobre duas estruturas de da-dos: uma colecção de pares nome-valor e uma lista ordenada de valores, que podem ser representadas através das seguintes formas [JSON 2006, RFC 4627]:

Objecto

Um objecto é um conjunto não ordenado nome-valor, que começa com o chaveta à esquerda ({) e termina cm chaveta à direita (}). Cada nome é procedido de dois pontos (:) e do valor. Cada par nome-valor é separado por vírgula (,).

Figura 2.5: Objecto em JSON. Fonte: [JSON 2006]

Array

Um array representa uma colecção ordenada de valores. É delimitado por parêntesis recto à esquerda ([) e parêntesis recto à direita (]). Os valores de um array são separados por vírgula (,).

Figura 2.6: Array em JSON. Fonte: [JSON 2006]

Valor

Um valor pode representar uma string (delimitada por aspas (“”)), um número, um booleano (true e false), um objecto, um array ou um objecto nulo (null).

(44)

Figura 2.7: Valor em JSON. Fonte: [JSON 2006]

String

Uma string é uma sequência de zero ou mais caracteres Unicode, delimitadas por aspas (“”). A codificação por defeito de um ficheiro JSON é UTF-8.

Figura 2.8: String em JSON. Fonte: [JSON 2006]

Número

Um número é representado em JSON da mesma forma que é representado nas linguagens de progra-mação C e JAVA. No entanto, os formatos octal e hexadecimal não são utilizados.

Figura 2.9: Número em JSON. Fonte: [JSON 2006]

As estruturas de dados descritas anteriormente podem ser facilmente identificadas no exemplo se-guinte:

(45)

1 {

2 "filmes": {

3 "filme": {

4 "titulo": "The Avengers",

5 "ano": 2012,

6 "duracao": {

7 "metrica": "min",

8 "value": 142

9 },

10 "resumo": "Nick Fury of S.H.I.E.L.D. brings together a team of super humans to form The Avengers to help save the Earth from Loki and his army.",

11 "actores": { 12 "actor": [ 13 "Robert Downey Jr.", 14 "Scarlett Johansson", 15 "Jeremy Renner", 16 "Tom Hiddleston" 17 ] 18 }, 19 "categorias": { 20 "accao": null, 21 "aventura": null 22 } 23 } 24 } 25 }

Objecto: Representado, por exemplo, nas linhas (03) a (23). O nome do objecto é “filme” e o valor é um conjunto de objectos.

Array : Na linha (12) é definido um array. Conta com 3 elementos (strings), devidamente separados por vírgula.

Vantagens do JSON

• Linguagem pouco expressiva: menor overhead.

• Parte integrante do JS, permitindo uma maior flexibilidade e tratamento dos dados.

• É possível importar dados de origens diferentes através de JSONP.

Desvantagens do JSON

• Falta de suporte a namespaces.

• Bastante sensível a erros de sintaxe.

2.1.7.3

JavaScript Object Notation with Padding

Com a introdução de portais web 2.0 (ver Web 2.0 (2.6)), o processamento e renderização das páginas web é efectuado no lado do cliente. Este característica permite a implementação de mashups, com a obtenção de dados a ser realizada directamente a partir do browser. Através da tecnologia Asynchronous JavaScript and XML (AJAX), é possível que um cliente (browser ) efectue pedidos HTTP assincronamente.

Referências

Documentos relacionados

Apesar de o mercado acionário brasileiro ter se tornado mais importante para a economia brasileira, sobretudo entre o período de 2002 para 2005 (Tabela 3), sua repre- sentatividade

No caso de uma apresentação de Artigo em formato Áudio, o arquivo deverá ser enviado em CD por correio postal para:.. Comitê Editorial INFEIES - RM

Parágrafo segundo – Não ocorrendo a citada homologação por responsabilidade do SESI-SP, em até 30 (trinta) dias após o prazo máximo para o pagamento das

No final, os EUA viram a maioria das questões que tinham de ser resolvidas no sentido da criação de um tribunal que lhe fosse aceitável serem estabelecidas em sentido oposto, pelo

Os instrumentos de pesquisa utilizados serão: Ficha de Rastreamento das Participantes do Estudo, International Consultation on Incontinence Questionnaire – Short Form

O objetivo deste estudo foi avaliar o comporta- mento clínico de lesões de dermatite digital bovina após tratamento cirúrgico, uso local e parenteral de oxitetraci- clina e passagem

A infecção pelo Vaccinia vírus não é totalmente considerada como de ocorrência natural, embora transmissão de ordenhadores para vacas e de vacas para o homem tenham ocorrido,

Desta forma, o objetivo deste trabalho foi estimar a diversidade genética para o pré-melhoramento de indivíduos de jenipapo procedentes do Estado de Sergipe, e avaliar o