Aplicação Web

Hoje em dia as aplicações Web não estão limitadas aosbrowsers, havendo já várias entidades que estão a dar força à ideia da criação de aplicações nativas baseadas em aplicações Web, como é o caso da Mozilla com o Firefox OS ou da Microsoft com o Windows 8. Para facilitar o desenvolvimento de aplicações para várias platafor- mas, é essencial a criação de uma API em Javascript que permita abstrair as diferenças de implementações de cada um dosbrowsers ou plataformas e também a lógica da implementação de cada uma das funcionalidades de forma a que seja apenas necessário implementar a camada visual própria de cada plataforma, para cada nova versão de uma aplicação Web. Assim, a implementação do cliente em Javascript, para além de uma arquitetura Model View Controller (MVC), deve também estar dividida em duas partes: A SDK e a User Interface (UI).

A SDK deve só por si estar dividida em várias camadas representadas na Figura 3.9 para permitir uma maior modularidade tanto ao nível da comunicação como de uma possível implementação futura.

Figura 3.9: Arquitetura da aplicação Web

pelos programadores para abstrair a complexidade das funcionalidades. Aqui deve existir uma forma de a UI configurar as camadas abaixo, de forma a que estas funcionem de acordo com o que a plataforma per- mite e o utilizador pretende. Para o caso em que um cliente esteja interessado apenas na API Javascript, os métodos existentes nesta camada são os únicos que serão documentados e distribuídos em conjunto com todo o código minificado e protegido.

Lógica de negócio - SDK Toda a lógica de negócio própria de cada funcionalidade RCS, o estabelecimento

de chamadas usando WebRTC entre outras capacidades devem estar definidas nesta camada. Esta deve ser dividida em módulos independentes de forma a que a remoção e adição de funcionalidades seja transparente e dependa apenas da configuração do utilizador ou do programador. Cada um destes módulos deverá disponibilizar os métodos necessários para a interação da API pública com a lógica de negócio.

Além da implementação de cada um dos módulos para disponibilizar funcionalidades, esta camada deve conter mais dois elementos na sua arquitetura: Um módulo de configuração e outro de eventos. O módulo de configuração deve estar acessível a cada um dos módulos de implementação das funcional- idades, para que estes possam agir em conformidade com a configuração recebida. As configurações incluídas neste módulo, para além das básicas sobre a plataforma em que estejam a correr, e as infor- mações sobre o utilizador que esteja a utilizar a aplicação, devem também ser geridas todas as configu- rações próprias de uma aplicação RCS, tal como definido na secção 2.2 da especificação[57]. A UI terá também acesso a esta configuração para que possa agir de forma correta, tal como por exemplo se deve

ou não mostrar os componentes para uma dada funcionalidade.

O outro módulo que deve fazer parte desta camada é um gestor de eventos para permitir a comunicação transparente com a camada da UI. Seguindo odesign pattern Observer[58], a forma da aplicação receber eventos tais como novas chamadas, mensagens, ou mudanças de estado de um dado contexto, é através do registo de funções para serem chamadas quando algo acontece. Todos os módulos podem lançar eventos quando algo acontece e deve ser passado para a UI, e quer tenham sido registados observadores para um dado evento, isto é transparente para cada módulo e a alteração é sempre passada para o gestor de eventos. Este por sua vez vai chamar cada função observadora que tiver sido registada para aquele evento em particular, se existir alguma.

Desta forma pretende-se dar liberdade à UI para que possa receber os eventos da SDK em diferentes partes da aplicação e que possa registar apenas os eventos desejados.

Camada de comunicação Para permitir que a aplicação utilize mais que um protocolo de transporte de-

pendendo do suporte de cada plataforma oubrowser, a camada de comunicação deve implementar um mecanismo de pedido-resposta em que cada módulo de cada funcionalidade possa enviar pedidos para o servidor abstraindo-se da comunicação. Independentemente de esta camada estar a utilizar WebSockets ou HTTP, os pedidos recebidos e respostas devolvidas devem ser iguais, por forma a tornar esta melhoria completamente autónoma desta camada.

Capítulo 4

Implementação

Após a análise da arquitetura, os componentes propostos foram implementados de forma a obter um ambi- ente funcional e que permitisse fazer as demonstrações e integrações necessárias para promover o produto da empresa.

O desenvolvimento pode-se dividir em duas grandes partes sendo uma delas a aplicação cliente e a outra os componentes do servidor. No entanto, todo o processo começou pela definição dos protocolos que seriam uti- lizados para unir os dois componentes. Assim, em seguida é apresentado o percurso de todo o desenvolvimento da solução que se inicia com esta análise e com a posterior descrição dos desenvolvimentos nos componentes em particular.

4.1 Comunicação aplicação - servidor

A comunicação entre os dois componentes foi feita usando dois protocolos de transporte para que pudessem ser suportados osbrowsers mais recentes com uma melhor performance (i.e WebSockets) e os browsers mais antigos usando tecnologias mais abrangentes (i.e HTTP).

Para a comunicação foi criado um conjunto de comandos e respostas para serem transmitidos entre aplicações e servidor substituindo os protocolos standard.