Colaboração e Cooperação

Hoje em dia, milhões e milhões de mensagens são trocadas diariamente em todo o planeta. A internet apresenta uma nova forma de comunicar e colaborar, isto porque usar a internet e usar o web browser tornou-se praticamente sinónimo. As pessoas usam o web browser como plataforma primária para realizar qualquer tarefa, e as ferramentas de comunicação não fogem “à regra”. Daí a necessidade de desenvolver aplicações “ricas” (Rich Internet Application – RIA), que funcionam num web browser, na tentativa de ir ao encontro das espectativas do utilizador. Um bom exemplo destas aplicações são as redes sociais, que são construídas para trabalharem num web browser e suportar comunicação em tempo-real, tanto a nível de atualização do

dashboard como a nível de comunicação entre as pessoas (Smolka, 2013).

Numa relação entre recursos (nomeadamente humanos), a possibilidade de colaborarem (todos em prol de um mesmo objetivo) ou cooperarem (todos juntos serão mais fortes) traduz-se em mecanismos que, ao serem suportados, representam mais valias e sustentam a co-decisão e co-criação.

Este capítulo apresenta algumas plataformas/tecnologias/protocolos comunicacionais atuais que contribuem, por um lado, para a comunicação síncrona (tempo-real) e por outro para a colaboração e cooperação.

2.3.1. XMPP

O Extensible Messaging and Presence Protocol (XMPP) é um protocolo para mover dados entre duas ou mais

entidades (Moffitt, 2010). Este também é visto como uma tecnologia aberta para comunicação em tempo-real, através do uso de XML como formato-base para a troca de informações (Saint-Andre, Smith, & Tronçon, 2009), oferecendo à comunicação uma estrutura “rica” e extensível.

Quanto aos serviços, este protocolo permite encriptação de sinal, autenticação, lista de contactos, notificações, troca de mensagens entre múltiplas pessoas, assim como sessões P2P de forma a permitir chamadas de voz e vídeo, como também a transferência de ficheiros (Saint-Andre et al., 2009).

Os principais benefícios a retirar deste protocolo são: i) segurança, fornecendo criptografia de canal e autenticação; ii) descentralização, i.e., qualquer pessoa ou organização pode criar o seu próprio servidor XMPP; iii) extensibilidade, visto que a troca de informações se baseia em XML e tem sido usado em aplicações de Instant Messaging, jogos, redes sociais, geolocalização, etc., e iv) escalabilidade, devido ao seu modelo “push” para a transferência de informação (Moffitt, 2010).

O facto de ser descentralizado também pode constituir uma desvantagem devido à falta de um “cliente” ou servidor oficial, que pode levar ao afastamento das pessoas. O esquema aplicado ao nome do utilizador também poderá constituir uma desvantagem, visto que há a necessidade de memorizar um nome que é parecido a um

e-mail e pode provocar confusão naquelas pessoas com menos aptidão para as tecnologias (Seer, 2015). Além

disso, o XMPP não é otimizado para sessões de curta duração ou pedidos simples. Este necessita de um número considerável de recursos para criar, manter e destruir sessões. Para ligações mais longas, a sobrecarga do

XMPP é insignificante em comparação com uma solução baseada em Hypertext Transfer Protocol (HTTP)

(Moffitt, 2010).

No Código 6 é possível observar um pequeno excerto de XMPP relativo ao envio de uma mensagem de texto.

Código 6 - Exemplo de Mensagem XMPP

2.3.2. MQTT

Message Queing Telemetry Transport (MQTT) é um protocolo de comunicação entre máquinas, isto é,

Máquina-a-Máquina (Machine-to-Machine – M2M) (Egli, 2016). Este protocolo é muito leve e, por isso, é

ideal para a comunicação M2M, para as Wireless Sensor Networks (WSN) e para o IoT, onde existem cenários

que contêm sensores e atuadores que comunicam com aplicações através do Message Broker do MQTT(Egli,

2016). Além disso, também é ideal para aplicações móveis devido ao seu mínimo tamanho, ao baixo consumo de energia, à minimização de pacotes de dados e à sua capacidade de distribuição eficiente de informações para um ou mais recetores (Sahoo, 2016).

