SEAN CARLISTO DE ALVARENGA PUSH TECHNOLOGIES

SEAN CARLISTO DE ALVARENGA PUSH TECHNOLOGIES LONDRINA PR 2013

SEAN CARLISTO DE ALVARENGA PUSH TECHNOLOGIES Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Computação da Universidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof(a). Dr(a). Bruno Bogaz Zarpelão Coorientador: Prof(a). Dr(a). Nome do(a) Coorientador(a) LONDRINA PR 2013

Sean Carlisto de Alvarenga Push Technologies/ Sean Carlisto de Alvarenga. Londrina PR, 2013-37 p. : il. (algumas color.) ; 30 cm. Orientador: Prof(a). Dr(a). Bruno Bogaz Zarpelão Universidade Estadual de Londrina, 2013. 1. Palavra-chave1. 2. Palavra-chave2. I. Orientador. II. Universidade xxx. III. Faculdade de xxx. IV. Título CDU 02:141:005.7

SEAN CARLISTO DE ALVARENGA PUSH TECHNOLOGIES Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Computação da Universidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Computação. BANCA EXAMINADORA Prof(a). Dr(a). Bruno Bogaz Zarpelão Universidade Estadual de Londrina Orientador Prof. Dr. Segundo Membro da Banca Universidade/Instituição do Segundo Membro da Banca Prof. Msc. Terceiro Membro da Banca Universidade/Instituição do Terceiro Membro da Banca Londrina PR, 24 de novembrode 2013 LONDRINA PR 2013

Este trabalho é dedicado às crianças adultas que, quando pequenas, sonharam em se tornar cientistas.

AGRADECIMENTOS Os agradecimentos principais são direcionados à Gerald Weber, Miguel Frasson, Leslie H. Watter, Bruno Parente Lima, Flávio de Vasconcellos Corrêa, Otavio Real Salvador, Renato Machnievscz 1 e todos aqueles que contribuíram para que a produção de trabalhos acadêmicos conforme as normas ABNT com L A TEX fosse possível. Agradecimentos especiais são direcionados ao Centro de Pesquisa em Arquitetura da Informação 2 da Universidade de Brasília (CPAI), ao grupo de usuários latex-br 3 e aos novos voluntários do grupo abntex2 4 que contribuíram e que ainda contribuirão para a evolução do abntex2. 1 Os nomes dos integrantes do primeiro projeto abntex foram extraídos de http://codigolivre. org.br/projects/abntex/ 2 http://www.cpai.unb.br/ 3 http://groups.google.com/group/latex-br 4 http://groups.google.com/group/abntex2 e http://abntex2.googlecode.com/

Não vos amoldeis às estruturas deste mundo, mas transformai-vos pela renovação da mente, a fim de distinguir qual é a vontade de Deus: o que é bom, o que Lhe é agradável, o que é perfeito. (Bíblia Sagrada, Romanos 12, 2)

ALVARENGA, S. C.. Push Technologies. 37 p. Trabalho de Conclusão de Curso (Graduação). Bacharelado em Ciência da Computação Universidade Estadual de Londrina, 2013. RESUMO Palavras-chave: latex. abntex. editoração de texto.

ALVARENGA, S. C.. Push Technologies. 37 p. Final Project (Undergraduation). Bachelor of Science in Computer Science State University of Londrina, 2013. ABSTRACT This is the english abstract. The Abstract in English should be faithful to the Resumo in Portuguese, but not a literal translation. Keywords: latex. abntex. text editoration.

LISTA DE ILUSTRAÇÕES Figura 1 Exemplo do modelo cliente-servidor tradicional [1]............ 25 Figura 2 Um sistema de interação publish/subscribe................ 27 Figura 3 Topic-Based Publish-Subscribe [2]..................... 29

LISTA DE TABELAS

LISTA DE ABREVIATURAS E SIGLAS GOF SRP OCP LSP ISP DIP MDD UML Gang of Four Single Responsibilty Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle Desenvolvimento Dirigido por Modelos Unified Modeling Language

LISTA DE SÍMBOLOS Γ Λ ζ Letra grega Gama Lambda Letra grega minúscula zeta Pertence

SUMÁRIO 1 TECNOLOGIA PUSH............................ 25 1.1 PUBLISH/SUBSCRIBE........................... 27 1.1.1 VARIAÇÕES DO MODELO..................... 28 1.1.1.1 Publish/Subscribe Baseado em tópico........... 28 1.1.1.2 Publish/Subscribe Baseado em conteúdo......... 29 1.2 COMET.................................... 31 1.2.1 AJAX................................. 31 1.3 WebSocket................................... 33 Conclusão..................................... 35 Referências..................................... 37

