MAYCON VIANA BORDIN

DESENVOLVIMENTO DE UMA REDE SOCIAL BASEADA EM GEOLOCALIZAO

Trs de Maio 2012

MAYCON VIANA BORDIN

DESENVOLVIMENTO DE UMA REDE SOCIAL BASEADA EM GEOLOCALIZAO

Relatrio do Estgio Final de Curso Sociedade Educacional Trs de Maio Faculdade Trs de Maio Curso de Bacharelado em Sistemas de Informao

Orientador: M. Sc. Claudio Schepke

Trs de Maio 2012

TERMO DE APROVAO

A banca Examinadora aprova o Trabalho de Estgio Final de Curso: DESENVOLVIMENTO DE UMA REDE SOCIAL BASEADA EM GEOLOCALIZAO de autoria de: MAYCON VIANA BORDIN como requisito para obteno do ttulo de Bacharel em Sistemas de Informao, concedido pela Faculdade Trs de Maio SETREM.

Banca examinadora:

M.Sc. Claudio Schepke Professor Orientador, Faculdade Trs de Maio SETREM

Vera Lcia Lorenset Benedetti Faculdade Trs de Maio SETREM

M.Sc. Fauzi de Moraes Shubeita Faculdade Trs de Maio SETREM

Marcelo Andr Ackermann Faculdade Trs de Maio SETREM

Trs de Maio, 31 de julho de 2012.

RESUMO

Fruns foram utilizados por muito tempo na Internet como principal ferramenta para criao de comunidades online e discusses sobre determinados assuntos. Com o surgimento das redes sociais, o foco de grande parte da Internet passou a ser o indivduo e suas relaes com outras pessoas. Com elas tambm foram introduzidas novas funcionalidades que melhoraram a experincia de seus usurios e possibilitaram uma melhor comunicao com outras pessoas. Este trabalho buscou unir algumas destas funcionalidades na tentativa de criar um frum que se adequasse a realidade atual sem, entretanto perder as caractersticas bsicas de um frum. O servio focou primeiramente dispositivos mveis, mantendo uma interface de usurio simples, reunindo todos os interesses em um nico lugar e permitindo que usurios sigam interesses e ltrem conversas de acordo com a sua localizao. Essas aes tornaram possvel a criao de um frum diferente e que pode ser til e de fcil uso para as pessoas, mesmo com relao as redes sociais. Palavras-chave: Redes sociais, computao mvel, computao nas nuvens, geolocalizao.

ABSTRACT

Internet forums have been used for many time as a main tool for online community creation and discussion about subjects. With the rise of social networks, the focus of much of the Internet has become the individual and his relations with others. With them were also introduced new features that improve the experience for their users and enabled better communication with others. This work aimed to join some of these features in an attempt to create a internet forum that would t the current reality without losing the basic characteristics of a forum. The service primarily focused mobile devices, while maintaining a simple user interface, bringing together all interests in one place and allowing users to follow interests and lter conversations according to their location. These actions made it possible to create a different forum and can be useful and easy to use for people, even in comparison with social networks. Keywords: Social networks, mobile computing, cloud computing, geolocation.

LISTA DE FIGURAS

Figura 2.1: Visibilidade de contedo com base em um relacionamento de dois nveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 2.2: Exemplos de objetos sociais. . . . . . . . . . . . . . . . . . . . . . . Figura 2.3: Linha do tempo de lanamento das redes sociais. . . . . . . . . . . Figura 2.4: Home page do Facebook. . . . . . . . . . . . . . . . . . . . . . . . . Figura 2.5: Timeline do Facebook. . . . . . . . . . . . . . . . . . . . . . . . . .

32 33 35 38 39 40 42 43 45 47 49 51

Figura 2.6: Aplicativo do Facebook para Android. . . . . . . . . . . . . . . . . . Figura 2.7: Home page do LinkedIn. . . . . . . . . . . . . . . . . . . . . . . . . Figura 2.8: Home page do Twitter. . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 2.9: Aplicativo do Twitter para iPhone. . . . . . . . . . . . . . . . . . . . . Figura 2.10: Aplicativo do Instagram para iPhone. . . . . . . . . . . . . . . . . . . Figura 2.11: Aplicativo do Pinterest para iPhone. . . . . . . . . . . . . . . . . . . Figura 2.12: Aplicativo do Path para iPhone. . . . . . . . . . . . . . . . . . . . . .

Figura 2.13: Comparao entre fruns non-threaded, semi-threaded e fully-threaded. 53 Figura 2.14: Diagrama da latitude e longitude na Terra. . . . . . . . . . . . . . . . Figura 2.15: Figuras da Terra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 59

Figura 2.16: Mapa do mundo segundo a projeo de Mercator. . . . . . . . . . . Figura 2.17: GPS utilizando satlites para obter sua localizao. . . . . . . . . . Figura 2.18: A interseco de tecnologias que formam o LBS. . . . . . . . . . . . Figura 2.19: Categorias de aplicaes LBS. . . . . . . . . . . . . . . . . . . . . . Figura 2.20: Componentes de um LBS. . . . . . . . . . . . . . . . . . . . . . . . Figura 2.21: Camadas de dados de um GIS. . . . . . . . . . . . . . . . . . . . . Figura 2.22: Japan Tohoku Earthquake. . . . . . . . . . . . . . . . . . . . . . . . Figura 2.23: Principais padres da OGC. . . . . . . . . . . . . . . . . . . . . . . Figura 2.24: Exemplos de geocoding. . . . . . . . . . . . . . . . . . . . . . . . . Figura 2.25: Tendncia da palavra geolocation. . . . . . . . . . . . . . . . . . . . Figura 2.26: Aplicativo do Yelp para iPhone. . . . . . . . . . . . . . . . . . . . . . Figura 2.27: Aplicativo Google Latitude para iPhone. . . . . . . . . . . . . . . . . Figura 2.28: Aplicativo do Loopt para iPhone. . . . . . . . . . . . . . . . . . . . . Figura 2.29: Aplicativo do Foursquare para iPhone. . . . . . . . . . . . . . . . . . Figura 2.30: Aplicativo do Glympse para iPhone. . . . . . . . . . . . . . . . . . . Figura 2.31: Aplicativo do Shopkick para iPhone. . . . . . . . . . . . . . . . . . . Figura 2.32: Exemplo de uso do Layar Reality Browser. . . . . . . . . . . . . . . Figura 2.33: Comparao entre browsers de realidade aumentada. . . . . . . . . Figura 2.34: Mtodos do objeto Geolocation. . . . . . . . . . . . . . . . . . . . . Figura 2.35: Mtodos do objeto Geolocation. . . . . . . . . . . . . . . . . . . . . Figura 2.36: Vericando suporte a API de geolocalizao. . . . . . . . . . . . . .

61 65 68 69 71 72 73 75 80 81 83 85 86 87 88 89 91 93 95 96 96

Figura 2.37: Estruturas comuns de uma arquitetura de software. . . . . . . . . . 100

Figura 2.38: Relacionamento entre modelos de referncia, padres de arquitetura, arquiteturas de referncia e arquiteturas de software. . . . . . 103 Figura 2.39: Tempos de resposta hipotticos com a mesma mdia. . . . . . . . . 107 Figura 2.40: Balanceador de carga e cache farm. . . . . . . . . . . . . . . . . . . 111 Figura 2.41: Inuncias dos meios de uma arquitetura. . . . . . . . . . . . . . . . 116 Figura 2.42: Inuncias dos meios de uma arquitetura. . . . . . . . . . . . . . . . 118 Figura 2.43: Acesso a um subsistema sem e com um facade. . . . . . . . . . . . 123 Figura 2.44: Viso geral das arquiteturas bsicas. . . . . . . . . . . . . . . . . . 131 Figura 2.45: Exemplo de arquitetura three-tier. . . . . . . . . . . . . . . . . . . . 133 Figura 2.46: Classicao de middlewares. . . . . . . . . . . . . . . . . . . . . . 135 Figura 2.47: Abstraes chave de um SOA. . . . . . . . . . . . . . . . . . . . . . 138 Figura 2.48: Viso geral dos conceitos de arquiteturas de Cloud Computing. . . 141

Figura 2.49: Taxonomia da Cloud Computing. . . . . . . . . . . . . . . . . . . . . 142 Figura 2.50: Viso lgica da arquitetura do servidor do MySQL. . . . . . . . . . . 146 Figura 2.51: Funcionamento da replicao no MySQL. . . . . . . . . . . . . . . . 150 Figura 2.52: Exemplo de hashing consistente, antes e depois da entrada e sada de um n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Figura 2.53: Diferenas entre layouts de armazenamento. . . . . . . . . . . . . . 163 Figura 2.54: Categorias de cdigos de status HTTP. . . . . . . . . . . . . . . . . 172 Figura 2.55: Exemplo bsico de autenticao HTTP. . . . . . . . . . . . . . . . . 174 Figura 2.56: Autorizao de aplicao no Google utilizando OAuth2. . . . . . . . 177 Figura 2.57: Os trs estgios dos arquivos no Git. . . . . . . . . . . . . . . . . . 190 Figura 2.58: Objetos no primeiro e segundo commits. . . . . . . . . . . . . . . . 191

Figura 2.59: Relacionamento entre os metadados no Mercurial. . . . . . . . . . . 193 Figura 2.60: Cache baseado em timeout e invalidao explcita. . . . . . . . . . 195 Figura 2.61: Interao entre aplicao, Sphinx e banco de dados. . . . . . . . . . 198 Figura 2.62: Arquitetura do LinkedIn de 2003 a 2005. . . . . . . . . . . . . . . . . 209 Figura 2.63: Arquitetura Atual (em 2008) do LinkedIn. . . . . . . . . . . . . . . . 210 Figura 2.64: Arquitetura distribuda de busca do LinkedIn. . . . . . . . . . . . . . 211 Figura 2.65: Exemplo de atividades em uma backstack, compondo uma atividade. 220 Figura 2.66: Exemplo de hierarquia da inerface grca no Android. . . . . . . . . 221 Figura 2.67: Camadas do iOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Figura 3.1: Esquema de autenticao do servio. . . . . . . . . . . . . . . . . . 235 Figura 3.2: Tempo mdio de execuo no MySQL. . . . . . . . . . . . . . . . . 247 Figura 3.3: Tempo mdio de execuo no PostgreSQL. . . . . . . . . . . . . . . 249 Figura 3.4: Modelo ER da aplicao. . . . . . . . . . . . . . . . . . . . . . . . . 257 Figura 3.5: Esquema da infraestrutura utilizando os servios da Amazon AWS. 258

Figura 3.6: Primeiros mockups do aplicativo. . . . . . . . . . . . . . . . . . . . . 263 Figura 3.7: Tela principal da aplicao, exibe as conversas mais populares entre os interesses seguidos pelo usurio. . . . . . . . . . . . . . . . . . . 264 Figura 3.8: Tela de uma conversa e suas respectivas respostas. . . . . . . . . . 265 Figura 3.9: Perl de um usurio, exibindo as suas conversas mais recentes. . . 266 Figura 3.10: Tela de busca de interesses. . . . . . . . . . . . . . . . . . . . . . . 267 Figura 3.11: Tela do interesse sobre Fotograa. . . . . . . . . . . . . . . . . . . . 268 Figura 3.12: Tela para criao de nova conversa. . . . . . . . . . . . . . . . . . . 270

LISTA DE QUADROS

Quadro 1.1: Cronograma das principais atividades do trabalho. . . . . . . . . . . Quadro 1.2: Cronograma das principais atividades do trabalho. . . . . . . . . . .

25 26

Quadro 2.1: Classicao de patterns. . . . . . . . . . . . . . . . . . . . . . . . . 130 Quadro 3.1: Exemplo de clculo de popularidade. . . . . . . . . . . . . . . . . . 232 Quadro 3.2: Lista de recursos e mtodos da API. . . . . . . . . . . . . . . . . . . 238 Quadro 3.3: Parmetros para consultas na API. . . . . . . . . . . . . . . . . . . . 239 Quadro 3.4: Cdigos de status HTTP. . . . . . . . . . . . . . . . . . . . . . . . . 239 Quadro 3.5: Cdigos de erros de validao. . . . . . . . . . . . . . . . . . . . . . 240 Quadro 3.6: Software utilizado e suas verses. . . . . . . . . . . . . . . . . . . . 244 Quadro 3.7: Resultado dos testes no MySQL. . . . . . . . . . . . . . . . . . . . . 246 Quadro 3.8: Resultado dos testes no PostgreSQL. . . . . . . . . . . . . . . . . . 250 Quadro 3.9: Comparao entre softwares para consultas em dados espaciais. . 250

LISTA DE ABREVIATURAS E SIGLAS

ACID AOSD API APNS AR B2B BASE BLOB BPO BSON CAP CDMA CDN CLOB CoC CSS DaaS DBMS DDL DNS DRDB DSL DTO

Atomicity, Correctness, Isolation and Durability Aspect-Oriented Software Development Application Programming Interface Apple Push Notication Service Augmented Reality Business-to-business Basic Available, Soft-state, Eventual consistency Binary Large Object Business Process Orchestrator Binary JSON Consistency, Availability and Partition Tolerance Code Division Multiple Access Content Distribution Network Character Large Object Convention over Conguration Cascading Style Sheets Database as a Service Database Management System Data Denition Language Domain Name System Distributed Replicated Block Device Domain-Specic Language Data Transfer Object

12

DVCS ECMA ED ESB FCC GFS GIS GML GNSS GPL GPS GRASS GSM GWT HTML HTTP HTTPS IaaS INFaaS INTaaS IoC IP IPO ISP JAAS JIT JMS JSON JVM LAMP LBS LSBN LSM

Distributed Version Control System European Computer Manufacturers Association European Datum Enterprise Service Bus Federal Communications Commission Google File System Geographic Information Systems Geography Markup Language Global Navigation Satellite System GNU General Public License Global Positioning System Geographic Resources Analysis Support System Global System for Mobile Communications Google Web Toolkit HyperText Markup Language Hypertext Transfer Protocol Secure HTTP Infrastructure as a Service Information as a Service Integration as a Service Inversion of Control Internet Protocol Initial Public Offering Internet Service Provider Java Authentication and Authorization Service Just-in-time Java Message Service JavaScript Object Notation Java Virtual Machine Linux + Apache + MySQL + PHP/Perl/Python Location-based Services Location-based Social Networks Log Sctructured Merge

13

MPS MSL MTTF MTTR MVCC MVC NAD OAuth OGC OGF OpenLS ORM ORM OWS P2P PaaS PKI RAC RCS REST RMI ROA RPC RPS RT RYOW SaaS SAN SensorML SFA SGBD SLD SOAP

Messages per second Mean Sea Level Mean Time to Failure Mean Time to Repair Multiversion Concurrency Control Model-View-Controller North American Datum Open Authorization Open Geospatial Consortium Open GRASS Foundation Open Location Services Object-Relational Mapping OGC Reference Model OGC Web Services Peer-to-peer Platform as a Service Public Key Infrastructure Real Application Cluster Revision Control System Representational State Transfer Remote Message Invocation Resource Oriented Architecture Remote Procedure Call Requests per second Retweet Read Your Own Writes Software as a Service Storage Area Network Sensor Model Language Simple Features Access Sistema de Gerenciamento de Banco de Dados Style Layer Description Simple Object Access Protocol

SOA SOI SPOF SQL SSL STaaS SXSW TPS TPS URI URL VCS W3C WCS WFS WGS WMS WPS WSDL WSGI XML XSD

Service Oriented Architecture Service Oriented Infrastructure Single Point of Failure Structured Query Language Secure Socket Layer Storage as a Service South By Southwest Transactions per second Transport Secure Layer Uniform Resource Identier Uniform Resource Locator Version Control System World Wide Web Consortium Web Coverage Service Web Feature Service World Geodetic System Web Map Service Web Processing Service Web Service Description Language Web Server Gateway Interface eXtended Markup Language XML Schema Denition

SUMRIO

INTRODUO . . . . . . . . . . . . . . . . . . . CAPTULO 1: ASPECTOS METODOLGICOS 1.1 TEMA . . . . . . . . . . . . . . . . . . . 1.1.1 Delimitao do Tema . . . . . . . . . . 1.2 PROBLEMA . . . . . . . . . . . . . . . 1.3 JUSTIFICATIVA . . . . . . . . . . . . . 1.4 HIPTESES . . . . . . . . . . . . . . . 1.5 OBJETIVOS . . . . . . . . . . . . . . . 1.5.1 Objetivo Geral . . . . . . . . . . . . . . 1.5.2 Objetivos Especcos . . . . . . . . . 1.6 METODOLOGIA . . . . . . . . . . . . . 1.6.1 Mtodos de Abordagem . . . . . . . . 1.6.2 Mtodos de Procedimentos . . . . . . 1.6.3 Tcnicas de Pesquisa . . . . . . . . . 1.7 ORAMENTO . . . . . . . . . . . . . . 1.8 RECURSOS . . . . . . . . . . . . . . . 1.9 CRONOGRAMA . . . . . . . . . . . . . CAPTULO 2: FUNDAMENTAO TERICA . 2.1 SOCIAL SOFTWARE . . . . . . . . . . 2.1.1 Redes Sociais . . . . . . . . . . . . . . 2.1.1.1 Caractersticas . . . . . . . . . . . . . . 2.1.1.2 Histria . . . . . . . . . . . . . . . . . . 2.1.1.3 Facebook . . . . . . . . . . . . . . . . . 2.1.1.4 LinkedIn . . . . . . . . . . . . . . . . . . 2.1.1.5 Twitter . . . . . . . . . . . . . . . . . . . 2.1.1.6 Instagram . . . . . . . . . . . . . . . . . 2.1.1.7 Pinterest . . . . . . . . . . . . . . . . . 2.1.1.8 Path . . . . . . . . . . . . . . . . . . . . 2.1.2 Fruns . . . . . . . . . . . . . . . . . . 2.1.3 Identidade . . . . . . . . . . . . . . . . 2.2 GEOLOCALIZAO . . . . . . . . . . . 2.2.1 Sistemas de Coordenadas . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19 21 21 21 21 22 23 23 23 23 24 24 24 25 25 25 25 27 27 29 29 33 37 41 42 46 48 50 52 53 55 56

16

2.2.2 2.2.3 2.2.4 2.2.5 2.2.5.1 2.2.5.2 2.2.5.3 2.2.6 2.2.7 2.2.8 2.2.9 2.2.10 2.2.11 2.2.11.1 2.2.11.2 2.2.12 2.3 2.3.1 2.3.1.1 2.3.1.2 2.3.1.3 2.3.1.4 2.3.1.5 2.3.1.6 2.3.2 2.3.2.1 2.3.2.2 2.3.2.3 2.3.2.4 2.3.2.5 2.3.2.6 2.3.2.7 2.3.2.8 2.3.3 2.3.4 2.3.4.1 2.3.4.2 2.4 2.4.1 2.4.1.1 2.4.1.2 2.4.1.3 2.4.2 2.4.2.1 2.4.2.2

Sistemas Geodticos e Datums . . . . . . Outros Conceitos . . . . . . . . . . . . . . . Distncia do Grande-Crculo . . . . . . . . Mtodos de Localizao . . . . . . . . . . . GPS (Global Positioning System) . . . . . . Endereo IP . . . . . . . . . . . . . . . . . . GSM/CDMA Cell IDs . . . . . . . . . . . . . Location-based Services . . . . . . . . . . GIS (Geographic Information Systems) . . Padres . . . . . . . . . . . . . . . . . . . . Spatial databases . . . . . . . . . . . . . . Geocoding . . . . . . . . . . . . . . . . . . . Aplicaes e Servios . . . . . . . . . . . . Social Media e Location-Sharing Applications Augmented Reality Applications . . . . . . . W3C Geolocation API . . . . . . . . . . . . ARQUITETURA DE SOFTWARE . . . . . . Atributos de Qualidade . . . . . . . . . . . Performance . . . . . . . . . . . . . . . . . . Escalabilidade . . . . . . . . . . . . . . . . . Modicabilidade . . . . . . . . . . . . . . . . Segurana . . . . . . . . . . . . . . . . . . . Avaliabilidade . . . . . . . . . . . . . . . . . Outros Atributos . . . . . . . . . . . . . . . . Princpios . . . . . . . . . . . . . . . . . . . Baixo Acoplamento . . . . . . . . . . . . . . Alta Coeso . . . . . . . . . . . . . . . . . . Projetar para Mudana . . . . . . . . . . . . Separao de Responsabilidades . . . . . . Ocultamento de Informaes . . . . . . . . . Abstrao . . . . . . . . . . . . . . . . . . . . Modularidade . . . . . . . . . . . . . . . . . . Outros Princpios . . . . . . . . . . . . . . . Patterns . . . . . . . . . . . . . . . . . . . . Arquiteturas Bsicas . . . . . . . . . . . . . Service Oriented Architecture . . . . . . . . Cloud Computing Architectures . . . . . . . . BANCO DE DADOS . . . . . . . . . . . . . . Bancos de Dados Relacionais . . . . . . . MySQL . . . . . . . . . . . . . . . . . . . . . PostgreSQL . . . . . . . . . . . . . . . . . . SQLite . . . . . . . . . . . . . . . . . . . . . NoSQL . . . . . . . . . . . . . . . . . . . . . Conceitos . . . . . . . . . . . . . . . . . . . . Key/Value Stores . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58 61 62 63 64 65 66 67 71 74 77 79 80 82 90 94 98 104 106 108 112 113 114 115 116 117 120 121 122 123 124 126 126 127 130 135 138 142 144 145 154 156 156 158 164

17

2.4.2.3 Document Databases . . . . . . . . . . . . . 2.4.2.4 Column-Oriented Databases . . . . . . . . . 2.5 WEB SERVICES . . . . . . . . . . . . . . . . 2.5.1 RPC-Style . . . . . . . . . . . . . . . . . . . 2.5.2 REST-RPC . . . . . . . . . . . . . . . . . . . 2.5.3 RESTful . . . . . . . . . . . . . . . . . . . . 2.5.4 Autenticao e Autorizao . . . . . . . . . 2.5.4.1 HTTP: Autenticao Bsica . . . . . . . . . . 2.5.4.2 OAuth . . . . . . . . . . . . . . . . . . . . . . 2.6 FERRAMENTAS DE DESENVOLVIMENTO . 2.6.1 Linguagens de Programao . . . . . . . . 2.6.1.1 Javascript . . . . . . . . . . . . . . . . . . . . 2.6.1.2 Python . . . . . . . . . . . . . . . . . . . . . 2.6.1.3 Ruby . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Frameworks . . . . . . . . . . . . . . . . . . 2.6.2.1 Ruby on Rails . . . . . . . . . . . . . . . . . 2.6.2.2 Microframeworks . . . . . . . . . . . . . . . . 2.6.3 Sistemas de Controle de Verso . . . . . . 2.6.3.1 Git . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3.2 Mercurial . . . . . . . . . . . . . . . . . . . . 2.6.4 Object Cache . . . . . . . . . . . . . . . . . 2.6.4.1 memcached . . . . . . . . . . . . . . . . . . 2.6.4.2 Redis . . . . . . . . . . . . . . . . . . . . . . 2.6.5 Search Server . . . . . . . . . . . . . . . . . 2.6.5.1 Sphinx . . . . . . . . . . . . . . . . . . . . . 2.6.5.2 Solr . . . . . . . . . . . . . . . . . . . . . . . 2.6.6 Servidores de Aplicao . . . . . . . . . . 2.6.7 Servidores HTTP . . . . . . . . . . . . . . . 2.6.7.1 Apache . . . . . . . . . . . . . . . . . . . . . 2.6.7.2 Nginx . . . . . . . . . . . . . . . . . . . . . . 2.6.8 Deployment . . . . . . . . . . . . . . . . . . 2.6.8.1 Amazon AWS . . . . . . . . . . . . . . . . . 2.6.8.2 Heroku . . . . . . . . . . . . . . . . . . . . . 2.7 SOLUTION STACKS . . . . . . . . . . . . . 2.7.1 Instagram . . . . . . . . . . . . . . . . . . . 2.7.2 LinkedIn . . . . . . . . . . . . . . . . . . . . 2.8 COMPUTAO MVEL . . . . . . . . . . . . 2.8.1 Evoluo . . . . . . . . . . . . . . . . . . . . 2.8.2 Plataformas . . . . . . . . . . . . . . . . . . 2.8.3 Android . . . . . . . . . . . . . . . . . . . . 2.8.4 iOS . . . . . . . . . . . . . . . . . . . . . . . 2.8.5 Web Mvel . . . . . . . . . . . . . . . . . . . CAPTULO 3: RESULTADOS OBTIDOS . . . . . . . 3.1 MOTIVAO . . . . . . . . . . . . . . . . . . 3.2 FUNCIONALIDADES E CARACTERSTICAS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

165 165 166 167 169 169 173 173 175 178 178 178 181 183 184 185 185 186 187 191 194 196 197 197 198 199 200 201 201 202 203 204 205 205 206 208 213 215 217 218 222 224 227 227 229

18

3.2.1 Identidade . . . . . . . . . . 3.2.2 Privacidade . . . . . . . . . 3.2.3 Algoritmo de Popularidade 3.3 API . . . . . . . . . . . . . . 3.3.1 Autenticao . . . . . . . . 3.3.2 Estrutura . . . . . . . . . . . 3.3.3 Implementao . . . . . . . 3.4 BANCO DE DADOS . . . . . 3.4.1 Comparao . . . . . . . . . 3.4.1.1 MySQL . . . . . . . . . . . . 3.4.1.2 PostgreSQL . . . . . . . . . 3.4.1.3 Concluso . . . . . . . . . . 3.4.2 Modelo ER . . . . . . . . . . 3.5 IMPLANTAO . . . . . . . 3.6 APLICAO MVEL . . . . 3.7 UNINDO AS PARTES . . . . CONCLUSO . . . . . . . . . . . . . TRABALHOS FUTUROS . . . . . . . REFERNCIAS . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

229 230 231 233 233 237 240 242 242 244 245 248 251 256 261 270 272 274 276

INTRODUO

A Internet est em constante evoluo. Servios no so criados do nada, eles fazem parte de uma evoluo natural que busca suprir as necessidades de um determinado pblico. Atualmente, as redes sociais podem ser consideradas os servios mais populares da Internet. Elas tem foco na personalizao do contedo, atualizaes em tempo real e a extenso das redes sociais existentes no mundo real. At certo ponto, elas amplicaram os canais de comunicao entre as pessoas. E como a Internet est em constante evoluo, servios vo e vem, e no foi diferente com os fruns. Antes uma ferramenta popular para a criao de comunidades online, hoje eles esto relegados a nichos. Mas isso no signica que as pessoas que frequentam a Internet no esto mais interessadas em se engajarem em comunidades, de acordo com interesses e objetivos em comum. Partindo do princpio de que um dos fatores para a decadncia dos fruns foi a ausncia de evoluo tecnolgica, este trabalho descreve o desenvolvimento de um servio que busca unir algumas das funcionalidades encontradas nas redes sociais para criar um frum de acordo com a realidade atual mantendo as caractersticas bsicas que os zeram populares. No Captulo 1 esto descritas as motiviaes que levaro ao desenvolvimento deste projeto, bem como os objetivos que se buscaram alcanar com ele e que abor-

20

dagens foram utilizadas para se chegar ao resultado esperado. O Captulo 2 descreve cada um dos aspectos que precisou ser considerado na construo deste servio. Nele ser possvel compreender o que so redes sociais, que caractersticas e propsitos elas possuem e quais funcionalidades podem ser reaproveitadas em um frum. Este captulo ainda aborda a geolocalizao, funcionalidade que tambm foi empregada na construo deste servio, descrevendo como e quando utiliz-la. E por m, so detalhadas questes relacionadas com as tecnologias e conceitos de softwares que serviram de base para a escolha do software stack deste servio. O Captulo 3 exibe os resultados obtidos com este trabalho, detalhando as caractersticas do servio, os motivos por trs das decises tcnicas tomadas, e a apresentao da aplicao para dispositivos mveis. E por m, a Concluso d fechamento ao trabalho, inferindo sobre os objetivos buscados e os resultados de fato obtidos.

CAPTULO 1: 1.1 TEMA

ASPECTOS METODOLGICOS

Desenvolvimento de uma rede social baseada em geolocalizao para smart phones.

1.1.1 Delimitao do Tema

Criao de um novo servio, consistindo no desenvolvimento de rede social para smart phones baseada em geolocalizao, onde tudo que for relevante para a rede social est ligada de alguma forma uma posio geogrca, como pessoas, lugares, eventos, mensagens, fotos e vdeos. Este projeto foi desenvolvido no perodo compreendido entre o ms de novembro de 2011 a agosto de 2012 na Sociedade Educacional Trs de Maio (SETREM), no curso de Bacharelado de Sistemas de Informao.

1.2 PROBLEMA

Enquanto que redes sociais foram crescendo ao longo da ltima dcada, comeando com o Friendster e seguido pelo MySpace, at os tempos atuais, com o Facebook, outras ferramentas de comunicao, como os fruns, foram caindo no esquecimento, ao menos de grande parte da Internet. Fruns, entretanto, no deixaram de existir, na verdade, ainda existem alguns muito populares. Mesmo assim, de algum modo eles no foram capazes de se atualizarem em vista da evoluo que estava

22

ocorrendo em sua volta, ou mesmo pela inexistncia de um plano de monetizao eciente. As redes sociais se mostraram ferramentas de grande valor na comunicao entre pessoas, permitindo que uma pessoa se mantenha atualizada com relao aos acontecimentos que esto ocorrendo na vida de outras pessoas que ela conhece. As redes sociais representam uma evoluo para Internet, bem como uma mudana de foco para o indivduo, o que ele faz, o que ele gosta e o que as outras pessoas a sua volta acham disso. Muitos dos conceitos por de trs de alguns servios da Internet so proveniientes do mundo real. assim com sites de compra, de notcias, redes sociais e comunidades. No se tratam de servios inditos ou revolucionrios, mas de conceitos do mundo real aplicados a Internet, conceitos que funcionam no mundo real e que em muitos casos fazem parte da natureza humana. E isso no diferente com o conceito de comunidade. No mundo real existem muitas comunidades, elas agregam pessoas com algo em comum, seja a localizao geogrca, algum interesse, projeto ou objetivo. E este mesmo conceito foi aplicado com sucesso na Internet. Entretanto, os servios mais populares atualmente, as redes sociais, apesar de em alguns casos darem suporte a comunidades, tem seu foco nos indivduos, como fora colocado anteriormente. possvel ento, criar um servio cujo foco primrio seja a criao de comunidades?

1.3 JUSTIFICATIVA

Em vista da problemtica apresentada acima, este projeto procura desenvolver um servio que busca unir algumas das funcionalidades encontradas nas redes sociais para criar um frum que esteja mais alinhado as expectativas atuais das pessoas sem, entretanto perder o foco dos fruns, que a criao de comunidades e estmulo a discusso.

23

1.4 HIPTESES possvel criar um frum com caractersticas de uma rede social sem, entretanto, perder sua essncia. Atrelar uma posio geogrca a tudo que acontece e faz parte de uma rede social cria um diferencial com relao s redes sociais atuais. O protocolo OAuth permite a implementao de autenticao em um web service sem exceder o tempo alocado para a tarefa no cronograma.

1.5 OBJETIVOS

Nesta seo esto dispostos o objetivo geral deste projeto e os objetivos especcos a serem seguidos.

1.5.1 Objetivo Geral

Desenvolver uma rede social baseada em geolocalizao, com os servios sendo fornecidos por um web service RESTful e um client para smartphones consumindoos.

1.5.2 Objetivos Especcos Criar o plano de negcios para a rede social. Levantar as funcionalidades da rede social. Especicar as caractersticas de cada uma das funcionalidades. Desenvolver e testar cada uma das funcionalidades em forma de web service RESTful. Fazer deploy do web service desenvolvido em algum servidor na nuvem. Criar o nome e a identidade visual da rede social.

24

Criar os mockups do client para smartphone. Desenvolver e testar cada uma das funcionalidades no client para smartphone. Publicar o client para smartphone em uma loja de aplicativos. Iniciar a divulgao da rede social para o pblico. Documentar todas as etapas do projeto em forma de relatrio. Criar os slides para a apresentao do trabalho.

1.6 METODOLOGIA

A metodologia da pesquisa prov mtodos e tcnicas para a correta investigao do pensamento e desenvolvimento do problema em busca de solues (OLIVEIRA, 2002). Nas sees a seguir esto descritos os mtodos de abordagem e de procedimentos e as tcnicas utilizadas nesta pesquisa.

1.6.1 Mtodos de Abordagem

Este trabalho se caracteriza pela abordagem qualitativa por possuir hipteses que buscam validar caractersticas do software como um servio, tanto com relao ao web service como ao client para smartphone.

1.6.2 Mtodos de Procedimentos

Quanto aos procedimentos, o trabalho basicamente laboratorial por fazer uso de ferramentas e experimentos para a modelagem e desenvolvimento das aplicaes.

25

1.6.3 Tcnicas de Pesquisa

Com relao s tcnicas de pesquisa aplicadas neste trabalho, este fez uso da documentao indireta, atravs do levantamento de informaes sobre as redes sociais, pesquisando tanto em livros como analisando exemplos que representam o estado da arte no assunto.

1.7 ORAMENTO
Atividade Construo do server-side Construo do client Documentao Criao de artigos Criao de apresentaes Impresso do trabalho Total Qtde. 300 200 100 20 20 500 Valor Un. R$ 10.00 R$ 10.00 R$ 10.00 R$ 10.00 R$ 10.00 R$ 0.10 Valor Total R$ 3,000.00 R$ 2,000.00 R$ 1,000.00 R$ 200.00 R$ 200.00 R$ 50.00

R$ 6,450.00

Quadro 1.1: Cronograma das principais atividades do trabalho.

1.8 RECURSOS Notebook, smart phone Livros, artigos, softwares

1.9 CRONOGRAMA

O projeto segue o seguinte cronograma, tendo como incio o ms de novembro de 2011 e o seu trmino em agosto de 2012. A primeira linha indica os meses de durao do projeto e a primeira linha aponta cada uma das fases do trabalho. Quadros sombreados indicam o cronograma previsto, enquanto que quadros com um "x"indicam o cronograma realizado.

26

Atividade Anlise e Projeto do server-side Desenvolvimento do server-side Mock-ups do smartphone client para x x

2011 Nov Dez x x x x x x x x x x x x x x x Jan Fev Mar

2012 Abr Mai Jun Jul Ago

Criar o nome e logo do servio Desenvolvimento do client Publicar o client em loja de aplicativos Criar um plano de negcios Documentar as etapas do projeto Apresentao

x x

x x

x x

x x

x x x x x x x x

Quadro 1.2: Cronograma das principais atividades do trabalho.

CAPTULO 2:

FUNDAMENTAO TERICA

Neste captulo ser apresentada a fundamentao terica utilizada na construo deste servio, comeando pelos fundamentos que descrevem o funcionamento de redes sociais e comunidades na internet, passando pelo uso da geolocalizao e suas aplicaes prticas, terminando com o embasamento mais tcnico tanto com relao a construo da parte servidor do servio como da parte do cliente.

2.1 SOCIAL SOFTWARE

Social Software can be loosely dened as software which supports, extends, or derives added value from, human social behaviour - messageboards, musical taste-sharing, photo-sharing, instant messaging, mailing lists, social networking (COATES, 2005).

Farkas (2007) arma que social software uma ferramenta que deve permitir a comunicao entre pessoas, colaborao, e criao de comunidades online; syndication (contedo disponvel em diversos web sites), compartilhamento, reuso ou modicao de contedos; e permitir que as pessoas possam aprender e tirar proveito do comportamento e conhecimento de outras pessoas. Os principais exemplos de social software so: blogs, wikis, fruns, redes sociais, social bookmarking, sistemas de recomendao, instant messaging e podcasting. Para Farkas (2007), muito embora cada um destes exemplos tenham suas peculiaridades, eles tambm possuem algumas caractersticas em comum e que os diferenciam de outras tecnologias, sendo elas:

Facilidade de criao e compartilhamento de contedo: blogs e outros servios

28

de compartilhamento permitem que praticamente qualquer pessoa possa publicar contedo na internet. Colaborao online: muito alm do email, wikis permitiram que pessoas em qualquer lugar do mundo pudessem criar e editar contedo na Web. Possibilidade de conversar de forma distribuda e em tempo real: seja uma conversa atravs de instant messaging ou mesmo atravs de blogs ou redes sociais. Criao de comunidades que no existiam antes: e no apenas comunidades mais explcitas como as que se desenvolvem em fruns, bulletin boards ou mailing lists, mas tambm comunidades que se criam em torno de blogs, wikis e qualquer outro meio que permita a troca de ideias. Inteligncia coletiva: wikis so um exemplo claro, alm deste existem tambm os sites de recomendaes, onde usurios podem avaliar produtos e servios, bem como visualizar avaliaes de outros usurios. Transparncia: com a possibilidade de ter uma voz na Web e de poder dar a opinio, empresas e pessoas pblicas esto mais vulnerveis, no sentido de que se um produto de m qualidade ou uma pessoa praticou um ato ilegal, algum pode publicar na internet. E da mesma forma que Web pode tirar, ela tambm pode trazer fama. Personalizao: diferentemente do rdio, televiso ou jornal, com as mdias sociais o contedo personalizado de acordo com cada usurio. Portabilidade: possibilidade de acessar estes softwares atravs de vrios tipos de dispositivos.

No escopo deste trabalho, dois tipos de social software so relevantes: redes sociais e fruns. Nas prximas sees cada um deles ser discutido, desde suas caractersticas bsicas at caractersticas especcas de servios conhecidos. Posteriormente sero ainda abordadas questes relacionadas a identidade dos usurios, assuntos que abrangem tanto redes sociais como fruns, alm de vrios outros tipos de social software.

29

2.1.1 Redes Sociais

Redes sociais so servios baseados na Web que permitem que pessoas criem um perl pblico ou semi-pblico, possuam uma lista de usurios com os quais compartilham algum tipo de conexo e possam visualizar a lista de conexes de outros usurios (BOYD; ELLISON, 2007). Mayeld (2008) extende esta denio, armando que pessoas tambm compartilham contedo e se comunicam com suas conexes. Boyd e Ellison (2007) coloca ainda que o principal objetivo das redes sociais no est em conhecer pessoas, mas sim em trazer para o mundo online as redes sociais do mundo ofine. Isso no quer dizer, entretanto, que novas amizades no possam se formar atravs de servios de redes sociais, apesar de este no ser seu propsito. Por outro lado, Farkas (2007), apesar de tambm ver os softwares de redes sociais como um meio de mostrar publicamente a rede social de um indivduo, acredita que o objetivo deste tipo de software no abrange apenas o desenvolvimento de uma identidade online, mas tambm o de expandir esta rede, seja a negcios, namoro, ou para fazer novos amigos. O autor parte do princpio de que um indivduo est mais propcio a encontrar pessoas interessantes entre amigos de seus amigos. Independentemente das funcionalidades que uma rede social possa ter, todas elas tem como princpio um perl, ele o centro das redes sociais. atravs dele que um indivduo ir dizer quem ele , que pessoas ele conhece, o que ele faz e quais so seus interesses (FARKAS, 2007; BOYD; ELLISON, 2007). Com relao as funcionalidades que variam de acordo com a rede social, elas sero discutidas na prxima seo e logo aps, um histrico das redes sociais ao longo dos anos ser apresentado.

2.1.1.1 Caractersticas

Uma das caractersticas mais notveis em uma rede social o seu propsito, pois, apesar de grande parte das redes sociais compartilharem as mesmas caracters-

30

ticas fundamentais, elas podem ser utilizadas para propsitos diversos. Por exemplo, existem redes sociais para fazer novos amigos, para namoro ou para conhecer novos contatos para negcios. Alm da distino com relao aos interesses, algumas redes sociais tambm se concentram em faixas etrias especcas (FARKAS, 2007). Como fora descrito anteriormente, as funcionalidades que difenciam redes sociais de outros aplicativos so o perl de um indivduo e sua lista de conexes. Pers podem variar de aplicao para aplicao, mas basicamente ele o local onde o usurio colocar todas as suas informaes pessoais, fotos, interesses, contedo compartilhado e atividades recentes. Com relao a privacidade, ela tambm varia de acordo com a aplicao, algumas permitem que o usurio escolha quais informaes sero privadas e quais sero publicadas, alguns permitem ainda o renamento de que grupo de pessoas pode ver quais informaes do perl (FARKAS, 2007; BOYD; ELLISON, 2007; BELL, 2009). A lista de conexes de uma pessoa tambm varia, tanto com relao a sua denominao, como na forma como ela funciona, ou como Bell (2009) descreve, o modelo de relacionamento. O autor descreve trs modelos: adicionar e noticar ou modelo assimtrico; adicionar e conrmar; e adicionar, conrmar e adicionar de volta ou modelo simtrico. O mais popular dos trs modelos o assimtrico, principalmente por ser um modelo de fcil implementao e compreenso, ele utilizado pelo Flickr e Twitter, e quem adiciona uma pessoa normalmente conhecido por seguidor ou f. O segundo modelo, adicionar e conrmar, no muito popular, funciona de forma semelhante ao primeiro, exceto pelo fato de que a pessoa adicionada no apenas noticada, mas tambm precisa aceitar a adio. O terceiro modelo, simtrico, utilizado por redes sociais como Facebook e LinkedIn. Neste modelo quando uma pessoa adiciona outra pessoa, esta precisa fazer a conrmao, para que ento ambos estejam na lista de conexes um do outro. Neste modelo as conexes de uma pessoa so conhecidas como amigos ou contatos (BOYD; ELLISON, 2007; BELL, 2009). Dentro destes modelos seria possvel ainda criar grupos, permitindo que um

31

indivduo coloque suas conexes em grupos, de acordo com critrios que ache conveniente (BELL, 2009). Alguns apontam problemas com esse modelo de grupos de conexes, modelo utilizado pelo Google+, principalmente pelo trabalho que demandado para manter estes grupos, ou crculos, como conhecido na rede social do Google (SIEGLER, 2011a). O Facebook, por exemplo, j permitia que os usurios colocassem seus amigos em listas antes mesmo de o Google+ existir, mas a funcionalidade nunca foi muito utilizada. Hoje a funcionalidade funciona um pouco diferente, ela utiliza alguns critrios (e.g., localizao geogrca) para classicar os amigos de um usurio em listas automaticamente (Smart Lists) (KUMPARAK, 2011). Outro modelo de conexo, citado por Bell (2009), aquele onde o usurio pode escolher entre adicionar uma conexo como amigo ou apenas como um contato. O autor arma que este um modelo mais do que suciente para a grande maioria das situaes, onde amigos prximos so colocados como amigos e apenas conhecidos como contatos. A Figura 2.1 mostra as opes possveis para a visualizao de contedo de um usurio com base neste modelo de relacionamento de dois nveis (amigos e contatos). Algumas redes sociais permitem ainda que um indivduo compartilhe contedo tambm com amigos de amigos. E assim como na vida real, redes sociais precisam suportar tanto a criao como o trmino de relacionamentos entre pessoas. Redes sociais como Flickr permitem que um usurio bloqueie outro usurio, fazendo com que todos os comentrios da pessoa bloqueada sejam removidos das fotos do usurio que a bloqueou, alm de remover as fotos de quem bloqueou da lista de favoritos do bloqueado. Motivos para bloquear um usurio so dos mais diversos, sendo o spam provavelmente um dos mais comuns (BELL, 2009). Outra funcionalidade que grande parte das redes sociais possui so as mensagens privadas ou pblicas direcionadas para um usurio em especco. Este servio pode ser ainda chamado de comentrios ou funcionar de forma muito semelhante a um e-mail interno. O Facebook, por exemplo, permite o envio de mensagens privadas para qualquer usurio (desde que este no tenha bloqueado o usurio que ir enviar a mensangem), e dentro do mesmo sistema so gravadas todas as conversas feitas

32

Fonte: Bell (2009, p. 251)

Figura 2.1: Visibilidade de contedo com base em um relacionamento de dois nveis.

pelo sistema de instant messaging, este disponvel apenas para amigos (FACEBOOK, 2012a; CHILDNET INTERNATIONAL, 2008). Oposto s mensagens privadas esto os grupos, estes permitindo que pessoas criem e participem de grupos de acordo com interesses especcos. Estes grupos funcionam de forma muito semelhante a fruns, onde usurios podem iniciar tpicos ou participar de outros existentes (FARKAS, 2007). Este tipo de social software ser abordado em detalhes na seo 2.1.2. Talvez um dos aspectos mais importantes de uma rede social sejam os objetos sociais (social objects), aqueles que fazem a mediao das atividades sociais. Objetos sociais esto ligados diretamente a uma pessoa ou aos seus interesses pessoais. Quando existe tal relacionamento entre a pessoa e seus objetos, ela estar mais propcia a cuidar deles e se importar com eles, aumentando a chance de o usurio retornar a rede social. Grande parte das interaes em redes sociais se d atravs dos objetos sociais compartilhados nela (BELL, 2009; PORTER, 2008). Exemplos de objetos sociais em aplicaes web podem ser vistos na Figura 2.2. Estes so exemplos de aplicaes que fazem (ou zeram) sucesso na Web, e como Porter (2008) mesmo coloca, todas as interaes nestes sites ocorre em torno destes objetos, e isso mostra a importncia que eles tem. Portanto, descobrir e modelar os objetos sociais de uma rede social so atividades muito importantes no projeto de uma aplicao social.

33

Fonte: Porter (2008, p. 32)

Figura 2.2: Exemplos de objetos sociais. Porter (2008) ainda comenta a respeito das funcionalidades principais de uma aplicao social (as core features), armando que as aes que um usurio pode realizar sobre os objetos sociais so candidatos em potencial. Geralmente o que se cria uma associao entre os objetos e seus verbos, como por exemplo:

Videos: tocar, parar, editar, armazenar, fazer upload, compartilhar, comentar. Artigos: ler, arquivar, citar, referenciar, compartilhar, comentar. Fotos: armazenar, ver, adicionar aos favoritos, editar, referenciar, imprimir, compartilhar, comentar. Livros: ler, adicionar ao carrinho de compras, comprar, compartilhar, adicionar a lista de presentes, comentar, avaliar, discutir, dar nota.

Cada rede social ou aplicao social possui seus objetos sociais e seu conjunto de verbos e funcionalidades, nas prximas sees ser apresentada uma histria breve das redes sociais e em sequncia a descrio detalhada de algumas das principais redes sociais e suas funcionalidades.

2.1.1.2 Histria

Segundo Boyd e Ellison (2007), o primeiro servio que pode ser chamado de rede social o SixDegrees.com, lanado em 1997. Apesar de outros servios j apresentarem as ideias de o usurio possuir um perl e uma lista de amigos, como nos

34

instant messengers AIM e ICQ, foi apenas com o SixDegrees que essa lista de amigos era visvel para outras pessoas. O servio chegou a atingir 1 milho de usurios (MORRISON & FOERSTER, 2011), mas no ano 2000 teve de ser fechado por no ter conseguido se tornar um negcio sustentvel. De 1997 a 2001, vrias comunidades implementaram o conjunto perl e lista pblica de amigos, como o AsianAvenue, BlackPlanet e MiGente, mas sem nenhuma inovao em comparao com o SixDegrees. Em 1999 o LiveJournal foi criado, e diferentemente de outras redes sociais, neste as conexes eram em apenas uma direo (assimtricas), e estas conexes eram utilizadas para seguir as atualizaes em blogs dos usurios (CHAPMAN, 2009; BOYD; ELLISON, 2007). Neste mesmo perodo, outros servios comearam a adicionar funcionalidades de redes sociais, como o koreano Cyworld em 2001 e o LunarStorm em 2000. No incio da dcada de 2000, segundo Chapman (2009), grandes mudanas aconteceram com o lanamento de novas redes sociais. Boyd e Ellison (2007) arma que esta nova onda de redes sociais teve incio com o lanamento da Ryze.com, uma rede social para negcios. Entretanto, ela nunca chegou a atingir grande popularidade. Em 2002 nascia o Friendster, este que pode ser reconhecido como a primeira rede social para o pblico em geral (CHAPMAN, 2009). Seu principal propsito era o de encontrar amigos e amigos de amigos, ele fora criado para competir como o site Match.com, s que diferentemente da maioria dos sites de namoro, o Friendster partia do princpio de que uma pessoa teria mais chances de encontrar um parceiro entre amigos de amigos do que entre estranhos (CHAPMAN, 2009; BOYD; ELLISON, 2007). O servio sofreu vrias diculdades tcnicas, alm de problemas sociais e perda da conana por parte dos usurios, motivos que levaram a sua decadncia nos EUA, o que no os impediu, entretanto, de fazer sucesso na Asia (BOYD; ELLISON, 2007). A partir de 2003 as redes sociais haviam atingido grande popularidade, tendo vrios servios lanados naquele ano e nos anos seguintes, muitos deles procurando o sucesso seguindo os passos do precursos Friendster e outros buscando nichos de mercado. Focado em relacionamentos prossionais estavam LinkedIn, Vsible Path e

35

Fonte: Boyd e Ellison (2007, p. 6)

Figura 2.3: Linha do tempo de lanamento das redes sociais.

36

Xing. Haviam ainda redes sociais como Dogster, para donos de cachorros; Care2 para conectar ativistas ao redor do mundo; MyChurch para igrejas crists e seus membros (BOYD; ELLISON, 2007). Outras redes sociais que obtiveram grande sucesso foram aquelas focadas em contedo gerado pelos usurios (user-generated content) como Flickr (para compartilhamento de fotograas), last.fm (para hbitos musicais) e o YouTube (para compartilhamento de vdeo) (BOYD; ELLISON, 2007). Com o declnio do Friendster, Tom Anderson criou em 2003 o MySpace na tentativa de atrair usurios descontentes com o servio, incluindo bandas de indierock que no estavam de acordo com os regulamentos do Friendster. Com o xodo de usurios do Friendster para outras redes sociais, como, principalmente, o MySpace, este conseguiu crescer rapidamente. O servio tambm se diferenciou por adicionar funcionalidades de acordo com a demanda dos usurios, alm de permitir que estes personalizassem seus pers (BOYD; ELLISON, 2007). Outras redes sociais como Orkut e Microsoft Live Spaces no obtiveram o mesmo sucesso com o pblico dos EUA, entretanto, foram capazes de crescer em mercados estrangeiros como o caso do Orkut, que obteve grande sucesso no Brasil e India (BOYD; ELLISON, 2007). Outra rede social que teve sucesso foi o Hi5, alcanando 60 milhes de usurios principalmente na Asia, Amrica Latina e frica Central (CHAPMAN, 2009). Em 2004 era criado o Facebook, servio que iniciou como uma rede social apenas para estudantes de Harvard e se expandiu rapidamente para outras universidades, escolas, empresas e nalmente em 2006 para todo o mundo. Um ano depois do lanamento do Facebook, o MySpace vendido para a News Corp por US$580 milhes e em 2006 o Facebook recusa uma oferta de compra por parte do Yahoo! por US$1 milho (CHAPMAN, 2009; MORRISON & FOERSTER, 2011). Dois anos depois e o Facebook ultrapassa o MySpace em popularidade baseado em visitas nicas por ms, se tornando a rede social mais popular do mundo.

37

Neste mesmo ano nasce o servio de microblogging chamado Twitter. A partir da o Facebook continua seguindo sua escalada em nmero de usurios, com mais de 350 milhes em Dezembro de 2009, 400 milhes em Fevereiro de 2010 e meio bilho de usurios cinco meses depois (MORRISON & FOERSTER, 2011). Atualmente o Facebook arma ter mais 800 milhes de usurios, sendo que 80% deles vivem fora dos EUA e 350 milhes acessam a rede social atravs de dispositivos mveis (FACEBOOK, 2012b). 2011 foi o ano em que a News Corp vendeu o MySpace por mais ou menos 6% do seu valor de compra ou US$35 milhes. Neste mesmo ano o Google lana a sua rede social, o Google+, e em menos de duas semanas ela j conta com mais de 10 milhes de usurios (MORRISON & FOERSTER, 2011). O Facebook recentemente teve o seu IPO (Initial Public Offering), sendo avaliado em mais de US$100 bilhes (GHOSH, 2012). Ainda em 2011, o Twitter celebrou seus cinco anos, ultrapassando os 200 milhes de tweets por dia em Junho e tendo mais de 100 milhes de usurios ativos ao redor do mundo (PARR, 2011). Ao longo dos anos muitos servios foram surgindo enquanto que outros foram caindo no esquecimento ou sobrevivendo atravs de nichos de mercado. Nas prximas sees sero apresentados em maiores detalhes os servios de redes sociais mais populares ou que mais ateno vem ganhando atualmente.

2.1.1.3 Facebook

O Facebook uma rede social fundada por Mark Zuckerberg em Fevereiro de 2004. Como mencionado anteriormente, inicialmente o servio estava disponvel apenas para estudantes de Harvard, posteriormente sendo expandido para outras universidades, em Setembro de 2005 para escolas e nalmente em 2006 para o pblico em geral (CRUNCHBASE, 2011a). O principal objetivo da rede social ajudar pessoas a se comunicarem de

38

forma mais efetiva com seus amigos, famlia e colegas de trabalho atravs de tecnologias que facilitam o compartilhamento de informaes atravs do grafo social (social graph), que o mapeamento digital das conexes sociais da vida real (FACEBOOK, 2012c). As principais funcionalidades da rede social so a Home page do usurio e o seu perl. na Home page que o usurio visualiza as suas atualizaes e de seus amigos, enquanto que no perl vo suas informaes pessoais, prossionais e de contato, e seus interesses. Alm da Home page e do perl, o servio tem as funcionalidades dde Fotos, Eventos, Videos, Grupos, Pginas, Chat, Mensagens pessoais, Wall posts, Pokes e Status updates (FACEBOOK, 2012c).

Figura 2.4: Home page do Facebook. A Figura 2.4 mostra a pgina principal do servio, aquela que todos usurios primeiro enxergam quando fazem login. A partir dela possvel visualizar atualizaes tanto de amigos como de pginas que a pessoa curtiu. O News Feed tambm permite que o usurio poste algum status, podendo este ser um texto, um link para outro site,

39

uma foto ou vdeo ou alguma questo para ser respondida pelos amigos. O usurio pode ainda curtir itens do News Feed, deixar um comentrio ou compartilhar com o seu social graph (FACEBOOK, 2012c). Em dezembro de 2011 o Facebook tornou disponvel para todos os seus usurios o Timeline, que um novo tipo de perl para os usurios. Basicamente ela uma linha tempo que permite que os usurios visualizem todas as atividades realizadas na rede social em ordem cronolgica, respeitando as conguraes de privacidade, claro (MCDONALD, 2011).

Fonte: McDonald (2011)

Figura 2.5: Timeline do Facebook.

Muito mais do que uma rede social, o Facebook tambm possui uma plataforma para desenvolvimento de aplicativos que tiram vantagem do grande nmero de usurios do servio. Atravs desta plataforma possvel adicionar funcionalidades sociais a websites, como o boto Curtir ou o login com uma conta do Facebook. Existem tambm ferramentas para aplicativos mveis, tanto para iOS, Android como para Mobile Web. H ainda a possibilidade de desenvolver aplicativos integrados com o Facebook, ou utilizar vrias outras ferramentas, como SDKs e APIs, para o desenvolvimento de aplicaes integradas ao Facebook Platform (FACEBOOK, 2012d).

40

Fonte: Android Market (2012a)

Figura 2.6: Aplicativo do Facebook para Android. Com relao ao modelo de relacionamento da rede social, ele simtrico, pois quando uma pessoa adiciona outra como amigo, esta precisa aceitar a adio, para que ento ambas sejam amigas. Em Setembro de 2011 o Facebook tambm passou a suportar uma espcie de relacionamento assimtrico, onde uma pessoa assina (Subscribe) os News Feed de outra pessoa, sem que estas precisem ser necessariamente amigas (RAIT, 2011). O Facebook tambm possui funcionalidades ligadas a geolocalizao, como a possibilidade de informar a localizao em um post ou em uma foto e encontrar e fazer check-in em lugares atravs do Places (FACEBOOK, 2012e). Com relao aos aplicativo mveis, o Facebook d suporte a uma grande quantidade de plataformas e dispositivos. Existem aplicativos para iPhone, iPad, An-

41

droid, Palm, BlackBerry e qualquer outro telefone atravs da plataforma Java ME (Micro Edition) ou atravs da verso Web Mobile (m.facebook.com) (FACEBOOK, 2012f). O Facebook tambm possui um aplicativo chamado Messenger, ele uma forma mais rpida para o envio de mensagens e recebimento de mensagens de amigos e est disponvel para Android, iPhone e BlackBerry (ANDROID MARKET, 2012b). Atualmente o Facebook a maior rede social do mundo, com mais de 800 milhes de usurios, atraindo todas as faixas etrias. Para se ter uma ideia do tamanho do Facebook, dos adultos nos EUA que usam redes sociais, 96% deles esto no Facebook. Depois do Facebook, as outras duas maiores redes sociais so LinkedIn e Twitter, respectivamente. Ambas sero abordadas nas sees que vem a seguir (BANKS, 2011; FACEBOOK, 2012b).

2.1.1.4 LinkedIn

O LinkedIn uma rede social voltada para negcios. Nela usurios podem criar um perl prossional e manter uma lista de contatos prossionais (Connections). Atravs do servio usurios podem procurar empregos, oportunidades de negcio, e pessoas. Ele tambm muito til para empresas que procuram maiores informaes sobre prossionais, bem como trabalhadores procurando informaes sobre empregadores. Apesar de ser um servio grtis, ele fornece algumas funcionalidades extras, como ferramentas para encontrar pessoas e o LinkedIn Answers, atravs de contas pagas (CRUNCHBASE, 2012b). Atravs do perl, um usurio pode informar alm de dados bsicos, suas experincias, educao e recomendaes feitas por outras pessoas. O servio fornece ainda funcionalidades como grupos de discusses, rea de empregos tanto para quem est a procura como para empregadores, pginas para empresas, questes para serem respondidas por prossionais da rea, alm de notcias lidas que esto sendo lidas e compartilhadas por outros prossionais. O servio ainda fornece aplicaes de terceiros para incrementar as funcionalidades do perl (LINKEDIN, 2012a). O LinkedIn possui ainda aplicativos para dispositivos mveis, dando suporte

42

para BlackBerry, iPhone, Palm Pre, Android e tambm atravs da verso Web Mobile (LINKEDIN, 2012b).

Fonte: LinkedIn (2012c).

Figura 2.7: Home page do LinkedIn.

Atualmente o servio possui mais de 100 milhes de usurios em mais de 200 pases, em 2011 ela abriu seu capital para o pblico (IPO) e atualmente est avaliada em US$9.31 bilhes (CRUNCHBASE, 2012b). Nos EUA o LinkedIn a terceira maior rede social com relao a visitas nicas (LIPSMAN, 2011).

2.1.1.5 Twitter

O Twitter um servio de redes sociais e microblogging que permite aos usurios postarem atualizaes, fundado em Maro de 2006 por Jack Dorsey, Biz Stone e Evan Williams (CRUNCHBASE, 2012c). O servio se auto descreve atualmente como uma rede de informaes em tempo real, essas informaes existem atravs de tweets, que so mensagens limitadas a 140 caracteres (TWITTER, 2012a).

43

Esta rede social segue o modelo assncrono de relacionamento, desta forma um usurio possui seguidores (Followers) e ele tambm segue outras pessoas (Following). Quando um usurio segue outra pessoa ele tambm passa a receber as mensagens desta pessoa. O Twitter tambm possui algumas funcionalidades que foram se tornando ociais como o retweet (ou RT), onde um usurio repassa a mensagem de uma pessoa para a sua rede de seguidores. Para referenciar uma pessoa da rede social em uma mensagem o usurio utiliza o @ seguido do nome de usurio que ser referenciado (e.g., @mayconbordin). Outra prtica comum criada pela comunidade e posteriormente adotada ocialmente a hashtag, simbolizada por #, que serve para marcar palavras-chave em um tweet (KWAK; LEE; PARK; MOON, 2010; TWITTER, 2012b).

Figura 2.8: Home page do Twitter.

A pgina principal do Twitter, assim como a maioria dos aplicativos sociais, pode ser chamada de pgina de atividades, pois mostra os ltimos tweets das pes-

44

soas que um usurio est seguindo (BELL, 2009). Um tweet, alm de poder ser retuitado, pode ser respondido (Reply ), o que tem a mesma funcionalidade que o @ para referenciar outras pessoas e ele tambm pode ser favoritado (KWAK; LEE; PARK; MOON, 2010). Originalmente, tweets continham apenas texto e URLs para compartilhar contedo atravs da rede, e isto, aliado ao limite de 140 caracteres proliferou o uso de encurtadores de URLs, como bit.ly e Tiny URL (ROWINSKI, 2011). Atualmente o Twitter encurta as URLs automaticamente com seu prprio encurtador (t.co), e alm disso o servio tambm d suporte para vrios tipos de mdia, como imagens, vdeos, mapas, alm de permitir que o usurio d sua localizao geogrca ao enviar um tweet (ROWINSKI, 2011; TWITTER, 2012b). Com relao a imagens, o servio tambm d suporte para upload delas atravs de uma parceria feita com o Photobucket. Existem ainda servios de terceiros que forneciam e ainda fornecem funcionalidades como imagens ao Twitter, como o caso do Twitpic (PANZARINO, 2011). Todo e qualquer usurio do servio possui um perl, este perl ser acessado atravs do seu nome de usurio. Alm do nome de usurio, possvel informar um nome (o nome real, por exemplo, mas no necessariamente) e uma imagem. O perl exibe os tweets do usurio, no caso de o usurio possuir um perl pblico, caso contrrio, apenas pessoas aprovadas pelo usurio poderam ver seus tweets. Alm disto, o perl exibe quem segue o usurio e quem este est seguindo, tweets favoritados e as listas. Estas so listas onde o usurio pode agrupar pessoas que segue, da forma que achar mais conveniente (TWITTER, 2012b). Por ser uma rede de informaes em tempo real, uma das funcionalidades mais interessantes do servio o Trending Topics (ou Assuntos do Momento) que mostra os assuntos mais comentados na rede social no exato momento. A lista de assuntos mais falados pode ser ainda ltrada por localizao (pases e cidades), e ao clicar em um assunto o usurio pode ver os ltimos tweets a respeito do mesmo (TWITTER, 2012b). Para Bell (2009), um dos fatores que levou ao crescimento do Twitter foi o uso

45

da API dos servio por vrios clientes. E isso se mostra verdadeiro atravs das informaes de trfego do Twitter em Maro de 2009, quando 10-20% dele era proveniente do site do Twitter e todo o resto de clientes utilizando a API.

Fonte: iTunes App Store (2012a).

Figura 2.9: Aplicativo do Twitter para iPhone. Com relao aos clientes fornecidos pelo prprio servio, h suporte para iOS, Android, Windows Phone 7, Google TV, alm da verso Web Mobile e a possibilidade de enviar tweets por SMS. E alm das aplicaes ociais do Twitter, existem vrias aplicaes de terceiros que fazem uso da API do servio, como Seesmic, Twitpic, Twitterric, Bubbletweet e Twitwipe (TWITTER, 2012c). O modelo de negcio do Twitter baseado em publicidade atravs de tweets, contas e trending topics promovidos. Jack Dorsey arma que o envolvimento dos usurios com relao aos produtos promovidos est entre 1% e 5% (WAUTERS, 2012). Atualmente, alm de ter mais de 200 milhes de tweets por dia e mais de

46

100 milhes de usurios, como fora comentado anteriormente, o Twitter tem obtido uma mdia de 460 mil novas contas por dia, segundo dados de Fevereiro de 2011 e o servio viu um aumento de 182% dos usurios mveis de 2010 para 2011 (TWITTER, 2011a). O servio tem ainda mais de 1 milho de aplicativos registrados e avaliado atualmente em US$8 bilhes (RUSHE, 2011).

2.1.1.6 Instagram

O Instagram um aplicativo para compartilhamento de fotos para iPhone, iPad e iPod Touch, desenvolvido por Kevin Systrom e Mike Krieger. Com o aplicativo, os usurios podem tirar fotos, aplicar ltros nas fotos e compartilh-las no prprio servio ou em outras redes sociais, como Facebook, Twitter, Foursquare, Tumblr, Flickr e Posterous (CRUNCHBASE, 2012d). Assim como no Twitter, o relacionamento entre usurios assimtrico, portanto, usurios tem seguidores e seguem outras pessoas. O perl do usurio no aplicativo simples, h o nome de usurio, nome, uma pequena descrio e uma URL para outro site do usurio (INSTAGRAM, 2012). Toda a interao desta rede social gira em torno das fotos, pessoas podem deixar comentrios nas fotos e assim como no Twitter, existem as convenes de @ e # para mencionar um usurio e sinalizar uma palavra-chave, respectivamente. Usurios tambm podem curtir (like) uma foto (INSTAGRAM, 2012). O aplicativo possui cinco sees ou telas importantes. A primeira delas j foi descrita anteriormente, o perl do usurio, que alm de mostrar suas informaes, tambm exibe as ltimas fotos publicadas. Quando um usurio segue outras pessoas, ele passa a receber as fotos que estas pessoas publicam, e isso ca disposto na tela Feed, em ordem cronolgica, como na maioria das aplicaes sociais, entretanto, o usurio s visualiza uma foto de cada vez, ao invs de uma lista de fotos (INSTAGRAM, 2012). Quando algum curte uma foto de um usurio ou faz um comentrio nela,

47

este usurio ir receber uma noticao atravs do Push Notication Service do iOS e estas noticaes tambm estaro dispostas na seo News do aplicativo. Outros eventos que geram noticaes so menes ao usurio em um comentrio e quando a foto do usurio aparece na pgina Popular do aplicativo. Esta pgina por sua vez mostra as fotos mais interessantes adicionadas recentemente, baseado em diversas variveis que no so divulgadas, provavelmente para evitar que pessoas tentem enganar o algoritmo (INSTAGRAM, 2012).

Fonte: iTunes App Store (2012b).

Figura 2.10: Aplicativo do Instagram para iPhone. O aplicativo foi lanado na Apple App Store em 6 de Outubro de 2010, em Dezembro do mesmo ano o aplicativo tinha 1 milho de usurios registrados, em Junho de 2011 5 milhes, em Setembro mais de 10 milhes de usurios e em Outubro 12 milhes. At Julho de 2011 mais de 100 milhes de fotos haviam sido compartilhadas pelo servio, marco que levara 2 anos para ser atingido pelo Flickr e o Instagram alcanara em menos de um ano e em apenas uma plataforma (VITICCI, 2011; SIEGLER, 2011b; TSOTSIS, 2011a). Para Stratmann (2011) as razes para o sucesso do aplicativo giram em torno da integrao simples com outras redes sociais, a prpria simplicidade do aplicativo, o apelo esttico que as fotos ganham com os ltros e tambm por causa da sua API que permite que vrias aplicaes sejam criadas em volta deste servio. Bolt (2011) tambm atribui o successo do aplicativo ao seu apelo visual, que, atravs dos ltros e

48

da qualidade da cmera do iPhone, proporcionam fotograas que fazem os usurios sentirem que h algum mrito artistco nelas, em outras palavras, muito mais do que um simples aplicativo para compartilhar fotos. O mais interessante sobre o aplicativo que ele era chamado originalmente de Burbn e era na verdade uma aplicao em HTML5 para check-ins, algo bem semelhante ao Foursquare. Mas, segundo Kevin Systrom, o aplicativo no trazia nada de novo para o mercado, foi ento que eles (Kevin e os outros integrantes da equipe) decidiram que deveria escolher apenas uma das funcionalidades principais do aplicativo e focar o desenvolvimento nela (SAWERS, 2011). Eles escolheram o compartilhamento de fotos e, ao invs de criarem solues, eles se perguntaram quais eram os problemas com os aplicativos j existentes no mercado. Foi ento que eles chegaram a trs problemas fundamentais e suas respectivas solues: as fotos tiradas por celulares eram feias, ltros foram a soluo, e apesar de j existirem aplicativos com esta funcionalidade, eles custavam caro e/ou eram ruins; o upload das fotos demorava muito tempo, eles resolveram isso otimizando as fotos para o iPhone 4; e o compartilhamento de fotos geralmente limitava o usurio a compartilhar em um canal (como uma rede social) por vez, eles resolveram este problema permitindo que o usurio escolhesse os canais pelos quais gostaria de compartilhar as fotos. Segundo Kevin, portanto, o levantamento destes principais problemas possibilitou-lhes ter o foco naquilo que realmente interessava e consequentemente criar um aplicativo de sucesso (SAWERS, 2011).

2.1.1.7 Pinterest

O Pinterest se auto descreve como um pinboard (semelhante a um quadro de avisos ou notcias) virtual (PINTEREST, 2012a). O CrunchBase (2012e) descreve o servio como uma rede social que, como a descrio anterior mesmo sugere, simula a interface de um pinboard. Partindo deste princpio, cada usurio possui o seu prprio pinboard e pode colocar nele fotos ou links de coisas que gosta, alm de poder seguir o pinboard de pessoas que acha interessante.

49

O servio possui dois conceitos bsicos que so: pin e board. Pin uma imagem adicionada ao Pinterest, ele pode ser adicionado de um site atravs do boto Pin It ou fazendo o upload de uma imagem. J um board um conjunto de pins e pode representar um tpico especco, como Receitas para o Jantar ou Lista de Desejos. Boards tem um ttulo e uma categoria e podem ser criados enquanto se est criando um pin (pinning) (PINTEREST, 2012a). Assim como o Instagram e o Twitter, o Pinterest tambm segue o modelo de relacionamentos assncrono, possibilitando a um usurio seguir e ser seguido por outros usurios (sem necessidade de reciprocidade). Entretanto, existe uma peculiaridade com relao a opo de seguir uma pessoa, pois um usurio pode tanto seguir tudo (Following All) ou seguir apenas boards especcos de um usurio. O Pinterest ainda segue a prtica de no trazer ms notcias aos usurios, ou seja, se algum deixar de seguir um usurio, este no ser noticado (PINTEREST, 2012a).

Fonte: iTunes App Store (2012c).

Figura 2.11: Aplicativo do Pinterest para iPhone. Seguindo ainda algumas caractersticas do Twitter (no necessariamente como pioneiro, mas certamente o mais conhecido), um usurio que est navegando pelo servio e encontra um pin que lhe agrade pode dar um repin, que funciona de forma bem semelhante ao retweet, para que o pin aparea em seu prprio board, mantendo os crditos originais. Ou se o usurio preferir, ele pode curtir o pin, e neste caso o pin ir aparecer na seo Likes do perl do usurio (PINTEREST, 2012a).

50

Ao criar um pin, o usurio pode ainda adicionar uma descrio a ele e depois de publicado, usurios podem ainda deixar comentrios no pin. Tanto na descrio como nos comentrios possvel fazer menes a outros usurios do servio, da mesma forma como feito no Twitter e Instagram, utilizando o @ seguido do nome do usurio (PINTEREST, 2012a). Atualmente o servio est disponvel apenas atravs de convites e pode ser acessado atravs da web ou do aplicativo para iPhone. Com este ltimo, alm das funcionalidades descritas acima, possvel criar um pin com a cmera do celular e ainda adicionar a localizao para que outras pessoas (chamados de pinners) possam visitar. O servio oferece ainda o boto "Pin It"para criar pins de websites de duas formas: na primeira o usurio adiciona o boto na barra de favoritos do Google Chrome e ento pode criar pins quando estiver visitando o site; e na outra forma, o prprio site disponibiliza o boto para o usurio, de forma semelhante a do boto Like do Facebook e Tweet do Twitter (PINTEREST, 2012b). Em Dezembro de 2011 o servio tinha atrado mais de 11 milhes de visitantes em uma semana, e estava entre as top 10 redes sociais monitoradas pleo Hitwise, e a comScore faz uma estimativa de 3.3 e 4.9 milhes de visitas nicas em Outubro e Novembro de 2011, respectivamente (SCHONFELD, 2011).

2.1.1.8 Path

O Path um aplicativo que funciona como um dirio que permite o compartilhamento de momentos da vida de uma pessoa com amigos prximos e a famlia. Path foi fundado por Dave Morin, Shawn Fanning e Dustin Mierau em 2010 e fora concebido originalmente para ser um aplicativo para compartilhamento de fotos apenas, mas depois de escutar o feedback dos usurios o aplicativo foi relanado em Novembro de 2011, permitindo agora que os usurios compartilhem, alm de fotos, lugares, msicas, chat, e modo dormindo (sleep mode) (CRUNCHBASE, 2012f; TSOTSIS, 2011b; PATH, 2012). Assim como todos os outros aplicativos aqui expostos, o Path tambm possui

51

Fonte: iTunes App Store (2012d).

Figura 2.12: Aplicativo do Path para iPhone.

uma seo de feeds (Home), onde as atualizaes de outras pessoas so exibidas em ordem cronolgica e outra de atividades, que funciona como uma rea de noticaes, dando feedback para momentos e comentrios do usurio. Com o Chooser o usurio pode postar fotos, vdeos, com quem est, onde est, o que est ouvindo ou pensando e quando vai dormir e acorda. Com relao ao compartilhamento de fotos, o aplicativo permite ainda a aplicao de ltros nas fotograas, funcionalidade existente na primeira verso do aplicativo (PATH, 2012). Como se pode notar, o objeto social principal deste aplicativo so os momentos, estes podendo ser representados de diversas formas. As interaes se do em volta deste objeto, e podem se manifestar atravs de comentrios ou emoes. Com relao a privicidade, todos os momentos criados no aplicativo so privados por padro e as conguraes permitem que o usurio escolha quem pode ver o qu (PATH, 2012). O aplicativo est disponvel para iPhone e Android. Em Janeiro de 2012 o aplicativo tinha por volta de 2 milhes de usurios e no comeo de 2011 havia recusado uma proposta de compra do Google por mais de US$100 milhes (PATH, 2012; CRUNCHBASE, 2012f).

52

2.1.2 Fruns

Frum, message board ou bulletin board um site para discusses online, que pode conter categorias de discusses, cada uma com threads (conversas em um tpico) e posts individuais (respostas ao tpico) (VBULLETIN, 2012). Segundo Farkas (2007), frums podem ser utilizados para a criao de comunidades online, que de acordo com Wu (2010) reunem pessoas que possuem um interesse em comum, seja este um hobby, um objetivo, projeto, estilo de vida ou localizao geogrca. Assim como redes sociais e outros social softwares, fruns geralmente permitem que usurios possuam um perl. As informaes permitidas podem variar, entretanto, e apesar de no haver nenhuma limitao tcnica, o perl costuma ser bsico (BELL, 2009). Alguns fruns possuem, alm dos usurios regulares, moderadores, que so pessoas responsveis por mediar discusses, em alguns casos modicando ou removendo conversas ou banindo usurios, alm de remover spams e spambots; e administradores, que cuidam da parte tcnica do frum (VBULLETIN, 2012). Tpicos podem ter um dos trs formatos conhecidos para exibio de conversas: non-threaded, semi-threaded ou fully-threaded. A Figura 2.13 mostra uma comparao entre estes trs formatos, onde o primeiro (non-threaded) utilizado principalmente para fazer anncios e assuntos similares onde no h a necessidade de gerar discusses, enquanto que os outros dois formatos so especcos para discusses, pois permitem que usurios respondam a um tpico. A diferena que no semi-threaded usurios podem responder apenas ao tpico original (OP ou original poster ), enquanto que no fully-threaded usurios podem responder a respostas (BULLETINBOARDS, 2012). Para Heffernan (2011), os fruns no so mais como antigamente. No no sentido de que eles deixaram de cumprir seus propsitos ou se desviaram dos mes-

53

Fonte: BulletinBoards (2012).

Figura 2.13: Comparao entre fruns non-threaded, semi-threaded e fully-threaded.

mos, mas por que a Internet evolura, e as redes sociais passaram a ser mainstream e os fruns, antes visitados por muitas pessoas, hoje lutam para sobreviver. No se deve, entretanto, colocar todos os fruns na mesma situao, pois ainda existem fruns populares.

2.1.3 Identidade

Segundo Bell (2009), so trs os modelos mais comuns para criao de uma conta: registro atravs de um endereo de e-mail, utilizar outro site para provr identidade (e.g., Twitter ou Facebook), ou utilizar o OpenID. O mais popular de todos o conjunto e-mail e senha, onde o usurio faz o seu

54

cadastro utilizando o e-mail para conrmar a sua identidade, geralmente recebendo um e-mail com um link para conrm-la. Entre as disvantagens desta soluo est a necessidade de o usurio memorizar mais uma senha. Ao servio onde o usurio ir se cadastrar cabe a tarefa de vericar se a senha segura o suciente sem, entretanto, tornar a tarefa de cadastro muito encmoda ao usurio. Xkcd (2011) j abordou a questo da fora de senhas, armando que existem outros fatores que precisam ser levados em conta, como o nmero de caracteres. Algo que tambm foi abordado por Atwood (2005), armando que em muitos casos utilizar frases como senha, alm de serem mais fceis de serem lembradas, podem ser muito mais seguras do que palavras curtas que contenham smbolos e nmeros. Wheeler (2012) descreve uma soluo em JavaScript para calcular a entropia de senhas e dar estimativas mais reais sobre sua fora. Bell (2009) ainda lembra que sistemas de login precisam se proteger contra ataques de fora bruta, bloqueado, por exemplo, usurios que tentem acessar suas contas muitas vezes sem sucesso, comportamento que pode indicar que eles no so usurios legtimos. Alm disso, preciso tomar cuidado com relao a como as senhas dos usurios so armazenadas no servidor. Obviamente, armazen-las em texto puro est fora de questo, mas a verdade que at mesmo as prticas largamente difundidas, geralmente no so sucientes, como o armazenamento de hashes das senhas utilizando algoritmos como MD5, SHA1, SHA256. Hale (2010) arma que estes algoritmos de hash, por melhores que sejam na garantia da integridade dos dados (nmero de colises), eles so muito rpidos, e em consequncia inadequados para o armazenamento de senhas. E nem mesmo o uso de salts pode garantir a segurana de um sistema, pois mesmo com o uso de salts, os algoritmos continuam sendo rpidos. Felizmente existem alternativas mais seguras como o caso do bcrypt e PBKDF2. Com relao as outras alternativas para identicao de usurios, um servio pode conrmar a identidade de um usurio atravs de outro servio atravs do protocolo OAuth, ou mais recentemente com o uso do OpenID, que um padro aberto para

55

autenticao de usurios de maneira descentralizada, sendo o Facebook Connect o exemplo mais famoso de todos (ELDON, 2009). Mas tudo o que foi acima descrito parte da premissa de que o servio em questo exige que o usurio se identique, o que no uma unanimidade na Internet. Existem sites na Internet que exigem diferentes nveis de identidade, desde os mais rigorosos, como o caso do Facebook e Google+, que possuem polticas que exigem identidades reais dos usurios citeMcCracken2011. At sites mais exveis, como o Reddit que nem ao menos exige um endereo de e-mail para o cadastro do usurio, o como o image board 4chan, onde usurios podem permanecer annimos, podendo postar contedo sem se cadastrar (BERNSTEIN; MONROY-HERNNDEZ; HARRY; ANDR; PANOVICH; VARGAS, 2011). O que exigir do usurio depende muito do propsito do servio. Existem casos onde o usurio pode no se sentir confortvel revelando sua identidade real, podendo at mesmo estar arriscando sua vida ao fazer isso. Por outro lado, existem aqueles que argumentam que a ausncia de uma identidade real pode depreciar a qualidade do contedo de um site, pois a anonimidade costuma abrir portas para comportamentos pouco sociais, bem como fortalecer o sentimento de comunidade (BERNSTEIN; MONROY-HERNNDEZ; HARRY; ANDR; PANOVICH; VARGAS, 2011). Alm disso, a ausncia de uma identidade pode ter um impacto negativo na percepo de outras pessoas com relao as contribuies de um usurio (RAINS, 2007).

2.2 GEOLOCALIZAO

Geolocalizao, segundo Holdener (2011), se refere ao ato de identicar a posio geogrca real de uma pessoa, lugar ou coisa, envolvendo atualmente diversos dispositivos eletrnicos, como computadores, roteadores, smartphones, tablets e sistemas baseados em GPS. Por de trs desta facilidade esto alguns conceitos que precisam ser compreendidos na construo de aplicaes que faam uso da geolocalizao. As prximas sees iro detalhar estes conceitos, bem como os meios pelos quais a localizao

56

pode ser obtida e que tipos de aplicaes podem ser desenvolvidas tirando vantagem da geolocalizao.

2.2.1 Sistemas de Coordenadas

Quando se fala em posicionamento global possvel imaginar um mapa da Terra ou de parte dela, como um pas, onde a localizao de uma pessoa ou objeto vem a ser um pequeno ponto neste mapa. A forma mais conhecida para se informar uma localizao na Terra atravs da latitude e longitude, dados que podem ser obtidos atravs de um aparelho que possua um GPS, por exemplo (HOLDENER, 2011). Estes dados representam as coordenadas do dispositivo, como as de um smartphone, e so utilizados na localizao do mesmo na Terra. Clynch (2006) arma que existem basicamente dois tipos de sistemas de coordenadas: cartesiano e curvilneo ou angular. O primeiro compreende os sistemas de coordenadas que se utilizam de valores x-y-z, tanto em metros, kilmetros ou outras unidades de distncia, enquanto que o segundo compreende aqueles que fazem uso da latitude, longitude e altitude. Sistemas de coordenadas geogrcas fazem uso do segundo tipo de coordenadas (HOLDENER, 2011). Como pode ser visto na Figura 2.14, a latitude representada pelas linhas verticais no globo, enquanto que a longitude representada pelas linhas horizontais. Tanto as linhas verticais como as horizontais so igualmente espaadas, muito embora a forma da terra no seja a de uma esfera perfeita, assunto que ser abordado na prxima seo (HOLDENER, 2011). O espaamento tanto entre as linhas de latitude como entre as linhas de longitude (tambm conhecidas como meridianos) de aproximadamente 111.04 kilmetros. Ambos tem suas medidas expressas em graus, sendo os valores da latitude compreendidos entre 0o (na linha do Equador) e 90o tanto para o hemisfrio norte como o sul. J a longitude vai de 0o a 180o tanto para o leste como para o oeste, partindo do meridiano de Greenwich, este tendo sido estabelecido em 1884 (HOLDENER, 2011).

57

Como fora falado no pargrafo anterior, tanto a latitude como a longitude so medidos em graus, mas importante dizer que na verdade, para garantir alta preciso, os graus so divididos em graus (o ), minutos () e segundos ("), sendo que cada minuto composto de 60 segundos e um grau por 60 minutos. As coordenadas podem ser representadas tanto em graus, minutos e segundos (e.g. 90 11 7O, onde O signica Oeste), graus e minutos (no sendo muito utilizado) e graus decimais (HOLDENER, 2011).

Fonte: Holdener (2011, p. 20)

Figura 2.14: Diagrama da latitude e longitude na Terra.

Em graus decimais, tanto os minutos como os segundos so transformados em uma frao de um grau e se a direo for sul ou oeste o valor passa a ser negativo, como no exemplo abaixo: 38 37 29N 38.624722 56 1213S 56.203611

Agora que os conceitos bsicos sobre coordenadas foram estabelecidos, preciso entender como posies geogrcas so traduzidas para posies reais na Terra, assunto que ser abordado na seo a seguir.

58

2.2.2 Sistemas Geodticos e Datums

Sistemas geodticos consistem em sistemas de coordenadas com mtricas e curvatura denidas e sua realizao atravs de um conjunto de coordenadas de pontos de referncia (TORGE, 1991). Em outras palavras, so sistemas utilizados para converter posies indicadas em mapas para suas reais posies na Terra, alm disso estes sistemas fazem uso de datums como referncia para realizar a converso das coordenadas (HOLDENER, 2011). De acordo com Defense Mapping Agency (1983), datum qualquer quantidade numrica ou geomtrica ou um conjunto destas quantidades, estas servindo como referncia ou base para outras quantidades. Holdener (2011) destaca que os datums relevantes para a geolocalizao so aqueles que modelam a Terra como uma superfcie plana (ao contrrio de outros que a modelam como uma esfera ou elipside), principalmente pela maior facilidade em se exibir mapas em duas dimenses na Web, tarefa que se torna mais complicada com mapas em trs dimenses. Com relao ao formato da Terra, muito embora possa ser representado atravs de uma esfera, como o Google Earth o faz, ele se aproxima mais a forma de um esferide achatado em seus plos (HOLDENER, 2011). Esta aproximao da gura da Terra utilizada pois a gura fsica da terra (i.e., o formato da Terra levando em conta o relevo dos continentes e do fundo dos oceanos) de difcil representao matemtica. Em vista disto se dene o que conhecido por geide, onde a superfcie do oceano se extende pelos continentes, criando uma forma mais uniforme, sendo que a superfcie do oceano equipotencial ao campo de gravidade terrestre (TORGE, 1991). Ainda assim, sistemas de referncia optaram pela elipside (ou esferide) pela sua simplicidade, enquanto que o geide, com sua distribuio desigual da massa da Terra, melhor utilizado como superfcie de referncia para altitudes (TORGE, 1991). A Figura 2.15 mostra as diferenas entre a superfcie de uma elipside, geide e do solo terrestre, sendo o primeiro deles o mais uniforme dentre os trs.

59

Fonte: Cross, Hollwey e Small (2002, p. 5).

Figura 2.15: Figuras da Terra. Ao longo do tempo, entretanto, vrios datums foram criados na medida em que a compreenso sobre o formato e tamanho da Terra se alteravam. Atualmente existem vrios datums em uso por todo o mundo, alguns deles so considerados globais enquanto que outros so mais utilizados em determinadas regies. Estes ltimos geralmente representam melhor determinada rea do que os datums globais, podendo em alguns casos haver diferenas de at 140 metros entre dois datums (HOLDENER, 2011). Dentre os datums globais atualmente em uso, os mais conhecidos so:

World Geodetic System (WGS 84) North American Datum (NAD 83) European Datum (ED 50)

Dentre os trs datums acima, aquele que pode realmente ser chamado de datum global o WSG 84, criado pelo Departamento de Defesa dos Estados Unidos. Dentre os motivos que levaram a criao de um sistema global estava a crescente necessidade de mapas globais, impulsionada pelo comrcio e turismo internacional

60

(HOLDENER, 2011). O WGS 84 fora criado em 1960 (WGS 60), tendo passado por diversas revises como a WGS 66, WGS 72 e por m WGS 84, sendo que esta ltima fora ainda revisada em 2004 (HOLDENER, 2011). De acordo com NIMA (2000), o WGS 84 , atualmente, o melhor sistema geodtico global de referncia para a Terra, sendo utilizado para aplicaes prticas de mapeamento, cartograa, geoposicionamento e navegao. No coincidncia portanto, o fato de o sistema NAVSTAR GPS utilizar como referncia a elipside denida pelo WGS 84 (USACE, 2003). O WGS 84, alm de fornecer uma elipside de referncia, tambm prov um framework para determinar coordenadas na Terra e um geide que dene matematicamente a forma aproximada da superfcie da Terra (HOLDENER, 2011). Mas tudo o que fora falado at agora se refere gura tridimensional da Terra, entretanto, boa parte dos aplicativos e servios disponveis na Web faz uso de representaes em duas dimenses da superfcie da Terra. Quando esta representao em duas dimenses feita sobre uma pequena rea no existem muitos problemas, mas quando a rea representada muito grande (i.e. toda a Terra) os problemas comeam a surgir. Mapas podem exibir certos aspectos da Terra, como escala, distncia, rea e forma, entretanto, nenhum mapa consegue manter todos os aspectos intactos, alguns deles precisam ser comprometidos para que outros permaneam intactos (HOLDENER, 2011). Grande parte dos fornecedores de servios de mapas da Web (e.g., Google e Microsoft) fazem uso do mapa baseado na projeo de Mercator, criada em 1569 por Gerardus Mercator. Nesta projeo todas as linhas longitudinais e latitudinais se cruzam em ngulos retos (90 ), mantendo os aspectos geogrcos da Terra normais nas proximidades da linha do Equador, mas deformando signicativamente os plos (HOLDENER, 2011).

61

Fonte: Holdener (2011, p. 26).

Figura 2.16: Mapa do mundo segundo a projeo de Mercator.

2.2.3 Outros Conceitos

Antes de falar sobre como as coordenadas geogrcas podem ser obtidas e o que pode ser feito com elas, existem ainda algumas propriedades que precisam ser abordadas. Uma delas a altitude, que faz parte do sistema de coordenadas angular e foi abordado na seo 2.2.1, e necessria para que um ponto possa ser posicionado exatamente em sua localizao. Normalmente a altitude compreende nveis acima do nvel do mar, mas ela tambm pode ser denida atravs da geodsia (HOLDENER, 2011). A altitude calculada atravs do Nvel Mdio do Mar (MSL ou Mean Sea Level) da Terra, este sendo estabelecido atravs do monitoramento prolongado da altura da superfcie do oceano, calculando a partir deste o seu nvel mdio. Devido as diferenas existentes no campo gravitacional da Terra, pases escolhem individualmente o nvel mdio do oceano que ser utilizado como padro (HOLDENER, 2011). Outra propriedade que pode ser til na geolocalizao o curso ou direo de determinado objeto. Esta propriedade pode ser vista de duas formas: a direo de um ponto a outro (e.g., se o objeto est indo do ponto A para o ponto B, ele precisa

62

tomar determinada direo para alcanar seu destino) ou a direo para a qual o objeto est apontando (no signicando, necessariamente, que ele ir se deslocar para esta direo). A direo medida como um ngulo, em graus, com relao a um ponto de referncia xo, sendo este geralmente o Norte verdadeiro. O valor da direo vai de 0 at 360 em sentido horrio, sendo 0 o Norte, 90 o Leste, 180 o Sul e 270 o Oeste. Objetos, alm de estarem localizados em trs dimenses e possuirem uma direo, podem ter ainda velocidade, isso quando estiverem em movimento (HOLDENER, 2011).

2.2.4 Distncia do Grande-Crculo

A distncia do grande crculo (ou do crculo mximo ou ainda ortodromica) a menor distncia entre dois pontos na superfcie de uma esfera, medidas ao longo do caminho percorrido atravs da superfcie, sem atravessar o seu interior. Enquanto que em um espao euclidiano a distncia entre dois pontos medida pelo comprimento de uma linha reta entre os pontos, na geometria no-euclidiana as linhas retas so substitudas por geodsicas (WEISSTEIN, 2012). Uma das frmulas utilizadas para o clculo de distncia entre dois pontos a Lei Esfrica dos Cosenos. E apesar de ela ser mais suscetvel a erros de ponto utuante, os computadores atuais possuem alta preciso com pontos utuantes, evitando assim erros em distncias pequenas (MOVABLE TYPE, 2012). A Frmula 2.1 mostra o clculo do ngulo central entre os dois pontos ( ), onde s , s , f e f representam a latitude e longitude dos dois pontos, respectivamente, e e a suas diferenas.

= arccos (sin s sin f + cos s cos f cos )

(2.1)

Outra frmula utilizada para o clculo da distncia entre dois pontos a de Haversine, sendo considerada melhor condicionada para curtas distncias (Frmula

63

2.2). Apesar de ser uma frmula com boa preciso para grande parte das distncias em um esfera, ela contm erros de arredondamento em pontos antipodais, que so pontos opostos da esfera, cuja linha reta traada de um ponto a outro cruza o centro da Terra (THE GEOMETRY OF THE EARTH, 2012).

= 2 arcsin sin2

+ cos s cos f sin2 2 2

(2.2)

Para se obter preciso para todas as distncias existe a frmula de Vincenty (Frmula 2.3), utilizada normalmente para a computao de distncias sobre um elipside. Segundo Movable Type (2012), esta frmula capaz de dar distncias com preciso prxima a 1mm.

(cos f sin )2 + (cos s sin f sin s cos f cos )2 = arctan sin s sin f + cos s cos f cos

(2.3)

O clculo da distncia entre os pontos (d), para todas as trs frmulas acima descritas, dado atravs de d = r , onde r o raio da esfera (raio da T erra 6371 km).

2.2.5 Mtodos de Localizao

Dentre os mtodos para obteno da localizao o mais conhecido , sem dvida alguma, o GPS. Alm deste, a localizao pode ser obtida atravs de endereos IP, GSM/CDMA Cell IDs, endereo MAC da WiFi ou Bluetooth e por entrada do usurio (HOLDENER, 2011). Os mtodos em maior uso atualmente sero abordados nas sees dispostas a seguir.

64

2.2.5.1 GPS (Global Positioning System)

O GPS um sistema de navegao global via satlite (GNSS Global Navigation Satellite System) operado e mantido pelo Departamento de Defesa dos Estados Unidos (DoD), compreendendo 24 satlites em rbita de grande altitude. Sua principal misso prover dados de navegao e velocidade passivos, em tempo real, de posicionamento 3D para foras tticas e estratgicas com base em terra, ar ou gua em qualquer lugar do mundo. Ficando em segundo lugar as aplicaes civis, estas predominantes (USACE, 2003). No sistema GPS o clculo da posio do dispositivo feita atravs do registro do tempo que as mensagens enviadas por todos os satlites ao alcance leva para chegar, permitindo assim a determinao da distncia do dispositivo com relao a cada um dos satlites. Com essas informaes o dispositivo capaz de calcular a sua posio atravs da trilaterao, de forma semelhante a triangulao via rdio, com a diferena de que no sistema GPS preciso pelo menos 4 satlites para determinar a posio devido ao tempo que os sinais dos satlites levam para chegar na Terra (HOLDENER, 2011). A Figura 2.17 ilustra um exemplo de um dispositivo utilizando 4 satlites para obter sua posio atravs da trilaterao, mtodo este que se baseia na medida simultnea das distncias de trs pontos de referncia com posies conhecidas (MANOLAKIS, 1996). Por outro lado, e como fora colocado anteriormente, no sistema GPS so necessrios no mnimo 4 satlites para que a posio do dispositivo possa ser conhecida. Cada satlite envia a todo momento sinais contendo um timestamp indicando quando a mensagem foi enviada (tempo calculado atravs de um relgio atmico, segundo Blewitt (1997)), informao orbital e correes de tempo para o satlite que enviou a mensagem (ephemeris), e informaes orbitais e correes de tempo para todos os satlites (almanac) (HOLDENER, 2011). Atravs das informaes acima descritas o dispositivo calcula a distncia com relao a cada um dos satlites e cria uma esfera para cada um deles. Seguindo a ordem da Figura 2.17, o dispositivo cria a esfera para A e depois a esfera para B, a

65

Fonte: Holdener (2011, p. 8).

Figura 2.17: GPS utilizando satlites para obter sua localizao. interseco entre as esferas de A e B indica o permetro onde o dispositivo est localizado. Com a criao da esfera de C o perimtro se reduziu a dois pontos possveis, e com a esfera de D possvel determinar com certeza a localizao do dispositivo (esfera vermelha com borda branca) (HOLDENER, 2011).

2.2.5.2 Endereo IP

O endereo IP um nmero nico designado a cada dispositivo conectado a Internet. Este endereo de rede um nmero de 32 bits escrito em notao decimal e com pontos, sendo que cada um dos 4 bytes do endereo pode ter um valor que vai de 0 at 255 (e.g., o endereo hexadecimal C0290614 corresponde 192.41.6.20) (TANENBAUM, 2003). Holdener (2011) arma que em boa parte dos casos endereos IP so designados a fornecedores de acesso a internet (conhecidos tambm como ISP Internet Service Provider ) com blocos do endereo baseados na regio por uma instituio

66

de registro local. Ou seja, atravs dos blocos do endereo IP possvel identicar o pas, estado e at mesmo a cidade onde ele est localizado. importante lembrar, entretanto, que a acuracidade da posio do dispositivo nem sempre boa, apesar dos avanos obtidos recentemente. Existem casos onde a localizao obtida corresponde a do ISP ou algum servidor de proxy ao invs da posio do dispositivo em si, podendo desta forma fornecer localizaes a kilmetros de distncia de sua real posio (HOLDENER, 2011). Em vista da diculdade de se obter informaes sobre a localizao de dispositivos atravs do seu endereo IP, algumas empresas criaram servios que permitem o acesso a bancos de dados que contm catlogos de endereos IPs e suas respectivas localizao em forma de APIs (e.g., IPInfoDB, Geobytes, Quova). Adicionalmente, a API de Geolocalizao denida pela W3C (melhor detalhada na seo 2.2.12) para navegadores tambm utiliza o endereo IP do dispositivo para obter a localizao do mesmo, sem a necessidade de o desenvolvedor fazer chamadas a servios de terceiros (HOLDENER, 2011).

2.2.5.3 GSM/CDMA Cell IDs

Assim como o endereo IP serve para identicar dispositivos na Internet, as Cell IDs identicam dispositivos mveis em redes de celulares, sendo a GSM (Global System for Mobile Communications) e a CDMA (Code Division Multiple Access) as redes mais populares (HOLDENER, 2011). A tcnica de obteno da localizao atravs de um identicador nico de rede, a Cell ID, independe do tipo de tecnologia utilizada (GSM ou CDMA) (HOLDENER, 2011). A obtebo da localizao do dispositivo feita atravs da triangulao, sendo que quanto maior a quantidade de torres ao alcance, maior a acuracidade da localizao obtida. De forma semelhante ao GPS, o dispositivo mvel deve receber a localizao de cada torre juntamente com o timestamp de envio do sinal para poder calcular a distncia com relao a torre e efetuar a triangulao (TREVISANI; VITALETTI, 2004).

67

Nos Estados Unidos a FCC (Federal Communications Commission), atravs dos servios Enhaced 9-1-1 (E911), obrigou as operadoras de celular a terem ao menos 95% dos dispositivos mveis obtendo suas posies com at 300 metros de acuracidade, o que melhorou consideravelmente a geolocalizao nestes dispositivos (HOLDENER, 2011).

2.2.6 Location-based Services

Servios baseados em localizao (LBS), segundo Holdener (2011); Steiniger, Neun e Edwardes (2012), so servios disponveis geralmente em dispositivos mveis e que provm informaes sensveis a localizao do usurio. Os LBSs podem ser considerados parte da Computao Sensvel ao Contexto (context-aware computing) por se adaptarem ao ambiente em que esto inseridos atravs de informaes obtidas por sensores, neste caso a geolocalizao (BARKUUS; DEY, 2003). A Figura 2.18 mostra as tecnologias que podem ser aplicadas para a criao de servios baseados em localizao, e a partir dela possvel ver que existe uma relao entre LBSs e GIS (Geographic Information Systems). Este ltimo, que ser abordado na prxima seo, se relaciona com os LBSs no sentido de que ambos lidam com dados de posicionamento e funes de anlise espacial, entretanto, os GISs existem a mais tempo e podem ser considerados sistemas voltados mais para prossionais da rea, fornecendo grande quantidade de funcionalidades e tambm exigindo maior poder de computao. Por outro lado, os LBSs so mais recentes devido a evoluo dos servios mveis pblicos, e trabalham em cima de limitaes como baixo poder computacional (ao menos no lado do cliente), monitores pequenos e tempo da bateria dos dispositivos mveis (STEINIGER; NEUN; EDWARDES, 2012). Para Shek (2010), a primeira gerao de servios baseados em localizao eram apenas reativos, ou seja, o usurio requisitava para uma aplicao alguma informao e recebia a informao. Mas com o advento de mecanismos de noticaes push (onde o servidor envia mensages para o cliente sem este ter necessariamente

68

Fonte: Steiniger, Neun e Edwardes (2012, p. 2).

Figura 2.18: A interseco de tecnologias que formam o LBS.

efetuado uma requisio (GSM ASSOCIATION, 2003)), alm de melhor conexo a internet atravs de dispositivos mveis e a evoluo da Web 2.0 as aplicaes LBS se tornaram mais proativas e interativas. GSM Association (2003) estende esta ideia e classica sistemas LBS em pull, push e tracking. O primeiro deles o que foi descrito como a primeira gerao de servios, onde o usurio faz as requisies e no segundo tipo o servio envia informaes para o usurio, sem este ter requisitado. O terceiro tipo de sistema LBS o tracking, neste caso uma pessoa ou outro servio pode requisitar a localizao de algum dispositivo (e.g., smartphone ou carro). Os exemplos de servios LBS so diversos, desde aplicaes para localizar estabelecimentos ao redor (e.g., restaurantes, hotis, lojas), aplicaes para monitorar familiares, noticaes sobre congestionamentos ou acidentes em estradas e aplicativos para encontrar amigos que esto por perto. Alm destes existem muitas outras aplicaes disponveis no mercado, sem levar em conta as novas oportunidades que podem ser criadas com este tipo de servio (HOLDENER, 2011). S para dar uma ideia de quo abrangente podem ser as aplicaes LBS, a Figura 2.19 exibe uma classicao hierrquica das aplicaes LBS, partindo da navegao, informao e

69

Fonte: Steiniger, Neun e Edwardes (2012, p. 8).

Figura 2.19: Categorias de aplicaes LBS.

rastreamento, e indo at emergncias, publicidade, contas, gerenciamento e lazer. Est previsto que em 2012 20% dos usurios faro uso de LBS, e o mercado para este tipo de servios pode exceder US$12 bilhes em 2014, sendo que aplicaes voltadas para vendas (mobile advertising) podero ser responsveis por boa parte deste resultado (GSM ASSOCIATION, 2003). Outra pesquisa, detalhada em Zickuhr e Smith (2011), mostra que 28% dos adultos americanos usam servios mveis e sociais baseados em localizao, principalmente para obter direes e recomendaes baseadas em sua localizao atual. Entretanto, apenas 4% dos adultos usam seus celulares para fazer checkin em lugares atravs de redes sociais especializadas como Foursquare e Gowalla. Um tpico dos LBSs que importante abordar diz respeito as tecnologias e componentes necessrios para que eles venham a funcionar. A Figura 2.18 d uma prvia a respeito dos componentes, estes sendo melhor detalhados agora na Figura 2.20.

70

O primeiro componente do LBS a aplicao, este por sua vez composto por um smartphone (ou algum outro dispositivo mvel capaz de obter sua localizao) e um servidor da aplicao. um esquema tpico de muitas aplicaes Web onde h um cliente e um servidor. Neste caso o cliente, sendo um dispositivo mvel, possui sensores e dentre eles o GPS (ver Mtodos de Localizao, seo 2.2.5), por exemplo, permitindo que a aplicao instalada no smartphone seja capaz de obter a localizao do dispositivo e envi-la para o servidor do aplicativo. O servidor recebe essas informaes e pode, atravs delas, realizar buscas em um banco de dados com objetos que tambm possuam informaes sobre suas localizaes (location-tagged) e ento retornar informaes sensveis a localizao do dispositivo (SHEK, 2010). O middleware encapsula o acesso dos aplicativos as core features do LBS, criando uma interface padronizada de acesso. Normalmente desenvolvedores de aplicaes LBS tambm eram responsveis pela construo destas interfaces de comunicao, pois no havia no mercado nenhum padro estabelecido, ao menos no at agora (SHEK, 2010). O OGC (Open Geospatial Consortium) est empenhado no desenvolvimento de padres na rea de LBS, tendo como membros empresas como ESRI, Oracle, Google e IBM. E dentre os padres em desenvolvimento est o OpenLS (Open Location Services), padro este que prope toda uma arquitetura para sistemas LBS, alm de interfaces para vrios de seus componentes. Este consrcio tambm promove o desenvolvimento de outros padres como GML e KML para transferncia de dados sobre localizao (SHEK, 2010). Mas por ser um tpico abrangente (padres abertos para contedo e servios geoespaciais), o mesmo ser abordado com maior propriedade na seo 2.2.8. O prximo componente de um LBS o location tracking (rastreamento da localizao), ele ca responsvel por armazenar a localizao de um indivduo. Atravs de um histrico de rotas percorridas pelo usurio mais a localizao atual do mesmo possvel determinar a rota futura do mesmo, enviar noticaes para o usurio de acordo com sua localizao atual ou possveis localizaes futuras, alm de muitas outras funcionalidades (SHEK, 2010).

71

Fonte: Shek (2010, p. 10).

Figura 2.20: Componentes de um LBS.

GIS Providers (ou Provedores de Sistemas de Informao Geogrca), como o prprio nome sugere, proveem funcionalidades geospaciais, estes podendo ser consumidos na forma de APIs, como o Google Maps ou o OpenRouteService.org. Provedores GIS incluem servios com informaes sobre mapas, visualizao de mapas e diretrios (SHEK, 2010). O ltimo dos componentes trata do mtodo pelo qual a localizao do dispositivo ou indivduo ser obtida, assunto este abordado na seo 2.2.5.

2.2.7 GIS (Geographic Information Systems)

De acordo com Bolstad (2008, p. 1), GIS is a computer-based system to aid in the collection, maintenance, storage, analysis, output, and distribution of spatial data and information .

72

Ferramentas de GIS auxiliam no gerenciamento do conhecimento geogrco e obteno e uso de dados espaciais. Este tipo de ferramenta se preocupa tanto com localizaes como com propriedades e atributos atrelados a essas localizaes. Por exemplo, uma destas ferramentas poderia armazenar a localizao de rios, bem como informaes sobre seu tamanho, qualidade da gua e taxa de uxo (BOLSTAD, 2008). Na Figura 2.21 possvel visualizar um exemplo do que uma aplicao GIS pode armazenar, como informaes sob vrios aspectos de determinada regio, como estradas, prdios e vegetao. Folger (2011) cita como exemplo de GIS uma aplicao que possui a localizao de uma interseco em uma rodovia e a mdia de carros que passam por ela em um dia, para que a partir destes dados seja possvel extrair informaes teis para a escolha da localizao de um negcio.

Fonte: Folger (2011, p. 5).

Figura 2.21: Camadas de dados de um GIS. Um exemplo real do uso do GIS foi quando ocorrera o terremoto e tsunami no Japo (em 11 de Maro de 2011) e um grupo de voluntrios chamado GISCorps iniciou um projeto, em colaborao com a CrisisCommons, para criar um mapa interativo para mostrar informaes em tempo real sobre abrigos, reas inundadas, centros de

73

distrubuio de gua, estradas limpas, alm de outras informaes teis para uso pelos cidados e voluntrios. interessante notar que uma das fontes de informaes deste aplicativo foram pessoas que estavam no Japo, como conhecidos dos membros do grupo de voluntrios, formando algo semelhante ao crowd-sourcing para obteno de informaes teis (FOLGER, 2011). A aplicao criada pelos voluntrios, mostrada na Figura 2.22 (disponvel em http://gis.ats.ucla.edu/japan/), possui vrias camadas de informaes. Nesta imagem, a aplicao mostra as reas inundadas em azul e as usinas de energia nuclear nos bales vermelhos. J o tringulo em vermelho indica a usina de Fukushima I, danicada pelo tsunami (FOLGER, 2011).

Fonte: Folger (2011, p. 12).

Figura 2.22: Japan Tohoku Earthquake.

74

2.2.8 Padres

Na dcada de 1980 diversas organizaes faziam uso de sistemas de informao geogrca, desde agncias do governo at setores de engenharia civil e marketing. Entretanto, apesar da disponibilidade de ferramentas para mapeamento e anlise espacial, estes softwares tinham altos custos, e principalmente, no eram capazes de trocar informaes com outros sistemas (OGC, 2012). O desenvolvimento do software GRASS (Geographic Resources Analysis Support System) para o U.S. Army Corps of Engineers, reconhecido como um dos primeiros projetos open source globais, culminou na criao da Open GRASS Foundation (OGF). Ainda assim, este software no oferecia interoperabilidade completa, e para tentar resolver este problema o The OpenGIS Project deniu interfaces abertas para comunicao entre sistemas de geoprocessamento (OGC, 2012). Em 1994 a OGC (Open Geospatial Consortium) foi fundada, ela uma organizao sem ns lucrativos e que se preocupa com a criao de padres abertos para interoperabilidade entre ferramentas GIS, sendo estas open source ou comerciais (MICHAELIS, 2007). A Figura 2.23 ilustra os principais padres estabelecidos pela OGC bem como o relacionamento entre eles, estes sendo descritos no OGC Reference Model (ORM), descrevendo no apenas o relacionamento entre seus padres mas tambm com os padres ISO (OSGEO, 2012a). Estes padres, tanto abstratos como implementaes (OGC Abstract and Implementation Standards), juntamente com documentos de melhores prticas (OGC Best Practices) formam o OGC Standards Baseline (SB) (PERCIVALL, 2011). Mais especicamente, a Figura 2.23 descreve os padres da OGC para Web services, conhecidos como OGC Web Services (OWS). Neste esquema existem os provedores de recursos, sendo estes servios de dados (Data Services), de representao (Portrayal Services) ou processamento (Processing Services), que os disponibilizam para o pblico atravs de servios de catlogos (Catalog Services). Possibili-

75

Fonte: OSGeo (2012a).

Figura 2.23: Principais padres da OGC.

tando, desta forma, que usurios nais e seus aplicaitivos sejam capazes de encontrar e fazer uso destes recursos (OSGEO, 2012a). No que tange os padres de codicao da OGC (encodings), a GML (Geography Markup Language) um vocabulrio XML para representao de caractersticas geogrcas, permitindo a interoperabilidade entre sistemas de forma aberta. H ainda a SensorML (Sensor Model Language), que prov um framework para descrio de caractersitcas geomtricas, dinmicas e observacionais de sensores e sistemas de sensores; e a SLD (Style Layer Description), que serve para a denio da simbolizao e colorao de caractersticas geogrcas e sua cobertura, utilizada na aplicao de estilos em Web Map Services (PERCIVALL, 2011). Processos, segundo Percivall (2011), incluem qualquer algortimo, clculo ou modelo que opera em dados. Quando estes dados so dados referenciados espaci-

76

almente, estes processos podem ser chamados de geoespaciais. O papel do WPS (Web Processing Service) o de denir uma interface que facilite a publicao e descoberta destes processos por clientes. E do mesmo modo que existem padres para descrever interfaces de acesso a processos sobre dados espaciais, devem haver padres para descrever as interfaces de acesso a estes dados. Um destes padres o Simple Features Access (SFA), ele descreve uma arquitetura comum para geometria simples (simple feature geometry ). Existem ainda documentos descrevendo a implementao deste padro em CORBA, OLE/COM e SQL. Para esta ltima fora denido um esquema para suporte ao armazenamento, recuperao, pesquisa e atualizao de informaes geogrcas (PERCIVALL, 2011). No mercado existem vrios sistemas de bancos de dados que suportam dados espaciais, sendo conhecidos como bancos de dados espaciais, apesar de serem na maioria dos casos bancos de dados relacionais com suporte adicional a esta caracterstica (HOLDENER, 2011). Na prxima seo maiores detalhes sero dados com relao a bancos de dados espaciais. Ainda com relao a padres de interfaces para acesso a dados geogrcos, existe o Web Feature Service (WFS), onde clientes podem recuperar e atualizar dados codicados com GML de vrios WFSs. Semelhante ao WFS, o Web Coverage Service (WCS) especica interfaces para acesso de dados geoespaciais na forma de coverages, ou como o autor dene, informaes geoespaciais digitais que representam fenmenos que variam no tempo e espao (PERCIVALL, 2011). Existem ainda padres como o Web Map Service (WMS), que dene uma interface atravs do protocolo HTTP para requisio de imagens de mapas geo-registrados provenientes de um ou mais bancos de dados espaciais distribudos (OSGEO, 2012b); KML (KML Encoding Standard) que dene um vocabulrio para codicao e transporte de representaes de dados geogrcos para exibio em browsers da Terra (e.g., Google Earth) (PERCIVALL, 2011). Para encerrar, existe ainda o padro OpenLS (OpenGIS Location Services) que dene uma plataforma aberta para aplicaes baseadas em localizao com foco

77

em terminais mveis. Este padro troca informaes na forma de Abstract Data Types e possui cinco servios principais: Directory Service, para busca de lugares especcos ou prximos, produtos ou servios; Gateway Service, para obteno da localizao de um terminal mvel; Location Utility Service, compreende servios de geocoding e reverse geocoding, descritos na seo 2.2.10; Presentation Service, cria mapas e outros grcos atravs de dados geoespaciais; e Route Service, que determina rotas e informao para navegao entre dois pontos em um mapa (PERCIVALL, 2011).

2.2.9 Spatial databases

Bancos de dados espaciais so bancos de dados que permitem o armazenamento de dados espaciais, dando suporte tanto no modelo de dados como na sua linguagem de consulta, alm de proverem ndices especiais para dados especiais e algoritmos ecientes para joins espaciais (GTING, 1994). Dados espaciais podem ser descritos como dados que possuem propriedades e coordenadas em duas, trs ou mais dimenses no espao (OOI; SACKS-DAVIS; HAN, 1993). Dados espaciais podem ser divididos em dados sobre um ponto ou regio e so considerados atributos de objetos espacias, como linhas, superfcies e volumes (VELICANU; OLARU, 2010). Bancos de dados espaciais sa bancos de dados que suportam os tipos bsicos de dados e possuem o suporte a dados espaciais com uma funcionalidade adicional (GTING, 1994). ndices para bancos de dados espaciais incluem Grid index, Z-order, Quadtree, Octree, UB-tree, R-Tree, kd-tree e M-tree. O banco de dados da Oracle, por exemplo, oferece tanto ndices R-tree como Quadtree (VELICANU; OLARU, 2010). Holdener (2011) coloca que SGBDs como MySQL, DB2, Oracle e Microsoft SQL Server so todos capazes de armazenarem informaes espaciais nativamente em tabelas. Entretando, o autor arma que existem casos onde softwares adicionais precisam ser colocados sobre os SGBDs para adicionarem funcionalidades para que

78

o banco de dados seja capaz de lidar com estes dados. Dentre estes softwares est o ArcSDE, OracleSpatial e o PostGIS, sendo que o primeiro suporta mais de um banco de dados, enquanto que os outros dois foram desenvolvidos especicamente para o SGBD Oracle e PostgreSQL, respectivamente. O ArcSDE um produto desenvovido pela Esri para armazenamento e gerenciamento de dados geogrcos em conjunto com outros tipos de dados em um banco de dados relacional. Ele funciona com os bancos de dados IBM DB2, Informix, Microsoft SQL Server, Oracle e PostgreSQL. Alm disso, ele est de acordo com o padro da OGC Simple Features e da ISO para tipos de dados espaciais (HOLDENER, 2011). O PostGIS um software open source especco para o banco de dados PostgreSQL, adicionando a este funcionalidades para lidar com dados espaciais (HOLDENER, 2011), ou mais especicamente, objetos geogrcos, permitindo que ele seja utilizado em sistemas de informao geogrca (GIS). O PostGIS tambm segue o padro Simple Features Specication for SQL, sendo certicado como de acordo com o perl Types and Functions da especicao (POSTGIS, 2012a). Ao contrrio do Oracle e PostgreSQL, o MySQL no necessita de softwares adicionais para trabalhar com dados espaciais, pois ele implementa nativamente um subconjunto da especicao OGC SQL with Geometry Types, sendo que as convenes de nomes da OGC s fora implementada na verso 5.6 do SGBD (HOLDENER, 2011). O suporte as extenses espaciais do SGBD se limita aos motores de armazenamento (storage engines) MyISAM, InnoDB, NDB e ARCHIVE, entretanto, apenas o MyISAM suporta ndices espaciais (MYSQL, 2012). Existem ainda alternativas open source fora do mundo dos bancos de dados relacionais. As opes mais conhecidas so MongoDB e CouchDB (via GeoCouch), ambos bancos de dados classicados como NoSQL e orientados a documentos, eles tambm fornecem suporte a dados espaciais, mas de forma bem supercial (STEINIGER; HUNTER, 2009).

79

2.2.10 Geocoding

Geocoding is the method of identifying the geographic coordinates associated with textual location information like street address or postal code (HOLDENER, 2011, p. 7). Por exemplo, se for dado como entrada um endereo indicando um pas, estado, cidade e rua, atravs do geocoding a sada dever ser as coordenadas geogrcas deste endereo, como a latitude e longitude. O contrrio tambm vlido, ou seja, a entrada passa a ser a coordenada e a sada dever ser o endereo em forma de texto correspondente a coordenada informada (reverse geocoding) (HOLDENER, 2011). Na Web existem vrios servios que fornecem essa funcionalidade, dentre eles est o Google Geocoding API, Yahoo! Geocoding API, Bing Geocode Service e GeoNames.org. Este ltimo permite, alm de obter o servio de geocoding atravs de um web service, fazer o download de toda a base de dados utilizada para realizar o geocoding, permitindo desta forma a criao de um servio prprio de geocoding, no mais dependendo de terceiros. Existem ainda diversas bibliotecas que encapsulam a fonte pela qual a geocodicao ser feita, como o Ruby Geocoder, uma soluo desenvolvida para a linguagem de programao Ruby e que permite a escolha do servio de geocoding que ser utilizado. Alm disso ele permite o uso de servios que convertem endereos IP em endereos da localizao, seguindo a ideia de obter a localizao atravs do endereo IP, conforme seo 2.2.5.2 (RUBY GEOCODER, 2012). A Figura 2.24 mostra trs exemplos de geocoding, extrados do site do Ruby Geocoder, e que demonstram como o geocoding funciona. No primeiro exemplo dado o nome de um local turstico e como resultado so retornadas as coordenadas geogrcas para este local. No segundo exemplo ocorre exatamente o contrrio, atravs das coordenadas geogrcas obtem-se um endereo. E no ltimo exemplo um endereo IP fornecido e o endereo correspondente ao mesmo retornado (RUBY

80

GEOCODER, 2012).

Fonte: Ruby Geocoder (2012).

Figura 2.24: Exemplos de geocoding.

O relatrio Swift, Goldberg e Wilson (2008) avalia com detalhes questes como licenciamento, preo, limitaes e acuracidade de 8 ferramentas de geocoding, fornecendo base suciente para a escolha da ferramenta mais apropriada de acordo com as necessidades em vista.

2.2.11 Aplicaes e Servios

O assunto geolocalizao comeou a ganhar notoriedade por volta de 2009, quando comeou a se falar muito sobre o assunto, em especial entre desenvolvedores de software para dispositivos mveis (HOLDENER, 2011). A Figura 2.25 mostra o quanto fora falado sobre geolocation ao longo dos anos, de acordo com o Google Trends. D para perceber que o tpico fora comentado em 2004, mas ganhou fora apenas em 2007, tendo crescido desde ento. importante notar que este grco se baseia em anlises de buscas no buscador do Google, computando quantas buscas foram feitas para determinado termo (GOOGLE TRENDS, 2012a). Com relao a estatsticas de uso (tambm discutidas no nal da seo 2.2.6), segundo a empresa de pesquisa Forrester, apesar de 30% dos adultos online nos EUA estarem familiares com aplicativos que utilizam geolocalizao, apenas 6% deles fazem uso destes aplicativos, e quanto aos que os utilizam mais de uma vez por semana o nmero cai para 2% (GROVE, 2011).

81

Fonte: Google Trends (2012b).

Figura 2.25: Tendncia da palavra geolocation.

E em comparao com pesquisa de mesmo cunho realizado tambm pela empresa Forrester em 2010 eles constataram que apenas 2% a mais dos adultos online comearam a utilizar este tipo de aplicativos. Com relao a adoo e demograa de quem usa, no apenas aplicativos especializados como Foursquare, Loopt e SCVNGR, mas aplicativos que utilizam geolocalizao de forma geral, constatou-se que a predominncia de jovens do sexo masculino, sendo que usurios do sexo feminino esto aumentando (GROVE, 2011). Esta ltima constatao pode ser percebida pelos nmeros, pois a porcentagem de usurios do sexo feminino que utilizam este tipo de aplicaes cresceu de 22% em 2010 para 37% em 2011. E mais, 32% de todos os usurios de aplicativos de geolocalizao so da gerao X, enquanto que 43% so da gerao Y, e isso signica que grande parte do pblico destes aplicativos (75%) tem idades entre 23 e 45 anos (GROVE, 2011). Para nalizar, a pesquisa arma que a adoo de aplicativos de geolocalizao est em pleno crescimento e que a tendncia de que grande parte dos servios disponveis iro fazer uso da geolocalizao ao invs de apenas servios especializados, algo que j vem acontecendo com servios como Twitter e Facebook (GROVE,

82

2011). Holdener (2011) d nfase a trs tipos de aplicativos especializados em geolocalizao, sendo eles: aplicativos de midias sociais (social media apps), aplicativos de compartilhamento de localizao (location-sharing apps) e aplicativos de realidade aumentada (augmented reality apps). Os dois primeiros tipos de aplicativos possuem servios bem conhecidos no mercado, entretanto, o terceiro ainda tem poucas aplicaes disponveis e possui muito potencial a ser explorado. Nas prximas sees sero dados exemplos em cada um dos tipos de aplicaes especializadas em geolocalizao.

2.2.11.1 Social Media e Location-Sharing Applications

Antes de falar das aplicaes existentes de social media, importante descrever o que ela . Para Mayeld (2008), social media um grupo de novos tipos de mdia online, compartilhando caractersticas como:

Participao: qualquer um pode contribuir e enviar feedback. Abertura: liberdade para contribuir e dar feedback, bem como para ter acesso ao contedo e qualic-lo. Conversao: comunicao de duas vias, diferente de mdias como televiso, revistas e jornais. Comunidade: permite a criao rpida de comunidades e fornece meios para que ela se comunique. Conexo: prosperidade atravs de conexes, como atravs de links para contedo em outros sites ou comunidades.

Fazem parte desta mdia redes sociais, blogs, wikis, podcasts, forums, comunidades de compartilhamento de contedo e microblogging (MAYFIELD, 2008).

83

Uma das primeiras aplicaes de social media foi o Yelp, servio com o propsito de conectar empresas locais com pessoas da comunidade, permitindo que usurios encontrassem estas empresas e zessem avaliaes sobre as mesmas, alm de ler as avaliaes de outros membros da comunidade. O servio foi lanado em 2004 por Jeremy Stopppelman e Russel Simmons, tendo mais de 45 milhes de pessoas visitado ele em 30 dias, em Janeiro de 2011 (MAYFIELD, 2008).

Fonte: iTunes App Store (2012e).

Figura 2.26: Aplicativo do Yelp para iPhone.

Na Figura 2.26 possvel ver o aplicativo do Yelp para iPhone (verso 5.5.1). No print screen a esquerda da gura est a busca do aplicativo, onde neste caso o usurio pesquisou por sushi em So Francisco (Califrnia) e recebeu como resultado um mapa da cidade com os locais que oferecem sushi. J no print screen a direita est a pgina de um estabelecimento, mostrando informaes bsicas sobre o local, e principalmente a classicao que o mesmo possui e quantos usurios qualicaram o local, alm de permitir ler as avaliaes que os usurios deram para o local (YELP, 2012).

84

Alm das funcionalidades acima descritas, o servio permite que um indivduo adicione pessoas como amigos, e isso interessante porque quando ela for ler as avaliaes dos usurios, as que foram feitas pelos seus amigos estaro em destaque (pessoas tendem a conar em recomendaes de conhecidos em primeiro lugar (NIELSEN, 2009)). Usurios podem ainda fazer check in nos locais onde vo e encontrar lugares prximos de onde esto e promoes (YELP, 2012). O Google Latitude, construdo em cima do Google Maps, permite que um indivduo veja onde seus amigos esto a qualquer momento, alm de permitir que este compartilhe sua localizao (Figura 2.27) (HOLDENER, 2011). O servio est disponvel pela Web, para iPhone, e para Android. Sendo que neste ltimo, ele vem integrado ao Google Maps, bem como o Google Places e Google Navigation (ANDROID MARKET, 2012a). O Google Latitude na verdade o sucessor do Dodgeball, rede social criada por Dennis Crowley (tambm fundador do Foursquare), adquirida pelo Google em 2005 e descontinuada em 2009 (HOLDENER, 2011). Como Holdener (2011) mesmo coloca, o Google Latitude apenas arranha a superfcie com relao a aplicaes de social media para check-in. Uma aplicao mais completa, se que d para colocar desta forma, o Loopt, criado por dois sophomores (estudantes do 2o ano da universidade) de Stanford, Sam Altman e Nick Sivo. Pelas funcionalidades que o Loopt oferece possvel armar que ele possui caractersticas tanto do Latitude (ou Foursquare) como do Yelp. Em primeiro lugar, no Loopt geolocalizao tudo, ou seja, todas as atividades que voc faz no aplicativo esto atreladas a localizao de quem usa a aplicao iTunes App Store (2012f). Com o Loopt um usurio pode adicionar amigos e avis-los de onde est, compartilhar fotos e ver no mapa onde seus amigos se encontram. No aplicativo possvel ainda encontrar lugares nas redondezas e escrever avaliaes sobre eles. Existe ainda a funcionalidade de perguntas e respostas, sendo que responder pergun-

85

Fonte: iTunes App Store (2012g).

Figura 2.27: Aplicativo Google Latitude para iPhone.

tas d status para o usurio, como forma de recompensa. Por m, o aplicativo tambm oferece cupons do Groupon, obviamente utilizando a geolocalizao para oferecer ao usurio promoes nas proximidades iTunes App Store (2012f). A Figura 2.28 mostra dois print screens do aplicativo do Loopt para iPhone (tambm disponvel para Android), sendo a tela a esquerda a tela inicial do aplicativo e a tela a direita o mapa mostrando onde o usurio e seus amigos esto. Com relao a aplicativos de check-in (location-sharing), onde o usurio compartilha com amigos ou pessoas da rede social onde est em determinado momento, eles tem ganhado notoriedade nos ltimos anos (MACMANUS, 2010). Dentre os aplicativos mais conhecidos esto o Foursquare, Gowalla e SCVNGR. O primeiro deles o mais popular de todos, com mais de 15 milhes de usurios, fundado em 2007 por Dennis Crowley e Naveen Selvaduirai (FOURSQUARE, 2012).

86

Fonte: iTunes App Store (2012f).

Figura 2.28: Aplicativo do Loopt para iPhone.

O Gowalla fora lanado em 2009 durante o SXSW 2009 (South by Southwest), inicialmente pensado em torno de check-ins, posteriormente se voltando para a criao de histrias sobre lugares visitados por usurios e seus amigos. No m de 2011 a empresa foi adquirida pelo Facebook (KINCAID, 2011). Em comum, alm da idia de check-in, estas aplicaes tem tambm o conceito de gamication, ou seja, aplicaes que funcionam de alguma forma como um jogo. Atravs desta tcnica argumenta-se que os usurios estaro mais dispostos a usarem a aplicao. As aplicaes acima descritas so conhecidas como locationbased social networks (LBSN), e a idia do check-in em conjunto com o conceito de gamication signica que a cada check-in o usurio ganha pontos e badges (recompensas dadas com base nos hbitos do usurio, e.g., comer muita pizza ou frequentar muitos bares) (MCKENZIE, 2011).

87

Fonte: iTunes App Store (2012h).

Figura 2.29: Aplicativo do Foursquare para iPhone.

A ideia de gamication interessante porque ela pode sobrepor-se as preocupaes dos usurios com relao a privacidade. Isso signica que existem usurios dispostos a compartilhar sua localizao em troca de diverso e reconhecimento, isso porque existe uma questo de status social em dizer os locais que se est frequentando. Por exemplo, o usurio tem a sensao de estar ganhando status social ao compartilhar com os amigos que est na melhor boate da cidade. Da mesma forma, se o usurio for visitar um hospital talvez ele no queira compartilhar isto, pois pode acreditar que ir perder status social (MCKENZIE, 2011). Ainda assim, preocupaes com relao a privacidade dos usurios continuam existindo. Neste contexto, alguns aplicativos seguem abordagens diferentes na tentativa de amenizar essas preocupaes. O prprio Google Latitude permite que usurios restrinjam quem pode ver sua localizao para apenas usurios selecionados. Seguindo a mesma ideia est o Glympse, fundado em 2008 por trs exfuncionrios da Microsoft Bryan Trussel, Jeremy Mercer e Steve Miller (HOLDENER, 2011). Apesar da semelhana com o Google Latitude no que diz respeito a privacidade, a forma como a localizao compartilhada difere. Neste aplicativo, em primeiro lugar, no existe check-in, aqui o usurio, quando compartilha sua localizao com

88

Fonte: iTunes App Store (2012i).

Figura 2.30: Aplicativo do Glympse para iPhone.

algum ele compartilha sua localizao em tempo real e por um perodo de tempo determinado. Este compartilhamento pode ser feito atravs de um link enviado por e-mail, SMS, Facebook ou Twitter (ITUNES APP STORE, 2012i; HOLDENER, 2011). At agora, todos os exemplos de aplicaes que utilizam geolocalizao envolviam de alguma forma social media, e embora a integrao de aplicativos com esse tipo de mdia seja inevitvel (ou ao menos desejvel), existem aplicaes que utilizam a geolocalizao para outros ns, como o Shopkick. Criado em 2009 por Cyriac Roeding, Jeff Sellinger e Aaron Emigh, nele os usurios ganham recompensas e ofertas especiais ao caminharem pelas lojas (HOLDENER, 2011). De acordo com CrunchBase (2012g), o servio criou uma nova tecnologia de localizao permitindo que o aplicativo verique quando um usurio est realmente dentro de uma loja, j que o GPS no to acurado.

89

Fonte: Rao (2011).

Figura 2.31: Aplicativo do Shopkick para iPhone.

O aplicativo pode ser considerado um sistema de geo-coupon, e o usurio que caminha pelas lojas, experimenta roupas os escaneia cdigos de barras recebe kickbucks, estes podendo ser trocados por vales presente (gift cards), crditos do Facebook ou descontos em lojas parceiras. O aplicativo tambm se integra com os cartes de crdito da Visa, recompensando o usurio toda vez que ele utilizar o carto de crdito para pagar suas compras em lojas parceiras (RAO, 2011). Acredita-se que o futuro do comrcio esteja em fechar o crculo que se inicia quando um indivduo exposto a um anncio e termina quando ele realiza uma compra, e esta compra conectada de volta a oferta (RAO, 2011).

90

2.2.11.2 Augmented Reality Applications

Augmented reality is a combination of a real world view (usually through a camera or other lens) and a computer-generated view superimposed with sensory input (HOLDENER, 2011, p. 16). A realidade aumentada (AR) permite que informaes digitais processadas por computador se unam com aquelas vindas do mundo real atravs de interfaces de computador adequadas. Ela torna explcito o implcito, permite que informaes relacionadas ao mundo real mas que no esto explcitas possam ser vistas (INGLOBE TECHNOLOGIES, 2012). Por exemplo, apontado a cmera de um celular para uma rua o usurio poderia visualizar informaes sobre a rua, lojas nos arredores (at mesmo promoes) e pessoas que esto caminhando, s para citar algumas possibilidades (HOLDENER, 2011). As aplicaes de realidade aumentada atualmente fazem uso da geolocalizao e outros sensores dos dispositivos mveis para conseguir descobrir o mximo de informaes a respeito do contexto onde o usurio est inserido (HOLDENER, 2011). Um exemplo de aplicativo que utiliza a realidade aumentada para fornecer camadas (layers) de informaes para os usurios o Layar, fundado em 2009 por Claire Boonstra, Maarten Lens-FitzGerald e Raimo van der Klein em Amsterd (HOLDENER, 2011). Um dos produtos desta empresa o Layar Reality Browser, aplicativo instalado mais de 10 milhes de vezes, ele permite que informaes sejam atreladas a objetos do mundo real e visualziadas atravs da cmera de dispositivos mveis (o aplicativo est disponvel para Android, iPhone, Nokia e BlackBerry). O aplicativo suporta o uso de objetos 3D e animaes, dando suporte tambm para camadas baseadas em localizao (location-based), permitindo que o usurio encontre locais nos arredores (LAYAR, 2012). Como exemplo, na Figura 2.32 o usurio apontou seu smart phone com o browser da Layar para um cartaz de um festival que encontrou na rua, como o objeto (neste caso, o cartaz) estava registrado no sistema ele fora reconhecido e as infor-

91

maes atreladas ao objeto exibidas, permitindo que o usurio adquira os ingresso para o festival (LAYAR, 2012). Isso funciona de forma semelhante aos QR codes, este sendo um sistema que pode ser reconhecido por mquinas e que contm pequenas informaes, como um texto, nmero de telefone ou um link da Web. A diferena entre o QR code e este aplicativo da Layar que este ltimo transforma qualquer objeto do mundo real em uma tag e por ser um browser ele permite que objetos contenham informaes muito mais ricas e interativas (EATON, 2011).

Fonte: Layar (2012).

Figura 2.32: Exemplo de uso do Layar Reality Browser. Alm do browser desenvolvido pela Layar, existem outras empresas oferecendo browsers de realidade aumentada para dispositivos mveis. Butchart (2012) faz uma pequena introduo aos principais deles, como Junaio, Sekai, WikitudeWorlds e LibreGeoSocial, e ao nal faz uma comparao entre eles atravs de alguns aspectos especcos deste tipo de aplicao (Figura 2.33). Na primeira coluna da Figura 2.33 est o nome de cada um dos produtos sendo comparados. A segunda coluna verica quais dos produtos d suporte a rastreamento da localizao atravs de GPS, alm de outros sensores como acelerme-

92

tros e compasso. Na terceira coluna (marker based), o autor avalia se o aplicativo utiliza algum tipo de marcao (como um cdigo impresso em 2d) para reconhecer os objetos do mundo real, enquanto que na quarta coluna (markerless) ele verica aqueles aplicativos que tem a capacidade de reconhecer objetos do mundo real sem a necessidade de algum tipo de marcao (BUTCHART, 2012). Built in user actions diz respeito s aes que o usurio pode realizar atravs do browser e que no esto relacionadas a nenhum canal ou ponto de interesse em particular. Segundo este critrio, o usurio pode postar mensagens de texto, imagens e modelos 3D na sua localizao atual, e ele tambm pode tirar fotos e fazer upload da imagem em um servidor. Desenvolvedores podem oferecer uma viso da Web embutida, fornecendo diversos servios aos usurios, alm de acesso as redes sociais e busca visual atravs de tecnologias de reconhecimento de imagens (BUTCHART, 2012). Com relao a API para publicao de contedo (na sexta coluna), ela pode ter um acesso atravs de uma chave obtida pelos desenvolvedores (open key ), permitindo que eles publiquem seu contedo no servio. A publicao pode ser tambm por crowd sourcing, onde todos os usurios podem contribuir com contedo para o servio, esta API pode ainda ser disponvel mediante pagamento de alguma taxa (restricted key ) ou o contedo pode ainda ser embutido na aplicao, signicando que o desenvolvedor tem acesso a cdigo fonte do browser e pode criar seus prprios aplicativos (BUTCHART, 2012). J a API da aplicao compreende como o desenvolvedor podem alterar as funcionalidades e aparncia do browser, sendo que eles podem fazer isso atravs de modicao do cdigo fonte podendo existir restries (restricted), alm de ter (commercial) ou no (open) taxas de licenciamento. Por outro lado, algumas aplicaes iro permitir apenas a modicao da aparncia, sem permitir acesso ao cdigo fonte para alterao de funcionalidades (customize only ) (BUTCHART, 2012). A coluna AR View Content indica que tipo de contedo pode ser visualizado atravs do browser, pondendo ele ser contedo 2D, 3D e 3D com animaes. Points

93

Fonte: Butchart (2012).

Figura 2.33: Comparao entre browsers de realidade aumentada.

of Interest (POI) so itens associados com uma localizao geogrca ou padro visual (e.g., marcao ou capa de livro) e que so renderizados de alguma forma por aplicaes de realidade aumentada. As aes que podem ser realizadas sobre um POI (POI actions) so das mais diversas, desde um texto ou link da Web, at vdeos, mapas, e msica (BUTCHART, 2012). Estas aplicaes podem trabalhar em modo online apenas (necessitam de conexo constante), modo ofine e atravs de cache (dados obtidos online so salvos localmente). E o ltimo critrio avaliado com relao as plataformas suportadas pelos aplicativos (BUTCHART, 2012). Por ser uma tecnologia de ponta, Holdener (2011) arma que muitas aplicaes utilizando realidade aumentada ainda esto por vir, principalmente em combinao com a geolocalizao.

94

2.2.12 W3C Geolocation API

A API de Geolocalizao um esforo da W3C (World Wide Web Consortium) para criar um padro de acesso a informaes sobre a localizao geogrca de dispositivos (HOLDENER, 2011). De acordo com a especicao da W3C, disponvel em Popescu (2009, 2. Introduction):

The Geolocation API denes a high-level interface to location information associated only with the device hosting the implementation, such as latitude and longitude. The API itself is agnostic of the underlying location information sources. Common sources of location information include Global Positioning System (GPS) and location inferred from network signals such as IP address, RFID, WiFi and Bluetooth MAC addresses, and GSM/CDMA cell IDs, as well as user input. No guarantee is given that the API returns the devices actual location. The API is designed to enable both "one-shot"position requests and repeated position updates, as well as the ability to explicitly query the cached positions. Location information is represented by latitude and longitude coordinates.

importante colocar ainda que ela uma API disponvel atravs da linguagem de scripts JavaScript, e a localizao geogrca representada atravs da latitude e longitude (PILGRIM, 2010), estas sendo fornecidas de acordo com o sistema de referncia WGS 84 (descrito na seo 2.2.2) (POPESCU, 2009). Basicamente a API fornece trs mtodos pblicos acessados atravs do objeto Geolocation, este acessado atravs da instncia window.navigator.geolocation. A Figura 2.34 descreve cada um dos mtodos disponveis. O principal mtodo da API o getCurrentPosition, ele tenta obter a localizao do dispositivo, devolvendo-a de forma assncrona. Em caso de sucesso na obteno da localizao, o mtodo successCallback executado, recebendo este um objeto Position com a localizao do dispositivo. Por outro lado, se ocorrer algum erro, o mtodo errorCallback chamado, caso esteja presente (POPESCU, 2009). De acordo com Pilgrim (2010), com relao ao objeto Position devolvido obtido s existe a garantia de recebimento da latitude, longitude e acuracidade, alm do

95

timestamp, este sendo a data e hora em que a localizao foi obtida. Alguns valores deste objeto podem ser retornados como null devido as discrepncias que podem haver de um dispositivo para outro.

Fonte: Holdener (2011).

Figura 2.34: Mtodos do objeto Geolocation.

Um terceiro parmetro do mtodo getCurrentPosition o options, sendo este um objeto do tipo PositionOptions. Ele possui trs atributos: enableHighAccuracy, booleano indicando que a aplicao deseja receber a melhor localizao possvel, o que pode levar mais tempo e consumir mais energia; timeout, tempo mximo em milisegundos para obteno da localizao; e maximumAge, indicando que a aplicao est disposta a aceitar posies em cache do dispositivo, desde que elas no excedam o valor dado em milisegundos (POPESCU, 2009). Em caso de erros o mtodo errorCallback chamado, como fora descrito anteriormente. Neste caso, a funo dada para lidar com os erros recebe um objeto PositionError, este contendo os atributos: code, um inteiro contendo o cdigo do erro (1 = permisso negada, 2 = posio indisponvel, 3 = tempo mximo excedido) e message, uma string contendo uma descrio do erro (POPESCU, 2009). Diferentemente do mtodo getCurrentPosition, o mtodo watchPosition monitora a posio do dispositivo e a retorna atravs do succesCallback toda vez que a posio do dispositivo mudar, removendo a necessidade de o desenvolvedor criar um mecanismo de polling para vericar a mudana de posio (HOLDENER, 2011; POPESCU, 2009).

96

Fonte: Pilgrim (2010).

Figura 2.35: Mtodos do objeto Geolocation. O mtodo watchPosition recebe os mesmos mtodos que o getCurrentPosition, entretanto, a nica diferena est no valor retornado. Enquanto que este ltimo no retorna valor algum, o primeiro retorna um valor inteiro correspondendo que serve de identicao do watcher. Esta identicao ser importante para quando a aplicao desejar cancelar o o processo watcher criado, utilizando o mtodo clearWatch que recebe como parmetro a identicao do processo (watchId) (POPESCU, 2009). Apesar de ser uma API muito til para os desenvolvedores, existe entretanto um pequeno problema, nem todos os navegadores suportam ela. Isso verdadeiro principalmente quando se fala em navegadores em verses mais antigas (HOLDENER, 2011). Com esta restrio ca evidente a necessidade de algum mecanismo para detectar se a API de geolocalizao est disponvel no navegador do usurio ou no. A maneira mais simples de se fazer isso atravs do cdigo mostrado na Figura 2.36.

Fonte: Holdener (2011).

Figura 2.36: Vericando suporte a API de geolocalizao.

97

Outra alternativa para detectar a existncia, no apenas da, API de geolocalizao atravs da biblioteca Modernizr. Esta biblioteca open-source detecta o suporte do navegador a funcionalidades tanto do HTML5 como do CSS3, permitindo que desenvolvedores tirem proveito delas, quando suportadas, e quando no suportadas, utilizem implementaes alternativas ou simplesmente exibam uma mensagem para o usurio avisando sobre a ausncia de suporte (ATES, 2010). Nos casos em que o navegador no possui suporte a API de geolocalizao, existem algumas alternativas para obter (ou ao menos tentar) a localizao do dispositivo (HOLDENER, 2011). Uma destas alternativas o Gears (antigamente chamado de Google Gears), uma biblioteca que adiciona novas funcionalidades aos navegadores (dentre elas a geolocalizao). Em 11 de maro de 2011 o Google anunciou que no haveriam novas verses do Gears, entretanto, aplicaes ainda podem tirar proveito dos navegadores que do suporte ao Gears (HOLDENER, 2011). Alm do Gears, existem vrias outras APIs especcas desenvolvidas por fabricantes de dispositivos mveis, principalmente quando se tratam de plataformas mais antigas, que foram criadas antes da geolocalizao ganhar popularidade. Exemplos de plataformas que possuem (ao menos em verses antigas) APIs especcas para geolocalizao so: iOS, BlackBerry, Nokia e webOS. Agora, se o desenvolvedor de uma aplicao web deseja atingir o maior pblico possvel, ele teria de escrever cdigos especcos para a API da W3C, Gears e para cada uma das plataformas supracitadas (HOLDENER, 2011). Felizmente existe uma biblioteca para JavaScript que resolve este problema, a geo-location-javascript. Ela encapsula todas as implementaes especcas de geolocalizao em uma API nica similar a denida pela W3C. A nica desvantagem com relao a API da W3C com relao as funcionalidades fornecidas, sendo que esta permite apenas a obter a localizao e vericar se o dispositivo tem suporte a goelocalizao (HOLDENER, 2011). As plataformas suportadas pela biblioteca so:

98

iOS Android BlackBerry OS Gears Nokia Web Run-Time (WRT) webOS Application Platform (Palm) Torch Mobile Iris Browser Mozilla Geode

Como esta biblioteca possui um mtodo para vericar se h suporte a geolocalizao, na sua ausncia seria possvel ainda para o desenvolvedor utilizar algum mtodo alternativo para obter a localizao do usurio, como o endereo IP do dispositivo ou mesmo deixando o usurio informar a sua localizao.

2.3 ARQUITETURA DE SOFTWARE

Dentre os objetivos deste trabalho est o de construir o server-side da rede social, a parte responsvel por lidar com requisies de clientes atravs de uma API e respond-las em tempo hbil. Esta tarefa levanta questes como performance, segurana e escalabilidade, alm de outras questes chave a respeito do projeto e tecnologias que devero ser consideradas. Este o papel da arquitetura de software, assunto que ser abordado nesta seo (GORTON, 2011). Mas antes de entrar nos detalhes da arquitetura de software, preciso denir o que ela e qual o seu papel na construo de sistemas. Para Bass, Clements e Kazman (2003, seo 2.1), The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them .

99

A denio colocada acima deixa claro que um sistema pode ser composto de mais de uma estrutura, e a bem da verdade, na grande maioria dos casos ele o , sendo que uma estutura por si s no pode ser chamada de arquitetura com certeza absoluta. Estruturas so um conjunto de elementos arquiteturais e so representadas atravs de vises. Com relao aos elementos arquiteturais, Rozanski e Woods (2005) os denem como sendo peas fundamentais sobre as quais um sistema construdo e que devem possuir responsabilidades, fronteiras e interfaces bem denidas. Bass, Clements e Kazman (2003) dividem as estruturas de software em trs grupos:

Estruturas de mdulo: os elementos so mdulos e correspondem ao sistema na forma de cdigos-fonte e com responsabilidades denidas, mas no como o software em execuo, este sendo uma estrutura a parte. Aqui so consideradas as responsabilidades de cada mdulo, suas dependncias e relacionamentos com outros mdulos. Estruturas de componente-e-conector: so os componentes em tempo de execuo (unidades principais de computao) e conectores (meios de comunicao entre os componentes). O interesse neste grupo est voltado para, por exemplo, quais so os principais componentes em execuo e como eles interagem, principais data stores, replicaes de partes do sistema, e partes que executam ou podem executar em paralelo. Estruturas de alocao: mostra o relacionamento entre os elementos de software e os elementos do(s) ambiente(s) externo(s) onde o software criado e executado, como em que processador determinado elemento de software est sendo executado ou que arquivos esto sendo utilizados para o armazenamento dos dados do sistema.

Gorton (2011) tambm faz uma breve descrio destes trs grupos, mas ele se refere a eles como vises de arquitetura, e credita-os ao SEI (Software Engineering Institute), sendo que o estado atual deste segmento da engenharia de software evoluiu, segundo o autor, das ideias expressas no artigo de Philippe Krutchen de 1995,

100

Fonte: Bass, Clements e Kazman (2003, seo 2.5).

Figura 2.37: Estruturas comuns de uma arquitetura de software.

onde este autor denia quatro vises para a arquitetura de software: viso lgica, viso de processos, viso fsica e viso de desenvolvimento. A Figura 2.37 mostra os trs grupos de estruturas de software acima descritos e ainda decompe cada um dos grupos, exibindo as estruturas mais comuns em softwares. Estruturas relacionadas a mdulos incluem decomposio, onde mdulos so decompostos em sub-mdulos; uses, onde mdulos so relacionados atravs da denio de quem utiliza quem para funcionar; layered, com mdulos organizados em camadas de acordo com as funcionalidades desempenhadas; e classe ou generalizao, onde as unidades de mdulo so chamados de classes e os relacionamentos so denidos atravs de instncias de uma classe e classes que so herdeiras de outras classes (BASS; CLEMENTS; KAZMAN, 2003). Ainda reetindo sobre a denio dada acima sobre arquitetura de software, ela diz respeito a estruturas, estas detalhadas acima, que so compostas por elementos. Mas para uma arquitetura o que interessa so as propriedades externas destes elementos, ou seja, tudo aquilo que caracterstico de um elemento e que inuencia outros elementos, e.g. servios fornecidos, desempenho oferecido e tratamento de erros. Esta inuencia desempenhada atravs de interaes, sendo que estas ocorrem

101

geralmente por intermdio de interfaces pblicas. Enquanto que detalhes privados so assim denidos exatamente por no serem de interesse de outros elementos (BASS; CLEMENTS; KAZMAN, 2003). Estes conceitos que denem o que arquitetura de software tambm so citados por Gorton (2011), dando nfase a estruturas compostas por componentes e suas interfaces de comunicao, sendo que esta ltima caracterstica tem papel fundamental na qualidade de uma arquitetura, isso porque quanto menores forem as dependncias entre os componentes, menor ser a propagao de modicaes ao longo da arquitetura, e consequentemente, menor a quantidade de modicaes nos testes do sistema e maiores as chances de sucesso no desenvolvimento de aplicativos com vrias equipes trabalhando concorrentemente em diferentes componentes ou mdulos do sistema. J Rozanski e Woods (2005) empregam uma abordagem um pouco diferente das anteriores para detalhar a descrio de arquitetura de software. O autor, atravs da descrio dada pelo SEI (muito semelhante a descrio citada acima, de Bass, Clements e Kazman (2003)), destaca as estruturas e as propriedades externas e visveis do sistema, divindido a primeira em estruturas estticas e dinmicas e a segunda em comportamento visvel externo e propriedades de qualidade. Segundo esta decomposio, a arquitetura de software se preocupa com as estruturas internas de um sistema, como mdulos, classes, packages, servios ou qualquer outra unidade de cdigo, assim como as estruturas de mdulo; bem como com as estruturas dinmicas de um sistema, que so os elementos existentes em tempo de execuo e suas interaes. Com relao as propriedades do sistema, a preocupao est tanto com o uxo de informaes do sistema com o ambiente externo, o comportamento que o sistema desenvolve de acordo com os estimulos recebidos, os contratos rmados atravs das interfaces; como com as propriedades de qualidade do sistema, estas detalhadas na seo a seguir. Mas para qu gastar recursos de um projeto criando uma arquitetura?

102

Em primeiro lugar, Rozanski e Woods (2005) e Bass, Clements e Kazman (2003) armam que qualquer sistema de computador possui uma arquitetura, independentemente de ela estar ou no documentada e ser compreendida. Ou seja, s porque no existe uma descrio formal ou diagramas ilustrando a arquitetura de um sistema, no quer dizer que ela no exista, o que no h, entretanto, uma representao desta. Querendo ou no, a arquitetura estar l, e nas palavras de Eoin Woods apud Gorton (2011, p. 11), software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled , portanto, desejvel ter uma boa arquitetura, ou como Bass, Clements e Kazman (2003) armam, bom ter uma arquitetura que esteja de acordo com o propsito do projeto. Mesmo que Bass, Clements e Kazman (2003) neguem a existncia de arquiteturas boas ou ruins, eles fazem uma lista de recomendaes de processo e produto que podem ser seguidas no desenvolvimento uma arquitetura. De forma resumida, a equipe encarregada do desenvolvimento da arquitetura deve estar comprometida, com a lista de requisitos bem denidos e organizados, os stakeholders devem estar envolvidos no processo de desenvolvimento da arquitetura, este processo pode ainda gerar uma arquitetura de forma incremental, utilizando mtricas para medir e avaliar os atributos de qualidade da mesma, alm de gerar uma boa documentao ao nal. J com relao ao produto, uma das recomendaes diz respeito a criao de uma arquitetura com mdulos bem denidos e com uma boa separao das responsabilidades, questo tambm levantada por Gorton (2011), quando ele faz meno ao resposibility-driven design, tcnica da orientao a objetos que pode ser utilizada para denir os componentes chave da arquitetura. Bass, Clements e Kazman (2003) seguem em frente com as recomendaes, salientando a importncia do encapsulamento das interfaces dos mdulos, aspecto comentado anteriormente. Alm disto, arquiteturas devem contemplar os atributos de qualidade levantados nos requisitos do sistema atravs de tticas especcas. No nal, uma arquitetura de software ir auxiliar na comunicao com os stakeholders, permitindo a compreenso do sistema por todos (ou quase todos), j que se trata de um modelo abstrato. Como fora mencionado anteriormente, a arquitetura

103

pode ser decisiva no sucesso de um projeto, isso porque atravs dela que as primeiras decises a respeito do projeto do sistema so tomadas e estas decises so fundamentais para todas as etapas subsequentes. E um dos aspectos interessantes de uma arquitetura, devido a sua natureza abstrata, a possibilidade de transferi-la para outros sistemas com caractersticas semelhantes (BASS; CLEMENTS; KAZMAN, 2003). A idia de reutilizar arquiteturas pode ser recompensadora, se bem utilizada, pois trata-se do uso de arquiteturas j aplicadas e testadas na soluo de certas classes de problemas, para Gorton (2011), um dos grandes valores dos padres de arquitetura.

Fonte: Bass, Clements e Kazman (2003, seo 2.3).

Figura 2.38: Relacionamento entre modelos de referncia, padres de arquitetura, arquiteturas de referncia e arquiteturas de software. Bass, Clements e Kazman (2003) vo alm e denem, alm dos padres de arquitetura, modelos de referncia e arquiteturas de referncia, colocando-os como conceitos teis que capturam elementos de uma arquitetura, mas que no so arquiteturas por si s. A Figura 2.38 mostra o relacionamento entre estes elementos que podem compor uma arquitetura de software. Padres de arquitetura so representaes abstratas de uma arquitetura e podem ser implementadas de vrias formas, segundo Gorton (2011). J Bass, Clements e Kazman (2003) denem padres como uma descrio de elementos e os tipos de relacionamentos deles juntamente com um conjunto de restries que viro a formar a arquitetura. Paralelo aos padres, esto os modelos de referncia, uma diviso das funcionalidades em partes e o uxo de dados entre estas partes que descreve como elas se relacionam para atingir um objetivo. Juntos, estes dois elementos compe a

104

arquitetura de referncia, que o mapeamento do modelo de referncia em elementos de software e os uxos de dados entre eles (BASS; CLEMENTS; KAZMAN, 2003). Nas sees a seguir os atributos de qualidade, to falados nesta seo, sero descritos em detalhes, bem como os prncipios que regem arquiteturas de software, alguns dos patterns mais conhecidos e utilizados e por m dando ateno para algumas das arquiteturas de software mais conhecidas atualmente.

2.3.1 Atributos de Qualidade

Os atributos de qualidade fazem parte dos requisitos no funcionais de um sistema, e descrevem como os requisitos funcionais devem ser obtidos. Esta descrio deve ser precisa com relao a como a aplicao deve atingir determinada necessidade (GORTON, 2011). Para Bass, Clements e Kazman (2003) um dos principais motivos que levam ao redesenho de um sistema a decincia em algum atributo de qualidade, e.g. a diculdade de realizar manutenes, portar o sistema, escalar ou por ele ser muito lento. Como fora dito anteriormente, a criao de uma arquitetura muito importante para as fases subsequentes de um projeto, e levar em considerao os atributos de qualidade nesta fase muito importante. Apesar de os atributos de qualidade descreverem como os requisitos funcionais ou funcionalidades devem ser obtidos, estes ltimos no costumam ter inuncia no primeiro, exceto em casos extremos. Ou seja, as funcionalidades escolhidas para um sistema no inuenciam os atributos de qualidade do mesmo, pois estes so obtidos atravs das decises tomadas com relao a arquitetura. A funcionalidade se preocupa apenas com a execuo das tarefas para as quais o sistema fora projetado (BASS; CLEMENTS; KAZMAN, 2003). Se os nicos requisitos importantes em um sistema fossem as funcionalidades, ele poderia ser construdo como um bloco nico de cdigo, sem estrutura alguma, como Bass, Clements e Kazman (2003) explicam. Isso no feito (normalmente) por-

105

que existem outros requisitos que devem ser contemplados. No por acaso que muitas aplicaes so divididas em mdulos e cada um deles est organizado em vrias estruturas com responsabilidades bem denidas, pois caractersticas como estas permitem que vrias equipes trabalhem no desenvolvimento do sistema e o uso de padres de projeto torna a compreenso do sistema, como um todo, mais fcil. Ento, a arquitetura de um sistema o ponto inicial para se pensar nos atributos de qualidade, mas a responsabilidade sobre a qualidade no recai totalmente sobre ela. O que a arquitetura faz prover as fundaes para a construo de um sistema que esteja em conformidade com estes requisitos, objetivo que s ser atingido se devida ateno for prestada aos detalhes do sistema. No se pode esperar uma boa performance ou manutenibilidade de uma aplicao, por exemplo, que apesar de possuir uma arquitetura bem planejada, foi implementada sem o conhecimento das melhores prticas da linguagem de programao escolhida (BASS; CLEMENTS; KAZMAN, 2003). E se no bastasse o esforo necessrio atravs de todas as fases do projeto para a obteno dos atributos de qualidade desejados, preciso levar em conta que em muitos dos casos os atributos so conitantes, criando os conhecidos trade-offs. Em outras palavras, em algum momento do projeto (antes que seja tarde demais), talvez seja preciso escolher um dos atributos em detrimento de outro. Bass, Clements e Kazman (2003) do como exemplo a segurana e a conabilidade, onde um sistema seguro tem a menor quantidade de pontos de falha, enquanto que sistemas conveis possuem o mximo possvel de pontos de falha, atravs de replicaes de partes do sistema ou infraestrutura, como mais de um servidor ou a replicao do bancos de dados. Bass, Clements e Kazman (2003) ainda se preocupam em dividir os atributos de qualidade em qualidade do sistema, do negcio e da arquitetura. Seria possvel ainda utilizar a classicao feita pela Associao Brasileira de Normas Tcnicas (2003), onde os requisitos de qualidade podem ser de um ponto de vista interno ou externo. Nas prximas sees os principais atributos, de acordo com os autores pesquisados, sero abordados, sem, entretanto, fazer distino com relao a classica-

106

o.

2.3.1.1 Performance

Para Gorton (2011), o requisito de performance descreve uma mtrica que dene a quantidade de trabalho que uma aplicao deve realizar em determinado tempo ou at determinado tempo para estar em conformidade. Obviamente, diferentes aplicaes tero requisitos diferentes de performance, havendo diferenas gigantescas entre aplicaes utilizadas por supermercados e aplicaes utilizadas em avies ou robs. Gorton (2011) ainda decompe a performance em throughput, tempo de resposta e prazo de entrega. Throughput a quantidade de trabalho que um sistema desempenha em alguma unidade de tempo, normalmente transaes por segundo (tps), requisies por segundo (rps) ou mensagens por segundo (mps). importante salientar, entretanto, que esta medida pode representar tanto uma mdia de um perodo ou um valor de pico. Detalhes assim podem esconder a situao real de um sistema (caso tenha sido implementado) ou induzir os desenvolvedores ao erro. Shaw (2012) critica, por exemplo, o uso de apenas mdias para vericar o desempenho de uma aplicao, armando que duas mdias idnticas podem esconder desvios padres completamente diferentes, como o caso da Figura 2.39, onde o autor criou dois conjuntos de 100 amostras aleatrias. Ambos conjuntos tem mdia 30, entretanto, o conjunto em azul possui desvio padro de 5.56, j no laranjado o valor sobre para 19.09. O autor coloca que, se este exemplo representasse dois servidores web, o laranjado estaria com graves problemas de conabilidade e os usurios perceb-lo como sendo muito mais lento que o azul. Esta percepo de lentido signica que o sistema est apresentando um tempo de resposta muito alto. Gorton (2011) descreve o tempo de resposta como a medida da latncia que uma aplicao demonstra ao processar uma transao. Fica evidente que quanto menor o tempo de resposta, melhor, e isso vale tanto para o

107

negcio como para os clientes. Requisitos de tempo de resposta de um sistema podem exigir que o sistema atenda todas as requisies dentro de um tempo limite, sem excees, algo conhecido por tempo de resposta garantida. Requisitos no to exigentes podem especicar uma latncia mdia ou que determinada porcentagem das requisies sejam atendidas dentro dos parmetros especicados.

Fonte: Shaw (2012).

Figura 2.39: Tempos de resposta hipotticos com a mesma mdia. Por m, a performance de um sistema pode dizer respeito ao prazo de entrega, atributo geralmente associado a sistemas de processamento em lotes. Se uma informao precisa estar disponvel em determinada data ou se determinada transao precisa ser processada at uma data limite, o sistema estar adequado a estes requisitos (GORTON, 2011). Em comum, o que todas estas medidas tem o fato de que no se pode generaliz-las, no sentido de que simplesmente descreve um requisito exigindo 300 requisies por segundo, por exemplo, no suciente. preciso ser exato na descrio de quanta carga o sistema dever enfrentar no ambiente de produo, para que

108

uma arquitetura adequada seja criada (GORTON, 2011).

2.3.1.2 Escalabilidade

Citando Gorton (2011, p. 27), escalabilidade dene: How well a solution to some problem will work when the size of the problem increases . Por exemplo, como o sistema ir se comportar se o nmero de usurios aumentar em 50%. Se existe uma estimativa do crescimento da aplicao, este requisito precisa ser expresso para que seja levado em conta quando na criao da arquitetura e subsequentes fases do projeto. Para Liu (2009) no faz sentido falar em escalabilidade se um sistema no tem boa performance, muito embora um sistema possa ter boa performance mas no escalar. Existem casos onde um sistema pode ver sua performance ser deteriorada na medida que a carga vai aumentando, antes mesmo de atingir a carga mxima para a qual fora planejado. Para o autor, este tipo de problema de escalabilidade pode ser superado atravs de otimizaes e modicaes do sistema. Um sistema escalvel deve, portanto, manter a performance constante em vista do aumento da carga at o limite planejado. Em um cenrio mais desfavorvel, um sistema no apenas tem sua performance deteriorada com o aumento da carga como tambm ela passa a ser inaceitvel e o software no demonstra melhora com a atualizao ou adio de hardware, sendo considerado um software que no escala. Nestes casos, modicaes na arquitetura do sistema so necessrias, tarefa arriscada, pois pode consumir muito tempo e recursos, algo que poderia ter sido evitado com um melhor planejamento da arquitetura do sistema (LIU, 2009). Dentro de um sistema, vrios de seus aspectos podem crescer com o tempo. Gorton (2011) menciona a carga de requisio, conexes simultneas e tamanho dos dados. Em um sistema que suporta, por exemplo, 100 tps em carga de pico, tendo

109

como tempo de resposta 1s, como ele iria se comportar se a carga de requisio aumentasse em dez vezes? Gorton (2011) explica que em um mundo perfeito, o throughput permaneceria constante, enquanto que o tempo de resposta iria aumentar linearmente (para 10s). E uma soluo escalvel seria adicionar capacidade de processamento, reduzindo o tempo de resposta e aumentado o throughput. Na prtica, com o aumento da carga o throughput da aplicao iria cair e o tempo de resposta iria aumentar de forma exponencial, isso porque o aumento de carga signica o aumento no uso de recursos como CPU e memria, alm de recursos adicionais que podem car escassos e limitar a escalabilidade. Escalar um sistema pode signicar escalar para cima (scale up ou escalar na vertical) ou para os lados (scale out ou escalar na horizontal). Escalar para cima pode signicar adicionar mais CPUs, enquanto que escalar para os lados pode signicar adicionar mais mquinas para a execuo da aplicao. Aplicaes que tiram vantagem de multithreading ou que podem rodar vrias instncias single threaded so adequadar para escalarem para cima, dando ateno especial para aplicaes de mltiplas instncias, j que estas tendem a consumir muitos recursos. J ao escalar um sistema para os lados signica que a carga de requisio ser distribuda atravs de um load balancer atravs das mquinas disponveis (GORTON, 2011). Henderson (2006) arma que ao escalar na vertical no h necessidade de se preocupar com as requisies dos usurios. Para demonstrar isto ele cita como exemplo o web server Apache, que, por ser multiprocesso, pode colocar um processo lho em cada processador e atender vrias requisies em paralelo, e o melhor que o balanceamento da carga entre os processadores feito pelo sistema operacional. Ao escalar horizontalmente, entretanto, no existe um sistema operacional para realizar o balanceamento da carga entre os servidores. Nestes casos, existem alguns mtodos colocados por Henderson (2006) e que, como mencionado anteriormente, so chamados de load balancers. Uma das opes para balancear carga atravs do DNS, criando mais de um registro A para a zona DNS do domnio da aplicao, fazendo com que o servidor DNS retorne ao browser do usurio todos estes registros onde sero feitas tentativas comeando pelo primeiro registro da lista. O

110

autor arma que apesar de ser de longe a forma mais fcil de se implementar balanceamento de carga, ela apresenta muitos problemas e decincias, como o fato de este mtodo ignorar redundncias e failover, alm dos problemas que o cache de DNS podem causar. Felizmente existem duas alternativas para load balancers, uma atravs de hardware e outra atravs de software. A alternativa em hardware consiste na aquisio de um dispositivo dedicado a tarefa de balanceamento de carga, que geralmente tem um custo elevado e nem sempre so de simples congurao. Por outro lado, eles no possuem as decincias encontradas na primeira alternativa. Uma terceira alternativa o uso de software para balancear a carga que, ao contrrio dos load balancers via hardware, no tem um custo elevado e desempenham as mesmas tarefas esperadas para um balanceador de carga (HENDERSON, 2006). Henderson (2006) ainda divide os balanceadores de carga em camadas 4 e 7. Balanceadores da camada 4 olham apenas para os endereos IP e portas da origem e destino da requisio. Geralmente estes balanceadores fazem uso do algoritmo round robin para balancear a carga, onde existe uma lista de servidores que podem servir a requisio e o algoritmo apenas escolhe o prximo da lista. Existem ainda algoritmos que designam requisies para os servidores com menor nmero de conexes, no sobrecarregando desta forma servidores que j esto servindo um grande nmero de requisies. Diferente dos balanceadores da camada 4, os da camada 7 examinam toda a requisio, inclusive a prpria requisio HTTP, permitindo o uso dos cabealhos como parte do balanceamento de carga. O mais comum neste tipo de balanceador de carga o uso da URL para fazer o balanceamento, designando um recurso especco para um nico servidor. Isso pode ser feito tanto com o uso de um ndice como pelo uso de uma hash table. Tal estrutura pode, em um primeiro momento, no fazer muito sentido, como Henderson (2006) coloca. Entretanto, em uma congurao como a mostrada na Figura 2.40, faz sentido que um nico servidor seja responsvel por servir determinados recursos, pois isso reduz a chance de redundncia de dados no cache, maximizando o uso do cache e aumentando a taxa de acertos do cache (cache hit

111

ratio).

Fonte: Shaw (2012).

Figura 2.40: Balanceador de carga e cache farm.

Alm das questes acima colocadas, a escalabilidade pode ainda estar relacionada com a quantidade de conexes simultneas que um sistema suporta, por exemplo, e como ele ir se comportar quando este nmero aumentar. Ou como uma aplicao lida com o aumento do tamanho dos dados que so trafgados ou que precisam ser recuperados de um repositrio e processados. Alm destas questes existem muitas outras que talvez precisem ser levadas em conta antes de comear a desenhar uma arquitetura, para que no futuro no sejam necessrias modicaes proibitivas na estrutura fundamental do sistema, algo que pode custar muito caro (GORTON, 2011).

112

2.3.1.3 Modicabilidade

Se existe uma coisa que certa a respeito de um software, que ele ser modicado uma hora ou outra, sem excees. Portanto, faz sentido levar em conta esta premissa na hora de planejar e criar a arquitetura. A modicabilidade de um sistema, de acordo com Gorton (2011), a medida de quo fcil pode ser a modicao de uma aplicao para acomodar novos requisitos, funcionais ou no. Mas esta medida meramente uma estimativa do esforo ou custo necessrio para realizar a modicao, isso porque s haver certeza quando a modicao for de fato realizada. Muitos projetos incluem entre suas tarefas a criao de uma lista de modicaes futuras para uma aplicao, reetindo a viso de longo prazo que a equipe tem do projeto em desenvolvimento e permitindo que uma arquitetura adequada seja produzida. O objetivo de prever ou estimar possveis modicaes em um sistema, em conjunto com a arquitetura j produzida, o de criar estimativas de impacto das modicaes na arquitetura bem como o custo destas modicaes (GORTON, 2011). Prever algo geralmente implica em aes proativas, ou seja, se foram previstas modicaes no sistema ainda na fase de criao da arquitetura, esta pode ser desenhada de forma a acomodar tais modicaes com o mnimo de impacto possvel. Infelizmente, as coisas no funcionam perfeitamente e previses nem sempre so acuradas. Isso signica que ao planejar uma arquitetura com modicabilidade em mente, preciso o fazer com cuidado. Questes como estas podem levar o sistema a ser conhecido como over engineered, ou seja, um sistema onde foram investidos mais esforos do que o necessrio (GORTON, 2011). Esses esforos exagerados podem ser expressos na forma de arquiteturas que possuem componentes extremamente independentes (altamente modulares) e de fcil modicao. E muito embora estas caractersticas possam ser interessantes e muitas vezes desejveis, existem limites, pois assim como elas carregam benefcios, problemas como alta complexidade, perda de performance e alta demanda de esforos costumam acompanh-las (GORTON, 2011).

113

Gorton (2011) arma, portanto, que o caminho consiste em no se deixar levar somente pelo desenho de uma arquitetura, mas tambm levar em conta os requisitos, quem sabe utilizando alguma metodologia gil, melhorando e aperfeioando a arquitetura a cada iterao, e mantendo uma comunicao constante com os stakeholders.

2.3.1.4 Segurana

Para Bass, Clements e Kazman (2003), segurana compreende a medida da capacidade de um sistema permitir que apenas usurios autorizados acessem os servios fornecidos. No nvel arquitetural isso est relacionado com os requisitos de segurana e os mecanismos que sero utilizados para atend-los (GORTON, 2011). Gorton (2011) e Bass, Clements e Kazman (2003) listam alguns dos requisitos mais comuns relacionados com segurana, sendo eles:

Autenticao: vericao da identidade dos usurios e outras aplicaes com as quais o sistema se comunica. Autorizao: so os nveis de acesso que usurios e aplicaes possuem, estes denindo que recursos do sistema podem ou no ser acessados por eles. Encriptao: mensagens enviadas ou recebidas pela aplicao so encriptadas. Integridade: visa garantir que o contedo de uma mensagem no foi alterado durante a transmisso. No-repudiao: garante que nenhuma das partes em uma transao pode negar a ao realizada. Condencialidade: proteo contra acesso no autorizado. Auditoria: o sistema mantm registros de todas as atividades nele realizadas, permitindo a futura consulta dos mesmos.

Na Internet, por exemplo, possvel fazer uso de tecnologias como SSL (Secure Socket Layer ) ou PKI (Public Key Infrastructure) para provr autenticao, en-

114

criptao e no-repudiao. Aplicaes em .NET podem tirar vantagem das funcionalidades de segurana do Windows e aplicaes Java possuem o JAAS (Java Authentication and Authorization Service) (GORTON, 2011). Mais detalhes a respeito da autenticao de usurios e aplicaes sero dados na seo 2.5.4, focando especicamente a autenticao atravs da Internet com HTTP e OAuth.

2.3.1.5 Avaliabilidade

A avaliabilidade est relacionada conabilidade de um sistema, e diz respeito falhas que possam ocorrer com ele e suas consequncias. Uma falha ocorre quando um sistema deixa de entregar um servio da forma especicada e isto se torna visvel ao usurio, seja ele uma pessoa ou outro sistema (GORTON, 2011; BASS; CLEMENTS; KAZMAN, 2003). Bass, Clements e Kazman (2003) colocam entre as preocupaes com relao a avaliabilidade, como uma falha no sistema detectada, com que frequncia falhas ocorrem, o que acontece quando uma falha ocorre, quanto tempo o sistema pode car fora de servio, como falhas podem ser prevenidas e que tipos de noticaes so necessrias para quando uma falha ocorrer. Algumas destas questes podem ser relacionadas com mtricas utilizadas para medir alguns aspectos da avaliabilidade de um sistema. IEEE (1996) e IEEE (2006) possuem uma grande quantidade de mtricas que podem ser utilizadas para assegurar conabilidade de softwares. Uma das mtricas mais bsicas, utilizada para o clculo de vrias outras, o tempo mdia para falhas (mean time to failure ou MTTF), que indica o tempo mdio entre as falhas em um sistema. Para Vogel et al. (2011) existem duas opes para se atingir uma melhor avaliabilidade do sistema: reduzir a frequncia das falhas e reduzir o tempo de recuperao de falhas. Em outras palavras, falhe pouco e quando falhar, recupere-se rapidamente. E estas duas opes possuem ainda mtricas para represent-las, para a primeira

115

opo o MTTF, j comentado no pargrafo anterior, e para a segunda opo existe a mtrica de tempo mdio para reparo (mean time to repair ou MTTR) (IEEE, 2006).

Availabilidade =

MT T F MT T F + MT T R

(2.4)

Juntas, estas duas mtricas podem ser utilizadas para calcular a avaliabilidade do sistema, mtrica obtida atravs da Frmula 2.4. Para uma aplicao apresentar alta avaliabilidade uma das medidas que pode ser tomada a replicao de componentes do sistema, eliminando assim os pontos nicos de falha (single points of failure ou SPOF) (GORTON, 2011). Um SPOF quando h no sistema apenas uma instncia de um componente e quando este componente falhar, e um dia ele ir, o sistema poder car indisponvel. Para Abbott e Fisher (2011), qualquer componente em um sistema pode ser um SPOF, desde um nico web server ou um nico dispositivo de rede, mas geralmente ele o banco dados, devido a maior diculdade em escal-lo atravs de vrios ns. Maiores detalhes sobre bancos de dados podem ser vistos na seo 2.4. Para Gorton (2011) existe uma estreita relao entre avaliabilidade e recuperabilidade, j que esta ltima olha para a capacidade de uma aplicao reestabelecer nveis de desempenho exigidos e recuperar dados afetados. Para melhorar a capacidade de recuperao de uma aplicao, esta deve possuir mecanismos ecientes para deteco de falhas, bem como se armar de todo e qualquer meio que permita a recuperao automtica do sistema, reduzindo por conseguinte o tempo de recuperao.

2.3.1.6 Outros Atributos

Alm dos atributos de qualidade acima discutidos, existem muitos outros atributos (o modelo de qualidade da Associao Brasileira de Normas Tcnicas (2003) descreve vrios atributos de qualidade). A ideia aqui foi dar um resumo dos principais

116

atributos e como eles podem inuenciar a criao de uma arquitetura de software. Algumas projetos de software podem precisar se preocupar ainda com a portabilidade de um sistema, a capacidade de testar este sistema, integr-lo com outros sistemas atravs de compartilhamento de dados ou de uma API (ver 2.5), usabilidade da interface com o usurio ou capacidade de reutilizar componentes desenvolvidos (GORTON, 2011). interessante notar ainda que existem outros atributos, os do negcio, e eles so to importantes quanto os atributos diretamente relacionados com o sistema, pois de uma forma ou outra eles inuenciam a arquitetura nal do sistema. Por exemplo, o atributo time to market pode ter grande inuencia em uma aplicao, determinando na fase de modelagem da arquitetura se vale a pena construir determinado componente ou utilizar um componente de terceiro. Outras questes como custo/benefcio podem determinar quais tecnologias fazem mais sentido, considerando os recursos disponveis para o projeto Bass, Clements e Kazman (2003).

2.3.2 Princpios

Na seo anterior foram apresentados os atributos de qualidade que uma arquitetura pode ter. Nesta seo e nas sees seguintes sero apresentados os meios da arquitetura, que do suporte para a construo da arquitetura de um software.

Fonte: Vogel et al. (2011, p. 117).

Figura 2.41: Inuncias dos meios de uma arquitetura.

117

Cada um destes meios possui um nvel de inuncia sobre a arquitetura, como mostra a Figura 2.41, e quanto maior a inuncia, mais concreta ser a sua especicao. Isso porque, enquanto os princpios de arquitetura apresentam diretrizes comprovadamente efetivas que devem ser seguidas, elas nada dizem sobre como implement-las, ao contrrio das arquiteturas de referncia, que indicam com maior clareza como uma arquitetura deve ser (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Como fora explicado na introduo a Arquitetura de Software, no existem arquiteturas boas e ruins, segundo Vogel et al. (2011) o que existem so variaes dos atributos de qualidade de um sistema. Entretanto, existem princpios gerais que devem ser considerados na hora de projetar uma arquitetura, eles procuram lidar com algumas questes e problemas recorrentes em arquiteturas de software, com destaque para: reduo da complexidade de uma arquitetura e aumento da exibilidade (ou modicabilidade) de uma arquitetura. A Figura 2.42 ilustra o relacionamento entre os princpios bsicos em arquiteturas de software. Nas sees abaixo cada um deles ser apresentado, juntamente com os princpios que deles derivam.

2.3.2.1 Baixo Acoplamento

A arquitetura de software se preocupa, em primeiro lugar, com os blocos de construo (building blocks) que a formam, e.g. mdulos, componentes, classes ou procedimentos, e com os relacionamentos existentes entre estes blocos, conhecido como acoplamento (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Albin (2003) dene acoplamento como as conexes entre dois mdulos, ou de modo mais generalizado, entre os blocos de construo. O acomplamento de uma classe, por exemplo, pode ser determinado atravs da determinao do nmero de classes com quem ela se relaciona. importante notar, entretanto, que o relacionamento entre classes ou qualquer outro bloco de construo no precisa ser explcito, isso signica que existem vrios tipos de relacionamentos e cada um deles carrega

118

Fonte: Vogel et al. (2011, p. 119).

Figura 2.42: Inuncias dos meios de uma arquitetura.

um peso diferente (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). O princpio do baixo acomplamento (loose coupling) arma que o acomplamento entre os blocos de construo de um sistema devem ser mantidos o mais baixo possvel. A consequncia disto uma arquitetura com estruturas de baixa complexidade, facilitando a compreenso dos blocos de construo, e por conseguinte, facilitando a modicao destes sem a necessidade de conhecer vrios outros blocos ao mesmo tempo. Outra consequncia do baixo acomplamento a reduo da propagao de mudanas pela arquitetura, ou seja, a mudana em um bloco de construo tem menor chance de afetar outros blocos do sistema (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Atravs do baixo acoplamento, possvel ainda alcanar princpios como pro-

119

jetar para mudana e alta coeso. Este ltimo alcanado atravs da reduo dos relacionamentos entre os blocos de construo, reduzindo o acoplamento, e aumentando as conexes dentro de um bloco. Existem ainda outros princpios que podem ser usados para se obter uma arquitetura com baixo acoplamento. Por exemplo, atravs de interfaces de abstrao possvel separar a interface da implementao e ocultar as informaes atrs destas interfaces. Reduzindo ao mximo a quantidade de interfaces e a frequncia com que trocas de informaes so feitas seria possvel reduzir tambm o acoplamento do sistema (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Dentro do princpio de baixo acoplamento existem ainda dois princpios derivados. Um deles a Lei de Demtrio, ela arma que um bloco de construo deve apenas utilizar blocos intimamente relacionados a ele ("no fale com estranhos") (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). O slogan deste princpio "Fale apenas com seus amigos", sendo este posteriormente renado para "Fale apenas com seus amigos que compartilham suas preocupaes", sendo esta ltima chamada de Law of Demeter for Concerns (LoDC). A melhor forma de se seguir esta lei atravs do Desenvolvimento de Software Orientada a Aspecto (Aspect-Oriented Software Development ou AOSD). Ultimamente, seguir esta lei (ou princpio) melhora o ocultamento de informaes dos blocos de construo e diminui a carga de informaes sobre o desenvolvedor, j que a quantidade de informaes externas ao bloco ser limitada (LIEBERHERR, 2012). O outro princpio derivado o de evitar dependncias circulares entre os blocos de construo de um sistema. Dependncias circulares signicam que o sistema est altamente acoplado e para compreender um dos blocos preciso compreender todos os blocos envolvidos no ciclo, sem contar nos problemas que podem ocorrer, como deadlocks e diculdade de modicao (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Para evitar dependncias circulares possvel seguir outro princpio, o Princpio de Hollywood: "no nos chame, ns chamaremos voc". Este princpio tambm conhecido como Inverso de Controle (Inversion of Control ou IoC) e visa redu-

120

zir o acomplamento entre blocos. Duas aplicaes deste princpio so a Inverso de Dependncia (Dependency Inversion) e a Injeo de Dependncia (Dependency Injection). A primeira delas aplica a inverso de controle atravs de uma interface pela qual um bloco de construo ir se comunicar, enquanto que outros blocos de construo sero responsveis pela sua implementao e instanciao. A injeo de dependncia d um passo a frente na aplicao da inverso de controle, transferindo a responsabilidade de criar e ligar os blocos de construo para um framework de congurao externa (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

2.3.2.2 Alta Coeso

Enquanto que o acomplamento diz respeito as dependncias entre diferentes blocos de construo de uma arquitetura, a coeso se preocupa com as dependncias existentes internamente em um bloco, j que este tambm pode ser dividido em partes. Quanto maior a independncia de um bloco, semnticamente, maior ser a sua coeso, e por consequncia, menor o seu acoplamento (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Se uma classe vem a ser um bloco de construo, por exemplo, medir a coeso deste bloco signica contabilizar a quantidade de chamadas feitas entre os membros desta classe. Entretanto, somente o fato de uma classe realizar muitas chamadas a outros membros semelhantes no signica que ela tenha alta coeso. Alta coeso signica que o bloco est corretamente organizado semanticamente, permitindo que ele seja compreendido por completo, sem a necessidade de consultar outros blocos de construo (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). A alta coeso pode ser obtida atravs da abstrao, separao de responsabilidades e ocultamento de informaes. O agrupamento de requisitos relacionados tambm podem aumentar a coeso, j que h uma tendncia de que requisitos relacionados se comuniquem com muita frequncia. Por m, um bloco de construo com alta coeso pode ser considerado como uma caixa preta que pode ser modicada, trocada e reutilizada independentemente dos outros blocos que com ela se comunicam (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

121

2.3.2.3 Projetar para Mudana

Este princpio est intimamente relacionado com o atributo de qualidade da modicabilidade de um sistema, inclusive no que diz respeito aos trade-offs enfrentados. Projetar para a mudana leva em conta o fato de que softwares esto constantemente mudando e estas diculdades so difceis de prever, mas ainda assim, algumas arquiteturas lidam melhor com mudanas (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Projetar para a mudana busca prever mudanas e criar uma arquitetura capaz de suportar futuramente estas e outras provveis mudanas. O problema aqui so as mudanas que no foram previstas. Muitas vezes a soluo mais atraente a criao de uma arquitetura altamente exvel, entretanto, preciso levar em conta que tal arquitetura pode estar sendo projetada para mudanas que nunca viro a ocorrer, sem contar nos esforos incorridos, alta complexidade da arquitetura e baixo desempenho oferecido (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). O ponto de equilbrio est em projetar uma arquitetura levando em conta apenas mudanas que possivelmente podero ocorrer. Lugares modicados com frequncia e/ou que so pontos de encontro de vrios aspectos de uma arquitetura geralmente so bons candidatos a possveis mudanas, sendo ainda conhecidos como os hot spots de uma arquitetura (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Projetar para mudana pode ser alcanado com o uso do princpio do baixo acomplamento, e.g. arquiteturas orientadas a servio (SOA) ou programao orientada a aspecto. Princpios como abstrao, modularidade, separao de responsabilidades e ocultamento de informaes tambm podem auxiliar na criao de uma arquitetura projetada para comportar mudanas (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

122

2.3.2.4 Separao de Responsabilidades

Quando um problema possui uma complexidade relativamente alta, lidar com ele como um todo pode ser difcil, entretanto, se este problema for dividido em partes menores, ele pode se tornar gerencivel. Este princpio conhecido como dividir e conquistar. Em arquitetura de software este princpio utilizado para quebrar um sistema em uma estrutura de blocos de construo (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). atravs da separao de responsabilidades que a modularidade de um sistema pode ser obtida, separandoo cada uma das responsabilidades, aspectos ou tarefas em blocos de construo separados. Isso signica que a arquitetura pode ser compreendida com maior facilidade, e j que estas partes do sistema so relativamente independentes (baixo acoplamento), possvel que vrios desenvolvedores trabalhem em paralelo em diferenes partes (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). A decomposio de um sistema geralmente feita atravs dos requisitos funcionais do mesmo, onde cada bloco de construo preenche uma funcionalidade especca. A identicao de partes que podem ser reutilizadas tambm pode ser utilizada como critrio. Ainda assim, existem outras dimenses que precisam ser levadas em conta na hora de decompor um sistema, como performance, usabilidade e segurana, aspectos que fazem parte dos requisitos no funcionais de um sistema (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Mesmo aplicaes altamente modulares sofrem com o problema de misturar aspectos funcionais e no funcionais de um sistema (GORTON, 2011). Para resolver isto, todos estes aspectos podem ser levados em conta na hora de modularizar uma arquitetura, tcnica conhecida como separao de responsabilidades multidimensionais. A abordagem mais conhecida que implementa esta tcnica a orientao a aspecto (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

123

2.3.2.5 Ocultamento de Informaes

Outro princpio muito importante em arquiteturas de software e que d suporta para a modularizao de sistemas o ocultamento de informaes, ou seja, um bloco de construo s torna visvel para outros blocos aquelas informaes que so de interesse deles, todo o resto ca escondido por de trs da interface (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Usando uma classe como exemplo, os mtodos e atributos privados e pblicos cobrem exatamente este conceito de ocultamento de informaes e dados. Outras classes que fazem uso desta devem saber o mnimo possvel sobre esta classe, e o ideal que no tenham conhecimento algum sobre como esta classe implementa seus mecanismos, contendo desta forma a complexidade dentro de fronteiras bem delineadas (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

Fonte: Vogel et al. (2011, p. 130).

Figura 2.43: Acesso a um subsistema sem e com um facade. Como Vogel et al. (2011) colocam, o ocultamento de informaes no uma exclusividade de blocos de construo, este princpio pode ser utilizado por estruturas maiores, como sub-sistemas. Uma forma de aplicar este princpio nestes cenrios atravs do design pattern facade, que prov uma interface unica para um conjunto de interfaces em um subsistema, facilidando o uso deste (GAMMA; HELM; JOHNSON; VLISSIDES, 1998). Um exemplo da aplicabilidade de um facade seria em um ambiente de progra-

124

mao que d acesso ao subsistema compilador. A maioria dos clientes no precisa conhecer os detalhes de um compilador, eles precisam apenas compilar cdigos-fonte. Nestes casos o uso de um face que fornea este mtodo para compilao muito bem vindo, j que ele abstrai esta complexidade e limita o conhecimento necessrio para compilar cdigos (GAMMA; HELM; JOHNSON; VLISSIDES, 1998). Outro exemplo da aplicao deste princpo em aplicaes com vrias camadas, onde cada camada apenas enxerga a camada ligeiramente abaixo dela, e a comunicao entre as camadas ocorre atravs de interfaces bem denidas, escondendo objetos especcos da camada bem como qualquer outro detalhe da implementao, onde a tranferncia de dados dada por intermdio de objetos de transferncia de dados (Data Transfer Object ou DTO um design pattern) tidos como neutros (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Estes conceitos tambm remetem ao princpio da caixa preta, que determina que clientes de um bloco de construo devem se comunica apenas com uma interface, escondendo todo o resto deles. Este princpio geralmente implementado atravs do princpio da abstrao, detalhado na seo a seguir.

2.3.2.6 Abstrao

Segundo Vogel et al. (2011, p. 131): Abstraction means focusing on aspects of a concept that are relevant for a specic purpose and neglecting unimportant details for this particular purpose . A abstrao permite a melhor compreenso de problemas, sendo ela um caso especial da separao de responsabilidades. Este princpio est dividido em sub-princpios focados na abstrao de interfaces, peas fundamentais para a comunicao em um sistema, detalhados abaixo:

Interfaces explcitas: blocos de construo devem mostrar com clareza com quais outros blocos ele se comunica e quais interfaces ele fornece para que clientes possam utiliz-las. Separao da interface e implementao: clientes no devem ter conhecimento

125

dos detalhes de implementao, portanto, separar a interface das implementaes recomendado. Alm disso, esta separao permite o uso de diferentes implementaes, at mesmo de diferentes fornecedores. Este princpio tambm conhecido como Inverso de Dependncia, j discutido anteriormente.

Princpio de substituio de Liskov: se um objeto S um subtipo (herdeiro) de T, ento objetos T podem ser substitudos por objetos S sem modicar o comportamento (ou propriedades) de um programa (MARTIN, 1996a).

Princpio da Segregao de Interface: um cliente nunca deve ser forado a depender de uma interface que ele no utiliza. Este princpio muito til, pois evita que mudanas em uma interface levem a reestruturao de boa parte do sistema, simplesmente porque vrios clientes implementam esta interface, mesmo que nunca a usem. Indo alm, quando interfaces se tornam muito complexas, o melhor a ser feito segreg-las em interfaces individuais (MARTIN, 1996b).

Suporte na linguagem para abstraes: abstraes arquiteturais devem possuir suporte tanto na linguagem de projeto como de programao.

Projetar por Contrato: ou Design by Contract, busca ir alm da interface, j que esta apenas padroniza a sntaxe de um relacionamento, deixando em aberto questes mais intrnsecas do relacionamento, como a semntica das operaes e dos dados. Atravs deste princpio possvel especicar pr-condies e pscondies para o relacionamento, algo semelhante (supercialmente) ao que feito em testes unitrios.

Atravs de abstraes possvel reduzir o acomplamento de um sistema. Este princpio tambm pode ajudar na modularidade, princpio detalhado a seguir. A abstrao tambm tem relao com o ocultamento de informaes, juntas podendo prover a portabilidade de um sistema, escondendo detalhes especcos de uma plataforma, por exemplo (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

126

2.3.2.7 Modularidade

O princpio da modularidade engloba vrios outros princpios j falados aqui. Ele arma que sistemas devem ser compostos de blocos de construo com funes bem denidas e atnomos, facilitando a troca de blocos sem precisar alterar outros blocos de construo do sistema (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). A modularidade promove o baixo acoplamento em um sistema, j que responsabilidades intimamente relacionadas so agrupadas em blocos de construo. A aplicao da separao das responsabilidades, em conjunto com o ocultamento de informaes e a abstrao permite a criao de interfaces bem denidas (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Vogel et al. (2011) menciona tambm o princpio de aberto/fechado (open/closed principle), que arma que os blocos de um sistema devem estar abertos para mudanas, mas fechados para o uso de seus detalhes internos por outros sistemas ou blocos.

2.3.2.8 Outros Princpios

Os princpios colocados acima tem relao prxima uns com os outros e so muito importantes na reduo da complexidade e aumento da exibilidade de uma arquitetura de software. Abaixo esto outros princpios, de acordo com Vogel et al. (2011), que tambm devem ser levados em conta no projeto e implementao de arquiteturas:

Rastreabilidade: princpio que busca garantir uma boa compreenso da arquitetura atravs de boas prticas, como nomeclaturas consistentes em todo o cdigo-fonte e documentos do sistema. Auto-documentao: todas as informaes sobre um bloco do sistema devem fazer parte do bloco em si. Como exemplo existem ferramentas como o JavaDoc e o Doxygen que permitem que comentrios nos cdigos-fonte sejam utilizados

127

na gerao de documentao da aplicao. Incrementabilidade: arquiteturas devem ser projetadas de forma incremental devido a sua alta complexidade, reduzindo desta forma a ocorrncia de erros. No crescimento fragmentado (piecemeal growth uma arquitetura criada passo a passo, sem planejar o futuro, parando aps cada passo para decidir qual ser o prximo. Esta tcnica utilizada nos conceitos de refactoring e Extreme Programming. possvel ainda fazer uso de prottipos com o intuito de melhorar o conhecimento a respeito do problema que est sendo abordado. Conveno sobre Congurao (Convention over Conguration ou CoC): utilizao de padres, necessitando desta forma pouco ou nenhum ajuste atravs de conguraes. Consistncia: denir e seguir padres e convenes durante todo o projeto, como nas nomeclaturas, forma de comunicao dos blocos do sistema, estrutura das interfaces e documentao.

2.3.3 Patterns

O que foi visto at agora foram os conceitos bsicos de arquitetura de software que servem de fundao para a concretizao de um sistema. Uma das diculdades existentes na criao de uma arquitetura est em mensurar a qualidade desta ou saber quo efetiva ela ser na hora de entregar as qualidades planejadas, pois no existem meios de se medir tais fatores com certeza absoluta. Em todo o caso, possvel tirar vantagem do conhecimento acumulado ao longo dos anos de experincia, no apenas de um prossional, mas de toda uma rea. Patterns representam exatamente isto, o uso da experincia do passado na soluo de problemas com caractersticas semelhantes (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Nas palavras de Alexander, Ishikawa e Silverstein (1977, apud Fowler, 2002) Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice

128

. Patterns so um meio termo entre princpios e conceitos bsicos e a implementao de solues, so abstraes feitas de problemas prticos de modo que eles possam ser utilizados na soluo de vrios outros problemas semelhantes. Para Gamma et al. (1998), patterns possuem quatro elementos: um nome que descreve qual o problema que ser resolvido e como em poucas palavras; o problema que este pattern se prope a resolver, para que outras pessoas possam identicar quando uslo ou no; a soluo deste problema, claro, descrevendo os elementos que fazem parte dela, como eles se relacionam, quais as suas responsabilidades e colaboraes; e as consequncias do uso deste pattern, tanto para o bem como para o mal, e.g. os impactos dele nos atributos de qualidade da arquitetura. Alm da possibilidade de melhorarem a arquitetura de um software atravs de solues que comprovadamente funcionam, patterns tambm podem ser muito teis na comunicao em um projeto de software, principalmente na compreenso e documentao da arquitetura sendo construda (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Fato que corroborado por Buschmann, Henney e Schmidt (2007), que arma que patterns fornecem um vocabulario comum e conhecimento compartilhado a respeito de conceitos de projeto de arquitetura. Vogel et al. (2011) divide patterns em design patterns (padres de projeto) e architecture patterns (padres de arquitetura), tendo os primeiros como solues mais especcas e com efeitos locais, enquanto que a segunda mais distribuda, podendo ter efeito em todo o sistema. O interessante que alguns desing patterns podem muito bem ser aplicados em um contexto mais amplo, servindo como um architecture patterns, mesmo no tendo sido originalmente planejado desta forma. Em resumo, patterns so tcnicas comuns e teis para a soluo de determinados problemas. Seguindo esta mesma linha de pensamento existem os antipatterns, que descrevem erros frequentes e que devem ser evitados em um sistema. Ou seja, se disseminar boas prticas bom e pode melhorar a qualidade de um sistema, fazer o mesmo com ms prticas tambm pode ter o mesmo efeito (OSMANI,

129

2011). Gamma et al. (1998) classicam patterns atravs de dois critrios: propsito e escopo. O escopo dos patterns pode ser de classe ou objeto, enquanto que os propsitos aos quais eles podem servir so trs:

Criao: de objetos ou o processo que envolve a criao de objetos. Estrutural: lidam com a composio de classes ou objetos. Comportamental: caracteriza as formas pelas quais classes e objetos interagem e distribuem responsabilidades.

Tanto Gamma et al. (1998) como Fowler (2002) denem uma grande quantidade de patterns com diversas aplicaes. Mas, diferentemente do primeiro autor, Fowler (2002) no segue o mesmo esquema de classicao, dando preferncia a uma organizao dos patterns de acordo com o problema ou classe de problemas que ele se prope a resolver. Como exemplo, o autor coloca patterns como Transaction Script, Domain Model, Table Module e Service Layer na lgica de domnio de uma aplicao, da mesma forma, Table Data Gateway, Row Data Gateway, Active Record e Data Mapper so solues para problemas relacionados com a fonte de dados de uma aplicao, havendo ainda solues mais complexas como o mapeamento objeto-relacional em aplicaes orientadas a objeto e que possuem bancos de dados relacionais. Existem patterns para a soluo de problemas que vo desde a camada de apresentao de uma aplicao (e.g. MVC, Front Controller, Template View ), at questes envolvendo concorrncia (e.g. Optimistic Ofine Lock, Implicit Lock ), aplicaes distribudas (e.g. Remote Facade, Data Transfer Object) e estado de sesso (e.g. Client Session State, Server Session State) (FOWLER, 2002). Detalhar cada um destes (ou os principais) patterns, entretanto, est fora do escopo deste trabalho. Obviamente, durante o processo de anlise e implementao da aplicao vrios patterns sero avaliados e possivelmente utilizados, sem contar

130

aqueles que j so utilizados por frameworks. Em todo caso, existem referncias (algumas citadas anteriormente) que fornecem catlogos de patterns que podem ser consultados, quando da necessidade de resolver algum problema com relao a arquitetura do software.
Criacional Factory Method Abstract Factory Builder Prototype Singleton Objeto Propsito Estrutural Comportamental Adapter Interpreter Template Method Adapter Chain of Responsibility Bridge Command Composite Iterator Decorator Mediator Facade Observer Flyweight State Proxy Strategy Visitor

Classe

Escopo

Fonte: Gamma et al. (1998, p. 22).

Quadro 2.1: Classicao de patterns. 2.3.4 Arquiteturas Bsicas

Esta seo apresenta algumas das arquiteturas mais utilizadas em sistemas. Elas fazem uso de alguns dos meios e princpios denidos nas sees anteriores e podem denir desde estruturas mais simples, como a arquitetura em camadas, at arquiteturas mais elaboradas, como a orientada a servios (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Para Vogel et al. (2011), a pior das arquiteturas possveis a monoltica, onde todo o software est contido em um nico bloco de construo, impedindo a existncia da separao de responsabilidades e baixo acomplamento. Este tipo de sistema apresenta vrias diculdades, principalmente no que diz respeito a modicabilidade, pela falta de organizao das estruturas e pela diculdade de compreender o seu funcionamento. Entretanto, arquiteturas monolticas no signicam necessariamente que todo o sistema est concentrado em uma nica estrutura. Em alguns casos, apenas alguns aspectos de uma arquitetura podem estar orgnizados de forma monltica, levantando

131

a questo de centralizar ou descentralizar. Com a descentralizao vem tambm a reduo de custos de hardware, maior exibilidade a mudanas e maior redundncia de componentes. Por outro lado, arquiteturas centralizadas facilitam tarefas como logging, segurana, monitoramento e entrega de novos blocos de construo ao sistema (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

Fonte: Vogel et al. (2011, p. 192).

Figura 2.44: Viso geral das arquiteturas bsicas.

Uma das questes fundamentais com relao criao de arquiteturas de software como dividir um sistema em grupos com funcionalidades e responsabilidades semelhantes. Uma das solues para esta questo o uso pattern de Camadas (Layers). Uma cadama pode conter vrios blocos de construo que podem se comunicar livremente, entretanto, a comunicao entre camadas s pode ocorrer atravs de interfaces bem denidas, alm disso, uma camada n s pode requisitar os servios da camada n-1. Desta forma, cada uma das camadas dependente apenas da camada ligeiramente inferior a esta e nenhuma outra camada. Esta arquitetura pode aumentar a modicabilidade, portabilidade e reusabilidade de um sistema (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

132

Outra forma de estrutura aquiteturas pode ser atravs de uxos de dados, dividindo tarefas complexas em series de tarefas mais simples. Cada uma destas tarefas no estilo de lotes sequenciais viria a se tornar um bloco de construo independente, sendo que cada um deles ca responsvel por chamar a prxima tarefa do uxo. Canos e ltros (Pipes and lters pattern) funcionam de forma semelhante, onde canos servem de conexo (datastreams) entre dois ltros, ltros podem ainda trabalhar em paralelo e canos podem funcionar ainda como buffers de dados. Filtros nos Java Servlets so um exemplo desta arquitetura, onde ltros podem ser congurados (e.g. atravs de XML) para interceptar requisies e respostas e inferir aes sobre elas (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Uma das arquiteturas mais conhecidas a de cliente/servidor. Nesta arquitetura um usurio acessa atravs de um cliente (e.g. um browser ou um programa dedicado) recursos disponveis em um servidor. A comunicao ocorre atravs de requisies do cliente e respostas do servidor. Em um exemplo onde o cliente faz acesso direto a um banco de dados, esta arquitetura pode ser considerada do tipo two-tier, onde um tier um meio para estruturar a distribuio de blocos de construo de software em blocos de construo de hardware. Aplicaes disponibilizadas na Web geralmente adicionam um novo tier, o servidor, este fazendo o meio de campo entre cliente e banco de dados, limitando seu acesso e ao mesmo tempo facilitandoo. Replicaes do banco de dados poderiam ser adicionadas, bem como replicas do servidor web criando um tier adicional responsvel pelo balancemaneto de carga (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Outra questo a respeito de arquiteturas cliente/servidor est com relao a quantidade de tarefas que sero a ele delegadas, classicando-os em thin clients e rich clients. O modelo de mainframes um exemplo extremo do uso de thin clients. J as aplicaes desktop costuma utilizar rich clients, cando encarregadas por grande parte do processamento de dados, reduzindo desta forma o trfego da rede, questo que pode fazer muita diferena no desempenho percebido pelo usurio. Na web browsers costumam caracterizar thin clients, mas com o advento de tecnologias como Ajax, websites podem oferecer experincias de rich clients, havendo atualmente no mercado uma grande variedade de bibliotecas que fornecem componentes para a

133

construo de aplicaes complexas. preciso, entretanto, analisar as vantagens e desvantagens de cada uma das alternativas, clientes desktop comstumam ser relativamente independentes da rede, mas por outro lado podem ser mais difceis de gerenciar (e.g. fazer atualizaes) do que clientes Web. Atravs do HTML5, entretanto, o uso de aplicaes Web no modo ofine passou a ser uma realidade, mesmo que limitado a informaes previamente consultadas (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

Fonte: Vogel et al. (2011, p. 197).

Figura 2.45: Exemplo de arquitetura three-tier. Apesar da arquitetura cliente/servidor ser a mais popular, ela no a nica. Alm dela existem ainda as arquiteturas peer-to-peer (P2P) e publish/subscribe. A primeira delas bastante conhecida como meio para compartilhamento de arquivos, principalmente (mas no unicamente) de arquivos com direitos autorais. Ela, assim como a arquitetura cliente/servidor, tambm funciona atravs da invocao explcita, mas dispensa a necessidade de um servio central, focando a comunicao diretamente entre clientes. Diferentemente das duas arquiteturas acima discutidas, uma terceira faz uso de uma abordagem diferente com relao a invocao, pois ao invs de o cliente fazer uma requisio, ele faz uma assinatura e o servidor faz contato com ele (sem o cliente ter requisitado), mtodo conhecido por invocao implcita. O

134

Instagram, por exemplo, expe na sua API um mtodo onde o cliente faz a inscrio e passa a receber em tempo real atualizaes de fotos feitas no servio (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Para Vogel et al. (2011), aps escolher uma das trs arquiteturas acima citadas preciso escolher o tipo de conexo entr os blocos de construo do sistema, conhecidos por middleware. Para o autor, middleware uma plataforma que oferece servios sob todos aspectos de sistemas distribudos. Arquiteturas distribudas precisam levar em conta questes como latncia da rede, previsibilidade (fundamental em sistemas de tempo real), concorrncia, escalabilidade e falhas parciais no sistema (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Vogel et al. (2011) cita ainda alguns dos estilos de middleware que podem ser aplicados em arquiteturas de software:

Remote Procedure Call (RPC): chamada de procedimentos distribudas so efetuadas da mesma forma que seriam feitas localmente, sendo que todos os detalhes especcos so escondidos do usurio atravs do sistema RPC. Sistemas de Mensagens: envio de mensagens de forma assncrona (ou sncrona) de um remetente para um ou mais sistemas recipientes, as mensagens so armazenadas em las e entregues quando possvel ou consumidas sob demanda. Repositrios compartilhados: vrios clientes tem acesso de leitura e escrita a um mesmo espao de dados, como um banco de dados. Sistemas de Streaming: troca contnua de dados atravs de um datastream.

Exemplos de middlewares so CORBA, RMI e .NET. Plataformas de componentes como JEE, CCM e .NET do suporte para estes meios de comunicao distribuda. Estas plataformas se preocupam com a separao da parte tcnica e funcional de sistemas de informao (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

135

Gorton (2011) vai alm e faz uma classicao formal dos middlewares, como mostra a Figura 2.46. Esta classicao feita na forma de camadas, sendo a mais bsica delas a camada de transporte, representando conexes bsicas para o envio de requisies e movimentao de dados entre componentes. Na camada acima esto os application servers, citados no pargrafo anterior, e que fornecem algumas funcionalidades adicionais a camada de transporte, como transaes e segurana. Message Brokers podem ou no fazer uso de application servers e fornecem funcionalidades para a troca, manipulao e roteamento de mensagens entre os componentes de uma aplicao. Na ltima das camadas, os BPOs estendem as funcionalidades dos message brokers, permitindo a descrio, execuo e gerenciamento de processos de negcio em aplicaes estilo workow.

Fonte: Gorton (2011, p. 40).

Figura 2.46: Classicao de middlewares. Nas prximas sees sero abordados em maiores detalhes outras quatro arquiteturas bsicas de software.

2.3.4.1 Service Oriented Architecture

Nas palavras de Vogel et al. (2011, p. 206), arquiteturas orientadas a servios are a basic architecture that represents the technically functional interfaces of software building blocks as reusable, distributed, loosely coupled, and standardized acessible services . Daigneau (2010) vai alm e arma que SOA um estilo de projeto que cuida de todos os aspectos da criao e utilizao de servios de negcios por todo seu ciclo de vida. Seja qual fora a rea de aplicao do SOA, o principal objetivo a criao de uma arquitetura independente e de baixo acomplamento, disponibilizando servi-

136

os de forma distribuda e que podem at mesmo ser provenientes de organizaes diferentes (e.g. business-to-business B2B) (DAIGNEAU, 2010). Atravs do SOA possvel integrar aplicaes dentro e fora de uma organizao, tarefa esta que era complicada quando os middlewares disponveis eram proprietrios e no haviam padres largamente aceitos, mas que com o advento da Internet e com a criao de padres para Web Services se tornou muito mais fcil (GORTON, 2011). Gorton (2011) ainda arma que as tecnologias de Web Services so as nicas atualmente que permitem a construo de arquiteturas baseadas em servios realmente interoperveis, independentemente das tecnologias implementadas dentro das organizaes. Para o autor, SOAs possuem quatro princpios fundamentais:

Fronteiras so explcitas: ou seja, servios so aplicaes independentes e fronteiras precisam ser cruzadas para acess-los, isso pode impactar no desempenho, aumentar a complexidade e reduzir a robustez de aplicaes. Tais implicaes reforam a necessidade de interfaces simples e de fcil compreenso. Servios so autnomos: isso signica que eles no tem relao alguma com componentes ou classes, e principalmente com os clientes. Clientes sabem apenas que mensagens sero enviadas e recebidas do servio, e contanto que o servio se mantenha compatvel a estas especicaes, todo o resto (i.e. a implementao) pode ser alterado. Compartilhe esquemas e contratos, no implementaes: seguindo a mesma ideia de servios autnomos, servios expe apenas as interfaces para seus clientes, muito diferente de tecnologias como CORBA, onde objetos inteiros eram transferidos. A compatibilidade de servios baseada em polticas: onde polticas so colees de requisitos do servio e que podem ser lidos por mquinas. Estas polticas podem incluir, por exemplo, questes como conabilidade, segurana e desempenho, denindo como o cliente deve se comportar para estar em confor-

137

midade com o servio.

J Bean (2010) dene como princpios bsicos de SOAs o baixo acomplamento, interoperabilidade, reusabilidade, capacidade de descoberta e governana. O baixo acomplamento aqui tem o mesmo papel j descrito nas sees anteriores sobre os princpios de arquitetura de software, e seu principal objetivo est em reduzir a dependncia entre servios e clientes destes servios, objetivo alcanado atravs da comunicao com mensagens. A ideia de independncia entre as partes envolvidas tambm aplicada no princpio de interoperabilidade, que prega o uso de interfaces independentes de tecnologias especcas. Havendo tal independncia e comunicao armada atravs de interfaces bem denidas, ser possvel para um cliente substituir um servio por outro que tambm esteja em conformidade com a interface. E da mesma forma, vrios clientes podem fazer uso de um mesmo servio, o que, dentro de uma organizao, pode signicar a reutilizao de um servio de autenticao em comum ao invs da implementao local, poupando tempo e reduzindo a manunteno atravs da unicao do gerenciamento de contas de usurios. Em SOAs, servios costumam ter um nvel de detalhamento menor do que interfaces de componentes, sendo ainda mais fortemente estruturados com relao a relevncia para o negcio. Isso tem relao direta com o princpio de baixo acomplamento que muito desejado neste tipo de arquiteturas. Os princpios descritos acima fazem com que servios se comuniquem atravs de padres que so independentes de tecnologias (nem sempre isso ocorre, mas esta uma caracterstica desejvel) e suas interfaces so auto-descritivas, seja atravs de metadados ou de uma documentao (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). As abstraes chave de arquiteturas orientadas a servios so quatro (ver Figura 2.47): consumidor do servio, provedor do servio, e opcionalmente um barramento e repositrio. Estas duas ltimas abstraes chave fazem parte da Service Oriented Infraestructure (SOI) ou Enterprise Service Bus (ESB) e elas compe o middleware. Logicamente, um consumidor de um servio est acessando diretamente o

138

provedor do servio, na prtica, entretanto, pode haver um intermedirio. O Repository responsvel pelo registro dos servios disponibilizados pelos provedores e tambm permite que clientes faam buscas pelos servios. J o Bus faz o redirecionamento das mensagens dos clientes e dos resultados retornados pelos servios. Dentre as vantagens de se utilizar um middleware est a capacidade de adicionar aspectos nofuncionais aos servios, como logs, segurana e transformao de mensagens, sem a necessidade de modicar os provedores de servios, realizando assim a separao das responsabilidades (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

Fonte: Vogel et al. (2011, p. 207).

Figura 2.47: Abstraes chave de um SOA. A seo 2.5 ir falar especicamente sobre os padres mais utilizados para a comunicao entre servios e clientes atravs dos chamados Web Services. J na seo a seguir ser detalhada a arquitetura de Computao nas Nuvens, muito utilizada para o fornecimento de servios na Internet, como o SaaS (Software as a Service), bem como a disponibilizao do servio na forma de API, para que terceiros possam fazer uso.

2.3.4.2 Cloud Computing Architectures

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of congurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction (NIST, 2009).

Isso signica, por exemplo, que h a possibilidade de uma empresa, que deseja criar um novo servio disponibilizado atravs da Internet, poder alocar recursos

139

de computao de uma empresa que fornece servios de Cloud Computing, podendo implementar seu servio e pagar somente pelo o que est sendo de fato utilizado, comportando tanto o crescimento como a reduo no uso do seu novo servio. Em termos prticos, a empresa no precisa se preocupar com questes como a instalao de um servidor, storage e interface de rede, segurana e disponibilidade (RODGER, 2011). A Figura 2.48 exibe uma viso geral dos principais conceitos de arquiteturas de cloud computing. Um dos aspectos destas arquiteturas a sua classicao em tipos, sendo os principais SaaS, PaaS e IaaS. Entretanto, alm destes trs tipos, existem outros mais especcos, descritos por Vogel et al. (2011):

Software as a Service (SaaS): nesta categoria, servios so distribudos atravs da web e geralmente acessados atravs de um browser por usurios. Ex.: Google Apps, Salesforce, Basecamp. Information as a Service (INFaaS): consumo de informaes armazenadas na nuvem atravs de interfaces bem denidas de informao. Platform as a Service (PaaS): oferece plataformas de aplicao e desenvolvimento prontas para implantao. Ex.: Google App Engine, Microsoft Azure, Heroku. Integration as a Service (INTaaS): oferece o encapsulamento de stacks completos de integrao com suporte a interfaceamento com aplicaes, mediao semntica e funcionalidade de controle de uxo. Infrastructure as a Service (IaaS): oferece poder de computao na forma de servio, como servidores ou server farms, podendo ainda se referir a outros tipos de servios como STaaS e DaaS. Ex.: Amazon Web Services e Rackspace. Storage as a Service (STaaS): servios de armazenamento e sistemas de disco sob demanda. Ex.: Amazon S3. Database as a Service (DaaS): prov alto nvel de abstrao para acesso a sistemas de armazenamento de dados. Ex.: Amazon SimpleDB, Amazon Dynamo.

140

Independente do tipo de servio fornecido, arquiteturas de cloud computing tambm podem ser classicadas de acordo com a forma como elas so implantadas. Uma nuvem privada signica que os servios por ela fornecidos esto disponveis apenas dentro de uma empresa ou negcio, enquanto que nuvens pblicas so fornecidas para um pblico mais amplo. Nuvens pblicas geralmente so fornecidas por empresas especializadas na venda de servios, como a Amazon e a Rackspace. Em um meio termo esto as nuvens hbridas, que so compostas tanto por nuvens pblicas como privadas. Tanto nuvens pblicas como privadas podem ser hospedadas interna ou externamente , sendo as nuvens internas implantadas e gerenciadas pela prpria equipe de TI da organizao (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Com as denies e classicaes descritas at agora j possvel criar uma taxonomia da cloud computing, ilustrada na Figura 2.49. Cloud Computing pode ser utilizado para facilitar o desenvolvimento e teste de aplicaes atravs de ambientes pr-congurados e prontos para uso, integrao de servios e funes de uma organizao com servios disponibilizados pela nuvem, ou para a construo de servios especialmente arquitetados para a nuvem (e.g. SaaS) (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Atravs do cloud computing e a virtualizao, os custos de hardware podem ser compartilhados entre os vrios clientes de um fornecedor de servios na nuvem, tornando a computao nas nuvens uma alternativa mais em conta se comparado com os custos de construo de um servidor prprio. Outro aspecto que refora esta ideia a cobrana varivel pelos servios de computao nas nuvens, onde se paga apenas aquilo que se usa. Alm destes benefcios, os recursos de computao disponibilizados pela nuvem esto prontos para uso imediato, provendo ainda espao para crescimento de um servio (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Mas, obviamente, estes benefcios andam de mos dadas com alguns problemas. Talvez um dos que mais cause medo seja o fato de que um provedor de servios na nuvem pode muito bem desaparacer amanh. Por outro lado, esta situao tambm pode ocorrer com fornecedores de aplicaes da forma tradicional. Em qualquer

141

Fonte: Vogel et al. (2011, p. 222).

Figura 2.48: Viso geral dos conceitos de arquiteturas de Cloud Computing.

um dos casos preciso realizar pesquisas para vericar se o fornecedor convel e no ir desaparecer de um dia para outro. Alm deste problema, muitos clientes se preocupam com questes como segurana das informaes que residem nas nuvens, sendo que na maior parte das vezes no se sabe ao certo onde estas informaes esto armazenadas, podendo resultar em problemas legais, sem contar nos riscos de vazamento e perda de dados (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011). Em todos os casos, preciso avaliar as vantagens e desvantagens da computao nas nuvens para que a escolha mais adequada seja feita. Invariavelmente, o que se v atualmente uma adoo cada vez maior desta arquitetura tanto por organizaes mais tradicionais como por novas empresas (start-ups). E com relao a estas ltimas, o fato que a computao nas nuvens permitiu a rpida implementao

142

Fonte: Vogel et al. (2011, p. 224).

Figura 2.49: Taxonomia da Cloud Computing.

de novos servios, servindo como propulsor do empreendedorismo.

2.4 BANCO DE DADOS

Um sistema de banco de dados um sistema computadorizado para armazenamento de informaes e subsequente recuperao e atualizao das mesmas (DATE, 2004). Bancos de dados possuem algumas propriedades implcitas, tal como representar algum aspecto do mundo real, contendo colees de dados que sejam coerentes e que tenham algum signicado e que cumpram um propsito especco (ELMASRI; NAVATHE, 2011). Estes sistemas computadorizados responsveis pelo gerenciamento de bancos de dados so conhecidos por SGBDs (Sistema de Gerenciamento de Banco de Dados, ou DBMS Database Management Systems), atravs deles possvel denir, construir, manipular e compartilhar bancos de dados entre usurios e aplicaes. A denio de um banco de dados involve a especicao de tipos de dados, estruturas e restries dos dados que sero armazenados, informaes que tambm so armazenados nos SGBDs na forma de metadados. SGBDs controlam o meio pelo qual os dados sero armazenados e fornecem

143

as funes que sero expostas aos usurios e aplicaes para a consulta (querying) e atualizao de dados. Alguns SGBDs ainda do suporte a transaes, onde dados podem no apenas ser consultados mas tambm alterados. SGBDs podem ainda incluir outras funcionalidades, como proteo contra falhas em hardware e software e um sistema de autenticao para evitar acesso indevido e mal intencionado (ELMASRI; NAVATHE, 2011). Alm das funcionalidades acima descritas, SGBDs permitem que dados sejam normalizados, evitando redundncia e inconsistncia de dados. Geralmente eles tambm fornecem um mdulo para processamento e otimizao de consultas, responsvel pela escolha de um plano eciente para consulta de dados de acordo com as estruturas existentes no banco de dados. Uma destas estruturas o ndice, que facilita a consulta de registros no disco atravs de estruturas de dados em rvore ou hash. Em uma consulta, registros so copiados do disco para a memria principal, e o banco de dados faz uso de mdulos de caching e buffering para otimizar esta tarefa (ELMASRI; NAVATHE, 2011). Funcionalidades de backup e recuperao tambm so comuns em SGBDs, incluindo a recuperao do ltimo estado consistente do banco de dados aps uma falha ocorrida durante uma transao. Atravs dos SGBDs possvel ainda representar dados que possuem relacionamentos complexos, por exemplo, um conjunto de dados de produtos pode estar relacionado com outro conjunto de marcas. E mais, SGBDs podem permitir a denio de restries para os dados, comeando pelo tipo de dados que poder ser armazenado, passando pela integridade referencial que refora o relacionamento, por exemplo, entre produtos e marcas, impedindo que uma marca seja removida enquanto ela possuir produtos relacionados. Outras restries podem ser com relao a valores nicos que identicam um registro, conhecidos como chaves. E alguns SGBDs permitem ainda a criao de regras que podem ser utilizadas para a execuo de aes sobre dados (ELMASRI; NAVATHE, 2011). Na prxima seo ser abordado o modelo de banco de dados mais popu-

144

lar atualmente, o modelo relacional. E na seo seguinte sero abordados vrios modelos de bancos de dados que surgiram e/ou ganharam popularidade em 2009 e passaram a ser chamados de bancos de dados NoSQL, apesar de possuirem vrias diferenas entre si.

2.4.1 Bancos de Dados Relacionais

O modelo relacional foi introduzido por Ted Codd da IBM Research em 1970 e ganhou ateno devido a sua simplicidade e fundao na matemtica. Neste modelo, um banco de dados uma coleo de relaes e cada relao chamada de tabela. Tabelas possuem linhas (ou tuplas) e cada linha de uma tabela corresponde a uma coleo de dados relacionados. Tabelas tambm possuem colunas (ou atributos) que possuem um tipo especco (domnio de valores possveis) e um nome, que dene o que ser armazenado nela (ELMASRI; NAVATHE, 2011). Em conjunto com as estruturas de dados acima descritas, bancos de dados relacionais possuem funes para manipulao de dados, sendo que a linguagem SQL (Structured Query Language) o padro para bancos de dados relacionais comerciais (ELMASRI; NAVATHE, 2011). Date (2004) ainda cita um terceiro aspecto com relao a bancos de dados relacionais, que o aspecto de integridade, onde as tabelas devem satisfazer determinadas restries de integridade. Estas restries podem ser implcitas, como no poder haver tuplas duplicadas; explcitas, estas especcas nos schemas do modelo de dados, geralmente atravs da DDL (Data Denition Language), como por exemplo a integridade de entidades (chaves primrias no podem ser NULL) e a integridade referencial (chaves estrangeiras no podem referenciar uma entidade que no existe); e por m, as restries da aplicao ou semnticas, ou seja, aquelas que no podem ser expressas no schema do modelo de dados (ELMASRI; NAVATHE, 2011). Antes de entrar nos detalhes dos bancos de dados open source mais conhecidos, MySQL, PostgreSQL e SQLite, preciso descrever um ltimo aspecto dos bancos de dados relacionais e que os diferenciam em partes de alguns bancos de

145

dados NoSQL, que so as transaes. Uma transao consiste em uma ou vrias operaes sobre um banco de dados, como inseres, remoes e atualizaes, bem como operaes para consulta de dados. Ao nal de uma transao, o banco de dados deve estar em um estado vlido ou consistente, de acordo com as restries do modelo de dados (ELMASRI; NAVATHE, 2011). Transaes possuem o que chamado de propriedades ACID (Atomiticy, Correctness, Isolation e Durability ). A atomicidade prega a abordagem do tudo ou nada, ou seja, se uma das operaes dentro de uma transao falhar todas as operaes da transao so desfeitas (ROLLBACK ) e se todas elas ocorrem com sucesso, elas so aplicadas ao banco de dados (COMMIT ). A consistncia, como armado no pargrafo anterior, dene que transaes devem receber o banco de dados em um estado consistente e deix-lo, ao nal da transao, em um novo estado tambm consistente. O isolamento das transaes garante que as modicaes realizadas por uma transao s possam ser visualizadas no banco de dados aps o nal da transao, nunca durante. E por m, quando uma transao termina e persistida no banco de dados, existem garantias de que as alteraes permanecero, mesmo que ocorram subsequentes falhas no sistema (DATE, 2004).

2.4.1.1 MySQL

O MySQL um sistema de gerenciamento de banco de dados relacional que inclui um servidor SQL, clientes para acesso ao servidor, ferramentas administrativas e APIs em vrias linguagens de programao, como C, Perl, PHP, Python, Java e Ruby. Este SGBD um projeto open source disponibilizado sob a licena GPL (GNU General Public License) bem como em licenas comerciais (DUBOIS, 2009). Dubois (2009) arma que o MySQL est entre os bancos de dados mais rpidos disponveis (muito embora seja preciso avaliar com cuidado benchmarks, sem contar que existem vrios fatores que podem implicar no desempenho de um banco de dados). Este banco de dados tambm apresenta uma maior facilidade de uso,

146

segundo o autor, sem contar que ele ocupa muito menos espao em disco (a sua instalao) do que outros SGBDs. E sem contar o fato de ser um projeto open source, j mencionado, ele tambm d suporte para os principais sistemas operacionais (e.g., Linux, Unix, Windows e Netware). O MySQL um banco de dados altamente exvel, com uma arquitetura organizada da forma que a parte responsvel pelo processamento de consultas separado de outras partes como armazenamento e recuperao de dados. Esta caracterstica, em especial, permite que storage engines possam ser escolhidos livremente para cada uma das tabelas de um banco de dados, variando assim a forma como o armazenamento feito, a performance apresentada, funcionalidades alm de outras caractersticas (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008).

Fonte: Schwartz et al. (2008, p. 2).

Figura 2.50: Viso lgica da arquitetura do servidor do MySQL.

Atravs da Figura 2.50 possvel ver como a arquitetura lgica do MySQL est organizada. Basicamente so trs camadas, e a primeira delas responsvel pelo gerenciamento de conexes, autenticao, segurana e outras funcionalidades relacionadas a ferramentas cliente/servidor utilizadas no acesso ao SGBD. A segunda camada o chamado servidor MySQL, e onde boa parte das funcionalidades prin-

147

cipais do banco de dados vive (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Esta camada responsvel, dentre outras coisas, pela interpretao de consultas (query parsing), anlise, otimizao, cache e todas as funcionalidades embutidas e que esto disponveis independentemente do storage engine. Este ltimo, por conseguinte, forma a terceira e ltima cada da aquitetura do MySQL, onde cam as peas responsveis pelo armazenamento e recuperao de dados. Storage engines no compreendem SQL, ao invs disso eles possuem uma API que a implementao de uma API comum a todos, possibilitando desta forma que o servidor MySQL se comunique de forma igual com todos os storage engines, caracterstica que torna o desenvolvimento de motores de armazenamento relativamente simples (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). No MySQL cada conexo com o cliente resulta na criao de uma nova thread dentro do processo do servidor, e o banco de dados faz cache destas threads para no precisar arcar com os custos de destru-las e cri-las a cada nova conexo estabelecida. Outra forma de cache feita pelo MySQL o cache de consultas, onde o servidor armazena em cache todas as consultas e caso a mesma consulta seja feita novamente o servidor apenas devolve o resultado armazenado em cache (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Infelizmente, esta situao nem sempre ocorre, e nestes casos a consulta precisa ser interpretada, criando o que se chama de parse tree, permitindo ao servidor aplicar vrias otimizaes em busca de melhor desempenho. importante lembrar, entretanto, que boa parte da otimizao de um banco de dados depende de decises tomadas com relao a estrutura das tabelas, como os ndices foram criados e como as consultas esto sendo feitas. Alm disso, o motor de armazenamento escolhido tem papel fundamental no desempenho do banco de dados, sendo que a escolha deve levar em conta as vantagens e desvantagens oferecidas por cada uma das opes disponveis, bem como as caractersticas da aplicao que utilizar este banco de dados (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008).

148

Com relao aos storage engines, o MyISAM um dos mais antigos e o padro para o MySQL. Ele no tem suporte a chaves estrangeiras e transaes (ao contrrio do InnoDB), sendo que cada comando executado nele considerado como uma transao, muito embora no possam ser chamadas assim, j que no existem garantias de que o comando ser executado ou que o banco de dados estar em um estado vlido, j que no possvel executar um ROLLBACK. Com relao a forma como o engine lida com a concorrncia, para leitura uma tabela pode ser consultada por vrias clientes, mas para escrita apenas um cliente pode acessar a tabela por vez. Entretanto, possvel que clientes faam a leitura do banco de dados enquanto dados esto sendo inseridos no mesmo. De qualquer forma, o bloqueio ao nvel de tabela, apesar de reduzir o overhead devido a baixa granularidade, implica na reduo da concorrncia (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). O MyISAM possui ainda algumas funcionalidades como ndices full-text que faz o indexamento de palavras individuais para operaes complexas de busca. Como fora mencionado na seo 2.2.9, o MySQL d suporte a algumas funcionalidades espaciais, e o MyISAM em especial, o nico engine que tem suporte a ndices espaciais (R-tree), que diferentemente dos ndices B-Tree no operam da esquerda para a direita nas clusulas WHERE, se tornando mais ecientes, desde que usados em conjunto com as operaes GIS oferecidas (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Quando o assunto transaes, a storage engine mais popular o InnoDB. Ao contrrio do MyISAM, o InnoDB permite um alto nvel de concorrncia pois faz uso de bloqueio por linhas ao invs de tabelas em conjunto com o MVCC (Multiversion Concurrency Control). Ao contrrio dos mecanismos mais simples para bloqueio de linhas, que acabam bloqueando vrias linhas de uma tabela, com o MVCC so criados snapshots dos dados em determinados pontos no tempo (como dados que foram alterados ou deletados), permitindo assim que duas transaes possam ver dados diferentes nas mesmas tabelas e ao mesmo tempo. Desta forma armazena-se mais dados em troca de um menor nmero de bloqueios em linhas de uma tabela (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008).

149

Diferentemente do MyISAM, o InnoDB possui ndices organizados em cluster. Enquanto que no MyISAM as folhas dos ndices B-Tree armazenam uma referncia do registro em disco, no InnoDB as folhas do ndice da chave-primria (tambm B-Tree) armazenam uma cpia dos dados do registro, enquanto que outros ndices armazenam apenas a chave-primria do registro. Isso signica que buscas pela chaveprimria sero mais rpidas, mas em contrapartida buscas em ndices secundrios de uma tabela InnoDB preciso percorrer dois ndices para encontrar os registros (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Ao contrrio do que as crenas dizem, MyISAM nem sempre mais rpido que InnoDB, havendo casos onde este ltimo apresenta desempenho signicativamente melhor, especialmente onde possvel tirar vantagem dos ndices em cluster e onde os dados cabem na memria. Sem contar que tabelas MyISAM costumam se tornar corruptas muito mais facilmente e podem demorar muito mais para serem recuperadas (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Alm dos dois storage engines supracitados, existem outros engines que podem ou no vir junto com a instalao padro do MySQL. Os outros engines mais conhecidos so: Memory (ou HEAP), Falcon, Archive, CSV, Blackhole, Federated, NDB Cluster, PBXT, solidDB e Maria (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). A escolha do storage engine mais apropriado para cada situao pode ter impacto signicativo no desempenho de uma aplicao. A medida que a carga de um banco de dados aumenta, tambm aumentam os problemas relacionados ao seu desempenho. Em um primeiro momento isto pode implicar na otimizao de consultas (melhorando o uso de ndices ou criando novos ndices, ou tabelas de sumrio ou qualquer outra abordagem que se mostre efetiva) ou upgrade do hardware, mas com o tempo escalar um banco de dados para comportar a carga crescente signica fazer uso de medidas mais drsticas. Estas medidas podem variar desde a criao de rplicas de somente leitura, at o escalamento vertical atravs de clusters ou o escalamento horizontal particionando os dados em shards (HENDERSON, 2006).

150

A replicao no MySQL, como o nome sugere, signica a replicao de um banco de dados em uma outra mquina, aumentando o nmero de pontos de leitura de dados. A replicao envolve mestres e escravos, onde um escravo pode ter apenas um mestre, e este pode possuir vrios escravos. Uma das conguraes possveis para a replicao o mestre-escravo, onde um mestre recebe tanto leitura como escrita e os seus escravos mantm uma conexo com o mestre, por onde este envia os logs dos eventos que vo ocorrendo para que o escravo possa efetuar as atualizaes e car em sincronia com o mestre (ver Figura 2.51). Escravos servem apenas para leitura de dados, nunca para escrita, e preciso ter em mente que eles nem sempre estaro em sincronia com o seu mestre. Um mestre pode ter mais de uma rplica, e mais, possvel ainda criar uma rvore de replicao, onde rplicas se tornam mestres de outras rplicas e propagam modicaes feitas no mestre (HENDERSON, 2006).

Fonte: Schwartz et al. (2008, p. 346).

Figura 2.51: Funcionamento da replicao no MySQL.

Outra congurao possvel para a replicao a mestre-mestre, neste caso cada servidor passa a ser o escravo do outro. Esta congurao trs consigo alguns problemas que sero vistos tambm no sharding, como a questo do uso do auto incremento. Outro problema a inconsistncia dos dados, j que ambos os servidores podem ser escritos. Esta congurao, entretanto, ideal para redundncia em caso de falhas em um dos servidores, e pode ainda ser estendida adicionando escravos para os mestres (HENDERSON, 2006).

151

O uso da replicao pode ser considerada uma estratgia para aplicaes que necessitam de alto desempenho e alta avaliabilidade, entretanto ela apenas ajuda na distribuio da carga de leitura de dados, no de escrita, j que esta tarefa continua sob os ombros de um nico servidor, o mestre. E mais, rplicas no devem ser conadas como forma de backup, apesar de poderem auxiliar (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Rplicas podem cumprir muito bem seu papel, mas em determinado momento ser necessrio o uso de outras abordagens para escalar o MySQL. Um banco de dados pode escalar para cima, para os lados e ainda para trs. A primeira das opes alcanada atravs da aquisio de hardware mais pontente, soluo que tende a custar caro at o ponto onde no havero mais justicativas para continuar atualizando o hardware. Sem contar que o MySQL possui limitaes quanto a sua escalabilidade vertical (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). A segunda opo escalar na horizontal, estratgia que pode ser realizada atravs da replicao, no caso de aplicaes com grande intensidade de leitura, ou atravs do particionamento da carga atravs de ns. Um n pode ser um simples servidor ou pode ser um conjunto de servidores com replicao e failover. Neste ltimo caso, um n pode se apresentar atravs de uma congurao mestre-mestre, mestre e escravos, um servidor ativo que faz uso de DRDB (Distributed Replicated Block Device), ou um cluster baseado em um SAN (Storage Area Network ) (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Independentemente da forma como esto organizados os ns, preciso escolher a forma pela qual a carga do banco de dados ser dividida, e isto pode ser feito de duas formas: particionamento funcional e sharding dos dados. No particionamento funcional, cada n ca responsvel por uma tarefa ou um conjunto de tarefas distintas. Esta estratgia tende, entretanto, a ter limitaes, j que algumas funcionalidades podem crescer muito, necessitando de outras estratgias para a diviso da carga (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). O sharding ou particionamento de dados a abordagem mais comum e efetiva

152

para escalar grandes aplicaes em MySQL, e consiste em dividir os dados em pedaos menores (shards) e armazen-los em ns diferentes. O maior desao do sharding como encontrar e recuperar dados, para fazer isso preciso escolher o critrio ou a chave de partio mais adequada para denir onde os dados sero armazenados. importante ter em mente questes como a chance de uma consulta precisar acessar mais de um shard para que possa ser realizada, fato que pode aumentar o tempo de resposta. possvel fazer uso de vrias chaves de particionamento como, por exemplo, em um sistema de blog, as chaves poderiam ser o ID do usurio de dos posts, mantendo todos os posts de um mesmo usurio em um nico shard, bem como todos os comentrios de um mesmo post (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). No MySQL um shard pode ser tanto um banco de dados, com ou sem identicao do shard, ou ele pode ser uma ou mais tabelas com a identicao do seu shard dentro de um banco de dados que contm dados de vrios shards. Outro aspecto dos shards que precisa ser levado em conta o seu tamanho, sendo que recomendvel o uso de shards menores, pois eles levam menos tempo na hora de fazer um backup ou uma recuperao, e alteraes na estrutura do banco de dados iro comprometer uma quantidade muito menor de dados (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Uma das questes mais importantes no sharding de dados como os dados sero divididos atravs dos shards. Esta alocao feita atravs de uma funo que recebe como entrada a chave de particionamento e devolve o identicador do shard que contm o registro ou que ir armazen-lo, e ela pode ser xa, dinmica ou explcita (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Na alocao xa a funo utilizada leva em conta apenas a chave de particionamento e a quantidade de shards (ou buckets) que poder receber os dados (e.g., hashes e mdulo). Apesar de sua simplicidade e baixo overhead, a alocao fsica no leva em conta o balanceamento de carga, no d a liberdade de decidir onde alocar determinados dados e tambm implica na recriao de todos os hashes e realocao de muitos dados caso mais shards sejam adicionados (SCHWARTZ; ZAITSEV;

153

TKACHENKO; D.; LENTZ; BALLING, 2008). Para evitar estes problemas, a melhor opo a alocao dinmica. Com ela possvel escolher onde cada informao ser armazenada com um maior grau de granularidade, permitindo a atribuio de uma carga maior para servidores mais potentes, ou uma distribuio mais igualitria de carga caso os servidores sejam semelhantes, ou ainda agrupar dados com maior anidade para evitar consultas que precisem acessar vrios shards para serem executadas. Em alguns casos pode ser necessrio ainda fazer uso tanto da alocao dinmica como da xa, como quando o diretrio de mapeamento da alocao dinmica ca muito grande (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Uma terceira abordagem a alocao explcita, onde a identicao do shard faz parte do ID do registro, deixando a responsabilidade de particionar os dados por parte da aplicao. Ela pode ainda ser utilizada em conjunto com a alocao xa e dinmica (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Outro desao inerente ao sharding de dados a criao de IDs globalmente nicas, algo que no pode mais ser obtido atravs do AUTO_INCREMENT, j que existem vrias mquinas e haveriam duplicaes da chave-primria. Existem vrias estratgias para resolver este problema, algumas delas so: delimitar intervalos diferentes do auto incremento para cada um dos servidores, criar uma tabela para controlar o auto incremento em um n global, e utilizar uma combinao de valores para compor o ID (como o ID do shard e um valor auto incremento) (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Na seo 2.7.1 h uma descrio de como o Instagram fez para gerar chaves globalmente nicas em um sharding com o PostgreSQL. O sharding do MySQL, sem dvida alguma, acrescenta signicativa complexidade a uma aplicao, mas os benefcios provenientes de tal estratgia so recompensadores. E como no poderia ser diferente, existem algumas ferramentas que foram desenvolvidas no intuito de reduzir a complexidade da criao de shardings, como o Hibernate Shards e o HiveDB, ambos escritos em Java (SCHWARTZ; ZAIT-

154

SEV; TKACHENKO; D.; LENTZ; BALLING, 2008). A terceira e ltima opo escalar para trs o MySQL. Nesta abordagem dados antigos ou que no sero acessados com muita frequncia so movidos para tabelas diferentes. Sendo possvel fazer ainda uso de shards para separar dados mais populares dos menos populares (SCHWARTZ; ZAITSEV; TKACHENKO; D.; LENTZ; BALLING, 2008). Acima de qualquer uma destas abordagens, escalar um banco de dados consiste em identicar garglos, projetar uma infraestrutura pensando na escalabilidade e monitorar o banco de dados para vericar como ele est desempenhando (HENDERSON, 2006).

2.4.1.2 PostgreSQL

O PostgreSQL um banco de dados relacional open source com suporte a linguagem de consultas SQL. Ele possui caractersticas como transaes, subselects, views, chaves estrangeiras com integridade referencial , sosticado sistema de bloqueio (locking), tipos de dados denidos pelo usurio, herana, regras e MVCC (Multiversion concurrency control) (MATTHEW; STONES, 2005). Este banco de dados possui uma arquitetura cliente-servidor, no permitindo que clientes faam acesso direto aos seus dados, sendo que toda a comunicao com o banco de dados feita atravs do processo do banco de dados (MATTHEW; STONES, 2005). Quando se trata de desempenho entre bancos de dados open source, sempre houve um consenso de que o MySQL era melhor que o PostgreSQL, armao essa corroborada no passado por trabalhos como os de Delno, Nunes e Spoto (2005) e Pires, Nascimento e Salgado (2006). Para Matthew e Stones (2005), o PostgreSQL pode ser comparado, em alguns aspectos, a bancos de dados comerciais e muito embora existam bancos de dados com melhor desempenho, como o MySQL, isto feito as custas de vrias funcionalidades, como a garantia de que os dados armazenados

155

no sero perdidos. Para Smith (2010), o PostgreSQL mais do que adequado para grande parte dos casos de uso, sendo que ele apenas peca com relao a consultas muito complexas, como algumas das que compe a suite de testes TPC-H, onde bancos de dados como Oracle, DB2 e SQL Server so superiores. J com relao ao desempenho, o autor tambm arma que bancos de dados mais exveis como o MySQL podem ser mais adequados, ou mesmo os bancos de dados NoSQL, quando no h a necessidade de se utilizar consultas muito complexas. Com relao a escalabilidade do PostgreSQL, as medidas que podem ser tomadas se assemelham as realizadas no MySQL. Smith (2010, p. 16) coloca o seguinte ciclo de vida, geralmente seguido para escalar um banco de dados PostgreSQL, apesar de no ser uma regra j que existem diferentes necessidades em diferentes aplicaes:

1. Escolha do hardware para o banco de dados e teste do mesmo para vericar se ele desempenha de acordo com as expectativas. 2. Congurar algum nvel RAID, sistema de arquivos, e um layout em disco para tabelas e ndices. 3. Otimizar a congurao do servidor. 4. Monitorar o desempenho e tempo de execuo das consultas. 5. Melhorar a ecincia das consultas, e/ou adicionar ndices para aceler-las. 6. Introduzir pooling de conexes e cache de objetos para reduzir a carga no servidor de banco de dados. 7. Utilizar replicao de dados em vrios servidores para distribuir a carga de leitura. 8. Particionar dados em shards para distribuir a carga de escrita entre vrios servidores.

156

Na seo 2.7.1 feita uma descrio detalhada do caso do Instagram, que fez uso do PostgreSQL e precisou fazer sharding de seus dados para suportar o rpido crescimento do seu servio.

2.4.1.3 SQLite

O SQLite um banco de dados open source utilizado principalmente em dispositivos pequenos, como smartphones Android. Este banco de dados, ao contrrio da maioria, no necessita de instalao ou congurao, apenas o uso de algumas bibliotecas, de acordo com a plataforma. O SQLite tambm no possui um servidor, ao invs disso o banco de dados fornece apenas bibliotecas para a comunicao direta com o banco de dados, este sendo basicamente um arquivo no sistema de arquivos (GARGENTA, 2010). Como o prprio nome sugere, o SQLite tem suporte a linguagem SQL, alm de possuir suporte a transaes com todas as propriedades ACID, chaves estrangeiras (sendo que a vericao de integridade opcional e desativada em dispositivos Android) e triggers (MEDNIEKS; DORNIN; MEIKE; NAKAMURA, 2010).

2.4.2 NoSQL

Nos ltimos anos vrias aplicaes viram um rpido crescimento na quantidade de contedo gerado pelos usurios, criando novos desaos para o armazenamento, anlise e arquivamento de grandes quantidades de dados, muitas vezes conhecido por big data. Alm disso, os dados esto cada vez menos estruturados e esparsos. Estes desaos colocaram em questo a efetividade das tcnicas tradicionais de gerenciamento de dados e o uso de bancos de dados relacionais, devido as suas estruturas pouco exveis. Culminando no surgimento de uma nova classe de bancos de dados, conhecidos como NoSQL (TIWARI, 2011). O movimento NoSQL tem como principal objetivo encontrar alternativas para problemas que no podem ser resolvidos atravs dos bancos de dados relacionais.

157

O termo foi utilizado pela primeira vez em 1998 para se referir a um banco de dados relacional que no fazia uso da linguagem SQL. Entretanto, o termo s ganhou a conotao atual em 2009, passando ento a se referir a bancos de dados no relacionais, excluindo, entretanto, algumas tecnologias previamente existentes, como XML e bancos de dados orientados a objeto (STRAUCH, 2011). Na busca por alternativas ao bancos relacionais, algumas de suas caractersticas foram abandonadas em troca de outras. Lidar com grandes quantidades de dados com estabilidade e permitindo que aplicaes escalem a um custo baixo signica que caractersticas como a integridade garantida atravs de transaes e a exibilidade na criao de ndices e consultas nem sempre sero possveis (TIWARI, 2011). Enquanto que em algumas situaes a ausncia de algumas das propriedades ACID impensvel, existem casos onde a reduo da complexidade do banco de dados pode ser favorvel, dispensando mecanismos complexos que iriam garantir propriedades que nem sempre so necessrias. Bancos de dados NoSQL tambm possuem alto throughput de dados (STRAUCH, 2011). No Google, por exemplo, possvel processar 20 petabytes de dados armazenados no Bigtable atravs de MapReduce. Outra vantagem desta classe de bancos de dados que eles foram criados com a escalabilidade em mente, desta forma estas solues geralmente escalam horizontalmente com maior facilidade e com um hardware modesto (ao contrrio de mquinas de alta disponibilidade e de custos maiores ainda), permitindo o sharding dos dados com um esforo muito menor do que o necessrio para bancos de dados como o MySQL e sem o alto custo envolvido em bancos de dados proprietrios (STRAUCH, 2011). Outro motivo para o uso de bancos de dados NoSQL a ausncia da necessidade de usar mecanismos para mapeamento dos dados armazenados no banco de dados para que eles possam se adequar a linguagens orientadas a objetos, estes conhecidos como ORMs (Object-Relational Mapping) para bancos de dados relacionais. Tais mecanismos so desnecessrios pois, ou os dados so muito simples e dicilmente se beneciariam das funcionalidades fornecidas por bancos relacionais e pelo

158

SQL, ou a estrutura dos dados muito semelhante a orientada a objetos (STRAUCH, 2011). Empresas da Web 2.0 esto entre as proeminentes no uso das tecnologias NoSQL, sendo que o Google e a Amazon, atravs de artigos publicados descrevendo suas alternativas aos bancos de dados relacionais, foram os propulsores deste movimento. Hoje vrias empresas da Web as utilizam, principalmente pelo baixo custo e alta escalabilidade. Enquanto que tecnologias como o Oracle RAC (Real Application Cluster ) s conseguem entregar esta ltima caracterstica, mediante o uso do hardware e das conguraes certas, mas com custos que so proibitivos para boa parte das empresas, principalmente para start-ups (STRAUCH, 2011).

2.4.2.1 Conceitos

Escalar um banco de dados NoSQL signica, em grande parte das vezes, montar um sistema distribudo e geralmente traz algumas implicaes e trade-offs. Estas caractersticas compartilhadas pela maioria dos sistemas distribudos que compartilham dados expressada pelo teorema CAP, acrnimo que signica:

Consistency : indica se e quando um sistema est em um estado consistente aps a execuo de uma operao. Por exemplo, se uma atualizao feita em um escritor do sistema e todos os leitores do sistema conseguem ver esta atualizao imediatamente, o sistema consistente. Availability : o sistema deve permanecer disponvel mesmo aps a falha de ns ou indisponibilidade de algum hardware ou software. Partition Tolerance: habilidade de um sistema se manter operante mesmo com parties na rede, isolando alguns ns em ilhas. Podendo signicar ainda a capacidade de um sistema lidar com adio ou remoo de ns.

O que o teorema CAP arma que um sistema distribudo s poder escolher no mximo duas das trs propriedades acima descritas, criando assim trs alternativas

159

possveis. Sistemas que escolhem consistncia e tolerncia a partio em detrimento a disponibilidade possuem as propriedades ACID. J aqueles que deixam de lado a consistncia possuem as propriedades BASE. Existem ainda aqueles que escolhem consistncia e disponibilidade, como o Google Bigtable, podendo no funcionar corretamente em face de parties de rede (STRAUCH, 2011). As propriedades ACID j foram abordadas na descrio dos bancos de dados relacionais. Falta agora falar das propriedades BASE, que deixam relaxam as propriedades de consistncia e isolamento em troca de disponibilidade, graceful degradation e desempenho. BASE signica Basic Available, Soft-state, Eventual consistency, e pode ser traduzido em uma aplicao que est sempre funcionando, nem sempre est consistente, mas eventualmente estar em um estado conhecido (STRAUCH, 2011). Quando um sistema exige consistncia, no sentido de que toda a leitura precisa retornar, sem excees, os dados da ltima operao de escrita, independente do n onde as operaes ocorreram, isso signica que ambas as operaes (leitura e escrita) precisam ocorrer no mesmo n ou deve haver algum mecanismo, como commit de duas fases e protocolos de validao de cache para garantir tal propriedade. J a consistncia eventual relaxa estes requisitos, armando que em algum momento as operaes de escrita iro aparecer para os clientes que esto fazendo a leitura (STRAUCH, 2011). Quando se fala em consistncia eventual em um sistema, existem ainda algumas caractersticas e tcnicas que podem ser utilizadas para melhorar a experincia dos clientes, em alguns casos. Por exemplo, se um cliente efetua uma atualizao, dependendo do sistema, existe uma chance de que ele no veja as suas atualizaes instantaneamente, e isso pode gerar alguns problemas, fazendo com que o cliente pense que sua atualizao no aconteceu, fazendo-o enviar a atualizao novamente. Para resolver esta situao possvel adotar o princpio RYOW (Read Your Own Writes Leia Suas Prprias Escritas), que arma que clientes devem ver suas atulizaes imediatamente, mesmo que a atualizao ocorra em um servidor e a leitura em outra. Outra forma de conseguir isso atravs da consistncia de sesso, ou seja, um cliente associado a um nico servidor, garantindo assim que suas atualizaes

160

estejam visveis a ele (STRAUCH, 2011). A consistncia eventual levanta outras questes, j que um sistema pode ter ns em estados diferentes ao mesmo tempo, exigindo algum tipo de versionamento dos dados e alguma forma de comunicar atualizaes para outros ns. Vector clocks, diferentemente dos outros mtodos citados, no dependem de relgios sincronizados entre os ns, no necessitam de uma ordem total de revises para casual reasoning e no preciso armazenar e manter varis revises de um dado em vrios ns. Vector clocks podem ser utilizados para propagar estados entre os ns atravs do protocolo Gossip, este podendo operar tanto pelo modelo de transferncia de estado (State Transfer Model) como o de operaes (Operation Transfer Model). Atravs do protocolo Gossip entretanto, somente a consistncia eventual pode ser alcanada j que um cluster com n nodes ir demorar O(log n) rodadas para espalhar as atualizaes. Por outro lado, este mtodo prov escalabilidade ao sistema e evita pontos nicos de falha (SPOF) (STRAUCH, 2011). Bancos de dados NoSQL seguem as mesmas estratgias j discutidas para escalabilidade: clusterizao de servidores de banco de dados (usado normalmente em bancos de dados no projetados para serem distribudos), uso de rplicas e sharding. Strauch (2011) ainda cita o uso de cache em memria como uma estratgia para armazenamento de dados, que pode ser distribudo, removendo parte da carga do banco de dados principal. E como no poderia ser diferente, os mesmos desaos so infrentados nos bancos de dados NoSQL com relao ao sharding de dados, principalmente no que diz respeito ao mapeamento dos dados em servidores. Esta funo feita normalmente atravs de hashing, fazendo uso, por exemplo, da chave primria dos objetos para decidir em qual servidor o dado ser armazenado (STRAUCH, 2011).

partition = hash(o) mod n

with o = object to hash, n = number of nodes

(2.5)

161

A frmula 2.5 um exemplo de como a escolha da partio onde o objeto ser armazenado pode ser feita. Neste caso criada uma hash do objeto a ser armazenado e efetuada a operao de mdulo utilizando o nmero de ns disponveis. Entretanto, existe um problema com esta soluo, pois ela no leva em conta que ns podem aparecer e desaparecer a qualquer momento (falha no servidor, na rede, no banco de dados), fazendo com que alguns dados quem indisponveis (STRAUCH, 2011). Para resolver este problema existe o hash consistente, onde cada n do sistema recebe da funo de hashing um intervalo determinado, e todos os objetos que se enquadrarem neste intervalo sero ali armazenados. Estes intervalos so muito exveis, e isso signica que se um n sai do sistema, outros ns iro tomar conta do seu intervalo, da mesma forma que se um novo n se junta ao sistema, ele ir receber parte do intervalo de outro n. Isso permite que clientes calculem em que n determinado dado est sem a necessidade de um servidor de metadados, como h no Google File System (GFS) (STRAUCH, 2011).

Fonte: Strauch (2011, p. 40).

Figura 2.52: Exemplo de hashing consistente, antes e depois da entrada e sada de um n Na Figura 2.52 possvel visualizar um exemplo de hashing consistente, onde o anel da esquerda representa o estado inicial de um sistema com trs ns (A, B e C) e quatro objetos (1, 2, 3, 4). O anel funciona em sentido horrio, ou seja, cada objeto no anel est armazendo no n a sua esquerda. No anel da direita o n C saiu por

162

algum motivo e o anel D entrou no sistema. Este ltimo tomou metade dos objeotos do n A (um) e tambm passou a cuidar dos objetos do n C (STRAUCH, 2011). Sem muito esforo j possvel notar a falta de balanceamento na distribuio dos objetos entre os ns. Para superar isto, foi introduzido o conceito de ns virtuais. Agora cada n real pode ter um ou mais ns virtuais, de acordo com a sua capacidade de hardware e so os ns virtuais que recebero os intervalos de hashing. Ainda assim, o problema de indisponibilidade de dados no caso da sada de um n persiste. Para resolver mais este problema foi introduzido o fator de replicao (r), determinando que no apenas um n fsico que responsvel por um objeto, mas sim r ns fsicos (STRAUCH, 2011). A natureza dinmica dos ns em um sistema distribudo s pode ser alcanada atravs da comunicao entre eles. Cada vez que um novo n se junta ao sistema, ele precisa anunciar a sua chegada aos demais ns (ou adjacentes), para que estes ajustem suas propriedades de dados, cedendo parte para o n recm chegado, que pode copi-los de uma vez ou de forma assncrona. J quando um n sai do sistema, geralmente ele no d um aviso prvio (dependendo da situao que levou a sua sada), deixando a responsabilidade de notar a sada de um n para os demais, que devem se comunicar entre si periodicamente para perceber tais eventos. E uma vez notada a sada de um n, os demais precisam ajustar suas propriedades de objetos, trocando entre si dados (STRAUCH, 2011). Existem ainda outros dois aspectos que diferenciam bancos de dados NoSQL dos relacionais, que so a forma como os dados so armazenados e acessados em disco e a os modelos de consultas utilizados. A respeito do primeiro aspecto, ele determina como os dados sero acessados em disco, afetando diretamente o desempenho, alm de indicar que tipo de dados poder ser lido em blocos. Strauch (2011) cita quatro layouts para armazenamento:

Baseado em linhas: neste layout uma tabela serializada serializada com linhas inteiras sendo adicionadas ao m da tabela, facilitando o acesso a conjuntos de dados em uma nica operao de IO e tendo boa localidade de acesso a

163

diferentes colunas. Colunar: diferente do layout acima, neste as tabelas so serializadas adicionando ao nal colunas ao invs de linhas, beneciando operaes sobre colunas, muito teis em anlise de dados, mas ao custo de um desempenho sofrvel em operaes sobre linhas. Colunar com Grupos de Localidade: semelhante ao layout acima, mas introduz os grupos de localidade, permitindo que colunas sejam agrupadas quando se espera que elas sejam acessadas ao mesmo tempo. rvores LSM (Log Sctructured Merge): este layout constrasta com todos os outros descritos acima, pois ele no procura serializar estruturas de dados lgicas, mas sim utilizar a memmria e o disco de forma eciente, servindo tanto requisies de leitura como escrita de forma eciente, com alto desempenho e de forma segura. Os dados so armazenados em pedaos na memria (Memtables) e commit-logs so mantidos em disco para estes dados na memria, e de tempos em tempos os dados em memria so descarregados em disco em SSTables.

Fonte: Strauch (2011, p. 45).

Figura 2.53: Diferenas entre layouts de armazenamento.

A Figura 2.53 mostra a diferena dos trs primeiros layouts de armazenamento de dados com relao a forma como as linhas e colunas so serializadas e adicionadas na tabela. J com relao as funcionalidades de consulta em bancos de dados NoSQL, elas so muito variadas, partindo de simples lookups de chaves primrias, como o caso dos bancos de dados de chave/valor. Existem ainda tcnicas como o scatter/gather, onde uma consulta enviada para vrios ns do banco de dados e posteriormente os resultados retornados so processados e entregues ao cliente. E o

164

MapReduce, introduzido pelo Google em 2004, onde pedaos de dados so designados a determinados ns que iro executar uma funo map e devolver um resultado, e este ser processado por mquinas atravs da funo reduce para criar o resultado nal (STRAUCH, 2011). Nas prximas sees sero abordados os principais tipos de bancos de dados NoSQL, dando exemplos em cada uma das categorias.

2.4.2.2 Key/Value Stores

Bancos de dados de chave/valor utilizam um modelo de dados bem simples, geralmente um map (ou HashMap) ou dicionrio (ou array associativo), onde clientes armazenam e requisitam valores atravs de chaves. Estas chaves so nicas e geralmente esto limitadas a uma certa quantidade de bytes. Este tipo de banco de dados muito eciente (big O(1)) e favorece para a alta escalabilidade sobre a consistncia, omitindo na maior parte dos casos funcionalidades muito elaboradas para consultas e anlise (como joins e agregaes) (TIWARI, 2011; STRAUCH, 2011). E apesar de o termo NoSQL ser relativamente novo, bancos de dados de chave/valor j existem a um bom tempo, como o Berkeley DB, e no segmento de sistemas de cache, aplicaes como EHCache e memcached tambm seguem a idia dos bancos de dados de chave/valor, apesar de no permitirem, em alguns casos, a persistncia dos dados. Apesar disto, os bancos de dados que surgiram recentemente so inspirados em outro banco de dados, o Amazon Dynamo (STRAUCH, 2011). O Dynamo foi criado em um contexto onde muitos servidores esto distribudos geogrcamente, hardware comum utilizado, falhas em componentes so situaes normais, e a losoa de SOA fortemente aplicada. Este banco de dados particionado atravs de hashing consistente em conjunto com replicao, os objetos nele armazenados so versionados, alm de alguns mecanismos para garantia de consistncia de dados durante atualizaes, deteco de falhas atravs de um protocolo baseado em gossip que permite adicionar e remover servidores com o mnimo de trabalho manual (STRAUCH, 2011).

165

Grande parte destes bancos de dados compartilham uma interface semelhante, consistindo basicamente de um mtodo para salvar pares chave/valor (set(key, value) ou put), outro mtodo para recuper-los (get(key)) e um terceiro para removlos (delete(key)). Alm do Amazon Dynamo, existem outros sistemas como Project Voldemort, Tokyo Cabinet, Redis, Memcached e MemcacheDB, e Scalaris (STRAUCH, 2011).

2.4.2.3 Document Databases

Bancos de dados orientados a documentos so considerados o prximo passo aps aqueles de chave/valor, permitindo o armazenamento de informaes mais complexas, com pares de chave/valor sendo armazenados na forma de documentos, normalmente adotando o formato JSON. Nestes bancos de dados possvel ter documentos diferentes em uma mesma coleo e ainda criar ndices no apenas para a chave, mas tambm para campos do documento (TIWARI, 2011; STRAUCH, 2011). Dentre as opes open source disponveis, o MongoDB e o CouchDB so as mais proeminentes. Ambos permitem a replicao de dados, mas apenas o MongoDB fornece uma soluo pensada para sharding de dados, j com o CouchDB a situao semelhante ao MySQL. O MongoDB fornece ainda uma linguagem de consultas, estas feitas atravs de objetos BSON (semelhantes ao JSON), permitindo ainda execuo de funes JavaScript no servidor ou de MapReduce (STRAUCH, 2011).

2.4.2.4 Column-Oriented Databases

Bancos de dados orientados a colunas, como a Figura 2.53 mostrou, armazenam os dados por colunas ao invs de linhas, como nos bancos de dados relacionais. Esta abordagem surgiu na anlise de dados e business intelligence com o uso de armazenamento em colunas em arquiteturas shared-nothing, criando uma arquitetura de processamento altamente paralela para aplicaes de alto desempenho (STRAUCH, 2011).

166

Bancos de dados orientados a colunas, entretanto, so menos puristas do que produtos pensados para o business intelligence, como Sybase IQ e Vertica, sendo que alguns inclusive misturam orientao a coluna como orientao a linhas. O mais notvel exemplo deste tipo de banco de dados o Google Bigtable, que serviu posteriormente como inspirao para outros bancos de dados do mesmo tipo, como o Hypertable e HBase (STRAUCH, 2011).

2.5 WEB SERVICES

Como Richardson, Ruby e Hansson (2007) colocam, a Web est cheia de informaes e servios. O que a diferencia de Web Services a forma como estes servios e informaes so consumidas. Ao invs de serem consumidas por pessoas na forma de HTML formatado por navegadores, as informaes so apresentadas na forma de XML ou JSON ou outro formato que possa ser compreendido por mquinas. Para Daigneau (2010), servios podem ser considerados qualquer funo de software que carregue alguma tarefa de negcio, como a execuo de alguma transao ou acesso a determinados arquivos. Neste contexto, servios podem ser utilizados atravs de vrias aplicaes, promovendo a reutilizao de componentes e a colaborao entre sistemas. E muito embora existam tecnologias que permitam a integrao de sistemas, como CORBA, DCOM e RMI, web services procuram fornecer uma integrao entre sistemas dependendo apenas de HTTP, permitindo o uso de plataformas distintas e no dependendo de tecnologias proprietrias e/ou restritivas. Web services so tecnologias que suprem vrias das necessidades que surgiram com os sistemas e arquiteturas orientados a servios, vistos na seo 2.3.4.1, substituindo (ou se tornando uma alternativa) as tecnologias proprietrias de middleware, promovendo o foco na simplicidade e interoperabilidade (GORTON, 2011). A forma como o protocolo HTTP utilizado dene o tipo de arquitetura ao qual a tecnologia de web services pertence. Alguns utilizam o HTTP apenas como meio de transporte de dados (com outros protocolos funcionando sobre o HTTP), outros o utilizam como um protocolo completo para as aplicaes, e outros ainda fazem uma

167

mistura das duas opes descritas anteriormente (DAIGNEAU, 2010). Estas trs arquiteturas, bem como as tecnologias por elas utilizadas, sero abordadas nas sees a seguir.

2.5.1 RPC-Style

Na arquitetura RPC (Remote Procedure Call), clientes enviam mensagens para servidores remotos (os web services, neste caso) e aguardam pela resposta. Estas mensagens contm o mtodo (procedimento ou funo) que dever ser executado no servidor, bem como possveis argumentos. Quando o servidor recebe a mensagem, ele verica a validade da mesma (como vericar se o mtodo existe ou se a quantidade de argumentos est correta), faz a chamada do mtodo e retorna para o cliente o resultado da chamada (DAIGNEAU, 2010). Este tipo de web service pode ou no fazer uso de HTTP como meio de transporte, geralmente o fazendo por ser o meio mais popular. Vale lembrar que aqui o HTTP utilizado apenas como um envelope que ir transportar as informaes da tecnologia que a utiliza para realizar as chamadas remotas e devolver os resultados de acordo. SOAP (Simple Object Access Protocol) tambm considerado um envelope para web services no estilo RPC, sendo que normalmente SOAP utilizado sob o protocolo HTTP (RICHARDSON; RUBY; HANSSON, 2007). Existem algumas controvrsias com relao a classicao de web services que utilizam SOAP como arquiteturas RPC, sob a armao de que SOAP orientado a mensagens ou documentos. Richardson, Ruby e Hansson (2007) argumenta que na realidade qulquer web service orientado a mensagens, isso porque HTTP orientado a mensagens. Mas o que torna SOAP uma arquitetura RPC o fato de que as informaes nele contidas, no formato XML, assim como o corpo de mensagens HTTP, descrevem chamadas RPC, assim como em tecnologias XML-RPC. No que diz respeito ao protocolo HTTP, arquiteturas RPC geralmente utilizam apenas uma URL (endpoint) por onde todas as chamadas sero recebidas, geral-

168

mente se utiliza um endpoint por "entidade"ou classe. Isso provavelmente pela existncia de frameworks como JAX-WS e WCF (para Java e C#, respectivamente) que permitem a criao de web services a partir de anotaes em classes de uma aplicao (DAIGNEAU, 2010; BELL, 2009). Obviamente, o uso destas ferramentas na gerao de web services, apesar da vantagem de esconderem toda a complexidade inerente, resultam em servios complexos, difceis de debugar, que utilizam muito mais CPU e banda (comparado com servios RESTful) e que exigem que clientes utilizem um setup igual para funcionarem (RICHARDSON; RUBY; HANSSON, 2007). Como Bell (2009) coloca, este tipo de arquitetura implica no uso de outros servios como SOAP e especicaes de web services, chamadas por Richardson, Ruby e Hansson (2007) de selos XML (WS-*) que so colocados nos envelopes SOAP, anlogo aos cabealhos em HTTP, aumentando a complexidade de implementao de web services. Alm disso, a maioria dos web services SOAP utilizam WSDLs (Web Service Description Language, vocabulrios em XML) para descrever os servios, algo dispensvel mas altamente recomendvel, j que servios SOAP sem um WSDL seriam muito difceis de se utilizar, como armam (RICHARDSON; RUBY; HANSSON, 2007). Esta arquitetura de longe a mais complexa de todas, denindo diversos padres (conhecidos como WS-*, Web service stack ou SOAP stack standards) para descrio dos servios (WSDL), descrio do esquema XML utilizado (XSD), descoberta de servios (UDDI), segurana dos servios (WS-Security, WS-Policy) e gerenciamento dos servios (WS Reliability, WS Transaction, WS Addressing) (BEAN, 2010). Outra crtica feita a tecnologias que fazem uso de SOAP est exatamente em uma das vantagens deste protocolo, que a idependncia de transporte, ou seja, ele pode ser transportado tanto por HTTP, como instant messaging, SMTP, TCP puro ou qualquer outro protocolo. Na realidade, grande parte das aplicaes SOAP utilizam o protocolo HTTP, entretanto, como SOAP independente de protocolo, ele no faz uso dos cdigos de status do HTTP, utiliza apenas os mtodos GET e POST e as URLs

169

so utilizadas apenas para identicar endpoints para o web service, evitando ainda o uso de cache de requisies HTTP (RICHARDSON; RUBY; HANSSON, 2007).

2.5.2 REST-RPC

Esta arquitetura na verdade um meio termo entre arquiteturas RPC e RESTful, pois utilizam tecnologias RPC mas tambm fazem uso mais apropriado das funcionalidades do protocolo HTTP. Por exemplo, alguns web services, apesar de continuarem funcionando com base em chamadas de mtodos, passam o nome do mtodo e os argumentos atravs de parmetros da URL, ao invs de arquivos XML (RICHARDSON; RUBY; HANSSON, 2007). Alguns destes web services so chamados de HTTP+POX (HTTP plus Plain Old XML), ou seja, arquiteturas que fazem uso hbrido de RPC e REST, mas no dependem de documentos XML encapsulados atravs de SOAP. Na verdade, muitos destes web services nem chega a usar XML, oferencendo formatos como JSON, texto puro ou arquivos binrios (RICHARDSON; RUBY; HANSSON, 2007).

2.5.3 RESTful

REST (REpresentational State Transfer ) no se trata de uma tecnologia, mas de uma losoa, ou mais tecnicamente, de um estilo de arquitetura introduzido por Roy Fielding em sua tese de doutorado. Esta arquitetura descreve as fundaes da World Wide Web, compostas por tecnologias como HTTP, URI (Uniform Resource Indentier ), HTML, XML e JSON (ALLAMARAJU, 2010). RESTful Web Services utilizam o protocolo HTTP como base nica e suciente para a criao de aplicaes expostas na forma de servios, focando na identicao e disposio de recursos ao invs da troca individual de transaes (BEAN, 2010; GORTON, 2011). Este estilo de arquitetura descrito por Fielding (2000) consiste em um conjunto de restries aplicados a elementos que fazem parte desta arquitetura. Estas restri-

170

es compe uma arquitetura cliente-servidor, sem estado (stateless), com cache de respostas no lado do cliente, interface uniforme (contendo quatro restries de interface, descritas no pargrafo a seguir), com um sistema em camadas, e com cdigo sob demanda (capacidade de baixar funcionalidades adicionais, como scripts). As restries impostas pela interface uniforme na arquitetura da Web impe que a informao deve mover-se do local onde est armazenada para o local onde ser utilizada, ao contrrio de outros paradigmas de processamento distribudo, onde o agente processador movido para onde os dados est armazenados. Para manter a separao de responsabilidades entre o cliente e o servidor, a arquitetura REST permite o uso de metadados para identicar tipos de dados de um recurso, limitando o escopo para uma interface padronizada. Desta forma o cliente informa os formatos suportados/desejados e o servidor ir servi-lo dentro de suas capacidades, devolvendo uma representao deste recurso que pode ser no formato original ou em algum formato derivado, e que em ambos os casos permanecer escondido atrs da interface (FIELDING, 2000). Os elementos de dados no REST, segundo Fielding (2000), so: recursos, intenticador do recurso, representao, metadados da representao, metadados do recurso e dados de controle. Recursos so parte fundamental de sistemas Web, ao ponto de esta ser conhecida como orientada a recursos (WEBBER; PARASTATIDIS; ROBINSON, 2010). Na verdade, Richardson, Ruby e Hansson (2007) defendem a diferenciao entre REST e ROA (Resource Oriented Architecture), pois REST trata-se de um conjunto de critrios de projeto independentes de tecnologia, enquanto que ROA est diretamente relacionado a web services RESTful. Para o autor, recurso qualquer coisa importante o suciente para ser referenciada como algo por si s, algo que possa ser armazenado em um computador e representado como um uxo de bits. Ou como Fielding (2000) arma, qualquer informao que pode ser nomeada pode ser um recurso. Em REST recursos podem ser estticos ou no, mas a nica coisa que deve permanecer imutvel em um recurso a semntica do mapeamento, ou seja, aquilo

171

que distingue um recurso de outro. A identicao destes recursos feita atravs das URIs (FIELDING, 2000). Elas so o nome e o endereo de um recurso, e mais, recursos s passam a existir quando possuirem uma ou mais URIs (RICHARDSON; RUBY; HANSSON, 2007). Um identicador pode estar associado a uma ou mais representaes de um recurso, que so tranformaes ou uma viso do estado de um recurso em determinado momento. Estas vises podem ser codicadas em formatos como HTML, XML, JSON, Atom, texto puro, MP3 ou JPEG. importante notar que no REST recursos nunca so acessados diretamente, mas atravs do intermdio de representaes (WEBBER; PARASTATIDIS; ROBINSON, 2010). Em conjunto com a representao, esto os metadados que descrevem esta representao. Um destes metadados o tipo de dados (media type) da representao. A escolha do formato da representao feita atravs do mecanismo de negociao de contedo da Web. Alguns frameworks, como o Rails popularizaram a utilizao de extenses na URI para identicar o formato desejado (e.g., .xml ou .json). E muito embora esta abordagem explicta possa parecer mais conveniente, a Web possui meios mais sosticados para a escolha do formato de representao de recursos, sem a necessidade de existirem URIs diferentes apontando para o mesmo recurso (FIELDING, 2000; WEBBER; PARASTATIDIS; ROBINSON, 2010). A negociao de contedo no se limita, entretanto, ao formato da representao do recurso. Ela pode ser utilizada tambm para a escolha da linguagem de preferncia, para os casos onde um recurso est disponvel em mais de uma linguagem. Estas informaes so armazenadas nos cabealhos das requisies, sendo que o servidor pode ou no atend-las (RICHARDSON; RUBY; HANSSON, 2007). Diferentemente de Webber, Parastatidis e Robinson (2010), Richardson, Ruby e Hansson (2007) no fazem objees ao uso da identicao do formato da representao na URI, como advoca o framework Rails. Muito pelo contrrio, os autores do preferncia a esta abordagem por acreditarem que informaes contidas na URI so mais teis do que metadados contidos em cabealhos, apesar de julgarem ambas

172

abordagens como RESTful. Com os meios para identicar e representar recursos, resta saber como interagir com eles. O protocolo HTTP fornece um conjunto pequeno mas suciente de verbos que so utilizados na interao com recursos, algo conhecido como interface uniforme, e que possui uma semntica bem denida e aceita para aplicaes distribudas. Os verbos mais conhecidos do HTTP so: GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, CONNECT e PATCH (WEBBER; PARASTATIDIS; ROBINSON, 2010). Basicamente, os verbos mais utilizados so quatro, para realizar as quatro operaes mais comuns:

GET: para obter a representao de um recurso. PUT: para criar recursos com uma nova URI ou modicar recursos existentes. POST: para criar recursos com uma URI existente. DELETE: para deletar um recurso existente.

Em conjunto com os verbos esto os cdigos de resposta, como 200 OK, 201 Created e 404 Not Found (classicao na Figura 2.54) . Juntos eles formam uma framework para a operao de recursos sob a rede (WEBBER; PARASTATIDIS; ROBINSON, 2010).

Fonte: Masse (2011, p. 28).

Figura 2.54: Categorias de cdigos de status HTTP. Como fora descrito anteriormente, em REST as interaes entre cliente-servidor no possuem estados ou sesses. Por outro lado, estados podem ser armazenados

173

nos clientes atravs dos links que esto sendo acessados. O servidor capaz de guiar o caminho do cliente atravs do que chamado de hypermedia, que so links e formulrios dentro de representaes de hipertexto. Isso permite que recursos estejam altamente conectados uns com os outros atravs destes links, algo mais difcil de se obter em web services (RICHARDSON; RUBY; HANSSON, 2007). Normalmente, clientes fazem uso de APIs (Application Programming Interfaces) para acessar web services, facilitando o seu acesso atravs de uma interface bem denida. Quando uma API exposta na Web e segue os princpios REST acima descritos, esta pode ser chamada de uma REST API, tornando o web service RESTful (MASSE, 2011).

2.5.4 Autenticao e Autorizao

A autenticao o mecanismo atravs do qual sistemas iro identicar de forma segura seus usurios. Na autenticao os sistemas esto preocupados em saber quem o usurio e se ele realmente quem ele arma ser. Por outro lado, a autorizao se preocupa em saber qual o nvel de acesso que esse usurio possui dentro do sistema, garantindo que ele possa executar tarefas ou visualizar apenas informaes sobre as quais ele tem permisso (CARTER, 2012).

2.5.4.1 HTTP: Autenticao Bsica

Grande parte da comunicao na Internet entre browsers, servidores e aplicaes web ocorre atravs do protocolo HTTP (Hypertext Transfer Protocol). Este protocolo fornece meios de realizar autenticao para o acesso de recursos de forma nativa, atravs do fornecimento de um nome de usurio e senha (GOURLEY; TOTTY, 2002). Uma das desvantagens de se usar autenticao bsica devido a necessidade de o cliente efetuar a autenticao com o cliente toda vez que ele precisar acessar um recurso. Alm disso, as credenciais do usurios no so protegidas, apenas

174

codicadas o mtodo Base-64, podendo desta forma ser capturados durante a transmisso pela rede. O protocolo HTTP permite, entretanto, o uso de digest authentication, uma forma mais segura de enviar a senha de forma segura. Ainda assim, existem outros protocolos, como TPS (Transport Secure Layer ) e HTTPS (Secure HTTP), que devem ser utilizados quando da necessidade de maior segurana (GOURLEY; TOTTY, 2002).

Fonte: Gourley e Totty (2002, cap. 12).

Figura 2.55: Exemplo bsico de autenticao HTTP. A Figura 2.55 mostra um exemplo bsico de autenticao utilizando HTTP. Neste caso, o usurio requisita ao servidor uma foto, o servidor ento responde com o cdigo 401, signicando que o usurio deve se autenticar para acessar o recurso. Como neste caso o cliente um browser, quando este recebe a resposta do servidor ele exibe um dilogo requisitando um nome de usurio e senha para o usurio. Quando o usurio d estas informaes ao browser, este une as informaes com dois pontos e codica a string utilizando o mtodo Base-64 e ento envia para o servidor no cabealho de autenticao. O servidor decodica as informaes, verica se elas esto corretas e ento devolve o recurso requisitado, mensagem com o cdigo 200 (GOURLEY; TOTTY, 2002). Utilizar a autenticao bsica signica que o cliente utilizado pelo usurio precisar armazenar as informaes de usurio e senha para que no precise requisitar estes dados ao usurio em cada requisio. O problema que nem sempre estes clientes, como uma aplicao web, fazem uso das melhores prticas na hora de armazenar tais informaes. Um usurio, portanto, precisa conar na empresa que fornece este aplicativo, para que possam lhes fornecer dados de autenticao de outro servio

175

que por eles ser utilizado. Alm disso, se o usurio troca sua senha em um servio, o cliente que acessa o servio pelo usurio precisar requisitar a nova senha para o usurio (LEBLANC, 2011). Outro problema com este mtodo que no existe um meio para controlar quais aplicaes esto acessando a conta de um usurio em um servio, problema inexistente em mtodos baseados em tokens (LEBLANC, 2011). Bell (2009) arma que entregar as informaes de autenticao (usurio e senha) para terceiros um antipattern, pois estas aplicaes so capazes de agir como se fossem o prprio usurio, tendo acesso a todas as suas informaes e podendo realizar todas as aes possveis. Todas estas decincias existentes tanto no mtodo em si como na implementao da autenticao de aplicaes de terceiros so tratadas no protocolo OAuth, assunto tratado na prxima seo.

2.5.4.2 OAuth

OAuth (Open Authorization) um protocolo aberto, baseado em HTTP, para autorizao segura utilizando uma abordagem consistente para todos os clientes. Ele permite que um usurio d permisso de acesso a recursos privados, como fotos e informaes de perl armazenados em um site, para outros sites, sem a necessidade de fornecer para estes seu nome de usurio e senha (MASSE, 2011). Este protocolo gerenciado pelo OAuth Working Group que faz parte do IETF e tem dentre seus membros, empresas como Google, Microsoft, Facebook, Twitter e Yahoo (MASSE, 2011). A primeira verso do protocolo, 1.0, que veio a se tornar posteriormente a RFC 5849 foi baseada nos protocolos criados pelo Flickr e Google. O OAuth consiste na obteno de um token atravs da permisso do usurio e o uso deste token para acessar recursos protegidos do usurio. Os mtodos de obteno do token so conhecidos como ows e no princpio eram trs: aplicaes web, clientes desktop e

176

dispositivos mveis e limitados. Com o tempo os trs ows foram reunidos em um nico ow, deciso que acabou por degradar a experincia do usurio em clientes desktop e dispositivos mveis (HAMMER, 2010). Mas primeira verso do protocolo no apresentava uma experincia ruim apenas para o usurio nal. A necessidade de gerenciar estados nas vrias fases do protocolo, alm do armazenamento de credenciais temporrias e uso de credenciais com longa durao, e que so consequentemente menos seguras, mostraram que o protocolo no escalava muito bem do ponto de vista dos provedores de servio (HAMMER, 2010). Com a introduo da verso 2.0 do protocolo, muitos destes problemas foram corrigidos. Agora existem 6 ows diferentes: user-agent ow, como clientes rodando em web browsers; web server ow, para clientes residentes em aplicaes web; device ow, para clientes em dispositivos limitados, mas onde o usurio tenha acesso a um browser em outro dispositivo; username and password ow, apenas em casos onde o usurio cona no cliente; client credentials ow, onde o cliente faz uso de suas credenciais para obter um token de acesso (2-legged); ou assertion ow, onde o cliente apresenta uma declarao, que pode ser em SAML (Security Assertion Markup Language), para o servidor de autorizao em troca de um token de acesso (HAMMER, 2010). Alm dos novos ows introduzidos, a segunda verso do protocolo prov uma opo de autenticao sem a necessidade de criptograa, permitindo que chamadas de API sejam feitas usando o prprio token como o secret, ao invs de requisies assinadas com HMAC e secret tokens (HAMMER, 2010). Com relao aos tokens de longa durao, o protocolo agora apresenta um refresh token de longa durao e tokens de acesso de curta durao. Assim usurios autorizam uma aplicao apenas uma vez e esta utiliza o refresh token para requisitar tokens de acesso, estes com curto tempo de vida, sem a necessidade de envolver novamente o usurio (HAMMER, 2010).

177

Fonte: Google (2012).

Figura 2.56: Autorizao de aplicao no Google utilizando OAuth2.

A Figura 2.56 mostra um exemplo de uma aplicao que requisita ao usurio acesso aos seus dados armazenados no Google. Para ter acesso as APIs do Google, aplicaes precisam ser registradas primeiramente no APIs Console, para que obtenham o client_id, client_secret alm de outras informaes. Para que aplicaes acessem as APIs do Google, antes elas precisam de um token de acesso, que ir possui uma validade e um conjunto de permisses (GOOGLE, 2012). Para obter este token de acesso, antes o usurio precisa informar suas credenciais do Google para que ento d as permisses para o aplicativo. Aplicaes web podem fazer isso atravs de uma janela que redireciona o usurio para o site do Google, e aplicaes instaladas em dispositivos sem um browser podem fazer fazer requisies atravs de um web service. Uma vez que a aplicao tenha em mos o token de acesso, ela poder us-lo para fazer requisies informaes do usurio (GOOGLE, 2012).

178

2.6 FERRAMENTAS DE DESENVOLVIMENTO

Enquanto que nas sees anteriores foram abordados conceitos mais abstratos sobre os assuntos que abrangem este trabalho, nas sees seguir sero descritas as vrias opes de tecnologias para a construo deste servio.

2.6.1 Linguagens de Programao

Esta seo ir descrever algumas das principais linguagens de programao utilizadas para o desenvolvimento de aplicaes Web.

2.6.1.1 Javascript

JavaScript conhecida como a linguagem da Web, sendo utilizada em conjunto com o HTML e o CSS para a construo de pginas web. Ela uma linguagem de alto nvel, dinmica, interpretada e de tipagem fraca, com suporte aos paradigmas orientado a objetos, imperativo e funcional. A nica semelhana com Java est na sua sintaxe, sendo que outras caractersticas derivam de linguagens como Scheme e Self (FLANAGAN, 2011). Esta linguagem foi criada pela Netscape nos primrdios da Web, tendo sido submetida para padronizao pelo ECMA (European Computer Manufacturers Association), passando ento a ser conhecida como ECMAScript (atualmente na verso 5), devido principalmente ao fato de JavaScript ser uma marca registrada da Sun Microsystems (agora parte da Oracle) (FLANAGAN, 2011). Dos tempos em que as conexes com a internet eram lentas a linguagem foi muito til evitando comunicaes desnecessrias e consequentes longas esperas pelas respostas dos servidores, como na validao de formulrios. De l para c as aplicaes web evoluram signicativamente, bem como os engines JavaScript que passaram de interpretadores para compiladores (JIT OU just-in-time, como o V8, Nitro e TraceMonkey) (ZAKAS, 2010).

179

Esta evoluo nos engines JavaScript foi necessria devido a complexidade crescente das aplicaes na linguagem, compostas cada dia por mais linhas de cdigo e bibliotecas mais ricas em funcionalidades (ZAKAS, 2010; MACCAW, 2011). As funcionalidades disponveis para a linguagem comearam com bilbiotecas como GWT e ext.js, fornecendo uma abstrao com relao a JavaScript para o desenvolvedor, alm de provr vrios componentes visuais para a construo de interfaces, muitas vezes semelhantes a aplicaes desktop (algo questionvel, no mnimo), alm do famoso Ajax, que permitia a realizao de chamadas ao servidor de forma assncrona (NORTH, 2011). Neste mesmo tempo surgiam frameworks como prototype e YUI, elas servem de suporte no desenvolvimento de aplicaes, fornecendo vrias funes e helpers, alm de permitirem o desenvolvimento orientado a objetos de forma simplicada. Posteriormente surgiria o jQuery, este mais simples do que os frameworks anterirores, buscando facilitar o tratamento de eventos, manipulao do DOM e chamadas ao servidor (NORTH, 2011). Com o advento do HTML5, JavaScript s veio a ganhar mais poder, abrindo caminho para uma nova gama de aplicaes, com funcionalidades como localStorage, grcos 2D e 3D, audio, vdeo, web sockets e geolocalizao (PILGRIM, 2010). Navegadores como o Google Chrome se tornaram a nica ferramenta necessria para o desenvolvimento de aplicaes (alm de um editor de textos, claro), permitindo debugar JavaScript (console.log ao resgate) e visualizar o estado atual da rvore DOM e realizar modicaes nela a partir do prprio navegador (NORTH, 2011). Mas a evoluo do JavaScript no para por a, pois o prximo passo desta linguagem foi ir para o lado servidor (da fora). Grande parte das aplicaes Web fazem I/O bloqueante, ou seja, a cada chamada de I/O (e.g., banco de dados, rede) a thread onde a aplicao est sendo executada precisa esperar o retorno da funo para continuar o uxo de execuo. Uma das maneiras de driblar esta limitao atravs

180

de thread concorrentes. Entretanto, elas adicionam complexidade as aplicaes, esto mais sujeitas a erros e algumas estratgias precisam ser utilizadas para lidar com variveis compartilhadas, competio entre threads, e evitar deadlocks. Alm disso, o uso de threads vem com um custo, reetido em maior uso de memria e de CPU (troca de contextos pode custar caro) (HERRON, 2011). Ryan Dahl percebeu que seria muito mais simples lidar com este problema atravs de eventos. Desta forma, cada vez que uma chamada I/O era feita, uma funo de callback criada pelo programador estaria responsvel por receber o resultado da chamada, de forma assncrona. Agora as chamadas a I/O retornam imediatamente e s passam a ser tratadas quando o resultado for retornado (NORTH, 2011). E para implementar uma soluo, nada melhor do que uma linguagem que incorpora o paradigma de eventos como o JavaScript. O ambiente foi montado em cima da engine V8, removendo funcionalidades DOM e de navegadores, e adicionando acesso ao sistema de arquivos, sockets e rede, criando o que conhecido por Node.js (NORTH, 2011). Agora se tornou possvel desenvolver aplicaes web com apenas uma linguagem, tanto no lado servidor como no cliente. Mas mais do que isso, o ambiente ao redor do Node.js repleto de bibliotecas e servidores web semelhantes ao Sinatra, conectores para bancos de dados e suportes para protocolos como IMAP, SMTP e LDAP, e tudo disponvel atravs de um gerenciador de pacotes, o npm (HERRON, 2011; NORTH, 2011). O Node.js capaz de servir mais requisies por segundo do que algumas conguraes utilizadas para servidores web, muito embora existam casos onde apenas depois de algumas otimizaes ele possa desempenhar melhor. Existe ainda a ideia de que os callbacks no devem demorar muito tempo para retornar (algo em torno de 5ms), do contrrio o desempenho do Node.js tende a cair muito. Pequenas aplicaes tendem, por consequncia, a tirar vantagem desta caracterstica, enquanto que em aplicaes maiores o uso ou no de Node.js deixa de ser relevante, dando destaque para a arquitetura utilizada como um todo (HERRON, 2011).

181

Alm de sua presena na programao do lado servidor, o formato para serializao de dados JSON (JavaScript Object Notation) tem sido adotado largamente como uma alternativa ao XML para transferncia de dados, como em web services. O formato tambm utilizado pelos bancos de dados CouchDB e MongoDB (este usa uma variante chamada BSON (Binary JSON)). O MongoDB ainda suporta JavaScript para a execuo de consultas e o CouchDB d suporte a linguagem para criao de consultas atravs de views (NORTH, 2011). Por m, surgiram recentemente algumas linguagens intermedirias que compilam para JavaScript como o CoffeScript, que muito semelhante a JavaScript, mas possui menos sintaxe, sendo at mais elegante. A linguagem Clojure tambm possui um compilador, o ClojureScript, que tambm compila para JavaScript (NORTH, 2011). E como Crockford (2008) coloca, apesar de seus defeitos, seu modelo de programao fora de moda e seu nome ridculo, o fato de a linguagem ter sido adotada por todos os navegadores e a Web ter se tornado o que hoje, JavaScript conseguiu se tornar a linguagem mais popular do mundo e os exemplos acima citados apenas servem de exemplo de como a linguagem tem crescido.

2.6.1.2 Python

Python uma linguagem de programao open source interpretada, interativa, orietada a objetos de alto nvel e propsito geral que pode ser utilizada em diferentes classes de problemas. Ela tambm altamente portvel, sendo suportada pelas plataformas Windows, Linux/Unix, Mac OS X, alm de Java e .NET (PYTHON, 2012). Lutz (2010) coloca algumas das vantages desta linguagem: qualidade de software, devido ao foco na facilidade de leitura do cdigo, reusabilidade e manuteno do mesmo; produtividade, fator que aumenta com o uso de linguagens interpretadas, sem contar que em Python programas possuem muito menos linhas do que em linguagens compiladas; a capacidade de portar scripts para vrias plataformas sem necessidade de reescrever cdigo; grande quantidade de funcionalidades distribudas atravs da biblioteca padro do Python, como o NumPy, que pode ser comparado ao Matlab; a

182

capacidade de integrar componentes externos escritos em C/C++, alm de acesso atravs de interfaces como SOAP, XML-RPC e CORBA. Uma das desvantagens bem conhecida das linguagens interpretadas a perda de desempenho com relao a linguagens compiladas como C e C++. Com Python no deixa de ser diferente, j que todo cdigo fonte compilado para byte codes para depois serem interpretados. A seu favor, ainda possvel escrever funes em C na forma de extenses e utiliz-las em programas escritos em Python, sem perder o desempenho das linguagens compiladas (LUTZ, 2010). Com Python possvel ainda ter acesso a diversas funcionalidades do sistema operacional sem, entretanto, perder a caracterstica da portabilidade, j que estas funes utilizam a interface POSIX. Para desenvolver aplicaes web, Python fornece funcionalidades para comunicao atravs de sockets, lidar com HTML e XML, e fazer chamadas atravs a web services, alm de possuir uma grande quantidade de frameworks para o desenvolvimento de aplicaes web (LUTZ, 2010). Em Python, aplicaes web podem ser implantadas de vrias formas. Uma delas atravs do mdulo mod_python para o servidor Apache. Uma alternativa mais exvel e que veio crescendo nos ltimos anos o WSGI (Web Server Gateway Interface) e o mod_wsgi, um protocolo que serve como ponte entre a aplicao escrita em Python e qualquer servidor Web, como Apache, Nginx, CherryPy e lighttpd. Alm da exibilidade, esta abordagem utiliza menos memria e apresenta melhor desempenho com relao ao mod_python. E a terceira opo mdulo up, que funciona como o WSGI, alm de suportar algo similar ao protocolo FastCGI (FORCIER; BISSEX; CHUN, 2009). A linguagem possui ainda suporte para os principais bancos de dados relacionais, alm dos NoSQL. Grande parte destas implementaes seguem a DB API que dene uma interface comum para o acesso a bancos de dados, permitindo a substituio do SGBD sem muitas alteraes ( claro, isso inclui qualquer expresso SQL particular ao SGBD). Existe ainda o ZODB, um banco de dados orientado a objetos, alm de ORMs, como SQLObject e SQLAlchemy (LUTZ, 2010).

183

Com relao a orientao a objetos, a linguagem suporta polimorsmo, operator overloading (conhecido ainda como polimorsmo ad hoc, que permite modicar o comportamento de operadores com base nos argumentos informados) e mltipla herana. Mas nada impede que o desenvolvedor utilize a programao procedural, ou ainda ambas, se achar necessrio, e at porque orientao a objetos no a resposta para todos os problemas (LUTZ, 2010). A linguagem ainda caracterizada por ser de tipagem dinmica, possuir um garbage collector, estruturas de dados como listas, dicionrios e strings, operaes para concatenao, diviso, classicao, mapeamento, sem contar na grande quantidade de bibliotecas utilitrias e bibliotecas de terceiros que servem para os mais diversos propsitos. Sem contar que a linguagem possui este nome em homenagem a srie de comdia da BBC Monty Pythons Flying Circus (LUTZ, 2010).

2.6.1.3 Ruby

Ruby uma linguagem de programao dinmica puramente orientada a objetos, mas como suporte aos paradigmas procedural e funcional, alm de possuir poderosas funcionalidades de metaprogramao e que pode ser utilizada para a criao de DSLs (Domain-Specic Languages). A linguagem foi criada por Yukihiro Matsumoto (a.k.a. Matz), tendo como inspirao Lisp, Smalltalk e Perl, utilizando uma gramtica familiar para programadores de C e Java (FLANAGAN; MATSUMOTO, 2008). A linguagem no possui uma especicao formalizada, tendo como referncia portanto o interpretador disponvel em ruby-lang.org conhecido como MRI (que pode vir a ser Matz Ruby Implementation). Na versoo 1.9 este interpretador foi unido como o YARV (Yet Another Ruby Virtual machine), criando uma nova referncia que compila o cdigo fonte para bytecode e ento executa este bytecode em uma mquina virtual (FLANAGAN; MATSUMOTO, 2008). Alm da implementao de referncia, existe uma implementao para a JVM, chamada JRuby. Tambm h uma implementao para a plataforma .NET, IronRuby. Alm de alternativas como o Rubinius, com uma VM escrita em C++, e o Cardinal, que

184

faz uso da VM Parrot, utilizada pelo Perl 6. A linguagem possui ainda um sistema para gerenciamento de pacotes (ou mdulos) chamado RubyGems. Ele vem instalado por padro a partir da verso 1.9 da linguagem e pode ser instalado em verses anteriores (FLANAGAN; MATSUMOTO, 2008).

2.6.2 Frameworks

Frameworks so conjuntos de classes que cooperam entre si para criar um design que possa ser reutilizado em determinados tipos de software. Uma das principais vantagens de um frameworks que ele j dene a arquitetura do software, a estrutura da aplicao, a organizao das classes, como ser a comunicao entre os componentes, como esta arquitetura ser dividida e que responsabilidades cada parte da arquitetura ter (GAMMA; HELM; JOHNSON; VLISSIDES, 1998). Muitos frameworks ditam regras especcas que devem ser seguidas para que a aplicao funcione de acordo, como boas prticas e convenes. E se por um lado isto possa soar inexvel, estas caractersticas tornam o desenvolvimento muito mais rpido, e como boa parte das decises de design j foram tomadas, resta apenas criar as classes e outros componentes necessrios para que a aplicao comece a funcionar. Obviamente, estas regras tiram parte da liberdade e criatividade de quem est projetando/desenvolvendo a aplicao, dando em troca rapidez, padronizao e maior facilidade de compreenso do funcionamento da aplicao (GAMMA; HELM; JOHNSON; VLISSIDES, 1998). Alguns frameworks permitem, entretanto, a congurao de certas funcionalidades, dando espao para a customizao da aplicao e adio de partes no conformantes com as regras ditadas pelo framework. Muitos frameworks fazem ainda uso extensivo de patterns para denir determinadas estruturas da aplicao, provendo assim nveis mais altos de design a reuso de cdigo (GAMMA; HELM; JOHNSON; VLISSIDES, 1998). Esta inexibilidade dos frameworks em parte por causo do uso da Inverso de Controle, onde o framework ca responsvel por todo o uxo de controle da apli-

185

cao, e apenas as partes congurveis dele podem ser adaptadas. Estas partes geralmente fazem uso de interfaces e classes abstratas, como parte da conformncia com as regras denidas pelo framework e tambm como meio de fornecer funes teis no desenvolvimento (VOGEL; ARNOLD; CHUGHTAI; KEHRER, 2011).

2.6.2.1 Ruby on Rails

Rails uma framework para desenvolvimento de aplicaes Web escrita na linguagem de programao Ruby. Ao invs de adotar uma abordagem neutra com relao ao desenvolvimento de aplicaes, esta framework assume vrias coisas sobre vrias partes de uma aplicao, acreditando na existncia da melhor forma ou da forma mais adequada de se fazer algo (RUBY; THOMAS; HANSSON; BREEDT, 2009). Dentre os princpios que guiam a losoa do Rails esto: DRY (Dont Repeat Yourself, repetir cdigo no algo bom (o famoso copiar e colar); Convention Over Conguration, a framework faz vrias suposies no desenvolvimento de aplicaes ao invs de exigir vrios arquivos de congurao que especiquem detalhes da aplicao; e REST a melhor forma de se desenvolver aplicaes para a Web (RUBY; THOMAS; HANSSON; BREEDT, 2009). O Rails adota a arquitetura MVC para a construo de aplicaes, possuindo uma implementao prpria do pattern Active Record, onde cada classe do model corresponde a uma tabela do banco de dados e onde a lgica de negcio reside (RUBY; THOMAS; HANSSON; BREEDT, 2009).

2.6.2.2 Microframeworks

Micro-frameworks, assim como os dois exemplos acima citados, e assim como grande parte das frameworks para web, seguem o pattern Model-View-Controller, mas diferem no quesito exibilidade. Enquanto frameworks como RoR, Django, Spring e Symfony fornecem um ambiente completo para a construo e gerenciamento de

186

aplicaes, outras frameworks, como Sinatra, web.py, Bottle, Flask, Express, e vrias outras inspiradas no Sinatra, seguem um caminho mais simples, fornecendo apenas o bsico para colocar uma aplicao na web (STREICHER, 2009). As micro-frameworks do mais liberdade para os desenvolvedores, permitindolhes fazer mais escolhas sobre o que utilizar em um projeto, como qual ORM utilizar (isso se quiser utilizar uma), qual engine para templates ser usado, se ir usar CSS puro ou alguma ferramenta para compilar para CSS (e.g., Saas e Less), dentre muitos outros aspectos. Na maioria das frameworks que seguem esta losoa, a criao de recursos para a web feita em apenas uma linha, identicando o verbo HTTP permitido e a URL pela qual o recurso estar disponvel (STREICHER, 2009). No nal das contas, a escolha entre uma framework "tradicional"ou uma microframework vai depender muito de cada projeto e da equipe que o compe, pois se por um lado micro-frameworks pregam a simplicidade, elas tambm deixam muitas responsabilidades nas mos dos desenvolvedores, enquanto que frameworks como Ruby on Rails facilitam o desenvolvimento seguindo regras pr-determinadas (mas nada impede que algum deixe de segu-las).

2.6.3 Sistemas de Controle de Verso

Um sistema de controle de verso (VCS Version Control System) um sistema que gerencia e registra diferentes verses de um software ou qualquer outro tipo de contedo, permitindo o acesso ao histrico de verses/revises, bem como os logs de todas as modicaes efetuadas (LOELIGER, 2009). Chacon (2009) divide os sistemas de controle de verso em trs tipos: locais, centralizados e distribudos. No primeiro deles, todos os arquivos do projeto, bem como o banco de dados contendo os registros das modicaes destes arquivos so armazenados localmente. Uma das ferramentas mais populares deste tipo o RCS (Revision Control System), criado no comeo dos anos 80 por Walter Tichy (LOELIGER, 2009).

187

O segundo tipo de VCS o centralizado, consistindo em um servidor que contm todas as verses dos arquivos e em clientes que fazem o checkout destes arquivos. Este tipo de sistema permitiu que vrios desenvolvedores pudessem colaborar no desenvolvimento de um mesmo software, alm de dar controle sobre o que cada um deles est contribuindo. Por outro lado, a centralizao destes sistemas introduziu um ponto nico de falha, ou seja, se por algum motivo o servidor parasse de funcionar, ningum conseguiria colaborar ou salvar suas contribuies. E mais, se ocorresse alguma falha com o servidor, toda a histria do projeto estaria perdida, caso no houvesse backup dos dados. Sistemas como CVS, Subversion e Perforce so classicados neste tipo (CHACON, 2009). O ltimo tipo de VCS o distribudo, representado por sistemas como Git, Mercurial, Bazaar e Darcs. Em um sistema de controle de verso distribudo clientes no fazem checkout apenas da ltima reviso do repositrio, mas sim do repositrio completo. Assim, contrastando com os sistemas centralizados, se algum servidor falhar (caso haja um servidor), qualquer repositrio de qualquer um dos clientes pode ser utilizado como backup (CHACON, 2009). Nas prximas sees sero feitas breves introdues a dois dos principais sistemas de controle de verso distribudos, Git e Mercurial.

2.6.3.1 Git

O Git um sistema de controle de verses distribudo (DVCS Distributed Version Control System), permitindo que desenvolvedores em qualquer lugar do mundo possam criar e modicar um projeto e depois combinar suas alteraes, sem a necessidade de um repositrio central (LOELIGER, 2009). O Git foi criado em 2005 por Linus Torvalds para dar suporte ao desenvolvimento do kernel do Linux, em face as restries impostas pela empresa dona do BitKeeper, sistema de controle de verses utilizado at ento. No tendo encontrado nenhuma alternativa a altura, Linus Torvalds decidiu desenvolver o seu prprio VCS (Version Control System) (LOELIGER, 2009).

188

Loeliger (2009) e Chacon (2009) citam como principais caractersticas do Git:

Desenvolvimento distribudo facilitado: permite desenvolvimento em paralelo, independente e simultneo, sem a necessidade de sincronizar constantemente com um repositrio central, e por consequncia, permitindo o desenvolvimento mesmo estando ofine. Escalabilidade: capacidade de lidar com uma grande quantidade de desenvolvedores, permitindo a integrao do seu trabalho de forma convel. Rapidez e ecincia: o kernel do Linux possui grande quantidade de desenvolvedores, e como consequncia, grande nmero de atualizaes so feitas. O Git foi construdo para ser eciente, tanto localmente como em rede, utilizando tcnicas para compresso de dados. Integridade e conana: o Git mantm a integridade dos dados, bem como garante que estes no foram alterados enquanto transitavam de um desenvolvedor para outro. Forar contabilidade: o Git obriga os desenvolvedores a prestarem contas das suas modicaes, sempre exigindo um log das alteraes efetuadas, garantindo a identicao de quem alterou o que e porqu. Imutabilidade: uma vez feita uma alterao e gravada no banco de dados do Git, ela no pode ser alterada. A forma como o Git armazena as modicaes tambm diferente da maioria dos outros VCSs, ele tira snapshots do sistema de arquivos ao invs de criar um banco de dados das modicaes feitas em um arquivo, facilitando, dentra vrias coisas, a comparao de arquivos. Transaes atmicas: o Git segue o princpio do tudo ou nada com relao as operaes nele realizadas, evitando desta forma que o repositrio que em um estado corrupto ou invlido. Suporte a desenvolvimento em branches: o Git facilita a criao de ramicaes de um nico projeto, bem como a unicao destas ramicaes (merging).

189

Repositrios completos: cada desenvolvedor de um projeto possui uma cpia local do repositrio, contendo todas as revises j feitas nele, evitando a consulta a um repositrio central para visualizar o seu histrico. Open Source.

O banco de dados onde toda a histria de um projeto armazenada, no Git, chamado de repositrio. Este repositrio composto por dois tipos de estruturas de dados: o armazenamento de objetos e o ndice. A primeira destas estruturas ca responsvel pelo armazenamento dos arquivos do projeto, mensagens de log, informaes do autor do projeto, datas e qualquer outra informao utilizada para recriar qualquer verso ou branch do projeto (LOELIGER, 2009). Estes objetos podem ser blobs (Binary Large Object), que armazenam qualquer arquivo, independentemente do seu contedo e tipo; trees, rvores que representam um nvel em um diretrio, contendo referncias a arquivos e outros diretrios, permitindo a construo de toda a hierarquia de um diretrio; commits, objeto que contm informaes sobre quais alteraes foram introduzidas, quem as introduziu e quando, a mensagem de log deixada e uma referncia a um objeto tree indicando todas as modicaes realizadas no commit, cada commit aponta ainda para um commit pai, exceto se ele for o primeiro commit; e tags, que serve para identicar objetos atravs de um nome que pode ser lido por humanos (LOELIGER, 2009). A outra estrutura de um repoistrio o ndice, para explicar como ele funciona, entretanto, preciso antes explicar os trs estados pelos quais um arquivo pode passar dentro de um projeto. Como fora dito anteriormente, o repositrio o responsvel por armazenar toda a histria de um projeto e toda vez que uma pessoa faz um clone de um projeto para outro computador, isto que copiado. O repositrio de um projeto reside na pasta .git e geralmente ela ocultada do usurio, e o que o usurio v a verso atual do projeto ou a verso a qual ele fez checkout, esta residindo no diretrio de trabalho do projeto, como mostra a Figura 2.57. a que entra o ndice, ele ca responsvel por registrar todas as alteraes feitas no diretrio de trabalho, informaes que sero utilizadas para o prximo commit. Este estado conhecido como

190

Fonte: Chacon (2009, p. 8).

Figura 2.57: Os trs estgios dos arquivos no Git.

staging e uma vez feito o commit dos arquivos neste estado, eles so armazenados no repositrio (CHACON, 2009). interessante notar ainda a forma como o Git armazena objetos. Ao invs de utilizar o nome do arquivo e seu diretrio, ele armazena os objetos criando uma hash do seu contedo utilizando o algoritmo SHA1, da mesma forma que outros bancos de dados de chave/valor (CHACON, 2009). Desta forma, o Git mantm uma cpia de todos os arquivos e toda a vez que um deles modicado, uma nova cpia salva no repositrio, j que modicaes no arquivo implicam em uma nova hash calculada. E mais, se dois arquivos em diretrios distintos possuem o mesmo contedo eles sero armazenados em apenas um objeto, j que a hash para eles calculada ser a mesma (LOELIGER, 2009). A Figura 2.58 mostra a disposio dos objetos no primeiro e segundo commits de um projeto. No lado esquerdo est o primeiro commit do projeto (8675309), apontado tambm pela tag com o nome V1.0 e pelo branch master. Cada commit aponta para uma tree, e neste caso esta tree contm dois objetos blob. Quando um

191

Fonte: Loeliger (2009, p. 34-35).

Figura 2.58: Objetos no primeiro e segundo commits.

segundo commit introduzido, o branch master passa a apontar para o novo commit (cafed00d), e este aponta para o seu pai (8675309). Este segundo commit adicionou um novo arquivo ao projeto e manteve os dois arquivos anteriores, sendo assim a sua tree aponta para os dois blobs criados no commit anterior e cria um novo blob para o terceiro arquivo (LOELIGER, 2009).

2.6.3.2 Mercurial

O Mercurial, assim como o Git, um sistema de controle de verso distribudo criado em 2005, que segundo OSullivan (2009) fcil de aprender e usar, leve, escalvel, e de fcil customizao, podendo ser utilizado tanto em projetos pequenos, com at mesmo um desenvolvedor, como em projetos grandes, com centenas ou milhares de desenvolvedores. Tanto o Mercurial como o Git possuem caractersticas que foram inuenciadas

192

pelo Monotone. Mas dentre as diferenas entre as duas ferramentas, OSullivan (2009) coloca a reputao do Git de ser difcil de aprender, enquanto que o Mercurial tem foco na simplicidade. A favor do Git est o desempenho, j que escrito em C, em contraste com o Mercurial, escrito em Python. Ainda assim, com relao aos repositrios, no Git os metadados armazenados precisam ser periodicamente reenpacotados (repack ) para evitar a degradao do desempenho devido ao aumento do espao utilizado em disco, podendo resultar em backups demorados. Mas o Git no se sobressai em todos os tipos de operaes com relao ao desempenho, havendo casos onde o Mercurial superior. Sem contar que o suporte do Git ao Windows muito inferior ao fornecido pelo Mercurial. Como OSullivan (2009) coloca, repositrios no Git so muito maiores do que no Mercurial, exceto quando comprimidos (repack ). Isso se deve a forma como cada um dos sistemas utiliza para manter o registro das alteraes em arquivos. Enquanto que o Git armazena cpias completas dos arquivos em blobs, o Mercurial armazena apenas as modicaes que precisam ser feitas no arquivo para transformar uma reviso antiga na nova reviso. A abordagem utilizada pelo Git se justica pois isso torna a comparao ou mesmo criao de um snapshot de alguma reviso em particular rpida. Sistemas que utilizam deltas, como o Mercurial o faz, demoram muito tempo para recriar uma reviso pois eles utilizam o primeiro snapshot do projeto e aplicam em cima dele as alteraes feitas pelas revises subsequentes at chegar na reviso desejada. Entretanto, o Mercurial resolveu este problema criando novos snapshots do projeto quando determinado limite de deltas atingido. Isso permite que o Mercurial reconstrua qualquer reviso de um arquivo ou do projeto com rapidez, mantendo o tamanho do repositrio menor do que em sistemas como o Git (OSULLIVAN, 2009). Cada reviso (ou changeset) identicada por uma string hexadecimal que a identica atravs de todas as cpias do repositrio, diferente do nmero de reviso, vlido apenas para um repositrio em particular. As modicaes so armazenadas em um arquivo chamado lelog, que contm tanto as informaes para a reconstruo de uma reviso como um ndice para facilitar a busca por revises. Existe ainda o

193

Fonte: OSullivan (2009, p. 47).

Figura 2.59: Relacionamento entre os metadados no Mercurial.

changelog, ele contm informaes sobre os changesets, como quem fez o commit, quando e qual comentrio foi deixado. Assim como no Git, cada changeset aponta para changeset pai, podendo ainda apontar para mais de um pai no caso de um merge. Chagesets possuem, alm do identicador hexadecimal (que uma hash dos dados no changelog), uma hash dos dados que representa. Esta hash no visvel para o usurio nal e tem como nalidade, alm de vericar se revises esto corrompidas, identicar revises (OSULLIVAN, 2009). No Mercurial changesets no apontam diretamente para os arquivos criados ou modicados, mas sim para um manifest. Cada entrada no manifest identica os arquivos presentes no changeset, a reviso de cada arquivo e outros metadados. Quando um arquivo no alterado de uma verso para outra, ambas as revises iro apontar para o mesmo arquivo. A Figura 2.59 demonstra exatamente como o relacionamento entre estes metadados funciona. Filelogs armazenam todas as revises existentes de um arquivo e um manifest pode fazer referncia a vrios lelogs e em qualquer uma de suas revises (OSULLIVAN, 2009).

194

2.6.4 Object Cache

De todos os componentes de um sistema, talvez o mais complicado de escalar seja o banco de dados, se tornando em muitas aplicaes um garglo. Uma das tcnicas mais utilizadas para aliviar a carga dele, para dar mais tempo at a tomada de medidas mais extremas, o uso de um cache de objetos. Este cache ir armazenar (normalmente na memria, por ser mais rpida) qualquer consulta feita no banco de dados que seja computacionalmente cara e/ou que tenha grandes chances de ser requisitada vrias vezes (ABBOTT; FISHER, 2011). O cache, na realidade, pode ser utilizado para armazenar praticamente qualquer coisa e no apenas consultas a bancos de dados, como objetos inteiros de determinada linguagem de programao. Quando o cache para o banco de dados, ele geralmente reside entre o banco de dados e a aplicao, vericando se as consultas j esto em cache, e caso negativo, consultando o banco de dados, armazenando o resultado em cache e devolvendo-o para o cliente (ABBOTT; FISHER, 2011). A descrio acima pode ser melhor compreendida atravs da Figura 2.60. Em ambos os casos a aplicao faz suas consultas atravs do cache e este verica se os dados esto nele armazenados ou no. O que difere as duas abordagens a forma como os dados no cache iro expirar. No caso da esquerda todas os dados armazenados possuem um timeout, ou seja, a partir da hora de insero no cache (timestamp) eles possuem um tempo de vida, quando esse tempo expira eles so removidos do cache. J na segunda abordagem necessria alguma ao externa para que os dados no cache sejam invalidados (SCHLOSSNAGLE, 2006). No primeiro caso, a aplicao de um timeout nico para todos os objetos injusto, considerando que muitos deles podem ser requisitados por vrios usurios, ou se mantenham inalterados por um bom tempo. Alm disso, existem dados que mudam constantemente e no pode car no cache por muito tempo, outros so pouco acessados pelos usurios e acabam ocupando espao em memria de forma desnecessria. O ideal seria ento manter os objetos em cache indeterminadamente, at que uma mudana seja feita neles, para que eles ento sejam invlidados (purged)

195

Fonte: Schlossnagle (2006).

Figura 2.60: Cache baseado em timeout e invalidao explcita.

(SCHLOSSNAGLE, 2006). A realidade, obviamente, no se mostra to simples assim. Existem casos onde a aplicao de cache complicada e pode exigir um pouco mais de trabalho, principalmente em aplicaes customizadas para cada um dos seus usurios e com atualizaes constantes. Existem duas formas de se dispr o cache em uma aplicao. A primeira delas consiste em fazer acessos ao cache diretamente da aplicao e quando o objeto a ser consultado no estiver no cache (cache miss), acessar o banco de dados, exatamente como fora explicado anteriormente. Esta abordagem pode aumentar a complexidade do cdigo, algo que resolvido de uma segunda forma, atravs da criao de uma camada de cache. Isso conhecido como write-through cache, onde, diferentemente da Figura 2.60, as operaes de escrita no banco de dados tambm passam pelo cache. Mas neste caso a aplicao s se comunica com a camada de cache, deixando para esta a responsabilidade sobre a invalidao dos objetos. Com o uso de uma camada exclusiva para o cache possvel, por exemplo, adiar a escrita dos dados no

196

banco de dados, criando uma espcie de buffer, para fazer commits em lotes. Mas como nem tudo perfeito, agora a camada de cache que precisa lidar com questes relacionadas ao banco de dados, como transaes, MVCC, failover e recuperao (HENDERSON, 2006). possvel ainda utilizar vrios servidores para fazer cache de objetos, colocando na frente deles uma balanceador de carga, este garantindo que no haver duplicao de objetos no cache, aumentando a capacidade total de armazenamento e por consequncia a taxa de cache hits (HENDERSON, 2006). De forma resumida, o uso do cache para objetos do banco de dados ir melhorar a escalabilidade do sistema, distribuindo parte da carga de consultas entre os servidores de cache; dar exibilidade ao sistema, como o uso do cache apenas para determinados usurios, lhes dando um melhor QoS (Quality of Service); aumentando a disponibilidade em casos onde o banco de dados est fora do ar, mas os dados requisitados pelos usurios continuam em cache; e aumentando o desempenho do sistema, j que boa parte das leituras ser feita em memria ao invs de disco, alm da possibilidade de tirar vantagem de padres de localidade na carga do sistema e de amenizar picos de carga (LUO; KRISHNAMURTHY; MOHAN; PIRAHESH; WOO; LINDSAY; NAUGHTON, 2002).

2.6.4.1 memcached

Memcached um sistema de cache distribudo e de alto desempenho para uso genrico, apesar de ter sido concebido originalmente para acelerar aplicaes web aleviando a carga do banco de dados. Foi criado em 2003 por Brad Fitzpatrick para o LiveJournal (MEMCACHED, 2012). Dentre as vantagens do memcached est o acesso rpido as informaes, j que elas esto armazenadas na memria RAM. No existem restries com relao as informaes que podem ser armazenadas como valor no memcached. Falhas em um dos servidores de cache tambm no afetam o funcionamento do resto do sistema, podendo no mximo aumentar a taxa de cache misses (MYSQL, 2012).

197

Com o memcached possvel congurar quantos servidores forem necessrios para cache, podendo este ser tanto um servidor dedicado como um utilizado para outros propsitos, e obter memria de cache total igual a soma da quantidade de memria cedida para cada uma das instncias do memcached, uma estratgia muito melhor do que o uso de cache isolado para cada servidor de aplicao, por exemplo (MEMCACHED, 2012).

2.6.4.2 Redis

Redis um software open source para armazenamento de chave/valor. Os dados nele armazenados ca em memria e podem ser, opcionalmente, persistidos em disco. Dada a sua exibilidade, ele pode ser utilizado tanto para armazenar dados, como para cache ou servidor de mensagens (REDIS, 2012; SANFILIPPO, 2010). Nele possvel armazenar, alm de strings, hashes, listas, conjuntos e conjuntos ordenados. O Redis permite ainda a execuo de operaes atmicas nestes dados, como adicionar ao nal de uma string, incrementar o valor de uma hash, adicionar itens a uma lista, interseco, unio e diferena de conjuntos, ou obter o membro de um conjunto ordenado com maior ranking (REDIS, 2012).

2.6.5 Search Server

Search servers ou servidores de busca so software utilizados para a implementao de buscas, como buscas textuais. Nestes sistemas, fazendo uma analogia aos bancos de dados, tabelas so ndices, registros so documentos e colunas so campos e atributos (AKSYONOFF, 2011). Servidores de busca podem fornecer vrias formas para se selecionar documentos, atravs de vrios critrios, com o uso de at mesmo linguagens de consulta. Buscas textuais podem incluir buscas booleanas, buscas frasais, buscas por proximidade e buscas em campos especcos de um documento (AKSYONOFF, 2011). Nas prximas sees sero detalhados os dois search servers mais conheci-

198

dos no mercado, ambos open source e utilizados por grandes servios da Internet.

2.6.5.1 Sphinx

Sphinx um full-text search engine, ou para evitar confuses com servios de busca, um servidore de buscas. Ele pode ser utilizado para vrias tarefas relacionadas com busca, indexando desde posts de um blog at colees com bilhes de documentos, servindo desde algumas buscas dirias at mais de 200 milhes de consultas, como o caso do Craiglist (AKSYONOFF, 2011). O Sphinx suporta uma grande quantidade de fontes de dados, como bancos de dados relacionais, e na prtica, contanto que algum consiga construir um proxy para intermediar a importao de dados (da fonte de dados para XML e ento para o Sphinx), qualquer fonte de dados pode ser utilizada. O software possui um indexer, este encarregado de recuperar dados da fonte de dados e index-los. Ele precisa ser executado periodicamente para indexar novos dados ou dados modicados recentemente (delta reindexing), abordagem conhecida como batch indexing. Alternativamente, possvel seguir o indexamento incremental ou em tempo real, onde cada nova informao armazenada na fonte de dados imediatamente indexada, ou ao menos entregue ao servidor de buscas para que este realize a indexao o mais rpido possvel (AKSYONOFF, 2011).

Fonte: Aksyonoff (2011, p. 19).

Figura 2.61: Interao entre aplicao, Sphinx e banco de dados.

199

Outra gura importante no Sphinx o searchd, com ele que os clientes fazem a comunicao, requisitando buscas e esperando pelos resultados. Este componente utiliza os ndices criados para processar as consultas de busca, bem como executar processamentos adicionais nos dados, como ltragens, odernaes e agrupamentos. Quando a arquitetura de busca distribuda, este componente o responsvel pela comunicao com seus pares remotos para construir o resultado de busca (AKSYONOFF, 2011). A Figura 2.61 exemplica este uxo de dados entre as partes de uma aplicao com Sphinx e fonte de dados relacional. Nesta gura a abordagem utilizada para indexamento a em lotes, quando o indexamento for em tempo real, entretanto, o indexer no envolvido. Nestes casos, os dados so entregues pela aplicao diretamente para o searchd (AKSYONOFF, 2011).

2.6.5.2 Solr

Solr um servidor de buscas open source utilizado por grandes servios como CNET, Zappos e Netix. O Solr escrito em Java e por baixo utiliza a engine Lucene, uma biblioteca para buscas em textos. A comunicao com o servidor entretanto, no exige o uso de Java, j que disponibilizada uma interface atravs de HTTP, com as informaes sendo dispostas em XML ou JSON (PUGH, 2011). O Lucene faz o indexamento de documentos, que so conjuntos de chave/valor contendo texto ou nmeros. O Lucene utiliza um analizador de textos congurado previamente para tokenizar o texto em um campo, quebrando-o em tokens (palavras) para ento transform-los em stems (a raiz da palavra), algo conhecido por stemming, alm da substituio de sinnimos e outros processamentos. Ao nal do processo, os tokens so chamados de termos e todo o processo descrito acima, de anlise de textos. O Lucene faz uso de ndices invertidos, armazenados em disco, que mapeiam os termos em um campo de um documento, identicando ainda a posio da palavra no texto original. Estes ndices so utilizados posteriormente para que o Lucene encontre os resultados das buscas e atribua pesos (ranking) para os resultados, retornando aqueles com maiores valores (PUGH, 2011).

200

Em cima de todas estas funcionalidades est o Solr. Ele permite que uma srie de conguraes, como denies de tipos de ndices e campos, sejam denidas. Ele faz uso de vrios tipos de cache para garantir melhores tempos de resposta para buscas, fornece uma interface web de administrao com estatsticas de busca e desempenho de cache, ferramenta de diagnstico e um browser do schema de busca (PUGH, 2011). O Solr ainda permite a realizao de buscas geoespaciais para ltragem de documentos e ordenao por distncia, um parser de consultas mais fcil de utilizar pelo usurio nal do que o fornecido pelo Lucene, capacidade de realizar buscas distribudas e replicao de ndices para escalar a aplicao, e uma ferramenta para importao de dados de bancos de dados, e-mails e arquivos (PUGH, 2011).

2.6.6 Servidores de Aplicao

Servidores de aplicao so componentes de uma infraestrutura responsveis pela lgica de negcio de uma aplicao e geralmente cam atrs de um servidor HTTP. Eles podem prover funcionalidades como validao de parmetros, consulta a banco de dados, comunicao com sistemas backend e renderizao de templates (ERB, 2012). No mundo Java existem vrios servidores de aplicaes, como Tomcat, Glasssh, JBoss e WebSphere, que so implementaes da especicao da Plataforma Java Enterprise Edition. Linguagens de script como PHP, Ruby e Python tambm podem estar contidos em servidores de aplicao, que so na verdade servidores HTTP especcos para aquela linguagem e/ou framework, sendo que alguns servidores ainda fornecem uma framework prpria para o desenvolvimento de aplicaes web, como o caso do Tornado, um servidor Web no-bloqueante escrito em Python (TORNADO, 2012). A comunicao entre servidores web e frameworks em linguagens como Python, Ruby e Perl ocorre atravs de interfaces padronizadas, sendo para os exemplos acima citados respectivamente, WSGI (Web Server Gateway Interface), Rack e PSGI (Perl

201

Web Server Gateway Interface) (FORCIER; BISSEX; CHUN, 2008; RUBY; THOMAS; HANSSON; BREEDT, 2009).

2.6.7 Servidores HTTP

Servidores HTTP so responsveis pelo recebimento e resposta requisies vindas de uma rede. Enquanto que servidores de aplicao so responsveis por questes relacionadas a lgica do negocio, servidores HTTP podem se preocupar com questes como segurana (encriptao de comunicao via SSL/TLS), persistncia de conexes e balanceamento de carga para os servidores de aplicao (ERB, 2012). Com relao a esta ltima responsabilidade, isso torna o servidor HTTP tambm um servidor de proxy reverso, signicando que para um cliente haver apenas um servidor, mas atrs deste podem haver centenas de servidores de aplicao servindo os clientes. Proxies reversos podem implementar ainda cache para determinados recursos, possibilitando a ele servir recursos aos clientes sem a necessidade de fazer requisies para servidores de aplicao (ERB, 2012). Atualmente o servidor web mais popular o Apache, seguido pelo Microsoft IIS e nginx. Nas prximas sees sero detalhados dois destes servidores HTTP, ambos open source (NETCRAFT, 2012).

2.6.7.1 Apache

O Apache foi baseado no software da NCSA httpd 1.3, tendo sido completamente reescrito para acomodar funcionalidades como estrutura modular e uma API que permitisse melhor extensibilidade, alocao de memria baseada em pools e um modelo adaptativo de pre-fork de processos (APACHE, 2012a). A comunicao com o sistema operacional no feita diretamente pelo core do Apache, sendo esta tarefa dada a um mdulo conhecido como MPM (Multi-Processing Module, permitindo assim a abstrao de funcionalidades especcas de um sistema

202

operacional. Este mdulo implementa um servidor hbrido multi-processos e multithreads (KEW, 2007; APACHE, 2012b). O modo de funcionamento do MPM vai depender do sistema operacional onde o Apache est instalado. Na plataforma Windows, por exemplo, o Apache funciona apenas com o Worker, que cria novos threads para lidar com as requisies. Enquanto que sistemas da famlia UNIX possuem como padro o Prefork e o Worker, alm do Event (KEW, 2007). O Prefork a opo mais segura das trs e recomendado para servidores que rodam aplicaes que no so thread-safe, como o PHP. Por outro lado, o Worker tem como vantagem o uso reduzido de memria e uma melhor escalabilidade, dependendo da aplicao. A terceira opo, Event, diferente das duas primeiras pois ela separa o thread da conexo, permitindo que aplicaes com muitos acesso, mas com processamento rpido, possam ser beneciadas sob situaes de grande carga (KEW, 2007).

2.6.7.2 Nginx

Nginx um web server criado em 2002 por Igor Sysoev para um website da Rssia, chamado Rambler, e que chegou a receber mais de 500 milhes de requisies HTTP por dia. Atualmente ele utilizado por vrios servios conhecidos, como WordPress, Hulu e SourceForge e tem se mostrado o maior competidor do Apache, principalmente a partir de 2009. O Nginx um servidor conhecido pela sua ecincia, leveza e velocidade, obtidos atravs de sockets assncronos, utilizao de um processo por core (ao contrrio da utilizao de uma thread por requisio), algo suciente para lidar com milhares de conexes, fazendo uso de pouca CPU e memria (NEDELCU, 2009). A congurao do Nginx tambm se caracteriza pela simplicidade com relao aos seus competidores, como o Apache, permitindo o setup de um host virtual em poucas linhas. Nginx um projeto open source sob uma licena BSD-like, vindo ainda com um sistema poderoso de mdulos, muitos destes disponveis no arquivo

203

original da distribuio, sem contar no mdulos de terceiros que podem ser instalados separadamente (NEDELCU, 2009). O Nginx escrito em C e roda nas plataformas Windows, GNU/Linux, Unix, BSD, Mac OS X e Solaris. Uma das desvantagens (dependendo do ponto de vista) com relao ao Apache que os mdulos precisam ser includos ao servidor na hora de compilar o mesmo, enquanto que o Apache suporta o carregamento dinmico atravs de arquivos de congurao. Por outro lado, o Nginx tem mostrado um rps (requests per second) de at duas vezes mais do que o Apache, com tempos de resposta muito menores, e com o aumento da quantidade de requisies o desempenho do Apache tende a degradar muito mais (NEDELCU, 2009).

2.6.8 Deployment

Colocar aplicaes para produo signica tem em mos um ou um conjunto de servidores onde sero instalados os diversos componentes que fazem parte de uma aplicao web, desde servidores HTTP, servidores de aplicao, banco de dados, servidores de arquivos, e assim por diante. Dependendo do tamanho da aplicao, apenas a instalao e congurao de todos os componentes de software pode demandar uma grande quantidade de tempo. E se forem somados a isto o tempo para provisionamento do hardware necessrio, os custos podem se tornar restritivos. A ideia por trs do Cloud Computing j foi expressa anteriormente, na seo 2.3.4.2, tornando desnecessria maiores apresentaes. Para a implantao de uma aplicao web existem dois tipos de servios de cloud computing que podem ser utilizados: Paas e Iaas. Ambos tambm j foram detalhados anteriormente neste relatrio, restando agora apresentar nas sees seguintes algumas das solues disponveis no mercado.

204

2.6.8.1 Amazon AWS

O Amazon Web Services um conjunto de servios de infraestrutura de TI oferecidos na forma de web services, ou como conhecido hoje, cloud computing, com alta conabilidade, escalabilidade, e baixos custos (AMAZON, 2012). Dentre os servios oferecidos pela Amazon AWS, os mais conhecidos so: Elastic Compute Cloud (EC2), Simple Storage Service (S3), SimpleDB, Relational Database Service (RDS), Simple Queue Service (SQS) e Elastic MapReduce (SOUSA; MOREIRA; MACHADO, 2009). O EC2 faz parte dos servios de computao da Amazon, e prov capacidade de computao escalvel para a execuo de aplicaes. Com o EC2 possvel escolher vrias caractersticas da mquina, como CPU, memria, armazenamento, alm do sistema operacional que nela ser executado. possvel ainda criar imagens customizadas (AMI - Amazon Machine Image) que contenham, alm do sistema operacional, todos os aplicativos desejados, podendo assim replicar com facilidade uma mquina (SOUSA; MOREIRA; MACHADO, 2009). Atravs do EC2 possvel, por exemplo, aumentar o nmero de instncias nos horrios de pico e nos demais horrios reduiz-las, reduzindo os custos sem, entretanto, reduzir a qualidade dos servios (SOUSA; MOREIRA; MACHADO, 2009). J o S3 um sistema simples de armazenamento e recuperao de qualquer tipo de dados que pode ser acessado de qualquer lugar, seja atravs do web service pelos desenvolvedores, como por qualquer pessoa, de acordo com as permisses dadas aos arquivos (SOUSA; MOREIRA; MACHADO, 2009). preciso ponderar, entretanto, com relao ao uso das APIs da Amazon para a criao de uma aplicao, pois isso pode reduzir a sua portabilidade para outros provedores de cloud computing, ou mesmo para uma infraestrutura prpria. Para contornar isso possvel, por exemplo, criar abstraes na aplicao, reduzindo a quantidade de modicaes necessrias para portar a aplicao.

205

2.6.8.2 Heroku

Diferentemente do Amazon AWS, o Heroku fornece plataformas em forma de servio ao invs de infraestrutura. Tendo sido concebido originalmente com suporte a linguagem de programao Ruby, atualmente ele suporta Java, Node.js, Scala, Clojure, Python e PHP (HEROKU, 2012). Em conjunto com as plataformas acima citadas, o Heroku tambm fornece add-ons que adicionam funcionalidades as aplicaes. Existem add-ons para os bancos de dados PostgreSQL, Redis, MongoDB, MySQL e Neo4j, alm de outros que fornecem servios como cache, logging, message queues, backup, email, monitoramento, sistema de busca, dentre outros (HEROKU, 2012).

2.7 SOLUTION STACKS

Um solution stack um conjunto de subsistemas de software ou componentes necessrios para a entrega de uma soluo funcional, como um servio ou produto (GELGER, 2008). Por exemplo, o LAMP (Linux + Apache + MySQL + PHP/Perl/Python) um dos mais populares application stacks do mercado, principalmente entre startups, tendo tido usurios como Facebook e Tumblr, quando estes ainda estavam na infncia (CANONICAL, 2010). Eventualmente estes servios tiveram que modicar drasticamente sua infraestrutura e seu stack para comportar o crescimento da base de usurios e conseguir escalar as suas aplicaes. Nesta seo sero apresentadas as solues utilizadas por algumas das maiores redes sociais da atualidade, e como elas conseguiram lidar com problemas de escalabilidade.

206

2.7.1 Instagram

Com mais de 14 milhes de usurios em pouco mais de um ano e com uma equipe de desenvolvimento pequena (3 engenheiros), o foco do servio com relao ao sistema est na simplicidade, no reinventar a roda e utilizar, quando possvel, tecnologias slidas e que comprovadamente funcionam (INSTAGRAM, 2011a). A infraestrutura do Instagram toda fornecida pela Amazon, principalmente pelo fato de a equipe ser composta por apenas 3 pessoas. So mais de 100 instncias do Amazon EC2 utilizadas para os mais variados propsitos, todas com sistema operacional Ubuntu Linux 11.04 Natty Narwhal (INSTAGRAM, 2011a). Todas as requisies aos servidores do servio passam pelo balanceamento de carga. No princpio eram utilizadas duas mquinas com nginx e DNS Round-Robin, mas como o tempo de atualizao do DNS muito alto, como fora comentado na seo 2.3.1.2. Atualmente o servio faz uso do Amazon Elastic Load Balancer, com trs instncias que podem ser trocadas ou removidas em caso de falha ou indisponibilidade. O SSL acaba nos balanceadores de carga, reduzindo a carga de CPU no nginx e para DNS utilizado o Amazon Route 53 (INSTAGRAM, 2011a). A linguagem de programao utilizada para a aplicao Python com o framework Djando. A aplicao roda em cima de pelo menos 25 mquinas Amazon High-CPU Extra-Large, permitindo escalabilidade na horizontal j que a aplicao stateless, alm disso a escolha destas mquinas faz sentido j que a aplicao mais CPU-bound do que memory-bound. O servidor HTTP utilizado para a aplicao costumava ser o Apache com mod_wsgi, mas atualmente o servio faz uso do Gunicorn, um servidor Python com suporte para WSGI, Djando e Paster, que mais fcil de congurar e utiliza menos CPU que o Apache (INSTAGRAM, 2011a). Grande parte dos dados do Instagram armazenado no PostgreSQL. Para servir os usurios com rapidez, as informaes mais importantes precisam caber na memria, e com mais de 25 fotos e 90 likes por segundo foi necessrio fazer shard dos dados, ou seja, dividir horizontalmente os dados em buckets menores (INSTAGRAM,

207

2011b). O sharding dos dados no PostgreSQL feito atravs de schemas. Neste SGBD cada banco de dados pode possuir vrios schemas, o default o public, e cada schema possui suas prprias tabelas. No Instagram cada shard lgico corresponde a um schema, e todos eles so mapeados a shards fsicos atravs da aplicao. Desta forma, quando mais mquinas (a.k.a. shards fsicos) forem adicionadas, basta apenas mover conjuntos de shards lgicos para as novas mquinas (INSTAGRAM, 2011b). Um dos desaos ao fazer sharding dos dados foi na gerao da chave primria que no poderia depender mais do auto-incremento fornecido pelo banco de dados. A soluo foi delegar para cada tabela de cada shard, atravs de PL/PGSQL, a criao de uma chave nica. Cada chave (ou ID) composta por 41 bits correspondendo ao tempo em milisegundos, permitindo assim ordenar registros por data; 13 bits representando a ID do shard lgico; e 10 bits representando um valor sequencial, mdulo de 1024 (INSTAGRAM, 2011b). O cluster de sharding do Instagram faz uso de 12 instncias do Quadruple Extra-Large Memory e mais 12 replicas em zonas diferentes. Todas instncias do PostgreSQL rodam na congurao master-replica utilizando Straming Replication. Backups dos dados so feitos atravs do Amazon EBS, com snapshots. A aplicao utiliza o Pgbouncer para criar um pool de conexes com o PostgreSQL (INSTAGRAM, 2011a). As fotos so armazenadas diretamente no Amazon S3, e o Amazon CloudFront utilizado como CDN, melhorando o tempo de carregamento das fotos para usurios ao redor do mundo (INSTAGRAM, 2011a). Para o feed principal e de atividades, sistema de sesses e outros servios do Instagram o banco de dados utilizado o Redis. Vrias instncias do Quadruple ExtraLarge Memory so utilizadas para rodar o Redis, permitindo que todos os seus dados caibam na memria. Ocasionalmente so feitos shards atravs de algumas instncias do Redis. Todas as instncias rodam na congurao master-replica, com replicas

208

salvando os dados para o disco constantemente, e assim como com o PostgreSQL, o EBS utilizado para realizar backups (INSTAGRAM, 2011a). A API de busca geolocalizada (geo-search), que antes utilizava o PostgreSQL, agora faz uso do Apache Solr, plataforma de busca open source, que prov uma interface simples em JSON. O servio faz ainda uso de cache de dados atravs de 6 instncias do Memcached. O compartilhamento de fotos no Facebook e Twitter e atualizaes de novas em tempo real so tarefas deixadas para o Gearman, um sistema de la de tarefas. Desta forma, quando um usurio faz upload de uma foto e compartilha ela em redes sociais, por exemplo, o servio faz o retorno imediato, deixando o trabalho pesado para a la de tarefas. O servio usa 200 workers escritos em Python para consumir as tarefas da la (INSTAGRAM, 2011a). Para provr APNS (Apple Push Notication Service), o Instagram fez uso do pyapns, para Python. Por m, o monitoramento dos recursos feito atravs do Munin, aplicao que permite a criao de plugins customizados em Python. Adicionalmente, o monitoramento externo feito atravpes do Pingdom, noticaes e incidentes so entregues atravs do PagerDuty e erros na aplicao so monitorados atravs do Sentry, aplicao desenvolvida pela Disqus (INSTAGRAM, 2011a).

2.7.2 LinkedIn

A maior rede social para prossionais do mundo comeou com uma arquitetura monoltica, possuindo apenas um banco de dados principal e com o grafo da rede (network graph) armazenado em cache de memria no que conhecido por The Cloud (HURVITZ, 2008). Posteriormente foram adicionados rplicas read-only do banco de dados para reduzir a carga em cima do banco de dados principal. Um servidor RepDB ca responsvel pela atualizao dos dados das replicas. Quando ainda no haviam rplicas, as atualizaes de dados eram escritas diretamente no banco de dados principal, e

209

Fonte: LinkedIn (2008, p. 13).

Figura 2.62: Arquitetura do LinkedIn de 2003 a 2005.

este atualizava o The Cloud. Com o tempo, o LinkedIn passou a utilizar um barramento chamado de Databus para provr atualizaes para qualquer componente da arquitetura que precise. Desta forma, atualizaes ocorridas no WebApp vo para o banco de dados principal e este envia as atualizaes para o barramento, que ento entrega as atualizaes para componentes como o RepDB, The Cloud e o Search. Em 2008 o WebApp passou a ser composto de servios, cada um com seu prprio banco de dados, permitindo que outras aplicaes pudessem acessar a rede social (HURVITZ, 2008). Os bancos de dados utilizados so Oracle e MySQL. O sistema operacional utilizado Solaris rodando nas plataformas Sun x86 e Sparc. A principal linguagem utilizada Java, com o framework Spring Source e servidores de aplicao Tomcat e Jetty, a conexo com os bancos de dados feita diretamente com JDBC, nada de ORMs. O servio faz uso ainda do Apache ActiveMQ como implementao do Java Message Service (JMS) (HURVITZ, 2008). O componente de busca (Search) responsvel pela busca de pessoas, empregos, notcias, fruns, grupos, empresas, e outros recursos da rede social. Ele completamente distribudo, sendo 5 milhes de membros por partio e duas parti-

210

Fonte: LinkedIn (2008, p. 16).

Figura 2.63: Arquitetura Atual (em 2008) do LinkedIn.

es por n, parcialmente balanceados, com mais de 13 parties e 6 replicaes, e a comunicao ocorre atravs de 5 brokers (WANG; MATSUDA, 2010). Para o sistema de busca o LinkedIn utiliza como base o Apache Lucene. Buscas em tempo real so feitas atravs de uma customizao do Lucene chamada Zoie. O componente no faz uso de index/cache warming, ou seja, ele no realiza cache de consultas populares antes do primeiro usurio as requisitar, algo que pouparia estes do nus de um cold cache. Isso ocorre provavelmente pela quantidade de atualizaes que ocorrem, tornando invivel aquecer toda a vez o cache (WANG; MATSUDA, 2010). J na busca atravs de ltros (facetada), tambm com suporte em tempo real, outra customizao do Lucene utilizada, chamada de Bobo. A arquitetura de busca distribuda feita atravs de sharding de acordo com o valor do UID, ela faz uso do

211

pattern scatter-gather, o balanceamento de carga utiliza o algoritmo round-robin e a replicao feita tanto no nvel dos brokers como dos searchers (WANG; MATSUDA, 2010).

Fonte: Wang e Matsuda (2010, p. 21).

Figura 2.64: Arquitetura distribuda de busca do LinkedIn.

Em setembro de 2010 o LinkedIn lanou um novo servio de busca chamado Signal para contedo compartilhado da rede social e tweets. O frontend da aplicao foi escrito em JRuby e o backend em Scalatra (framework em Scala inspirado no Sinatra) na forma de um servio Restful utilizando o modelo REST/JSON RPC. Buscas utilizando ltros so feitas atravs do Sensei, um banco de dados distribudo com clusterizao dinmica e que tira vantagem tanto do Zoie como do Bobo. O servio tambm faz uso do banco de dados de chave/valor Voldemort para buscas salvas e follows (WANG, 2010). The Cloud ou A Nuvem se trata de um servidor que faz cache de toda a rede de grafos em memria, rede esta com mais de 22 milhes de ns e 120 milhes de arestas. So 12 GB de RAM e 40 instncias em produo, sendo que recriar uma instncia do The Cloud leva 8 horas. O The Cloud atualizado em tempo real atravs do Databus e os dados so persistidos no disco ao desligar. O cache implementado

212

em C++ ao invs de Java, utilizando assim o mnimo possvel de memria e evitando pausas que ocorriam com o Garbage Collector em Java (HURVITZ, 2008). Sobre a arquitetura de comunicao, especicamente o servio responsvel pelas mensagens permanentes, como mensagens inbox e emails. A criao de mensagens faz uso do JMS de forma assncrona, as mensagens so roteadas atravs do servio de roteamento para a mailbox apropriada ou diretamenta atravs do processamento de email. A entrega de mensagens ocorre ou pela requisio de um cliente ou atravs de processos agendados, as mensagens so formatadas atravs de JSP. O servio de mensagens utiliza uma arquitetura SOA, com componentes construdos em volta de extenses Spring (HURVITZ, 2008). Ainda na arquitetura de comunicao, o servio responsvel pelas noticaes de vida curta, como atualizaes de status, desde a sua verso inicial teve mais trs iteraes. No incio o cliente precisava contatar cada um dos servios que poderia ter atualizaes, o que levava muito tempo. Na primeira iterao o cliente passou a contatar apenas o NetworkUpdateService, arquitetura baseada em pull, este responsvel por vericar atualizaes com os vrios servios, a comunicao ocorria em paralelo para reduzir o tempo de resposta (HURVITZ, 2008). A segunda iterao da arquitetura passou a ser push, sendo que toda vez que um evento ocorria no sistema, a atualizao era adicionada ao mailbox do usurio, e quando este requisitasse as atualizaes bastaria apenas retornar aquelas que j estavam no mailbox. Como resultado, a leitura de atualizaes cou mais rpida, mas em contrapartida a quantidade de espao necessrio para armazenamento aumentou, sem contar que muitas atualizaes nunca chegavam a ser lidas. As atualizaes eram armazenadas em CLOB (Character Large Object), sendo um para cada tipo de atualizao para cada usurio, com tamanho de 8 kb, o que levou a disperdcio de espao (HURVITZ, 2008). Na terceira iterao o objetivo principal estava no aumento do desempenho atravs da reduo das atualizaes do CLOB, pois estes custam caro. Para fazer isso utilizou-se um buffer, na forma de uma coluna VARCHAR(4000), desta forma,

213

todas atualizaes eram inicialmente colocadas nesta coluna, e somente quando ela estivesse cheia os dados seriam depositados no CLOB, reduzindo o nmero de atualizaes deste em 90% (HURVITZ, 2008).

2.8 COMPUTAO MVEL

Para BFar e Fielding (2004), sistemas de computao mvel so sistemas computadorizados que podem ser movidos sicamente com facilidade e que podem ter seus recursos computacionais utilizados durante o movimento. Eles se diferenciam de outros sistemas computacionais pelo uso de conexes de rede sem o, pelo tamanho reduzido, pela natureza do seu uso, sua fonte de energia e as funcionalidades projetadas especialmente para usurios mveis. Devido as caractersticas da computao mvel, novas variveis precisam ser levadas em conta na construo de aplicaes mveis. Estas variveis compoe as sete dimenses da mobilidade, sendo elas: localizao, qualidade da conexo de rede, dispositivos com capacidade limitada, fonte de energia limitada, suporte a uma gama maior de interfaces de usurio, grande variedade de plataformas e transaes ativas (BFAR; FIELDING, 2004). A primeira das dimenses, localizao, pode ser dividida em duas categorias: localizao e sensibilidade a localizao. A primeira categoria implica na utilizao da localizao para inferir sobre as regras de negcio de uma aplicao, ou seja, informaes sobre a localizao devem ter alguma utilidade dentro da aplicao, caracterstica que no exclusiva de aplicaes mveis. Por outro lado, a sensibilidade a localizao , pois ela implica a capacidade de obter a localizao do dispositivo para ento utiliz-la para oferecer funcionalidades ao usurio (BFAR; FIELDING, 2004). A segunda dimenso inerente computao mvel a qualidade de servio da conexo de rede. Mesmo em aplicaes desktop se exige o mnimo de cuidado com relao, por exemplo, a quedas na conexo, uma situao que pode ocorrer eventualmente. Entretanto, na computao mvel a queda da conexo, muitas vezes constante, bem como baixa largura de banda no so excees, mas a regra. Isso sig-

214

nica que aplicaes precisam levar em conta estas condies e precisam se manter funcionais mesmo sob tais circunstncias (BFAR; FIELDING, 2004). Uma das caractersticas marcantes dos dispositivos mveis e cuja evoluo pde ser acompanhada ao longo dos anos o seu tamanho. Dentro de certos limites, quanto menor o dispositivo, mais fcil o seu manuseio e maior a sua portabilidade. A reduo do tamanho dos dispositivos implica diretamente na reduo do tamanho dos componentes dele, algo que pode custar caro at que a tecnologia seja disseminada e os preos comecem a baixar. E mais do que isso, componentes menores signicam menor capacidade, seja no processamento ou na memria (BFAR; FIELDING, 2004). Mas a tendncia, mesmo com a reduo do tamanho dos dispositivos mveis, de aumentar a capacidade dos componentes. E isso traz consequncias para outra dimenso da computao mvel, a fonte de energia. Aplicaes mveis precisam estar cientes destas restries, tomando medidas preventivas para salvar o mximo possvel de recursos, principalmente de carga da bateria (BFAR; FIELDING, 2004). Anal, quem gostaria de utilizar uma aplicao que, por mais til que seja, consuma metade da carga do dispositivo em menos de uma hora? Dispositivos mveis tambm acrescentam certa complexidade na construo de aplicaes devido a quantidade de interfaces existentes. No justo comparar com o desenvolvimento de aplicaes desktop, levando em conta que esta muito mais madura e as interfaces com o usurio j esto bem estabelecidas. Dispositivos mveis possuem telas menores, alguns permitem a entrada de dados atravs de teclados, telas sensveis ao toque, stylus ou voz, e alm da tela, alguns dispositivos podem utilizar como sada de dados a voz, atravs de sistemas de traduo de texto para voz (BFAR; FIELDING, 2004). Tanto as dimenses reduzidas dos dispositivos mveis, como as situaes onde eles sero utilizados podem exigir interfaces diferentes. E aplicaes mveis precisam se adaptar estas situaes, bsucando acomodar o usurio da melhor forma possvel. Sem contar que a construo de interfaces precisa ainda levar em conta questes como comportamento do usurio, diferenas culturais, tempo de implemen-

215

tao, desempenho e complexidade (BFAR; FIELDING, 2004). Estas dimenses da computao mvel trazem a tona o contexto. Enquanto que desktops so muito limitados e previsveis com relao ao contexto no qual um usurio pode estar, dispositivos mveis envolvem uma innidade de contextos possves. Por exemplo, o comportamento de um usurio no o mesmo enquanto ele dirige um carro ou quando ele pega um nibus. No primeiro caso, a ateno do usurio est voltada (ou deveria estar, para a sua segurana) para o trnsito, portanto, a medida que uma aplicao mvel tem conhecimento sobre o contexto, ela pode, por exemplo, trocar o modo de interface para voz, permitindo que o usurio utilize comandos de voz (FLING, 2009). O contexto pode dizer muito no apenas sobre o comportamento do usurio, mas tambm sobre o que ele espera de uma aplicao mvel capaz de perceber o seu contexto. E a medida que uma aplicao capaz de no apenas ter conhecimento sobre um contexto, mas de tambm saber que aes tomar, ela passa a executar transaes ativas, a penltima dimenso da mobilidade. Isso signica que quando um usurio chegar na faculdade ou entrar em um avio o seu celular entrar no modo silencioso, ou quando ele estiver chegando em casa o celular o lembrar de passar no mercado (FLING, 2009; BFAR; FIELDING, 2004). A ltima das dimenses da mobilidade diz respeito proliferao de plataformas distintas no mercado. Este assunto ser abordado em maiores profundidade nas sees a seguir, detalhando ainda a evoluo dos dispositivos mveis, sistemas operacionais e ferramentas para desenvolvimento, bem como a situao atual do mercado.

2.8.1 Evoluo

Telefones mveis surgiram por volta de 1967, e na poca os usurios no podiam mudar de rea. Foi na dcada seguinte que Amos Edward Joel criara o sistema de handover, permitindo que usurios mudassem de rea sem perder a conexo. Mas foi apenas em 1982 que a FCC aprovou o servio de celulares para a AT&T atravs

216

do AMPS (Advanced Mobile Phone Service), um sistema analgico que s passou a ser digital em 1990 (SPENCER, 2012). Fling (2009) divide a evoluo dos telefones celulares em: brick (vulgo tijolar, de 1973 a 1988), candy bar (ou barra de chocolate, de 1988 a 1998), feature phone (de 1998 a 2008), smartphone (de 2002 at hoje) e touch. A primeira gerao de celulares, bicks, tinha esta denominao por um motivo bvio, o seu tamanho exagerado. Entretanto, este era um mau necessrio, pois as suas baterias precisavam ser grandes, pois a quantidade de energia necessria para alcanar a antena de celular mais prxima era grande. O primeiro aparelho a ser aprovado pela FCC nesta poca foi o Motorola DynaTAC 8000X (FLING, 2009). Com a introduo da segunda gerao de redes de telefonia celular (2G), a quantidade de energia necessria para o funcionamento dos celulares foi reduzida, reetindo diretamente no tamanho dos aparelhos, conhecidos nesta poca como candy bars. Esta poca foi marcada pela tecnologia GSM que demonstrou que celulares poderia servir para outras coisas alm de chamadas de voz, como foi o caso do SMS (FLING, 2009). A terceira era dos telefones celulares foi a era dos feature phones. Nesta poca celulares comearam a receber funcionalidades extras, como possibilidade de tocar mp3, cmera fotogrca e de vdeo, aplicativos e o uso da Internet. Nesta poca estava ocorrendo uma transio entre as tecnologias 2G para 3G, mais conhecido como 2.5G, onde as tecnologias 2G podia agora fornecer servios de dados. O aparelho que marcou esta poca foi o Motorola RAZR que, apesar de no possuir nenhum avano tecnolgico, teve grande demanda devido ao seu formato, se tornando o segundo aparelho de celular mais vendido no mundo (FLING, 2009). A prxima era, dos smartphones, para Fling (2009), no algo que pode ser denido com exatido. De certo modo, o que diferenciou os smartphones dos feature phones foi o uso de um sistema operacional em comum, tela maior, teclado QWERTY ou stylus e conexo atravs de WiFi. Os aparelhos mais proeminentes desta poca

217

foram os Nokias da linha S60, que utilizavam o sistema operacional Symbian e o BlackBerry da RIM (Research In Motion) (FLING, 2009). Apesar das qualidades dos smartphones descritos acima, eles no foram capazes de atrair a ateno do grande pblico. Em 2007, entretanto, o mercado de telefones celulares mudou completamente, com a introduo do iPhone da Apple. Em menos de quatro meses ele foi capaz de passar as vendas do Motorola RAZR nos Estados Unidos, bem como as da RIM (FLING, 2009). Com a introduo do iPhone mais pessoas passaram a acessar a Internet comparado com proprietrios de celulares e smartphones. Portanto, o iPhone pode ser considerado um marco na histria dos telefones celulares, criando a era touch (FLING, 2009). Atualmente existem mais de 4 bilhes de telefones celulares em todo o mundo, e destes, 27% so smartphones (RICHMOND, 2011). E de acordo com Nielsen (2012), nos Estados Unidos metade dos proprietrios de celulares possu um smartphone, nmero que era de apenas 36% em 2011. Alm disso, Morgan Stanley (2010) arma que em 2014 havero mais pessoas acessando a Internet atravs de dispositivos mveis do que desktops.

2.8.2 Plataformas

Apesar do seu pioneirismo, a Apple est em segundo lugar, com 31.4%, nos Estados Unidos com relao a participao de mercado das plataformas de smartphones, perdendo para o Google, que possu 50.8% de participao (COMSCORE, 2012). Em sequncia esto RIM, Microsoft e Symbian. importante deixar clara a diferena entre plataforma e sistema operacional. Uma plataforma, segundo Fling (2009), prov acesso aos dispositivos e permite que softwares e servios sejam nele executados. J um sistema operacional possui um conjunto de servios bsicos que gerenciam o dispositivo e as aplicaes nele execu-

218

tadas. Exemplos de plataformas so: Java Micro Edition (Java ME), Binary Runtime Environment for Wireless (BREW), Windows Mobile, LiMO, Palm, BlackBerry, iOS e Android. Enquanto que sistemas operacionais para dispositivos mveis so: Symbian, Windows Mobile, Palm OS, Linux, iOS e Android (FLING, 2009). Enquanto que os dados de participao de mercado exibidos acima dizem respeito apenas aos Estados Unidos, Gartner (2012) mostra dados com relao a todo o mundo com relao a participao de mercado de sistemas operacionais e fabricantes de dispositivos mveis. E novamente, o Android (Google) ca em primeiro lugar, seguido pelo iOS, Symbian e RIM em sistemas operacionais, e com relao aos fabricantes, Samsung lidera, seguida por Nokia e Apple. interessante notar que enquanto que a Apple controla todo o seu ecossistema, com exceo das redes de telecomunicao, o Android no est atrelado a nenhum dispositivo em especial, sendo ele usado por diversos fabricantes OEM, como Samsung, HTC e Motorola, esta ltima propriedade da Google. Nas sees a seguir as duas principais plataformas mveis, Android e iOS, sero descritas em maiores detalhes, desde as caractersticas de seus sistemas operacionais at as ferramentas para desenvolvimento e a estrutura de suas aplicaes.

2.8.3 Android

O Android um sistema operacional para dispositivos mveis open source baseado no Linux e desenvolvido pela Open Handset Alliance, um consrcio liderado pelo Google (BRHLER, 2010). Atualmente o Android a plataforma mais popular no mundo, como a seo anterior deixou claro, com mais de 900,000 novos dispositivos ativados todos os dias (ANDROID, 2012).

219

Aplicaes para o Android so escritas na linguagem de programao Java com o uso dos componentes e ferramentas fornecidos pela Android SDK. As aplicaes so executadas na mquina virtual Dalvik, que no executa bytecodes como uma JVM, mas sim arquivos binrios .dex, que so bytecodes convertidos atravs da ferramenta dx (BRHLER, 2010). Os arquivos .dex so otimizados para utilizar o mnimo possvel de memria. Alm disso, a Dalvik VM foi desenvolvida para garantir que vrias instncias suas pudessem ser executadas ao mesmo tempo sem, entretanto, degradar a performance do dispositivo (ANDROID, 2012). As aplicaes so distribudas atravs do pacote .apk, que contm todos os arquivos da aplicao, que podem ser os cdigos-fonte Java compilados ou outros arquivos, chamados de recursos, como imagens e arquivos xml (ANDROID, 2012). No Linux, cada aplicao um usurio diferente, com sua prpria ID, executando em seu prprio processo e com sua prpria instncia da Dalvik VM, garantindo o isolamento entre aplicaes. Alm disso, no Android as aplicaes s podem ter acesso aos recursos que foram explicitamente requeridos, atravs do arquivo AndroidManifest.xml, sendo tudo o mais bloqueado (ANDROID, 2012). O AndroidManifest tambm utilizado para a declarao dos componentes de uma aplicao e os requisitos mnimos para a sua execuo, como a verso mnima do sistema operacional. Os tipos de componentes de uma aplicao so quatro: activities, que so aes especcas que um usurio pode realizar na aplicao, sendo que uma atividade possu interface grca; services, estes sem interface grca, so utilizados em tarefas de segundo plano, que geralmente levam mais tempo para serem completadas; content providers, que gerenciam conjuntos de dados de uma aplicao, armazenados no dispositivo ou em algum servidor, e permitem que outras aplicaes tenham acesso a eles, e at mesmo modiquem eles; e broadcast receivers, que respondem a anncios feitos para todo o sistema, podendo ser criados tanto pelo sistema operacional como por outras aplicaes (ANDROID, 2012).

220

Aplicaes podem ter vrios componentes, de qualquer um dos tipos acima descritos e mais, uma aplicao pode ainda iniciar componentes de outras aplicaes atravs de Intents. Um aplicativo de e-mail, por exemplo, pode conter links que sero abertos pelo navegador, ou um arquivo de msica para ser tocado pelo player instalado no dispositivo (ANDROID, 2012).

Fonte: Android (2012).

Figura 2.65: Exemplo de atividades em uma backstack, compondo uma atividade. Quando uma aplicao inicia novas atividades passa a existir o que se chama de tarefa, que uma pilha de atividades, sendo a ltima atividade da pilha a atividade em primeiro plano, enquanto que as outras esto em segundo plano (Figura 2.65). Isso permite que um usurio volte para telas anteriores sem, entretanto, perder o estado desta tela. Ou seja, se o usurio abriu seu e-mail e clicou em um link que o levou para o navegador, quando ele pressionar o boto voltar, ele continuar de onde parou, vendo o e-mail que estava lendo (ANDROID, 2012). Os componentes descritos acima podem ser considerados os responsveis pelo comportamento de uma aplicao. Entretanto, uma aplicao possui mais do que isso. Alm do cdigo-fonte Java de uma aplicao, existem os recursos, estes responsveis pelos layouts, strings, imagens, sons e qualquer outro tipo de arquivo pertencente a aplicao. E cada recurso, dentro da aplicao, ir possuir uma ID nica, utilizada para referenciar o recurso (ANDROID, 2012). Uma das vantagens de se utilizar recursos ao invs de cdigo-fonte, a possibilidade de prover diferentes alternativas para diferentes tipos de conguraes e dispositivos. Por exemplo, atravs dos recursos possvel dar suporte a internacionalizao, criando arquivos de strings para diversas linguagens, ou criar layouts dife-

221

renciados para dispositivos com telas maiores, como o caso dos tablets (ANDROID, 2012). A interface de usurio do Android construda atravs de dois componentes bsicos: View e ViewGroup. Uma View um componente com o qual o usurio pode interagir, chamado normalmente de widget, como um boto ou um text eld. J um ViewGroup um objeto que agrega vrias Views e dene a forma como elas sero organizadas na tela. A Figura 2.66 mostra como funciona a hierarquia da UI em uma aplicao Android (ANDROID, 2012).

Fonte: Android (2012).

Figura 2.66: Exemplo de hierarquia da inerface grca no Android.

Dentre as vrias implementaes do ViewGroup fornecidas pela API do Android, as mais utilizadas so: LinearLayout, que organiza os componentes em uma nica linha vertical ou horizontal; RelativeLayout, que permite que componentes sejam posicionados relativamente uns aos outros; e WebView, que exibe pginas web, permitindo, por exemplo, a criao de aplicaes hbridas, escritas com tecnologias Web, mas executadas no Android como se fossem aplicaes nativas (ANDROID, 2012). O ambiente de desenvolvimento Android compoosto pela IDE Eclipse em conjunto com o plugin ADT (Android Developer Tools), que juntos proveem todas as funcionalidades necessrias para o desenvolvimento, debug e teste de aplicaes, permitindo o deploy tanto em dispositivos reais como em emuladores (ANDROID, 2012).

222

2.8.4 iOS

iOS o sistema operacional dos dispositivos da Apple, iPhone, iPod e iPad, tendo sido baseado no sistema operacional para desktops Mac OS X. Aplicativos so desenvolvidos na linguagem de programao Objective-C e fazem uso do iOS SDK, que contm ferramentas e interfaces necessrias para o desenvolvimento instalao, execuo e teste de aplicaes nativas (APPLE, 2011).

Fonte: Apple (2011).

Figura 2.67: Camadas do iOS. O sistema operacional iOS pode ser dividido em cinco camadas, como pode ser visto na Figura 2.67. As camadas superiores so abstraes das camadas inferiores do sistema operacional, tornando o desenvolvimento de aplicaes mais fcil (APPLE, 2011). A camada do topo, Cocoa Touch, contm os principais frameworks para o desenvolvimento de aplicaes, como a infraestrutura bsica da aplicao, suporte a multitarefas, noticaes push, alm de outros servios de alto nvel do sistema. No total, at a verso 5 do iOS, so oito as frameworks disponveis:

Address Book UI: prov interfaces padro para a criao, edio e seleo de contatos, garantindo que todas as aplicaes tenham uma interface consistente. Event Kit UI: fornece view controllers para a visualizao e edio de eventos relacionados com o calendrio. Game Kit: permite que aplicaes utilizem funcionalidades de redes perr-to-peer e funcionalidades de voz in-game. Na verso 4.1 foi introduzido o Game Center,

223

que prov funcionalidades adicionais a jogos, como possibilidade de criar um alias, visualizao de pontuaes, marcao de jogos multiplayer, etc. iAd: permite adicionar anncios na forma de banners nos aplicativos. Map Kit: permite a adio de mapas a aplicaes, permitindo a customizao dos mesmos, criando pontos de interesse ou mesmo criando overlays com informaes adicionais. Message UI: componente padro para o envio de mensagens. Twitter : introduzido no iOS 5, permite que aplicaes faam requisies a API do Twitter no nome do usurio, criem e enviem tweets. UIKit: fornece os componentes essenciais para a construo de aplicaes grcas e orientadas a eventos no iOS. Ela implementa as funcionalidades de: gerenciamento de aplicao e interface do usurio, suporte a grcos e janelas, suporte a multitarefas, impresso, eventos touch, componentes bsicos da view, notications push (Apple Push Notication Service), criao de documentos PDF, acesso aos dados do acelermetro, a cmera, e as informaes da bateria e dispositivo.

At a verso 4 do iOS as interfaces do usurio eram criadas atravs de arquivos nib, entretanto, no iOS 5 a forma recomendada passou a ser os storyboards. Atravs dos storyboards possvel criar toda a interface de usurio em um nico lugar, visualizando as views, os controladores das views, alm de poder denir as segues, que so as transies entre views (APPLE, 2011). Abaixo da camada Cocoa Touch est a camada de Media. Ela implementa todas as funcionalidades relacionadas com grcos, udio e vdeo, como codecs de imagem, udio e vdeo, renderizadores de texto, e bibliotecas para grcos 2D e 3D (Quartz, OpenGL ES e GLKit) (APPLE, 2011). Nos Core Services esto os servios bsicos do sistema que so utilizados pelas aplicaes. Exemplos de servios so o iCloud, que permite o armazenamento

224

e recuperao de arquivos e dados em um local central; In-App Purchase, para que contedos e servios possam ser vendidos atravs de aplicaes; suporte a arquivos XML; armazenamento de dados atravs do SQLite; alm de servios relacionados contas de usurio, rede, localizao, telefonia, entre outros (APPLE, 2011). A ltima das camadas do iOS contm as funcionalidades de baixo nvel do sistema operacional, utilizadas como base para a construo de todas as outras tecnologias acima dela. Normalmente aplicaes no acessam esta camada diretamente, mas sim atravs das abstraes provenientes das camadas superiores. Entretanto, em situaes onde uma aplicao precise, por exemplo, se comunicar com um hardware externo, esta a camada que precisar ser utilizada (APPLE, 2011). Diferentemente do Android, as ferramentas de desenvolvimento do iOS, contidas na sua SDK, executam somente em computadores Macintosh com processadores Intel. A SDK composta pela IDE Xcode, um emulador de dispositivos iOS e toda a documentao necessria para o desenvolvimento de aplicaes no iOS (APPLE, 2011).

2.8.5 Web Mvel

At agora foram abordadas apenas plataformas mveis para o desenvolvimento de aplicaes nativas. Porm, existem alternativas que podem ser consideradas, de acordo com as necessidades da aplicao, no desenvolvimento de aplicaes mveis. Uma das alternativas a criao de aplicaes para a Web mvel. E com a introduo do iPhone, seguida pelo Android, a qualidade dos navegadores melhorou muito, com um suporte a grande parte dos padres da Web. Este fator viabilizou a criao de aplicaes Web mais ricas e que podem comear a ser comparados com as aplicaes nativas (FLING, 2009). Uma das razes mais evidentes para a criao de aplicaes para a Web mvel a ideia de escrever uma vez a aplicao e executar em qualquer dispositivo. Na

225

prtica, entretanto, as coisas no funcionam exatamente desta forma. Primeiro porque cada sistema operacional mvel possui o seu prprio navegador, cada um com um nvel diferente de compatibilidade com os padres da Web. Acrescente a isto o fato de que diferentes verses de um mesmo sistema operacional podem ter verses diferentes do navegador, ou mesmo navegadores diferentes, e a fragmentao aumenta mais ainda (FLING, 2009). Isso signica que uma aplicao Web mvel pode se comportar ou ser renderizada de maneiras diferentes, de acordo com o navegador onde executada, exigindo que ela seja testada ao menos nos dispositivos mais populares, j que testar em todos os dispositivos seria algo impensvel (FLING, 2009). Obviamente, muitas pessoas j se depararam com problemas como este e resolveram criar solues para eles. Um exemplo o HTML5 Mobile Boilerplate, que no chega a ser uma framework, mas uma estrutura bsica para a construo de aplicaes para a Web mvel, contendo vrios truques para funcionar nas principais plataformas do mercado. J as solues denomidas frameworks para construes de aplicaes para Web mvel, em sua maioria, buscam se aproximar ao mximo a experincia oferecida pelas aplicaes nativas. Dentre as opes no mercado, as mais conhecidas so Sencha Touch, jQuery Mobile e jQTouch. Elas diferem, dentre outras coisas, na curva de aprendizado, componentes disponveis e plataformas suportadas (ALLEN; GRAUPERA; LUNDRIGAN, 2010). preciso ter em mente, entretanto, que mesmo com o uso de tais frameworks, existem recursos disponveis nos smartphones que ainda no podem ser acessados atravs do navegador, como a cmera, acelermetro, lista de contatos, etc. Alm disso, o desempenho percebido em aplicaes Web mvel (incluindo a responsividade a aes do usurio) depende de vrios fatores, como velocidade da conexo, desempenho do navegador na renderizao da pgina e do engine de JavaScript. E ainda que otimizaes sejam aplicadas onde possvel, a verdade que aplicaes Web nunca podero ser comparadas a aplicaes nativas, no uma batalha justa

226

(FLING, 2009). Mas existe ainda uma terceira opo, criada para tentar eliminar algumas das desvantagens das aplicaes Web mvel. Tratam-se de frameworks, como o PhoneGap e Titanium, que permitem a criao de aplicaes hbridas, escritas em HTML, CSS e JavaScript, mas que so executadas como se fosse aplicaes nativas, permitindo assim que as aplicaes tenham acesso a APIs do sistema disponveis apenas para aplicaes nativas (ALLEN; GRAUPERA; LUNDRIGAN, 2010). Mas no nal das contas, preciso avaliar os recursos que sero exigidos pela aplicao, bem como os conhecimentos dos membros da equipe de desenvolvimento e o custos incorridos de cada uma das opes a ser escolhida, levando em conta que desenvolver aplicaes nativas para diferentes plataformas pode custar muito caro, j que a reutilizao de cdigo muito pequena (FLING, 2009).

CAPTULO 3:

RESULTADOS OBTIDOS

Este captulo descreve todos os detalhes do desenvolvimento deste trabalho, partindo da motivao para a criao do servio, quais as funcionalidades apresentadas por ele e porque elas foram escolhidas, at chegar na parte tcnica, onde so feitas as consideraes com relao as escolhas tomadas para o seu desenvolvimento.

3.1 MOTIVAO

Com o crescimento da popularidade das redes sociais, por volta de 2006 com o MySpace e mais recentemente com o Facebook e Twitter, a internet se tornou, em sua grande maioria, um lugar voltado para o "eu", para o indivduo e seus relacionamentos. As redes sociais se tornaram uma extenso da vida real, permitindo que pessoas pudessem entrar em contato com seus amigos, tanto atuais como do passado, bem como com colegas de trabalho, ex-colegas de escola, e parentes. Se concentrando nos indivduos, chegando a um nvel egocntrico, as redes sociais deixaram de lado algumas das caractersticas existentes em comunidades online. claro que isto faz todo sentido, pois esta uma das caractersticas de tecnologias desruptivas, elas se desprendem de alguns preceitos das tecnologias que as antecederam. E como consequncia, os fruns da internet, muito embora ainda existam, eles tem presena forte apenas em alguns nichos, no fazendo parte mais do mainstream. Algumas das consequncias desta internet mais voltada ao eu j esto sendo observadas e estudadas. Um exemplo a constatao de que as redes sociais (i.e.

228

Facebook) esto tornando as pessoas mais infelizes, pois os pers dos indivduos e suas atualizaes no reetem a vida real de uma pessoa. Poucas pessoas se sentem confortveis em expor seus momentos ruins e frustrantes, elas se limitam as coisas boas que lhes acontecem. E como a grama do vizinho sempre mais verde, as redes sociais esto potencializando a exposio destes quintais (COPELAND, 2012). Mas por mais que as redes sociais sejam, indiscutivelmente, grandes ferramentas de comunicao, elas perderam aquela sensao de comunidade na internet. claro, este no o propsito destes servios, no d para culp-los. Mas para a internet como um todo, o que se v um aumento da propagao de contedo, mas a originalidade deste contedo est muito menor, porque as pessoas caram mais acostumadas em compartilhar e curtir, mas elas caram menos propensas a discutir e debater, e quando elas o fazem, esta discusso se limita a um crculo de conhecidos (ningum tem 500 amigos de verdade, ou tem?). Esta limitao exatamente o motivo pelo qual as pessoas procuravam (e ainda procuram, mas em menor escala) comunidades com focos especcos, porque nestas comunidades se pressupunha que haveriam outras pessoas com a mesma propenso para gerar discusses. Na internet tudo se move muito rapidamente, e neste mesmo ritmo servios entram e saem de moda, o que era cool ontem, hoje no mais. Criar um servio na internet, principalmente um servio voltado para um pblico amplo e que se prope a criar um meio de comunicao, no uma tarefa fcil. Mas a instabilidade deste ambiente signica que as pessoas mudam a forma como elas se comunicam ou se comportam? pouco provvel. O ser humano sempre teve e continuar tendo a necessidade de viver em comunidade, se comunicar e conviver com outros indivduos. como a msica, a grande maioria das pessoas gostam de msica e sempre iro gostar. Entretanto, msicas vo e vem. A msica da moda de dez anos atrs no a mesma de hoje, mas ambas cumpriam um mesmo propsito.

229

Claro que existem diferenas entre a msica e um software, embora ambos sejam fruto de manifestaes criativas. E h de se ponderar que nem todos servios da internet esto sujeitos a instabilidade da moda. Mas se algo deixa de estar na moda, muito provavelmente seja porque outra coisa mais cool surgiu. Em outras palavras, a concorrncia conseguiu se sobressair, oferecendo algo novo, melhor e mais atraente. Portanto, a decadncia dos fruns da internet provavelmente est muito mais relacionada com a incapacidade de evoluir em face do surgimento das redes sociais do que com a alterao dos comportamentos mais bsicos dos seres humanos. A questo agora : como criar um servio que tenha os benefcios dos fruns, mas seja atraente o suciente para ganhar notoriedade? Simplesmente recriar as funcionalidades dos fruns, melhorando apenas a interface talvez no seja o suciente, muito embora interfaces (e experincia de usurio inerente) possam ter papel fundamental para o sucesso de um produto ou servio (a Apple que o diga).

3.2 FUNCIONALIDADES E CARACTERSTICAS

Nesta seo sero abordados algumas das caractersticas mais fundamentais com relao ao servio, como o modo pelo qual a identidade e privacidade dos usurios tratada e como feito o clculo de popularidade das conversas.

3.2.1 Identidade

Todo servio que necessita algum tipo de cadastro por parte do usurio precisa decidir quais dados so importantes, o que o usurio precisa informar para poder utilizar o servio. No incomum encontrar servios na Internet que exigem informaes em excesso, sem um motivo real para tal. Isso pode por em dvida a credibilidade do servio, sem contar que pode desencorajar muitos usurios a se cadastrarem, pois ningum gosta de preencher formulrios extensos.

230

Neste servio decidiu-se por no exigir do usurio sua identidade verdadeira, anal trata-se de um frum onde pessoas iro discutir diversos assuntos, at mesmo assuntos controversos. Para que um usurio se cadastre, as nicas informaes exigidas so o nome de usurio, utilizado para efetuar o log in, um email e uma senha. Mas por se tratar de uma aplicao voltada a dispositivos mveis, em primeiro lugar, no ser feita a vericao do e-mail. Pode parecer sem sentido exigir o email se o mesmo no ser vericado, mas o propsito de tal exigncia apenas para a recuperao de senha e nada mais. Deixar claro este ponto para o usurio importante, bem como deixar claro que e-mails no sero enviados sem a autorizao do mesmo.

3.2.2 Privacidade

Juntamente com as caractersticas do servio com relao a identidade dos usurios, sempre sero levantadas questes com relao a privacidade dos usurios. No caso deste servio, onde os usurios podem permanecer annimos, importante deixar claro quem pode ver o qu dentro do servio Como a maioria dos fruns tradicionais, todo o contedo pode ser visto por qualquer pessoa, no existem mensagens privadas ou semiprivadas. O perl dos usurios tambm no possu conguraes de privacidade, at porque as informaes que um perl pode conter so poucas. Na realidade, o perl de um usurio ir conter somente o seu nome, a imagem do seu avatar, as conversas por ele criadas e os interesses que ele segue. O ponto mais sensvel do servio, sem sombra de dvidas, com relao a geolocalizao. Em primeiro lugar, esta funcionalidade totalmente opcional, ou seja, o usurio pode escolher a qualquer momento se quer ou no compartilhar a sua localizao ao criar uma conversa, e a aplicao deixa explcito se ele est ou no compartilhando-a. Alm disso, o servio no revela para os outros usurios a localizao de uma

231

pessoa. As informaes sobre a localizao de um usurio so utilizadas apenas para ltrar conversas de acordo com a localizao geogrca, permitindo que um usurio possa, por exemplo, ver apenas discusses em um raio de 50 km. O usurio tambm poder ver a que distncia dele esto outros usurios, quando estes compartilharem as suas localizaes ao criarem conversas.

3.2.3 Algoritmo de Popularidade

Neste ltimo caso existe uma diferena na forma como a popularidade calculada para conversas e para interesses. Por questes de desempenho e simplicidade, a popularidade de um interesse absoluta, ou seja, quanto mais conversas houverem, maior a popularidade do interesse. claro que a simplicidade desta soluo pode trazer um pouco de injustia. Por exemplo, um determinado interesse com poucas conversas em relao a outros interesses nunca chegar ao topo da lista, mesmo que nos ltimos meses tenha gerado mais conversas que todos os outros interesses acima dele no mesmo perodo. Sendo assim, a nica forma de um interesse atingir a popularidade ter mais conversas. J para as conversas, um algoritmo mais justo aplicado. Trata-se de uma adaptao do algoritmo utilizado pelo agregador de notticas de tecnologia da Y Combinator, Hacker News. A frmula original pode ser vista pela Equao 3.1, onde p o nmero de votos dos usurios, subtraido por um para descontar o voto do usurio que submeteu o artigo, e t o tempo desde a submisso do artigo, em horas (LINKIBOL, 2010).

P opularidade = (p 1)/(t + 2)1.5

(3.1)

Na adaptao do algoritmo para esta aplicao, os votos dos usurios foram substitudos pela quantidade de respostas que uma conversa recebeu e a diferena de tempo calculada em segundos, utilizando o tempo epoch do Unix. A frmula

232

Conversation A B C

replies 100 50 20

created_at 1334910386 1334996786 1335097586

diff time 190800 104400 3600

score 1.21186381541034E-006 1.51188733190128E-006 9.72222222222222E-005 1335101186

current_time

Quadro 3.1: Exemplo de clculo de popularidade.

adaptada pode ser vista na Equao 3.2.

P opularidade = (replies + 1)/(current_time created_at)1.5

(3.2)

Na adaptao da frmula, replies a quantidade de respostas de uma conversa, somado a um para incluir a prpria conversa iniciada, dividido pela diferena entre o tempo atual e o tempo da criao da conversa, ambos em segundos, elevado a 1.5. A ideia bsica deste algoritmo a de balancear entre a quantidade de respostas e o tempo de criao de uma conversa, dando espao para as conversas mais novas e aos poucos eliminando as conversas mais antigas, por mais respostas que elas possuam. No Quadro 3.1 h um exemplo do clculo da popularidade (score) de trs conversas. Com relao a idade de cada uma das conversas, A > B > C, portanto, C a mais nova de todas e tambm a que possui menos respostas. Apesar disto, como o algoritmo leva em conta a data de criao da conversa para calcular a popularidade, C a mais popular, seguida por B e por m A. Linkibol (2010) d exemplos mais complexos para o clculo de popularidade. Entretanto, por se tratar de um servio ainda em testes, optou-se por um algoritmo mais simples, levando em conta que ele seria calculado inteiramente pelo banco de dados. Sem contar que adicionalmente ao calculo da popularidade, existe o ltro de conversas de acordo com a localizao do usurio, o que diculta a utilizao de cache de consultas no memcached.

233

O mais sensato analisar como o algoritmo ir se comportar na medida em que o servio vai crescendo, vericando se ele de fato um algoritmo justo e acima de tudo, um algoritmo relevante, que de fato traz para o topo da lista aquelas conversas que possuem maior atividade e que venham a ser mais relevantes para outros usurios. E esta anlise s poder ser feita com o tempo, para ento recolher maiores informaes e melhorar gradualmente o algoritmo, levando em conta ainda questes como desempenho e escalabilidade do servio.

3.3 API

Nesta seo sero descritos os detalhes tcnicos do backend do servio, implementado na forma de uma API RESTful.

3.3.1 Autenticao

Um dos aspectos mais importantes de uma API, bem como da maioria dos servios disponibilizados pela internet, a autenticao dos usurios e aplicaes. APIs expostas publicamente podem fomentar a criao de todo um meio ambiente ao redor das informaes disponveis, mas preciso criar meios para controlar o acesso a estas informaes, pertencentes aos usurios. Com base nos detalhes levantados na seo 2.5.4, ca claro aqui que a melhor escolha do ponto de vista do usurio nal o OAuth, pois este permite que os usurios escolham quais aplicaes podem acessar quais dos seus dados, alm de no ser necessrio entregar o nome de usurio e a senha para realizar autenticao. J do ponto de vista tcnico, a implementao do protocolo OAuth claramente requer mais tempo com relao a autenticao bsica. Adicionando a isto a restrio de tempo imposta neste projeto e o carater de novidade que o protocolo apresenta ao autor do mesmo, optou-se pelo uso da autenticao bsica do protocolo HTTP, mesmo mtodo utilizado pelo Twitter em seus primrdios (TWITTER, 2011b). Entretanto, utilizar a autenticao bsica requer, preferencialmente, o uso de

234

algum protocolo de criptograa, como TLS (Transport Layer Security ) ou SSL (Secure Sockets Layer ) para que as credenciais do usurio no sejam transportadas pela rede em texto puro, sem nenhuma segurana. Como alternativa, ao menos temporria, seria possvel implementar a autentircao HTTP Digest, que uma melhoria com relao a autenticao bsica, evitando o envio de informaes sensveis em uma rede insegura, apesar de ainda ser vulnervel a ataques, como o man in the middle (FRANKS; HALLAM-BAKER; HOSTETLER; LAWRENCE; LEACH; LUOTONEN; STEWART, 1999). Aqui a auntenticao bsica utilizada em conjunto com tokens. Assim o cliente envia suas credenciais apenas uma vez, e por um determinado perodo de tempo ele pode utilizar o token recebido para fazer chamadas a API, ao invs de enviar as credenciais em cada chamada. No a opo ideal, como fora deixado claro no pargrafo anterior, mas j reduz a frequncia do envio das credenciais, reduzindo a janela de exposio destes dados sensveis. A Figura 3.1 mostra como o esquema de autenticao do servio funciona. O incio desta operao se d atravs do cliente, que faz a primeira requisio a API. Todos os recursos da API exigem autenticao para poderem ser acessados (com exceo de uma operao, que ser discutida depois), portanto, qualquer que seja a requisio feita pelo cliente, se as credenciais no forem informadas em primeira mo, a API ir retornar o cdigo de status 401, exigindo que o cliente informe um nome de usurio e senha. O cliente ir ento realizar uma nova requisio, desta vez enviando suas credenciais. A API ir vericar junto ao banco de dados se as credenciais so validas. Em caso positivo, um token ser gerado, utilizando informaes do usurio e outros dados (como o timestamp), atravs de algum algoritmo de hashing (e.g. MD5, SHA1). Este token poder ser utilizado pelo cliente para que ele possa fazer novas requisies a API sem a necessidade de informar suas credenciais. E para vericar que este token vlido, a API ir armazenar no memcached o token, como a chave, em conjunto com o objeto que contm as informaes do usurio autenticado. Subsequentes requisies, agora utilizando o token, sero vericadas atravs da consulta do memcached.

235

Figura 3.1: Esquema de autenticao do servio. Se o token existir, o usurio est autenticado e pode proseguir com sua requisio, caso contrrio, ele dever informar suas credenciais novamente. Uma das vantagens de se utilizar o memcached para armazenar estes dados, algo parecido com uma sesso do usurio, que no h a necessidade de controlar atravs da aplicao quando estes tokens iro expirar. Para isto basta dizer ao memcached, no momento do armazenamento do token, quanto tempo de vida ele ter. Depois deste tempo, o prprio memcached se encarregar de eliminar o token e o objeto com as informaes do usurio. Alm disso, como o memcached um sistema de armazenamento de objetos distribudo, se o servio vier a crescer e adicionar novas instncias de servidores de aplicao, os clientes no precisariam car atrelados a um servidor em especial, j

236

que os dados do token esto disponveis a todas as instncias, e no apenas aquela que o autenticou. Como fora colocado anteriormente, existe uma exceo a este esquema de autenticao, que a criao de novos usurios. Obviamente ela no pode exigir que o usurio esteja autenticado no servio, mas preciso haver alguma forma de controle de quem est criando este usurio. Neste servio a criao de usurios um recurso restrito ao aplicativo mvel, no podendo ser utilizado por terceiros. Este controle assegurado atravs de uma chave de API, armazenada no banco de dados e que identica as aplicaes autorizadas a criar usurios, neste caso, apenas o aplicativo mvel. Esta segurana , entretanto, bem simples e nada impede que ela seja quebrada. Em primeiro lugar, a chave da API precisa ser armazenada no aplicativo mvel. Atravs do pacote do aplicativo (.apk) possvel ter acesso aos bytecodes e fazer uso de algum descompilador para ter acesso as classes Java e por consequncia, ter acesso a chave da API. Alm disso, neste primeira implementao da API, a chave deve ser enviada diretamente atravs da URL, tornando fcil a interceptao da requisio e obtendo imediatamente o conhecimento do valor da chave da API. Ento, por que no implementar algum mtodo mais seguro? Primeiramente, no vale a pena, tendo em vista que o aplicativo ainda no possui usurios. Obviamente que ter o servio lotado com usurios falsos no uma situao desejvel, mas tambm no chega a ser um problema grave. Em segundo lugar, qualquer tentativa de implementar um esquema prprio para autorizao de aplicaes tambm no faz sentido, j que existe um padro largamente aceito, que o OAuth. Na prxima seo ser abordada a organizao da API, como os recursos esto disponibilizados e que operaes podem ser realizadas com eles.

237

3.3.2 Estrutura

A estrutura da API segue a os princpios denidos na seo 2.5.3, bem como exemplos de outros servios como GitHub e Twitter, que possuem APIs muito utilizadas e com rica documentao. Nesta API existem essencialmente trs endpoints: interests, conversations e users. Estas so as trs entidades principais do servios. O Quadro 3.2 descreve em detalhes cada uma das URLs disponibilizadas, os verbos HTTP permitidos para elas e uma descrio da operao que realizada pelo conjunto URL e verbo. Algumas das operaes disponibilizadas pela API implicam na listagem de grande quantidade de objetos, algo que, por razes de performance, no pode ser feito sem a utilizao de algum tipo de paginao. Especicamente, so as operaes para listagem de interesses e conversas, com as IDs: 4, 5, 8, 9, 10, 18 e 24. A paginao feita atravs de dois parmetros informados na query da URL, page e per_page, que indicam a pgina atual a ser obtida e quantos registros devem ser listados. Agora, estas listagens de interesses e conversas tambm podem ser renadas e ordenadas de acordo com alguns parmetros adicionais. O primeiro deles a localizao do usurio, que pode ser utilizada para restringir a abrangncia das conversas, para que o cliente receba apenas conversas dentro de um raio determinado. Ou a localizao pode ser utilizada para ordenar as conversas de acordo com a distncia da localizao informada, ou ambas as opes. Conversas e interesses tambm podem ser ordenados de acordo com a data da ltima atividade, sendo devolvidas na ordem das mais novas para as mais antigas, ou de acordo com a popularidade das mesmas. A consultas com ID 10 e 18 so as nicas que aceitam o uso dos parmetros para ordenao e uso de localizao. O Quadro 3.3 faz um resumo de todos os parmetros que podem ser utilizados nestas consultas.

238

ID 1

Mtodo e Recurso GET /

Descrio Raz da API

/user 2 3 4 5 GET PUT GET /interests GET /conversations Retorna informaes sobre o usurio autenticado Atualiza informaes do usurio autenticado Retorna lista de interesses que o usurio autenticado segue de acordo com parmetros informados Retorna lista das conversas do usurio autenticado de acordo com parmetros informados Cria um novo usurio Retorna informaes sobre o usurio :username Retorna lista de interesses que o usurio :username segue de acordo com parmetros informados Retorna lista das conversas do usurio :username de acordo com parmetros informados Lista os interesses de acordo com parmetros informados Cria um novo interesse Procura interesses cujo nome comece com :query Retorna informaes sobre o interesse :id

/users 6 7 8 9 POST GET /:username GET /:username/interests GET /:username/conversations

/interests 10 11 12 13 GET POST GET /search/:query GET /:id

/interests/:id/followers 14 15 16 17 GET GET /me POST /me DELETE /me Lista todos os usurios que seguem o interesse :id Verica se o usurio autenticado est seguindo o interesse :id O usurio autenticado comea a seguir o interesse :id O usurio autenticado para de seguir o interesse :id

/interests/:id/conversations 18 19 20 21 22 23 GET POST GET /:cid GET /:cid/replies POST /:cid/replies GET /:cid/replies/:rid Lista todas as conversas do interesse :id de acordo com parmetros informados Cria uma nova conversa no interesse :id Retorna informaes sobre a conversa :cid dentro do interesse :id Lista todas as respostas a conversa :cid Responde a conversa :cid Retorna informaes sobre a resposta :rid

/conversations 24 GET Lista todas as conversas de todos os interesses de acordo com parmetros informados

Quadro 3.2: Lista de recursos e mtodos da API.

239

Parmetro order radius

Tipo de Dados string: recent, popular, distance integer, em metros

Default popular

Descrio Como sero ordenados os registros. Raio de abrangncia dos registros retornados. S ir ser aplicado em conjunto com lat e lon. Valor da latitude da localizao do cliente. Valor da longitude da localizao do cliente. A pgina de registros a ser devolvida. A quantidade de registros a ser devolvida por pgina.

lat lon page per_page

oat oat integer positivo integer positivo: entre 1 e 50 1 10

Quadro 3.3: Parmetros para consultas na API.

Cdigo de Status 200 OK 201 Created 204 No Content 400 Bad Request 404 Not Found 409 Conict 422 Unprocessable Entity Descrio A requisio foi processada com sucesso O recurso foi criado com sucesso A requisio foi processada com sucesso, nada para retornar Ocorreu um erro no processamento da requisio O recurso ou operao no foi encontrada O recurso no pode ser criado, pois j existe outro com mesma identicao Existem erros nos dados enviados na requisio

Quadro 3.4: Cdigos de status HTTP.

Em conjunto com as informaes expostas no Quadro 3.2 esto os cdigos de status HTTP que podem ser utilizados para informar os clientes sobre erros na requisio ou no servidor, estes descritos no Quadro 3.4. Requisies retornadas com o status 200 e 201 retornam no corpo da resposta os dados do recurso. J os cdigos de status 4xx retornam apenas uma mensagem descrevendo o error ocorrido, exceto no caso do status 422. Neste caso retornada uma lista dos erros de validao ocorridos. Cada erro possui um identicador do erro, o campo em que o erro ocorreu e opcionalmente uma dica da soluo provvel. O campo pode ser tanto um valor informado na URL, nos parmetros da query ou de formulrios enviados atravs de POST ou PUT. Os identicadores de erros de validao esto listados no Quadro 3.5.

240

Cdigo de Erro missing_eld empty_eld invalid_value invalid_le_type invalid_type below_min_length above_max_length below_min_value above_max_value invalid_length

Descrio O campo obrigatrio e no foi encontrado O campo obrigatrio e est vazio O campo contm um valor que no permitido O campo contm um tipo de arquivo no permitido O campo contm um tipo de valor invlido O valor do campo tem tamanho menor do que o mnimo permitido O valor do campo tem tamanho maior do que o mximo permitido O valor do campo menor do que o mnimo permitido O valor do campo maior do que o mximo permitido O valor do campo tem um tamanho no permitido

Quadro 3.5: Cdigos de erros de validao.

Todas as informaes retornadas ao cliente no corpo da resposta esto no formato JSON, sendo este o nico formato suportado atualmente, por ser bastante utilizado e de mais fcil compreenso por humanos do que o XML. Alm de objetos JSON, so utilizados arrays para listas de objetos e os tipos mais bsicos: inteiros, pontos utuantes, strings e datas. Esta ltima no formato ISO 8601 (YYYY-MMDDTHH:MM:SSZ ), utilizando o tempo em UTC (Universal Time Coordinated).

3.3.3 Implementao

Como pde ser visto nas sees acima, a estrutura da API no tem um alto nvel de complexidade, contendo poucos tipos de recursos para serem manipulados: usurios, interesses e conversas. Portanto, no h necessidade de se utilizar frameworks de grande porte, sendo que apenas um subconjunto de suas funcionalidades viria a ser utilizado. Frameworks como Rails e Django fornecem um conjunto completo de ferramentas para o desenvolvimento de aplicaes, desde abtraes do banco de dados na forma de ORMs, bibliotecas para criao de layouts, migraes para bancos de dados relacionais, convenes para a organizao dos componentes da aplicao, etc.

241

Por outro lado, existem as chamadas microframeworks, que proveem apenas o essencial para a construo de aplicaes Web, deixando qualquer outro detalhe por conta dos desenvolvedores. E foi exatamente esta caracterstica que fez este projeto optar por este tipo de framework. Especicamente, a framework escolhida foi o Flask para a linguagem de programao Python. Ela fornece uma API simples para a construo de aplicaes REST, sem o overhead que outras frameworks mais completas iriam proporcionar. Como no Flask no existem controllers e sim rotas, a organizao destas foi feita atravs de arquivos, buscando separ-las de acordo com o propsito. Por se tratar de uma API RESTful, no existem views, cando ento a exibio dos dados a cargo das rotas. O formato escolhido para exibio dos dados foi o JSON, primeiro por ser um formato mais simples e descritivo do que o XML; segundo, porque ele mais leve do que o XML, quando se trata de tamanho de arquivos; e terceiro, porque muito mais simples fazer parse em arquivos JSON do que em arquivos XML. Como pde ser visto na seo anterior, a API aceita algums parmetros para controle de paginao ou ltragem de informaes, como o caso da latitude e longitude. Alm destas entradas de dados, existem aquelas feitas em algumas operaes de POST e PUT, onde novas entidades so criadas. Por razes de segurana, nenhuma entrada proveniente dos usurios pode ser considerada convel. Alm disso, alguns parmetros possuem restries quanto aos tipos de dados e tamanho aceitos, sendo que alguns aceitam apenas valores especcos. Para atender essas necessidades, foi criada uma pequena biblioteca para criao de formulrios para APIs, que permitem a declarao de regras e validao das entradas recebidas dos usurios, fornecendo ainda mensagens descritivas sobre os erros de validao, que podem ser utilizadas pelo usurio para san-los. Com relao as entradas do usurio que sero gravadas no banco de dados, elas so feitas atravs de prepared statements, evitando desta forma ataques de sql injection. Ainda com relao ao acesso ao banco de dados, ele feito sem o uso de

242

frameworks de ORM, utilizando-se apenas a biblioteca psycopg. Os mtodos para acesso ao banco de dados foram distribudos em classes, uma para cada tabela, sendo que todos os mtodos so estticos. Os registros, por sua vez, correspondem a instncias destas classes, sendo o mapeamento de campos em atributos feito pela prpria classe da entidade/registro.

3.4 BANCO DE DADOS

Esta seo detalha o processo de escolha do banco de dados mais adequado para este projeto, bem como a forma como os dados foram organizados no banco de dados escolhido.

3.4.1 Comparao

Um dos requisitos para o banco de dados so servio a capacidade de realizar buscas espaciais, ou mais especicamente, pesquisar registros localizados at certa distncia de um ponto determinado, utilizando como coordenadas a latitude e longitude. No que tange este assunto, a seo 2.2.9 forneceu algumas informaes para iniciar a escolha do SGBD mais adequado para a tarefa. O primeiro passo neste escolha foi realizar uma avaliao de desempenho de cada uma das ferramentas, levando em conta ainda todas as outras caractersticas e implicaes inerentes a cada uma das opes. Para os testes foi utilizado um banco de dados de teste com mais de 2 milhes de registros de locais nos Estados Unidos disponveis no site geonames.org, contendo, dentre outras informaes, a latitude e longitude destes. O primeiro dos candidatos a passar pelo teste foi o MySQL. Como fora mencionado algumas vezes no Captulo 2, ele d suporte a um subconjunto de funes, tipos de dados e ndices (ndice na verdade, apenas um) espaciais. O primeiro trade-off encontrado com relao ao storage engine a ser escolhido, sendo os mais populares MyISAM e InnoDB. O primeiro deles muito conhecido por ser o default das

243

instalaes do MySQL, alm de apresentar um bom desempenho e ser a nica storage engine a dar suporte ao ndice espacial. O InnoDB, como fora colocado na seo 2.4.1.1, possui desempenho que em muitos casos j se equiparam ao MyISAM, sem falar no suporte a chaves estrangeiras. Outro ponto em favor do InnoDB o uso de row locking ao invs de table locking para escrita de dados, caracterstica que favorece muito sistemas com muitas transaes em paralelo. O que cou claro at este ponto, embasado na literatura, que o InnoDB apresenta mais vantagens na implementao deste servio do que o MyISAM. Entretanto, apenas com testes prticos possvel determinar qual a melhor opo. Nestes testes vrias ferramentas foram avaliadas para identicar a possibilidade de se comparar o desempenho das mesmas de forma justa. Infelizmente, foram encontradas diculdades ao reproduzir as mesmas consultas com os mesmos resultados dentre as ferramentas testadas. Para este servio uma consulta em especial interessa, que a consulta para retornar conversas dentro de um raio em alguma posio determinada. Algumas ferramentas possuem funcionalidades nativas para este tipo de consulta, outras possuem pouco suporte e outras ainda necessitam de plug-ins para funcionar. As sees a seguir iro descrever os testes realizados com cada uma das ferramentas, e embora no seja prudente tomar estes testes como uma comparao entre elas, os resultados serviram sim de base para a escolha da mais adequada. Os testes foram executados 20 vezes em cold cache, ou seja, sem o uso do cache de consultas do banco de dados. Do contrrio, apenas a primeira consulta atingiria o disco e as consultas subsequentes seriam recuperadas na memria do computador, pois j haveriam sido feitas anteriormente. Em um cenrio real, o uso do cache certamente uma vantagem, entretanto, neste aplicativo as consultas dicilmente sero repetidas, pois elas dependem da localizao do usurio. Uma alternativa seria, antes de realizar a consulta espacial, determinar em que cidade o usurio est e ento realizar uma consulta utilizando a localizao da

244

Software Debian Linux kernel MySQL PostgreSQL PostGIS CouchBase Server Apache Solr MongoDB Ruby

Verso 6.0.3 2.6.32-5-686 5.1.49 8.4.9 1.5.1 1.2.0 3.5.0 2.0.1 1.9.2p290

Quadro 3.6: Software utilizado e suas verses.

cidade e no a do usurio, aumentando a chance de utilizao do cache de consultas do banco de dados. O Quadro 3.6 especica as verses dos softwares utilizados para estes testes. Todos eles foram executados em uma mquina virtual VirtualBox com 1 processador (Intel Core i5) e 1GB de memria RAM, com sistema operacional Debian 32 bit, atravs de scripts escritos na linguagem de programao Ruby.

3.4.1.1 MySQL

Apesar de apresentar algumas funes para consultas espaciais, consultar locais ao redor de uma localizao requer o uso de frmulas de distncia. Neste teste foram criadas duas consultas, uma utilizando a frmula de Haversine e outra com a frmula da Lei Esfrica dos Cosenos. Ambas consultas foram feitas tanto para o storage engine MyISAM como InnoDB. Como pode ser visto na Figura 3.2, em qualquer valor do raio a consulta mais rpida a 1/MyISAM. Na consulta 2, MyISAM no se sai to bem, apesar de desempenhar melhor do que InnoDB em quase todos os raios testados. O que ca claro neste grco o pssimo desempenho do InnoDB, fruto da ausncia de um ndice espacial, algo que apenas o MyISAM possui e que lhe garante vantagem absoluta nos

245

testes. E enquanto que a consulta 1, que utiliza a frmula de Harvesine, mostrou os melhores resultados sob o MyISAM, a mesma mostrou os piores resultados com o InnoDB. A bem da verdade, analisando os resuldados em maiores detalhes no Quadro 3.7, utilizar o InnoDB impraticvel. Ainda mais se for levado em conta que na Web, de acordo com WebsiteOptimization (2008), o tempo de espera tolervel (TWT Torelable Wait Time) de um usurio gira em torno dos dois segundos. O MyISAM, por outro lado, teve um desempenho timo na consulta 1, enquanto que na consulta 2 os resultados foram insatisfatrios, com tempos de execuo variando de 3 a 26 segundos, nos piores casos. A explicao provvel para este comportamento do MyISAM a de que a consulta 2 no tirou vantagem dos ndices espaciais fornecidos pela engine, resultando em um desempenho semelhante ao do InnoDB. Atravs destes testes cou claro que a melhor opo, para buscas espaciais no MySQL, o uso da frmula de Harvesine em conjunto com o storage engine MyISAM e seu ndice espacial.

3.4.1.2 PostgreSQL

Ao contrrio do MySQL, o PostgreSQL no trs suporte nativo a operaes espaciais. Entretanto, a extenso PostGIS uma das mais completas, ao menos no que diz respeito a bancos de dados open source. Alm disso, com o PostgreSQL no existe o trade-off encontrado no MySQL, pois possvel ter o melhor das consultas espacias, sem largar mo da integridade referencial e das propriedades ACID que as transaes fornecem. Os testes no PostgreSQL utilizaram o mesmo banco de testes utilizado para o MySQL, com mais de 2 milhes de registros. A latitude e longitude foi armazenada em um campo do tipo Point, mas este campo no fora utilizado nas consultas. Ao invs disso, foi criado um campo especco do PostGIS com SRID 32661 e todos

246

Query 1/InnoDB 1/InnoDB 1/InnoDB 1/InnoDB 1/InnoDB 1/InnoDB 1/InnoDB 1/MyISAM 1/MyISAM 1/MyISAM 1/MyISAM 1/MyISAM 1/MyISAM 1/MyISAM 2/InnoDB 2/InnoDB 2/InnoDB 2/InnoDB 2/InnoDB 2/InnoDB 2/InnoDB 2/MyISAM 2/MyISAM 2/MyISAM 2/MyISAM 2/MyISAM 2/MyISAM 2/MyISAM

Raio 50 100 150 200 280 370 500 50 100 150 200 280 370 500 50 100 150 200 280 370 500 50 100 150 200 280 370 500

Mdia 25.3963856 8.918659479 9.184612243 9.002513411 9.158097704 9.036220277 9.111568156 0.342944947 0.162466984 0.014697226 0.037450919 0.015471062 0.034446375 0.033719628 7.835595115 7.597728427 7.584073729 7.686057433 7.549682913 7.643851638 7.777668057 12.43747528 10.04227534 4.063199493 3.874031245 3.780425888 3.961201353 3.901904453

Desvio Padro 2.87423185 0.455065762 0.554286073 0.618880565 0.585273137 0.594831114 0.478069773 0.201610002 0.108464948 0.002782669 0.024708571 0.002302155 0.024092818 0.017654063 0.513185321 0.509141196 0.50736585 0.614693898 0.497227841 0.455250469 0.459010009 5.953614709 5.2461031 0.35007796 0.223471709 0.16681414 0.217224735 0.221475713

Mn 22.27372286 8.370354747 8.199370573 8.190699156 8.215168046 8.103175553 8.325641132 0.149985294 0.015065089 0.010941507 0.01340804 0.011527046 0.015447966 0.019523905 7.115948719 6.849792313 6.936892847 6.744370935 6.94702263 7.049076928 7.09865471 5.9463121 4.36648074 3.516136054 3.636232327 3.550481355 3.589243086 3.594542222

Mx 33.68926384 9.907915609 10.0893714 10.55999708 10.61326181 10.02528588 9.911057422 1.024606131 0.347804329 0.024135269 0.080821854 0.020880228 0.073542716 0.068225676 8.842590562 8.876596824 8.90440893 8.784622551 8.877349579 8.805104042 8.563215639 26.18184967 17.24486435 4.988798643 4.303127032 4.045565961 4.347172164 4.380481201

Quadro 3.7: Resultado dos testes no MySQL.

247

Figura 3.2: Tempo mdio de execuo no MySQL.

os registros foram atualizados atravs da converso do campo contendo a latitude e longitude. Tambm fora utilizado um ndice GiST, especco da extenso PostGIS e que faz uso de estruturas de dados R-Tree, para garantir o maior desempenho nas consultas espaciais. Com o banco de dados pronto para os testes, foram construdas duas consultas que seriam comparadas para determinar qual delas a mais eciente. Ambas consistem em encontrar pontos dentro de um raio com relao a uma localizao xa, tal qual ocorreria em uma busca por conversas ao redor de um usurio. A primeira das consultas utiliza as funes ST_Expand e ST_Distance, enquanto que a segunda consulta utiliza a funo ST_DWithin. A primeira consulta utiliza a funo ST_Expand para limitar os resultados para apenas aqueles que se encontram dentro de uma caixa delimitadora (bounding box), para ento utilizar ST_Distance e devolver apenas os resultados dentro do raio de distncia. E segundo PostGIS (2012b), a funo ST_DWithin, at a verso 1.3.4, era apenas uma interface resumida que por baixo utiliza as duas funes. Entretanto, aps

248

a verso 1.3.4, ST_DWithin passou a utilizar um mtodo mais eciente para regies com grandes buffers. Como pode ser observado na Figura 3.3, a documentao estava certa, tendo a consulta 2 obtido resultados signicativamente melhores do que a consulta 1. A consulta 2 tambm se mostrou mais estvel, com desvio padro muito baixo em todos os valores de raio. O que tambm notvel na consulta 2 que a mdia de tempo de execuo pouco se alterou, independentemente do raio. J a consulta 1 apresentou um desempenho sofrvel, apresentando ainda um desvio padro muito alto, tendo consultas que duraram 0.10 segundos em um momento, e em outros consultas com mais de 3 segundos de durao, tambm independentemente do raio, o que neste caso no algo bom. Vale ressaltar aqui que o desempenho das consultas tambm ir depender da quantidade de registros que precisaro ser retornados. Por exemplo, se a regio a ser consultada tiver pouca atividade, ou seja, poucas conversas nos arredores, provvel que a consulta demorar menos tempo para ser executada do que em uma regio onde muitos usurios esto gerando conversas. Como concluso dos testes, cou claro que a funo ST_DWithin (e consequentemente a consulta 2) mais eciente para este tipo de busca, como a prpria documentao do PostGIS havia deixado claro.

3.4.1.3 Concluso

Alm dos testes realizados com o MySQL e PostgreSQL, os bancos de dados MongoDB e CouchDB tambm foram considerados, sendo que testes semelhantes aos acima descrito foram conduzidos. Entretanto, fatores como a maturidade dos projetos, ausncia de mecanismos de consulta to poderosos quanto o SQL, alm de outras funcionalidades presentes em bancos de dados relacionais pesaram contra estas ferramentas. Juntamente com os dois bancos de dados NoSQL, tambm foram realizados

249

Figura 3.3: Tempo mdio de execuo no PostgreSQL.

alguns testes com o servidor de buscas Solr, mas no nal ele tambm foi descartado pois ainda haveria a necessidade de se utilizar um banco de dados principal, alm da criao de uma rotina para a alimentao do Solr, algo que adicionaria complexidade ao projeto sem, entretanto, trazer um retorno justicvel. Algumas das funcionalidades que pesaram na escolha do banco de dados podem ser vistas no Quadro 3.9, que faz uma comparao entre os softwares aqui testados. Alm disso, os dois bancos de dados relacionais testados so mais do que adequados para as necessidades deste projeto, sem contar que so projetos implantados em milhares de softwares e largamente testados em produo. Dito isto, preciso deixar claro aqui que a escolha do banco de dados no levou em conta somente o desempenho demonstrado nos testes, mas o conjunto de funcionalidades fornecidas. E como fora colocado anteriormente, o engine MyISAM do MySQL no possu muitas das funcionalidades desejadas em um banco de dados, inclusive no que diz respeito a integridade de dados, o que preocupante.

250

Query 1 1 1 1 1 1 1 2 2 2 2 2 2 2

Raio 50 100 150 200 280 370 500 50 100 150 200 280 370 500

Mdia 2.023276785 1.573119782 0.673521194 0.293412519 0.480442147 0.725162177 1.413704392 0.060000905 0.043981964 0.029057685 0.023550989 0.03148176 0.030663415 0.041608999

Desvio Padro 0.449411528 0.300722805 0.164871785 0.131080629 0.133448227 0.184651955 0.174625766 0.027037792 0.02681786 0.017823684 0.002017744 0.017213881 0.003700193 0.004082383

Mn 1.460058504 1.196857349 0.439820264 0.104332802 0.278005399 0.50719545 1.108397872 0.013825312 0.018024822 0.020619376 0.01944228 0.02292826 0.024462041 0.033842011

Mx 3.170215684 2.239702522 1.016725018 0.602487965 0.859064477 1.370875515 1.75369911 0.140688447 0.09704693 0.090725865 0.028737774 0.085372681 0.040065034 0.049886418

Quadro 3.8: Resultado dos testes no PostgreSQL.

Software MySQL (InnoDB) MySQL (MyISAM) PostgreSQL (c/ PostGIS) CouchDB (c/ GeoCouch) MongoDB Solr Integridade Referencial Sim No Sim No No No ndices Espaciais No R-Tree GIST (variante do R-Tree) R-Tree No Transformao entre Ref. Esp. No No Sim No No No

Fonte: Hsu e Obe (2008); MongoDB (2012); Mische (2012); Solr (2012).

Quadro 3.9: Comparao entre softwares para consultas em dados espaciais. Por outro lado, a engine InnoDB fornece estas funcionalidades, mas no implementa os ndices espaciais, que como os testes puderam comprovar, tem grande impacto no desempenho de consultas espaciais, tornando o InnoDB imprticavel neste tipo de consultas. A escolha mais vivel passou a ser o PostgreSQL, banco de dados escolhido para este projeto. O desempenho dele nas consultas espaciais no to bom quanto o do MySQL (com o MyISAM), mas a diferena no chega a ser muito grande. Alm

251

disso, o PostGIS fornece uma gama muito maior de funes espaciais, permitindo a criao de consultas muito mais complexas. E, claro, o PostgreSQL um banco de dados que garante a integridade dos dados, possuindo as funcionalidades bsicas que se espera de um banco de dados, como as propriedades ACID e a integridade referencial dos dados. Por m, importante deixar claro o motivo pelo qual no foi feita uma comparao direta entre MySQL e PostgreSQL. Apesar de os testes realizados em ambos bancos de dados terem sido realizados sobre uma base de dados com os mesmos registros e utilizando-se de consultas com entradas equivalentes, as sadas geradas pelos bancos de dados no foram iguais. Em outras palavras, as funes utilizadas para consultas espaciais do MySQL e PostgreSQL no so iguais, muito embora tenha-se procurado utilizar funes com o mesmo propsito, que era o de retornar registros localizados dentro de um raio determinado.

3.4.2 Modelo ER

Mesmo durante a avaliao de qual seria o banco de dados ideal para este trabalho, a descrio das funcionalidades j permitira a criao das estruturas que iriam armazenar as informaes do servio, estruturas estas que foram evoluindo ao longo do tempo para acomodar todas as necessidades. E com a denio do banco de dados, que no caso fora um banco de dados relacional, foi possvel ento formalizar estas estruturas em um modelo ER, algo que tambm seria possvel para bancos de dados NoSQL, mesmo que atravs de diagramas mais genricos e simples. Assim como fora salientado na descrio da API sobre a existncia de trs entidades principais, no banco de dados a situao semelhante. Entretanto aqui, existem vrias outras tabelas circundando estas entidades, provendo meios para armazenamento de informaes adicionais e de suporte, seja por necessidades mais tcnicas como do servio em si. Como padro denido, todas as tabelas principais, ou seja, todas exceto aquelas que servem para criar relacionamentos n:m, so identicadas atravs de um cdigo

252

inteiro sequencial. No PostgreSQL este tipo de dados chamado de Serial, que no passa de um campo inteiro, mas que quando criado no SGBD automaticamente cria uma sequncia e uma trigger que ir atribuir o valor da sequncia aos novos registros. A escolha por um valor inteiro e sequencial a mais vista em aplicaes com banco de dados, e levando em conta que neste aplicativo no haviam chaves naturais para as entidades, utilizar nmeros inteiros era a escolha bvia. E mesmo que alguma entidade possusse uma chave natural (como uma pessoa e seu CPF), ainda assim, por questes de performance, o uso de um nmero inteiro poderia fazer sentido. Alternativamente, poderia ter sido utilizada uma soluo hbrida para a chave primria das principais entidades, assim como fora feito pelo Instagram (ver seo 2.7.1). Claro que neste caso se tratava de uma soluo para o sharding do banco de dados, utilizando o timestamp de criao do registro, identicao do shard e um nmero sequencial gerado pelo SGBD. De qualquer forma, uma soluo que pode ser usado futuramente, caso surja a necessidade. Ainda sobre padres estabelecidos dentro do banco de dados, foi decidido que todas as datas operariam sobre o tipo Timestamp sem fuso horrio, utilizando a hora em UTC, assim como fora descrito na seo 3.3.2. Alm disso, para assegurar este padro todas as datas so inseridas atravs de triggers ao invs de serem informadas atravs da aplicao, garantindo assim que todas as datas esto em UTC. Assim, se houver a necessidade de utilizar algum fuso horrio especco para um usurio, esta tarefa estar a cargo do aplicativo mvel, que precisar apenas converter a data de UTC para o fuso horrio escolhido. Voltando ao modelo ER, uma das principais entidades entidades so os usurios. Nela, como o nome sugere, cam armazenadas as informaes sobre cada um dos usurios do servio. H um nome de usurio, valor que deve ser nico no banco de dados, pois servir para identic-lo no servio. Alm disso, como ser utilizado em URLs optou-se por permitir apenas valores alfanumricos, lgica esta implementada pela aplicao, no o banco de dados. O email tambm outro campo nico dentro do banco de dados.

253

A senha do usurio no banco de dados armazenada em um campo de tamanho constante, com 60 caracteres. A aplicao utiliza o algoritmo bcrypt, que um mtodo de criptograa do tipo hash baseado no Blowsh, para armazenar as senhas de modo a garantir que em caso do o banco de dados venha a ser exposto, as credenciais dos usurios no sejam expostas. Este algoritmo apresenta vrias vantagens com relao a outros mtodos de hash (e.g. MD5, SHA1, SHA256), pois foi desenvolvido para ser lento, tornando ataques de fora bruta mais custosos (HALE, 2010). O campo de status do usurio utiliza um valor inteiro para indicar o status atual da conta, podendo esta estar pendente, ativa, bloqueada ou removida. Nem todos estes status so utilizados atualmente pelo servio, mas podero vir a ser utilizados. No caso da remoo de uma conta, por exemplo, faz mais sentido utilizar um cdigo de status do que remover de fato o registro da tabela pois isto tornaria o estado do banco de dados inconsistente. Na verdade, nem seria possvel remover o registro sem antes remover toda a atividade relacionada ao usurio, por causa da integridade referencial. S que no faz sentido remover todas as conversas de um usurio apenas porque ele decidiu remover sua conta. Por isso a deciso de utilizar um cdigo para indicar contas no mais ativas, mantendo o histrico do usurio. Cada usurio possu ainda um campo que contm a URL para seu avatar (foto do perl, se preferir) que aponta, caso o usurio tenha escolhido ter um avatar, para um endereo na Amazon S3, onde estar armazenada a foto. Por m, existem dois campos de timestamp que informam quando a conta foi criada e a ltima vez que ela fora modicada. Adicionalmente a esta ltima informao, existe a tabela de modicaes do usurio, reponsvel por armazenar informaes antigas da conta do usurio. Por exemplo, se um usurio modicar seu avatar, email ou nome de usurio, o valor antigo deste campo ser armazenado nesta tabela auxiliar, para manter um histrico de alteraes de sua conta. Neste caso, bem como outros que sero visto mais frente, foram utilizadas stored procedures ativadas por triggers para tomar registro das alteraes na tabela de usurios.

254

Usurio so ainda os responsveis pela criao de interesses, apesar de no receberem a autoria de tal ao, no que diz respeito ao banco de dados. Um usurio pode seguir interesses, como fora descrito anteriormente, e portanto possui um relacionamento N:M com os interesses. Nesse relacionamento existe ainda um campo timestamp que indica quando este relacionamento se estabeleceu. Ainda, assim como na prpria tabela de usurios, existe na tabela que estabelece o relacionamento entre usurios e interesses uma trigger que acionada quando um usurio deixa de seguir um interesse, criando ento um novo registro na tabela de interesses antigos do usurio, mantendo desta forma registro dos interesses que o usurio um dia seguiu, especicamente informando quando o relacionamento comeou e terminou. A entidade interesse por sua vez mais simples, contm, alm da identicao, apenas o nome e a data de criao. Seguindo a hierarquia, abaixo dela esto as conversas, suas lhas. Cada conversa possui um timestamp de quando foi criada, opcionalmente a latitude e longitude, que indica o local de onde o usurio enviou esta conversa, a mensagem, a identicao de qual usurio a enviou, e a qual interesse esta conversa pertence. Agora, conversas podem signicar conversas iniciadas ou respostas a estas conversas. Esta diferenciao feita atravs do campo parent_id, que se for nulo indica que uma conversa iniciada e se houver algum valor inteiro nele, esta uma resposta a conversa identica por este valor. Optou-se aqui por esta estrutura de conversas (normalmente se usa a palavra tpico) pela sua simplicidade e facilidade de visualizao e compreenso. Este tipo de estrutura conhecido como linear ou plano, e pode ser considerado o oposto de threaded, que aquela estrutura onde respostas podem se ramicar interminvelmente. Do ponto de vista tcnico, conversas na estrutura threaded no chegam a ser um desao, levando em conta que existem softwares que utilizam esta abordagem a muito tempo, bastaria apenas analisar como estes softwares implementam esta abordagem (como o software phpBB e o servio reddit, ambos open source). De qualquer forma, a simplicidade de conversas em estrutura plana, alm do fato que este tipo de estrutura evita (ou ameniza) a existncia de conversas paralelas e muitas vezes fora do tpico original (offtopic) da conversa (ATWOOD, 2006).

255

E esta a estrutura principal do servio. O que fora descrito at agora corresponde a todas as funcionalidades fornecidas pelo servio. Alm disso, esto outras tabelas auxiliares que so tabelas de sumrio sobre as tabelas principais, todas alimentadas atravs de triggers. Cada usurio possui uma registro na tabela de sumrio dos usurios. Esta tabela informa quantas conversas um usurio criou, quantas respostas a conversas ele criou e quantos interesses ele est seguindo atualmente. Toda vez que um usurio cria uma conversa ou responde a uma conversa, comea ou deixa de seguir um interesse, triggers so ativadas, e estas iro chamar stored procedures que iro contabilizar estas atividades do usurio na tabela de sumrio. Esta tabela evita o uso da funo COUNT em SQL, toda vez que estes dados precisarem ser obtidos. A entidade interesses tambm possui sua tabela de sumrio, que indica quantas conversas iniciadas o interesse possui e quantas conversas e respostas. Estes valores sero utilizados posteriormente para calcular a popularidade de um interesse, que por enquanto feito utilizando apenas o nmero total de conversas. Sumrios mais granulares podem vir a ser adicionados futuramente, armazenando, por exemplo, contadores de conversas em fragmentos que correspondem a perodos xos de tempo, como de cada ms ou semana, permitindo desta forma apontar interesses que esto ganhando popularidade. Por m, as conversas tambm possuem tabelas de sumrios. Elas so duas, uma para indicar quantas respostas uma conversa obteve e outra para listar todos os usurios que esto participando da conversa. claro que no caso de uma conversa as tabelas de sumrio venham a perder um pouco de sua nalidade, j que conversas tendem a ter menos registros. Entretanto, a inexistncia desta tabela de sumrio signicaria que selecionar conversas com a quantidade de respostas da mesma necessitaria de um select aninhado. claro que para identicar a melhor abordagem (select aninhado ou inner join em uma tabela de sumrio) seria necessrio realizar testes de desempenho, algo que no est no escopo deste trabalho. Por m, existe a tabela de aplicaes, isolada de todas as outras. Ela sim-

256

plesmente guarda o nome da aplicao e uma chave de API, que servir para que a aplicao se identique ao servio. Por enquanto, haver apenas um registro identicando a aplicao mvel, como fora explanado na seo 3.3.1.

3.5 IMPLANTAO

A implantao (tambm conhecida como deploy ) da API foi feita atravs da computao nas nuvens, devido principalmente a facilidade de alocao de recursos de acordo com a demanda, bem como custos seguindo o modelo pay-as-you-go (pague pelo o que usar). A vantagem de possuir capacidade de computao disponvel a medida do necessrio remove a necessidade de planejamento com relao a aquisio de infraestrutura, sem contar na mo de obra necessria para manuteno desta infraestrutura. Exemplos como o do Instagram, descrito na seo 2.7.1, mostram como possvel ter um servio nas nuvens escalando para milhes de usurios, e em um perodo de tempo inferior a um ano. Outra deciso tambm muito importante na implantao foi qual tipo de servio utilizar: PaaS ou IaaS. O primeiro permite a implantao de aplicaes sem a necessidade de instalao e congurao de softwares, ao custo da perda de exibilidade at certo ponto. Enquanto que com servios de IaaS as possibilidades se equiparam as de possuir uma infraestrutura prpria, permitindo at mesmo a escolha do sistema operacional que ser utilizado e a capacidade das mquinas alocadas (memria, processadores, armazenamento). Devido alguns dos requisitos de software existentes na API desenvolvida, como banco de dados e bibliotecas, utilizou-se um servio de IaaS, mais especicamente a Amazon Web Services. A Figura 3.5 ilustra como est organizada a infraestrutura do servio na Ama-

257

Figura 3.4: Modelo ER da aplicao.

258

Figura 3.5: Esquema da infraestrutura utilizando os servios da Amazon AWS.

zon AWS. A API executada em uma instncia EC2 (tipo Micro, com Ubuntu Server 12.04 LTS 64 bit) atravs do servidor de aplicaes uWSGI que utiliza a interface WSGI para se comunicar com a framework Flask. Na frente do servidor est o servidor HTTP nginx, que funciona como um proxy reverso, redirencionando as requisies pertinentes ao servidor de aplicaes, no caso, todas as requisies destinadas ao sub-domnio api.boardhood.com. Enquanto que requisies ao domnio boardhood.com, tambm servidas pelo nginx, so direcionadas para a pgina de apresentao da aplicao, composta apenas de arquivos estticos (HTML, CSS e JS). A instncia que contm a API tambm comporta o banco de dados PostgreSQL 9.1 e o memcached. Uma outra instncia EC2 utilizada para monitorar a instncia com a API atravs do software de monitoramente em rede Munin. Nesta instncia tambm est instalado o servidor HTTP Apache, que permite o acesso aos relatrios gerados pelo Munin, como relatrios de I/O do disco rgido, utilizao de armazenamento, utilizao do processador, processos em execuo, requisies HTTP, conexes com o PostgreSQL, alm de vrios outros relatrios que podem ser congurados atravs de plugins. Alm do EC2, a API faz uso do Amazon S3 para armazenamento dos avatares

259

(imagens de perl) dos usurios que so acessados pelo cliente mvel diretamente, sem passarem pelo servidor da API, sendo que esta apenas recebe a imagem (quando o usurio decide adicionar um avatar ao seu perl), redimensiona ela (apesar de isto j ser feito no cliente, para reduzir o tempo de transferncia dos dados) e a envia para o S3, salvando no banco de dados a url criada. Tendo denido onde ser implantada a API, preciso estabelecer uma estratgia para executar a implatano do cdigo desenvolvido, testado e pronto para entrar em produo ou ser testado em um ambiente de staging. Para alcanar tal objetivo foram denidas na verdade duas estratgias, ambas tem como objetivo garantir a rpida implantao de aplicaes. A primeira estratgia foi utilizada durante o desenvolvimento, com uma instncia EC2 especca para testes. Nesta instncia existem dois repositrios Git, um deles um repositrio bare, que serve como um repositrio remoto que recebe modicaes. O outro repositrio o repositrio que contm o cdigo que ser executado no servidor, e ele atualizado automaticamente toda vez que modicaes so enviadas para o repositrio bare. Em uma mquina local, utilizada para desenvolvimento, existe um repositrio clone do repositrio bare, e qualquer modicao nele feita pode ser commitada e "empurrada"(push) para o repositrio bare, que por sua vez ir, atravs de um script, atualizar o repositrio que ir executar a aplicao. A vantagem desta estratgia de que ela permite que modicaes sejam rapidamente implantadas e visualizadas no servidor. Entretanto, esta no uma estratgia ideal para o ambiente de produo que, apesar de requerer um mtodo rpido para implantao de aplicaes, tambm requer um mtodo que garanta que a aplicao ir funcionar, se certicando, por exemplo, de que o ambiente onde a aplicao foi implantada atende a todos os seus requisitos. Em Python, assim como em muitas outras linguagens, muitas bibliotecas so utilizadas em aplicaes e a atualizao de uma delas pode signicar problemas, seja pela mudana da API, modicao no comportamento de alguma funo ou algum

260

erro introduzido. De qualquer forma, uma aplicao, antes de ser implantada, precisa ser testada e preciso garantir que as verses das bibliotecas no ambiente de produo sejam as mesmas das do ambiente de desenvolvimento. Para se fazer isso em Python possvel fazer uso do distribute, uma ferramenta que empacota aplicaes Python e garante que durante a instalao todas as dependncias da aplicao sero instaladas de acordo com as verses especicadas no pacote de instalao. Resolvido o problema das dependncias da aplicao, resta ainda denir uma forma para enviar a aplicao para o servidor, instal-la, efetuar possveis modicaes nos arquivos de congurao dos servidores de aplicao e HTTP e reinici-los para que as modicaes tenham efeito. Mesmo possuindo apenas um servidor para instalar a aplicao, so muitos passos a serem seguidos, e cada um deles pode abrir brechas para a insero de erros, caso sejam executados manualmente. Alm disso, executar manualmente a implantao signica que todo o processo est armazenado apenas na cabea de um ou alguns indivduos, e mesmo que haja alguma documentao, sempre existe a chance de ela no estar atualizada. Para evitar este problema, uma soluo muito utilizada a criao de scripts que executam todas as etapas da implantao, servindo ainda como uma documentao sempre atualizada do processo. Para acessar as instncias EC2 possvel fazer uso de SSH, e pensando nisto foi criada uma ferramenta em Python chamada de Fabric. Ela permite a execuo de comandos via SSH tanto em mquina local como em mquinas remotas. Com o uso desta ferramenta foram criados duas rotinas principais: uma para a instalao dos softwares bsicos, como banco de dados, servidores de aplicao e HTTP, memcached, alm de vrias bibliotecas das quais outros softwares dependem; e outro para empacotar a aplicao e implant-la no ou nos servidores de produo, modicando ainda arquivos de congurao necessrios e reiniciando os servidores. Com estes scripts, criar uma nova instncia e implantar a aplicao uma

261

questo de executar uma nica linha de comando, algo muito bom, se comparado com a execuo manual de tais processos, algo trabalhoso e que pode levar a muitos erros durante o caminho.

3.6 APLICAO MVEL

No desenvolvimento deste servio algumas perguntas foram levantadas desde o comeo. A primeira era se seria melhor desenvolver primeiro para a Web Desktop ou para dispositivos mveis. E levando em conta os dados colocados na seo 2.8, cou evidente que as possibilidades proporcionadas pelos dispositivos mveis muito grande, sem contar que aplicaes pensadas primeiro para dispositivos mveis tendem a ser mais simples e mais focadas no objetivo principal da aplicao, removendo qualquer outra funcionalidade secundria e que s teria espao em computadores desktop. Decidido o segmento de dispositivos a ser suportado, a segunda deciso foi a de desenvolver uma aplicao nativa ou web mvel. Depois de avaliar as possibilidades disponveis em ambas as opes, cou claro que apesar de a web mvel se mostrar atrativa, atravs da promessa de desenvolver aplicaes com suporte a vrias plataformas, o estado atual destas tecnologias ainda no oferecem a melhor experincia possvel para usurios de dispositivos mveis, sendo que por enquanto, aplicaes nativas ainda so a melhor opo. Com a deciso de desenvolver uma aplicao nativa, restou a escolha de para qual plataforma desenvolver o aplicativo. De antemo, as plataformas do Symbian, Blackberry e Windows Phone foram descartadas, sendo as duas primeiras devido a drstica queda de popularidade e a terceira devido ao ainda pequeno nmero de usurios, algo que pode mudar no futuro, mas por enquanto no interessante para um servio que precisa do mximo de usurios possveis. Sendo assim, restaram as plataformas Android e iOS. Se a deciso fosse tomada levando em conta o que outros servios da web zeram, como Twitter, Facebook, Foursquare, Path e Instagram, iOS seria a escolha certa. Entretanto, outros

262

fatores precisam ser levados em conta na escolha da plataforma mais adequada. Para este servio, a plataforma Android foi escolhida. Primeiro, porque ela j se posiciona em primeiro lugar no nmero de dispositivos em todo o mundo e continua crescendo. Segundo, aplicaes Android so desenvolvidas na linguagem de programao Java, o que torna a curva de aprendizado menor, ao contrrio do iOS, que faz uso de Objective-C. Alm disso, as ferramentas de desenvolvimento para o Android podem ser executadas nos principais sistemas operacionais no mercado, ao contrrio do iOS, que exige um computador Mac e, obviamente, sistema operacional Mac OS X. A aplicao foi desenvolvida utilizando a IDE Eclipse em conjunto com o plugin ADT (Android Development Tools), tendo como alvo dispositivos com a verso 2.1 ou superior do sistema operacional, garantindo assim que mais de 97% dos dispositivos do mercado possam executar a aplicao. Antes do incio do desenvolvimento da aplicao, foram criados os mock-ups (Figura 3.6) da aplicao, ilustrando o posicionamento dos componentes na tela e denindo algumas convenes que seriam utilizadas por toda a aplicao, garantindo assim consistncia a interface de usurio. A medida em que as telas do aplicativo, bem como o uxo das atividades que os usurios poderiam seguir foram denidas, a interface do usurio comeou a ser criada no Photoshop, esta agora representando como a aplicao deveria ser, exatamente. Alguns podem argumentar sobre as vantagens de se criar uma UI l ao que se deseja no Photoshop ao invs de fazer isso diretamente na programao, algo que tambm muito discutido com relao a aplicaes Web. Mas a verdade que, apesar de tudo, o Photoshop ainda d uma liberdade maior na criao de interfaces, pois as modicaes podem ser visualizadas instantaneamente, enquanto que no Android preciso modicar o cdigo-fonte, compilar e executar a aplicao. Mas nem tudo dentro de uma aplicao mvel est relacionada com uma interface grca. Por exemplo, a comunicao entre o aplicativo e o web service no de-

263

Figura 3.6: Primeiros mockups do aplicativo.

pende de uma interface, e neste caso nem mesmo das APIs do Android. Aproveitando esta oportunidade, o desenvolvimento do aplicativo foi separado do desenvolvimento do cliente que iria se comunicar com o web service, permitindo que este possa ser reutilizado por outras aplicaes Java, se algum dia surgir esta necessidade. Este cliente ca ento responsvel pela comunicao atravs do protocolo HTTP com o web service, sendo responsvel ainda pela compresso/descompresso (normalmente gzip) de mensagens, serializao de parmetros, autenticao e renovao de tokens de acesso. Para os usurios deste cliente apresentada uma nica interface de acesso, contendo todos os mtodos disponveis no web service. Tanto os argumentos destes mtodos como as respostas dadas so instncias de classes denidas pelo cliente, que representam as entidades do servio, que so: usurios, conversas e interesses. A aplicao Android, portanto, apenas importa o cliente do web service. Por se tratar de um cliente que precisa fazer acessos a rede para se comunicar com o web service, tarefa custosa em aplicaes mveis, o aplicativo faz uso do cliente atravs de tarefas assncronas (executadas em segundo plano, em threads separadas). Isso signica que enquanto o aplicativo estiver se comunicando com o web service, a interface

264

Figura 3.7: Tela principal da aplicao, exibe as conversas mais populares entre os interesses seguidos pelo usurio.

de usurio no ser bloqueada, algo que denitivamente no ajuda na experincia do usurio. A tela principal da aplicao a tela de Feeds (Figura 3.7). Nela so exibidas as conversas mais populares, de acordo com o algoritmo explicado na seo 3.2.3, dentro dos interesses do usurio e, opcionalmente, ltradas de acordo com a localizao. Atravs dos ltros disponveis possvel escolher a forma como estas conversas podero ser ordenadas, que pode ser, alm da popularidade, a distncia com relao

265

Figura 3.8: Tela de uma conversa e suas respectivas respostas.

a localizao do usurio ou a data de criao da conversa. No aplicativo, todas as listas seguem o mesmo padro para a atualizao e paginao. A primeira feita atravs do boto mais a direita na action bar, clicando nele o aplicativo verica no web service se novas conversas surgiram aps a ltima atualizao da lista. J a paginao feita atravs de um boto que ca posicionado ao m lista, e quando o usurio clica no boto o aplicativo carrega um determinado nmero de conversas.

266

Figura 3.9: Perl de um usurio, exibindo as suas conversas mais recentes.

Existem, entretanto, outras maneiras de se abordar estas duas funcionalidades. A atualizao de listas, por instncia, pode ser feita atravs do mecanismo conhecido como pull-to-refresh, que patenteado pelo Twitter. As atualizaes tambm podem ser automticas, com o uso de um servidor push que envia as atualizaes para o smartphone quando elas ocorrerem. J a paginao pode ser feita atravs da lista innita, que carrega a prxima pgina toda a vez que o usurio atingir o nal da lista. As conversas exibidas no Feed so apenas as conversas iniciadas por usurios, ou seja, respostas de outros usurios no aparecero nesta listagem. Cada item da lista contm o nome e avatar do usurio que criou a conversa, o interesse onde esta conversa foi criada, o contedo da conversa, a quanto tempo ela foi criada, quantas respostas ela j obteve e a que distncia do usurio do aplicativo ela foi criada, esta ltima implicando que tanto o usurio do aplicativo como o criador da conversa

267

Figura 3.10: Tela de busca de interesses.

permitiram que sua localizao fosse utilizada. Ao pressionar um dos itens da lista, o usurio ir visualizar a conversa em conjunto com as respostas dadas a ela, como mostra a Figura 3.8. Acima da conversa inicial est a identicao do interesse ao qual a conversa pertence que, ao ser pressionado levar o cliente a tela do interesse. Tanto nesta tela como na de Feeds, ao pressionar o avatar de um usurio, o perl do mesmo ser exibido. Nesta tela tambm existe o boto para atualizar as conversas, mas ao con-

268

Figura 3.11: Tela do interesse sobre Fotograa.

trrio da tela de Feeds, aqui as novas conversas so posicionadas ao nal da lista, levando em conta que esta est em ordem cronolgica. Como fora dito anteriormente, ao clicar no avatar de um usurio, o seu perl ser exibido na tela. Agora, no existem informaes, alm de seu nome de usurio, a serem exibidas. Deste modo, grande parte da tela utilizada para a exibio das conversas criadas pelo usurio, bem como respostas a outras conversas e os interesses que este usurio segue. A separao entre a visualizao das conversas mais recentes de um usurio e os interesses que ele segue feita atravs de abas. Na Figura

269

3.9 possvel ver a esquerda a aba de conversas e a direita a aba de interesses do usurio. Para que um usurio possa ter seu feed de conversas ele precisa seguir interesses, e para tanto, preciso haver um meio de se pesquisar os interesses existentes, para ento comear a segu-los. A tela Explore serve exatamente para este propsito, permitindo que usurios busquem interesses ou mesmo criem novos interesses, caso no eles no existam. Na Figura 3.10 possvel visualizar esta tela. Seu funcionamento simples, basta ao usurio comear a digitar as letras do interesse desejado e a lista ser atualizada, exibindo interesses que contenham o mesmo prexo. Seja atravs da tela de Explore ou atravs de conversas, um usurio pode ir para a tela de um interesse, podendo desta forma visualizar quais so os usurios que seguem o interesse e quais as ltimas conversas criadas nele, como mostrado na Figura 3.11. Por m, a funcionalidade central da aplicao, que a criao de uma nova conversa, esta tela vista na Figura 3.12. Esta tela atua, na verdade, como um dilogo, cando sobre a tela atual que o usurio estava visualizando. Esta funcionalidade acionada atravs do boto central da footer bar do aplicativo, e ela pode utilizar informaes da tela atual para preencher as informaes para criao da nova conversa. Por exemplo, se o usurio estiver na tela do interesse Fotograa, quando ele pressionar o boto para criao de uma nova conversa, o aplicativo ir assumir que a nova conversa ser colocada no interesse Fotograa, muito embora o usurio possa alterar o interesse posterirmente. Da mesma forma, se o usurio estiver visualizando uma conversa, quando ele for criar uma nova conversa, presume-se que esta ser uma resposta a conversa visualizada. Atravs de tais padres de comportamento implcitos, possvel facilitar a vida do usurio. Entretanto, uma vez que o usurio tenha pressionado o boto para criar a conversa, necessrio trazer a tona este comportamento, mostrando que a conversa que ele est criando ser colocada em determinado interesse ou ser uma resposta a

270

Figura 3.12: Tela para criao de nova conversa. determinada conversa, tornado assim explcito o comportamente, e removendo qualquer dvida sobre o funcionamento do aplicativo.

3.7 UNINDO AS PARTES

Talvez uma das tarefas mais difceis e ao mesmo tempo mais empolgante no desenvolvimento de uma aplicao seja colocar ela para funcionar e ver todas as partes se conversando entre si. E no se trata apenas dos componentes de um software, mas de todo o servio, incluindo aqui os testes, a documentao da aplicao, os

271

scripts utilizados na implantao, e as ferramentas de monitoramento. Tudo precisa ser pensando de forma a facilitar a evoluo deste servio, garantindo, em primeiro lugar, a qualidade na experincia dos usurios. E isso se traduz em cada uma das etapas do desenvolvimento do servio. Seja na utilizao de testes unitrios e de integrao, para garantir que a aplicao est se comportando conforme o experado, seja na criao de processos para implantao da aplicao que garantam consistncia, segurana e rapidez. Ou no cuidado com o qual a interface grca da aplicao foi criada, que, acima de tudo, transmite aos usurios o nvel de comprometimento do servio com a qualidade. Nem sempre possvel fazer algo da forma certa na primeira vez, em muitos dos casos pois o que certo ou no no est claro o suciente. Mas se h algo que a Internet possibilitou foi a troca de experincias, que algo de valor inestimvel, mas muitas vezes ignorado. Durante cada uma das etapas de desenvolvimento deste sevio sempre buscouse encontrar relatos de outras pessoas e empresas, com o intuito de antecipar ou evitar problemas, e elencar estratgias para curto e longo prazo. Com este relatrio espera-se que outras pessoas possam tirar vantagem das experincias aqui documentadas.

CONCLUSO

Conceber um servio, desde suas caractersticas bsicas at a sua implatano uma tarefa que requer tempo e dedicao. Ela tambm envolve muitas questes que precisam ser levantadas e estudadas para que ento possa-se denir as opes disponveis, qual a mais adequada e que impacto isso ter no servio como um todo. Cada deciso tomada precisa levar em conta o objetivo principal do trabalho, que colocar o servio em funcionamento, atrair usurios, receber feedback dos mesmos, melhorar o servio e iterar. Ao reetir sobre o formato atual dos fruns e como eles poderiam ser melhorados, buscando ideais provenientes das redes sociais, este trabalho conseguiu criar um servio que mantm a essncia dos fruns, permitindo a criao de comunidades online, mas que ao mesmo tempo atende as expectativas que muitos usurios podem vir a ter quanto a um servio da Internet nos dias de hoje, comprovando desta forma a primeira das hipteses deste trabalho. Neste mesmo sentido, a escolha da estratgia de criar a aplicao mvel primeiro tambm foi acertada. Primeiro porque o mercado mvel est crescendo em ritmo constante, com cada vez mais pessoas tendo acesso a Internet atravs de smartphones. E segundo, porque a construo de uma aplicao mvel imps muitas restries com relao as funcionalidades dos servios, obrigando a remoo de caractersticas supruas e dando foco as funcionalidades realmente importantes.

273

E uma destas funcionalidades foi a geolocalizao. O uso dela neste servio no se tratou apenas de seguir uma tendncia, da qual ela de fato faz parte, mas sim de melhorar a experincia dos usurios. Atravs dela um indivduo pode se engajar em discusses sobre assuntos que lhe interessam, e faz-lo com pessoas que esto prximas dele, possibilitando a criao de comunidades que, alm de compartilharem interesses em comum, tambm faam parte de uma mesma localizao geogrca. Apesar disto, a hiptese de que a geolocalizao por si cria um diferencial com relao as outras redes sociais no pde ser comprovada. Isso porque este servio serve a um propsito diferente do das redes sociais, e nele a geolocalizao tem o papel de permitir que indivduos participem de discusses com pessoas que esto prximas dele. Alm disso, as principais redes sociais j fazem uso da geolocalizao de alguma forma. O uso da geolocalizao tambm proporcionou a experimentao de diversos bancos de dados, em uma busca pelo mais adequado para o servio em vista. Esta deciso, de carter tcnico, foi tomada atravs de testes que demonstraro qual a melhor opo disponvel, levando em conta ainda caractersticas inerentes a cada um dos bancos de dados. Outra deciso tcnica foi a autenticao da API RESTful. E infelizmente, a terceira das hipteses no pode ser comprovada, pois a implementao do protocolo OAuth requer tempo e um projeto maduro. Entretanto, a implementao utilizada neste servio atendeu as necessidades atuais sem, entretanto, exceder o cronograma do trabalho. Atravs do estudo aprofundado das reas que seriam utilizadas na criao deste servio, bem como a tomada de decises levando em conta no somente questes tcnicas, mas tambm as caractersticas e restries do trabalho, os recursos disponveis e, principalmente, a experincia do usurio como um todo, este trabalho foi capaz de criar um servio em sua completude.

TRABALHOS FUTUROS

Neste trabalho foram documentadas todas as etapas do desenvolvimento de uma aplicao mvel at o momento de sua implantao. Entretanto, a partir do momento em que o servio est no ar existem outras questes que ao longo do tempo precisaro ser respondidas. Uma delas diz respeito a possibilidade de o servio crescer e consequentemente da necessidade de comportar este crescimento. A escalabilidade, bem como algumas estratgias para se obt-la em vrios dos componentes que fazem parte de uma aplicao foram abordados neste trabalho sem, entretanto, um aprofundamento nos assuntos. Uma das propostas para trabalhos futuros seria o estudo de arquiteturas, tecnologias e estratgias para se escalar aplicaes web, abordando questes como distribuio da aplicao em vrios servidores, balanceadores de carga, redes de distribuio de contedo, sistemas de cache de dados, e replicao e sharding de bancos de dados. J partindo mais para o lado conceitual do servio, seria possvel desenvolver uma anlise sobre o estado atual do servio, se ele deu certo ou no e quais foram as razes, bem como um levantamento do que poderia melhorar no servio e quais seriam os prximos passos na evoluo do mesmo, buscando fomentar a criao de discusses e o crescimento das comunidades dentro do servio.

275

Com relao a criao de comunidades e discusses, seria interessante analisar o comportamento dos usurios dentro do servio, em que contextos as discusses ocorrem, e qual o perl da maioria dos usurios. E partindo para o lado mais tcnico, seria possvel avaliar a quantidade de spam gerado no servio, bem como a qualidade do mesmo, dando sugestes para a reduo do primeiro e aumento do segundo. E importante lembrar que os fruns j introduziram alguns mecanismos para evitar spams e elevar a qualidade nas discusses, se utilizando, por exemplo, de moderadores. Entretanto, o uso de moderadores nem sempre uma estratgia escalvel, tornando interessante o estudo de alternativas para a remoo de spams, bloqueio de usurios problemticos (trolls) e remoo de conversas inapropriadas. A verdade que um servio com a natureza como a deste possu muitos desaos pela frente que precisaro ser, uma hora ou outra, enfrentados, sejam eles de natureza tecnolgica ou comportamental.

REFERNCIAS

ABBOTT, M. L.; FISHER, M. T. Scalability Rules: 50 principles for scaling web sites. Addison-Wesley, 2011. AKSYONOFF, A. Introduction to Search With Sphinx: from installation to relevance tuning. OReilly Media, 2011. ALBIN, S. T. The Art of Software Architecture: design methods and techniques. [S.l.]: Wiley Pub., 2003. (Wiley Application Development Series). ALEXANDER, C.; ISHIKAWA, S.; SILVERSTEIN, M. A Pattern Language: towns, buildings, construction. New York: Oxford University Press, 1977. ALLAMARAJU, S. RESTful Web Services Cookbook: solutions for improving scalability and simplicity. Yahoo Press, 2010. ALLEN, S.; GRAUPERA, V.; LUNDRIGAN, L. Pro Smartphone Cross-Platform Development: iphone, blackberry, windows mobile and android development and distribution. 1st.ed. Berkely, CA, USA: Apress, 2010. AMAZON. About AWS. Disponvel em: Acesso em: jan. 2012. ANDROID. Android Developers. Disponvel em: <http://developer.android.com>. Acesso em: jan. 2012. ANDROID MARKET. Android Market Facebook para Android. Disponvel em: <http://market.android.com/details?id=com.facebook.katana>. Acesso em: 2012a. jan. <http://aws.amazon.com/what-is-aws/>.

277

ANDROID MARKET. Android Market Facebook Messenger. Disponvel em: <http://market.android.com/details?id=com.facebook.orca>. Acesso em: jan. 2012b. APACHE. About Apache. Disponvel em: <http://httpd.apache.org/ABOUT_APACHE. html>. Acesso em: jan. 2012a. APACHE. Documentation. Disponvel em: <http://httpd.apache.org/docs/>. Acesso em: jan. 2012b. APPLE. iOS Technology Overview. Apple, 2011. Disponvel em:

<http://developer.apple.com/library/ios/documentation/Miscellaneous/Conceptual/iP honeOSTechOverview/iPhoneOSTechOverview.pdf>. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS (ABNT). NBR ISO/IEC 9126-1 Engenharia de Software - Qualidade de Produto Parte 1: modelo de qualidade. p.21, Junho 2003. ATES, F. Taking Advantage of HTML5 and CSS3 with Modernizr. A List Apart, 22 de Junho de 2010. Disponvel em: <http://www.alistapart.com/articles/takingadvantage-of-html5-and-css3-with-modernizr/>. Acesso em: jan. 2012. ATWOOD, J. Passwords vs. Pass Phrases. Coding Horror, 17 de Juloh de 2005. Disponvel em: <http://www.codinghorror.com/blog/2005/07/passwords-vspass-phrases.html>. Acesso em: abr. 2012. ATWOOD, J. Discussions: at or threaded? Coding Horror, 24 de Novembro de 2006. Disponvel em: <http://www.codinghorror.com/blog/2006/11/discussions-ator-threaded.html>. Acesso em: abr. 2012. BANKS, E. Facebook Is Most Popular Social Network for All Ages; LinkedIn Is Second [STUDY]. Mashable, 4 de Novembro de 2011. Disponvel em: <http://mashable.com/2011/11/04/facebook-most-popular-forrester/>. Acesso em: jan. 2012. BARKUUS, L.; DEY, A. Location-Based Services for Mobile Telephony: a study of users privacy concerns. In: INTERACT 2003, 9TH IFIP TC13 INTERNATIO-

278

NAL CONFERENCE ON HUMAN-COMPUTER INTERACTION. Proceedings. . . [S.l.: s.n.], 2003. BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. 2a .ed. Addison-Wesley, 2003. BEAN, J. SOA and Web Services Interface Design: principles, techniques, and standards. Morgan Kaufmann, 2010. BELL, G. Building Social Web Applications. OReilly, 2009. BERNSTEIN, M. S. et al. 4chan and /b/: an analysis of anonymity and ephemerality in a large online community. In: ICWSM. Anais. . . [S.l.: s.n.], 2011. BFAR, R.; FIELDING, R. T. Mobile Computing Principles: designing and developing mobile applications with uml and xml. Cambridge University Press, 2004. BLEWITT, G. Basics of the GPS Technique: observation equations. In: JONSSON, B. (Ed.). Geodetic Applications of GPS. Gvle, Sweden: Swedish Land Survey, 1997. p.1054. Organizado por Nordic Geodetic Commission. Disponvel em: <http://www.lantmateriet.se/upload/ler/kartor/geodesi_gps_och_detaljmatning/Rap porter-Publikationer/LMV-rapporter/1997-16.pdf>. BOLSTAD, P. GIS Fundamentals. 3a .ed. Atlas Books, 2008. BOLT, N. Why Instagram Is So Popular: quality, audience, & constraints. TechCrunch, 27 de Novembro de 2011. Disponvel em: <http://techcrunch.com/2011/11/27/whyinstagram-is-so-popular/>. Acesso em: jan. 2012. BOYD, D. M.; ELLISON, N. B. Social Network Sites: denition, history, and scholarship. Journal of Computer-Mediated Communication, v.13, Outubro 2007. Disponvel em: <http://www.danah.org/papers/JCMCIntro.pdf>. BRHLER, S. Analysis of the Android Architecture. System Architecture Group, University of Karlsruhe, Germany, 2010. BULLETINBOARDS. Non-Threaded vs Semi-Threaded vs Threaded Display Formats. Disponvel em: <http://www.bulletinboards.com/ThreadHelp.cfm>. Acesso em: jan. 2012.

279

BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. C. Pattern-Oriented Software Architecture: on patterns and pattern languages. Wiley, 2007. (Wiley series in software design patterns). BUTCHART, B. Augmented Reality for Smartphones: a guide for developers and content publishers. JISC Observatory, 2012. TechWach Report, Disponvel em: <http://observatory.jisc.ac.uk/docs/AR_Smartphones.pdf>. Acesso em: jan. 2012. CANONICAL. Ubuntu Server Guide. Ubuntu 11.10. Disponvel Acesso em: em:

<https://help.ubuntu.com/11.10/serverguide/C/serverguide.pdf>. fev. 2012.

CARTER, R. G. Kerberos: What, Why, How?. Duke University. Disponvel em: <http://www.duke.edu/ rob/kerberos/>. Acesso em: jan. 2012. CHACON, S. Pro Git. Apress, 2009. CHAPMAN, C. The Depot, History 7 de and Evolution de of Social Disponvel Media. em:

WebDesigner

Outubro

2009.

<http://www.webdesignerdepot.com/2009/10/the-history-and-evolution-of-socialmedia/>. Acesso em: jan. 2012. CHILDNET INTERNATIONAL. Young People and Social Networking Services: a childnet international research report. [S.l.: s.n.], 2008. Disponvel em: <http://www.digizen.org/socialnetworking/downloads/Young_People_and_Social_Ne tworking_Services_full_report.pdf>. Acesso em: jan. 2012. CLYNCH, Wales, J. R. Earth of Coordinates. Engineering, The University Notes. of New South em:

Faculty

Technical

Disponvel

<http://www.gmat.unsw.edu.au/snap/gps/clynch_pdfs/coorddef.pdf>. em: jan. 2012. COATES, ware. 5 T. An de addendum Janeiro de to 2005, a denition plasticbag.org. of Social

Acesso

Softem:

Disponvel

<http://www.plasticbag.org/archives/2005/01/an_addendum_to_a_denition_of_soc ial_software/>. Acesso em: jan. 2012.

280

COMSCORE. bile

comScore Subscriber

Reports Market

April Share.

2012

U.S.

Moem:

Disponvel

<http://www.comscore.com/Press_Events/Press_Releases/2012/6/com Score_Reports_April_2012_U.S._Mobile_Subscriber_Market_Share>. Acesso em: abr. 2012. COPELAND, L. The Anti-Social Network. Disponvel em:

<http://www.slate.com/articles/double_x/doublex/2011/01/the_antisocial_network.html>. Acesso em: ago. 2012. CROCKFORD, D. The Worlds Most Misunderstood Programming Language Has Become the Worlds Most Popular Programming Language. 3 de Maro de 2008. Disponvel em: <http://javascript.crockford.com/popular.html>. Acesso em: mar. 2012. CROSS, P. A.; HOLLWEY, J. R.; SMALL, L. G. Geodetic Appreciation. University of East London, 2002. Working Paper No. 2, School of Computing and Technology Surveying Subject Area. CRUNCHBASE. CrunchBase: facebook. Disponvel em:

<http://www.crunchbase.com/company/facebook>. Acesso em: jan. 2012a. CRUNCHBASE. CrunchBase: linkedin. Disponvel em:

<http://www.crunchbase.com/company/linkedin>. Acesso em: jan. 2012b. CRUNCHBASE. CrunchBase: twitter. Disponvel em:

<http://www.crunchbase.com/company/twitter>. Acesso em: jan. 2012c. CRUNCHBASE. CrunchBase: instagram. Disponvel em:

<http://www.crunchbase.com/company/instagram>. Acesso em: jan. 2012d. CRUNCHBASE. CrunchBase: pinterest. Disponvel em:

<http://www.crunchbase.com/company/pinterest>. Acesso em: jan. 2012e. CRUNCHBASE. CrunchBase: path. Disponvel em:

<http://www.crunchbase.com/company/path>. Acesso em: jan. 2012f.

281

CRUNCHBASE.

CrunchBase:

shopkick.

Disponvel

em:

<http://www.crunchbase.com/company/shopkick>. Acesso em: jan. 2012g. DAIGNEAU, R. Service Design Patterns: fundamental design solutions for soap/wsdl and restful web services. Addison-Wesley, 2010. DATE, C. J. An Introduction to Database Systems. 8a .ed. Pearson, 2004. Defense Mapping Agency (DMA). Geodesy for the Layman. Defense Mapping Agency, 1983. DMA Technical Report. DELFINO, S. R.; NUNES, F. L.; SPOTO, E. S. Avaliao de desempenho de SGBDs gratuitos para construo de bases de imagens mdicas. V Workshop de Informtica Mdica, Porto Alegre, v.1, Junho 2005. DUBOIS, P. MySQL. 4a .ed. Addison-Wesley, 2009. EATON, K. Augmented Reality Kills The QR Code Star. Fast Company, 4 de Agosto de 2011. Disponvel em: <http://www.fastcompany.com/1771451/augmented-

reality-kills-the-qr-code-star>. Acesso em: jan. 2012. ELDON, E. Single sign-on service OpenID getting more usage. VentureBeat, 14 de Abril de 2009. Disponvel em: <http://venturebeat.com/2009/04/14/single-signon-service-openid-getting-more-usage/>. Acesso em: jan. 2012. ELMASRI, R.; NAVATHE, S. B. Fundamentals of Database Systems. 6a .ed. AddisonWesley, 2011. ERB, B. Concurrent Programming for Scalable Web Architectures. 2012. Diploma Thesis Institute of Distributed Systems, Ulm University. (VS-D01-2012). FACEBOOK. Messages basic Facebook Help Center. Disponvel em: <http://www.facebook.com/help/?topic=new_messages>. Acesso em: jan. 2012a. FACEBOOK. Facebook Statistics. Disponvel em:

<http://www.facebook.com/press/info.php?statistics>. Acesso em: jan. 2012b. FACEBOOK. Facebook Factsheet. Disponvel em:

<http://www.facebook.com/press/info.php?factsheet>. Acesso em: jan. 2012c.

282

FACEBOOK.

Facebook

Developers

Getting

Stacrted.

Disponvel

em:

<http://developers.facebook.com/docs/>. Acesso em: jan. 2012d. FACEBOOK. Facebook Help Center About Location Services. Disponvel em: <http://www.facebook.com/help/location/about>. Acesso em: jan. 2012e. FACEBOOK. Facebook Help Center Facebook Mobile Apps. Disponvel em: <http://www.facebook.com/help/mobile/apps>. Acesso em: jan. 2012f. FARKAS, M. G. Social Software in Libraries: building collaboration, communication, and community online. Information Today Inc., 2007. 344p. FIELDING, based R. T. Architectural Styles 2000. and the Design (Doutorado of Networkem Cin-

Software

Architectures.

Tese

cia da Computao) University of California,

Irvine. Disponvel em:

<http://www.ics.uci.edu/ elding/pubs/dissertation/top.htm>. FLANAGAN, D. JavaScript: the denitive guide. OReilly, 2011. FLANAGAN, D.; MATSUMOTO, Y. The Ruby Programming Language. OReilly Media, 2008. FLING, B. Mobile Design and Development: practical concepts and techniques for creating mobile sites and web apps - animal guide. 1st.ed. OReilly Media, Inc., 2009. FOLGER, P. Geospatial Information and Geographic Information Systems (GIS): an overview for congress. Congressional Research Service, 2011. CRS Report for Congress. Disponvel em: <http://www.fas.org/sgp/crs/misc/R41825.pdf>. FORCIER, J.; BISSEX, P.; CHUN, W. Python Web Development with Django. 1.ed. Addison-Wesley Professional, 2008. FORCIER, J.; BISSEX, P.; CHUN, W. Python Web Development With Django. Addison-Wesley Professional, 2009. FOURSQUARE. Foursquare About. Disponvel em:

<http://foursquare.com/about/>. Acesso em: jan. 2012.

283

FOWLER, M. Patterns of Enterprise Application Architecture. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002. FRANKS, J. et al. HTTP Authentication: basic and digest access authentication. IETF, 1999. n.2617. (Request for Comments). GAMMA, E. et al. Design patterns CD: elements of reusable object-oriented software. Addison-Wesley, 1998. (Addison-Wesley professional computing series). GARGENTA, M. Learning Android. OReilly Media, 2010. GARTNER. clined Year 2 Gartner Percent Says in Worldwide Quarter Sales of of 2012; Mobile Phones De-

First

Previous

Year-overem:

Decline Occurred

in Second

Quarter of 2009.

Disponvel

<http://www.gartner.com/it/page.jsp?id=2017015>. Acesso em: abr. 2012. GELGER, Solution R. The Benets 2 de of Integrated de 2008, Systems Completing Disponvel a em:

Stack.

Maio

Blackbaud.

<https://www.blackbaud.com/les/conference/2008Canada/Geiger_TheBenetsOfIn tegratedSystems.pdf>. Acesso em: fev. 2012. GEOMETRY of the Earth, The. The Geometry of the Earth. Disponvel em: <http://www.scribd.com/doc/78790027/The-Geometry-of-the-Earth>. Acesso em: fev. 2012. GHOSH, S. Facebooks value slides by $10 billion; outlook unclear, Reuters. Disponvel em: <http://www.reuters.com/article/2012/07/27/us-facebook-researchidUSBRE86Q0ID20120727>. Acesso em: ago. 2012. GOOGLE. Using OAuth 2.0 to Access Google APIs. Disponvel em:

<https://developers.google.com/accounts/docs/OAuth2>. Acesso em: mar. 2012. GOOGLE TRENDS. About Google Trends. Disponvel em:

<http://www.google.com/intl/en/trends/about.html>. Acesso em: jan. 2012a. GOOGLE TRENDS. Google Trends: geolocation. Disponvel em:

<http://www.google.com/trends?q=geolocation>. Acesso em: jan. 2012b. GORTON, I. Essential Software Architecture. 2a .ed. Springer, 2011.

284

GOURLEY, D.; TOTTY, B. HTTP: the denitive guide. OReilly, 2002. GROVE, nant. J. V. Adoption 6 of de geolocation Dezembro applications de 2011. is still stagem: jan.

VentureBeat,

Disponvel

<http://venturebeat.com/2011/12/06/geosocial-app-adoption/>. Acesso em: 2012. GSM ASSOCIATION. Location Based Services. GSM Association, Permanent Reference Document: SE.23. Verso 3.1.0. Disponvel

2003. em:

<http://www.gsmworld.com/documents/se23.pdf>. GTING, R. H. An introduction to spatial database systems. The VLDB Journal, Secaucus, NJ, USA, v.3, p.357399, October 1994. Disponvel em: <http://www.cise.u.edu/ mschneid/Research/thesis_papers/Gue94VLDBJ.pdf>. HALE, C. How To Safely Store A Password. 31 de Janeiro de 2010. Disponvel em: <http://codahale.com/how-to-safely-store-a-password/>. Acesso em: abr. 2012. HAMMER, E. Introducing OAuth 2.0. hueniverse, 15 de Maio de 2010. Disponvel em: <http://hueniverse.com/2010/05/introducing-oauth-2-0/>. Acesso em: fev. 2012. HEFFERNAN, V. The Old Internet Neighborhoods. Disponel em:

<http://opinionator.blogs.nytimes.com/2011/07/10/remembrance-of-messageboards-past/>. HENDERSON, C. Building Scalable Web Sites: building, scaling, and optimizing the next generation of web applications. OReilly Media, Inc., 2006. HEROKU. Dev Center. Disponvel em: <https://devcenter.heroku.com/>. Acesso em: mar. 2012. HERRON, D. Node Web Development. Packt Publishing, 2011. HOLDENER, A. T. I. HTML5 Geolocation. OReilly, 2011. HSU, D.; greSQL. OBE, B. Cross Compare of SQL Server, MySQL, and PostPostgres OnLine Magazine, May/June 2008. Disponvel em:

<http://www.postgresonline.com/journal/index.php?/archives/51-Cross-Compareof-SQL-Server,-MySQL,-and-PostgreSQL.html>. Acesso em: ago. 2012.

285

HURVITZ, O. LinkedIn Architecture. Cookies are for Closers: Oren Hurvitzs Blog, 5 de Junho de 2008. Disponvel em: architecture>. Acesso em: fev. 2012. IEEE. IEEE Standard Dictionay of Measures to Produce Reliable Software. New York, USA: IEEE Standards Board, 1996. IEEE. IEEE Standard Dictionay of Measures of the Software Aspects of Dependability. New York, USA: IEEE Standards Board, 2006. INGLOBE TECHNOLOGIES. Augmented Reality and the Future of Printing and Publishing. Inglobe Technologies, 2012. White Paper, Disponvel em: <http://www.inglobetechnologies.com/docs/whitepapers/AR_printing_whitepaper_e n.pdf>. Acesso em: jan. 2012. INSTAGRAM. What Powers Instagram: technologies. Instagram Engineering, hundreds of instances, dozens of 2 de Dezembro de 2011a. Dispon<http://hurvitz.org/blog/2008/06/linkedin-

vel em: <http://instagram-engineering.tumblr.com/post/13649370142/what-powersinstagram-hundreds-of-instances-dozens-of>. Acesso em: fev. 2012. INSTAGRAM. ring, 30 de Sharding Setembro & de IDs at Instagram. Disponvel Instagram Enginee-

2011b.

em:

<http://instagramAcesso

engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram>. em: fev. 2012. INSTAGRAM. Instagram Support Center. Disponvel

em:

<http://help.instagram.com/>. Acesso em: jan. 2012. ITUNES APP STORE. iTunes App Store Twitter. Disponvel em: jan.

<http://itunes.apple.com/us/app/twitter/id333903271?mt=8>. Acesso em: 2012a. ITUNES APP STORE. iTunes App Store Instagram. Disponvel Acesso

em: em:

<http://itunes.apple.com/us/app/instagram/id389801252?mt=8>. jan. 2012b.

286

ITUNES

APP

STORE.

iTunes

App

Store

Pinterest.

Disponvel

em: jan.

<http://itunes.apple.com/us/app/pinterest/id429047995?mt=8>. Acesso em: 2012c. ITUNES APP STORE. iTunes App Store Path. Disponvel em:

em: jan.

<http://itunes.apple.com/us/app/path/id403639508?mt=8>. 2012d. ITUNES APP STORE. iTunes App Store

Acesso

Yelp.

Disponvel

em:

<http://itunes.apple.com/br/app/yelp/id284910350?mt=8>. Acesso em: jan. 2012e. ITUNES APP STORE. iTunes App Store Loopt. Disponvel em: em: jan.

<http://itunes.apple.com/us/app/loopt/id281952554?mt=8>. 2012f.

Acesso

ITUNES APP STORE. iTunes App Store Google Latitude. Disponvel em: <http://itunes.apple.com/br/app/google-latitude/id306586497?mt=8>. Acesso em: jan. 2012g. ITUNES APP STORE. iTunes App Store Foursquare. Disponvel em: <http://itunes.apple.com/us/app/foursquare/id306934924?mt=8>. Acesso em: jan. 2012h. ITUNES APP STORE. iTunes App Store Glympse- Location Sharing Made Simple. Disponvel em: <http://itunes.apple.com/br/app/glympse-location-sharingmade/id330316698?mt=8>. Acesso em: jan. 2012i. KEW, N. The Apache Platform and Architecture. informIT, 13 de Abril de 2007. Disponvel em: <http://www.informit.com/articles/article.aspx?p=705689>. Acesso em: abr. 2012. KINCAID, J. Facebook Has Acquired Gowalla. TechCrunch, 2 de Dezembro de 2011. Disponvel em: <http://techcrunch.com/2011/12/02/report-facebook-has-acquiredgowalla/>. Acesso em: jan. 2012. KUMPARAK, Smart Lists. G. Facebook TechCrunch, 8 Begins de Auto-Grouping de 2011. Friends Disponvel Into em:

Setembro

287

<http://techcrunch.com/2011/09/08/facebook-begins-auto-grouping-colleaguesschool-mates-and-local-friends-into-smart-lists/>. Acesso em: jan. 2012. KWAK, H. et al. What is Twitter, a social network or a news media? In: WORLD WIDE WEB, 19., New York, NY, USA. Proceedings. . . ACM, 2010. p.591600. (WWW 10). Disponvel em: <http://cs.wellesley.edu/ cs315/Papers/What%20is%20twittera%20social%20net%20or%20news%20media.pdf>. LAYAR. Layar Layar Browser. Disponvel em: <http://www.layar.com/browser/>. Acesso em: jan. 2012. LEBLANC, J. Programming Social Applications: building viral experiences with opensocial, oauth, openid, and distributed web frameworks. OReilly, 2011. LIEBERHERR, lege of K. Law of and Demeter. Information Northeastern Science. University, Disponvel Colem:

Computer

<http://www.ccs.neu.edu/home/lieber/LoD.html>. Acesso em: jan. 2012. LINKEDIN. LinkedIn - A Professional Network built with Java Technologies and Agile Practices. Disponvel em: <http://www.slideshare.net/linkedin/linkedinscommunication-architecture>. Acesso em: fev. 2012. LINKEDIN. LinkedIn Learning Center What is LinkedIn. Disponvel em: <http://learn.linkedin.com/what-is-linkedin/>. Acesso em: jan. 2012a. LINKEDIN. LinkedIn Learning Center Mobile. Disponvel em:

<http://learn.linkedin.com/mobile/>. Acesso em: jan. 2012b. LINKEDIN. LinkedIn Learning Center Homepage Overview. Disponvel em: <http://learn.linkedin.com/the-homepage/overview/>. Acesso em: jan. 2012c. LINKIBOL. How to Build a Popularity Algorithm You can be Proud of. linkiblog, 7 de Maio de 2010. Disponvel em: <http://blog.linkibol.com/2010/05/07/how-to-builda-popularity-algorithm-you-can-be-proud-of/>. Acesso em: abr. 2012. LIPSMAN, cebook tion. A. State of the U.S. Social Networking but de upstarts 2011. Market: gaining Disponvel fatracem:

maintains comScore,

leadership 23 de

position, Dezembro

288

<http://blog.comscore.com/2011/12/state_of_the_us_social_networking.html>. Acesso em: jan. 2012. LIU, H. H. Software Performance and Scalability: a quantitative approach. John Wiley & Sons, 2009. (Quantitative software engineering series). LOELIGER, J. Version Control With Git. OReilly, 2009. LUO, Q. et al. Middle-tier database caching for e-business. In: SIGMOD CONFERENCE. Anais. . . [S.l.: s.n.], 2002. p.600611. LUTZ, M. Learning Python: powerful object-oriented programming. 4a .ed. OReilly Media, 2010. MACCAW, A. JavaScript Web Applications. OReilly, 2011. MACMANUS, R. 5 Check-in Apps to Check Out. ReadWriteWeb, 11 de Outubro de 2010. Disponvel em: <http://www.readwriteweb.com/archives/5_checkin_apps_to_check_out.php>. Acesso em: jan. 2012. MACMILLAN, D.; Valuation. WOMACK, B. Facebook Said to Plan IPO at $100B 29 de Novembro de 2011. Disponvel em:

Bloomberg,

<http://www.bloomberg.com/news/2011-11-29/facebook-said-to-plan-10-billionipo-with-100-billion-of-social-network.html>. Acesso em: jan. 2012. MANOLAKIS, D. E. Efcient Solution and Performance Analysis of 3-D Position Estimation by Trilateration. IEEE Transactions on Aerospace and Electronic Systems, v.32, n.4, Outubro 1996. MARTIN, R. C. The Liskov Substitution Principle. C++ Report, Maro 1996. Disponvel em: <http://www.objectmentor.com/resources/articles/lsp.pdf>. MARTIN, R. C. The Interface Segregation Principle. C++ Report, Agosto 1996. Disponvel em: <http://www.objectmentor.com/resources/articles/isp.pdf>. MASSE, M. REST API Design Rulebook. OReilly Media, 2011. MATTHEW, N.; STONES, R. Beginning Databases With Postgresql: from novice to professional. Apress, 2005. (Experts voice in Open Source).

289

MAYFIELD,

A.

What

is

Social

Media?

iCrossing.

Disponvel

em:

<http://www.icrossing.co.uk/leadmin/uploads/eBooks/What_is_Social_Media_iCros sing_ebook.pdf>. Acesso em: jan. 2012. MCDONALD, cebook P. Blog, Timeline: 15 de now Dezembro available de worldwide. 2011. The Faem: em:

Disponvel Acesso

<http://blog.facebook.com/blog.php?post=10150408488962131>. jan. 2012.

MCKENZIE, G. Gamication and Location-based Services. Vision Statement for the Cognitive Engineering for Mobile GIS Workshop at COSIT 2011, 2011. Disponvel em: <http://geog.ucsb.edu/ jano/CEMob2011/paper4.pdf>. MEDNIEKS, Z. et al. Programming Android. OReilly Media, 2010. MEMCACHED. About Memcached. Disponvel em: <http://memcached.org/about>. Acesso em: mar. 2012. MICHAELIS, C. Application of Open Geospatial Consortium Specications to Client-Side Geographic Information Systems. 2007. Dissertao (Mestrado em Cincia da Computao) Idaho State University. Department of Geosciences. Disponvel em: <http://www.wanderingidea.com/linkedcontent/ChristopherMichaelis-

MastersThesis.pdf>. MISCHE, de V. Janeiro The de Future 2012. of GeoCouch em: and CouchDB, 6

Disponvel

<http://vmx.cx/cgi-

bin/blog/index.cgi/the-future-of-geocouch-and-couchdb%3A2012-0106%3Aen%2CCouchDB%2CGeoCouch%2CErlang%2Cgeo>. Acesso em: 2012. MONGODB. Geospatial Indexing. Disponvel em: jan.

<http://www.mongodb.org/display/DO CS/Geospatial+Indexing/>. Acesso em: ago. 2012a. MORGAN STANLEY. Internet Trends. 2010, Abril. Disponvel em:

<http://www.morganstanley.com/institutional/techresearch/pdfs/Internet_Trends_041 210.pdf>.

290

MORRISON & FOERSTER. A Short History of Social Media. Socially Aware. Disponvel em: <http://www.mofo.com/les/Uploads/Images/A-Short-History-of-SocialMedia.pdf>. Acesso em: jan. 2012. MOVABLE TYPE. Calculate points, distance, Movable bearing Type and more between em:

Latitude/Longitude

Scripts.

Disponvel

<http://www.movable-type.co.uk/scripts/latlong.html>. Acesso em: mar. 2012. MYSQL. MySQL and memcached Guide. Disponvel Acesso em: em:

<http://downloads.mysql.com/docs/mysql-memcached-en.pdf>. mar. 2012. NATIONAL The INSTITUTE OF STANDARDS of Cloud AND

TECHNOLOGY Disponvel

(NIST). em:

NIST

Denition

Computing.

<http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf>. Acesso em: fev. 2012. NEDELCU, C. Nginx HTTP Server. Packt Publishing, 2009. NETCRAFT. February 2012 Web Server Survey. Disponvel em:

<http://news.netcraft.com/archives/2012/02/07/february-2012-web-serversurvey.html>. Acesso em: jan. 2012. NIELSEN. Global Advertising: consumers trust real friends and virtual strangers the most. Disponvel em: <http://blog.nielsen.com/nielsenwire/consumer/global-

advertising-consumers-trust-real-friends-and-virtual-strangers-the-most/>. Acesso em: jan. 2012. NIELSEN. Smartphones Account for Half of all Mobile Phones, Domi-

nate New Phone Purchases in the US. 29 de Maro de 2012. Disponvel em: <http://blog.nielsen.com/nielsenwire/online_mobile/smartphones-account-for-

half-of-all-mobile-phones-dominate-new-phone-purchases-in-the-us/>. Acesso em: abr. 2012. NIMA. Department of Defense World Geodetic System 1984. National Imagery and Mapping Agency, 2000. Technical Report.

291

NORTH, D. The rise and rise of JavaScript. DanNorth.net, 19 de Dezembro de 2011. Disponvel em: <http://dannorth.net/2011/12/19/the-rise-and-rise-of-javascript/>.

Acesso em: mar. 2012. OLIVEIRA, S. L. Tratado de Metodologia Cientca: projetos de pesquisas, tgi, tcc, monograas, dissertaes e teses. 2a .ed. So Paulo: Pioneira, 2002. OOI, B. C.; SACKS-DAVIS, to ACM R.; HAN, J. Indexing in in Spatial Disponvel Dataem:

bases.

Submitted

Comp.

Survey

1994.

<http://www.comp.nus.edu.sg/ ooibc/spatialsurvey.pdf>. OPEN GEOSPATIAL CONSORTIUM (OGC). OGC History (abbreviated) | OGC. Disponvel em: <http://www.opengeospatial.org/ogc/history>. Acesso em: jan. 2012. OSGEO. Open GeoSpatial Consortium Standards OSGeo-Live 5.0 Documentation. Disponvel em: <http://live.osgeo.org/en/standards/standards.html>. Acesso em: jan. 2012a. OSGEO. Open GeoSpatial Consortium Standards Web Map Service (WMS). Disponvel em: <http://live.osgeo.org/en/standards/wms_overview.html>. Acesso em: jan. 2012b. OSMANI, A. Essential JavaScript Design Patterns For Beginners, Volume 1. [S.l.: s.n.], 2011. OSULLIVAN, B. Mercurial: the denitive guide. OReilly Media, 2009. PANZARINO, Twitter.com. M. The Twitter Next now Web, rolling 9 de out Agosto direct de image upload at em:

2011.

Disponvel

<http://thenextweb.com/twitter/2011/08/09/twitter-now-rolling-out-direct-imageupload-at-twitter-com/>. Acesso em: jan. 2012. PARR, In B. Every Twitter Day. Has 100 Mashable, Million Monthly Active 18 de Outubro de Users; 50% Log em:

2011.

Disponvel

<http://mashable.com/2011/10/17/twitter-costolo-stats/>. Acesso em: jan. 2012. PATH. Path About. Disponvel em: <https://path.com/about>. Acesso em: jan. 2012.

292

PERCIVALL, Geospatial

G.

OGC

Reference 2011.

Model

(OGC

08-062r7).

The

Open em:

Consortium,

Informative/Educational,

Disponvel

<http://www.opengeospatial.org/standards/orm>. PILGRIM, M. HTML5: Up and Running. OReilly, 2010. PINTEREST. Pinterest Help. Disponvel em: <http://pinterest.com/about/help/>. Acesso em: jan. 2012a. PINTEREST. Pinterest Goodies. Disponvel em:

<http://pinterest.com/about/goodies/>. Acesso em: jan. 2012b. PIRES, C. E. S.; NASCIMENTO, R. O.; SALGADO, A. C. Comparativo de Desempenho entre Bancos de Dados de Cdigo Aberto. II Escola Regional de Banco de Dados, Passo Fundo, RS, p.2126, 2006. POPESCU, A. Geolocation API Specication. W3C, 2009. Last Call WD, Disponvel em: <http://www.w3.org/TR/2009/WD-geolocation-API-20090707/>. PORTER, J. Designing for the Social Web. Berkeley, CA: New Riders, 2008. POSTGIS. PostGIS Home. Disponvel em: <http://postgis.refractions.net/>. Acesso em: jan. 2012a. POSTGIS. PostGIS 2.0.0 Manual. Disponvel em:

<http://postgis.refractions.net/docs/ind ex.html>. Acesso em: jan. 2012b. PUGH, D. S. . E. Apache Solr 3 Enterprise Search Server. Packt Publishing, 2011. PYTHON. General Python FAQ. Disponvel em:

<http://docs.python.org/faq/general.html>. Acesso em: mar. 2012. RAINS, S. A. The Impact of Anonymity on Perceptions of Source Credibility and Inuence in Computer-Mediated Group Communication: a test of two competing hypotheses. Communication Research, v.34, n.1, p.100125, 2007. RAIT, book Z. Blog, Introducing 14 de the Subscribe de Button. 2011. The Disponvel Faceem:

Setembro

293

<http://blog.facebook.com/blog.php?post=10150280039742131>. jan. 2012.

Acesso

em:

RAO, L. Visa Teams Up With Shopkick To Dole Out Retailer Reward Points At The Point Of Sale. TechCrunch, 21 de Novembro de 2011. Disponvel em: <http://techcrunch.com/2011/11/21/visa-teams-up-with-shopkick-to-dole-

out-retailer-reward-points-at-the-point-of-sale/>. Acesso em: jan. 2012. REDIS. Introduction to Redis. Disponvel em: <http://redis.io/topics/introduction>. Acesso em: mar. 2012. RICHARDSON, L.; RUBY, S.; HANSSON, D. H. Restful Web Services. OReilly Media, 2007. RICHMOND, ging. H. The Tag, Growth 21 de of Mobile de Marketing 2011. and Tagem:

Microsoft

Maro

Disponvel

<http://tag.microsoft.com/community/blog/t/the_growth_of_mobile_marketing_and_t agging.aspx>. Acesso em: mar. 2012. RODGER, R. Beginning Mobile Application Development in the Cloud. Wrox, 2011. ROWINSKI, ner. D. Twitter.com 8 de Gets Junho Its de Own 2011. URL Shorteem:

ReadWriteWeb,

Disponvel

<http://www.readwriteweb.com/archives/twittercom_gets_its_own_url_shortener.php>. Acesso em: jan. 2012. ROZANSKI, N.; WOODS, E. Software Systems Architecture: working with stakeholders using viewpoints and perspectives. Addison-Wesley Professional, 2005. RUBY GEOCODER. Ruby Geocoder Home Page. Disponvel em:

<http://www.rubygeocoder.com/>. Acesso em: jan. 2012. RUBY, S. et al. Agile Web Development With Rails. Pragmatic Bookshelf, 2009. RUSHE, ment. D. The Twitter Guardian, valued 2 de at $8bn de after 2011. large investem:

Agosto

Disponvel

294

<http://www.guardian.co.uk/technology/2011/aug/02/twitter-valued-8bn-largeinvestment>. Acesso em: jan. 2012. SANFILIPPO, S. Redis as an LRU cache. Disponvel em:

<http://redis.io/topics/introduction>. Acesso em: mar. 2012. SAWERS, P. Kevin Systrom on Instagrams meteoric rise. . . and when IS it coming to Android? [Interview]. The Next Web, 18 de Setembro de 2011. Disponvel em: <http://thenextweb.com/video/2011/09/18/kevin-systrom-on-instagramsmeteoric-rise-and-when-is-it-coming-to-android-interview/>. Acesso em: jan. 2012. SCHLOSSNAGLE, T. Scalable Internet Architecture. Sams, 2006. SCHONFELD, months. E. Hitwise: 22 pinterest de grows de nearly 2011. 40-fold past six em:

TechCrunch,

Dezembro

Disponvel

<http://techcrunch.com/2011/12/22/pinterest-40-fold/>. Acesso em: jan. 2012. SCHWARTZ, B. et al. High Performance MySQL: optimization, backups, replication, and more. 2a .ed. OReilly, 2008. SHARESPOST. SharesPost Facebook. Disponvel em: jan.

<http://www.sharespost.com/companies/facebook/overview>. Acesso em: 2012.

SHAW, Z. A. Programmers Need To Learn Statistics Or I Will Kill Them All. Disponvel em: <http://zedshaw.com/essays/programmer_stats.html>. Acesso em: fev. 2012. SHEK, S. Next-Generation Location-Based Services for Mobile Devices. Computer Sciences Corporation, 2010. Leading Edge Forum, CSC Grants. Disponvel em: <http://assets1.csc.com/lef/downloads/CSC_Grant_2010_Next_Generation_Location _Based_Services_for_Mobile_Devices.pdf>. SIEGLER, M. A Perfect Circle: "friends". TechCrunch, 24 de Agosto de 2011a. Disponvel em: <http://techcrunch.com/2011/08/24/circles-or-circular-reasoning/>. Acesso em: jan. 2012.

295

SIEGLER, M. At 5 Million Users, Its Hard Not To View Instagram Through A Rose-Colored Filter. TechCrunch, 13 de Junho de 2011b. Disponvel em: <http://techcrunch.com/2011/06/13/instagram-ve-million-users/>. Acesso em: jan. 2012. SMITH, G. PostgreSQL 9.0 High Performance. Packt Publ., 2010. (Community experience distilled). SOLR. Spatial Search. Disponvel em: <http://wiki.apache.org/solr/SpatialSearch/>. Acesso em: ago. 2012. SOUSA, F. R. C.; MOREIRA, L. O.; MACHADO, J. C. Computao em Nuvem: conceitos, tecnologias, aplicaes e desaos. III Escola Regional de Computao Cear Maranho Piau, Parnaba, Piau. SPENCER, W. The History of Cell Phones. The Tech FAQ. Disponvel em: <http://www.tech-faq.com/history-of-cell-phones.html>. Acesso em: mar. 2012. STEINIGER, S.; HUNTER, A. J. S. Free and Open Source GIS Software for Building a Spatial Data Infrastructure. In: BOCHER, E.; NETELER, M. (Ed.). Geospatial Free and Open Source Software in the 21st Century: pro-

ceedings of the rst open source geospatial research symposium. Heidelberg: Springer, 2009. Disponvel em: <http://sourceforge.net/projects/jump-

pilot/les/w_other_freegis_documents/articles/sstein_hunter_fosgis4sdi_v10_nal.p df/download>. STEINIGER, tions of S.; NEUN, Location M.; Based EDWARDES, Services. A. Disponvel Foundaem:

<http://www.spatial.cs.umn.edu/Courses/Fall11/8715/papers/IM7_steiniger.pdf>. Acesso em: jan. 2012., CartouCHe Lecture Notes on LBS, V. 1.0. STRATMANN, J. Instagram 5 million users, 5 reasons behind its

growing success. FreshNetworks, 14 de Junho de 2011. Disponvel em: <http://www.freshnetworks.com/blog/2011/06/instagram-5-million-users-5-reasonsbehind-its-growing-success/>. Acesso em: jan. 2012.

296

STRAUCH, C. NoSQL Databases. Selected Topics on Software-Technology UltraLarge Scale Sites, Computer Science and Media, Stuttgart Media University., Lecture. STREICHER, M. Micro-Frameworks: big things in small packages. Linux Magazine, 5 de Maio de 2009. Disponvel em: <http://www.linux-mag.com/id/7324/>. Acesso em: mar. 2012. SWIFT, J. N.; GOLDBERG, D. W.; WILSON, J. P. Geocoding Best Practices: review of eight commonly used geocoding systems. Los Angeles, CA: University of Southern California GIS Research Laboratory, 2008. Technical Report No 10, Disponvel em: <http://spatial.usc.edu/Users/dan/gislabtr10_Eight-CommonlyUsed-Geocoding-Systems.pdf>. TANENBAUM, A. S. Redes de Computadores. 4a .ed. Campus, 2003. TIWARI, S. Professional NoSQL. Wrox, 2011. TORGE, W. Geodesy. 2a .ed. Berlin: Walter de Gruyter, 1991. TORNADO. Home Page. Disponvel em: <http://www.tornadoweb.org/>. Acesso em: mar. 2012. TREVISANI, E.; VITALETTI, A. Cell-ID location technique, limits and benets: an experimental study. In: SIXTH IEEE WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS (WMCSA 2004). Proceedings. . . IEEE, 2004. TSOTSIS, A. Instagram Now Has 12 Million Users, 100K Weekly Downloads In China Alone. TechCrunch, 31 de Outubro de 2011a. Disponvel em: <http://techcrunch.com/2011/10/31/instagram-now-has-12-million-users-100kweekly-downloads-in-china-alone/>. Acesso em: jan. 2012. TSOTSIS, A. Paths Second Iteration Is Less Photosharing And More Everything Sharing. TechCrunch, 29 de Novembro de 2011b. Disponvel em: <http://techcrunch.com/2011/11/29/paths-second-iteration-is-less-photosharingand-more-everything-sharing/>. Acesso em: jan. 2012.

297

TWITTER. #numbers. Twitter Blog, 14 de Maro de 2011a. Disponvel em: <http://blog.twitter.com/2011/03/numbers.html>. Acesso em: jan. 2012. TWITTER. Moving from Basic Auth to OAuth. Twitter Developers, 13 de Julho de 2011b. Disponvel em: <https://dev.twitter.com/docs/auth/moving-from-basic-authto-oauth>. Acesso em: mar. 2012. TWITTER. Twitter About. Disponvel em: <http://twitter.com/about>. Acesso em: jan. 2012a. TWITTER. Twitter Help Center Twitter basics. Disponvel em:

<http://support.twitter.com/groups/31-twitter-basics>. Acesso em: jan. 2012b. TWITTER. Twitter Help Center Apps, SMS, and Mobile. Disponvel em: <http://support.twitter.com/groups/34-apps-sms-and-mobile>. Acesso em: 2012c. US Army Corps of Engineers (USACE). NAVSTAR Global Positioning System Surveying. US Army Corps of Engineers, 2003. VBULLETIN. vBulletin Community Forum FAQ. Disponvel em: jan.

<https://www.vbulletin.com/forum/faq.php>. Acesso em: jan. 2012. VELICANU, matica A.; OLARU, v.14, S. Optimizing n.2, Spatial 2010. Databases. Disponvel Inforem:

Economica,

p.6171,

<http://revistaie.ase.ro/content/54/07%20Velicanu,%20Olaru.pdf>. VITICCI, F. Instagram Hits 10 Million Users in 355 Days A Brief Retrospective. MacStories, 26 de Setembro de 2011. Disponvel em:

<http://www.macstories.net/stories/instagram-hits-10-million-users-in-355-daysa-brief-retrospective/>. Acesso em: jan. 2012. VOGEL, O. et al. Software Architecture: a comprehensive framework and guide for practitioners. Springer, 2011. WANG, J. LinkedIn Signal a look under the hood. SNA Projects Blog, 1 de Outubro de 2010. Disponvel em: <http://sna-projects.com/blog/2010/10/linkedin-signala-look-under-the-hood/>. Acesso em: fev. 2012.

298

WANG,

J.; 27

MATSUDA, de

Y. Janeiro

LinkedIn de 2010.

Search.

LinkedIn, em: em:

SD-Forum,

Disponvel Acesso

<https://docs.google.com/present/view?id=d7qvbkn_28cgpvm96r>. fev. 2012. WAUTERS, R. DLD 2012 @Jack Dorsey: del that works". TechCrunch,

"twitter has a business mo-

22 de Janeiro de 2012. Disponvel em:

<http://techcrunch.com/2012/01/22/dld-2012-jack-dorsey-twitter-has-a-businessmodel-that-works/>. Acesso em: jan. 2012. WEBBER, J.; PARASTATIDIS, S.; ROBINSON, I. REST in Practice: hypermedia and systems architecture. OReilly Media, 2010. WEBSITEOPTIMIZATION. formance. 30 de The Maio Psychology de 2008. of Web Disponvel Perem:

<http://www.websiteoptimization.com/speed/tweak/psychology-webperformance/>. Acesso em: mar. 2012. WEISSTEIN, E. W. Great Circle. From MathWorld A Wolfram Web Resouce. Disponvel em: <http://mathworld.wolfram.com/GreatCircle.html>. Acesso em: mar. 2012. WHEELER, D. zxcvbn: realistic password strength estimation. Dropbox tech blog, 10 de Abril de 2012. Disponvel em: <http://tech.dropbox.com/?p=165>. Acesso em: jan. 2012. WU, M. Community vs. Social Network. Disponvel em:

<http://lithosphere.lithium.com/t5/Lithium-s-View/Community-vs-Social-Network/bap/5283>. Acesso em: jun. 2012. XKCD. Password Strength. 10 de Outubro de 2011. Disponvel em:

<http://xkcd.com/936/>. Acesso em: jan. 2012. YELP. Yelp FAQ. Disponvel em: <http://www.yelp.com/faq>. Acesso em: jan. 2012. ZAKAS, N. C. High Performance JavaScript. Yahoo Press, 2010.

299

ZICKUHR, K.; SMITH, A. 28% of American adults use mobile and social locationbased services. Pew Internet & American Life Project, 2011. Disponvel em: <http://pewinternet.org/Reports/2011/Location.aspx>.