Este protocolo começou a ser desenvolvido em 1999 por Andy Stanford-Clark (International Business

Machines – IBM) e Arlen Nipper (Eurotech) (HiveMQ, 2014). Com o crescimento exponencial da IoT e a

necessidade de conectar e comunicar entre dispositivos de baixa potência, hoje descobriu um mercado (Sahoo, 2016) onde pode ser largamente usado.

O seu funcionamento baseia-se numa arquitetura de publish/subscribe. Este tipo de arquitetura é orientado a eventos e permite enviar informações para os clientes. A comunicação ocorre através de um ponto central, designado de Broker (mediador), que é responsável por encaminhar todas as mensagens entre os remetentes e os recetores. Cada mensagem publicada para o broker inclui um “tópico” (topic) que permite ao broker rotear a informação. Cada cliente que pretende receber mensagens com um certo tópico, realiza a subscrição e o broker trata de entregar todas as mensagens com esse tópico nos respetivos clientes (Sahoo, 2016).

“Esta arquitetura permite soluções altamente escaláveis sem dependências entre os produtores e

consumidores de dados” (Sahoo, 2016), visto que os clientes comunicam através de um tópico, não existindo

Figura 13 - Arquitetura Publish/Subscribe – MQTT (HiveMQ, 2014)

Em MQTT cada cliente tem uma ligação TCP permanentemente aberta para com o broker e, caso esta ligação

seja interrompida, o broker tem a capacidade de “guardar” (buffer) todas as mensagens e enviá-las para o cliente quando este voltar a estar online (HiveMQ, 2014).

2.3.3. WebRTC

Web Real-Time Communications (WebRTC) é um projeto aberto, iniciado pela Google, com o objetivo de

construir um método padrão de comunicação em tempo-real através dos web browsers disponíveis (Consulting, 2012). Basicamente, este projeto contempla a visão de um mundo onde todo o tipo de dispositivo é capaz de comunicar através de uma plataforma comum, isto é, ser fácil de incorporar um sistema de videoconferência em qualquer aplicação web.

Surgiu a partir de uma necessidade de eliminar processos como o download, a instalação e a atualização que a maior parte das aplicações que suportam comunicação em tempo-real utilizam, tendo como princípio de que as suas API devem ser compostas por código aberto, padronizado e mais eficiente que as tecnologias existentes (Dutton, 2012).

Para a realização da troca de dados de streaming entre web browsers, WebRTC usa RTCPeerConnection. No entanto, métodos e protocolos de sinalização (para coordenar a comunicação e enviar mensagens de controlo) não se encontram especificados (Google, 2016).

Além da comunicação ponto-a-ponto entre os web browsers, WebRTC estende a semântica da arquitetura cliente-servidor e disponibiliza dois modelos:

a) Trapezoid – Os web browsers executam uma aplicação web através de servidores diferentes. É estabelecida uma ligação ponto-a-ponto que configura o caminho por onde vão circular os dados de media, sem intervenção de qualquer servidor. A sinalização é enviada através de HTTP ou

WebSockets através dos servidores que vão gerindo os sinais conforme for necessário (Romano & Loreto, 2014) (Figura 14).

Figura 14 - WebRTC Trapezoid (Romano & Loreto, 2014)

b) Triangle – A diferença deste modelo para o anterior, é o facto de ambos web browsers estarem a

correr a mesma aplicação, através do mesmo servidor (Figura 15).

Figura 15 - WebRTC Triangle (Romano & Loreto, 2014)

A existência de comunicação ponto-a-ponto, direta e segura entre os web browsers terá grande impacto sobre a web moderna, remodelando a forma de utilização das redes físicas que compõe a internet. As ligações diretas ponto-a-ponto, muitas das vezes, são de baixa latência, permitindo um rápido aparecimento de jogos, streaming de vídeo, etc. Além disso, estas ligações permitem a troca de informações de forma privada, sem a existência de servidores intermediários. Esta troca de dados remove a necessidade de serializar, recodificar, ou converter dados em cada passo do processo (Manson, 2013).