25 1 TECNOLOGIA PUSH O conteúdo da Web está hospedado em servidores Web, que fornecem seu conteúdo para clientes Web. Os clientes Web, por sua vez, solicitam dados para os servidores através de requisições e os servidores respondem aos clientes com os respectivos dados solicitados. Clientes e servidores possuem um acordo na forma em que se comunicam, um protocolo, comum para ambos. O Hypertext Transfer Protocol (HTTP) é o protocolo usado para se comunicar através da World Wide Web [1]. HTTP é um protocolo de request-response para o modelo tradicional clienteservidor [3]. Neste modelo, o cliente Web (geralmente um web browser) envia uma requisição para o servidor, que faz algum processamento e retorna uma resposta. HTTP é um protocolo half-duplex, ou seja, tanto o cliente quanto o servidor podem enviar e receber dados, mas não simultaneamente. Figura 1 Exemplo do modelo cliente-servidor tradicional [1] No modelo cliente-servidor tradicional, toda comunicação precisa ser iniciada pelo cliente, impedindo que o servidor envie notificações sem uma requisição. Isso se torna uma desvantagem do modelo, pois há diversas situações nas quais se deseja atualizar os dados do cliente no momento em que ocorrerem essas atualizações no servidor. Preço de ações, notícias, informações sobre o clima [3], site de leilões e bate-papos [4], são alguns exemplos de informações que podem envelhecer se não são enviadas imediatamente aos clientes. Se o cliente deseja esses dados em tempo-real, deve atualizar constantemente a página manualmente, uma solução ruim que pode gerar diversas requisições desnecessárias que irão aumentar a latência, o consumo da banda da rede e o consumo da CPU do servidor. Aplicações baseadas no modelo tradicional cliente-servidor que exigem notificações de eventos e transferência de dados em tempo real, na maioria das vezes, são implementadas utilizando uma técnica de polling. Com polling, o cliente envia requisições HTTP para o servidor em intervalos regulares, verificando se houve atualizações. Se houver atualizações disponíveis, o servidor envia uma resposta com os dados para o cliente. Caso não haja alterações, o servidor envia uma resposta negativa e o cliente encerra a conexão [3]. O problema do uso da técnica de polling para notificações de eventos em tempo-

26 Capítulo 1. TECNOLOGIA PUSH real, é saber determinar qual intervalo de envio das requisições. A fim de se obter as atualizações mais recentes, esse intervalo precisa ser pequeno e portanto a frequência de verificações por atualizações será alta. Isso vai gerar um número muito grande de requisições (e possivelmente requisições desnecessárias) que podem causar overhead no servidor. Porém, por outro lado, se esse intervalo for muito grande, a frequência de verificações será baixa e o cliente pode perder diversas atualizações. Polling é uma boa solução quando se sabe exatamente qual o intervalo em que as atualizações ocorrem no servidor, permitindo sincronizar as requisições HTTP do cliente nesse mesmo intervalo. Porém, dados em tempo-real não são tão previsíveis, resultando em requisições desnecessárias e muitas conexões são abertas e fechadas sem necessidade [5]. Um modelo de comunicação entre cliente-servidor baseado em push inverte o modelo tradicional. Push refere-se a um modelo de comunicação entre cliente-servidor onde é o servidor que inicia a comunicação. Neste modelo, é possível que o servidor envie dados para o cliente (push server) sem que ele tenha explicitamente solicitado [6]. Diferente do modelo tradicional onde o cliente era o responsável por fazer as requisições de dados ao servidor, no modelo push, é o servidor que empurra os dados para os clientes considerando configurações prévias de suas preferências, utilizando um padrão chamado publish/subscribe. No padrão publish/subscribe, o cliente se registra em um ou mais serviços de seu interesse presentes no servidor e aguarda por atualizações. No momento em que ocorrer atualizações em algum desses serviços, o servidor notifica todos os clientes que estão registrados nele. Com isso, o cliente não precisa mais buscar por atualizações, enviando requisições HTTP periodicamente ao servidor como na técnica de polling. Ele será notificado pelo próprio servidor assim que essas atualizações ocorrerem. Comet e Websockets são duas tecnologias nas quais é possível utilizar o modelo push. As duas tecnologias possuem abordagens diferentes e serão exploradas nas sessões 1.2 e 1.3.