Em jeito de conclusão, é possível afirmar que o avanço deste projeto pode levar à adoção de novas formas de construção de serviços que permitem a comunicação em tempo-real de uma forma mais simples e sem preocupações em relação à instalação de aplicações com o mesmo objetivo.

2.3.4. WebSocket

Normalmente, quando um web browser abre uma página web, é realizado um pedido HTTP para o servidor

onde esta se encontra armazenada. A partir daí, o servidor reconhece o pedido e responde enviando a página pretendida. Durante este processo a informação pode tornar-se obsoleta e para o utilizador se manter atualizado terá de recarregar a página constantemente, o que poderá apresentar algum incómodo (Wang, Salim, & Moskovits, 2013).

Apesar de começarem a surgir bibliotecas que implementam o protocolo WebSocket, ainda há pouco tempo as

tentativas de fornecer aplicações web que trabalham em tempo-real eram sustentadas na técnica de Polling (Figura 16). Esta baseia-se em pedidos síncronos realizados regularmente (em intervalos de tempo regulares) por parte do cliente para o servidor de forma a verificar se existem novas informações. O cliente recebe a resposta, independentemente da existência ou não de informações (Wang et al., 2013).

Figura 16 - Polling (IBM, 2015)

Outra técnica que também se usa/usava é a Long Polling (Figura 17), um pouco diferente do Polling, já que na realização de um pedido é aberta uma ligação durante um período de tempo específico, que pode variar. Ou seja, após a realização do pedido, a ligação é mantida aberta até à existência de resposta por parte do servidor ou até ao fim do período de tempo estabelecido. Este processo repete-se a cada pedido realizado (IBM, 2015).

Figura 17 - Long Polling (IBM, 2015)

Por fim, numa última alternativa, temos o Streaming onde o cliente realiza um pedido e o servidor responde mantendo essa resposta “aberta”, encontrando-se constantemente a ser atualizada (Figura 18). Esta resposta é atualizada sempre que uma nova mensagem esteja pronta a ser entregue. Apesar de aparentar ser uma boa solução para aplicações de tempo-real, o servidor nunca sinaliza a resposta como completa, mantendo a ligação aberta. Isto pode tornar-se num problema porque proxies e firewalls podem guardar a resposta temporariamente, provocando um aumento da latência na entrega das mensagens (Wang et al., 2013).

Figura 18 - Streaming (IBM, 2015)

De forma a combater todos os problemas mencionados anteriormente, surge o protocolo WebSocket (Figura

19). O tipo de comunicação adotado por este protocolo é o full-duplex, onde os intervenientes podem trocar mensagens em simultâneo. Neste ocorre apenas um pedido HTTP que é responsável pela abertura da ligação WebSocket. A partir daí, o servidor não necessita de aguardar por pedidos do cliente, assim como o cliente pode enviar mensagens a qualquer momento. A existência de um único pedido reduz significativamente a latência (Wang et al., 2013) e oferece uma melhor experiência ao utilizador.

Figura 19 - Protocolo WebSocket (Adaptado de Wang et al., 2013)

2.3.5. SignalR

SignalR é uma framework que facilita a construção de aplicações web multi-utilizador e assentes em comunicação tempo-real, através da vasta utilização de técnicas de assíncronia com o objetivo de atingir grande rapidez e desempenho máximo das aplicações (Aguilar, 2014).

Esta framework tem a capacidade de abstrair o developer das características de baixo nível, aparentando sempre que o sistema/aplicação se encontra a trabalhar sobre uma ligação persistente, constantemente aberta entre o

servidor e o cliente. SignalR tem uma característica única: determinar qual a melhor técnica (Long Polling; WebSockets; Server-sent Events; Forever frame) a usar, tanto no cliente como no servidor. Portanto, o conhecimento da técnica adotada pelo SignalR numa comunicação torna-se irrelevante, visto que a sua utilização se apoia numa API que oferece abstração quanto ao tipo de envio de mensagens utilizado.

Além disso, SignalR também inclui um bus de mensagens que tem a capacidade necessária para fazer a gestão de transmissão e receção de informações entre o servidor e os clientes. O servidor consegue detetar as conexões e desconexões dos clientes, enviar mensagens para todos os clientes, gerir todas as questões relativamente à comunicação e garantir a entrega das mensagens (Aguilar, 2014).

Por fim, a sua arquitetura é escalável, oferecendo às aplicações a capacidade de evoluírem e responderem em proporção ao número de utilizadores (Aguilar, 2014). Através da Figura 20 é possível visualizar a esquematização de uma ligação virtual com SignalR.

Figura 20 - Conexão Virtual SignalR (Aguilar, 2014)

2.3.6. Pusher

Pusher baseia-se numa API simples que permite, de uma forma rápida, fácil e segura, a integração de funcionalidade bidirecional em tempo-real através de WebSockets para a web e aplicações móveis (Pusher, 2016). Esta apresenta-se como uma camada entre os servidores e clientes, mantendo ligações persistentes (Community, 2015) (Figura 21).

Figura 21 - Integração do Pusher (Adaptado de Pusher, 2016)

Devido à sua aplicabilidade, esta API vem sendo largamente usada e por entidades de renome. Os casos de uso desta podem ser vários: notificações em tempo-real, indicação de atividade, visualização de dados, chats, aplicações “colaborativas”, jogos de multiplayer, etc. (Community, 2015).

Pusher apresenta um modelo baseado em canais que permite filtrar e controlar quem recebe as mensagens.

Além disso, também é possível “anexar” a cada canal diferentes tipos de eventos, ou seja, é possível do lado do cliente realizar a subscrição a diferentes canais e consequentemente a vários tipos de eventos, provocando assim um mecanismo de “escuta” (listener) que reage a cada mensagem enviada por parte do servidor. A grande vantagem aqui presente, passa pela não necessária realização de pedidos ao servidor para, por exemplo, atualizar dados, porque sempre que existir alguma atualização o servidor irá enviar a mesma (Código 7 – 1) e o cliente estará preparado para reagir (Código 7 – 2), reduzindo assim a carga sobre o servidor em relação ao número de pedidos realizados.

Código 7 - Pusher – Exemplo comunicação entre cliente-servidor

2.3.7. Dashboards

A comunicação tem apresentado grande evolução nos últimos tempos, promovendo cada vez mais a necessidade constante de partilha de informação. A aproximação das pessoas exige agora menos custos e menos tempo. Plataformas de colaboração, como Podio20, Trello e Asana21, são exemplos de fomentação dessa aproximação. Embora estejam assentes em linguagens e plataformas diferentes, existe já uma variedade de protocolos com o objetivo de garantir a necessária comunicação em tempo-real.

Estas plataformas implementam protocolos de comunicação ao nível do dashboard. Todas “reconhecem” que

é essencial uma atualização automática da informação. Por isso, tanto o Podio, como o Trello e o Asana têm implementações de sistemas baseados em protocolos que permitem a comunicação em tempo-real, como os

que foram apresentados previamente. O Podio apresenta-se como uma solução mais completa em relação à

gestão de projetos, enquanto que o Trello e o Asana são mais “orientados à tarefa”, mas o foco assenta-se na

implementação das tecnologias de comunicação ao nível do dashboard, assim como a construção/integração

de aplicações.

O Podio baseia-se numa implementação “completa” no que diz respeito à gestão dos processos que decorrem

numa empresa. Além de permitir estruturar projetos, também é possível organizar, por exemplo, a equipa comercial, de forma a transformar o funcionamento global da empresa (Podio, 2016a). Em relação à comunicação/atualização no dashboard, o Podio utiliza um sistema baseado na arquitetura publish/subscribe através do protocolo Bayeux22, designado de Faye23(Podio, 2016b). Bayeux baseia-se num protocolo de

20 https://podio.com/

21 https://asana.com/

22 https://docs.cometd.org/current/reference/index.html#_bayeux

transporte de mensagens assíncronas, com baixa latência entre o cliente e o servidor. Tal como o Pusher, o Bayeux faz um roteamento das mensagens através de canais (Russell, Wilkins, Davis, & Nesbitt, 2007). O Trello, também relacionado com a gestão de projetos, consiste numa plataforma cujo objetivo principal é a organização de tarefas. Inspirado na metodologia de trabalho Scrum, oferece total liberdade ao utilizador na definição do seu dashboard. As técnicas de comunicação implementadas são: pushing e polling. O pushing através de uma biblioteca baseada em Javascript, designada de Socket.IO²⁴, que permite conexões WebSocket segundo o mesmo padrão (publish/subscribe) aplicado no Pusher e no Podio. O polling (através de pedidos

baseados em Asynchronous Javascript and XML – AJAX) foi implementado como alternativa ao pushing, caso