1.1. PUBLISH/SUBSCRIBE 27 1.1 PUBLISH/SUBSCRIBE O paradigma de interação publish/subscribe relaciona produtores de informações com consumidores [7]. Consumidores (subscribers assinantes) expressam seu interesse em um ou mais serviços, para que possam vir a ser notificados quando informações geradas nesses serviços, por um produtor (publisher publicador), combinem com os de seu interesse. A figura 2 ilustra um sistema de interação para o modelo publish/subscribe. Figura 2 Um sistema de interação publish/subscribe Produtores sensores (1) publicam informações (que no modelo publish/subscribe são tratados como eventos) em um banco de dados. Essas informações são leituras de sensores. Cada leitura é compostas por um identificador do sensor, o dado que foi lido (que varia de acordo com a natureza do sensor) e a data que foi efetuada a leitura. mote_id: 1, data: 27.83, reading_time: 2013-01-18 00:17:40 mote_id: 2, data: 47.47, reading_time: 2013-01-18 00:17:41... Essas leituras são enviadas do banco de dados para um gerenciador de eventos localizado no servidor (2) através de um Programa. Os assinantes clientes móveis (3) assinam nesse gerenciador, para quais sensores desejam receber suas leituras. É função do gerenciador de eventos receber e rotear as leituras dos sensores para seus respectivos assinantes. Sensor Assinantes 1 Cliente 1, 2 2 Cliente 2 3 Cliente 1, 3...... Em um modelo publish/subscribe, algumas operações são necessárias para a interação entre publicadores e assinantes. A operação Publish() é usada pelos publicadores

28 Capítulo 1. TECNOLOGIA PUSH para gerar um evento. Esse evento será propagado para todos assinantes por meio da operação Notify(). A operação Subscribe() registra um assinante em algum evento de seu interesse e Unsubscribe() remove esse assinante. O uso de um gerenciador de eventos como mediador proporciona um desacoplamento entre publicadores e assinantes. Esse desacoplamento elimina qualquer dependência entre eles, aumenta a escalabilidade (a adição ou remoção de publicadores ou assinantes são independentes da interação) e o ambiente dinâmico resultante se adapta bem em redes móveis onde há frequentes conexões e desconexões [7]. O desacoplamento pode ser descritos a partir de três variáveis [8]: Desacoplamento espacial: Publicadores e assinantes não precisam ter conhecimento uns dos outros. Publicadores não guardam referências de nenhum assinante e vice-versa. Publicadores e assinantes não sabem quantos membros participam da interação. Desacoplamento temporal: Publicadores e assinantes não precisam estar ativos ao mesmo tempo, ou seja, participar da interação simultaneamente. Publicadores podem gerar eventos, enquanto os assinantes interessados nesses eventos estão desconectados. Da mesma maneira, assinantes podem ser notificados por um evento enquanto o publicador desse evento está desconectado. Desacoplamento de sincronização: Publicadores não sofrem bloqueio ao gerar eventos e assinantes podem receber notificações de forma assíncrona mesmo realizando uma operação concorrente. 1.1.1 VARIAÇÕES DO MODELO Assinantes recebem notificações apenas de eventos específicos nas quais se registraram. A forma do assinante representar seu interesse em algum evento, será usada como filtro de suas notificações e pode variar de acordo com diferentes esquemas da operação Subscribe(). 1.1.1.1 Publish/Subscribe Baseado em tópico O primeiro esquema publish/subscribe que surgiu é baseado na noção de tópicos ou assuntos. Em um publish/subscribe baseado em tópicos, cada publicador ou assinante gera ou declara interesse em tópicos identificados por palavras-chave. Cada tópico pode ser visto como um grupo, logo assinar um tópico T significa se tornar membro do grupo T [8]. A figura 3 ilustra esse esquema. Considere um exemplo de um sistema de geração de alarmes através de sensores. O sistema é dividido em áreas (sensores de clima, de trânsito, etc.) que geram leituras de monitoramento. Os assinantes podem decidir de qual área estão interessados em receber