o web browser não suporte WebSockets (Kiefer, 2012).

Assim como o Trello, o Asana tem como objetivo principal a organização de tarefas. O seu dashboard é orientado a listas de tarefas, permitindo que estas sejam agrupadas formando um projeto, como também os

projetos podem ser agrupados formando um workspace. Quanto aos sistemas de comunicação implementados,

Asana usa uma framework desenvolvida pela própria equipa, designada de Luna (Asana, 2016), onde os processos que decorrem entre o cliente e o servidor apresentam um conceito diferente dos que foram apresentados até então. Luna permite o desenvolvimento de aplicações “isomórficas” em tempo-real. Este tipo de aplicações permite a execução de processos no servidor para cada sessão cliente. Luna tem a capacidade de simular o cliente no servidor, ou seja, de forma sincronizada, é capaz de executar no servidor o mesmo código que está a ser executado no cliente.

“This allows the server to look at the data that the application loads and proactively send data to the client, essentially simulating the UI on the server” (Strimpel & Najim, 2016).

Neste projeto, além da implementação de tecnologias/protocolos que permitam uma comunicação em

tempo-real, tanto a nível de dashboard como a nível de comunicação Humano-Humano (Human-to-Human – H2H),

os objetivos principais, em relação à comunicação, passam por: i) demonstrar que o funcionamento deste tipo de dashboards pode melhorar quanto à capacidade de reação das aplicações, tendo em conta o contexto apresentado e ii) apresentar proposta que garante a comunicação H2H sempre que necessária.

Da análise ao Podio, Trello e Asana, foi elaborada uma tabela (Tabela 4) onde se confrontam estas soluções

com o que é pretendido desenvolver (Extended Federated Social Network – EFSN) tendo em conta vários

aspetos que se consideram relevantes na apresentação e funcionamento de um dashboard eficaz: ser acessível via web (Web Based); incorporar tecnologias que permitam sincronização em tempo-real (Real-Time); estar disponível em várias plataformas web e mobile (Cross-Platform); ter um dashboard adaptável ao contexto atual, i.e., uns componentes – widgets – que reagem de forma autónoma a alterações de estado de outros, na sequência do que se “está a passar” no dashboard (Context-Aware); disponibilização de meios de comunicação síncrona (Canais Comunicacionais) e consequente abstração – ausência de consciência – em relação ao canal utilizado durante a comunicação (Abstração do Canal); permitir integrar múltiplas aplicações distintas (Orientado a Aplicações); partilhar widgets entre dashboards diferentes, com a capacidade de sincronização de estados (Sincronização de Widgets).

24 http://socket.io/

Tabela 4 - Podio vs Trello vs Asana vs EFSN Podio (Faye) Trello (Socket.IO) Asana (Luna) EFSN (Pusher) Web Based Real-Time Cross-Platform Context-Aware Canais Comunicacionais Abstração do canal Orientado a Aplicações Sincronização de Widgets

Apesar das múltiplas tecnologias/protocolos utilizados, assim como a interoperabilidade já suportada (com outras aplicações como Slack²⁵, Toggl²⁶, etc.), nenhuma destas soluções apresenta um dashboard que: i) seja capaz de reagir ao contexto apresentado; ii) permita integrar widgets correspondentes a aplicações externas à plataforma; iii) permita a sincronização de estado entre widgets partilhados.

Quanto à comunicação H2H, as plataformas atuais apresentam alguns meios para tal (nomeadamente chats),

mas nunca envolvendo utilizadores externos à plataforma.

Neste trabalho será explorada uma arquitetura para dashboards “conscientes do contexto”, que garante comunicação H2H através de uma camada de abstração em relação ao canal que está a ser usado, onde aplicações distintas podem ser integradas e cujos widgets podem ser partilhados entre dashboards diferentes.