1.1. PUBLISH/SUBSCRIBE 29 Figura 3 Topic-Based Publish-Subscribe [2] essas leituras. O trecho de código a seguir, mostra um exemplo onde um assinante se registra para receber leituras dos sensores de monitoramento do clima. 1 public c l a s s SensorReading { 2 public int moteid ; // i d e n t i f i c a d o r do sensor 3 public f l o a t data ; // dados do monitoramento 4 } 5 6 public class S e n s o r S u b s c r i b e r implements S u b s c r i b e r { 7 // List <Object> c o n t m as l e i t u r a s dos s e n s o r e s 8 public void update ( List <Object> l i s t ) { 9 for ( Object obj : l i s t ) { 10 i f ( ( ( SensorReading ) obj ). moteid == 1 11 && ( ( SensorReading ) obj ). data > 29) { 12 alarm ( ) ; 13 } 14 } 15 } 16 } 17 18 //... 19 S e n s o r S u b s c r i b e r sub = new S e n s o r S u b s c r i b e r ( ) ; 20 SensorMap. getarea ( weather ). s u b s c r i b e ( sub ) ; 1.1.1.2 Publish/Subscribe Baseado em conteúdo O esquema publish/subscribe baseado em conteúdo difere do esquema publish/subscribe baseado em tópico por considerar o conteúdo dos eventos em vez de algum critério predefinido (nome do tópico) como filtro para a operação Subscribe(). Nesse esquema, os eventos são classificados de acordo com suas propriedades. Os assinantes se registram nos eventos passando algum filtro como parâmetro. Os filtros são restrições geralmente em pares nome-valor (moteid = 1) e com operadores de comparação (data > 29). Os filtros podem ser combinados com operadores lógicos (AND, OR, NOT, etc.) para formarem

30 Capítulo 1. TECNOLOGIA PUSH padrões de registro (moteid = 1 AND data > 29). A representação desses filtros pode variar, sendo na maioria das vezes representados por Strings [8] que são interpretados pelo programa. O trecho de código a seguir mostra um exemplo onde um assinante se registra para receber leituras dos sensores de monitoramento utilizando um filtro. 1 public c l a s s SensorReading { 2 public int moteid ; // i d e n t i f i c a d o r do sensor 3 public f l o a t data ; // dados do monitoramento 4 } 5 6 public class S e n s o r S u b s c r i b e r implements S u b s c r i b e r { 7 public void update ( List <Object> l i s t ) { 8 alarm ( ) ; 9 } 10 } 11 12 //... 13 S t r i n g f i l t e r = moteid = 1 and data > 100 ; 14 S e n s o r S u b s c r i b e r sub = new S e n s o r S u b s c r i b e r ( ) ; 15 SensorMap. getarea ( weather ). s u b s c r i b e ( sub, f i l t e r ) ; Outros esquemas para assinaturas incluem Broadcast-Based Publish/Subscribe [2], List-Based Publish/Subscribe (conhecido como Observer Pattern [9]) e Type-Based Publish/Subscribe [8].

1.2. COMET 31 1.2 COMET Comet é um termo cunhado pelo Engenheiro de Software Alex Russell [10] que descreve um modelo de comunicação entre cliente e servidor onde a cada requisição do cliente, a conexão HTTP é persistida por um certo período, permitindo que nesse tempo o servidor envie dados para o cliente sem uma requisição explicita [6], técnica conhecida como push server. 1.2.1 AJAX Como vimos na seção 1, a comunicação no modelo tradicional cliente-servidor é realizada pelo protocolo HTTP, um protocolo de request-response. O seu funcionamento é da seguinte maneira: a maioria das ações do cliente (acessar um link, submeter um formulário, etc.) gera uma requisição HTTP para o servidor. O servidor recebe essa requisição, faz algum processamento e retorna uma resposta, contendo uma nova página HTML com as devidas mudanças que é usada pelo cliente (browser) para atualizar seu conteúdo. Mesmo se a página gerada alterar apenas uma linha, uma imagem ou pequenos fragmentos em relação a atual, o browser fará uma completa atualização de seu conteúdo atual com a nova página. Isso causa muito tráfego entre cliente e servidor de forma desnecessária. Além disso, vimos que o protocolo HTTP é half-duplex, ou seja, ações do cliente e servidor são executadas de forma síncrona. Enquanto o servidor estiver ocupado processando, o cliente fica completamente ocioso esperando pela resposta [6]. Essas limitações do modelo cliente-servidor, dificulta a criação de páginas e aplicações Web interativas e responsivas ao cliente, que a cada ação precisa esperar e esperar. Ajax é um novo modo de utilizar os padrões já existentes na Internet para superar essas dificuldades. Ajax (Asynchronous JavaScript and XML) não é uma tecnologia. Ajax é uma forma de projetar páginas e aplicações Web que sejam rápidas, dinâmicas e interativas com o usuário. Aplicações Web Ajax utilizam tecnologias já existentes na Internet: Extensible HyperText Markup Language (XHTML) Document Object Model (DOM) JavaScript Cascading Style Sheets (CSS) XMLHttpRequest Object Extensible Markup Language (XML) A explicação de cada uma dessas tecnologias está além do escopo desse trabalho.

32 Capítulo 1. TECNOLOGIA PUSH Ajax permite enviar requisições para o servidor de forma assíncrona, ou seja, em segundo plano. Com isso, o cliente não fica mais inativo esperando por uma resposta do servidor a cada requisição, podendo continuar a interagir com a página. Além disso, com Ajax é possível atualizar o conteúdo da página com os dados da resposta do servidor sem precisar atualizar a página por completo. Isso torna-se útil para requisições que resultariam em poucas alterações na página atual.

1.3. WebSocket 33 1.3 WEBSOCKET

35 CONCLUSÃO Sed consequat tellus et tortor. Ut tempor laoreet quam. Nullam id wisi a libero tristique semper. Nullam nisl massa, rutrum ut, egestas semper, mollis id, leo. Nulla ac massa eu risus blandit mattis. Mauris ut nunc. In hac habitasse platea dictumst. Aliquam eget tortor. Quisque dapibus pede in erat. Nunc enim. In dui nulla, commodo at, consectetuer nec, malesuada nec, elit. Aliquam ornare tellus eu urna. Sed nec metus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Phasellus id magna. Duis malesuada interdum arcu. Integer metus. Morbi pulvinar pellentesque mi. Suspendisse sed est eu magna molestie egestas. Quisque mi lorem, pulvinar eget, egestas quis, luctus at, ante. Proin auctor vehicula purus. Fusce ac nisl aliquam ante hendrerit pellentesque. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Morbi wisi. Etiam arcu mauris, facilisis sed, eleifend non, nonummy ut, pede. Cras ut lacus tempor metus mollis placerat. Vivamus eu tortor vel metus interdum malesuada. Sed eleifend, eros sit amet faucibus elementum, urna sapien consectetuer mauris, quis egestas leo justo non risus. Morbi non felis ac libero vulputate fringilla. Mauris libero eros, lacinia non, sodales quis, dapibus porttitor, pede. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Morbi dapibus mauris condimentum nulla. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Etiam sit amet erat. Nulla varius. Etiam tincidunt dui vitae turpis. Donec leo. Morbi vulputate convallis est. Integer aliquet. Pellentesque aliquet sodales urna.

37 REFERÊNCIAS 1 III, A. T. H. Ajax: The Definitive Guide. [S.l.]: O Reilly Media, 2008. ISBN 0596528388. 2 PUBLISH/SUBSCRIBE. http://msdn.microsoft.com/en-us/library/ff649664. aspx. Acesso em 06/08/2013. 3 WANG, V.; SALIM, F.; MOSKOVITS, P. The Definitive Guide to HTML5 Websocket. [S.l.]: Apress, 2013. ISBN 978-1-4302-4740-1. 4 MESBAH, A.; DEURSEN, A. V. A component- and pushbased architectural style for ajax applications. Journal of Systems and Software, p. 2194 2209, 2008. 5 LUBBERS, P.; GRECO, F. HTML5 Web Sockets: A Quantum Leap in Scalability for the Web. http://www.websocket.org/quantum.html. Acessado em 06/08/2013. 6 KACHHWAHA, R.; PATNI, P. Ajax enabled web application model with comet programming. International Journal of Engineering and Technology, p. 1155 1160, 2012. 7 HUANG, Y.; GARCIA-MOLINA, H. Publish/subscribe in a mobile environment. Wirel. Netw., Springer-Verlag New York, Inc., Secaucus, NJ, USA, v. 10, n. 6, p. 643 652, nov. 2004. ISSN 1022-0038. Disponível em: <http://dx.doi.org/10.1023/b:wine-.0000044025.64654.65>. 8 EUGSTER, P. T. et al. The many faces of publish/subscribe. ACM Comput. Surv., ACM, New York, NY, USA, v. 35, n. 2, p. 114 131, jun. 2003. ISSN 0360-0300. Disponível em: <http://doi.acm.org/10.1145/857076.857078>. 9 GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. [S.l.]: Addison-Wesley Professional, 1994. ISBN 0201633612. 10 RUSSELL, A. Comet: Low Latency Data for the Browser. http://infrequently. org/2006/03/comet-low-latency-data-for-the-browser/. Acesso em 06/08/2013.