Emanuel Fernando Passos Ramos da Mota...

Outubro de 2011

Tese de Mestrado

Ciclo de Estudos Integrados Conducentes ao Grau de Mestre

em Engenharia Eletrónica Industrial e Computadores

Trabalho efectuado sob a orientação do

Professor Doutor Sérgio Adriano Fernandes Lopes

Emanuel Fernando Passos Ramos da Mota Miranda

Monitorização de Plataformas Marítimas

Geradoras de Energia

Universidade do MinhoEscola de Engenharia

Monitorização de plataformas marítimas geradoras de energia

III

Agradecimentos

Quero em primeiro lugar agradecer a Deus, pela oportunidade que me concedeu de poder frequentar e concluir um curso

superior, e por toda a sabedoria que por ele me foi dada nesta caminhada:

Porque o SENHOR dá a sabedoria, e da sua boca vem o conhecimento e o entendimento.

Provérbios 2:6

Agradeço naturalmente ao meu orientador Professor Doutor Sérgio Adriano Fernandes Lopes, por todo o apoio,

disponibilidade e ajuda prestada ao longo de todo este trabalho. Agradeço pela excelente orientação, por todas as dicas,

correcções e ideias, pois seguramente foram valiosas.

Não posso deixar de agradecer também à minha família, em especial à minha mãe e ao meu pai, que me instruíram e

ensinaram, e por isso este trabalho é uma realidade. Fizeram um bom trabalho. Ao meu irmão Daniel, que em breve

seguirá os meus passos, pelo apoio demonstrado.

À minha noiva e futura esposa, Nini, agradeço todo o apoio, paciência e amor demostrado, não só ao longo deste

trabalho, mas ao longo de toda esta caminhada. Agradeço pelo portátil gentilmente cedido, sem ele nem uma linha de

código poderia escrever. Prometo que o vou formatar em breve. Por tudo, muito obrigado.

Ao meu avô Fernando e avó (vovó) Céu, cuja sabedoria de ambos é imensa, agradeço todos os conselhos e incentivos que

sempre me deram, e vão continuar a dar.

Agradeço aos meus colegas, em especial ao Rui, à Cátia e ao Joel, pela companhia e incentivo constante. Custou mas

conseguimos. Eu disse que conseguíamos, não disse?

Por fim, obrigado a quem me roubou o portátil juntamente com toda a informação importante. Agora faço backups.


V

Resumo

As aplicações web modernas assemelham-se cada vez mais às aplicações desktop, permitindo interacções

sofisticadas com o utilizador, interfaces ricas e interactivas, processamento do lado do cliente, comunicação assíncrona e

características multimédia. Ao mesmo tempo, estas são facilmente distribuídas e interagem com outros sistemas e

aplicações, que habitualmente são implementadas em plataformas e linguagens diferentes.

O objectivo final desta dissertação é o desenvolvimento de uma aplicação, disponível pela web, que permita

monitorizar o estado de plataformas marítimas geradoras de energia. Devido aos requisitos impostos, a aplicação não

pode ser uma aplicação web tradicional que apenas acede a uma Base de Dados para apresentar informação ao

utilizador. Essencialmente, a aplicação deve apresentar as plataformas num mapa, e permitir a visualização dos estados

mais problemáticos. Assim, de modo a cumprir os requisitos impostos, o sistema desenvolvido é constituído por uma Rich

Internet Application, que integra um servidor de Base de Dados e armazena o estado de todas as plataformas.

No entanto, um sistema deste tipo envolve a integração de diferentes tecnologias, linguagens e APIs,

nomeadamente, a integração entre tecnologias relacionadas com o lado do cliente, servidor, e com a comunicação entre

ambos. Deste modo, é necessário ponderar as alternativas existentes, para os diferentes serviços/funcionalidades

estipuladas. Por essa razão, este trabalho tem também como objectivo intermédio, o estudo comparativo entre várias

tecnologias web susceptíveis a integrar o sistema de monitorização, com o intuito de escolher uma solução global robusta

e eficiente. Assim, nesta dissertação, são avaliadas três tecnologias para a implementação da interface, o Ajax (com

HTML5), o JavaFX, e o Flex, serviços diferentes de informação geográfica como o Google Maps, Yahoo! Maps e Bing Maps,

e diferentes tecnologias de comunicação como o HTTP, Web Services (SOAP, REST) e AMF.

O estudo clarificou as vantagens e desvantagens de cada tecnologia, e permitiu concluir que no âmbito da

aplicação pretendida, o Flex foi a escolha mais adequada para a implementação da interface, o Google Maps para o

serviço de informação geográfica, e o AMF para a comunicação com o servidor. Definiu-se assim a arquitectura final do

protótipo e procedeu-se à implementação do mesmo, começando pelo desenvolvimento do servidor e terminando com o

cliente. Para simular os dados chegados das plataformas ao servidor, implementou-se ainda uma outra aplicação para

testar o protótipo da aplicação de monitorização. No final o objectivo principal foi cumprido através do desenvolvimento

de uma RIA, que engloba as tecnologias escolhidas nas experiências anteriores, e que cumpre todos os requisitos

impostos. Além disso, através das experiências efectuadas, demonstrou-se o impacto das RIA na forma de desenvolver

aplicações web modernas, a importância dos Web Services na web actual, e que todas as tecnologias avaliadas podem ser

usadas em simultâneo para simplificar o desenvolvimento de uma aplicação web, e para melhorar a sua qualidade final.

Palavras-chave: Programação Web, Base-de-Dados, Web Services, SOAP, REST, Java, Flex, Ajax, PHP e HTML5


VII

Abstract

Modern web applications hold obvious similarities to desktop applications, allowing sophisticated user

interaction, rich and interactive interfaces, client-side processing, asynchronous communication, and multimedia

characteristics. At the same time, these applications are easily distributed, and interact with other systems and

applications that are usually from different platforms, and different languages.

The primary objective of this dissertation is the development of an application, accessible by the web, which

allows the monitoring of energy generation maritime platforms. Due to the imposed requisites, the application cannot be

a simple traditional web application that solely fetches data from a database, and presents it to the user. Essentially, the

application must display the platforms on a map, and provide the monitoring of the most problematic states. Thus, in

order to fulfill the demanded requirements, the system developed in this work is composed by a Rich Internet Application

that includes a database server and stores all platforms condition.

Nevertheless, a system like this involves the integration of different technologies, languages and APIs, namely,

the integration between client and server related technologies, and their communication. Hence, it is necessary to weigh

the existing alternatives to the stipulated services/functionalities.

For that reason, it is also this works objective, to perform a comparative study between several web technologies

that are likely to integrate the monitoring system, with the motif of choosing a robust and efficient solution. Thus, in this

dissertation, three technologies for the interface implementation are evaluated, specifically Ajax (with HTML5), JavaFX,

and Flex, also different geographic information services, like Google Maps, Yahoo! Maps and Bing Maps, and different

communication technologies, including HTTP, Web Services (SOAP, REST) and AMF.

The experiment clarified the advantages and disadvantages of each technology, and according to the

comparative study, Flex was the most adequate choice for the interface implementation, Google Maps for the geographic

information service, and AMF for the server communication. With the final prototype architecture defined, one

proceeded with its implementation, starting with the development of the server and finishing with the client. To simulate

the data reception from the platforms to the server, one implemented another application to test the monitoring

application. In the end the final objective was accomplished through the development of a RIA, which includes the

technologies chosen from the experimental study, and fulfills all the mandatory requisites. Moreover, through the

performed experiments, one could demonstrate the RIA impact in the development of modern web applications, the

importance of Web Services in the modern web, and that all the evaluated technologies can be used together to simplify

the development of a web application, and to enhance its final quality.

Keywords: Web programming, Databases, Web Services, SOAP, REST, Java, Flex, Ajax, PHP and HTML5


IX

Índice

AGRADECIMENTOS .......................................................................................................................................................... III

RESUMO .......................................................................................................................................................................... V

ABSTRACT ...................................................................................................................................................................... VII

ÍNDICE ............................................................................................................................................................................. IX

ÍNDICE DE FIGURAS........................................................................................................................................................ XIII

ÍNDICE DE TABELAS...................................................................................................................................................... XVII

ACRÓNIMOS ..................................................................................................................................................................XIX

1 INTRODUÇÃO ............................................................................................................................................................ 1

1.1 ENQUADRAMENTO .................................................................................................................................................. 1

1.2 MOTIVAÇÃO.......................................................................................................................................................... 2

1.3 REQUISITOS DA APLICAÇÃO........................................................................................................................................ 2

1.4 ORGANIZAÇÃO DA TESE ............................................................................................................................................ 4

2 TECNOLOGIAS DE COMUNICAÇÃO WEB .................................................................................................................... 7

2.1 HTTP .................................................................................................................................................................. 7

2.2 WEB SERVICES ..................................................................................................................................................... 12

2.2.1 SOAP-based Web Services ......................................................................................................................... 13

2.2.2 REST ......................................................................................................................................................... 16

2.3 ACESSO A BASES DE DADOS..................................................................................................................................... 19

2.4 REMOTING/AMF ................................................................................................................................................. 21

3 RICH INTERNET APPLICATIONS ................................................................................................................................ 23

3.1 PLATAFORMAS RIA ............................................................................................................................................... 28

3.1.1 Flex .......................................................................................................................................................... 28

3.1.2 Microsoft Silverlight .................................................................................................................................. 31

3.1.3 JavaFX ...................................................................................................................................................... 32

3.1.4 HTML5 ..................................................................................................................................................... 34 Perspectiva das tecnologias web normalizadas ...................................................................................................... 35 3.1.4.1

AJAX ..................................................................................................................................................................... 36 3.1.4.2

4 EXPERIMENTAÇÃO DE SOLUÇÕES ALTERNATIVAS ................................................................................................... 40

4.1 GUI E MAPAS...................................................................................................................................................... 41

4.1.1 Serviços de Mapas .................................................................................................................................... 42 Mapas Interactivos ................................................................................................................................................ 42 4.1.1.1

Mapas Estáticos .................................................................................................................................................... 44 4.1.1.2


X

4.1.2 Aplicação Ajax ..........................................................................................................................................46 Processamento ..................................................................................................................................................... 46 4.1.2.1

Apresentação da UI ............................................................................................................................................... 50 4.1.2.2

4.1.3 Aplicação Flex ...........................................................................................................................................52 Comunicação com o servidor ................................................................................................................................. 53 4.1.3.1

Apresentação da UI ............................................................................................................................................... 53 4.1.3.2

Processamento ..................................................................................................................................................... 55 4.1.3.3

4.1.4 Aplicação JavaFX.......................................................................................................................................57

4.1.5 Conclusão .................................................................................................................................................61

4.2 COMUNICAÇÃO CLIENTE- SERVIDOR ...........................................................................................................................65

4.2.1 Serviços SOAP Java & PHP .........................................................................................................................65

4.2.2 Clientes SOAP............................................................................................................................................67

4.2.3 Serviços REST Java & PHP ..........................................................................................................................72

4.2.4 Clientes REST ............................................................................................................................................75

4.2.5 Conclusão .................................................................................................................................................78

5 DESCRIÇÃO DO PROTÓTIPO .....................................................................................................................................83

5.1 SERVIDOR ...........................................................................................................................................................83

5.1.1 Construção da Base de Dados ...................................................................................................................83

5.1.2 Operações ................................................................................................................................................87

5.2 CLIENTE ..............................................................................................................................................................92

5.2.1 Inicialização da aplicação ..........................................................................................................................95

5.2.2 Vista de mapa ...........................................................................................................................................97

5.2.3 Vista de tabela ........................................................................................................................................ 100

5.2.4 Procura de plataforma ............................................................................................................................ 102

5.2.5 Histórico de um sensor ............................................................................................................................ 105

5.2.6 Actualização da informação .................................................................................................................... 109 Plataformas ........................................................................................................................................................ 109 5.2.6.1

Sensores ............................................................................................................................................................. 111 5.2.6.2

SensorDataGrid – Cor de fundo ........................................................................................................................... 113 5.2.6.3

5.3 SIMULADOR ....................................................................................................................................................... 114

6 CONCLUSÃO .......................................................................................................................................................... 117

6.1 ANÁLISE DE RESULTADOS....................................................................................................................................... 117

6.2 CONCLUSÕES E TRABALHO FUTURO .......................................................................................................................... 118

BIBLIOGRAFIA ............................................................................................................................................................... 121

ANEXO A. DOCUMENTO WSDL ............................................................................................................................... 125

ANEXO B. TRIGGERS ............................................................................................................................................... 127


XI

ANEXO C. SANITIZESTRINGANDSQL ....................................................................................................................... 129

ANEXO D. FLEX GUI ................................................................................................................................................ 130

ANEXO E. INICIALIZAÇÃO DO MAPA ...................................................................................................................... 133

ANEXO F. PLACEMARKERS ..................................................................................................................................... 135

ANEXO G. SHOWPLATGROUP ................................................................................................................................. 137

ANEXO H. DATEPARSEFUNCTION ........................................................................................................................... 139

ANEXO I. GETSENSORSELECTEDHISTORIC ................................................................................................................. 141

ANEXO J. GETUPDATEDPLATFORMSRESULT_RESULTHANDLER ................................................................................. 143

ANEXO K. CHECKPLATSTATUS ................................................................................................................................ 145

ANEXO L. UPDATEPLATSTATUS ................................................................................................................................. 146

ANEXO M. CALCROWCOLOR ................................................................................................................................... 147


XIII

Índice de Figuras Figura 1.1 – Estrutura base do sistema de monitorização ................................................................................................... 3

Figura 2.1 – Pedido e resposta HTTP .................................................................................................................................. 7

Figura 2.2 – Mensagem HTTP ............................................................................................................................................ 8

Figura 2.3 – Exemplo de uma transacção HTTP GET [3] .................................................................................................... 10

Figura 2.4 – Pilha protocolar do http................................................................................................................................ 11

Figura 2.5 – Exemplo de uma ligação TCP/IP .................................................................................................................... 11

Figura 2.6 – Constituição de uma mensagem SOAP .......................................................................................................... 13

Figura 2.7 – Esqueleto de uma mensagem SOAP .............................................................................................................. 14

Figura 2.8 – Pedido HTTP cujo corpo contém uma mensagem SOAP ................................................................................ 14

Figura 2.9 – Resposta HTTP ao pedido anterior ................................................................................................................ 15

Figura 2.10 – Exemplo de um documento WSDL .............................................................................................................. 16

Figura 2.11 – Interacção JDBC e bases de dados [17]........................................................................................................ 20

Figura 2.12 – Exemplo de uma ligação JDBC ..................................................................................................................... 21

Figura 2.13 – Comunicação AMF entre um cliente Flex e um servidor PHP, com conversão automática dos tipos de dados

[19] ................................................................................................................................................................................. 22

Figura 3.1 – Tecnologias web ordenadas de acordo com a quantidade de processamento do lado do cliente e servidor ... 25

Figura 3.2 – Interacção síncrona com o servidor [25] ....................................................................................................... 25

Figura 3.3 – Comunicação assíncrona [25] ....................................................................................................................... 26

Figura 3.4 – Exemplo da linguagem MXML, onde se pode verificar a descrição de vários componentes ordenados

hierarquicamente............................................................................................................................................................ 29

Figura 3.5 – Funcionamento das aplicações flex num browser. Comunicação com outros sistemas [34] ............................ 30

Figura 3.6 – The New York Times Reader – http://timesreader.nytimes.com/timesreader/index.html .............................. 30

Figura 3.7 – Hard Rock Café Memorabilia - http://memorabilia.hardrock.com/ ................................................................ 32

Figura 3.8 – Plataforma JavaFX ........................................................................................................................................ 33

Figura 3.9 – My TV Schedule - http://javafx.com/samples/MyTVSchedule/index.html ...................................................... 33

Figura 3.10 – Modelo de uma aplicação Ajax [25] ............................................................................................................ 37

Figura 3.11 – Página em HTML5, com os novos elementos de semântica e funcionalidades CSS3 [39] .............................. 38

Figura 4.1 – Opções consideradas para a Arquitectura do sistema ................................................................................... 40

Figura 4.2 – Arquitectura da aplicação simplificada .......................................................................................................... 41

Figura 4.3 – Exemplo da inicialização de um mapa em JavaScript usando o Google Maps [43] .......................................... 43

Figura 4.4 – Exemplo da inicialização de um mapa em JavaScript usando o Yahoo! Maps [42] .......................................... 44

Figura 4.5 – Exemplo da inicialização de um mapa em JavaScript, usando o Bing Maps [44] ............................................. 44

Figura 4.6 – APIs REST dos três serviços de mapas ........................................................................................................... 45

Figura 4.7 – Os três serviços de mapas ............................................................................................................................. 45

Figura 4.8 – Arquitectura da aplicação Ajax...................................................................................................................... 46

Figura 4.9 – Diagrama de sequência da inicialização da aplicação Ajax ............................................................................. 47

Figura 4.10 – Função Ajax Cross-Browser ......................................................................................................................... 47


XIV

Figura 4.11 – Função de CallBack do evento onReadyStateChange ...................................................................................48

Figura 4.12 – Diagrama de sequência da funcionalidade de procura por nome de uma plataforma na aplicação AJAX ......49

Figura 4.13 – Event Handler para o clique no botão de pesquisa ......................................................................................49

Figura 4.14 – Código HTML, com as novas tags a verde ....................................................................................................50

Figura 4.15 – Aplicação de estudo Ajax sem CSS ...............................................................................................................51

Figura 4.16 – Código CSS parcial, apresentando algumas das novas funcionalidades do CSS3 ...........................................52

Figura 4.17 – Aplicação de estudo ajax com CSS ...............................................................................................................52

Figura 4.18 – Arquitectura da aplicação Flex ....................................................................................................................53

Figura 4.19 – Acesso do Flex ao servidor através do Remoting .........................................................................................53

Figura 4.20 – Excerto de Código MXML da aplicação Flex .................................................................................................54

Figura 4.21 – Excerto de Código AS da aplicação Flex .......................................................................................................56

Figura 4.22 – Aplicação de estudo Flex .............................................................................................................................56

Figura 4.23 – GUI em JavaFX que comunica com o MySQL através da JDBC, e usa o serviço de mapas estáticos da Google

maps ...............................................................................................................................................................................57

Figura 4.24 – Ligação à BD remota no JavaFX ...................................................................................................................57

Figura 4.25 – Objectos Stage e Scene ...............................................................................................................................58

Figura 4.26 – Excerto de código relativo à navegação entre plataformas ..........................................................................59

Figura 4.27 – Inclusão do mapa na aplicação JavaFX .........................................................................................................60

Figura 4.28 – Aplicação JavaFX com CSS ...........................................................................................................................60

Figura 4.29 – SEI e SIB do WebService SOAP em Java .......................................................................................................66

Figura 4.30 – Envelope SOAP DE UM pedido DE HORA E respectiva resposta ....................................................................66

Figura 4.31 – Código do WebService SOAP em PHP ..........................................................................................................67

Figura 4.32 – Diferentes Clientes SOAP para OS WebServices em Java e PHP ....................................................................68

Figura 4.33 – Pedido XHR a uma origem diferente usando o servidor como um proxy.......................................................68

Figura 4.34 – Cliente SOAP com o resultado da operação getTimeAsString .......................................................................69

Figura 4.35 – Criação de um cliente SOAP em PHP ...........................................................................................................69

Figura 4.36 – Implementação manual de cliente SOAP em Java ........................................................................................70

Figura 4.37 – Cliente SOAP em Java com geração de código suporte ao cliente ................................................................70

Figura 4.38 – Cliente SOAP em JavaFX ..............................................................................................................................70

Figura 4.39 – Código referente ao cliente SOAP Ajax ........................................................................................................71

Figura 4.40 – Interface do Web Service RESTfull em Java ..................................................................................................73

Figura 4.41 – Classe TimeServer .......................................................................................................................................73

Figura 4.42 – Código referente ao WebService REST em Php ............................................................................................74

Figura 4.43 – Resposta dos WebServices REST em XML ....................................................................................................75

Figura 4.44 – Cliente REST PHP. Pedido da data e hora como uma string ..........................................................................76

Figura 4.45 – Análise do documento XML em Java através da API DOM ............................................................................76

Figura 4.46 – Connexão HTTP e análise XML no cliente JavaFX .........................................................................................77

Figura 4.47 – Conexão HTTPe análise XML no cliente Ajax ................................................................................................78


XV

Figura 4.48 - Cliente Flex em comunicação com os quatro WebServices em simultâneo ................................................... 78

Figura 4.49 – Uso dos métodos de uma classe PHP como operações de um serviço SOAP ................................................ 81

Figura 5.1 – Arquitectura da aplicação ............................................................................................................................. 83

Figura 5.2 – Diagrama relacional da Base de Dados do protótipo ..................................................................................... 84

Figura 5.3 – Triggers utilizados para a actualização das plataformas/sensores e histórico dos sensores ............................ 86

Figura 5.4 – Diagrama das classes usadas no servidor PHP ............................................................................................... 87

Figura 5.5 – Código referente à Operação GetPlatforms .................................................................................................. 88

Figura 5.6 – Query sem filtragem prévia .......................................................................................................................... 89

Figura 5.7 – Código referente à operação GetPlatByName ............................................................................................... 89

Figura 5.8 – Salting .......................................................................................................................................................... 90

Figura 5.9 – Código referente à operação validateLogin ................................................................................................... 91

Figura 5.10 – Transacção na operação GetUpdatedPlatforms........................................................................................... 92

Figura 5.11 – Diagrama UML de casos de uso da interface ............................................................................................... 93

Figura 5.12 – Diagrama UML máquina de estados ............................................................................................................ 94

Figura 5.13 – loginState que corresponde ao ecrã de login da interface ........................................................................... 95

Figura 5.14 – Diagrama UML de sequência para o loginState ........................................................................................... 96

Figura 5.15 – Estado platview com as duas vistas gerais de monitorização – a tabela e o mapa ..................................... 97

Figura 5.16 – Diagrama UML de sequência ralativo à inicialização do mapa, colocação das plataformas no mapa e

mudança do tipo de mapa ............................................................................................................................................... 98

Figura 5.17 – Classe MarkersFactory ................................................................................................................................ 99

Figura 5.18 – Diagrama UML de sequência relativo ao aumento/diminuição da visto do mapa ....................................... 100

Figura 5.19 – Estado platDetails com a plataforma do Porto selecionada e respectivos atributos no formulário. A vista

de mapa apresenta todas as plataformas do mesmo grupo ........................................................................................... 101

Figura 5.20 – Diagrama UML de sequência relativo ao clique numa plataforma na tabela .............................................. 101

Figura 5.21 – O Estado searchState apenas apresenta uma plataforma tanto na tabela como no mapa .......................... 102

Figura 5.22 – Excerto de código MXML referente à searchDataGrid e searchDetailsForm ............................................ 103

Figura 5.23 – Diagrama UML de sequência referente à procura de uma plataforma por nome ....................................... 104

Figura 5.24 – Gráfico que apresenta os valores do sensor Pressure1 da plataforma LisbonPlat referentes ao dia actual. O

eixo dos YY representam os valores do sensor, e o eixo dos XX a escala de tempo. ........................................................ 105

Figura 5.25 – Definição de um LineChart em MXML ................................................................................................... 106

Figura 5.26 – Diagrama UML de sequência relativo à visulização do histórico de um sensor ........................................... 107

Figura 5.27 – Função callback da conclusão da operação GetSensorDayHistoric ............................................................. 108

Figura 5.28 – Diagrama UML de sequência referente à actualização das plataformas ..................................................... 110

Figura 5.29 – Diagrama UML de sequência referente à actualização dos sensores .......................................................... 112

Figura 5.30 – Classe SensorDataGrid .............................................................................................................................. 113

Figura 5.31 – Aplicação de teste que fornece dados fictícios à BD .................................................................................. 114

Figura 5.32 – Classe SensorSimulator ............................................................................................................................. 115

Figura 5.33 – Função updateRandomData() ................................................................................................................... 115


XVI


XVII

Índice de Tabelas

Tabela 1 – Métodos HTTP mais comuns ............................................................................................................................. 9

Tabela 2 – CategoRIA gerais do código de estado de uma resposta .................................................................................... 9

Tabela 3 – Códigos de estado mais comuns ....................................................................................................................... 9

Tabela 4 – Elementos de dados do REST .......................................................................................................................... 17

Tabela 5 – Correspondência entre os Verbos HTTP e as operações CRUD ......................................................................... 19

Tabela 6 – Eventos progressivos do objecto XmlHttpRequest nível 2 ................................................................................ 39

Tabela 7 – APIs disponibilizadas pelos serviços de mapas em estudo ............................................................................... 42

Tabela 8 – Comparação entre as três plataformas em estudo segundo os critérios definidos ........................................... 61

Tabela 9 – Mapeamento das URI e Verbos HTTP .............................................................................................................. 72

Tabela 10 – Abordagens de comunicação implementadas e testadas nas experiências ao longo da dissertação................ 80


XIX

Acrónimos

AJAX – Asynchronous JavaScript and XML

AMF – Action Message Format

API – Application Programming Interface

AS – ActionScript

BD – Base de Dados

CSS – Cascading Style Sheets

COM – Component Object Model

CORBA – Common Object Request Broker Architecture

CRUD – Create, Read, Update and Delete

CURL – Client URL Request Library

DHTML – Dynamic Hypertext Markup Language

DNS – Domain Name System

DSL – Domain Specific Language

DOM – Document Object Model

GUI – Graphical User Interface

HTML – Hypertext Markup Language

HTTP – Hypertext Transport Protocol

IDE – Integrated Development Environment

IP – Internet Protocol

JAXB – Java Architecture for XML Binding

JAXP – Java API for XML Processing

JAX-RS – Java API for RESTful Web Services

JAX-WS – Java API for XML Web Services

JDBC – Java Database Connectivity

JVM – Java Virtual Machine

JRE – Java Runtime Environment

JS - JavaScript


XX

JSON – JavaScript Object Notation

ODBC – Open Database Connectivity

PHP – Hypertext Preprocessor

REST – Representational State Transfer

RDBMS – Relational Database Manage System

RIA – Rich Internet Application

RMI – Remote Method Invocation

RPC – Remote Procedure Call

RTMP – Real Time Messaging Protocol

SAX – Simple API for XML

SEI – Service Endpoint Interface

SDK – Software Development Kit

SIB – Service Implementation Bean

SQL – Structured Query Language

SVG – Scalable Vector Graphics

SO – Sistema Operativo

SOP – Same Origin Policy

TCP – Transmission Control Protocol

TCP/IP – Transmission Control Protocol/Internet-Protocol

UI – User Interface

UML – Unified Modeling Language

URL – Uniform Resource Locator

URN – Uniform Resource Name

URI – Uniform Resource Identifier

WADL – Web Applications Description Language

WSDL – Web Service Description Language

WHATWG - Web Hypertext Application Working Group

WWW – World Wide Web

XAML – eXtensible Application Markup Language


XXI

XHTML – eXtensible Hypertext Markup Language

XML – eXtensible Markup Language

XSS – Cross-site scripting

YAML – YAML Ain’t Markup Language

YUI – Yahoo! User Interface


1

1 Introdução

Este trabalho tem como objectivo final o desenvolvimento de uma aplicação de monitorização disponível

através da web, de plataformas marítimas que produzem energia eléctrica através do movimento das ondas do mar. A

geração de energia a partir da ondulação marítima faz-se através da instalação de plataformas, que formam grupos

geograficamente espalhados por zonas próximas da costa. Estas plataformas estão presas por um cabo e são dotadas

de um sistema electromecânico cuja monitorização é necessário fazer. No essencial, a aplicação deve mostrar a

localização geográfica das plataformas, i.e., apresentar as plataformas num mapa, e permitir o acesso rápido e fácil

aos estados mais problemáticos. Outros requisitos da aplicação incluem a apresentação das plataformas juntamente

com os seus atributos mais importantes (e.g., estado global da plataforma) e, se solicitado pelo utilizador, de todos os

atributos, a apresentação do estado de cada sensor de cada plataforma, e permitir a procura de plataforma por nome.

A interface deve ser sofisticada e deve proporcionar a visualização rápida e clara das informações mais importantes.

Ao mesmo tempo deve contribuir para a redução do número de comunicações com o servidor, uma vez que se

pretende minimizar o tráfego de rede.

1.1 Enquadramento

O crescimento global da conectividade à internet e do acesso a dispositivos computacionais e de comunicação

tornaram a World Wide Web (WWW) num continente sem fronteiras [1]. Qualquer pessoa com um computador e

ligação à internet pode ter acesso a um conjunto infindável de conteúdos e participar activamente na comunidade

Web. A Web 2.0 é composta por aplicações que vão de encontro às necessidades exigentes dos utilizadores,

claramente alterando a forma como a internet é utilizada. Redes sociais, blogs, e-commerce e motores de busca, são

apenas alguns exemplos de aplicações que exigem um grau elevado de interactividade e usabilidade por parte do

utilizador. Uma abordagem thin-client, onde o cliente se limita a apresentar dados provenientes do servidor que por

sua vez faz todo o processamento, é uma opção que não cumpre os requisitos impostos às aplicações web modernas,

nem tão pouco as exigências do utilizador.

Existem várias tecnologias que fornecem ao utilizador interfaces ricas e que proporcionam uma boa

experiência, sem as limitações das aplicações web mais antigas [1]. As RIA permitem o desenvolvimento de aplicações

web com interfaces sofisticadas, processamento do lado do cliente e comunicação assíncrona, muito diferentes dos

websites estáticos. Estas aplicações são muito semelhantes às aplicações desktop, e ao mesmo tempo são distribuídas.

No que diz respeito à distribuição, a arquitectura cliente-servidor é dominante e existem tecnologias e abordagens

que simplificam a conexão a fontes de informação alojadas em servidores web, como é o caso dos Web Services. Estes

promovem a interoperabilidade entre plataformas, sistemas operativos e linguagens diferentes, o que resulta na

propagação, reutilização e interoperação entre os conteúdos Web. No lado do servidor, linguagens como o PHP e o

Java, facilitam a construção de Web Services e o acesso a BDs.


2

1.2 Motivação

Pela sua natureza distribuída, as aplicações web actuais, como é o caso da aplicação a desenvolver, são

constituídas por vários componentes e envolvem o acesso a variados recursos e serviços. Isto faz com que a sua

complexidade aumente, e portanto, é importante encontrar uma boa arquitectura para a aplicação1. Para tal é

necessário fazer um estudo prévio das opções tecnológicas possíveis, e desenhar a arquitectura tendo em conta os

requisitos funcionais e não-funcionais.

Devido ao rápido crescimento e adopção das RIA, existem inúmeras tecnologias ligadas ao desenvolvimento

deste tipo de aplicações. Isto diz respeito não só ao cliente (GUI) propriamente dito, mas também a todas as

tecnologias web envolventes (e.g., Web Services). Portanto, para além da importância arquitectural é também

interessante fazer um estudo comparativo entre algumas das tecnologias mais influentes. Naturalmente, cada uma

possui vantagens e desvantagens distintas, mas o estudo deve centrar-se também na combinação entre essas

tecnologias e analisar as vantagens e desvantagens das combinações possíveis, tendo em conta os requisitos da

aplicação.

Assim sendo, o objectivo intermédio deste trabalho consiste em fazer um estudo comparativo das

tecnologias mais importantes para cada um dos componentes da aplicação. Tendo em conta os requisitos mais gerais

impostos à aplicação, como por exemplo, proporcionar a localização geográfica das plataformas sobre um mapa, o

sistema de monitorização terá como estrutura base os componentes representados na Figura 1.1:

• Interface web proporcionado pela parte cliente da RIA;

• Geolocalização das plataformas baseado num serviço de mapas de acesso livre;

• Servidor de BD para armazenar o estado das plataformas;

• Recepção dos dados das plataformas pela internet.

A comunicação das plataformas com o sistema, não é um problema abordado neste trabalho, mas esta será certamente

feita através da internet e à partida por unidades em zonas costeiras próximo das plataformas.

1.3 Requisitos da aplicação

Pretende-se que a aplicação seja facilmente acessível e minimize os requisitos sobre a plataforma cliente,

idealmente não requerendo a instalação de qualquer software e sendo compatível com todos os computadores

pessoais actuais (i.e., sistema operativo e browser). O serviço fornecido pela aplicação deve permitir monitorizar o

estado das plataformas, e portanto, deve indicar ao utilizador a sua localização geográfica num mapa e o estado

funcional mais ou menos detalhado conforme pedido, entre outras características.

1 Actualmente, devido à complexidade dos sistemas de software, existe a necessidade de partir a implementação em componentes independentes

que comunicam e interagem entre si para completar uma determinada tarefa [11].


3

FIGURA 1.1 – ESTRUTURA BASE DO SISTEMA DE MONITORIZAÇÃO

Para o cliente web pretende-se uma interface fácil de utilizar, intuitiva, interactiva, e que permita a

manipulação dos dados obtidos pelo servidor. Apesar de a aplicação ser de monitorização, não deverá ser um simples

cliente thin, pois tem que possuir uma interface evoluída, que proporcione uma boa experiência ao utilizador e que

reduza o tráfego com o servidor, uma vez que se pretende que tenha características de tempo-real. Para que a

monitorização seja eficaz, a aplicação requer uma ligação regular com o servidor, nomeadamente para efectuar

pedidos da informação geral das plataformas, da informação mais detalhada de cada plataforma (e.g., estado dos

sensores), e para actualizar regularmente o estado das plataformas. Os dados transferidos nestes pedidos são

essencialmente texto (e.g., atributos das plataformas, e leituras dos sensores), no entanto, o número de plataformas

pode ser elevado e cada plataforma pode ter muitos sensores, o que significa que a actualização dos dados na

interface não pode ser feita de qualquer forma, ou seja, é importante minimizar o tráfego de rede. Assim, deverá ser

possível actualizar esses dados de forma periódica ou em tempo-real (conforme definido pelo administrador) e reduzir

a transferência redundante de dados, e.g., transferir apenas os dados que sofreram alterações.

A carga de processamento no servidor respeitante às respostas dos pedidos dos clientes será relativamente

baixa, uma vez que se prevê um número reduzido de utilizadores da aplicação. A manipulação e processamento de

dados deverão ser efectuados, sempre que possível, do lado do cliente. Por exemplo, o cliente pede as plataformas ao

servidor, e a partir daí pode proceder à colocação das plataformas no mapa e na tabela, de acordo com a informação

obtida (e.g., coordenadas). Assim, a tarefa do servidor deve resumir-se principalmente à consulta da BD e ao

input/output de dados. No que diz respeito à comunicação com as plataformas, o processamento deverá ser mais

elevado uma vez que haverá vários nós clientes geograficamente próximos das plataformas a enviar os dados

daquelas para o servidor. Apesar de a comunicação entre as plataformas e a BD não ser um problema abordado neste

trabalho, as trocas de dados entre o servidor e a aplicação de monitorização devem também ser minimizadas de

modo a deixar largura de banda disponível para a recepção de dados das plataformas.


4

Os requisitos funcionais principais da aplicação são os seguintes:

• Apresentar as plataformas num mapa;

• Permitir a navegação rápida para a localização do grupo da plataforma seleccionada (e.g., seleccionando o

nome de uma plataforma na tabela, a vista do mapa ajusta-se automaticamente para mostrar todas as

plataformas pertencentes ao grupo da plataforma seleccionada);

• Apresentar uma tabela com a vista geral da informação, incluindo o estado global das plataformas e

permitindo a ordenação por (gravidade do) estado;

• Apresentar as informações detalhadas de uma plataforma quando seleccionada;

• Procurar plataformas por nome;

• Permitir a consulta do histórico de dados de um determinado sensor de uma plataforma;

• Actualizar as plataformas e respectivos sensores com uma periocidade definida pelo administrador do

sistema;

A aplicação possui também os requisitos não funcionais listados de seguida:

• Conexão a uma BD remota;

• Ser independente do número e tipo de sensores;

• Suportar vários grupos de plataformas de acordo com a sua localização geográfica;

• Suportar perfis de utilizador com diferentes permissões;

• Minimizar o número de comunicações entre o cliente e servidor, de modo a reduzir o trafego de rede;

• Ser facilmente acessível e minimizar os requisitos sobre a plataforma cliente;

• Interface de fácil utilização, intuitiva e interactiva.

1.4 Organização da tese

Como se pretende avaliar várias alternativas para a implementação dos diferentes componentes do sistema,

de entre as tecnologias actualmente mais relevantes em termos de mercado foram consideradas: Ajax (HTML5),

JavaFX e Flex para a implementação da interface; serviços de informação geográfica Google Maps, Yahoo! Maps e Bing

Maps; e diferentes tecnologias de comunicação como HTTP, Web Services (SOAP, REST) e AMF. Assim, o trabalho que

serviu de base a esta dissertação incluiu as seguintes tarefas:

• Desenho, instalação e configuração da Base de Dados;

• Desenvolvimento de aplicações cliente em JavaFX, Flex e Ajax com as funcionalidades básicas

pretendidas;

• Implementação da ligação a serviços de informação geográfica gratuitos como os da Google, Yahoo! e

Bing, a partir dos diferentes clientes possíveis (naturalmente nem todos disponibilizam Application

Programing Interfaces (APIs) Java, Flex e Ajax);


5

• Integração da ligação à BD em cada uma das aplicações anteriores, experimentando tecnologias como

HTTP, Web Services (SOAP e REST) e AMF;

• Implementação do protótipo do sistema;

• Implementação de uma aplicação de teste que forneça dados fictícios à BD e permita demonstrar o

protótipo.

Nesta dissertação começa-se por abordar, nos capítulos 2 e 3, as tecnologias importantes para o desenrolar

deste trabalho. No capítulo 2, discutem-se tecnologias de comunicação web como o HTTP, Web Services, JDBC e AMF.

No capítulo 3, descreve-se o conceito de Rich Internet Application, onde se discute a sua definição alargada e quais as

tecnologias que engloba, terminando com a apresentação de várias plataformas que permitem o desenvolvimento de

RIA.

Depois dos conceitos teóricos vem a parte experimental desta dissertação, no capítulo 4, que está dividido

em duas partes. Na primeira, analisa-se a utilização dos vários serviços de mapas, a implementação de GUIs básicos

em Ajax, Flex e JavaFX, e comparam-se as várias alternativas. Na segunda parte, descrevem-se as várias experiências

realizadas sobre a comunicação cliente-servidor, concretamente Web Services SOAP e REST, concluindo com a análise

comparativa das alternativas.

No capítulo 5 apresenta-se a arquitectura da aplicação e descreve-se a implementação do protótipo da

aplicação e do simulador. A descrição do protótipo está dividida em duas partes: o lado do servidor e o lado do

cliente. No servidor, descreve-se a construção da Base de Dados, e as operações que este facilita ao cliente. No

cliente, é feita numa primeira fase a modelação da GUI, incluindo diagramas UML de casos de uso e de máquinas de

estado, e posteriormente são descritas todas as funcionalidades relevantes da aplicação. Finalmente, este capítulo

termina com a descrição de uma aplicação que simula as partes de envio de dados das plataformas, e que foi criada

para testar o protótipo da aplicação de monitorização.

O documento finaliza com o capítulo 6, que inclui a análise de resultados, conclusões e o trabalho futuro.


7

2 Tecnologias de comunicação web

Neste capítulo descrevem-se várias tecnologias utilizadas na comunicação entre cliente e servidor. Em termos

computacionais, um cliente é um programa que consome (utiliza) os serviços disponibilizados por um outro programa

chamado servidor, através de uma rede de computadores. Nesta arquitectura (cliente-servidor), o servidor partilha os

seus recursos com um ou mais clientes, que tipicamente efectuam pedidos de conteúdos, serviços ou funções ao

servidor. O servidor processa o pedido, constrói uma resposta e aguarda novo pedido. Esta é a arquitectura

maioritariamente utilizada por grande parte da computação em rede e protocolos mais importantes.

Começa-se por apresentar os conceitos básicos do protocolo HTTP, porque serve como base para outros tipos de

comunicação. Posteriormente aborda-se o conceito de Web Services, analisa-se a sua importância, bem como as

características dos dois principais tipos de Web Services que existem. Aqui não é feita uma comparação entre ambos,

mas apenas se apresenta as duas abordagens. Para finalizar, abordam-se sucintamente processos de comunicação entre

aplicações e sistemas de gestão de BD (e.g., ODBC, JDBC), e uma tecnologia mais específica mas igualmente importante

para este trabalho, o AMF.

O conteúdo deste capítulo é incluído nesta tese porque foi alvo de estudo durante a realização do trabalho, no

entanto o leitor familiarizado com as tecnologias referidas acima pode passar para o capítulo seguinte.

2.1 HTTP

O Hypertext Transport Protocol (HTTP) é um protocolo do nível da aplicação para sistemas de informação

distribuídos, colaborativos e hipermédia [2] usado pela WWW desde 1990. Milhares de ficheiros são transportados pela

internet todos os dias através do HTTP. Esta informação está disponível na Web e é armazenada em servidores web.

Tipicamente, o cliente (e.g., browser) efectua um pedido HTTP ao servidor web que por sua vez retorna uma resposta

(Figura 2.1): em caso de sucesso, contendo o conteúdo pedido juntamente com outras informações (tais como o

tamanho e tipo do objecto). Na Web, o objecto transportado é um recurso, ou seja, qualquer tipo de conteúdo, como

por exemplo, uma imagem, um ficheiro AVI, uma página HyperText Markup Language (HTML) ou um motor de busca da

internet.

FIGURA 2.1 – PEDIDO E RESPOSTA HTTP


8

Como existem milhares de recursos com diferentes formatos, o HTTP identifica cada um através de um formato

chamado MIME type [3]. O Multipurpose Internet Mail Extensions (MIME) foi inicialmente desenvolvido para resolver

problemas relacionados com a troca de mensagens entre sistemas de correio electrónico diferentes [3]. Devido ao seu

sucesso, o HTTP adoptou este método para identificar o tipo de recurso a ser transportado. Deste modo, o servidor

anexa um MIME type que é transportado juntamente com a resposta do servidor. Um MIME type é um rótulo de texto,

representado por um tipo de objecto primário e respectivo subtipo separados por uma barra, como por exemplo [3]:

• Documento HTML identificado por text/html;

• Documento de texto identificado por text/plain;

• Imagem JPEG identificada por image/jpeg;

• Imagem GIF identificada por image/gif;

• Ficheiro QuickTime identificado por video/quicktime;

• Ficheiro de apresentação PowerPoint identificado por application/vnd.ms-powerpoint.

Cada recurso tem um nome dado pela Uniform Resource identifier (URI). Uma URI identifica um recurso na Web. A

forma mais comum de uma URI é uma Uniform Resource Locator (URL) que descreve a localização específica de um

recurso num determinado servidor [3]. Uma URL mostra precisamente onde e como aceder a um determinado recurso

(e.g., http://www.ericclapton.com/photos/budokan-1). A primeira parte de uma URL (scheme) define o protocolo usado

para aceder ao recurso, que é normalmente o HTTP. A segunda parte refere-se ao endereço do servidor na internet

(e.g., www.ericclapton.com) e o restante identifica o recurso no servidor (e.g., /photos/budokan-1).

Como referido, um cliente pode enviar um pedido HTTP e receber uma resposta. Nesta transacção são

transferidas mensagens HTTP (Figura 2.2). Uma mensagem HTTP é constituída por uma sequência de três partes [3]:

• Linha de começo: primeira linha da mensagem, que indica uma acção no caso de ser um pedido, ou o

estado do resultado no caso de ser uma resposta;

• Cabeçalho: conjunto (possivelmente vazio) de linhas com pares “nome:valor”, terminado com uma linha

em branco;

• Corpo: campo opcional, que pode conter qualquer tipo de dados, texto e/ou binário (e.g., imagens, vídeos,

aplicações de software, etc.).

FIGURA 2.2 – MENSAGEM HTTP

http://www.ericclapton.com/photos/budokan-1

http://www.ericclapton.com/


9

Cada pedido HTTP possui na primeira linha um método que indica ao servidor a acção a tomar (e.g., apagar um ficheiro).

A Tabela 1 apresenta os métodos HTTP mais comuns. Por sua vez, a mensagem de resposta contém, também na

primeira linha, um código numérico de três dígitos que indica o estado do pedido. Neste código o primeiro dos três

dígitos identifica uma categoria geral da resposta (Tabela 2). Juntamente com esse código é incluída uma pequena frase

descritiva para facilitar a sua leitura (Tabela 3).

TABELA 1 – MÉTODOS HTTP MAIS COMUNS

Método Descrição

GET Transferir um recurso do servidor para o cliente

PUT Armazenar dados fornecidos pelo cliente num recurso do servidor (e.g., um ficheiro de texto, imagem, etc.)

DELETE Apagar um recurso do servidor

POST Enviar dados para uma aplicação servidora

HEADER Enviar apenas o cabeçalho

TABELA 2 – CATEGORIA GERAIS DO CÓDIGO DE ESTADO DE UMA RESPOSTA

Código Categoria geral

1xx Messagem informativa

2xx Mensagem de sucesso

3xx Redireciona o cliente para outra URL

4xx Erro no lado do cliente

5xx Erro no lado do servidor

TABELA 3 – CÓDIGOS DE ESTADO MAIS COMUNS

Código Frase Descrição

200 Ok Pedido realizado correctamente

201 Created Para pedidos que criam objectos no servidor (e.g., PUT, POST). O corpo deve conter as URLs para identificar o recurso criado.

302 Found Indica que a URL foi movida. O cliente deve usar a URL retornada no cabeçalho para ter acesso ao recurso temporariamente

400 Bad Request Indica ao cliente que o pedido não foi bem formado

401 Unauthorized Retornado juntamente com cabeçalhos apropriados que indicam ao cliente que deve autenticar-se para ter acesso ao recurso

404 Not Found Usado para indicar que o servidor não encontrou a URL


10

A Figura 2.3 exemplifica uma transacação HTTP. O cliente envia um pedido GET do recurso que o cliente

pretende obter (/tools.html). Ainda na primeira linha é também indicada a versão HTTP (1.0 neste caso). Como é normal

no método GET, o corpo da mensagem está vazio, uma vez que não são enviados dados para o servidor. O cabeçalho é

composto por diversas linhas facultativas, tais como o endereço do servidor para onde o pedido está a ser efectuado, os

tipos de dados esperados e as línguas em que o servidor pode responder ao cliente. Por sua vez o servidor envia uma

mensagem de resposta contendo na primeira linha a versão HTTP (1.0) e o código de estado (200) com o respectivo

texto descritivo (Ok). O cabeçalho da resposta indica entre outros, o tipo e o tamanho do corpo da mensagem HTTP.

Neste caso, o corpo é um documento HTML.

FIGURA 2.3 – EXEMPLO DE UMA TRANSACÇÃO HTTP GET [3]

O HTTP é um protocolo da camada da aplicação (Figura 2.4) e portanto não se preocupa com os detalhes da

comunicação [3], função que é fornecida pelo Transmission Control Protocol/Internet Protocol (TCP/IP). Este é um

protocolo fiável que garante que a informação não chega danificada mesmo quando provém do outro lado do mundo

[3]. O HTTP utiliza o TCP para transportar mensagens, que por sua vez utiliza o IP. O TCP/IP é um conjunto de camadas

protocolares de rede que escondem os detalhes e peculiaridades das redes e hardware individuais e garantem a troca

de mensagens de forma ordenada e sem erros, permitindo computadores de qualquer tipo falarem de forma fiável [3].

Para um cliente HTTP poder enviar uma mensagem a um servidor é necessário estabelecer uma conexão TCP/IP,

especificando o endereço de IP do servidor e o número da porta TCP associada ao programa servidor. O número da

porta é opcional, pois existem números atribuídos a protocolos normalizados [4].


11

HTTP

Hardware da rede física

TCP

IP

Interface especifica da ligação de rede

Aplicação

Transporte

Rede

Ligação de dados

Física

FIGURA 2.4 – PILHA PROTOCOLAR DO HTTP

O endereço e a porta são especificados na URL. Na realidade, o endereço de um determinado servidor (e.g.,

www.amazon.co.uk) é convertido num IP através do Domain Name System (DNS), conforme ilustrado na Figura 2.5.

Após o estabelecimento da ligação TCP/IP, pode começar a transacção das mensagens HTTP. A conexão é tipicamente

terminada pelo cliente após a leitura da resposta do servidor. No entanto, o HTTP 1.1 (e versões melhoradas do HTTP

1.0 através da inclusão da linha Connection: Keep-Alive no cabeçalho do pedido [3]) suporta conexões persistentes, i.e.,

a conexão TCP mantém-se aberta após o fim de uma transacção HTTP para que possa ser reutilizada em futuros

pedidos. Isto é particularmente interessante quando se pretende efectuar vários pedidos ao mesmo servidor (e.g.,

imagens de um website), pois não é necessário iniciar uma nova conexão, evitando-se assim atrasos no estabelecimento

da ligação, o que resulta transferências mais rápidas.

FIGURA 2.5 – EXEMPLO DE UMA LIGAÇÃO TCP/IP

http://www.amazon.co.uk/


12

2.2 Web Services

Os Web Services são fundamentais para a integração de aplicações web, e daí, uma das tecnologias que tornam

a Web 2.0 uma possibilidade. A Web actual é composta por uma família heterogénea de sistemas e tecnologias [5], [6],

e portanto, a interoperabilidade é uma necessidade [6]. É aqui que reside a importância dos Web Services, no facto de

fornecerem a aplicações diferentes, de diferentes plataformas, linguagens ou Sistemas Operativos (SOs), um meio de

trocar a informação. O HTTP por si só é incapaz de viabilizar esta interoperabilidade, uma vez que não trata as eventuais

diferenças entre aplicações, relacionadas com o tipo de dados nativos. Por exemplo, o HTTP permite efectivamente a

comunicação entre uma aplicação cliente Java e uma aplicação servidora Hypertext Preprocessor (PHP), mas a última

pode não ser capaz de compreender a informação transferida. Em contraste, um Web Service é caracterizado pela

transparência de linguagem, ou seja, o cliente não tem que ser escrito na mesma linguagem que o servidor para poder

entender os dados transferidos. Num quadro onde o aumento do software escrito em linguagens distintas e a sua

distribuição numa vasta variedade de plataformas é notório e cada vez mais acentuado, os Web Services são de extrema

importância. De facto, é raro um sistema de software operar isoladamente [5]. Um sistema de software típico tem que

interagir com outros, que eventualmente residem em plataformas diferentes e são escritos em linguagens diferentes.

Um Web Service é uma aplicação cujos componentes podem ser distribuídos e executados em dispositivos

distintos [5]. Apesar de outras tecnologias como a Common Object Request Broker Architecture (CORBA), Remote

Method Invocation (RMI) e Component Object Model (COM) também abordarem este problema, os Web Services são

tipicamente baseados no protocolo HTTP para o transporte da informação, e na linguagem eXtensible Markup Language

(XML) para codificar e descodificar dados. Assim, desenvolver um sistema deste tipo é mais simples, pois ao contrário

das tecnologias referidas acima, a curva de aprendizagem é menor uma vez que se usam tecnologias normalizadas bem

conhecidas e com um elevado grau de maturidade. Por exemplo, um Web Service escrito em PHP pode ser consumido

por clientes Java, C# ou Flex. Esta interoperabilidade é conseguida através da arquitectura cliente-servidor, um

protocolo de comunicação normalizado (e.g., HTTP), um formato que permita tratar as diferenças nos tipos de dados

entre as linguagens do servidor e cliente, e possivelmente uma descrição do serviço. A tecnologia XML, que suporta a

troca e processamento de um documento estruturado, age como um intermediário [5] garantindo a transparência de

linguagem. Por exemplo, um determinado cliente pode enviar um documento XML no corpo de um pedido HTTP, que

por sua vez responde com um outro documento XML de onde o cliente pode extrair a informação solicitada.

Os Web Services podem ser divididos em dois grandes grupos [5]: serviços baseados em SOAP2 e serviços

baseados no estilo Representational State Transfer (REST). Basicamente, um Web Service do primeiro tipo, usa o SOAP

como protocolo de troca de mensagens, e portanto requer uma libraria específica que encapsula a troca de

documentos SOAP (escritos em XML) sobre HTTP entre o cliente e servidor, enquanto o segundo tipo é um estilo de

software que define vários princípios arquitecturais para o desenvolvimento de sistemas de hipermédia,

nomeadamente o uso de ferramentas normalizadas (e.g., HTTP, XML, JSON, etc.).

2 Originalmente SOAP era acrónimo de Simple Object Access Protocol. No entanto, desde a versão 1.2, versão avaliada neste documento, o SOAP

deixou de ser oficialmente um acrónimo.


13

2.2.1 SOAP-based Web Services

Os elementos de uma plataforma Web Services baseada em SOAP são os seguintes:

• SOAP; • Web Services Description Language (WSDL); • Universal Description Discovery and Integration (UDDI).

O primeiro é um protocolo de comunicação, independente da plataforma ou linguagem baseado em XML, que

permite a troca de dados sobre HTTP entre programas. Pode ser definido de uma forma simplista, como um protocolo

para aceder a um Web Service. Oficialmente este protocolo é descrito da seguinte forma [7]:

“O SOAP é um protocolo leve para trocar informação estruturada num ambiente distribuído e descentralizado.

O SOAP usa tecnologias XML para definir uma framework extensível de troca de mensagens, que proporciona uma

construção de mensagem que pode ser trocada através de uma variedade de protocolos numa camada inferior. A

framework foi desenhada para ser independente de qualquer modelo de programação em particular e de outras

implementações semânticas específicas.”

Uma mensagem SOAP é um documento XML constituído pelos seguintes elementos, com a estrutura e ordem

apresentadas na Figura 2.6:

• Envelope – identifica o documento XML como uma mensagem SOAP e agrega o restante conteúdo da mensagem;

• Cabeçalho (Header) – é opcional, e contém informações específicas de uma determinada aplicação (e.g., assinatura digital para autenticação, número de conta para pagamentos);

• Corpo (Body) – é obrigatório, pois contém os dados do pedido e da resposta; • Fault – indica possíveis erros e o estado da mensagem.

A Figura 2.7 exemplifica um documento em XML com o esqueleto de uma mensagem SOAP.

FIGURA 2.6 – CONSTITUIÇÃO DE UMA MENSAGEM SOAP

Tipicamente num Web Service SOAP, o cliente efectua uma Remote Procedure Call (RPC) através da invocação

de uma das operações do serviço e obtém uma resposta, formando um padrão pedido/resposta. Neste padrão são

trocados envelopes SOAP que permitem o serviço e o cliente serem programados em linguagens diferentes. Apesar de

existirem outros padrões de troca de mensagens (e.g., um cliente pode apenas enviar uma mensagem sem esperar por

uma resposta), este é o dominante.


14

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-env

soap:encodingStyle="http://www.w3.org/2001/12/s <soap:Header> ... </soap:Header> <soap:Body> ... <soap:Fault> ... </soap:Fault> </soap:Body> </soap:Envelope>

FIGURA 2.7 – ESQUELETO DE UMA MENSAGEM SOAP

Para exemplificar, repare-se no pedido HTTP da Figura 2.8 cujo corpo da mensagem contém uma mensagem

SOAP. Este pedido tem como objectivo solicitar a operação sayHello que apenas retorna a string “Hello”. É de realçar

que o método HTTP utilizado é o POST. À partida faria mais sentido utilizar o método GET, uma vez que se está a fazer

um pedido e não a introduzir nova informação no servidor, mas este método não possui um corpo para encapsular o

envelope SOAP. A seguir ao cabeçalho, que especifica entre outros, o tamanho da mensagem e o tipo (text/xml), vem o

corpo do pedido HTTP que contém o envelope SOAP. Por sua vez, o corpo do envelope SOAP contém a operação que o

cliente pretende invocar (sayHello). Repare-se que num Web Service SOAP, é necessário especificar o nome da

operação que se pretende invocar (RPC) no pedido.

POST /sayHelloSOAP HTTP/1.1Host: localhost:9876User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: pt-pt,pt;q=0.8,en;q=0.5,en-us;q=0.3Accept-Encoding: gzip, deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Referer: http://localhost/SoapClient-debug/SoapClient.swf/[[DYNAMIC]]/4Content-type: text/xml; charset=utf-8SOAPAction: ""Content-length: 285

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SOAP-ENV:Body> <tns:sayHello xmlns:tns="http://HelloSoap/"/>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

FIGURA 2.8 – PEDIDO HTTP CUJO CORPO CONTÉM UMA MENSAGEM SOAP

Do outro lado, o servidor web recebe o pedido HTTP e passa o corpo para o Web Service, que processa o envelope SOAP

e identifica a operação requisitada. O serviço invoca essa operação e retorna a resposta HTTP da Figura 2.9. Neste

exemplo, a resposta HTTP indica que o pedido foi processado correctamente. O corpo da mensagem HTTP contém

novamente um envelope SOAP, cujo corpo contém a resposta do Web Service: a string “Hello”.

Portanto, numa abordagem RPC, o cliente vê o servidor como um conjunto de operações que pode utilizar para

completar uma determinada tarefa [8].


15

HTTP/1.1 200 OKDate: Mon, 14 Nov 2011 23:46:11 GMTServer: Apache/2.2.17 (Win32) PHP/5.3.5X-Powered-By: PHP/5.3.5Content-Length: 308Content-Type: text/xml; charset=utf-8

<?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

<S:Body><ns2:sayHelloResponse xmlns:ns2="http://HelloSoap/">

<return>Hello</return></ns2:sayHelloResponse>

</S:Body></S:Envelope>

FIGURA 2.9 – RESPOSTA HTTP AO PEDIDO ANTERIOR

O documento WSDL é um documento XML que descreve as operações que um determinado Web Service expõe

[9]. Alguns serviços necessitam deste documento antes de serem publicados (e.g., PHP), outros possuem ferramentas

que o geram automaticamente (e.g., Java), mas este documento é particularmente útil para o desenvolvimento e

suporte do cliente. É através deste documento que os clientes descobrem os serviços e respectivas operações, e

portanto, ele constitui um contracto entre o serviço e os seus clientes [8]. O documento WSDL fornece informações

relevantes como, a URL do serviço, as suas operações, tipos de dados, e através da descrição das mensagens trocadas

pelo serviço e pelo cliente, o padrão do serviço, como por exemplo o padrão pedido/resposta [5]. Existem ferramentas

que permitem a geração de código de suporte para o cliente em várias linguagens através da inspecção deste

documento.

Um documento WSDL é dividido nas seguintes secções (Figura 2.10):

• types: opcional, fornece as definições dos tipos de dados segundo um sistema de tipos de dados, tais

como o XML Schema [5]. Esta secção contém ou importa um documento XML Schema Definiton (XSD). Se

não estiver preenchida, o serviço usa apenas dados de tipo simples, tais como, xsd:string, xsd:int, ou

xsd:float. O tipo dos dados é definido, por defeito, através do sistema de tipos XML Schema;

• message: define as mensagens que implementam o serviço, sendo que a ordem na qual estão definidas

indica o padrão de funcionamento do serviço. Por exemplo, no padrão pedido/resposta, esta secção

apresenta o pedido seguido da respectiva resposta;

• portType: agrupa as operações que o serviço oferece, com cada operação como uma ou mais mensagens.

As operações são apresentadas de forma abstracta, ou seja, sem detalhes de implementação;

• binding: apresenta os detalhes omitidos na secção precedente, e.g., o atributo transport indica o

protocolo que vai transportar as mensagens SOAP (tipicamente, HTTP) e o atributo style indica o estilo do

serviço. Existem dois estilos, o rpc e o document, sendo que o primeiro indica que as mensagens SOAP

contêm parâmetros e valores de retorno, nas mensagens de pedido e resposta respectivamente [5]. Por

sua vez, o segundo estilo indica que as mensagens SOAP contêm unicamente documentos XML [5]. No

caso da Figura 2.10, o estilo é rpc;

• service: Indica o endpoint, ou seja, a URL onde o serviço e as suas operações se encontram disponíveis.


16

A publicação de um serviço e respectivo WSDL pode ser facilitada através da UDDI, que é uma norma que

permite registar e tornar o serviço disponível aos clientes. Por exemplo, um utilizador pode procurar um número de

telefone usando Web Services SOAP que estejam disponíveis na internet [10]. O utilizador pode tipicamente visitar um

website UDDI e pesquisar os serviços disponíveis através de uma palavra-chave, como por exemplo “phone” [10]. Como

resultado uma lista de serviços pode ser apresentada ao utilizador. Este pode, através da inspecção do documento

WSDL, consumir o serviço e verificar se é o que pretende. A Amazon ou a Google são exemplos de empresas, que

disponibilizam Web Services baseados em SOAP através de documentos WSDL. No entanto, apesar de este documento

descrever toda a sintaxe do serviço, o mesmo não acontece com a semântica, ou seja, não tem informações explícitas

sobre o propósito do serviço. Cabe ao programador prever ou analisar a funcionalidade do serviço, o que se traduz

numa limitação do WSDL.

<?xml version="1.0" encoding="UTF-8"?><definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://soap/" xlmns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://soap/" name="SIBService"><types></types><message name="GetTime"></message><message name="GetTimeResponse">

<part name="return" type="xsd:string"></part></message><portType name="SEI">

<operation name="GetTime"><input message="tns:GetTime"></input><output message="tns:GetTimeResponse"></output>

</operation></portType><binding name="SIBPortBinding" type="tns:SEI">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"></soap:binding><operation name="GetTime">

<soap:operation soapAction=""></soap:operation><input>

<soap:body use="literal" namespace="http://soap"></soap:body></input><output>

<soap:body use="literal" namespace="http://soap"></soap:body></output>

</operation></binding><service name="SIBService">

<port name="SIBPort" binding="tns:SIBPortBinding"><soap:address location="http://localhost/TimeServerPhp/PhpTimeSoapServer.php"></soap:address>

</port></service>

</definitions>

FIGURA 2.10 – EXEMPLO DE UM DOCUMENTO WSDL

2.2.2 REST

O REST, termo criado por Roy T. Fielding em [11] e acrónimo de Representational State Transfer surge como

uma alternativa ao SOAP, e apesar de não ser um novo conceito, só recentemente se tornou mais popular. O REST não é

uma norma, mas sim uma abordagem para o desenvolvimento e fornecimento de serviços na internet, mais

concretamente um estilo de arquitectura de software para sistemas de hipermédia distribuídos [5], [8], [9], [12]. Um

exemplo óbvio de um sistema deste tipo é a internet. Aliás, a filosofia do REST deriva da Web [9] e sustenta que os


17

princípios e protocolos da arquitectura da internet existentes (e.g., HTTP e XML) são suficientes para criar Web Services.

Neste contexto, o XML-RPC é também uma abordagem em que os dois aspectos principais dizem respeito ao uso do

XML para codificar/descodificar dados garantindo a interoperabilidade entre plataformas, e ao uso do HTTP para o

transporte de informação [5]. No entanto, o XML-RPC (antecessor do SOAP [5]) é diferente do REST na medida em que é

uma abordagem RPC, e portanto o cliente vê o serviço como um conjunto de operações que pode invocar. O corpo de

um pedido HTTP nesta abordagem equivalente ao exemplo SOAP da Figura 2.8 seria por exemplo o seguinte:

<?xml version="1.0"?> <methodCall>

<methodName>sayHello</methodName> </methodCall>

O REST por outro lado assenta num conceito simples: A tudo o que pode ser manipulado através de um

conjunto limitado de operações, atribui-se uma URI, sendo que o cliente determina o método HTTP a utilizar. Isto

significa que um número reduzido de métodos (denominados de “verbos”) é aplicável a uma grande diversidade de

dados (denominados de “nomes”). Por exemplo, quando um browser, faz um pedido GET de uma URL, é retornada uma

página web, que pode conter imagens, áudio, texto, vídeos, etc. O importante é que cada um destes dados (“nomes”)

pode ser acedido através do mesmo método HTTP (“verbo”), e não um verbo para cada nome. Em contraste, um serviço

RPC tal como o SOAP ou o XML-RPC, enfatiza a diversidade de verbos, i.e., um nome apenas é acedido por um

determinado verbo.

A Tabela 4 apresenta os seis elementos de dados definidos por Roy T. Fielding em [11].

TABELA 4 – ELEMENTOS DE DADOS DO REST

Elemento de dados Exemplos na web actual

Recurso O alvo da hiperligação

Identificador de recurso URI; URL; Uniform Resource Name (URN)

Metadados de recurso Allow; Content-Location

Representação Documento HTML, imagem JPEG

Metadados de representação Content-Type; Content-Length;

Dados de controlo If-modified-since; Cache-Control

A definição de recurso na arquitectura REST, é exactamente a mesma que um recurso no contexto da Web.

Assim, um recurso é tudo o que possui uma identidade, que tenha um estado e/ou um determinado comportamento. O

estado pode ser variável ou estático, neste último caso o recurso possui sempre o mesmo valor/representação. Toda a

informação que pode ter um nome pode ser um recurso [11]: um documento, uma imagem, um determinado serviço,

entre outros. Uma URI identifica um recurso, que é observável através de uma representação, ou seja, os recursos não

são manipulados directamente. Uma representação é algo que se obtém do recurso no momento em que o cliente faz

um pedido, e portanto a representação deve capturar o estado actual do recurso [5]. Por exemplo, um GET de um


18

determinado recurso retorna a representação desse mesmo recurso no seu estado actual. É a representação (do

recurso) que é transferida na resposta do servidor para o cliente. Uma representação é portanto um conjunto de bytes

com a adição de metadados de representação. Os metadados de recurso e representação descrevem respectivamente o

recurso e a representação. Os metadados têm o formato de pares nome-valor, onde o nome corresponde a uma norma

que define a estrutura e semântica do valor. Uma resposta pode incluir metadados de representação e de recurso no

cabeçalho HTTP [13]. Por fim, os dados de controlo definem o propósito de uma mensagem, como por exemplo, a acção

requisitada no pedido, ou o significado da resposta [11]. É também usado para parametrizar os pedidos e para alterar o

comportamento normal de alguns componentes, nomeadamente o comportamento da cache [11] e a alteração do tipo

da representação (através da inclusão de dados de controlo no pedido/resposta no cabeçalho HTTP).

O servidor pode incluir nas representações transições possíveis para a aplicação, portanto o estado do cliente

também evolui. Isto significa que no REST existem dois conceitos diferentes de estado [8]. Um é o estado do recurso

que apenas está no servidor, e o outro é o estado da aplicação que apenas diz respeito ao cliente. Um cliente acede a

um recurso, por exemplo, introduzindo num browser a URL que o identifica (www.exemplo.pt). Na resposta é retornada

uma representação que pode incluir uma nova URL (www.exemplo.pt/menu). A aplicação cliente, pode então alterar o

seu estado acedendo ao recurso identificado por essa URL. Assim, a aplicação cliente, move-se de um determinado

estado para outro baseado na representação, daí o Representational State Transfer.

Uma aplicação RESTful, ou um Web Service RESTful, é um programa que segue rigorosamente os princípios e

restrições impostas pela arquitectura REST. Assim uma aplicação REST deve seguir os seguintes princípios arquitecturais

[14]:

• Acessibilidade: todos os recursos podem ser acedidos através de um único identificador.

• Restrição de operações: utilizar o conjunto finito de operações que o protocolo de distribuição do serviço

oferece, o que significa que esta arquitectura enfatiza a diversidade de nomes, e não de verbos como as

abordagens RPC.

• Serviço orientado à representação: Cada recurso é endereçável através de uma URI, sendo que existe

uma troca da representação de um recurso entre o cliente e o servidor. Um recurso pode ter várias

representações [8].

• Comunicação stateless: não existem dados das sessões iniciadas por um determinado cliente no servidor,

ou seja, o servidor não se “lembra” dos eventos ou interacções realizadas anteriormente.

Como já referido, a acessibilidade é conseguida atribuindo-se a cada recurso uma URI (e.g.,

Protocolo://host:porta/caminho?queryString. O “?” é opcional e indica uma query (e.g.,

Http://exemplo.pt/PinkFloydCds?CdName=TheDivisonBell). Como usualmente o protocolo utilizado pelo REST é o HTTP,

significa que os métodos normalmente utilizados são os fornecidos por este protocolo. A Tabela 5 apresenta a

correspondência entre os métodos HTTP e as operações Create, Read, Update, Delete (CRUD). É de realçar que estes

verbos devem ser utilizados de forma coerente relativamente à operação que se pretende efectuar. Por exemplo, se o

utilizador pretende efectuar uma operação de leitura, o verbo adequado seria obviamente o GET.

http://exemplo.pt/PinkFloydCds?CdName=TheDivisonBell


19

A complexidade na interacção cliente-servidor num serviço RESTful reside na troca de representações [14].

Estas são normalmente um documento XML [15], podendo ser também JavaScript Object Notation (JSON) ou YAML

Ain’t Markup Language (YAML), ou qualquer outro formato [14]. A representação é encapsulada no corpo da

mensagem HTTP, cujo formato é definido no cabeçalho através do MIME type. Desta forma, o cliente e o servidor

podem negociar o formato da mensagem a ser trocada [14], [16].

TABELA 5 – CORRESPONDÊNCIA ENTRE OS VERBOS HTTP E AS OPERAÇÕES CRUD

Verbo HTTP Operação CRUD Descrição do verbo

GET Ler um recurso Operação usada para obter dados do servidor. É uma operação idempotente e

segura3.

PUT Actualizar um

recurso

Coloca o corpo da mensagem HTTP numa localização especificada no cabeçalho

da mensagem HTTP. O cliente sabe qual o recurso que está a ser actualizado. É

uma operação idempotente e não segura.

DELETE Apagar um

recurso

É também uma operação idempotente, mas não segura.

POST Criar um recurso É a única operação não-idempotente e não segura, pois pode alterar o serviço.

2.3 Acesso a Bases de Dados

Hoje em dia a maioria das aplicações web requer, de alguma forma, o acesso a uma BD. Muitas linguagens

possuem APIs específicas para determinados sistemas de gestão de BD, que permitem a interface entre a linguagem e a

BD. Por exemplo, o PHP contém por defeito a extensão php_mysql que pode ser usada para aceder a uma BD MySQL, e

formatar os resultados de uma query Structured Query Language (SQL) para serem apresentados numa webpage. A BD

pode ser consultada programaticamente, através da criação de queries em forma de string que são passadas para o

MySQL, sendo que a resposta é retornada numa estrutura de dados que o PHP reconhece.

No entanto, como existem vários vendedores de sistemas de gestão de BD, cada um com a sua API, torna-se

difícil escrever código que suporte mais do que uma interface diferente. A Open DataBase Connectivity (ODBC) é uma

API independente de plataforma e de SO, que permite o acesso a diferentes sistemas de gestão de BD. Esta API, é uma

libraria constituída por um conjunto de funções que permitem a conexão, execução de queries e retribuição de

resultados, entre uma aplicação de software e uma BD para a qual esteja disponível um driver ODBC. O objectivo da

ODBC é precisamente tornar uma aplicação interoperável com qualquer sistema de gestão de BD. Isto é conseguido

3 Idempotente na medida em que o facto de se ler uma informação do servidor, não altera o conteúdo da informação. É segura pois a operação não

altera o estado do recurso no servidor.


20

através da inclusão de um driver exclusivo a uma BD, que se comporta como uma camada intermédia, e que traduz as

queries da aplicação em comandos que a BD compreenda, tipicamente comandos SQL.

Uma abordagem análoga, cuja relevância é intensificada pela notoriedade da linguagem Java, é a Java

DataBase Connectivity (JDBC). A JDBC é uma API definida pela Oracle, que proporciona às aplicações Java uma interface

única de acesso a BD independentes do vendedor [17], através de um driver JDBC e da SQL. Esta API define uma série de

interfaces4 que encapsulam o funcionamento da BD, nomeadamente, a execução de queries, processamento dos

resultados, entre outros. Cada vendedor de BD desenvolve o seu driver JDBC, que na realidade é um conjunto de classes

que implementam as interfaces referidas, para o respectivo sistema de BD em particular [17]. A Figura 2.11 apresenta a

interacção entre uma determinada aplicação e diferentes sistemas de BD através da JDBC, onde se pode verificar a

existência do objecto DriverManager, cuja função é a criação de uma nova ligação entre a aplicação e a Base de Dados.

FIGURA 2.11 – INTERACÇÃO JDBC E BASES DE DADOS [17]

A Figura 2.12 apresenta uma listagem de código que incorpora as principais funcionalidades da JDBC. Este

exemplo começa por carregar a classe do driver (neste caso o driver JDBC-ODBC). Depois de carregado, cria uma nova

conexão representada pelo objecto Connection através do driver carregado. A JDBC usa uma URL JDBC para identificar

e conectar a uma BD em particular. Geralmente estas têm a seguinte forma [17]:

Jdbc:driver:databasename

A URL é o primeiro parâmetro do método getConnection que necessita de mais dois parâmetros para estabelecer a

conexão e aceder à BD – um username e respectiva palavra-chave, que neste caso estão vazios (“ ”). Com a conexão

estabelecida pode-se criar uma expressão SQL representada pelo objecto Statement e executá-la, o que produz um

ResultSet que contém o resultado da query. Neste caso o programa apenas imprime os resultados, e liberta os

recursos que usou. No caso da ocorrência de um erro, é lançada uma excepção que apresenta uma mensagem com

informação relacionada com o erro.

4 Uma interface em Java possui um determinado conjunto de métodos cujo corpo está vazio, ou seja, não estão implementados. Neste caso, cabe ao

vendedor da base de dados, implementar esses métodos (driver).


21

import java.sql.*;

public class JDBCSample {

public static void main(java.lang.String[] args) { try { // This is where we load the driver Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch (ClassNotFoundException e) { System.out.println("Unable to load Driver Class"); return; } try { // All database access is within a try/catch block. Connect to database, // specifying particular database, username, and password Connection con = DriverManager.getConnection("jdbc:odbc:companydb", "", ""); // Create and execute an SQL Statement Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("SELECT FIRST_NAME FROM EMPLOYEES"); // Display the SQL Results while (rs.next()) { System.out.println(rs.getString("FIRST_NAME")); } // Make sure our database resources are released rs.close(); stmt.close(); con.close(); } catch (SQLException se) { // Inform user of any SQL errors System.out.println("SQL Exception: " + se.getMessage()); se.printStackTrace(System.out); } }}

FIGURA 2.12 – EXEMPLO DE UMA LIGAÇÃO JDBC

2.4 Remoting/AMF

O Action Message Format (AMF) é um formato binário da Adobe Systems usado para serializar objectos

ActionScript (AS) [18]. Além disso, este pode também ser usado na invocação assíncrona de serviços remotos [18], e

portanto, o AMF é geralmente usado para trocar informação entre uma aplicação da plataforma Adobe Flash e um

serviço remoto através de RPCs. Nas aplicações Flash/Flex, a troca de dados no formato AMF através da invocação de

pedidos, mais especificamente através do objecto RemoteObject, é também designada como Remoting. O

Remoting/AMF usa o protocolo Real Time Messaging Protocol (RTMP) que funciona sobre o TCP, e é usualmente

utilizado para o streaming de áudio e vídeo. Através do Remoting, uma aplicação Flash/Flex pode executar

directamente os métodos que estejam expostos no lado do servidor e receber a informação no seu modelo de dados

nativo, i.e., no modelo de dados AS.

Como é um formato binário, o AMF é mais eficiente em termos de utilização da largura de banda e carga de

processamento no lado do servidor do que outros formatos (e.g., XML, JSON) [19], [20]. O Remoting com AMF permite

enviar e receber objectos simples ou complexos, sem a necessidade de saber como estes são serializados, e de forma

comprimida sem que sejam de fácil leitura.


22

O AMF é um formato proprietário apenas suportado nativamente por clientes da plataforma Adobe Flash. Por

esta razão, é necessário instalar software adicional/específico que suporte o AMF no lado do servidor. No entanto, este

formato é suportado por inúmeras frameworks open-source para linguagens server-side, nomeadamente, PHP

(ZendAMF, AMFPHP), Java (BlazeDS), Ruby (RubyAMF) e Perl (AMF::Perl).

Tipicamente, uma framework que implemente o AMF trata da serialização entre o servidor e um cliente

Flash/Flex e mapeia uma classe da linguagem servidora para uma classe ActionScript e vice-versa, sendo que as

diferenças entre os tipos de dados das linguagens são tratadas automaticamente. A Figura 2.13 ilustra um diagrama

funcional da comunicação AMF, para o caso de um servidor PHP. Basicamente, o objecto RemoteObject é utilizado

como se fosse a classe remota MyClass para invocar dois métodos, o getData(), que retorna um array de objectos

MyVO e o saveData(), que recebe como parâmetro esse mesmo array. Repare-se que existe a troca de vários objectos

complexos, i.e., de várias instâncias da classe MyVO, e que cada uma é automaticamente convertida numa classe AS ou

PHP conforme aplicável.

FIGURA 2.13 – COMUNICAÇÃO AMF ENTRE UM CLIENTE FLEX E UM SERVIDOR PHP, COM CONVERSÃO AUTOMÁTICA DOS TIPOS DE DADOS [19]


23

3 Rich Internet Applications

Desde a sua concepção, a WWW está em constante evolução. No início, a interacção com o utilizador era

limitada à navegação entre páginas, apresentação de texto e inserção de dados em formulários, resultando numa

experiencia limitada e pouco atractiva. De facto, a tarefa inicial da web era pedir dados ao servidor e apresentá-los. Esta

abordagem thin-client era simples, sem instalação no cliente, mas limitava consideravelmente as potencialidades das

aplicações web [21]. Um cliente é geralmente classificado como:

• Fat Client: também conhecido como Thick Client ou Rich Client, requer uma ligação periódica ao servidor,

mas é pouco dependente do mesmo, sendo capaz de realizar um grande número de operações sem essa

ligação. A carga de processamento está deste modo sobre o cliente. Armazena dados localmente;

• Thin Client: o contrário do descrito acima, altamente dependente do servidor e normalmente apenas

apresenta ao utilizador dados provenientes do servidor, que executa todas as operações de processamento

e disponibiliza os seus recursos ao cliente. São limitados em termos de interactividade da user interface;

• Hybrid Client: modelo intermédio relativamente aos dois anteriormente descritos, podendo assemelhar-se

mais a um Thin Client ou a um Fat Client. Tanto o cliente como o servidor executam operações de

processamento. No entanto, depende do servidor para armazenar dados.

Hoje, as aplicações web possuem semelhanças óbvias às aplicações de desktop como referido em várias

literaturas, (e.g., [21], [22], [23], [24], [25]) proporcionando uma interacção com o utilizador sofisticada, processamento

do lado do cliente, comunicação assíncrona e conteúdos multimédia. Uma abordagem HTML pura, não é simplesmente

capaz de suportar as características requeridas pelas aplicações web modernas [21], especialmente no que diz respeito

à apresentação/interacção e à comunicação com o servidor (síncrona). Assim, de forma a ultrapassar as limitações

impostas pelas aplicações web tradicionais, surgiram as Rich Internet Applications.

O termo Rich Internet Application foi usado pela primeira vez em 2002, no documento, “Macromedia Flash MX

– A next-generation rich client”, publicado pela então Macromedia (comprada pela Adobe em 2005). É uma tecnologia

razoavelmente recente, cuja evolução foi impulsionada pelos seguintes factores [26]:

1. Banda larga:

a. Com o aparecimento da banda larga, o acesso à internet torna-se mais rápido e facilitado, possibilitando a

troca de conteúdos mais pesados, e rompendo a barreira imposta pelas conexões dial-up;

2. Poder de processamento:

a. A diferença de poder de processamento entre os computadores pessoais e os servidores diminuiu

significativamente;

b. O poder de processamento de um computador comum aumentou consideravelmente, disponibilizando

um ambiente ideal para as aplicações RIA;


24

3. Necessidade de uma resposta eficaz às acções do utilizador:

a. Hoje em dia, os utilizadores exigem interfaces funcionalmente mais sofisticadas, que apresentem a

informação rapidamente, e que respondam rapidamente às suas acções;

b. Os utilizadores preferem interfaces com aspecto graficamente mais sofisticadas e apelativas, moldando o

mercado nesse sentido;

4. Acção por parte das empresas líder:

a. As empresas de renome adoptaram as RIA pelos seus benefícios e para responder à procura do mercado;

b. Surgimento de várias plataformas de desenvolvimento (e.g., Macromedia Flex, AJAX, Microsoft Silverlight,

JavaFX), resultando num aumento significativo de aplicações deste tipo;

5. Web Services:

a. A emergência dos Web Services influenciou também como a camada de apresentação (interface com o

utilizador) deve ser desenvolvida. Permitem que a interface seja completamente independente das

camadas middleware, pois através dos Web Services, a interacção entre duas aplicações é possível mesmo

com diferenças nas linguagens de programação e plataformas. Isto permite a reutilização de aplicações

backend e o desenvolvimento independente do frontend.

Actualmente existe uma definição alargada das RIA, que usualmente se refere a uma família heterogénea de

soluções caracterizada pelo objectivo comum de adicionar novas funcionalidades às aplicações web tradicionais [21],

[24], resultando numa mistura de termos que pode ser confusa e ao mesmo tempo ambígua [21], [27]. Por aplicações

web tradicionais entendem-se aplicações com código de apresentação (HTML4 ou inferior) e conteúdo estático, que é

interpretado por um browser. Existem diversas tecnologias que fazem processamento do lado do cliente bem como do

lado do servidor, diferenciando-se principalmente pela quantidade de actividade presente em cada um deles [22]. As

RIA incluem várias destas tecnologias, e como tal, podem assemelhar-se mais a um cliente do tipo rich ou do tipo thin,

dependendo da quantidade de processamento em cada lado. A Figura 3.1 apresenta várias tecnologias ordenadas de

acordo com a quantidade de processamento do lado do cliente e servidor, relativamente às aplicações desktop e web

tradicionais.

Como ilustrado pela Figura 3.1, uma RIA pode ser definida como uma aplicação que se situa entre uma

aplicação desktop e uma página web típica. Do lado esquerdo estão as aplicações desktop (e.g., Adobe Acrobat Reader,

Microsoft Office e Windows Media Player) que usualmente necessitam de ser instaladas no computador, têm acesso a

mais recursos deste (e.g., sistema de ficheiros), oferecem uma interacção complexa com o utilizador e são graficamente

ricas. Do lado oposto, estão as páginas web tradicionais, que correm num browser e não necessitam de instalação. Estas

têm várias limitações principalmente no que diz respeito à interface com o utilizador, uma vez que estão limitadas às

capacidades do HTML. Por exemplo, a funcionalidade drag-and-drop, bastante comum em aplicações desktop não

existe numa abordagem HTML pura. Numa RIA thin-client o servidor faz a maioria do processamento e o cliente apenas

disponibiliza a GUI. No entanto a aplicação distingue-se de uma página web tradicional por executar pedidos

assíncronos ao servidor e ter uma interface que seja apelativa e graficamente rica.


25

FIGURA 3.1 – TECNOLOGIAS WEB ORDENADAS DE ACORDO COM A QUANTIDADE DE PROCESSAMENTO DO LADO DO CLIENTE E SERVIDOR

Normalmente, e independentemente da tecnologia usada no lado do servidor, a Web original era uma máquina

pedido-resposta com comunicação síncrona (o servidor apenas envia informação em resposta a um pedido do cliente

[21]), e daí, as aplicações funcionavam baseadas na arquitectura page-based, e.g., [27]:

• O utilizador abre a janela do browser (cliente), e pede uma página ao servidor;

• O servidor recebe e processa o pedido;

• O servidor envia a página para o browser;

• O browser apresenta a página ao utilizador no lugar do que estava a ser apresentado previamente;

Este conceito, ilustrado na Figura 3.2, era e continua a ser bem-sucedido para muitas aplicações, no entanto cria várias

limitações, como apresentado em [23], [24], [25] e [27], por exemplo: refrescamento total da página (mesmo se as

diferenças forem mínimas), interactividade com o utilizador limitada devido à constante interrupção após um pedido e

espera pelo processamento do lado do servidor, transferência de código redundante e consequente uso excessivo da

banda.

FIGURA 3.2 – INTERACÇÃO SÍNCRONA COM O SERVIDOR [25]


26

Pela combinação de várias definições, em [28] foi obtida uma definição bastante completa e generalizada:

“As Rich Internet Applications são aplicações web, que usam dados que podem ao mesmo tempo, ser

processados pelo servidor e pelo cliente. A troca de dados é feita de forma assíncrona, de modo a que o cliente

fique responsivo enquanto continua a recalcular ou a actualizar porções da interface. Do lado do cliente, as RIA

proporcionam uma aparência semelhante às aplicações desktop, (...)” sendo “(...) basicamente caracterizadas

por uma variedade de botões de controlo interactivos, pela possibilidade do uso on-/off-line da aplicação, e

pelo uso transparente do poder de processamento e da conexão de rede por parte do cliente/servidor.”

Portanto, as RIA combinam características das aplicações web e desktop, herdando vantagens de ambas [23],

[29], [30], nomeadamente interfaces gráficas mais ricas e eficientes com um grau elevado de interactividade (e.g.,

Streaming de áudio/vídeo, janelas múltiplas, drag-and-drop, temas, animações, etc.), e ao mesmo tempo, preservando

a habilidade de ser distribuída e acedida facilmente por um browser e uma conexão à internet. Esta combinação resulta

na melhoria de todos os elementos de uma aplicação web [21], [23], [31].

A melhoria da interface, além de ser uma das razões principais pelo aumento da popularidade das RIA,

proporciona aplicações de página única, contendo subpáginas, refrescamento parcial e apresentação progressiva da

página, e o carregamento independente e progressivo de elementos, i.e., a criação, apresentação, e actualização

dinâmica de elementos da página em runtime [21], [28], [32]. Por exemplo, no caso de uma aplicação que necessite de

consultar uma BD usando informação introduzida pelo utilizador, o cliente pode manipular, filtrar e validar a informação

antes de ser enviada para o servidor, evitando comunicações desnecessárias. Depois, pode usar a informação obtida

para actualizar uma determinada secção ou elemento da página sem que seja necessário o refrescamento total, e ao

mesmo tempo criar um novo elemento (sem comunicar com o servidor) que indique que os dados foram obtidos com

sucesso. Isto é possível devido à capacidade de receber/executar comandos assíncronos, através da definição de event

listeners e handlers (e.g., um pedido assíncrono pode ser iniciado através de um clique num botão). Os event listeners e

respectivos handlers são definidos no código comportamental, que é executado/interpretado pelo cliente, e são o

mecanismo adoptado pela linguagem de programação em que esse código é escrito, para a execução dos comandos

assíncronos. Na comunicação assíncrona (Figura 3.3), a transferência de determinados dados é efectuada e dividida em

vários pedidos, sendo que cada um deles transfere apenas a informação necessária.

FIGURA 3.3 – COMUNICAÇÃO ASSÍNCRONA [25]


27

Devido à natureza assíncrona do pedido, o cliente mantém-se responsivo, o que significa que o utilizador pode interagir

com a interface sem quaisquer interrupções. Além disso, a execução de um comando assíncrono não implica

necessariamente a comunicação com o servidor, uma vez que o cliente tem a capacidade de actualizar ou criar

elementos dinamicamente. A transferência de parte da computação do servidor para o cliente resulta numa maior

interactividade da aplicação, i.e., a aplicação reage, ou responde mais rapidamente às acções do utilizador, e na redução

do trafego de rede.

Além das características principais referidas ao longo deste capítulo, as RIA possuem outras vantagens e

benefícios importantes, tais como:

1. Fácil implantação e manutenção [33]. Não necessitam de instalação, pois sendo uma aplicação web, um

browser e uma conexão à internet são suficientes para aceder à aplicação em questão. Além disso, a

actualização da mesma é automática. Constitui uma grande vantagem quando uma aplicação necessita de ser

flexível e extensiva;

2. Independência da plataforma. As aplicações correm em sistemas operativos e browsers diferentes. Isto deve-

se ao facto de estas aplicações correrem (geralmente) sobre um plugin (e.g., Flash Player), permitindo diminuir

problemas de compatibilidade de browsers e plataformas, desde que a versão do plug-in seja suportada pela

plataforma em questão;

3. Distribuição de dados pelo servidor e cliente. O programador pode decidir e distribuir a quantidade de

informação que irá residir no cliente ou servidor (as RIA suportam armazenamento de dados do lado do cliente

[21]). Por exemplo, numa aplicação de comércio online, o cliente pode armazenar os dados relativos ao carrinho

de compras enquanto o utilizador manipula estes dados. Nas aplicações web tradicionais esta tarefa era do

servidor [21]. Pode até desenhar uma aplicação que funcione temporariamente de forma independente do

servidor [28]. O cliente pode então manipular um determinado conjunto de informação, e só posteriormente,

após a operação estar finalizada, enviar ao servidor. Isto possibilita:

a. Uso offline [28];

b. Validação e preparação dos dados no lado do cliente [28];

c. Optimização do tráfego de rede.

4. Seguras. Uma RIA corre normalmente dentro de uma sandbox5, que restringe o acesso a certos recursos, e

consequentemente os danos que aplicações não desejadas podem causar.

No entanto, tal como todo o tipo de tecnologia, também as RIA possuem desvantagens e limitações. Por

exemplo, é facto que as RIA se aproximam em termos gráficos e interactivos das aplicações desktop, no entanto estas

5 É um mecanismo de segurança que fornece a um programa em execução, um conjunto controlado e diminuto de recursos. Geralmente

utilizado em browsers, para a execução de código não-confiável.


28

são geralmente mais avançadas, principalmente em termos gráficos. Outro aspecto, e de fácil percepção, é que o facto

de estas aplicações correrem numa sandbox restringe o acesso da aplicação a recursos do sistema que provavelmente

poderiam aumentar o seu desempenho. Logo, existe aqui um “trade off” entre a segurança e desempenho, que talvez

deva ser balanceado definindo a quantidade, ou a quais recursos, a aplicação pode ter acesso. Por fim, é verdade que

estas aplicações podem não necessitar de um acesso constante à internet, mas, como aplicações web que são,

dependem de acesso à internet para funcionar na sua plenitude.

3.1 Plataformas RIA

Existem diversas tecnologias que os programadores podem usar para desenvolver RIA. Estas podem ser

classificadas em quatro categorias gerais, conforme descrito em [23]:

• Scripting-based, onde a lógica do cliente é implementada usando linguagens script, tais como o

JavaScript, e a apresentação é baseada na combinação HTML/CSS;

• Plugin-based, onde o código da aplicação é executado numa máquina virtual instalada no browser, e

portanto toda a interpretação avançada e processamento de eventos são garantidos pelo plugin;

• Browser-based, onde o browser suporta e interpreta nativamente linguagens de marcação de interface

semelhantes ao XML (e.g., XUL);

• Desktop web-based, onde a aplicação pode ser descarregada e executada fora do browser (e.g., Adobe

AIR).

Actualmente as RIA oferecem essencialmente quatro caminhos [27]: HTML/AJAX, Java, Microsoft Silverlight e a

plataforma Adobe Flash, em que a primeira é scripting-based e as restantes são plugin-based/ desktop web-based, uma

vez que as suas aplicações podem ser executadas fora do browser. Obviamente, cada uma das tecnologias possui

vantagens e desvantagens distintas, pelo que é importante descobrir a ferramenta adequada para cada circunstância.

3.1.1 Flex

O Flex é uma framework open source, que permite construir aplicações web, mais propriamente RIA, na

plataforma Flash. Estas aplicações funcionam em quase todos os browsers, computadores pessoais e sistemas

operativos através do Adobe AIR ou do Adobe Flash Player, que está instalado em 99% dos computadores com acesso à

internet [27].

O Flex propriamente dito, é composto por duas linguagens de programação [27]: MXML e ActionScript. A primeira é

uma linguagem de marcação, com sintaxe XML que ajuda a criar, estruturar e manter a interface com o utilizador. Esta

permite facilmente implementar uma Graphical User Interface (GUI) de forma hierárquica (Figura 3.4), sem a

necessidade de escrever directamente código AS.


29

<?xml version="1.0" encoding="utf-8"?><s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"

xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600">

<s:Panel x="110" y="93" width="376" height="288"><mx:DataGrid x="36" y="10">

<mx:columns><mx:DataGridColumn headerText="Column 1" dataField="col1"/><mx:DataGridColumn headerText="Column 2" dataField="col2"/><mx:DataGridColumn headerText="Column 3" dataField="col3"/>

</mx:columns></mx:DataGrid><s:HGroup x="36" y="160" width="302" height="69">

<s:Button label="Button"/><s:Button label="Button"/><s:Button label="Button"/><s:Button label="Button"/>

</s:HGroup></s:Panel>

</s:Application>

FIGURA 3.4 – EXEMPLO DA LINGUAGEM MXML, ONDE SE PODE VERIFICAR A DESCRIÇÃO DE VÁRIOS COMPONENTES

ORDENADOS HIERARQUICAMENTE

O AS é uma linguagem orientada-ao-objecto que tem muitas semelhanças com Java, PHP e C#. É a linguagem de

programação oficial da plataforma Adobe Flash e permite codificar o comportamento de cada elemento da interface.

Esta pode ser customizada usando a linguagem Cascading Style Sheets (CSS). O Flex proporciona uma separação clara

entre a construção/aparência da interface e a codificação do seu comportamento (de acordo com o modelo Model-

View-Controller), o que facilita o desenvolvimento e manutenção da aplicação em questão bem como uma melhor

colaboração entre programadores e designers. O código da aplicação é compilado num ficheiro de extensão “.swf” e

posteriormente executado no desktop através do Adobe AIR, ou num browser, através do Adobe Flash Player.

O Flex proporciona, entre muitos outros, um conjunto de controlos, containers, layouts, forms e animações,

que permitem o desenvolvimento rápido de uma RIA. Esta produtividade é aumentada através dos Integrated

Development Environments (IDEs) fornecidos pela Adobe (Adobe Flash Builder, Adobe Flash Catalyst e Adobe Flash

Professional). O Flex privilegia uma interface intuitiva, permitindo fácil interpretação dos dados/controlos por parte do

utilizador, com poucas caixas de texto e mais interactiva. Para aceder a aplicações backend, o Flex dispõe de várias APIs

de rede (Figura 3.5) e de um grande número de tecnologias que permitem a comunicação com aplicações do lado do

servidor. Entre elas, estão algumas tecnologias que deverão ser usadas nesta dissertação:

• HTTP;

• XML;

• RESTfull Web Services;

• SOAP Web Services;

• AMF;

Por exemplo, para aceder a uma BD remota é necessário interligar o Flex através de um dos meios referidos acima a

uma tecnologia server-side, como por exemplo o PHP.


30

FIGURA 3.5 – FUNCIONAMENTO DAS APLICAÇÕES FLEX NUM BROWSER. COMUNICAÇÃO COM OUTROS SISTEMAS [34]

O Times reader é um exemplo de uma aplicação Flex, que implementa um jornal electrónico que corre em

Windows, Mac e Linux através do Adobe AIR. Este programa permite ao utilizador consultar as notícias no “The New

York Times”, proporcionando particularidades como o ajuste da quantidade de informação que deseja consultar,

pesquisa de notícias por título, secção ou imagens, visualização de vídeos e até completar as palavras cruzadas diária

(Sem lápis!). Uma vez que corre através do Adobe AIR no desktop, o Times Reader necessita apenas de ligação à

internet para descarregar as notícias diária, sendo que estas ficam armazenadas no computador permitindo a

visualização de notícias offline de até sete dias atrás. A Figura 3.6 ilustra o Times Reader.

FIGURA 3.6 – THE NEW YORK TIMES READER – HTTP://TIMESREADER.NYTIMES.COM/TIMESREADER/INDEX.HTML

http://timesreader.nytimes.com/timesreader/index.html


31

3.1.2 Microsoft Silverlight

O Silverlight é a abordagem da Microsoft às RIA. É um ambiente de execução6 .Net7 multiplataforma, um plugin

multibrowser e um conjunto de ferramentas baseadas em Windows, destinadas ao desenvolvimento de RIA [35]. Tal

como no Flex, o layout dos componentes que constituem a aplicação são descritos através de uma linguagem baseada

em XML, o eXtensive Application Markup Language (XAML). A lógica e comportamento dos componentes podem ser

implementados usando uma das linguagens suportadas pela framework .Net, tais como C#, Visual Basic, Phython ou

Ruby. Este facto constitui uma das principais vantagens do Microsoft Silverlight, pois quem está familiarizado com a .Net

não necessita de aprender uma linguagem de programação nova.

O Silverlight é suportado por múltiplos browsers, nomeadamente o Microsoft Internet Explorer, Safari, Mozilla

Firefox e Google Chrome, bem como vários sistemas operativos, incluindo obviamente o Windows, Mac OS X e Linux

através de um projecto open-source chamado moonlight e desenvolvido em parceria com a Microsoft, mas que apenas

suporta as duas primeiras versões do Silverlight. É também suportado por sistemas operativos de dispositivos móveis,

nomeadamente o Windows Phone 7 e o Nokia Symbian S60.

A framework da interface com o utilizador do Silverlight possui as seguintes características principais [36]:

• Suporte para o desenho de imagens vectoriais e transformações de perspectiva 3D;

• Suporte para a criação de animações e storyboards;

• Um leque variado de controlos, botões e caixas de textos, e suporte para a criação de componentes

personalizados;

• Suporte para a gestão de layout, data-binding (interligar um determinado conjunto de dados a um

determinado componente) e multi-touch;

• Suporte para webcams e microfones, permitindo a partilha de vídeo e áudio, e streaming de vídeo e

áudio;

Para criar aplicações Silverlight, a Microsoft oferece uma grande quantidade de ferramentas. As mais usuais

são o Microsoft Expresison Blend e o Microsoft Visual Studio. Este último é o IDE usado para o desenvolvimento de

aplicações que correm em ambiente .Net, mas o segundo é mais indicado para o desenvolvimento de GUIs,

proporcionando um melhor ambiente que o Visual Studio. Por exemplo, o Microsoft Expression Blend permite construir

uma interface arrastando os componentes para a localização desejada (como acontece no Adobe Flash Builder) e

gerando automaticamente o código, o que não acontece no Visual Studio. Por fim, é importante referir que tal como o

Flex, o Silverlight não acede directamente a uma BD. É no entanto possível a interacção com uma aplicação backend,

através de SOAP, REST, HTTP e Sockets.

6 Software desenhado para suportar a execução de um determinado programa escrito numa determinada linguagem.

7 .Net é uma framework que inclui uma biblioteca vasta e que suporta várias linguagens de programação, permitindo uma interoperabilidade entre as

linguagens suportadas pela framework.


32

Como exemplo de uma aplicação Silverlight, considere-se o Hard Rock café Memorabilia (Figura 3.7). Esta

página web apresenta numa espécie de painel, uma série de itens de tamanho pequeno, que podem ser explorados

através de drag-and-drop e zoom. É possível reparar que à medida que se faz zoom, é perceptível que a imagem do

objecto é progressivamente descarregada à medida que é necessária. O clique numa imagem permite obter

informações acerca do objecto em questão.

FIGURA 3.7 – HARD ROCK CAFÉ MEMORABILIA - HTTP://MEMORABILIA.HARDROCK.COM/

3.1.3 JavaFX

Como indicado pela Sun Microsystems (adquirida em 2009 pela Oracle), a plataforma JavaFX tem como

propósito principal o desenvolvimento de RIA para uma grande variedade de dispositivos, nomeadamente, desktops,

dispositivos móveis e IPTV [37]. Estas aplicações são escritas usando uma linguagem completamente nova, o JavaFX

Script. Este trabalho considera a versão 1.3 da plataforma JavaFX8. O JavaFX Script é uma linguagem orientada a

objectos construída de raiz, com uma sintaxe muito diferente do Java, que tem como objectivo modelar e animar

aplicações multimédia. É uma Domain-Specific Language (DSL)9 para criar, optimizar e simplificar o processo de

construção de uma GUI. A sintaxe é declarativa, ou seja, a estrutura do código é ordenada hierarquicamente (algo

semelhante ao XML, mas sem o uso de marcação) reflectindo-se na interface. O ambiente de execução JavaFX integra-

se com o Java Runtime Environment (JRE), adicionando funcionalidades à Java Virtual Machine (JVM), tirando portanto

partido de um conjunto de características com elevado grau de maturidade da plataforma Java. A Figura 3.8 apresenta a

plataforma JavaFX e cada um dos elementos que a integram [37]:

• JavaFX Runtime: Contém as livrarias de suporte e ambientes de execução multiplataforma, bem como as

de plataforma específica;

8 A versão actual é JavaFX 2.0, publicada na fase final deste trabalho, concretamente em 11/10/2011.

9 Linguagem criada unicamente para resolver um determinado tipo de problema ou domínio de aplicação.

http://memorabilia.hardrock.com/


33

• Elementos Comuns: Contém APIs e outros ambientes de execução que funcionam de forma consistente

em várias plataformas;

• Elementos específicos com APIs para diferentes plataformas: desktop, móvel e TV;

• Framework da Aplicação: Proporciona a base da construção e desenvolvimento da aplicação;

É possível criar conteúdo gráfico, através de ferramentas populares como o Adobe Photoshop e Adobe

Illustrator, que pode ser importado para a aplicação JavaFX utilizando um plugin adequado. No que diz respeito às

ferramentas que ajudam o programador, as aplicações JavaFX podem ser desenvolvidas no popular IDE Netbeans, ou

alternativamente no Eclipse.

FIGURA 3.8 – PLATAFORMA JAVAFX

A Figura 3.9 apresenta um exemplo de uma aplicação JavaFX. Esta é uma aplicação que permite o utilizador

visualizar a programação de um determinado canal televisivo ao longo de 24 horas. A aplicação demonstra algumas das

capacidades desta plataforma, sendo que o utilizador pode deslizar o rato pelos programas (eixos horizontais de cor

verde) para visualizar informação detalhada acerca do programa.

FIGURA 3.9 – MY TV SCHEDULE - HTTP://JAVAFX.COM/SAMPLES/MYTVSCHEDULE/INDEX.HTML

http://javafx.com/samples/MyTVSchedule/index.html


34

3.1.4 HTML5

O HTML é a linguagem utilizada para descrever a estrutura de uma página web [38]. Segundo o World Wide

Web Consortium (W3C) o HTML permite:

• Publicar na internet, textos, fotos, documentos, tabelas, etc.

• Descarregar informação online através de links e de um clique no botão;

• Desenhar formulários que permitem acções como pesquisa de informação, reservas online,

transacções online, etc.

• Incluir folhas de cálculo, clips de vídeo e áudio, e outras aplicações directamente num documento

HTML;

Foi publicado pela primeira vez em 1993 como um documento de projecto, tendo ganho grande popularidade

e atingido a versão 4.01 em 1999, versão que oficialmente permanece até hoje. A maioria do conteúdo existente na

internet continua a ser distribuído através do HTML [39]. Com o objectivo de inovar e dar nova vida ao HTML, o Web

Hypertext Application Working Group (WHATWG) criou em 2004 a especificação do HTML5. Em 2006, o W3C envolveu-

se novamente no HTML publicando em 2008 o primeiro rascunho (documento de projecto) do HTML5. A especificação

actual (de 2011) permanece ainda numa versão projecto, sendo que a data alvo para a finalização do mesmo é 2012.

Isso não significa que o HTML5 não possa ser utilizado, na verdade, a maioria dos browsers já suportam muitas das

funcionalidades do HTML5 e adicionam com regularidade suporte para novas características. O HTML5 será o novo

standard para o HTML, eXtensible Hypertext Markup Language (XHTML) e Document Object Model (DOM) HTML.

Algumas das novas funcionalidades incluem:

• Novos elementos de secção (novas marcações de semântica para descrever o conteúdo de um elemento

[39]), tais como, <article>, <footer>, <header>, <nav>, <aside> e <section>;

• Novos controlos de formulário, como <calendar>, <time>, <email>, <url>, <date> e <search>;

• Suporte nativo de áudio e vídeo;

• Elemento <canvas> para desenho (2D e 3D);

• Suporte para armazenamento offline local;

• Geolocalização;

• Scalable Vector Graphics (SVG);

De forma sucinta a visão do HMTL5 resume-se aos seguintes pontos [39]:

• Manter a compatibilidade com o conteúdo já existente;

• Sintaxe prática e pouco rígida. Por exemplo, no HTML5 as porções de código id=”html5”, id=html5 e

ID=”html5”, são válidas;

• Ser seguro desde do início do seu desenvolvimento;


35

• Separar a camada de apresentação do conteúdo, diminuindo a complexidade, aumentando a facilidade de

interpretação do código e consequentemente a sua manutenção, e ao mesmo tempo diminuir o tamanho

do documento para ser mais rápido a carregar;

• Simplificar a interoperabilidade entre browsers, e.g., evitar complexidades desnecessária (e.g.,

simplificação do DOCTYPE), e construir uma especificação mais precisa e detalhada;

• Ser de acesso universal, i.e., as funcionalidades devem sempre que possível funcionar em diferentes

plataformas e dispositivos, suporte para utilizadores com dificuldades, e suporte para a publicação em

todas as línguas mundiais;

• Ser plugin free, i.e. suportar nativamente funcionalidades que eram apenas possíveis através de plugins;

Perspectiva das tecnologias web normalizadas 3.1.4.1

Ao invés de uma abordagem HTML pura, os websites modernos são desenvolvidos segundo uma série de

tecnologias web normalizadas. Como referido na secção 2.4, por si só o HTML não é capaz de suportar os requisitos das

RIA. Apesar do HTML5 possuir novas características, este não substitui o uso do JavaScript, CSS, e DOM, nem é essa a

intenção. Pelo contrário, como referido pelo W3C, o HTML5 deve ser baseado nas seguintes tecnologias normalizadas:

JavaScript: Permite adicionar interactividade às páginas web, através de código embutido em HTML [40] e

interpretado pelo browser, não requerendo o uso de plugins. Reage a eventos e permite o acesso a todos os elementos

do HTML através do DOM, o que se reflecte numa interacção dinâmica com o utilizador. Por exemplo, a selecção de um

elemento com o rato pode mudar a aparência do mesmo elemento.

CSS: Define como os elementos do HTML, tais como os títulos ou links são apresentados, permitindo aos

programadores e designers um controlo facilitado sobre a apresentação das páginas [40]. Uma folha de estilos pode ser

usada para definir o layout da página, cores dos elementos, sombras, fontes, etc.

DOM: É uma interface de programação que permite ao programador identificar e manipular os elementos das

páginas HTML [40]. O DOM divide um documento HTML em objectos discretos, cada um com as suas propriedades e

métodos, que podem ser manipulados através do JavaScript [41];

XMLHttpRequest: É um objecto JavaScript usado para fazer pedidos HTTP assíncronos e receber pedidos sem

que o utilizador experimente quaisquer interrupções visuais [40];

Dynamic HTML: Não é uma linguagem, mas sim um termo que se refere à combinação de HTML, JavaScript,

CSS e DOM [40], para desenvolver websites interactivos e dinâmicos;

AJAX: Asynchronous JavaScript and XML, que basicamente se refere ao uso do JavaScript para se obter a

comunicação assíncrona com o servidor. É composto pelo conjunto de tecnologias web standard, nomeadamente

JavaScript, DOM, CSS, XML e XMLHttpRequest (XHR);

Como se pode verificar, a ideia de desenvolver RIA usando HTML5 por si só, não é totalmente correcta (O

HTML5 não deixa de ser uma linguagem de markup). Para o desenvolvimento deste tipo de aplicações e de forma a


36

corresponder aos requisitos impostos pelas mesmas, é necessário o uso de todo um conjunto de tecnologias. Por

exemplo, a comunicação assíncrona, uma das características principais das RIA, apenas é conseguida através do

JavaScript, mais especificamente através do objecto XMLHttpRequest. Do mesmo modo, o refrescamento parcial da

página também só é possível através do JavaScript e DOM. Assim, o HTML5 é apenas uma das tecnologias usadas pelo

estilo Ajax [25].

AJAX 3.1.4.2

O termo Ajax criado em 2005 por Jesse James Garnet é um conjunto de tecnologias para criar aplicações web

sofisticadas [25]. Aplicações como o Google Maps, Gmail ou Windows Live são exemplos de RIA que tiram partido desta

técnica. O Ajax não é uma tecnologia, nem uma nova linguagem [25], [40]. É uma técnica que usa um conjunto de

tecnologias standard open-source, multi-browser e multiplataforma. Este conjunto de tecnologias funciona a níveis

diferentes, cada uma com uma funcionalidade específica, podendo ser [25]:

• Linguagens de marcação: HTML, XML;

• Linguagem para descrever a apresentação da página: CSS;

• Interacção e apresentação dinâmica: DOM;

• Linguagens Client-side: JavaScript;

• Transferência e comunicação assíncrona com o servidor: Objecto XmlHttpRequest;

• Manipulação, transformação e troca de dados: XML, XSLT, HTML, JSON, dados de texto;

• Protocolos de transferência: HTTP(s);

• Linguagens Server-side: JSP, JSF, Perl, Ruby, PHP, Cold Fusion, ASP e aplicações CGI;

Estas não são as únicas tecnologias ou linguagens que podem ser utilizadas para o desenvolvimento de aplicações Ajax.

No entanto, são as mais populares e na sua maioria são normas open-source (com excepção nas linguagens server-side

Cold Fusion e ASP). Uma aplicação Ajax pode ter várias combinações de tecnologias dependendo da aplicação em

questão. Portanto, o Ajax não se encontra necessariamente ligado a uma determinada linguagem, formato de troca de

dados, ou linguagem de server-side [25], mas usa uma combinação de tecnologias web.

Uma aplicação Ajax é composta do lado do cliente por três camadas distintas [25] – Interface, código

JavaScript e motor Ajax – conforme ilustrado na Figura 3.10. A primeira envolve o uso de HTML, CSS e DOM. O HTML

descreve o conteúdo da página através das marcações. O CSS, obrigatoriamente10 com a chegada do HTML5, contém a

informação de apresentação, separada do conteúdo em ficheiros de estilos que eliminam a redundância [25]. Por fim, o

DOM permite o acesso dinâmico e actualização de cada elemento da página, incluindo das suas propriedades. Já na

camada JavaScript, cada interacção do utilizador com um elemento HTML gera um evento que é tratado pelo respectivo

handler (Event Listener). A Figura 3.10 apresenta dois casos. O primeiro não necessita de efectuar um pedido ao

10 Em versões anteriores, era possível especificar as propriedades de estilo de cada elemento nas marcações. O HTML5 força a separação, não

permitindo o uso de muitas propriedades de estilo dentro das marcações.


37

servidor, pelo que o código do handler é executado fazendo todo o processamento do lado do cliente. No segundo caso,

a camada do motor Ajax é utilizada. Cria-se um objecto XHR que faz um pedido HTTP assíncrono, cujo progresso é

indicado pela propriedade readyState. Esta pode estar em cinco estados distintos [25]: Unitialized, loading, loaded,

interactive e completed. Sempre que o estado é alterado o evento readyStateChange é lançado. O servidor processa o

pedido, que normalmente implica o acesso a uma BD e constrói uma resposta em XML, HTML ou texto, que é depois

processada pelo JavaScript. A resposta pode conter novos elementos que através do DOM podem ser adicionados à

página sem que seja necessário um refrescamento total.

.

FIGURA 3.10 – MODELO DE UMA APLICAÇÃO AJAX [25]


38

Com a chegada do HTML5, a abordagem Ajax torna-se mais competitiva devido à introdução das novas

funcionalidades, nomeadamente o suporte nativo de e drag and drop, e de áudio e vídeo que anteriormente não era

possível sem o uso de plugins. Além disso, a evolução não está limitada apenas ao HTML5, mas sim a todo o conjunto de

tecnologias Ajax, pois o CSS3, DOM4 e XHR nível 2 constituem também desenvolvimentos, com novas características e

funcionalidades promissoras. A constante evolução dos browsers, mais especificamente a evolução dos motores

JavaScript, beneficia não só as aplicações já existentes, mas também o surgimento das novas características do HTML5,

tornando possível muitas funcionalidades que seriam impensáveis há pouco tempo atrás (e.g., Canvas, WebGL). A

Figura 3.11 ilustra uma página com novos elementos de semântica do HTML5 que definem a disposição dos elementos.

Todos estes elementos podem ser personalizados através do CSS, sendo que alguns usam já novas características do

CSS3, nomeadamente transformações, sombras e cantos redondos. O objecto XHR foi também melhorado

consideravelmente. Os melhoramentos centram-se em duas áreas [39]:

• Cross-origin XMLHttpRequests;

• Eventos progressivos.

FIGURA 3.11 – PÁGINA EM HTML5, COM OS NOVOS ELEMENTOS DE SEMÂNTICA E FUNCIONALIDADES CSS3 [39]

O primeiro permite o desenvolvimento de aplicações web que usam serviços alojados em origens diferentes através do

XHR. Considera-se que dois serviços (ou páginas) têm origens diferentes se uns destes três elementos forem diferentes:

• Protocolo;

• Porta (se especificada);

• Endereço do servidor.

Por exemplo, a URL http://local.pt/index.html tem uma origem diferente da URL http://local2.pt/index.html. Com o

cross-origin XMLHttpRequest, é possível criar uma aplicação que usa conteúdo de uma determinada origem e serviços

Ajax de outra origem, utilizando o XHR para comunicar entre as duas [39]. Sem esta funcionalidade, só pode haver

http://local.pt/index.html

http://local2.pt/index.html


39

comunicação assíncrona entre aplicações com a mesma origem (devido à same origin policy 11 ). O segundo

melhoramento pode ser exemplificado com uma barra de progresso, cuja implementação pode ser simplificada através

do uso eventos progressivos e sem a participação do lado do servidor. Por exemplo, pode-se usar o evento progress

para calcular o progresso de uma transferência XHR. Em adição, os eventos progressivos têm propriedades que

permitem o acesso ao tamanho dos dados a transferir e à quantidade que falta e que já foi transferida. Na versão

anterior do XMLHttpRequest, o único evento relacionado com este objecto é o readyStateChange [39]. A Tabela 6

apresenta os eventos progressivos que podem ser observados usando os respectivos event handlers.

TABELA 6 – EVENTOS PROGRESSIVOS DO OBJECTO XMLHTTPREQUEST NÍVEL 2

Nome do evento de progresso

Loadstart

Progresso

Abort

Error

Load

Loadend

11 Política que impede um documento ou script de uma origem aceder aos métodos e propriedades de um documento de origem diferente.


40

4 Experimentação de soluções alternativas

A primeira fase deste projecto consistiu no estudo da arquitectura mais adequada para a aplicação de acordo

com os requisitos impostos inicialmente. Assim, a abordagem passou por implementar várias aplicações testando as

diversas opções descritas no capítulo 1 e 3. O objectivo foi basear a escolha não só no estudo teórico, mas

complementá-la com a experiência prática e apurar as vantagens e desvantagens de cada opção directamente. Deste

modo, foi possível apurar várias características que de outro modo seriam difíceis de descobrir e ao mesmo tempo

afinar a escolha da arquitectura da aplicação.

A construção da arquitectura da aplicação implica a escolha de pelo menos três componentes importantes – a

GUI (cliente), o meio de comunicação com o servidor e a API de mapas (Figura 4.1). A existência de uma aplicação

servidora para intermediar o acesso à BD está naturalmente dependente da tecnologia usada no lado do cliente, porque

esta pode ou não permitir o acesso directo a uma BD remota. As experiências centram-se nestes elementos e a decisão

final deve obviamente ter em conta vários aspectos, nomeadamente a facilidade de acesso à BD, aspecto da UI e

facilidade de integração com as APIs dos mapas, entre outros.

FIGURA 4.1 – OPÇÕES CONSIDERADAS PARA A ARQUITECTURA DO SISTEMA

Para isso, implementaram-se três UIs (clientes) para o desenvolvimento de RIA recorrendo a tecnologias

diferentes: Flex, JavaFX e Ajax. Estas aplicações de teste são versões simplificadas da aplicação final, implementando

apenas algumas das funcionalidades. Como a GUI tem que incluir uma vista de mapa, as experiências sobre as APIs dos

mapas foram efectuadas em simultâneo com as próprias UIs. Além destas experiências, implementaram-se WebServices

SOAP e REST em diferentes linguagens (Java e PHP) do lado do servidor, em combinação com clientes também em

diferentes linguagens (e.g., Flex, JavaFX e Ajax). Neste capítulo descreve-se cada experiência realizada, analisam-se as

vantagens e desvantagens de cada uma e finaliza-se com a decisão da arquitectura da aplicação e tecnologia de cada

um dos componentes.


41

4.1 GUI e Mapas

Os requisitos das aplicações são apenas alguns do conjunto total da aplicação final (enumerados em 1.2),

concretamente:

• Conectar-se a uma BD remota;

• Apresentar as plataformas num mapa;

• Apresentar uma tabela que liste o estado geral das plataformas. Permitir rapidamente ir para a

localização da plataforma seleccionada;

• Apresentar as informações detalhadas de uma plataforma quando seleccionada;

• Procura de plataformas por nome;

• Minimizar o número de comunicações entre o cliente e servidor, de modo a reduzir o trafego de rede.

Quando o utilizador acede à aplicação, o cliente pede ao servidor a informação das plataformas. Usando a

latitude/longitude, as plataformas são correctamente colocadas num mapa que ocupa a maioria da interface.

Juntamente com o mapa, uma tabela de vista geral apresenta informações como, o nome da plataforma, localização e

condição. O utilizador pode então interagir com a tabela, com o mapa e com as plataformas, através de acções como, ir

para uma posição de uma determinada plataforma com um clique no nome, visualizar informação detalhada através do

clique na plataforma (na tabela ou no mapa), fazer zoom, navegar pelo mapa através de drag and drop e mudar o tipo

de mapa. Como se pode ver na Figura 4.2, o servidor é apenas invocado para obter informação das plataformas e para

procurar uma plataforma por nome.

FIGURA 4.2 – ARQUITECTURA DA APLICAÇÃO SIMPLIFICADA

O servidor, ao receber um pedido, realiza uma query à BD para obter a informação pretendida. Esta é, aliás, a sua

principal função, juntamente com algumas medidas de segurança como a prevenção de injecção de código SQL na BD.

De notar que, como estas experiências são principalmente centradas no lado do cliente, os detalhes da implementação

do lado do servidor não são abordados nas subsecções seguintes. No entanto, a implementação do servidor difere

ligeiramente dependendo da tecnologia do lado do cliente, uma vez que o protocolo de comunicação não é o mesmo.

Repare-se que era naturalmente possível desenvolver o servidor de modo a ser compatível com todos os clientes (e.g.,


42

HTTP + XML). No entanto, para avaliar a facilidade da comunicação com o servidor e respectivo acesso à BD de cada

plataforma foram necessárias abordagens diferentes no lado do servidor.

4.1.1 Serviços de Mapas

Um dos requisitos fundamentais da aplicação é a apresentação das plataformas no mapa. Estas devem ser

representadas por um ícone que ao mesmo tempo indica o estado geral da plataforma. Portanto, o ícone deve ter três

cores – vermelho, amarelo, e verde – que indicam o estado global da plataforma. O serviço de mapas tem que permitir

pelo menos:

• Inclusão de marcadores no mapa, com a possibilidade de alterar o ícone;

• Janelas (estilo pop-up) que permitam a consulta de dados detalhados com um clique no marcador;

• Controlos de tipos de mapa, zoom e navegação;

• Permitir a alteração programática do campo de visão para que a visualização das plataformas seja

amigável.

Conforme anteriormente ilustrado na Figura 3.1, foram considerados os serviços de mapas da Google, Yahoo! e

Bing. Ao longo das experiências, verificou-se que os três serviços possuem métodos com nomes e modos de uso muito

semelhantes. Todos os serviços fornecem funcionalidades que permitem cumprir os requisitos acima referidos. Assim

sendo, a escolha do serviço de mapas está principalmente dependente da família de APIs que fornecem para diferentes

plataformas, e da tecnologia escolhida para o desenvolvimento da aplicação (cliente). Então, um bom ponto de começo

para a comparação dos três serviços é analisar quais as APIs que cada serviço dispõe (Tabela 7). Estas APIs podem ser

divididas em dois grupos – APIs para mapas interactivos e APIs para mapas estáticos - e serão descritas nas secções

seguintes.

TABELA 7 – APIS DISPONIBILIZADAS PELOS SERVIÇOS DE MAPAS EM ESTUDO

Linguagens do cliente Tipo de Web Service

JavaScript ActionScript .Net REST SOAP

Serv

iço

de

Map

as Google Maps Sim Sim Não Sim Não

Yahoo! Maps Sim Sim Não Sim Não

Bing Maps Sim Não Sim Sim Sim

Mapas Interactivos 4.1.1.1

Estas APIs permitem incluir mapas interactivos, com controlos de tipo de mapa, zoom e navegação. Permitem

também adicionar marcadores, janelas de informação e desenhar polígonos programaticamente. Basicamente os mapas


43

podem ser programados pela linguagem em questão. Este é o caso das APIs para JavaScript, ActionScript e linguagens

.Net.

A um nível mais baixo todas as APIs do mesmo fornecedor de serviço funcionam da mesma maneira. Por

exemplo, no caso do Yahoo! Maps, todas as APIs encapsulam o uso do REST [42]. No entanto, este facto é transparente

ao programador, uma vez que dispõe de métodos para a manipulação do mapa. Para todos os casos, com excepção da

API JavaScript da Google, é necessário efectuar um registo e obter uma chave única da API. A Figura 4.3, Figura 4.4 e

Figura 4.5, exemplificam a inicialização de um mapa em JavaScript (uma vez que todos os serviços fornecem APIs

Javascript) usando a respectiva API de cada um dos três serviços.

<!DOCTYPE html><html><head><meta name="viewport" content="initial-scale=1.0, user-scalable=no" /><style type="text/css"> html { height: 100% } body { height: 100%; margin: 0; padding: 0 } #map_canvas { height: 100% }</style><script type="text/javascript" src="http://maps.googleapis.com/maps/api/js?sensor=false"></script><script type="text/javascript"> function initialize() { //New latitude and longitude var latlng = new google.maps.LatLng(-34.397, 150.644); var myOptions = { zoom: 8, center: latlng, mapTypeId: google.maps.MapTypeId.ROADMAP }; //Map options var map = new google.maps.Map(

document.getElementById("map_canvas"), myOptions); //New map } </script></head><body onload="initialize()"> <div id="map_canvas" style="width:100%; height:100%"></div></body></html>

FIGURA 4.3 – EXEMPLO DA INICIALIZAÇÃO DE UM MAPA EM JAVASCRIPT USANDO O GOOGLE MAPS [43]

Como se pode verificar existem muitas semelhanças nas três situações. Tipicamente define-se um evento que é

disparado quando o corpo da página HTML começa a carregar (onload). O handler trata das opções de inicialização,

inicializa o mapa e, através do DOM, insere o mapa na respectiva secção. No caso da Yahoo! Maps, não se está a utilizar

nenhuma função para a inicialização do mapa, embora fosse naturalmente possível associá-la e.g., ao evento onload.

No entanto, como o código JavaScript está directamente no corpo do HTML (também poderia estar no cabeçalho), é

executado quando a página é carregada. Repare-se ainda que a primeira marcação <script> contém a propriedade

src igualada à URL que permite o carregamento da API. Isto significa que no JavaScript não é necessária a instalação

de libraria adicionais, basta inserir a URL do programa que faz o carregamento da API. No caso de a API necessitar de

uma chave, como acontece no Yahoo! e Bing Maps, esta deve ser incluída na URL ou na propriedade credentials

respectivamente. Por fim, o Google Maps possui ainda o parâmetro adicional sensor na propriedade src, que deve ser

explicitamente definido (true ou false), e que serve para indicar se a aplicação usa um sensor para determinar a

localização do utilizador.


44

<!DOCTYPE html><html> <head> <script type="text/javascript" src="http://api.maps.yahoo.com/ajaxymap?v=3.8&appid=YD-eQRpTl0_JX2E95l_xAFs5UwZUlNQhhn7lj1H"></script> <style type="text/css"> #map{ height: 75%; width: 100%;} </style> </head> <body> <div id="map"></div> <script type="text/javascript"> // Create a map object var map = new YMap(document.getElementById('map')); // Add map type control map.addTypeControl(); // Add map zoom (long) control map.addZoomLong(); // Add the Pan Control map.addPanControl(); // Set map type to either of: YAHOO_MAP_SAT, YAHOO_MAP_HYB, YAHOO_MAP_REG map.setMapType(YAHOO_MAP_SAT); // Display the map centered on a geocoded location map.drawZoomAndCenter("New York, NY", 4); </script> </body> </html>

FIGURA 4.4 – EXEMPLO DA INICIALIZAÇÃO DE UM MAPA EM JAVASCRIPT USANDO O YAHOO! MAPS [42]

<!DOCTYPE html><html> <head> <title></title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <script type="text/javascript" src="http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0"></script> <script type="text/javascript"> function GetMap() { //New map on the mapDiv HTML element along with the map options var map = new Microsoft.Maps.Map(document.getElementById("mapDiv"), {credentials: "Your Bing Maps Key", center: new Microsoft.Maps.Location(45.5, -122.5), mapTypeId: Microsoft.Maps.MapTypeId.road, zoom: 7}); } </script> </head> <body onload="GetMap();"> <div id='mapDiv' style="position:relative; width:400px; height:400px;"></div> </body></html>

FIGURA 4.5 – EXEMPLO DA INICIALIZAÇÃO DE UM MAPA EM JAVASCRIPT, USANDO O BING MAPS [44]

Mapas Estáticos 4.1.1.2

As APIs para mapas estáticos permitem inserir o mapa na aplicação como uma imagem (e.g., <img> numa

aplicação HTML). Estas recebem um pedido HTTP e, de acordo com os parâmetros passados na URL (GET), retornam

uma resposta contendo o mapa como uma imagem (com excepção do serviço da Yahoo!, que retorna uma resposta em

XML com a URL da imagem do mapa e aceita pedidos POST com os parâmetros no corpo). Os parâmetros permitem

especificar o centro do mapa, nível de zoom, marcadores, tamanho do mapa, entre outros. Este é o caso da API REST

disponível nos três serviços, e da API SOAP disponível no Bing Maps. A Figura 4.6 ilustra o exemplo de um pedido e

resposta de um mapa estático para cada um dos serviços. Mais uma vez as situações são muito semelhantes. Repare-se

que no caso do Google Maps, não é necessária uma chave para poder utilizar a API.


45

As APIs para mapas estáticos funcionam a nível inferior relativamente às anteriores, e consequentemente, a

interactividade é mais limitada. Funcionalidades como drag and drop e controlos de zoom, navegação e tipo de mapa,

não são suportadas nativamente. Além disso, a cada interacção é necessário especificar uma URL e fazer o pedido HTTP

ao serviço em questão. Por exemplo, como não existe um controlo de zoom no mapa, é necessário um componente

extra (e.g., Slider, Numeric Stepper) que permita ao utilizador definir o zoom pretendido. Depois, é necessário passar

esse valor na URL e fazer um pedido HTTP para modificar a imagem do mapa.

Aplicação Google Maps

http://maps.googleapis.com/maps/api/staticmap?center=Brooklyn+Bridge,New+York,NY&zoom=14&size=512x512&maptype=roadmap&markers=color:blue%7Clabel:S%7C40.702147,-74.015794&sensor=false Serviço

Google Maps

Imagem do mapa

http://local.yahooapis.com/MapsService/V1/mapImage?appid=YahooMapsKey&street=701+First+Avenue&city=Sunnyvale&state=CA Serviço

Yahoo! Maps

Resposta em XML com a URL da imagem do mapa

Aplicação Yahoo! Maps

http://dev.virtualearth.net/REST/v1/Imagery/Map/AerialWithLabels/eiffel tower?mapSize=800,600&pp=47.612441,-122.204533;;2&dcl=1key=BingMapsKey Serviço Bing

Maps

Imagem do Mapa

Aplicação Bing Maps

FIGURA 4.6 – APIS REST DOS TRÊS SERVIÇOS DE MAPAS

Concluindo, todas as APIs são usadas de forma muito semelhante e todas elas permitem cumprir os requisitos

impostos pela aplicação pretendida. Preferencialmente, a opção passa por uma API de mapas interactivos, pois permite

uma produtividade maior, maior controlo sobre as opções do mapa, simplicidade de desenvolvimento e maior

interactividade por parte do utilizador. A Figura 4.7 apresenta o aspecto dos três serviços de mapas em estudo.

FIGURA 4.7 – OS TRÊS SERVIÇOS DE MAPAS


46

4.1.2 Aplicação Ajax

Nesta subsecção aborda-se o caso de estudo da aplicação Ajax. Esta versão foi implementada no Integrated

Development Environment (IDE) NetBeans 7.0, que já suporta o HTML5. A Figura 4.8 ilustra a arquitectura da aplicação e

as tecnologias utilizadas, incluindo uma base de dados MySQL e um script PHP do lado do servidor para fazer o acesso à

BD. Esta aplicação testa os três serviços de mapas, com o objectivo de decidir qual será utilizado na versão final, pois

todos os serviços incluem uma API JavaScript. Portanto, pode embutir-se mapas interactivos da Google, Yahoo! ou Bing

em aplicações Ajax.

Cliente Ajax(HTML5 + JavaScript

+ CSS + DOM)

Google Maps

Yahoo! Maps

Bing Maps

JavaScript API

JavaScript API

JavaScript API

PlatService.php

MySQL

XMLHttpRequest

FIGURA 4.8 – ARQUITECTURA DA APLICAÇÃO AJAX

Processamento 4.1.2.1

A Figura 4.9 descreve este comportamento inicial da aplicação. A aplicação começa por utilizar o objecto XHR

para fazer um pedido HTTP assíncrono à BD através do script PHP PlatService.php. Este script faz o acesso à BD e cria

uma resposta XML contendo os dados das plataformas. Uma resposta em XML é preferível, pois toda a informação é

automaticamente inserida numa árvore DOM pelo XHR [41] (mais especificamente na propriedade responseXML), e

portanto, pode ser facilmente extraída pelo cliente. Em alternativa, o servidor podia ter construído uma resposta no

formato JSON, o que também seria adequado, uma vez que este formato é na realidade uma string de um objecto

JavaScript, e pode ser efectivamente convertido num através do método JavaScript eval(). Esta informação é depois

usada para colocar as plataformas no mapa e construir a tabela de vista geral.

Como existem diferenças na implementação do objecto XHR entre os browsers, é necessário garantir que o

pedido funciona em todos eles. Isto deve-se ao facto de na altura da publicação do Internet Explorer, versões 5 e 6, o

identificador do objecto XHR não ser ainda uma norma. No entanto, o Internet Explorer 7 segue a implementação

normalizada do XHR, sendo portanto consistente com todos os outros browsers. A estratégia passou então por usar a

técnica de feature detection, i.e., ao invés de se detectar o browser a ser usado, verifica-se se o browser suporta uma

determinada característica.


47

Browser Servidor

Evento da criação do corpo HTML

Cria um novo XHR

GET PlatService.php

Pede ao MySQL as plataformas

Resposta em XML

Extrai a informação do documento XML

Coloca as plataformas no mapa segundo a sua latitude/longitude e adiciona as respectivas janelas de informação

Insere cada plataforma numa linha de uma tabela HTML

Cria resposta XML com os dados das plataformas

FIGURA 4.9 – DIAGRAMA DE SEQUÊNCIA DA INICIALIZAÇÃO DA APLICAÇÃO AJAX

Pode-se então usar uma função especial composta por e.g., blocos try-catch, para instanciar o XHR correctamente.

Como ilustrado pela Figura 4.10, o primeiro try verifica se o XHR pode ser criado usando o objecto nativo. Se a criação

for bem-sucedida, significa que o browser implementa o XHR segundo a norma. Caso contrário, está-se perante o

Internet Explorer 5 ou 6, pelo que a instanciação deve ser feita de maneira diferente.

request = new AjaxRequest() //Pedido XHR request.open("GET", "PlatService.php", true) //GET PlatService.php: request.send(null) //GetXmlFile é o event handler request.onreadystatechange = GetXmlFile function AjaxRequest(){ try { // Para IE7+, Chrome, Firefox, Safari, etc. var request = new XMLHttpRequest() } catch(e1) { try { //Para IE5 e IE6 request = new ActiveXObject("Microsoft.XMLHTTP") } catch(e2) { //Não suporta XHR request = false } } return request; }

FIGURA 4.10 – FUNÇÃO AJAX CROSS-BROWSER

A função GetXmlFile() é definida como event handler, e é chamada quando a propriedade readyState se altera. Esta

função (ver Figura 4.11) verifica se o pedido está concluído (readyState == 4) e foi bem-sucedido (código HTTP 200).

Se for o caso, pode extrair-se a informação do documento XML, colocar as plataformas no mapa, criar uma linha por

plataforma para inserir na tabela, e adicionar as janelas de detalhe a cada plataforma. As plataformas são identificadas


48

no mapa através de marcadores, aos quais estão anexadas janelas de pop-up que são automaticamente apresentadas

quando o utilizador clica num marcador, apresentando informações detalhadas da respectiva plataforma. Todo este

processo é realizado no ciclo for ilustrado na Figura 4.11. O DOM permite um acesso fácil aos elementos do documento

XML, e ao mesmo tempo ao corpo da tabela HTML. A cada iteração, uma linha com as informações gerais da plataforma

(nome, localização e estado) é dinamicamente criada e adicionada ao corpo da tabela. Como esta tabela é um elemento

HTML, o JavaScript pode interagir com ele através do DOM

(document.getElementById(‘PlatTableBody’).innerHTML).

Além disso, o nome de cada plataforma é definido como um link, que pode ser usado para ir para a localização da

plataforma com um clique:

<a href="javascript:map.panTo(point['+ i + ']); map.setZoom(10)">

O código JavaScript inserido neste elemento HTML diz respeito à API JavaScript da Google Maps, e permite alterar a

vista actual do mapa deslocando-o para a coordenada da respectiva plataforma com um zoom escolhido. O vector

point[] armazena a cada iteração as coordenadas (latitude e longitude) da plataforma, e portanto é passado para a

função map.panTo. Esta porção de código depende da API de mapas que se utilize. Na Figura 3.10 utiliza-se a API da

Google, para as APIs do Bing Maps e da Yahoo! Maps o código seria, respectivamente:

• <a href="javascript:map.setView({center: point['+ i + '], zoom: 8})">

• <a href="javascript:map.panToLatLon(point['+ i + ']); map.setZoomLevel(8)">

function GetXmlFile(){ if(request.readyState == 4 && request.status == 200) { //Load XML doc var xml = this.responseXML //Go to "Platform" node var platforms = xml.documentElement.getElementsByTagName("Platform") for(var i=0; i < platforms.length; i++){ //Get latitude and longitude first var latitude = parseFloat(platforms[i].getAttribute("latitude")) var longitude = parseFloat(platforms[i].getAttribute("longitude")) //Place markers [...] var name = platforms[i].getAttribute("name") var location = platforms[i].getAttribute("location") var status = platforms[i].getAttribute("status") //Create row document.getElementById('PlatTableBody').innerHTML += '<tr><td><a href="javascript:map.panTo(point['+ i + ']); map.setZoom(10)">'+ name + '</a></td><td>' + location + '</td><td>' + status + '</td></tr>' //Add Info Windows: [...] } } }

FIGURA 4.11 – FUNÇÃO DE CALLBACK DO EVENTO ONREADYSTATECHANGE

Para implementar a funcionalidade de procura por nome, cujo diagrama de funcionamento se encontra na

Figura 4.12, foi necessário adicionar uma textbox e um botão para introduzir o nome da plataforma. Para evitar o

refrescamento completo da página, usa-se novamente o objecto XmlHttpRequest.


49

Browser Servidor

Clique no botão

GET SearchPlat.php

Resposta em HTML

Coloca a plataforma na tabela

Procura na BD o nome da plataforma

Filtra a informação introduzida pelo

utilizador

Constrói uma resposta HTML (linha de uma tabela)

FIGURA 4.12 – DIAGRAMA DE SEQUÊNCIA DA FUNCIONALIDADE DE PROCURA POR NOME DE UMA PLATAFORMA NA APLICAÇÃO AJAX

Começa-se por definir um event handler para o clique no botão (SearchPlat(name) ver Figura 4.13), que envia um

pedido XHR com o nome da plataforma num parâmetro da URL. A resposta do servidor é colocada na tabela de vista

geral, que é a única parte da interface que é actualizada. Também para evitar ligações desnecessárias, o cliente verifica

se existe algum texto introduzido na textbox antes de o pedido ser enviado. Se for o caso, um aviso amigável é

apresentado. Este aviso é criado através da alteração do texto de um elemento HTML (<span>) em runtime.

function SearchPlat(name){if(name == ''){ //Se a caixa de texto estiver vazia, não faz a chamada ao servidor e emite aviso: document.getElementById('info').innerHTML = "<font id='Finfo'> ← Please enter a Platform name</font>"}else{document.getElementById('info').innerHTML = "" //Limpa o avisorequest.open("GET", "SearchPlat.php?q=" + name, true) //Fazer um GET assíncrono do ficheiro PlatServicerequest.send(null)

request.onreadystatechange = function(){ //Eventhandler. if(request.readyState == 4 && request.status == 200) document.getElementById('PlatTableBody').innerHTML = request.responseText //Introduzir a tabela no código HTML }}

FIGURA 4.13 – EVENT HANDLER PARA O CLIQUE NO BOTÃO DE PESQUISA

A resposta do servidor neste caso pode ser em HTML, uma vez que só se pretende apresentar os dados numa

tabela e não utilizá-los como anteriormente. O servidor constrói a tabela para apresentar os dados da plataforma em

questão e envia-a para o cliente que actualiza a tabela anterior substituindo-a pelos resultados da pesquisa de

plataforma.


50

Apresentação da UI 4.1.2.2

Relativamente ao código HTML da aplicação, apresentado na Figura 4.14, usaram-se várias das novas tags semânticas.

Primeiro, o HTML5 define um doctype simples e pequeno (<!DOCTYPE html>, em vez de <!DOCTYPE HTML PUBLIC “-

//W3C//DTD HTML 4.01 Transitional//EN”), que indica ao browser para apresentar a página no modo standard. As

novas marcações semânticas melhoram consideravelmente a estrutura da página, tornando-a mais compreensível e

coerente. Esta aplicação inclui as seguintes marcações HTML5:

• <header>: Destina-se a conter ajudas de navegação ou de introdução ao assunto no cabeçalho da página

ou de uma secção, geralmente (mas não obrigatoriamente) em headings (de <h1> até <h6>);

• <nav>: Destinada para conter elementos de navegação;

• <section>: Especifica uma dada secção na página. Pode conter todo o tipo de tags;

• <aside>: Destinada a conter elementos relacionados com a secção principal, mas que fazem sentido por

si só, por exemplo, pode ser utilizada como sidebar;

• <footer>: Rodapé da página ou de uma secção.

<!DOCTYPE html> <html> <head><script type="text/javascript">[...]</head> <body onload="loadMap()"> <header> <h1>Platforms Graphical User Interface</h1> <h4>HTML 5 v1.0.1</h4></header> <nav><ul>

<li><a href="PlatGui1.01YahooMaps.html">Yahoo! Maps Version</a></li> <li><a href="PlatGui1.01BingMaps.html">Bing Maps Version</a></li> <li><input type="submit" value="Search By name" class="Sbutton" onclick="SearchPlat(Ssearch.value)"/> <input type="text" class="Stextbox" id="Ssearch"/> <span id="info"></span></li></ul>

</nav> <section id="mainsection"> <section id="mapcontent"> <header><h2 id="mappy">Platforms Map</h2></header> <div id="mapholder" style="width: 100%; height: 500px"></div> </section> <aside> <section> <header> <h2>Platform Table View</h2> </header> <table id="PlatTable"> <thead><tr>

<th>Name</th> <th>Location</th>

<th>Status</th> </tr>

</thead> <tbody id="PlatTableBody"></tbody> </table> </section> </aside> </section> <footer><h3>Departamento de Electronica Industrial</h3><p>Uminho 2011</p></footer> </body> </html>

FIGURA 4.14 – CÓDIGO HTML COM AS NOVAS TAGS A VERDE


51

Assim, em vez de se usar uma marcação <div> para cada secção da página (e.g., cabeçalho, corpo e rodapé), pode

agora utilizar-se marcações apropriadas. A vantagem além da organização e da simplificação do design da página, é que

os motores de busca vão tirar partido destes elementos facilitando o processamento. Por exemplo, a Google analisou

milhares de páginas e concluiu que a tag <div> contém identificadores comuns em grandes quantidades [39] (e.g., <div

id = ”footer”>).

Todos estes elementos podem ser customizados através do CSS. Como referido em 3.1.4, uma das

características do HTML5 é o esforço da separação do conteúdo e da apresentação, logo com esta nova versão, os

elementos têm que ser customizados através do CSS. Sem o uso do CSS a página web tem a aparência “despida”, pouco

atractiva e antiquada da Figura 4.15. De facto, não parece uma RIA.

FIGURA 4.15 – APLICAÇÃO DE ESTUDO AJAX SEM CSS

Para tornar a página mais apelativa e interactiva usou-se o CSS, que permite definir os estilos dos

componentes. Tal como o HTML5, o CSS3 ainda está sob desenvolvimento, pelo que existem certas características que

estão em fase experimental. No ficheiro CSS (mostrado na Figura 4.16), foram definidas cores, layout, margens,

sombras, entre outros. Além destes, utilizaram-se novas funcionalidades do CSS3, como os cantos redondos (border-

radius), sombra (box-shadow), e transformações (transform) que permitem movimentos de rotação ou translação do

elemento. Os prefixos –webkit e –moz são prefixos específicos de vendedores, usados nesta fase experimental para

evitar problemas de incompatibilidade, nomeadamente de namespace. Pode também adicionar-se alguma

interactividade alterando o estilo de um elemento em função de uma acção (e.g., estar em cima de, seleccionar). É o

que acontece no último elemento da Figura 4.16, onde se altera a cor do elemento quando o dispositivo apontador

passa sobre ele, e depois efectua-se uma translação para adicionar alguma animação ao componente. A Figura 4.17

apresenta a nova versão (irreconhecível) da aplicação, com estilos definidos através do CSS3.


52

/*myCSS101.css*/ nav { position: absolute; width: 1024px; background: #1a1a1a; margin: 0px; -webkit-border-radius: 10px; -moz-border-radius: 10px; border-radius: 10px; -webkit-box-shadow: 2px 2px 20px #888; -moz-box-shadow: 2px 2px 20px #888 } h4{ color: #F47D31; background-color: #fff; -webkit-box-shadow: 2px 2px 20px #888; -webkit-transform: rotate(-45deg);

-moz-box-shadow: 2px 2px 20px #888; -moz-transform: rotate(-45deg); position: absolute; padding: 0px 150px; top: 50px; left: -120px; text-align:center; } nav ul li a:hover{ color: #fff; transform: translateX(10px); -webkit-transform: translateX(10px); -moz-transform: translateX(10px); -webkit-box-shadow: 2px 2px 20px #888; -moz-box-shadow: 2px 2px 20px #888; }

FIGURA 4.16 – CÓDIGO CSS PARCIAL, APRESENTANDO ALGUMAS DAS NOVAS FUNCIONALIDADES DO CSS3

FIGURA 4.17 – APLICAÇÃO DE ESTUDO AJAX COM CSS

4.1.3 Aplicação Flex

A versão Flex da aplicação em estudo é abordada nesta subsecção. Neste caso, o IDE utilizado foi o Adobe Flash

Builder. Este IDE é poderoso, proporcionando drag and drop de componentes para a área de design, code completion,

geração de código, e um sofisticado wizard de conexão a serviços que simplifica (e muito) a interface ao backend da

aplicação (e.g., PHP, XML, HTTP e WebServices). A Figura 4.18 ilustra a arquitectura desta aplicação e as tecnologias

utilizadas. O serviço de mapas utilizado foi o Google, por intermédio da API para AS. Em alternativa podia-se

naturalmente utilizar o serviço da Yahoo! também por intermédio da API para AS, ou até mesmo o serviço Bing Maps,

mas apenas através das APIs de mapas estáticos. No lado do servidor as tecnologias mantêm-se, no entanto o acesso à

BD é feito de maneira diferente, logo o script PHP é diferente relativamente ao caso do Ajax.


53

FIGURA 4.18 – ARQUITECTURA DA APLICAÇÃO FLEX

Comunicação com o servidor 4.1.3.1

No Flex não existe acesso directo aos dados armazenados numa BD. Assim, é sempre necessária uma aplicação

do lado do servidor para fazer esse acesso. Entre as várias maneiras de se conectar a um servidor através do Flex,

optou-se pela utilização do AMF como alternativa ao SOAP e REST. Como referido em 2.4, o Remoting permite invocar

os métodos expostos pela aplicação servidora, que pode ser implementada em várias linguagens. Para simplificar este

acesso, o Flash Builder possui um wizard “Connect to data/service” que permite conectar, entre outros serviços, a uma

classe PHP. Utilizou-se uma classe PHP com dois métodos: um que retorna todas as plataformas, i.e., array de objectos

Platform), e outro que retorna uma plataforma segundo um nome (Figura 4.19). Na primeira vez que este serviço é

utilizado, o Flash Builder solicita a instalação do ZendAMF no servidor. O Flash Builder inspecciona a classe PHP, cria o

serviço no lado do cliente gerando uma classe AS que replica a classe do servidor (contendo todo o código de

Remoting). Todas as operações do serviço/classe ficam disponíveis na vista “Data/Services” após a criação do mesmo.

FIGURA 4.19 – ACESSO DO FLEX AO SERVIDOR ATRAVÉS DO REMOTING

Apresentação da UI 4.1.3.2

Para criar a UI não foi praticamente necessário escrever código MXML. Todos os componentes foram

arrastados da palete de componentes para a área de design e o respectivo código MXML foi automaticamente gerado

pelo IDE. Primeiro, arrastou-se um componente painel que contém todos os outros elementos da aplicação, incluindo

um componente DataGrid (tabela). Depois, definiu-se um contentor para o mapa, e mais dois para conter vários botões


54

e uma textbox. O único código MXML que foi necessário escrever manualmente foi a declaração do mapa dentro do

respectivo contentor (<maps:Map>…</maps:Map> ver Figura 4.20).

Para preencher a tabela, pode arrastar-se a operação GetPlatforms() para a tabela (DataGrid) e seguir os passos

solicitados pelo IDE. A partir deste momento, o resultado da operação fica vinculada (bound) à tabela, ou seja, sempre

que o resultado da operação GetPlatforms() se alterar, a informação apresentada na tabela reflecte essa alteração

automaticamente. Como o que se pretende da tabela é a apresentação da informação geral das plataformas (nome,

localização e estado), ajustaram-se as colunas (repare-se que na Figura 4.20 apenas estão declaradas três objectos

DataGridColumn) de modo a só apresentarem esta informação, e não a mais detalhada. Note-se que, ao contrário da

aplicação Ajax, o código AS não necessita de criar linhas programaticamente, uma vez que a tabela mostra

automaticamente todas as plataformas retornadas pelo serviço. Como se pode ver pela Figura 4.20, o objecto DataGrid

possui um atributo change e creationComplete que especificam a função a ser chamada quando os eventos change e

creationComplete ocorrem respectivamente. Assim, quando a criação da DataGrid está completa a função

PlatData_creationCompleteHandler(event) é chamada.

[...]<s:states>

<s:State name="PlatView"/><s:State name="PlatDetails"/><s:State name="GiantMap"/>

</s:states>[...]<fx:Declarations>

<s:CallResponder id="GetPlatformsResult" result="GetPlatformsResult_resultHandler(event)"/><valueObjects:Platform id="platform"/>

</fx:Declarations><fx:Binding source="PlatData.selectedItem as Platform" destination="platform"/><s:Panel [...]>

<mx:DataGrid x="10" y="10" id="PlatData" height="208" styleName="Titles" width="371" creationComplete="PlatData_creationCompleteHandler(event)" change="PlatData_changeHandler(event)" includeIn="PlatDetails,PlatView" dataProvider="{GetPlatformsResult.lastResult}">

<mx:columns><mx:DataGridColumn headerText="name" dataField="name"/><mx:DataGridColumn headerText="location" dataField="location"/><mx:DataGridColumn headerText="status" dataField="status"/>

</mx:columns></mx:DataGrid>[...]<s:SkinnableContainer [...]>

<maps:Map [...]></maps:Map></s:SkinnableContainer><mx:Form includeIn="PlatDetails" x="10" y="226" width="371" height="215">

<mx:FormItem label="Name"><s:Label id="nameLabel" text="{platform.name}"/>

</mx:FormItem><mx:FormItem label="Location">

<s:Label id="locationLabel" text="{platform.location}"/></mx:FormItem><mx:FormItem label="Status">

<s:Label id="statusLabel" text="{platform.status}"/></mx:FormItem><mx:FormItem label="Platgroup">

<s:Label id="platgroupLabel" text="{platform.platgroup}"/></mx:FormItem><mx:FormItem label="Latitude">

<s:Label id="latitudeLabel" text="{platform.latitude}"/></mx:FormItem><mx:FormItem label="Longitude">

<s:Label id="longitudeLabel" text="{platform.longitude}"/></mx:FormItem>

</mx:Form>[...]

</s:Panel></s:Application> FIGURA 4.20 – EXCERTO DE CÓDIGO MXML DA APLICAÇÃO FLEX


55

Tal como na aplicação da secção anterior, as informações detalhadas de uma plataforma podem ser vistas através das

janelas de informação anexadas aos marcadores. No entanto, neste caso optou-se também pela alternativa de

apresentar a informação detalhada num formulário (Form), uma vez que pode ser facilmente criado através da própria

DataGrid com a opção “Generate Details Form”. Essa opção abre um wizard de criação do formulário que possui uma

opção “Master-Detail”, que vincula a informação da DataGrid ao formulário. Assim, a DataGrid apresenta a

informação principal, e o formulário a informação detalhada. Depois da criação do formulário, todo o código MXML é

gerado automaticamente. Como se pode ver ainda pela Figura 4.20, a propriedade text de cada label que constitui o

formulário está vinculada ao objecto platform. Este foi definido como uma instância da classe Platform

(<valueObjects:Platform id=”platform”/>) na secção Declarations, onde são colocados todos os objectos não-

visuais. Isto significa que se pode aceder às propriedades da plataforma assim: e.g., platform.name. É a secção Binding

que vincula o item seleccionado na DataGrid ao objecto platform, de modo a colocar em platform o elemento

correspondente do array de plataformas e em simultâneo sincronizar a plataforma com os detalhes apresentados no

formulário. É de salientar que a partir do momento que a DataGrid é criada, toda a informação das plataformas já está

no cliente, e portanto, não se fazem pedidos adicionais dos detalhes das plataformas.

Como se pretende que as informações detalhadas sejam apenas apresentadas quando o utilizador selecciona

uma plataforma na tabela, definiu-se um novo estado (página) chamado PlatDetails como um duplicado do estado

inicial, que inclui todos os componentes anteriores e o formulário. As aplicações HTML usam uma página como um ecrã,

e muda-se de página saltando para um ficheiro HTML diferente. No Flex, usa-se um conceito parecido chamado de

estados [34], no entanto, ao contrário das páginas HTML, os estados não estão necessariamente em ficheiros

diferentes. Além disso, o mesmo componente definido em MXML pode pertencer a mais do que um estado: define-se a

que estados um componente pertence através da propriedade includeIn. Portanto, para que o formulário só exista no

estado PlatDetails faz-se: includeIn: "PlatDetails" (Figura 4.20).

Processamento 4.1.3.3

A Figura 4.21 apresenta uma porção de código AS que é basicamente composto por três event handlers. A

operação GetPlatforms() é executada quando a criação do objecto DataGrid está completa. Este é um pedido

assíncrono, e portanto o utilizador pode continuar a interagir com a aplicação. O objecto GetPlatformResult é um

objecto do tipo CallResponder, que trata dos resultados bem-sucedidos. Quando o pedido de Remoting é feito ao

servidor, é retornada uma instância da classe AsyncToken. Esta pode ser associada ao objecto CallResponder

igualando a sua propriedade token ao objecto AsyncToken retornado pelo pedido [34], para que, deste modo, o

CallResponder possa receber (e tratar) os dados recebidos. É a propriedade lasResult que é automaticamente

preenchida com os dados retornados do servidor. Note-se também que a propriedade dataProvider do objecto

DataGrid está vinculada à propriedade lastResult, pelo que, sempre que o seu valor seja alterado a tabela será

também automaticamente actualizada.


56

protected function PlatData_creationCompleteHandler(event:FlexEvent):void{GetPlatformResult.token = PlatService.GetPlatforms();

}

protected function PlatData_changeHandler(event:ListEvent):void{currentState = “PlatDetails”;map.panTo(new LatLng(Number(Platform.latitude),Number(Platform.longitude)));map.setZoom(10);

}

protected function searchButton_clickHandler(event:MouseEvent):void{if(searchTextbox.text != '')

GetPlatformsResult.token = platService.GetPlatByName(searchTextbox.text)else currentState = "PlatView";

}

FIGURA 4.21 – EXCERTO DE CÓDIGO AS DA APLICAÇÃO FLEX

A alteração entre os estados é feita na função PlatData_changeHandler(event), que é chamada sempre que

o utilizador selecciona uma plataforma diferente na tabela. Repare-se que para além de alterar o estado, este método

altera a vista do mapa para a plataforma seleccionada e define um zoom adequado.

Por fim, para implementar a funcionalidade de pesquisa por nome basta arrastar a operação GetPlatByName()

para o botão de pesquisa. Neste momento, o Flash Builder gera automaticamente o handler para o clique no botão, que

faz a chamada ao servidor passando o valor da textbox. Depois de verificar se existe algum texto na textbox, o pedido é

efectuado e o servidor filtra os dados e envia a query à BD. Como a propriedade GetPlatformResult.lasResult já

está vinculada à DataGrid, pode atribuir-se a resposta da operação à propriedade token do mesmo objecto para que a

tabela seja actualizada com plataforma resultante da busca (ou nenhuma). No caso de a textbox estar vazia, o estado é

alterado para a vista geral de todas as plataformas.

A Figura 4.22 apresenta a aplicação com a VigoPlat seleccionada na tabela, mostrando a sua informação geral,

sendo que o formulário apresenta todos os detalhes da plataforma.

FIGURA 4.22 – APLICAÇÃO DE ESTUDO FLEX


57

Por sua vez o mapa apresenta um marcador amarelo, indicando que o estado da plataforma não é perfeito mas

aceitável. Incluíram-se ainda alguns botões que permitem mudar o tipo de mapa a ser apresentado, apesar de a API AS

do Google permitir a inserção de botões no próprio mapa. Não existe nenhuma razão para não o fazer, apenas se

pretende apresentar diferentes abordagens. À semelhança da aplicação anterior pode-se usar o CSS para definir o

aspecto da aplicação, no entanto o Flex inclui por defeito vários temas (no formato SWC) customizáveis e atractivos,

pelo que escolheu-se um deles.

4.1.4 Aplicação JavaFX

Como nos exemplos anteriores, esta aplicação é composta por três elementos principais, a UI, o serviço de

mapas e a ligação à BD remota, que são abordados de forma individual. A Figura 4.23 apresenta estes três elementos e

as respectivas interacções. No que diz respeito ao serviço de mapas, o mecanismo utilizado neste caso é

completamente diferente do utilizado nas experiências anteriores, uma vez que não existe em nenhum dos serviços de

mapas uma API para JavaFX Script. A solução para este tipo de aplicações é então utilizar uma API de mapas estáticos. A

ligação à BD também é diferente, uma vez que o JavaFX Script suporta JDBC, dispensando os scripts PHP no lado do

servidor pois é feita directamente pelo cliente. A aplicação foi desenvolvida utilizando o IDE Netbeans com o plug-in

JavaFX, que permite escrever o código manualmente, ou então tirar partido do JavaFX Composer, que gera código

automaticamente a partir do drag and drop de componentes. No entanto, o código gerado é bloqueado pelo IDE, e.g., a

alteração dos atributos (e.g., width, height, etc.) dos componentes não pode ser feita directamente no código. Por este

motivo, optou-se escrever o código manualmente.

GUI JavaFXGoogle Maps API Static Maps MySQLJDBC

FIGURA 4.23 – GUI EM JAVAFX QUE COMUNICA COM O MYSQL ATRAVÉS DA JDBC, E USA O SERVIÇO DE MAPAS ESTÁTICOS DA GOOGLE

MAPS

A ligação à BD remota foi feita através de JDBC. O NetBeans possui uma framework DataSource que

abstrai/generaliza e simplifica o acesso a várias fontes de dados persistentes, nomeadamente BDs, serviços HTTP,

sistemas de ficheiros e ficheiros locais (algo semelhante à conexão de serviços do Adobe Flash Builder). Deste modo,

uma DataSource JDBC pode ser usada para estabelecer a ligação remota com o MySQL; no entanto é necessário

adicionar o driver JDBC (MySQL Connecter/J) ao projecto. A Figura 4.24 apresenta como se define uma DataSource

JDBC.

def Platforms: org.netbeans.javafx.datasrc.DbDataSource = org.netbeans.javafx.datasrc.DbDataSource{ connectionString: "jdbc:mysql://localhost:3306/platformsbd" user: "user" password: "pass" query: "select name, location, latitude, longitude, status from platforms}

FIGURA 4.24 – LIGAÇÃO À BD REMOTA NO JAVAFX


58

A Figura 4.25 ilustra o objecto de nível hierárquico mais elevado, ou seja, que inclui todos os outros objectos

que constituem a interface. O stage é o contentor que representa a ligação com o mundo exterior, é a janela da

aplicação. Este inclui o scene, que é onde todos os outros componentes estão inseridos. Existem várias variáveis

definidas no scene: width e height definem respectivamente a largura e altura da aplicação, e content define o conteúdo

da scene. Na aplicação, a scene contém vários containers que por sua vez incluem outros componentes, como por

exemplo searchTile que é a área que define os componentes usados para procurar uma plataforma por nome (contém

um botão, uma caixa de texto e uma label).

Stage { title: "Application title" scene: Scene { width: 800 height: 600 fill: Color.STEELBLUE stylesheets: "{__DIR__}PlatStyle.css" content: [headerHBox, gridVBox, mapContainer, searchTile ] }}def searchTile = Tile{ layoutX: 2 layoutY: 202 width: 250 content:[searchButton,searchTextBox,warningLabel]}

FIGURA 4.25 – OBJECTOS STAGE E SCENE

À semelhança das aplicações anteriores, quer-se uma tabela para apresentar a informação geral das

plataformas. No entanto, o JavaFX 1.3 (versão utilizada neste projecto) não fornece um componente tabela12. Assim,

para apresentar a informação geral relativa às plataformas foram utilizadas labels. Estas poderiam ter sido criadas

programaticamente com posicionamento e tamanho adequados a formarem uma tabela; no entanto o JavaFX possui

um contentor grid, que está somente disponível como uma funcionalidade de teste, onde podem ser colocadas as

labels.

Como a aplicação tem que ser independente do número de plataformas, é necessário criar labels

dinamicamente conforme o número de plataformas, ou criar três labels fixas, e dois botões que permitam a navegação

entre as plataformas (anterior/seguinte), alterando a informação apresentada. Optou-se pelo segundo caso, embora

este método não permita a visualização geral de todas as plataformas em simultâneo. Assim, é necessário actualizar os

campos de texto das labels, conforme o utilizador carrega no botão anterior/seguinte e se move de plataforma em

plataforma. Para isso, utilizou-se o conceito de binding já abordado no caso da aplicação Flex. O binding permite a

actualização automática de uma variável ou propriedade de um objecto, através da definição de uma relação de

actualização automática entre dados de uma parte do programa que estão dependentes de dados de uma outra parte

ou fonte [45]. Basicamente, este mecanismo permite controlar o valor de uma determinada variável através de outra

variável ou objecto.

12 A versão JavaFX 2.0, publicada em 11/10/2011, já suporta tabelas (http://download.oracle.com/javafx/2.0/ui_controls/table-view.html).


59

Como se pode ver pela Figura 4.26, a variável “nameValueLabel” está vinculada ao valor retornado pela

expressão Platform.getRecordSet().currentString(“name”). O objecto Platform acede à BD e contém um cursor

que percorre os resultados da query. Portanto a variável nameValueLabel está vinculada ao valor da linha de resultados

seleccionada e cuja coluna tem o nome “name” (nome da plataforma). Deste modo, o avanço/retrocesso do cursor nas

linhas de resultado reflecte-se na label. Os dois botões de navegação por sua vez permitem alterar a plataforma

seleccionada avançando ou retrocedendo o cursor, o que significa que o texto das labels, que contêm a informação

geral de uma plataforma, se altera automaticamente. Quando não existe uma plataforma seguinte/anterior, o botão de

avanço/ retrocesso é desactivado automaticamente usando a expressão bind not para alterar o estado da propriedade

disable do objecto Button.

def nameValueLabel = Label{ vpos: VPos.BASELINE text: bind "{Platforms.getRecordSet().currentString("name")}"}[...]//Botões para navegar pelas plataformasdef nextPlatButton = Button {

text: "Next" styleClass: "button1" disable: bind not Platforms.getRecordSet().hasNext()

action: function():Void {Platforms.getRecordSet().next(); //Avança uma row

}}def prevPlatButton = Button{ text: "Previous" styleClass: "button1" disable: bind not Platforms.getRecordSet().hasPrev() action: function():Void {

Platforms.getRecordSet().prev(); //Recua uma row}

}

FIGURA 4.26 – EXCERTO DE CÓDIGO RELATIVO À NAVEGAÇÃO ENTRE PLATAFORMAS

Para obter os mapas foi utilizada a API de mapas estáticos do Google Maps, que retorna imagens. Para

adicionar um mapa à aplicação JavaFX foi necessário definir um contentor destinado à apresentação de uma imagem

(ImageView), e inserir a imagem (Image) propriamente dita (Figura 4.27). A imagem possui um atributo url onde se

define a URL da imagem, neste caso do mapa, enviando-se como parâmetros o centro do mapa, a posição do marcador

(plataforma) e o zoom, de acordo com a API Google Maps. Estes parâmetros (com excepção do zoom) são

automaticamente modificados através dos botões de navegação, conforme a plataforma que seja seleccionada pelo

utilizador. Mais uma vez utilizou-se o binding para o efeito: na Figura 4.27 existe uma função bound (getMap()) cujo

valor retornado é usado para controlar o estado de uma variável bind (image). A função retorna o mapa que será

utilizado como imagem do componente ImageView. Note-se também que esta função recebe como parâmetros três

variáveis que estão vinculadas à latitude, longitude e zoom da plataforma seleccionada no momento. Quando o

utilizador carrega no botão seguinte/anterior, selecciona uma nova plataforma e as variáveis que contêm a latitude e

longitude tomam automaticamente novos valores. Como houve alteração nestes valores a função getMap é chamada

actualizando a imagem com o mapa centrado na localização da plataforma seleccionada e com o zoom seleccionado.


60

Embora a abordagem usada para inserir o mapa na aplicação tenha funcionado correctamente, o mapa é

apenas uma imagem e, portanto, não suporta nativamente o drag and drop, controlos do tipo de mapa nem controlos

de zoom. Estas funcionalidades podem ser implementadas usando componentes do JavaFX. Por exemplo, o zoom, é

neste caso controlado através de um Slider, cujo valor está vinculado à variável zoom e é enviado na URL. Para o drag

and drop, pode-se definir um evento do tipo drag and drop no componente Image e alterar a localização do mapa

conforme a direcção do arraste. No entanto, estas abordagens, além de exigirem um esforço de implementação

bastante superior, não funcionam com a mesma fluidez como as outras APIs (e.g., a actualização do mapa é mais lenta).

Por fim, também não é possível adicionar as janelas de informação nos marcadores, pelo que foi necessário definir mais

labels para apresentar a informação detalhada.

def latitude = bind Platforms.getRecordSet().currentString("latitude");def longitude = bind Platforms.getRecordSet().currentString("longitude");def zoom:Integer = bind javafx.util.Math.round(zoomSlider.value);

bound function getMap(lat,lng,zoom){def mapUrl:String = "http://maps.google.com/maps/api/staticmap?center={lat},{lng}&markers=icon:http://maps.google.com/mapfiles/kml/pal3icon53.png%7C{lat},{lng}&zoom={zoom}&size=400x400&sensor=false";

//Container para o mapa. Este vai ser uma imagemdef mapImage = Image{

url: mapUrl} return mapImage;}

def mapContainer = ImageView{ image: bind getMap(latitude,longitude,zoom) layoutX: 264 layoutY: 42 fitWidth: 534 fitHeight: 534}

FIGURA 4.27 – INCLUSÃO DO MAPA NA APLICAÇÃO JAVAFX

Mais uma vez, usou-se o CSS para definir a aparência de cada componente, e o resultado está apresentado na

Figura 4.28.

FIGURA 4.28 – APLICAÇÃO JAVAFX COM CSS


61

4.1.5 Conclusão

Uma única tecnologia não resolve todos os problemas; existem vantagens e desvantagens distintas em cada

uma das tecnologias testadas. Nestas últimas secções, abordaram-se três tecnologias RIA tentando identificar qual a

que permitia cumprir da melhor forma os requisitos enumerados em 3.1.1 e também exigindo um menor esforço. Os

seguintes critérios foram usados para avaliar cada uma das experiências:

• Aspecto/Riqueza da UI: Componentes disponíveis, customização de componentes, facilidade de criação

de novos componentes, aspecto dos componentes, animações, Look and Feel;

• Experiência oferecida ao utilizador: interactividade, rapidez de resposta e facilidade de utilização. (e.g.,

notificações ao utilizador, drag and drop, etc.);

• Tempo de inicialização: o tempo de inicialização da aplicação deve ser reduzido;

• Carga de processamento sobre o servidor: a carga de processamento deve estar mais no lado do cliente

do que no servidor;

• Compatibilidade com plataformas de software: independência relativamente a browsers e SOs utilizados;

• Conexão à BD: Facilidade da ligação à BD remota, segurança da ligação e requisitos no lado do servidor;

• Ferramentas de suporte: Existência de ferramentas de suporte, funcionalidades oferecidas que ajudem

ao desenvolvimento e ao aumento da produtividade;

• Integração com o serviço de mapas: Facilidade de integração dos mapas na aplicação, com preferência

sobre as APIs de mapas interactivos;

• Facilidade de implementação das funcionalidades requeridas: Existência de componentes standards

adequados ao tipo da aplicação, facilidade de conexão ao serviço de mapas, entre outros.

A Tabela 8 apresenta a comparação das três plataformas em estudo segundo os critérios enumerados acima. A

tabela avalia de forma qualitativa cada critério com um “+” se uma plataforma se distinguir das restantes no critério a

ser avaliado, “o” se não existir distinção, “-” se for inferior e “X” se não suportar o critério correspondente. A tabela

possui ainda uma pequena descrição por critério, que justifica a classificação atribuída a cada plataforma.

TABELA 8 – COMPARAÇÃO ENTRE AS TRÊS PLATAFORMAS EM ESTUDO SEGUNDO OS CRITÉRIOS DEFINIDOS

Flex Ajax JavaFX

Aspecto/Riqueza

da UI + o o

A interface do Flex é a mais apelativa de todas, embora isso seja subjectivo. O Flex possui o maior

número de componentes disponíveis, com um alto nível de customização e possibilidades de animação;

Ao mesmo tempo é o que mais facilita a criação de novos componentes. Com os novos HTML5 eCSS3, o

Ajax melhora consideravelmente o aspecto da UI e as possibilidades de animação, no entanto é inferior

ao Flex e não proporciona tantos componentes nem o mesmo nível de customização/criação dos

mesmos. Por sua vez o JavaFX peca principalmente por disponibilizar menos componentes que o Flex, e a

criação de novos componentes não é tão simplificada como no Flex.


62

Experiência

oferecida ao

utilizador

o o o

Todas as abordagens proporcionem um óptimo nível de experiência ao utilizador, muito semelhante às

aplicações desktop. Todas possuem comunicação assíncrona, têm um tempo de resposta e fluidez

semelhantes (o JavaFX é mais lento nos mapas mas isso deve-se ao facto de utilizar mapas estáticos).

Tempo de

inicialização o + −

A aplicação Ajax, por correr directamente no browser, é a mais rápida a inicializar. O Flex possui também

uma inicialização muito rápida para uma tecnologia plugin. Além disso, o programador pode melhorar

esse tempo colocando menos componentes no estado em que a aplicação arranca. O JavaFX neste caso

possui um tempo de inicialização bastante demorado, com vários passos, incluindo a inicialização do

plugin.

Carga de

processamento

sobre o servidor

o o +

Em todas as abordagens o processamento está praticamente todo no lado do cliente, e todas evitam a

transferência redundante de dados. No JavaFX, o cliente fala directamente com a BD. Tanto o Flex como

o Ajax requerem uma aplicação servidora, pelo que colocam mais carga sobre o servidor (embora isso

permita ganhos em termos de segurança). No Ajax, o script PHP constrói uma resposta em XML ou HTML,

e no Flex, o ZendAMF serializa os dados no formato AMF.

Compatibilidade

com plataformas

de software

o − o

A grande desvantagem do Ajax são os problemas de compatibilidade entre os browsers, porque nem

todos seguem as normas (e.g., ECMAScript, CSS), limitando a flexibilidade das aplicações. Além disso, por

assentar em tecnologias normalizadas as funcionalidades demoram mais tempo a evoluir. Tanto as

aplicações Flex como JavaFx correm em plugins proprietários com distribuição para os SOs mais

utilizados, sendo assim compatíveis entre esses SOs.

Conexão à BD + o o

O Flex e Ajax não acedem directamente a BDs. No Flex, o Remoting simplifica a reutilização dos métodos

no lado do servidor, pelo que podem ser utilizados directamente pelo cliente; não é necessária a

construção nem análise de um documento XML. Além disso, o Flash Builder aumenta a produtividade

pois gera em AS, o código de Remoting). O Ajax facilmente envia pedidos a uma BD invocando scripts

server-side, mas caso o resultado não seja para mostrar (e.g., XML para processar, em vez de HTML) tem

que processar os dados no formato utilizado. O JavaFX acede directamente à BD e portanto não necessita

de scripts. No entanto, não usufrui das medidas de segurança oferecidas pelas linguagens server side.

Além disso, as credenciais de acesso à BD são descarregadas para o cliente, e (embora compiladas na

aplicação) podem ser comprometidas com mais facilidade. Por esta razão, o acesso à BD deve ser feito

sempre no lado do servidor [19].

Ferramentas de

suporte o − o

A melhor ferramenta é sem dúvida o Adobe Flash Builder. Distingue-se principalmente pela facilidade de

conexão a serviços. Inspecciona uma classe PHP, Java, documento XML, serviço HTTP ou documento

WSDL, e gera um serviço do lado do cliente que pode facilmente ser associado a um determinado

componente. Esta ferramenta é um dos pontos fortes do Flex. O senão é que não é open-source, nem

barata. Existe no entanto a possibilidade de adquirir uma versão trial. Apesar do AMF não ser suportado

nativamente pelas linguagens server-side existem várias frameworks que podem ser instaladas no lado do


63

servidor (e.g., ZendAMF). No caso do Ajax os IDEs são mais escassos. No NetBeans, toda a estrutura da

aplicação tem que ser construída manualmente pois não existe geração de código nem drag and drop de

componentes, embora existam inúmeras frameworks de apoio (e.g., YUI, Clean Ajax Framework, Dojo

Tollkit, etc.). O JavaFX possui um bom suporte de ferramentas, nomeadamente o NetBeans, que é

gratuito, mas não é tão poderoso como o Flash Builder. Para a conexão à BD é necessária a inclusão do

driver do fabricante da BD no projecto.

Integração com

os serviços de

mapas

o − x

Todos os serviços de mapas incluem APIs para JavaScript, o que facilita a integração de qualquer um dos

serviços em aplicações Ajax. O Bing Maps limita as aplicações Flex à API de mapas estáticos. Por fim, não

existem APIs para JavaFX script, portanto a única opção é usar uma das APIs de mapas estáticos, o que

limita ou dificulta consideravelmente a interactividade com o utilizador.

Facilidade de

implementação

das

funcionalidades

requeridas

+ o −

A aplicação foi mais facilmente implementada em Flex. Os componentes disponibilizados são ideais para

a aplicação pretendida (e.g., DataGrid, Formulários, Layouts, Contentores, etc.). No caso do Ajax a

criação da tabela não é tão simples, e.g., é necessário criar linhas de acordo com o número de

plataformas, e depois inseri-las no corpo da tabela. No Flex, a UI é automaticamente preenchida com os

dados dos objectos ligados a ela. A versão JavaFX utilizada não inclui um componente tabela, o que é

grave para o tipo de aplicação que se pretende.

Como se pode observar, o Flex é, segundo o estudo efectuado, a plataforma mais adequada para o

desenvolvimento da aplicação que se pretende. De facto, a aplicação em Flex foi desenvolvida a um ritmo incrível.

Usando o Adobe Flash Builder, pode-se obter um nível de produtividade muito elevada, em parte devido ao arraste de

componentes para a área de design e respectiva geração de código, mas principalmente devido à facilidade de conexão

a serviços. É possível conectar a uma classe PHP, WebService, documento XML ou serviço HTTP, com muita facilidade; o

Flash Builder faz todo o trabalho inspeccionando o serviço em questão, e gerando as mesmas operações, incluindo o

código Remoting inerente às operações no lado do cliente. Estas podem ser associadas a um componente através de

um simples arraste da operação para o componente pretendido. Por sua vez, os componentes fornecidos pela

framework são os mais indicados para aplicações empresariais, de educação, visualização/monitorização de dados e

aplicações desktop de consumo, pois fornece componentes como a DataGrid, vários tipos de gráficos, formulários e

gestores de layouts. Além disso, os próprios componentes oferecem uma boa interface ao utilizador, por exemplo, a

DataGrid permite por si só ordenar o conteúdo alfabeticamente ou numericamente através de um clique numa das

colunas. Isto, para a aplicação pretendida é importante, pois facilita a monitorização do estado geral das plataformas

complementando a vista do mapa. Nas outras abordagens, seria necessário um esforço maior por parte do

programador para a implementação desta funcionalidade. Relativamente ao acesso à BD remota, a necessidade de uma

aplicação servidora para aceder à BD não é necessariamente uma desvantagem. Primeiro, a existência de uma aplicação

servidora intermédia permite o desenvolvimento do frontend de forma independente da BD, o que resulta numa

arquitectura geral da aplicação robusta, compreensiva e de manutenção facilitada pois está particionada. Segundo, e

mais importante, as credenciais de acesso à BD não devem estar no lado do cliente, pois podem ser comprometidas


64

com mais facilidade. Por exemplo, as credenciais podem eventualmente ser comprometidas através de um

descompilador swf. Além disso, o PHP é uma linguagem madura com muitas características relacionadas com a

segurança que podem ser usadas para aumentar a segurança da aplicação. Em termos de compatibilidade, as aplicações

Flex são executadas pelo Flash Player, e portanto são compatíveis com todos os browsers e SOs de interesse. Assim, o

programador não tem a preocupação de escrever código adicional para tornar a aplicação compatível em todos os

browsers, pois a aplicação corre como esperado em todas as plataformas.

É precisamente no facto da compatibilidade onde o Ajax, com o uso do HTML5 e CSS3 peca. O HTML5

combinado com o CSS3, JavaScript e PHP no lado do servidor, é sem dúvida uma solução forte e interessante para o

desenvolvimento de websites dinâmicos. O HTML5 e o CSS3 possuem muito mais funcionalidades do que as que foram

apresentadas, mas não estão directamente ligadas e não são necessária à aplicação que se pretende desenvolver. A

grande desvantagem são os problemas de compatibilidade entre os browsers. A aplicação foi testada em três browsers,

o Google Chrome 11, Mozilla Firefox 4 e Internet Explorer 9. É inteiramente compatível com o Google Chrome, e com o

Mozilla. No Internet Explorer 9 a aplicação fica completamente diferente das outras: não constrói a tabela de vista geral,

não coloca os marcadores no mapa, sombras e os cantos redondos e as transformações são completamente

inexistentes. Isto deve-se principalmente à falta de suporte das novas características do HTML5 e CSS3. De realçar que a

aplicação foi testada nas versões mais actualizadas, sendo que nas versões anteriores de alguns browsers a aplicação

fica totalmente irreconhecível. Devido aos problemas de compatibilidade entre os browsers, o programador tem que

escrever código adicional para tornar a aplicação compatível (e.g., na criação do objecto XmlHttpRequest). Existem no

entanto frameworks, como por exemplo a YUI (Yahoo! User Interface Library) que fornecem métodos compatíveis entre

os browsers e que ao mesmo tempo reduzem a quantidade de código da aplicação. Por exemplo, o código apresentado

na Figura 4.9 da subsecção 4.1.2.1 que cria um objecto XmlHttpRequest pode ser substituído pelas linhas:

Request = YAHOO.util.Connect.asyncRequest(‘GET’, ‘PlatService.php’, callback); Callback = {success:GetXmlFile, failure:failureHandler};

Além disso, a YUI fornece suporte noutras áreas, incluindo animações, botões, calendários, gráficos, menus, estilos,

drag and drop, entre outros. Ainda assim, na abordagem Ajax, existe sempre um esforço e uma preocupação adicional e

nem todas as novas características do HTML5/CSS3 são suportadas pelos browsers. Por curiosidade, o site

www.html5test.com classifica o browser de acordo com o suporte das novas características do HTML5. Na altura da

escrita deste documento, a melhor classificação foi obtida pelo Chrome 12.0.742, seguido pelo Opera 11.5, Mozilla

Firefox 5.0, Safari 5.0.5, e por último o Internet Explorer 9 que evidencia ainda sérios problemas de suporte. No geral,

esta abordagem é mais indicada para o desenvolvimento de websites propriamente ditos, blogs, redes sociais e portais;

na verdade, os novos elementos de estrutura, tais como o <article>, <footer>, <header>, <nav> ou <aside>

corroboram esta conclusão. É no entanto uma boa ferramenta para o desenvolvimento de RIA, que ficará mais forte

com o aumento do suporte e cumprimento dos standards web por parte dos browsers.

Por fim, na aplicação JavaFX identificaram-se duas desvantagens principais. A primeira é a integração dos

serviços de mapas na aplicação. O facto de o mapa ser apenas uma imagem, obriga à implementação de raiz dos

controlos de tipo de mapa, zoom, navegação, marcadores, janelas de pop-up e da função de drag and drop. Para se

conseguir que esses componentes e funcionalidades tivessem um aspecto e interactividade idênticos ao das APIs


65

JavaScript e ActionScript, seria necessário um esforço de implementação enorme. O mapa é um dos pontos importantes

da aplicação, e portanto esta é uma limitação que por si só poria de lado o JavaFX. A segunda desvantagem diz respeito

aos componentes disponíveis. A não existência de um componente tabela indica que esta plataforma não é tão indicada

para aplicações empresariais ou de visualização de dados. Na verdade o JavaFX destaca-se na palete de componentes,

mas vários são apropriados para a animação/desenho, nomeadamente formas básicas (círculos, rectângulos, etc.),

animações, transições, cores, gradientes e efeitos. O JavaFX é mais indicado para o desenvolvimento de mini aplicações

multimédia que são normalmente embutidas numa página web, tais como applets, banners e animações. Basicamente é

mais adequado para uma aplicação multimédia do que para o tipo de aplicação pretendida (desktop-like UI). Outras

particularidades foram também identificadas no JavaFX, nomeadamente o facto de a sintaxe ser declarativa e a

estrutura hierárquica, mas não existir a separação entre o comportamento do componente e a sua declaração, pois

ambos são codificados em JavaFX Script. Este aspecto diferencia o JavaFX das outras duas abordagens na medida em

que o Flex e Ajax usam respectivamente AS e JS para os aspectos programáticos e MXML e HTML para os aspectos da

definição da interface respectivamente13.

Concluindo, o Flex foi a plataforma escolhida para o desenvolvimento da aplicação final. Com esta escolha, o

serviço de mapas da Bing fica posto de lado uma vez que com este serviço só seria possível usar as APIs de mapas

estáticos. Assim, a decisão divide-se entre o Google Maps e Yahoo! Maps. Os serviços são semelhantes, pelo que a

escolha não é importante. Assim, por existir uma maior familiarização por parte da generalidade dos utilizadores com o

serviço da Google, este foi o escolhido.

4.2 Comunicação cliente- servidor

O segundo conjunto de experiências diz respeito ao método de comunicação com o servidor. Foram

desenvolvidos dois WebServices (SOAP e REST) simples, um em PHP e outro Java, e vários clientes que consomem os

respectivos serviços. Os serviços disponibilizam apenas uma ou duas operações que retornam a hora actual da máquina

que aloja o servidor em formatos diferentes. É claro que é um serviço muito simplificado, mas para o efeito que se

pretende é suficiente para tirar conclusões. Todas as experiências foram desenvolvidas no NetBeans IDE.

4.2.1 Serviços SOAP Java & PHP

O primeiro WebService SOAP implementado foi em Java. Este pode ser compilado usando a versão Java

Development Kit 6 (JDK6), uma vez que inclui por defeito a Java API for XML WebServices (JAX-WS). Esta API dedicada

aos WebServices suporta serviços baseados em SOAP e REST, e baseia-se fortemente em anotações14. Um WebService

13 O JavaFX 2.0 introduziu a linguagem FXML para definir a interface de uma aplicação JavaFX, logo esta observação só é válida para a versão

analisada nesta tese.

14 Mecanismos da linguagem Java que permite a introdução de metadados sintácticos no código fonte.


66

em Java pode ser implementado numa única classe, mas seguindo as boas práticas de desenho de programas, deve

existir uma interface que declara os métodos (operações do serviço), e uma implementação que define os métodos

declarados na interface. A interface é a Service Endpoint Interface (SEI) e a Service Implementation Bean (SIB) é a

implementação [5]. Foram declarados e implementados dois métodos que retornam a data em formatos diferentes. A

SEI e o SIB estão ilustrados na Figura 4.29. No primeiro caso, a anotação @WebService indica que é uma SEI e a anotação

@SOAPBinding tem impacto na construção do documento WSDL (neste caso concreto define o estilo como sendo rpc, ver

subsecção 2.2.1). Cada método é precedido da anotação @WebMethod que indica que este é uma operação do serviço.

No SIB a anotação @WebService(timeserver.SEI) liga-o à SEI, onde timeserver se refere ao pacote do projecto.

//SEI.java@WebService@SOAPBinding(style = Style.RPC)public interface SEI {

//Inserir operações do WebService@WebMethod String getTimeAsString();@WebMethod long getTimeAsElapsed();

}

//SIB.java//Note-se que a implementação dos métodos não necessita do @WebMethod@WebService(endpointInterface = "timeserverjava.SEI") //@WebService liga ao SEIpublic class SIB implements SEI {

public String getTimeAsString() { return new Date().toString();}public long getTimeAsElapsed() {return new Date().getTime();}

}

FIGURA 4.29 – SEI E SIB DO WEBSERVICE SOAP EM JAVA

Uma vez implementado, é necessário publicar o Web Service. Para isso, pode invocar-se no método main a função

seguinte, que recebe como parâmetros a localização de publicação (URL) e uma instância do SIB:

Endpoint.publish("http://127.0.0.1:9876/JavaTimeSoapServer", new SIB());

A partir deste momento o Web Service pode ser consumido. O documento WSDL (ver Anexo A) é automaticamente

gerado através deste método na publicação do serviço. A Figura 4.30 mostra o envelope SOAP de um pedido e

respectiva resposta. Neste caso, o envelope SOAP de ambos contém apenas o body, respectivamente com a chamada

da operação e os dados de retorno.

<?xml version="1.0" encoding="utf-8" ?><env:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <n1:getTimeAsString xmlns:n1="http://JavaTimeSoapServer/"> </n1:getTimeAsString> </env:Body></env:Envelope>

<?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body><ns2:getTimeAsStringResponse xmlns:ns2="http://JavaTimeSoapServer/"> <return>Mon Jan 24 17:26:32 GMT 2011</return> </ns2:getTimeAsStringResponse> </S:Body></S:Envelope>

FIGURA 4.30 – ENVELOPE SOAP DE UM PEDIDO DE HORA E RESPECTIVA RESPOSTA


67

O PHP possui uma extensão SOAP nativa, que permite a criação de um servidor e cliente SOAP. Esta extensão é

composta por duas classes chave – a classe SoapClient e a classe SoapServer. O processo de criação do servidor é

bastante simples, no entanto, ao contrário do Java que gera automaticamente o documento WSDL na publicação do

serviço, é necessária a escrita do documento WSDL antes da publicação. Assim, aproveitou-se o documento WSDL do

servidor Java e criou-se um servidor SOAP em PHP com as mesmas operações. O código do servidor resume-se à

listagem da Figura 4.31. Cria-se um novo servidor indicando qual o documento WSDL a utilizar, adicionam-se as

operações, e coloca-se o servidor pronto a tratar os pedidos. Neste caso, para publicar o Web Service utilizou-se o

servidor Apache, pelo que apenas é necessário copiar o script PHP do Web Service para a pasta pública do servidor

(e.g.,../apache/www).

<?php //Operações do serviço function GetTimeAsString(){ return date("r",time()); }

function GetTimeAsElapsed(){ return date(time()); } $Server = new SoapServer('TimeWsdl.wsdl'); //Servidor SOAP //Adicionar operações ao servidor SOAP; $Server->addFunction('GetTimeAsString'); $Server->addFunction('GetTimeAsElapsed'); $Server->handle(); //Trata o pedido;?>

FIGURA 4.31 – CÓDIGO DO WEBSERVICE SOAP EM PHP

Como se pode verificar a criação de um WebService SOAP não é de todo complicada em ambas as linguagens.

Repare-se que as operações GetPlatforms() e GetPlatByName() da classe PHP implementada em 4.1.2 poderiam

facilmente ser inseridas neste serviço SOAP. O código destas operações seria o mesmo, bastando instanciar a classe PHP

e adicionar as operações ao serviço SOAP. Como as operações retornam uma plataforma ou um array de plataformas,

este tipo de dados teria que ser adicionado à secção types do documento WSDL (ver subsecção 2.2.1), uma vez que o

serviço retornaria tipos de dados que não são simples.

4.2.2 Clientes SOAP

Com os serviços publicados, pode agora desenvolver-se clientes em linguagens diferentes para consumirem os

serviços e testar a interoperabilidade. A Figura 4.32 resume os clientes desenvolvidos e que consomem ambos os

serviços apresentados na secção anterior.

Foram desenvolvidos clientes nas mesmas linguagens utilizadas em 4.1, e adicionalmente um cliente PHP. O

desenvolvimento deste cliente é especialmente importante devido às limitações impostas pela same-origin policy (SOP).

A SOP é uma medida de segurança que não permite a uma aplicação Ajax enviar pedidos XHR a servidores externos, i.e.

servidores cujo domínio (origem) é diferente daquele de onde a aplicação foi descarregada.


68

FIGURA 4.32 – DIFERENTES CLIENTES SOAP PARA OS WEBSERVICES EM JAVA E PHP

Neste projecto o único servidor externo utilizado é o que fornece o serviço de mapas. No entanto, as APIs de mapas são

utilizadas através da inclusão de scripts externos provenientes de outros servidores - Cross-site scripting (XSS),

conforme ilustrado em 4.1.1.1. Neste cenário a SOP não é imposta. No caso de o XSS não ser opção e caso se pretenda

utilizar o XHR, uma forma de resolver o problema é incluir no servidor da aplicação Ajax um script PHP que funciona

como um proxy (ver Figura 4.33). Esse script é, por sua vez, cliente para o servidor externo. Um script do género poderia

eventualmente ser inserido na aplicação Ajax de 4.1.2 junto das funções que fazem o acesso à BD.

FIGURA 4.33 – PEDIDO XHR A UMA ORIGEM DIFERENTE USANDO O SERVIDOR COMO UM PROXY

A criação de um cliente em Flex é bastante simples. Da mesma forma que se conecta a uma classe PHP, pode

conectar-se a um Web Service SOAP. Para isso, basta usar o wizard de conexão a serviços do Flash Builder e inserir

(quando solicitado) a localização do documento WSDL do serviço. A localização é dada pela URL do serviço com a query

string “?wsdl” anexada; para os Web Services Java e PHP implementados, tem-se respectivamente:

http://localhost:9876/JavaTimeSoapServer?wsdl

http://localhost/TimeServerPhp/PhpTimeSoapServer.php?wsdl


69

O documento WSDL é inspeccionado e é gerado o proxy15 para o cliente. Deste modo, as réplicas das operações do

serviço passam a estar disponíveis na vista “Data/Services”. As RPC são definidas como métodos de uma classe AS

gerada pelo Flash Builder à semelhança do que aconteceu na conexão ao serviço PHP na subsecção 4.1.2. Os Web

Services têm duas operações que retornam a data e hora em formatos diferentes. Arrastando uma das operações para

uma label, o resultado retornado (data e hora) passa a estar vinculado à label, que deste modo apresenta a hora e data

actual retornada pelo serviço (Figura 4.34).

FIGURA 4.34 – CLIENTE SOAP COM O RESULTADO DA OPERAÇÃO GETTIMEASSTRING

Relativamente ao PHP, pode-se usar a extensão SOAP para criar um novo cliente passando a URL do

documento WSDL como parâmetro. Um exemplo simples de um cliente para este caso, resume-se somente às três

linhas de código da Figura 4.35.

<?php $Client = new SoapClient('http://localhost/TimeServerPhp/PhpTimeSoapServer.php?wsdl');$Response = $Client->GetTimeAsString();echo $Response; ?>

FIGURA 4.35 – CRIAÇÃO DE UM CLIENTE SOAP EM PHP

Este código cria um cliente SOAP, invoca a operação GetTimeAsString() e imprime a resposta no ecrã. Repare-se que

neste caso a URL do documento WSDL diz respeito ao WebService em PHP. No entanto basta passar a URL do

documento WSDL da versão Java para que este cliente consuma o WebService Java.

No Java existem duas maneiras de criar um cliente SOAP – através da inspecção automática do documento

WSDL, e manualmente através da API JAX-WS. A primeira é obviamente mais simples, mas são apresentadas as duas

alternativas de modo a evidenciar os benefícios do WSDL. A implementação manual do cliente requer a leitura do

documento WSDL, para, e.g., se conhecer as operações disponíveis e proceder à implementação da SEI manualmente. É

a secção portType que apresenta o nome das operações do serviço (ver Anexo A). A Figura 4.36 apresenta o cliente

Java, que utiliza a URI do serviço e o nome do serviço para criar uma instância do mesmo para acesso local. Depois

utiliza o método getPort() para obter a interface (o proxy), e poder invocar os métodos que fazem parte dela. Nada

de complicado, mas mais uma vez o programador tem que saber interpretar o documento WSDL e implementar a SEI

manualmente.

15

Código, classe ou função, que encapsula a conversão de parâmetros e, respectivamente, a invocação dos métodos de uma classe ou de uma função

remota.


70

//Localização da publicação do WebServiceURL myURL = new URL("http://localhost:9876/JavaTimeSoapServer?wsdl");//Nome do serviço (Qualified Name)//1º argumento - a URI do serviço;//2º argumento - o nome do serviço publicado (Class SIB com o Service à frente)QName myQName = new QName("http://TimeServer/","SIBService");//Criar efectivamente o acesso ao serviço;Service myService = Service.create(myURL,myQName);//Extrair a SEI (Service Endpoint interface);SEI eif = myService.getPort(SEI.class);System.out.println(eif.getTimeAsString());

FIGURA 4.36 – IMPLEMENTAÇÃO MANUAL DE CLIENTE SOAP EM JAVA

O NetBeans permite, a partir do documento WSDL, gerar várias classes numa subdirectoria do projecto que

ajudam à implementação do cliente. Foram geradas duas classes: uma é a interface que declara os métodos disponíveis

pelo serviço (semelhante à classe SEI original do servidor Java), e outra que possui um construtor que cria o serviço

através da URI do WebWervice e do nome do serviço (ambos obtidos automaticamente do documento WSDL). Por fim,

este serviço encapsula o método getSIBPort(), que retorna uma instância do tipo SEI, que por sua vez suporta as

operações do serviço. Desta forma é mais fácil escrever um cliente, pois existem detalhes, nomeadamente a URI, que

ficam transparentes ao programador do cliente, mas principalmente porque não é necessária a escrita manual da SEI.

Assim, o mesmo cliente Java resume-se a três linhas de código:

SIBService myService = new SIBService();SEI port = myService.getSIBPort();

System.out.println(port.getTimeAsString());

FIGURA 4.37 – CLIENTE SOAP EM JAVA COM GERAÇÃO DE CÓDIGO SUPORTE AO CLIENTE

O JavaFX, não possui por defeito uma API que permita a conexão a um WebService SOAP. No entanto, este

pode interagir directamente com qualquer classe Java. Assim, o processo de conexão é exactamente o mesmo usado no

Java. Basta, e.g., importar as classes geradas (SIBService e SEI) para o cliente Java, e criar uma classe (SOAPClient)

que na realidade é o cliente, i.e., usa a SEI para obter o proxy definindo dois métodos que retornam o resultado das

operações do serviço. Esta classe pode ser instanciada no JavaFX como apresentado na Figura 4.38. Depois podem

invocar-se os métodos (e.g., com um clique no botão) no cliente JavaFX e apresentar o resultado numa Label.

var SOAP:SOAPClient = SOAPClient{};

var SoapTime = SOAP.getTimeAsString();def timeSOAPLabel = Label{ text: bind {SoapTime}}

FIGURA 4.38 – CLIENTE SOAP EM JAVAFX

Por fim, o caso do Ajax é ligeiramente diferente dos restantes. Aqui não existe inspecção do documento WSDL

automática e geração de código. Repare-se que em todos os outros casos pode invocar-se métodos no lado do cliente

idênticos às operações disponibilizadas pelo serviço (utilizando o proxy). As ferramentas tratam de gerar métodos na

linguagem do cliente, que encapsulam o pedido HTTP e a construção do envelope SOAP, cujo corpo contém a operação


71

a invocar. Como o JavaScript não suporta nativamente o SOAP são necessários os seguintes passos para a criação do

cliente [46]:

• Criar o envelope SOAP;

• Serializar a informação específica da aplicação em XML;

• Criar o corpo do envelope SOAP com a versão serializada da informação específica da aplicação;

• Enviar um pedido HTTP através do objecto XmlHttpRequest contendo a mensagem SOAP;

• Definir a função de callback do pedido, que fica responsável por analisar a resposta com o envelope SOAP,

e extrair a informação pretendida.

A Figura 4.39 apresenta a função load() que é chamada na criação do corpo da página HTML. Esta função executa os

passos referidos acima. Faz-se um pedido HTTP POST para encapsular o envelope SOAP, que é criado manualmente a

partir da interpretação do documento WSDL. Depois, a função de callback é chamada quando há alteração no estado do

pedido HTTP, e se este tiver sido efectuado correctamente é ainda necessário extrair a informação pretendida do

envelope. Como o envelope é um documento XML, pode-se aceder à marcação que contém a resposta da operação

através do DOM. Neste caso, a resposta contém a data e hora como uma string, que é colocada no corpo da página

HTML.

function load(){//Fazer uma chamada XMLHttpRequestrequest = new AjaxRequest();//No SOAP é preciso um POST para encapsular o SOAP env. no corpo da mensagem HTTPrequest.open("POST", "http://localhost/TimeServerPhp/PhpTimeSoapServer.php?wsdl", true);request.setRequestHeader("Content-Type", "text/xml; charset=utf-8");//Construir o Envelopevar mySOAP = "<SOAP-ENV:Envelope xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\""+ "xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"" + "xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">"+ "<SOAP-ENV:Body><tns:getTimeAsString xmlns:tns=\"http://TimeServer/\"/>" + "</SOAP-ENV:Body></SOAP-ENV:Envelope>"//Fazer o pedido, e enviar o envelope no corporequest.send(mySOAP);request.onreadystatechange = function(){

if (request.readyState==4) {if(request.status==200) {

//Carregar o envelope SOAPvar xml = this.responseXMLvar TimeAsString = xml.documentElement.getElementsByTagName('return')document.getElementById('myBody').innerHTML = TimeAsString[0].firstChild.node;

}}

}}

FIGURA 4.39 – CÓDIGO REFERENTE AO CLIENTE SOAP AJAX

Este processo pode tornar-se moroso para envelopes SOAP de grande dimensão, pois é necessário criar o pedido e

extrair a resposta manualmente. Em alternativa, é sempre possível invocar um script PHP ao servidor, que por sua vez é

um cliente SOAP. Neste caso, a implementação é mais simples mas o processamento fica no lado do servidor, uma vez

que o PHP não corre no browser.


72

4.2.3 Serviços REST Java & PHP

Em Java é possível programar serviços REST com recurso a várias APIs. Por exemplo a JAX-WS (API usada para o

SOAP), a Java API for RESTful Web Services (JAX-RS) (API dedicada ao desenvolvimento de aplicações RESTful), ou usar as

APIs de HTTP e XML. Optou-se por usar a API JAX-RS para este caso, uma vez que é dedicada especificamente ao REST.

Para publicar o WebService utilizou-se o servidor Glassfish, onde o serviço foi instalado com a ajuda do Netbeans (opção

deploy). Normalmente num serviço REST começa-se pela sua modelação, que consiste na atribuição de uma URI a cada

recurso, definição do formato de dados, ou seja, do formato das representações de cada recurso, e por fim na

atribuição de um método HTTP a cada recurso. Como este é um serviço muito simples, pode resumir-se tudo nas duas

linhas da Tabela 9. É necessário que exista uma combinação única entre a URI e o método HTTP para cada recurso.

Como as duas operações de leitura da hora utilizam o método GET, atribui-se uma URI relativa diferente para cada

operação. Eventualmente, se o serviço tivesse uma operação para mudar a hora no servidor e outra para apresentar a

hora actual, ambas as operações poderiam partilhar a mesma URI relativa, como por exemplo:

POST /Timeserver HTTP/1.1

GET /Timeserver HTTP/1.1

Repare-se que nenhuma das URIs da Tabela 8 identifica a operação que se vai utilizar, apenas sugere o formato da data

que a operação retorna.

TABELA 9 – MAPEAMENTO DAS URI E VERBOS HTTP

Método HTTP URI Formato de Dados Descrição

GET /TimeServer/string XML Retorna Data e hora como uma String

GET /TimeServer/long XML Retorna Data e hora em milissegundos desde 1 de

Janeiro de 1970

Mais uma vez, foram criadas uma interface e uma classe que implementa a interface, algo análogo ao SEI/SIB

no WebService SOAP. A interface é muito simples e está apresentada na Figura 4.40. Um serviço JAX-RS também usa

anotações para mapear um pedido especifico nos métodos que o Web Service dispõe. Cada método é precedido das

anotações que indicam o respectivo verbo/método HTTP (neste caso ambos @GET) e o caminho relativo (@Path) a

utilizar para o executar, e a anotação @Produces que indica o formato da resposta que a operação retorna (XML em

ambos os casos).

Na Figura 4.41 é listado o código que implementa a interface anterior. A anotação (@Path), porque é específica

do JAX-RS, indica que a classe TimeServer é um serviço JAX-RS. Esta anotação define também a URI relativa do serviço.

Esta é concatenada com a URI definida pela anotação @Path na Figura 4.41 para formar um caminho para método no

servidor web. Portanto, se a URI base do WebService for:

Http://localhost:8080/


73

package Timeserver;

import javax.ws.rs.GET;import javax.ws.rs.Path;import javax.ws.rs.Produces;import javax.xml.transform.Source;

public interface TimeServerInterface {

@GET @Path("string") @Produces("application/xml") public Source GetTimeAsString(); @GET @Path("long") @Produces("application/xml") public Source GetTimeAsElapsed();}

FIGURA 4.40 – INTERFACE DO WEB SERVICE RESTFULL EM JAVA

A absoluta será:

Http://localhost:8080/TimeServer

Consequentemente, para aceder a cada um dos métodos adiciona-se à URI relativa o caminho /string ou /long.

@Path("TimeServer")public class TimeServer implements TimeServerInterface {

@Override public StreamingOutput GetTimeAsString() { //Retorna um documento XML return new StreamingOutput() { @Override public void write(OutputStream output) throws IOException, WebApplicationException {

PrintStream Ps = new PrintStream(output); Ps.println("<TimeServer>"); Ps.println("<TimeAsString date = \"" + new Date() + "\"/>"); Ps.println("</TimeServer>"); } }; } @Override public StreamingOutput GetTimeAsElapsed() { //Retorna <TimeServer><TimeAsElapsed date …/></TimeServer> } }; }

FIGURA 4.41 – CLASSE TIMESERVER

Ambas as operações retornam um documento XML com a data e hora actuais em formatos diferentes. Repare-se que se

construiu o documento XML manualmente através de um OutputStream. Na API JAX-RS, quando se pretende escrever

a resposta manualmente, tem que se implementar e retornar uma instância da interface StreamingOutput. Esta é uma

interface de callback constituída apenas pelo método de callback write(). Quando a JAX-RS estiver pronta para enviar

o corpo da resposta a um pedido, o método write() é chamado para criar a representação em XML [14]. Usou-se uma

implementação anónima de StreamingOutput, dentro dos métodos da classe TimeServer, porque a interface é muito

pequena e raramente reutilizada, não fazendo sentido criar uma classe para a implementar. Existem outros métodos de

criação de documentos na JAX-RS, e.g., através da framework JAXB, que permite converter automaticamente objectos

Java em XML e XML Schema. No entanto, neste caso o documento é muito pequeno e pode ser escrito manualmente


74

com facilidade. Uma vez que a resposta é em XML, o browser tem por defeito a capacidade de o interpretar, e por isso

pode testar-se o serviço inserindo a URL no browser.

No caso do PHP existem também várias frameworks de apoio ao desenvolvimento de aplicações RESTful. No

entanto, o desenvolvimento do serviço sem recorrer a APIs adicionais é relativamente simples. A Figura 4.42 apresenta

o código referente ao servidor REST em PHP. O servidor verifica através do array (global) $_SERVER(PATH_INFO) se a

URL possui parâmetros (neste caso /string ou /long) e separa-os para poderem ser manipulados individualmente. Por

exemplo, considere-se a URL:

http://localhost/RestfulPhpTimeServer/TimeServer.php/string

Esta URL possui apenas 1 parâmetro (tudo o que vem a seguir ao .php), pelo que a função explode retorna um array

com as seguintes posições e respectivo conteúdo:

• 0: “” (vazio porque a string começa com o caracter delimitador definido na função explode (/string))

• 1: “string”

Posto isto, o serviço precisa apenas (porque só se pretende ler dados) de verificar se o pedido é um GET e qual o

parâmetro passado. Depois, o serviço cria um documento XML apenas com o elemento que contém a data e hora no

respectivo formato. Note-se que este é um exemplo muito simplificado, e portanto usa-se o echo para escrever

manualmente o documento XML. Por outro lado, repare-se que um serviço REST pode ser desenvolvido sem a adição de

software adicional. Para a publicação do serviço usou-se novamente o servidor Apache.

<?phpfunction GetTimeAsString() { $Date = date("r", time()); echo"<TimeServer>"; echo"<TimeAsString date= \"$Date\">"; echo"$Date"; echo"</TimeAsString>"; echo"</TimeServer>"; }

function GetTimeAsElapsed() { $Date = date(time()); echo"<TimeServer>"; echo"<TimeAsElapsed date= \"$Date\">"; echo"$Date"; echo"</TimeAsElapsed>"; echo"</TimeServer>"; }

header("Content-type: text/xml"); if (isset($_SERVER['PATH_INFO'])) { //Verificar se existem parâmetros na URL $path_params = explode('/', $_SERVER['PATH_INFO']); //Separar os parâmetros Da URL if ($_SERVER['REQUEST_METHOD'] == 'GET') { //Verificar se o Verbo é um GET if ($path_params[1] == 'string') { GetTimeAsString(); } else if ($path_params[1] == 'long') { GetTimeAsElapsed(); } } else echo "Only GETs allowed"; }?>

FIGURA 4.42 – CÓDIGO REFERENTE AO WEBSERVICE REST EM PHP


75

Os dois serviços produzem, dependendo da operação a realizar, o mesmo documento XML (Figura 4.43).

Repare-se que a data está inserida como um atributo de um elemento. Isto resulta num acesso facilitado por parte dos

clientes, pois todos possuem métodos que permitem o acesso aos atributos de um elemento através do nome do

atributo.

//GetTimeAsString<TimeServer><TimeAsString date="Mon, 22 Aug 2011 15:35:29 +0000"/></TimeServer>

//GetTimeAsElapsed<TimeServer><TimeAsElapsed date="1314027346"/></TimeServer>

FIGURA 4.43 – RESPOSTA DOS WEBSERVICES REST EM XML

4.2.4 Clientes REST

Qualquer linguagem de programação que possua, tipicamente, APIs para HTTP e XML/JSON pode consumir um

WebService Restful. Os clientes REST foram implementados nas mesmas linguagens que os clientes SOAP, e portanto

podem ser resumidos através da Figura 4.32 da subsecção 4.2.2. De um modo geral, o procedimento para a criação de

um cliente REST é o seguinte:

• Constrói-se um documento XML se a operação a utilizar não for um GET, uma vez que um GET não possui

corpo. O corpo da mensagem HTTP encapsula o documento XML;

• Envia-se o pedido HTTP. Este deve ser coerente com o tipo de acção que o serviço irá efectuar, ou seja,

GET para leituras, DELETE para apagar recursos, etc.

• Recebe-se a resposta em XML, e processa-se o documento de modo a extrair a informação desejada.

No Flex, este processo pode ser feito de forma automática através do wizard de conexão a um serviço HTTP do

Flash Builder. Para isso, insere-se quando solicitado a URL do recurso ao qual se pretende aceder. O Flash Builder

inspecciona o documento XML retornado e cria as operações equivalentes no lado do cliente, i.e., uma classe proxy em

AS.

No caso do PHP, o processo também é o descrito acima, mas não é obviamente feito de forma automática.

Para o cliente utilizou-se inicialmente a Zend framework, mas o seu funcionamento (na versão mais recente da altura da

escrita deste documento) viola as regras da filosofia REST, pois inclui na URL do pedido o nome do método a invocar,

definindo assim uma espécie de “mini-rpc”. Isto significa que o serviço espera que o nome de uma das operações do

serviço esteja presente na URL. Por exemplo, imagine-se que é feito um pedido da data e hora actuais ao Web Service

PHP descrito em 4.2.3. A URL correcta seria:

http://localhost/RestfulPhpTimeServer/TimeServer.php/string

Em contraste, a URL utilizando a Zend framework seria algo do género:


76

http://localhost/RESTfulPhpTimeServer/TimeServer.php?method=GetTimeAsString

Deste modo optou-se pela utilização das extensões nativas de HTTP e XML que o PHP fornece. Para o HTTP, usou-se a

biblioteca Client URL Request Library (CURL), e para o XML utilizou-se a SimpleXML. Como se pode verificar pela Figura

4.44, define-se a URL do recurso e indica-se à CURL para não imprimir a resposta automaticamente através da opção

CURLOPT_RETURNTRANSFER. Depois, define-se o método a utilizar, neste caso o GET, e envia-se o pedido. A resposta em

XML é tratada de forma a se extrair a informação pretendida. Este excerto de código apresenta a ligação ao serviço PHP,

e corresponde à operação que retorna a data e hora como uma string. Com a excepção da URL, o mesmo código pode

ser utilizado para consumir o serviço em Java e aceder às outras operações. ?php

//Fazer a ligação HTTP;//Como é um GET, não é preciso fazer um doc XML;$url = 'http://localhost/RestfullPhpTimeServer/TimeServer.php/string';$client = curl_init($url);//Esta opção indica à CURL para não imprimir a resposta automáticamente;curl_setopt($client, CURLOPT_RETURNTRANSFER, true);//Definir o método HTTP;curl_setopt($client, CURLOPT_HTTPGET, true);$response = curl_exec($client);curl_close($client);//Extrair do documento XML$xml = new SimpleXMLElement($response);$TimeAsString = $xml->TimeAsString[0];$attributes = $TimeAsString->attributes();echo $attributes['date'];?>

FIGURA 4.44 – CLIENTE REST PHP. PEDIDO DA DATA E HORA COMO UMA STRING

O cliente REST em Java pode também ser gerado com a ajuda do Netbeans. O IDE cria a classe proxy cliente,

com um atributo referente à URI de base do serviço. Esta URI é complementada pelo restante caminho associado às

operações do serviço (e.g., /string, /long), também gerado pelo IDE. Pode-se depois instanciar a classe

(TimerServerClient) e invocar os métodos gerados, conforme é feito na Figura 4.44. Resta depois extrair a informação

pretendida do documento XML. Para isso existem várias APIs (built-in no JDK) Java que permitem a manipulação de

documentos XML, nomeadamente a Simple API for XML (SAX), o DOM e a Java API for XML Processing (JAXP). Como se

pode ver pela mesma figura, utilizou-se a API DOM, pelo que a análise não foi feita manualmente. Basta passar o

documento XML retornado pela operação do serviço para o método parse. A partir daí, o cliente tem acesso aos

nodos, elementos e respectivos atributos.

TimeServerClient myClient = new TimeServerClient();DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();Document doc = builder.parse(myClient.GetTimeAsString(InputStream.class));NodeList nList = doc.getElementsByTagName("TimeAsString");Node TimeAsString = nList.item(0);Element el = (Element) TimeAsString;System.out.println(el.getAttribute("date"));

FIGURA 4.45 – ANÁLISE DO DOCUMENTO XML EM JAVA ATRAVÉS DA API DOM

O JavaFX pode por sua vez usar o mesmo mecanismo, ou usar as suas própRIA APIs HTTP e XML para se

conectar a um serviço REST. A segunda abordagem é apresentada na Figura 4.46, onde se definem duas funções. A

primeira trata da conexão HTTP e declara um objecto do tipo HttpRequest, que possui atributos como o método a

utilizar, a URL e uma função de callback referente ao evento lançado quando existe uma resposta (onInput). Essa


77

resposta é passada para a função que analisa o documento XML como uma InputStream. Esta função define um

analisador que tem a capacidade de analisar documentos JSON ou XML. Neste caso, definiu-se o tipo de documento

como XML. O atributo onEvent define uma função de callback que é invocada sempre que um nodo do documento é

encontrado [45]. Assim, verifica-se se existe um primeiro elemento de marcação, e se não existir termina-se a execução

da função. Como para este caso só existe um elemento de interesse, verifica-se o nome do mesmo; se for o nome

esperado passa-se o atributo date, para a variável time. Esta variável é depois apresentada no ecrã com a data e hora

actual.

public function HttpConn() {

var http:HttpRequest = HttpRequest {method: HttpRequest.GET;location: url;onInput: function(Is: InputStream) {

try { parseXML(Is);} finally {

Is.close();}

}}http.start();

}

public function parseXML(input: InputStream) {

def Parser = PullParser {documentType: PullParser.XML;input: input;onEvent: function(event:Event): Void{

if(not (event.type == PullParser.START_ELEMENT)){return;

}if(event.level == 0 and event.qname.name == "TimeAsString"){ time = event.getAttributeValue("date") as String }

}}

Parser.parse();}

FIGURA 4.46 – CONNEXÃO HTTP E ANÁLISE XML NO CLIENTE JAVAFX

Para finalizar, resta o cliente Ajax. Aqui pode usar-se o objecto XHR e depois usar o DOM para extrair a

informação do documento XML como foi feito na aplicação apresentada na subsecção 4.1.2. A Figura 4.47 apresenta a

listagem correspondente à conexão HTTP e análise do documento XML retornado pelo serviço PHP. O processo consiste

em enviar o pedido HTTP através do XHR, e definir a função de callback referente à mudança do estado do pedido

(onreadystatechange). Esta extrai a data e hora do documento XML e insere-a num elemento HTML.

Concluindo, desenvolveram-se vários clientes, em várias linguagens, que consomem um serviço REST em PHP

ou em Java. É de realçar que em nenhuma das implementações dos clientes foram necessária APIs ou frameworks

adicionais, pois todas as linguagens possuem por defeito suporte HTTP e XML. A Figura 4.48 apresenta o cliente Flex a

aceder em simultâneo aos quatro WebServices implementados, dois SOAP e dois REST.


78

function load(){//Fazer uma chamada XMLHttpRequest:request = new AjaxRequest()request.open("GET", "http://localhost/RestfullPhpTimeServer/TimeServer.php/string", true)request.send(null)//A função o GetXmlFile é o eventhandlerrequest.onreadystatechange = GetXmlFile

}function GetXmlFile(){

if(request.readyState == 4 && request.status == 200){

//Carregar o doc XML:var xml = this.responseXMLvar TimeAsString = xml.documentElement.getElementsByTagName('TimeAsString')document.getElementById('myBody').innerHTML = TimeAsString[0].getAttribute('date')

}}

FIGURA 4.47 – CONEXÃO HTTPE ANÁLISE XML NO CLIENTE AJAX

FIGURA 4.48 - CLIENTE FLEX EM COMUNICAÇÃO COM OS QUATRO WEBSERVICES EM SIMULTÂNEO

4.2.5 Conclusão

Nas últimas secções foram descritas várias aplicações baseadas em Web Services. Foi possível através destas

experiências perceber as abordagens SOAP e REST, bem como as suas diferenças. Ficou também evidente a importância

dos Web Services para a distribuição de serviços e interoperabilidade entre o software, e por isso os Web Services são

uma ferramenta de extrema importância para qualquer programador.

A comparação entre os Web Services SOAP e REST é uma discussão usual, e tanto o REST como o SOAP, têm os

seus proponentes. Ambas as abordagens têm características diferentes e podem coexistir pacificamente [5]. O REST,

argumenta que os standards envolvidos no funcionamento da internet são suficientes e possuem vantagens. Uma delas

é o facto de que qualquer recurso (nome) poder ser identificado por uma URL. Os clientes manipulam esse recurso

através dos comandos HTTP, como o GET, PUT, ou DELETE, ou seja, o enfâse é na diversidade de nomes. O SOAP, pelo

contrário, enfatiza a diversidade de comandos do protocolo (verbos), pois segue uma abordagem RPC. Portanto, o REST


79

utiliza uma interface amplamente conhecida (URI) e explora o que o HTTP oferece, sendo que o SOAP acrescenta o seu

próprio protocolo, e portanto, não tira partido directo do HTTP, apesar de funcionar quase sempre sobre este.

Um tópico importante é a utilização da largura de banda. Um dos benefícios do REST é que os pedidos e

respostas podem ser mais curtos, resultando numa latência de interacção menor. O SOAP, por outro lado, necessita

sempre da construção do envelope e das definições dos namespaces para cada mensagem. Uma determinada resposta

em SOAP, necessita de um maior número de bytes do que a mesma resposta em REST. Além disso, isto resulta num

melhor desempenho dos serviços REST em geral que é também inerente à sua simplicidade [8]. Segundo a Amazon [8],

que disponibiliza serviços SOAP e REST, executar queries às suas BDs através do serviço REST é seis vezes mais rápido

que o serviço SOAP.

No que diz respeito à complexidade, o REST é baseado nos standards usados intensivamente na Web, e

portanto não necessita de especificações adicionais. Isto evita a dependência a uma plataforma em especifico e reduz a

ocupação de recursos do sistema [8]. Por exemplo, o REST usa directamente o protocolo HTTP para a troca de dados.

No entanto, os envelopes SOAP são normalmente transparentes ao programador, que não têm que se preocupar com a

escrita do documento XML a enviar, e com a análise desse mesmo documento na recepção. Cada lado, cliente e serviço,

só tem que ter uma biblioteca local que permita a serialização e des-serialização dos dados em SOAP/HTTP [5]. Assim, a

complexidade relativa às mensagens SOAP e comunicação via rede é praticamente eliminada pela biblioteca. Isto foi

perceptível nas experiências realizadas; o Java, PHP e Flex, possuem ferramentas que permitem a geração das

operações no lado do cliente, e que encapsulam toda a construção do envelope SOAP. Em nenhum deles foi necessária

a construção do envelope no pedido e na resposta. Em contraste, no caso do Ajax, foi necessária a construção e

extracção manual do envelope SOAP. No que diz respeito às aplicações RESTful implementadas, com a excepção do

cliente Flex (que faz o parse do XML automaticamente), foi sempre necessária a construção e análise do documento

XML. Isto pode tornar-se num processo moroso e difícil, quando se lida com documentos XML grandes e complicados. A

vantagem é que não é de todo necessária, a instalação de bibliotecas adicionais, embora haja a necessidade de se

entender com mais profundidade o protocolo HTTP e o processamento de XML. Por outro lado, com uma boa base de

conhecimento de HTTP e XML fazer o debug no REST é simples, uma vez que se “pode ver” com mais facilidade o que se

está a passar [47]. Em contraste, no SOAP, procurar um erro pode ser uma tarefa difícil pois analisam-se envelopes

SOAP e especificações [47].

O SOAP possui o documento WSDL que define as suas operações; não existe um standard equivalente para o

REST [16]. A existência de um contracto entre o serviço e o seu consumidor, ou seja o WSDL, é do ponto de vista do

programador uma grande vantagem, pois pode ser usado para gerar código de suporte à escrita do cliente. De facto,

uma das grandes desvantagens do REST é a falta de um contracto deste tipo, de forma a suportar a codificação do

cliente. No caso, possivelmente bastante comum, em que o programador do cliente não é o mesmo que o programador

do servidor, o programador terá que obrigatoriamente ter informações acerca dos formatos das URI de cada recurso e

dos métodos que podem ser utilizados com cada URI (além do contexto em que uma determinada operação se insere

no mundo real, mas aqui, nem o WSDL fornece essa informação). Por isso, existem já iniciativas para a introdução de

um documento desse tipo. O Web Applications Description Language (WADL) (iniciativa Sun Microsystems) é desenhado


80

para ser uma alternativa simples ao WSDL para aplicações XML/HTTP [16]. O WADL age como um contracto, que

semelhantemente ao WSDL descreve o serviço e permite facilitar a escrita do cliente ao programador. A adopção de um

formato standard deste género seria de grande vantagem para o REST.

Até aqui, e ao longo do capítulo 4, para além dos WebServices SOAP e REST foram utilizadas outras tecnologias

de comunicação que são válidas no âmbito do projecto. A Tabela 10 apresenta os clientes e servidores implementados

para cada tecnologia de comunicação. A primeira coluna identifica a linguagem de programação do cliente, e a primeira

linha identifica uma tecnologia de comunicação. A correspondência entre um cliente e tecnologia de comunicação

indica se houve implementação do cliente e servidor (Java ou PHP), numa dada tecnologia de comunicação.

TABELA 10 – ABORDAGENS DE COMUNICAÇÃO IMPLEMENTADAS E TESTADAS NAS EXPERIÊNCIAS AO LONGO DA DISSERTAÇÃO.

SOAP REST (HTTP + XML) HTTP JDBC AMF

Flex Java, PHP Java, PHP

PHP

Java Java, PHP Java, PHP

PHP Java, PHP Java, PHP

JavaFX Java, PHP Java, PHP

MySQL

Ajax Java, PHP Java, PHP Java, PHP

No cliente Flex usou-se o Remoting/AMF para a comunicação com um script PHP no lado do servidor, no JavaFX usou-se

directamente o JDBC para a comunicação com a BD, e no Ajax usou-se o HTTP, que não é considerado REST pois não foi

feita a modelação de um serviço, ou seja, mapeamento entre URIs e verbos HTTP.

Pelas razões referidas em 4.1.5, a JDBC fica de lado. Além disso, a alternativa JDBC coloca o Flex de parte, que é

a opção mais vantajosa em termos de GUI. O HTTP pode realmente ser utilizado mas na forma de um serviço REST, até

porque seria necessário escolher um formato de dados (provavelmente XML) para garantir a interoperabilidade entre a

aplicação cliente e servidora, fazendo todo o sentido modelar um serviço REST. Assim, resta escolher entre o SOAP,

REST e AMF. Entre estes, o AMF parece ser a melhor opção face aos requisitos impostos, isto por duas razões principais.

A primeira é porque a implementação do servidor é mais simples, ou seja, basta escrever um script PHP, que na verdade

é uma classe composta por uma variedade de métodos que fazem o acesso à BD. A classe é inspeccionada e os métodos

ficam disponíveis no lado do cliente. Não é necessário construir uma resposta em XML, nem um envelope SOAP. No

cliente também não é necessária a análise de qualquer tipo de documento. De facto, a transparência é de um nível tão

elevado que o programador só precisa de escrever o script PHP com as operações pretendidas e usá-las no lado do

cliente através da classe proxy gerada. A segunda razão é a rapidez da transferência. Como o Remoting/AMF usa um

formato binário, a velocidade de transferência final é muito superior. Na verdade a diferença de rapidez de

transferência entre o Remoting/AMF e o SOAP/REST é extraordinária, principalmente para grandes quantidades de


81

dados. O website http://www.jamesward.com/census2/ permite comparar, entre outros aspectos, o tempo total de um

pedido Remoting/AMF, SOAP ou REST (XML) de um cliente Flex. Para testar, efectuou-se o pedido de um objecto

complexo (contém atributos do tipo String, e possivelmente inteiros) que retorna 20000 linhas de resultados. No AMF,

os resultados foram obtidos em 1,9 segundos, dos quais apenas 40 milissegundos foram gastos na serialização. Já no

XML, o tempo total do pedido para os mesmos dados foi de 33,5 segundos, dos quais 1,5 segundos foram para a

serialização. Por fim, no SOAP o tempo total foi de 42 segundos, sendo que praticamente metade do tempo é devido à

serialização. Ora, estes resultados fazem todo o sentido, principalmente no tempo de serialização. É mais moroso

analisar um documento XML, e muito mais moroso analisar um envelope SOAP pelas razões esclarecidas anteriormente

ainda nesta subsecção. Como se pode verificar a diferença é significativa e, uma vez que a aplicação terá um número de

plataformas elevado, cada uma com vários atributos e uma grande quantidade de sensores, o tempo de transferência é

muito importante. É claro que existem desvantagens; a principal é que o AMF é um protocolo proprietário, e portanto

só é compatível com clientes das plataformas Adobe Flash. Outra questão é que é necessária a instalação de

frameworks adicionais no lado do servidor, pois apenas as plataformas Flash suportam o AMF nativamente. No entanto,

linguagens server-side como o PHP, Java, linguagens .Net, Phyton e Ruby suportam o AMF através de frameworks. Em

todo o caso, o serviço pode ser transformado num WebService SOAP ou REST com relativa facilidade, pois o código no

lado do servidor é uma simples classe, e portanto é altamente reutilizável. Suponha-se o caso de um serviço em PHP,

tendo em conta as implementações dos serviços em 4.2.1 e 4.2.3. Para uma implementação AMF basta a criação de

uma classe PHP (com os respectivos métodos) ordinária, i.e., independente da componente AMF; a framework trata do

resto. Portanto, a mesma classe pode ser usada e instanciada num outro script PHP que cria um novo servidor SOAP e

adiciona os métodos ao serviço (Figura 4.49). O senão é que é preciso escrever o documento WSDL. No caso do REST a

classe pode também ser reutilizada. No entanto, ao invés de se adicionar as operações ao serviço, é necessária a

ponderação e respectivo mapeamento das URI e verbos HTTP para cada recurso. Depois, de acordo com a URI do

pedido, chama-se um dos métodos que faz o acesso à BD (e.g., GetPlatforms() da Figura 4.49) e constrói-se um

documento XML com a informação retornada.

<?phpclass PlatService {

public function GetPlatforms(){/*Connecta à BD e retorna todas as plataformas*/} public function GetPlatByName($name){//Conecta à BD e retorna uma plataforma dado um nome*/}}?>

<?phprequire_once 'PlatService.php'

$platService = new PlatService();$soapServer = new SoapServer(someWSDL);//Adicionar as operações:$soapServer->addFunction($platService->GetPlatforms());$soapServer->addFunction($platService->GetPlatByName());[...]?>

FIGURA 4.49 – USO DOS MÉTODOS DE UMA CLASSE PHP COMO OPERAÇÕES DE UM SERVIÇO SOAP

http://www.jamesward.com/census2/


83

5 Descrição do protótipo

Com base na análise feita no capítulo anterior, foi escolhida a arquitectura apresentada na Figura 5.1.

FIGURA 5.1 – ARQUITECTURA DA APLICAÇÃO

Este capítulo descreve o protótipo desenvolvido, com ênfase no lado do servidor e cliente, por esta ordem. A

descrição do lado do servidor inclui a construção da BD e os scripts PHP com as operações que fazem o acesso à BD. No

cliente é analisada a aplicação Flex com o auxílio a diagramas UML e respectivo código quando considerado relevante.

Ao mesmo tempo, evidenciam-se, tanto no lado do cliente como no servidor, as dificuldades encontradas e as

características/funcionalidades implementadas.

5.1 Servidor

5.1.1 Construção da Base de Dados

O MySQL é provavelmente o Relational Database Management System (RDBMS) mais popular e mais usado em

servidores web [41]. É de livre utilização, rápido, altamente escalável, e robusto [41], e portanto foi a tecnologia

escolhida para armazenar a informação das plataformas.

Um bom começo para o desenho de uma BD, é listar um conjunto de queries prováveis. Normalmente se se

planeia fazer muitas pesquisas sobre um determinado item, é razoável que esse item tenha uma tabela própria. De

seguida listam-se algumas questões, que identificam a informação que a aplicação cliente necessita:

1. Quantas plataformas existem?

2. Qual o nome desta plataforma?

3. Qual a latitude e longitude desta plataforma?

4. A que grupo pertence esta plataforma?

5. Quais as plataformas em mau estado?


84

6. Qual o estado desta plataforma?

7. Quais os sensores desta plataforma?

8. Quantos sensores tem esta plataforma?

9. Qual o estado deste sensor?

10. Qual o valor deste sensor?

Através destas questões pode-se concluir que existem muitas pesquisas relacionadas com as plataformas e

com os sensores. Claro que existem mais pesquisas que podem ser feitas, mas este pequeno exemplo dá uma ideia das

tabelas e respectivas colunas que devem ser criadas. Portanto, criaram-se duas tabelas principais – platforms e

sensors para as plataformas e sensores respectivamente. Estas duas tabelas permitem com que a aplicação seja

independente do número de plataformas e do número de sensores. Assim, é possível a qualquer altura adicionar novas

plataformas e sensores para cada plataforma. No entanto, a BD não se resume apenas a estas duas tabelas. Com o

desenrolar do trabalho, a BD foi crescendo de acordo com os requisitos impostos e foram criadas mais quatro tabelas. O

diagrama relacional da BD é apresentado na Figura 5.2.

FIGURA 5.2 – DIAGRAMA RELACIONAL DA BASE DE DADOS DO PROTÓTIPO

Como se pode ver, existe obviamente uma tabela que armazena a informação dos utilizadores. Esta inclui, os

atributos username, password, e profile que identifica os privilégios de cada utilizador. Este último campo pode ter

valores numéricos de zero a dez, pelo que cada um identifica um tipo de utilizador. Esta gama alargada de perfis tem

como objectivo suportar perfis que possam eventualmente surgir no futuro. Para já, existem três – monitor (1),

controlador (5) e administrador (10).

Relativamente às plataformas, cada uma pode ter um ou mais sensores e uma actualização (a mais actual). As

tabelas platforms e sensors relacionam-se através do atributo id da plataforma. Este atributo é um inteiro, chave


85

primária da tabela platforms e do tipo auto increment, o que significa que à medida que se adicionam plataformas, é

atribuído um identificador único e crescente a cada plataforma. A tabela platforms possui de resto os atributos de

cada plataforma, como a sua latitude e longitude, estado global (status) e localização (e.g., Lisboa, Porto, etc.).

Repare-se que foi utilizado um índice no atributo name que corresponde ao nome da plataforma. Isto porque

serão feitas pesquisas pelo nome da plataforma. Sem um índice, o MySQL percorre todas as linhas de forma sequencial

até encontrar o registo pretendido, e portanto, quanto maior a tabela maior os custos em termos de desempenho. Com

um índice, o MySQL consegue rapidamente determinar a posição a partir da qual deve procurar um nome, sem a

necessidade de percorrer todas as linhas.

Na tabela dos sensores, o atributo plat_id identifica a que plataforma é que pertence um determinado

sensor, que juntamente com o atributo sensor_name forma a chave única e primária. Um sensor de uma plataforma

pode ter zero ou vários valores no histórico (armazenados na tabela sensor_history) e exactamente uma actualização

(também a mais actual). Cada sensor possui um nome, um estado (ligado ou desligado), um valor actual, e campos de

threshold que permitem avaliar se o valor do sensor está dentro dos limites de bom funcionamento.

As tabelas platforms_update e sensors_update são tabelas auxiliares que têm como objectivo armazenar a

informação das plataformas que foram criadas, actualizadas ou apagadas (embora esta última seja pouco provável), e a

informação dos sensores a cada alteração do seu valor respectivamente. Estas tabelas guardam essa informação até

existir uma nova leitura por parte do cliente, ou seja, o cliente actualiza a informação das plataformas e dos sensores

num período de tempo definido pelo administrador, através da leitura destas tabelas, sendo que após a leitura as

tabelas são apagadas. A razão da criação destas tabelas é evitar que em cada período de actualização por parte do

cliente, seja necessária nova transferência de todas as plataformas e sensores, o que é ineficiente. Com estas duas

tabelas, mantém-se o registo das plataformas/sensores que sofreram alterações, desde a última até à próxima leitura

do cliente

Como referido em 1.3, a actualização das plataformas e dos sensores na BD não é um problema deste trabalho

e é feita pelas próprias plataformas. No entanto, sabe-se que uma plataforma é actualizada quando existe um comando

UPDATE na tabela platforms. Do mesmo modo, o valor de um sensor é actualizado sempre que exista um comando

UPDATE sobre o atributo value na tabela sensors. O MySQL possui um mecanismo chamado trigger, que é um

procedimento que é executado sempre que o evento associado ao trigger ocorre. Assim a solução passou pela criação

de triggers nas tabelas platforms e sensors, que executam uma query de inserção/actualização na tabela

platforms_update ou sensors_update respectivamente. Por exemplo, o INSERT de uma plataforma na tabela

platforms provoca automaticamente um INSERT da mesma plataforma na tabela platforms_update. Um UPDATE de

uma plataforma na tabela platforms provoca um INSERT da plataforma actualizada na tabela platforms_update, ou

em alternativa, um UPDATE se a plataforma já tiver sido actualizada, i.e., se já constar na tabela platforms_update. Do

mesmo modo, um UPDATE de um sensor na tabela Sensor provoca um INSERT/UPDATE do sensor actualizado na tabela

sensors_update. Portanto, hipoteticamente, sempre que um atributo da tabela sensors se alterar (através do

comando UPDATE), o MySQL insere ou actualiza automaticamente na tabela sensor_update (que tem os mesmos

atributos que a tabela sensors) a linha que sofreu a alteração com os novos valores. O cliente consulta a tabela


86

sensors_update regularmente, apaga todos os seus registos, e através da combinação id da plataforma e nome do

sensor, actualiza o respectivo sensor na aplicação de monitorização.

O facto de o trigger verificar se a plataforma ou sensor já foi actualizada é muito importante, pois evita

redundância de dados, i.e., o cliente lê apenas as últimas actualizações, e no máximo, lê tantas actualizações como o

número de plataformas, ou tantas actualizações como o número de sensores. Isto foi conseguido através do comando

SQL INSERT […] ON DUPLICATE KEY UPDATE (ver código da criação dos triggers no Anexo A), que verifica se a linha a

inserir origina duplicação de valores num índice único ou chave primária, e se for o caso, executa um UPDATE na linha

antiga, ao invés de adicionar uma nova. É de salientar que, no caso da criação de uma nova plataforma, i.e., de um

INSERT na tabela platforms, não é necessária esta verificação, uma vez que quando uma plataforma é criada é lhe

atribuída um identificador único (atributo id) pelo MySQL.

Para manter o histórico dos sensores foi também utilizado um trigger. Neste caso, sempre que um sensor é

actualizado, é inserido na tabela sensor_history o nome, valor, data de actualização e id da plataforma a que o sensor

pertence. A diferença é que existe sempre uma inserção e nunca uma actualização, e além disso, esta tabela nunca é

apagada pois pretende-se que mantenha o registo dos valores de cada sensor ao longo do tempo.

A Figura 5.3 apresenta um diagrama ilustrativo da utilização dos triggers. Como no caso da actualização das

plataformas existem três eventos diferentes, a tabela platforms_update possui um atributo adicional (task) em relação

à tabela original (ver Figura 5.2). Este indica se a plataforma foi criada, actualizada ou apagada. Com esta informação o

cliente pode agir de forma adequada. Por exemplo, se uma plataforma for actualizada, o cliente pode usar o id para

actualizar a plataforma correspondente no lado do cliente, se for apagada, o cliente pode usar também o id, mas para

identificar qual a plataforma que deve apagar da aplicação de monitorização. A vantagem em utilizar os triggers e as

tabelas de dados actualizados é que, e.g., com cem plataformas, se uma das plataformas for actualizada, apenas é

transferida uma plataforma ao invés de cem.

FIGURA 5.3 – TRIGGERS UTILIZADOS PARA A ACTUALIZAÇÃO DAS PLATAFORMAS/SENSORES E HISTÓRICO DOS SENSORES


87

5.1.2 Operações

Nesta secção descrevem-se as operações disponibilizadas pelo servidor, e que o cliente pode invocar para

adquirir a informação de que necessita. A implementação do servidor PHP consistiu em vários scripts, mas apenas um

contém as operações disponibilizadas. Do ponto de vista do modelo cliente-servidor, este script PHP é cliente da BD mas

servidor para a aplicação Flex (ver Figura 5.1). A Figura 5.4 apresenta o diagrama de classes de cinco dos scripts. Como

se pode ver, a classe PlatService contém todas as operações que o cliente pode invocar, nomeadamente adquirir

todos os atributos das plataformas (GetPlatforms()), todos os sensores de todas as plataformas (GetPlatSensors())

e procurar uma plataforma por nome (GetPlatByName()). É esta classe que gere e faz o acesso à BD. Repare-se que a

maioria das operações retorna um objecto, mais especificamente um array de plataformas (classe Platform), um array

de sensores (classe Sensor), um array de histórico de sensores (classe SensorHistory) ou um array de sensores

actualizados (classe Platform_Update). Estas quatro classes não possuem métodos e agem apenas como uma estrutura

de dados que contêm toda a informação de cada linha retornada da BD (wrappers).

+GetPlatforms() : Platform[]+GetPlatByName(entrada searchString : string) : Platform+ValidateLogin(entrada user : string, entrada pass : string) : bool+GetUpdatedPlatforms() : Platform_Update[]+GetPlatSensors() : Sensor[]+GetUpdatedPlatSensors() : Sensor[]+GetSensorDayHistoric(entrada plat_id : int, entrada sensor_name : string, entrada day : int) : SensorHistory[]+GetSensorMonthHistoric(entrada plat_id : int, entrada sensor_name : string, entrada month : int) : SensorHistory[]+GetSensorYearHistoric(entrada plat_id : int, entrada sensor_name : string, entrada year : int) : SensorHistory[]+GetSensorOverallHistoric(entrada plat_id : int, entrada sensor_name : string) : SensorHistory[]+GetBetweenSensorHistoric(entrada plat_id : int, entrada sensor_name : string, entrada inf_date : string, entrada sup_date : string) : SensorHistory[]+UpdatePlatStatus(entrada id : int, entrada status : string) : void+updateActuator(entrada id : string, entrada status : string) : void

PlatService

+id+name+location+latitude+longitude+platgroup+status+visible

Platform

+plat_id+sensor_name+state+value+minThreshold+maxThreshold+criticalThreshold

Sensor

+value+date

SensorHistory

+id+name+location+latitude+longitude+platgroup+status+visible+task

Platform_Update

FIGURA 5.4 – DIAGRAMA DAS CLASSES USADAS NO SERVIDOR PHP

O PHP é dotado de inúmeros métodos que facilitam o acesso a uma BD. Por norma o acesso é feito da seguinte

forma:

1. Conectar ao servidor MySQL;

2. Seleccionar a BD a utilizar;

3. Elaborar uma string com a query pretendida;

4. Executar a query;

5. Extrair o resultado;

6. Desconectar da BD;


88

Considere-se o exemplo da operação GetPlatforms() apresentado na listagem da Figura 5.5. Como se pode verificar

são importados (linhas require_once) dois scripts PHP. O primeiro (Login.php) contém dados referentes à

autenticação e à BD que se pretende utilizar, nomeadamente o nome de utilizador e palavra-chave de acesso à BD, e o

nome e endereço (e.g., localhost) da BD. O segundo script contém a classe Platform com exactamente os mesmos

atributos que as colunas da tabela platforms. O resto do código traduz a execução dos passos referidos acima, até à

execução da query. A variável result contém o resultado da query, que ao contrário do resultado de uma query na

consola MySQL (que apresenta uma tabela), consiste num recurso que pode ser utilizado para extrair a informação

referente à query. A estratégia foi usar a função mysql_fetch_object para, enquanto houver o registo de uma

plataforma, inserir a linha correspondente num array cujas propriedades a retornar são dadas pela instanciação da

classe Platform. Relembre-se que esta classe é depois reutilizada no Flex. Portanto, o objecto return[0] é do tipo

Platform e contém a primeira linha, return[1] contém a segunda linha, e assim sucessivamente. O Flash Builder irá

inspeccionar o ficheiro, e configurar automaticamente o tipo de retorno desta operação como um array de objectos do

tipo Platform. A operação GetPlatSensors() usa precisamente a mesma abordagem, com a diferença que pede

todos os sensores de todas as plataformas, e usa a classe Sensor como wrapper.

<?phpfunction GetPlatforms() { //Imports require_once 'Login.php'; require_once 'Platform.php'; //1.Conectar à Base de Dados; $BdServer = mysql_connect($BdHost, $BdUser, $BdPass); if (!$BdServer) die("Unable to connect to DataBase Server: " . mysql_error()); //2.Selecionar a Base de Dados; mysql_select_db($BdName) or die("Unable to select DataBase: " . mysql_error()); //3.Query à Base de dados; //$result contém um recurso que permite extrair os dados da BD; //Se falhar contém um False; $query = "SELECT * FROM platforms"; $result = mysql_query($query); if (!$result) die("Unable to query DataBase: " . mysql_error()); //Transformar em array; $return = array(); //Extrai do result uma row como um array e através da instanciação //da class Platforms, coloca por essa ordem no result; //Quando não houver mais rows, retorna FALSE, e o cilco while termina; while ($row = mysql_fetch_object($result, "Platform")) { $return[] = $row; } //Liberta o resultado da memória; mysql_free_result($result); return $return; }?>

FIGURA 5.5 – CÓDIGO REFERENTE À OPERAÇÃO GETPLATFORMS

No caso da operação GetPlatByName(), esta retorna apenas uma ou nenhuma plataforma de acordo com o

nome passado como parâmetro. Aqui existe informação introduzida pelo utilizador, e portanto esta deve ser

devidamente filtrada antes de executar a query para evitar injecção de código SQL na BD. A neutralização imprópria de

elementos especiais usados num comando SQL (injecção de SQL), é segundo a literatura [48] o erro de software mais

comum. A injecção de SQL aproveita as vulnerabilidades das aplicações que partem do princípio que a informação

introduzida pelos utilizadores é legítima e pode ser usada para formar queries SQL [49], [50]. Estas aplicações devem


89

assumir que os dados introduzidos pelo utilizador são sempre maliciosos [48], e que, portanto, devem sempre ser

verificados e validados com precaução [41]. Por exemplo, considere-se o código PHP da Figura 5.6, cuja variável

platname contém o texto (nome da plataforma) a pesquisar.

<?php$searchString = 'platname';$query = "SELECT * FROM platforms WHERE name='$searchString'";[...]?>

FIGURA 5.6 – QUERY SEM FILTRAGEM PRÉVIA

Está a passar-se directamente para a BD a variável recebida do cliente. No entanto, tudo parece bem. Agora, imagine-se

que o cliente invoca a operação GetPlatByName() passando como nome a pesquisar algo do género:

'nome'; DELETE * FROM platforms';

O que acontece neste caso é que a introdução de um apóstrofo adicional a seguir ao nome torna o resto do texto em

comandos SQL, o que significa que a instrução DELETE * FROM platforms vai ser executada, apagando todos os

registos da tabela platforms. Isto compromete a aplicação de monitorização, pois deixa de haver plataformas para

monitorizar!

Um dos métodos mais eficientes para evitar a injecção de código SQL é inserir antes dos caracteres especiais

(e.g., apóstrofo, aspas) um barra oblíqua invertida (‘\’). Em PHP isso consegue através da função

mysql_real_escape_string(), que deve ser sempre utilizada antes de fazer os pedidos à BD [41]. Outras medidas de

segurança incluem remover barras indesejadas através da função stripslashes(), e remover código e tags HTML

através das funções htmlentities() e strip_tags() respectivamente. Mais especificamente, a função

htmlentities() converte uma string que é interpretada como HTML, e.g., <i>exemplo</i>, na respectiva entidade

HTML, &ltiexemplo&gti, que é interpretada como texto, e a função strip_tags() remove por completo o código

HTML. Ambas são muito importantes para evitar a injecção de código JavaScript e HTML numa aplicação web.

Relembre-se que neste caso o utilizador só tem que introduzir o nome de uma plataforma, logo, barras, código HTML e

outros caracteres especiais podem ser removidos sem afectar o bom funcionamento da aplicação. A Figura 5.7

apresenta a listagem correspondente à operação GetPlatByName(). Repare-se que se usou a função

sanitizeStringAndSQL() (Anexo B) para filtrar os dados introduzidos pelo utilizador.

<?phppublic function GetPlatByName($searchString) { //Imports require_once 'Login.php'; require_once 'Sanitize.php'; require_once 'Platforms.php'; //1º Filtrar os dados introduzidos pelo utilizador por segurana: $searchString = sanitizeStringAndSQL($searchString); //1.Conectar à Base de Dados;

... //2.Selecionar a Base de Dados;

... //3.Query à Base de dados; $query = "SELECT * FROM platforms WHERE name='" . $searchString . "'"; $result = mysql_query($query) or die("Unable to query DataBase: " . mysql_error()); //Retorna apenas um resultado, pois o nome da plataforma é único. $return = mysql_fetch_object($result, "Platforms"); //Liberta o resultado da memória; mysql_free_result($result); return $return; }

FIGURA 5.7 – CÓDIGO REFERENTE À OPERAÇÃO GETPLATBYNAME


90

Como o nome indica, a operação ValidateLogin(), tem o objectivo de efectuar a autenticação do utilizador.

Aqui existe mais uma vez a introdução de dados por parte do utilizador, logo, deve filtrar-se novamente a informação

através da função referida acima. No entanto, há ainda uma medida de segurança importante neste caso. O utilizador

introduz a combinação username e palavra-chave, que é comparada com a combinação armazenada no MySQL, mas a

palavra-chave não deve ser armazenada na BD como texto visível. Na eventualidade da autenticação de acesso à BD ser

quebrada, as palavras-chave dos utilizadores seriam facilmente acedidas, e a aplicação comprometida. Uma solução é

usar uma one-way function, isto é, uma função que converta facilmente uma string de texto numa string aleatória. Estas

funções são virtualmente impossíveis de reverter devido à sua natureza de sentido único [41]. Exemplos destas funções

são a md5 e sha1, que recebem uma string como parâmetro e, segundo o respectivo algoritmo de encriptação, retornam

uma hash hexadecimal. No entanto, uma função deste tipo por si só não é suficiente, pois pode ser susceptível a

ataques que usam outras BDs de hashes conhecidas [41]. Assim, complementa-se esta solução com um mecanismo

chamado salting. Este consiste simplesmente na adição de texto, conhecido apenas pelo programador, ao parâmetro a

ser encriptado (Figura 5.8). Para a mesma palavra-chave, a alteração de um único carácter resulta numa hash

completamente diferente.

FIGURA 5.8 – SALTING

Deste modo, mesmo que um hacker ganhe acesso à BD, torna-se quase impossível aceder às palavras-chave

armazenadas sem o acesso ao código PHP [41]. A Figura 5.9, apresenta a listagem da operação ValidateLogin(). Após

filtrar a informação, executa-se uma query dado o username, que retorna os dados do utilizador. Depois, usam-se as

variáveis que contêm o texto adicionado à palavra-chave, e encripta-se usando a função sha1. Se a hash corresponder à

retornada pelo MySQL, o login é efectuado com sucesso.

As operações GetUpdatedPlatforms() e GetUpdatedPlatSensors() fazem o acesso às tabelas

platforms_update e sensors_update, respectivamente. São estas operações que permitem ao cliente monitorizar as

plataformas e respectivos sensores. As funções retornam todas as plataformas/sensores que foram de alguma forma

actualizadas desde a leitura anterior, e que portanto estão nas tabelas referidas. Os comandos de leitura de cada tabela

e remoção de todos os seus registos devem ser executados sequencialmente sem interrupção, pois uma

plataforma/sensor pode ser actualizada(o) depois da leitura da tabela platforms_update/sensors_update por parte

do cliente, mas antes da remoção de todos os registos. Se assim não acontecer, o cliente vai apagar todos os registos da

tabela, e o registo entretanto actualizado perde-se. A solução é usar uma transacção, que consiste num conjunto de


91

expressões SQL que são executadas como uma unidade, i.e., de forma atómica, e que podem ser canceladas se

necessário [51]. Ou todas as expressões são executadas com sucesso, ou nenhuma tem efeito [51].

<?php public function ValidateLogin($user, $pass) { //Imports require_once 'Login.php'; require_once 'Sanitize.php'; //Never trust the client! $user = sanitizeStringAndSQL($user); $pass = sanitizeStringAndSQL($pass); //1.Conectar à Base de Dados; [...] //2.Selecionar a Base de Dados; [...] //3.Query à Base de dados; $query = "SELECT * FROM user WHERE username='" . $user . "'"; $result = mysql_query($query) or die("Unable to query DataBase: " . mysql_error()); if (mysql_num_rows($result)) { $row = mysql_fetch_row($result); //Lets Mix. $Mystery1 = "&%gh"; $Mystery2 = "$$!"; $token = sha1("$Mystery1$pass$Mystery2"); //Se for igual, é um match e faz login. if ($token == $row[1]) { mysql_free_result($result); return true; } else { mysql_free_result($result); return false; } } }

FIGURA 5.9 – CÓDIGO REFERENTE À OPERAÇÃO VALIDATELOGIN

A Figura 5.10 ilustra a listagem referente à transacção da operação GetUpdatedPlatforms(), e a única diferença

relativamente à operação GetUpdatedPlatSensors() é a definição da query e o nome da tabela a apagar. A transacção

começa através do comando BEGIN. A partir daqui, executa-se a query de leitura da tabela e apaga-se a mesma através

do comando TRUNCATE. Repare-se que se o apagar da tabela falhar, pode-se reverter os dois comandos executados

através do comando ROLLBACK. Por fim, o comando COMMIT completa a transacção fazendo com que as mudanças sejam

permanentes.

No que diz respeito às operações relacionadas com o histórico dos sensores, estas executam uma simples

query que retorna todos os campos da tabela sensor_history. Para isso, passa-se como parâmetros o id da plataforma a

que o sensor pertence, o nome do sensor e, exceptuando as operações GetSensorOverallHistoric() e

GetBetweenSensorHistoric() que retornam todo o histórico e o intervalo do histórico dadas duas datas

respectivamente, o dia ou mês ou ano que se pretende consultar. O facto de existirem várias operações para diferentes

intervalos temporais contribui para a diminuição considerável do volume de tráfego. Isto porque não existe a

necessidade de pedir todo o histórico de um determinado sensor, a não ser que o utilizador assim o solicite. Deste

modo, é apenas transferida a informação que o utilizador pretende visualizar, e existem mais ou menos pedidos de

acordo com as acções do utilizador.


92

<?php//Depois da ligação à BD estabelecida, define-se a query:$query = "SELECT * FROM platforms_update;";//Começar a Transactionmysql_query("BEGIN");//Executar a query$result = mysql_query($query);//Apaga a tabelamysql_query("TRUNCATE platforms_update");if (!$result) {

mysql_query("ROLLBACK");die("Unable to query DataBase: " . mysql_error());

} else {mysql_query("COMMIT");

FIGURA 5.10 – TRANSACÇÃO NA OPERAÇÃO GETUPDATEDPLATFORMS

Por fim, a operação updatePlatStatus() permite ao cliente actualizar o estado global de cada uma das

plataformas segundo um determinado critério. Como o cliente é uma aplicação de monitorização, e ao mesmo tempo

para libertar carga de processamento do servidor, o estado global de cada plataforma é calculado pelo cliente segundo

o estado individual de cada sensor e outros critérios, como por exemplo, uma falha energética. Este estado poderia

também ser calculado pela própria plataforma, no entanto, como o sistema de interface das plataformas não está ainda

desenvolvido, optou-se por fazer este cálculo no cliente. Para isso, após a determinação do estado, passa-se o id da

plataforma e o estado actualizado, e executa-se um UPDATE na tabela platforms ao atributo status da plataforma

identificada pelo id passado.

5.2 Cliente

Nesta secção e subsecções que se seguem descreve-se a aplicação de monitorização. Esta aplicação é uma

evolução do estudo apresentado em 4.1.2. Foram reutilizados componentes como a DataGrid e o mapa,

funcionalidades como a procura de plataforma por nome, e as operações GetPlatforms() e GetPlatByName() já

desenvolvidas. Alguns conceitos encontram-se já descritos no capítulo da aplicação de estudo, e.g., a conexão ao

serviço PHP, associação das operações a componentes, entre outros, e portanto não são aqui repetidos. A Figura 5.11

apresenta o diagrama de casos de uso da GUI, que deriva dos requisitos funcionais apresentados em 1.3, e portanto

descreve o que o utilizador pode fazer com a mesma. É de salientar que este não é o diagrama de casos de uso do

sistema, e é incluído porque é favorável à descrição das acções do utilizador com a interface e respostas do sistema

associadas [52].

Como se pode ver, existem três actores (perfis) que podem interagir com a interface. A maior parte das

funcionalidades podem ser utilizadas pelo monitor, que apenas possui privilégios de visualização. O controlador faz tudo

o que o utilizador comum faz, e adicionalmente, pode ligar ou desligar um sensor ou actuador e configurar o tempo de

de actualização das plataformas e dos sensores. Por sua vez, o administrador também faz tudo o que os outros fazem,

além de poder tornar uma plataforma visível ou invisível à monitorização. De resto, o utilizador pode obviamente

efectuar o login ou logout, procurar uma plataforma, aumentar o mapa, ordenar as plataformas na tabela por nome,

estado ou localização geográfica, seleccionar uma plataforma a partir da tabela, entre outros.


93

Utilizador

Controlador

Administrador

UI da aplicação de monitorização

Login

Logout

«extends»

Alerta de logininválido

Procura plataforma«extends»

Alerta deplataforma não encontrada

Mostra plataforma nomapa e na tabelaMostra todas as

plataformas na tabela

«extends»

No caso de acaixa de texto estar vazia

Seleccionaplataforma na tabela

Mostra grupo deplataformas no mapa

«include»

Mostra atributos

Mostra sensores

Selecciona sensorna tabela

«include»

Mostra históricodo sensor

Navegar no mapa Muda tipo de Mapa

Escolhe intervalopredefinido

Mostra atributosno mapa

Ajusta intervalo

Mostra atributosnum formulário

Seleccionaplataforma no mapa «include»

Ordena plataformas poratributo (e.g., estado)

Ordena sensores poratributo (e.g., valor)

Liga/Desligaactuador

Torna plataformavisível/invisível

Configura tempo derefrescamento

«extends»

«extends»

«extends»

«extends»

«extends»

Minimiza/Aumentatabela

Liga/desligaleitura de sensor

«extends»

Altera zoom do mapa

«extends»«extends»

Mostra detalhes daplataforma

«include»

«extends»

FIGURA 5.11 – DIAGRAMA UML DE CASOS DE USO DA INTERFACE

Repare-se que existem casos de uso que incluem outros («include»), ou seja, que reutilizam sempre os passos do caso

de uso que incluem [53]. Por exemplo, o facto de o utilizador clicar numa plataforma na tabela implica sempre mostrar

os detalhes da plataforma. Por sua vez, este caso de uso possui uma relação de generalização (seta de linha contínua)

com outros dois casos de uso, o que significa que existem dois tipos de detalhes mais específicos que podem ser

visualizados pelo utilizador (mostrar sensores e mostrar os atributos da plataforma). Por fim, no caso de uso da procura

de uma plataforma, existem relações «extends». Estas indicam que o caso de uso por vezes reutiliza o comportamento

de um outro caso, e dependendo de uma decisão em runtime [53]. Por exemplo, o caso de uso da procura de uma

plataforma pode ou não, apresentar um alerta de plataforma não encontrada, dependendo do facto de uma plataforma

ser ou não encontrada.

A aplicação é composta por oito estados, sendo que o estado inicial corresponde ao ecrã de login. A Figura 5.12

apresenta o diagrama de estados da aplicação com todos os estados e transições envolventes.


94

loginState platView

giantMap

platDetails

graphFromDetails

searchState

graphFromSearch

duplo clique no mapa login [login_validation = true]

logout

clique no botão minimizar tabela clique no botão minimizar tabela

clique no botão maximizar tabela

logout

clique num sensor

clique numa plataforma na tabela

clique no botão minimizar tabela

giantGraph

logout

logout

login [login_validation = false]

clique numa plataforma na tabela

procura plataforma

procura plataforma

logout

clique num sensor clique no botão minimizar tabela

clique no botão maximizar tabela

[previousState = graphFromDetails]

[previousState = graphFromSearch]

[existe_texto = true]

[existe_texto = false]

logout

procura plataforma

[plataforma_existe = true] [plataforma_existe = false] Não muda de estado

duplo clique no mapa

procura plataforma

clique num sensor

clique num sensor

clique no botão minimizar tabela

duplo clique no mapa

Volta ao estado anterior

FIGURA 5.12 – DIAGRAMA UML MÁQUINA DE ESTADOS

Se o login for bem-sucedido, o estado platview é activado e apresenta as duas vistas principais da aplicação de

monitorização, a tabela e o mapa com as plataformas. Depois do login o utilizador pode efectuar o logout a partir de

qualquer estado, e portanto é desnecessário voltar a referir esta transição no texto que se segue. Como se pode ver,

uma vez neste estado, apenas três acções implicam a mudança para um outro – procura de plataforma por nome,

aumento do mapa (através de um duplo clique no mapa ou do clique no botão de minimizar a tabela), e o clique numa

plataforma na tabela. A última resulta na activação do estado platDetails, que apresenta os mesmos componentes

que o estado platview com a adição dos dados detalhados da plataforma seleccionada, nomeadamente os atributos

num formulário e os sensores numa outra tabela. Ao mesmo tempo, este estado habilita outras opções, como por


95

exemplo, ver o histórico de um sensor através de um clique, que resulta na activação do estado graphFromDetails.

Este substitui a vista do mapa por um gráfico que apresenta a evolução ao longo do tempo dos valores de um sensor,

sendo que a tabela das plataformas e respectiva informação detalhada permanece visível. Por isso, é ainda possível

carregar noutra plataforma na tabela, ou noutro sensor. Repare-se que existem dois estados para a visualização do

histórico dos sensores (graphFromDetails e graphFromSearch). Isto porque, no estado platDetails, a tabela das

plataformas apresenta todas as plataformas, mas o mesmo não acontece no estado searchState, que apenas

apresenta a plataforma pesquisada (match exacto do nome). Uma vez que o estado relativo ao histórico dos sensores

mantém a tabela das plataformas visível, são necessários dois estados (um para cada tabela) para manter a tabela que

anteriormente estava apresentada. Finalmente, com excepção dos estados loginState, giantMap, e giantGraph, é

sempre possível pesquisar uma plataforma por nome. Por exemplo, considere-se o estado platview como o estado

actual. O utilizador carrega no botão de pesquisa de plataforma; a aplicação verifica primeiro se existe texto na textbox,

e posteriormente se a plataforma existe. Se ambas as condições forem verdadeiras o estado altera-se para o

searchState, que apresenta a tabela apenas com uma plataforma, os seus atributos num formulário, e respectivos

sensores numa outra tabela. Uma vez neste estado, o utilizador pode ver o histórico de um sensor ou procurar outra

plataforma. Neste ultimo caso, se a pesquisa for feita com a caixa de texto vazia, são apresentadas novamente todas as

plataformas, e portanto o estado actual passa a ser o platview. É importante referir que, se numa pesquisa a

plataforma não for encontrada, o estado não chega a ser alterado. Esta questão é apresentada na Figura 5.12 através de

uma nota, apenas para não tornar o diagrama mais confuso.

5.2.1 Inicialização da aplicação

O primeiro estado da aplicação, ilustrado na Figura 5.13, corresponde ao ecrã de login. Apesar de ser um ecrã

de login, este estado não fica simplesmente à espera que o utilizador introduza os seus dados para entrar na aplicação

de monitorização.

FIGURA 5.13 – LOGINSTATE QUE CORRESPONDE AO ECRÃ DE LOGIN DA INTERFACE


96

A aplicação é iniciada neste momento, e portanto existem outras acções transparentes ao utilizador que são

executadas, nomeadamente os pedidos das plataformas e dos sensores ao servidor, GetPlatforms() e

GetPlatSensors(), respectivamente (ver operações na subsecção 5.1.2). Como estes pedidos são assíncronos, o

utilizador pode continuar a interagir com a aplicação e efectuar o seu login a qualquer altura. A vantagem de pedir as

plataformas e os sensores na inicialização da aplicação é o facto de se aproveitar o tempo que o utilizador demora a

introduzir os dados de autenticação para transferir informação. A Figura 5.14 ilustra o diagrama de sequência para o

caso do estado loginState. Repare-se que, a maioria das mensagens são assíncronas; e.g., a aplicação inicia e o event

handler PlatGui_InitHandler() é chamado, que por sua vez pede, novamente de forma assíncrona, as plataformas e

os sensores. Enquanto isto acontece, o utilizador pode eventualmente carregar no botão de login e fazer o pedido de

validação de credenciais (identificação do utilizador e palavra-chave) ao servidor. Para que a validação seja executada, é

necessário que as caixas de texto não estejam vazias. Se não estiverem, o pedido é executado e o servidor verifica se as

credenciais estão correctas ou incorrectas, retornando verdadeiro ou falso respectivamente. A resposta ao pedido

ValidateLogin() é tratada pelo CallResponder ValidateLoginResult, pelo que se a validação for bem-sucedida, o

estado actual passa para o platview e é criado o objecto refreshtimer, que é o temporizador que dita o período de

actualização das plataformas e dos sensores.

Flash Player

opt [ValidateLoginResult.lastResult = true]

opt [userTextBox.text != ‘’ && passTextBox != ‘’]

ValidateLoginResult : CallResponder

loginButton:Button

platformsMonitoring : Application«actor» Utilizador Servidor

GetPlatforms():Platform

GetPlatSensors():Sensor

Clica no botão de login

ValidateLogin(username:String, password:String):Boolean

«create»«actor» refreshTimer:

Timer

«create»PlatData:DataGrid

map:Map«create»

currentState = "platView"

addEventListener("timer", updateData):void

start()

PlatGui_initHandler(event:FlexEvent):void

ValidateLoginResult_resultHandler(event:ResultEvent):void

loginButton_clickHandler(event:MouseEvent):void

FIGURA 5.14 – DIAGRAMA UML DE SEQUÊNCIA PARA O LOGINSTATE


97

Para não saturar o diagrama da Figura 5.14, representou-se a criação de apenas dois dos objectos, por serem os mais

relevantes – os objectos PlatData (DataGrid) e map (Map). Estes são também criados após a mudança de estado, após o

arranque temporizador. Pela mesma razão, optou-se por não incluir o caso de o login não ser válido, bem como o caso

de as caixas de texto estarem vazias. O que acontece em ambas as situações, é que é enviada uma mensagem de

notificação ao utilizador através do controlo Alert, e.g.,:

Alert.show("Please enter a valid username or password","Wrong username/password", Alert.OK);

5.2.2 Vista de mapa

Após o login efectuado com sucesso, a aplicação transita para o estado platview (Figura 5.15), que apresenta

a tabela das plataformas e o mapa, e que permite o início da monitorização. Além da tabela e do mapa, são criados

neste estado outros componentes, nomeadamente painéis e contentores para acomodar outros componentes: o botão

de busca de plataformas, botões para a alteração do tipo de mapa, entre outros. A criação e o respectivo carregamento

das plataformas no componente tabela (PlatData) é mais rápida que a criação do mapa, e consequentemente, que o

carregamento das plataformas no mapa, uma vez que a inicialização do mapa implica a conexão aos servidores da

Google. Relembre-se que o secção 4.1.2 descreve como a informação das plataformas retornadas pelo servidor

(GetPlatforms()) é associada à DataGrid através do mecanismo bind. Apesar de o mapa só estar pronto a utilizar

depois da tabela, é importante perceber como este é inicializado e como as plataformas são colocadas no mapa, uma

vez que o clique numa plataforma na tabela resulta na mudança do campo de visão do mapa.

FIGURA 5.15 – ESTADO PLATVIEW COM AS DUAS VISTAS GERAIS DE MONITORIZAÇÃO – A TABELA E O MAPA

A Figura 5.16 apresenta o diagrama de sequência da inicialização do mapa. A primeira função da classe Map a

ser executada é uma função de callback executada automaticamente quando se dá a pré-inicialização do mapa, ou seja,

antes de o mapa estar desenhado. Dentro deste event handler, a única função da API da Google que pode ser utilizada é

a setInitOptions() que como o próprio nome indica, permite definir as opções de inicialização do mapa.


98

«actor» Utilizador map:Map

loop count < platformsCount

placeMarkers():void

BindWindow(platMarker:Marker, html:String):void

Clica numa plataforma no mapa

PlatMarker.openInfoWindow(new InfoWindowOptions({contentHTML: html}))

Clica no botão do tipo satélite

SatTypeButton:Button

map.setMapType(MapType.PHYSICAL_MAP_TYPE)

Flash Player

onMapPreinitialize(event:Event):void

onMapReady(event:MapEvent):void

map.addOverlay(platMarker);

function(event:MapMouseEvent):void

SatTypeButton_clickHandler(event:MouseEvent):void

FIGURA 5.16 – DIAGRAMA UML DE SEQUÊNCIA RALATIVO À INICIALIZAÇÃO DO MAPA, COLOCAÇÃO DAS PLATAFORMAS NO MAPA E MUDANÇA

DO TIPO DE MAPA

Quando o mapa está pronto a ser utilizado a função onMapReady() é chamada. Aqui, o que se faz é adicionar um event

listener referente ao duplo clique no mapa, controlos de navegação e de zoom, e mais importante, colocar as

plataformas no mapa através da função placeMarkers(). No Anexo E encontra-se o código AS referente ao método

onMapPreinitialize() e onMapReady(). A colocação dos marcadores (plataformas) no mapa implica:

• Percorrer todas as plataformas através de um ciclo for;

• Verificar o estado de cada plataforma;

• Desenhar um marcador por plataforma através da classe Sprite;

• Adicionar a janela de informação e colocar o marcador.

Como se pode ver pela listagem do Anexo E, a colocação das plataformas no mapa é feita dentro de um ciclo for. Como

os marcadores devem ser colocados de acordo com o estado global da plataforma, é necessário verificar esse mesmo

estado. O estado global é verificado através de blocos if else, e pode ter um de quatro valores possíveis – Good, Bad,

Acceptable ou EnergyBreakDown. O marcador é criado passando a latitude/longitude onde este vai ser colocado e as

respectivas opções, que especificam, entre outros aspectos, o ícone do marcador. O ícone é desenhado através do

objecto Sprite, do qual são descendentes todos os componentes da framework Flex [54].

Como existem quatro ícones possíveis criou-se a classe MarkersFactory (Figura 5.17), descendente da classe

Sprite, que possui quatro métodos para a criação de cada ícone. Os ícones para os estados Good, Bad e Acceptable são

objectos Sprite na forma de um círculo cuja cor reflecte o estado global da plataforma. Por outro lado, o ícone


99

referente ao estado EnergyBreakDown tem a forma de um raio, e é armazenado numa variável da classe

MarkersFactory porque não é um objecto Sprite, i.e., o ícone é uma imagem importada para a aplicação que é

adicionada ao estado global da plataforma quando há uma falha de energia. Por exemplo, para o caso da plataforma

estar em bom estado, apenas se tem que definir o ícone do marcador através da função DrawGoodStateMarker(), que

cria uma nova instância da classe Sprite e desenha o marcador para o estado. Depois pode adicionar-se ao marcador a

janela de informação que apresenta os detalhes da plataforma.

+MarkersFactory()+DrawGoodStateMarker() : Sprite+DrawAcceptableStateMarker() : Sprite+DrawBadStateMarker() : Sprite+DrawBatteryStateMarker() : Sprite

MarkersFactory

-batteryImg

Sprite

FIGURA 5.17 – CLASSE MARKERSFACTORY

Para isso, chama-se a função BindWindow(), que recebe o marcador e o texto (neste caso é código HTML) a inserir na

janela. Uma vez que se pretende que a janela de informação apresente os detalhes da plataforma através de um clique

no respectivo marcador, esta função simplesmente define um event listener referente ao clique no marcador passado

como parâmetro:

PlatMarker.addEventListener(MapMouseEvent.CLICK,function(event:MapMouseEvent):void {

PlatMarker.openInfoWindow(new InfoWindowOptions({contentHTML: html})); });

A função BindWindow(), é uma função closure que permite à função anónima, definida como event handler para o

clique num marcador, aceder à variável html que está fora do seu contexto. Desta forma é possível adicionar

dinamicamente, dentro do ciclo for, diferentes conteúdos à janela de informação de acordo com o marcador a ser

iterado. Por fim, adiciona-se o marcador ao mapa através da função addOverlay(), que recebe como parâmetro o

marcador a colocar. O diagrama de sequência da Figura 5.16 exemplifica ainda a possibilidade de o utilizador alterar o

tipo de mapa através do clique no botão SatTypeButton. Aquando o clique é chamada a função

SatTypeButton_clickHandler() que altera o tipo de mapa para satélite através da função indicada no diagrama.

Existem ainda outros tipos de mapa (mapa, físico e híbrido) para os quais são disponibilizados outros tantos botões, e o

procedimento para fazer a alteração é o mesmo. Como apresentado no diagrama de estados da secção 5.2, o utilizador

pode aumentar a vista do mapa, minimizando a tabela. Isto pode ser feito de duas formas, conforme ilustrado na Figura

5.18: fazendo duplo clique no mapa para aumentar/diminuir a vista do mapa, ou clicando no botão hButton para

esconder a tabela. Ambos os casos implicam a mudança do estado actual para o estado giantMap (Fig. A do Anexo D),

sendo que o registo do estado anterior actual é mantido pela variável previousState. Ao contrário da variável

currentState que é definida pelo Flex, e por isso basta alterar o seu valor para transitar de estado, a variável

previousState foi explicitamente declarada para guardar o estado anterior da aplicação, visto que é possível aumentar


100

a vista do mapa a partir de vários estados, i.e., o duplo clique no mapa, ou o clique no hbutton é permitido em vários

estados. No entanto, ao contrário do hbutton que apenas serve para minimizar a tabela (para aumentá-la é um outro

botão), o duplo clique no mapa serve tanto para aumentar como para diminuir o mapa, e portanto é necessário verificar

o estado actual para se poder agir de forma coerente.

alt [currentState == ‘giantMapState’]

«actor» Utilizador map:Map

previousState = currentState

hButton:Button

currentState = previousState

previousState = currentState

currentState = 'giantMapState'

currentState = 'giantMapState'

[else]

Duplo clique no mapa

Clica no botão hideButton

Flash Player

onMapDClick(event:MapMouseEvent):void

hButton_clickHandler(event:MouseEvent):void

FIGURA 5.18 – DIAGRAMA UML DE SEQUÊNCIA RELATIVO AO AUMENTO/DIMINUIÇÃO DA VISTO DO MAPA

5.2.3 Vista de tabela

Ainda no estado platView e com as plataformas colocadas no mapa, o utilizador pode carregar em qualquer

parte de uma linha na tabela (que corresponde a uma plataforma), para mostrar automaticamente o seu grupo no

mapa, sem ter que navegar manualmente até à sua posição, e consultar a informação detalhada da plataforma,

mudando para o estado platDetails (Figura 5.19). Esta acção resulta na invocação do método

PlatData_changeHandler() da tabela (objecto PlatData do tipo DataGrid na Figura 5.20) que é chamado sempre que

ocorre uma mudança na linha seleccionada. Este método invoca por sua vez o método setDataGridSensors() que

coloca todos os sensores da plataforma seleccionada no array platSensors. O que este faz é percorrer o array

GetPlatSensorsResult.lastResult[], (que contém o resultado do pedido GetPlatSensors() executado na

inicialização da aplicação) e, através da comparação do id da plataforma que está seleccionada com o id da plataforma a

que um sensor pertence, adicionar apenas os sensores da plataforma seleccionada no array platSensors. Este é usado,

através do bind, para preencher a tabela sensorsDataGrid que apresenta os sensores da plataforma seleccionada (Fig.

B do Anexo D). Portanto, sempre que o utilizador selecciona uma plataforma diferente na tabela preenche-se

novamente o array com os sensores da plataforma seleccionada.


101

FIGURA 5.19 – ESTADO PLATDETAILS COM A PLATAFORMA DO PORTO SELECIONADA E RESPECTIVOS ATRIBUTOS NO FORMULÁRIO. A

VISTA DE MAPA APRESENTA TODAS AS PLATAFORMAS DO MESMO GRUPO

Se a alteração para o estado platDetails for feita pela primeira vez, são criados dois novos objectos, a saber, um

formulário para os atributos das plataformas, e a DataGrid sensorsDataGrid para os sensores. Depois, a função que

permite a vista de um grupo de plataformas é chamada. No caso de não ser necessária a mudança de estado, o

formulário e a DataGrid dos sensores não são obviamente criadas, pelo que apenas é necessário chamar a função de

vista em grupo.

«actor» Utilizador PlatData:DataGrid

alt [currentState != “platDetailsState”]

setDataGridSensors(platforms.id)

Clica numa plataforma na tabela

detailsForm:Form

currentState = "platDetailsState"

showPlatGroup():void

showPlatGroup():void

«creates»

«creates»sensordatagrid:SensorDataGrid

[else]

Flash Player

PlatData_changeHandler(event:ListEvent):void

FIGURA 5.20 – DIAGRAMA UML DE SEQUÊNCIA RELATIVO AO CLIQUE NUMA PLATAFORMA NA TABELA

A função de vista de grupo (Anexo G), começa por alterar a vista do mapa para se centrar na localização da plataforma

seleccionada e por escolher um zoom relativamente grande, de modo a diminuir o chamado viewport. Este é a janela

que apresenta o mapa, e pode ser calculado a partir das coordenadas das plataformas que se pretendem ver. O objecto

LatLngBounds oferece essa funcionalidade definindo uma região rectangular cujos limites (cantos sudoeste e nordeste)

podem ser expandidos para incluir uma localização geográfica [55]. Assim, a estratégia passa por armazenar o viewport

actual, ou seja, apenas da plataforma seleccionada, e percorrer todas as outras plataformas. Se uma determinada


102

plataforma for do mesmo grupo que a plataforma seleccionada, aumenta-se o viewport através da função extend(), de

maneira a que essa plataforma fique também visível. Depois de todas as plataformas percorridas, obtém-se os limites

da região que contém o grupo de plataformas. Para obter o viewport correspondente, define-se como centro do mapa o

ponto central da região obtida, e define-se um zoom adequado através da função getBoundsZoomLevel(), que retorna

o zoom máximo para o qual todo o viewport fica visível.

5.2.4 Procura de plataforma

A funcionalidade da procura de plataforma por nome é muito semelhante à implementada na aplicação de

estudo da secção 4.1.3. A diferença principal reside na criação de uma DataGrid e de um formulário dedicados à

apresentação da plataforma encontrada e seus detalhes, respectivamente, apresentados na Figura 5.21. Além disso,

criou-se um estado apenas para esta funcionalidade, útil para evitar problemas na actualização da informação das

plataformas.

FIGURA 5.21 – O ESTADO SEARCHSTATE APENAS APRESENTA UMA PLATAFORMA TANTO NA TABELA COMO NO MAPA

Como se sabe, o resultado do pedido GetPlatforms(), que contém todas as plataformas, está vinculado à

DataGrid que apresenta as plataformas (PlatData). Como a informação das plataformas (com excepção dos sensores)

está na propriedade GetPlatformsResult.lastResult (ver subsecção 4.1.2), é razoável que se aceda a esta

propriedade para actualizar um determinado atributo. Por exemplo, o estado global de uma plataforma pode ser

actualizado da seguinte forma:

GetPlatformsResult.lastResult[PlatNumber].status = ‘Good’;

Para utilizar a mesma DataGrid na apresentação da plataforma encontrada na procura poderia fazer-se:

GetPlatformsResult.token = GetPlatByNameResult.token;

Deste modo, a PlatData passaria a estar vinculada ao resultado da operação GetPlatByName(), que apenas retorna

uma plataforma, e portanto a propriedade lastResult seria automaticamente preenchida com essa plataforma. No

entanto, se ocorresse a actualização de uma outra plataforma no momento em que a aplicação estivesse, por exemplo,


103

no estado searchState, a actualização poderia não ser possível, uma vez que a plataforma pode não estar na propriedade

lastResult, nem tão pouco a ser apresentada na DataGrid. Assim a solução passa por criar uma nova DataGrid

(searchDataGrid), que está vinculada à propriedade lastResult da operação GetPlatByName(), para apresentar a

plataforma encontrada na procura. Deste modo, a propriedade lastResult da operação GetPlatforms() pode

receber as actualizações, pois contém sempre todas as plataformas. Ao mesmo tempo, cria-se um novo formulário para

a apresentação dos detalhes da plataforma.

Note-se que a tabela para a apresentação dos sensores da plataforma encontrada na pesquisa pode ser a mesma. Isto

porque o resultado que está vinculado a essa tabela não é o da operação GetPlatSensores(), nem nunca poderia ser,

pois esta operação retorna todos os sensores de todas as plataformas e apenas se pretende apresentar os sensores da

plataforma seleccionada. Como referido em 5.2.3, sempre que uma plataforma seja seleccionada, por clique na tabela

ou por pesquisa, a função setDataGridSensors() (descrita na subsecção anterior) preenche o array platSensors, que

está vinculado à tabela dos sensores, com os sensores dessa plataforma. Em alternativa, poderia criar-se uma operação

que retornasse os sensores de uma plataforma dado o id da mesma. A desvantagem é que sempre que se seleccionasse

outra plataforma, era necessário um pedido ao servidor e transferência redundante de dados.

A Figura 5.22 ilustra uma listagem MXML referente à declaração da searchDataGrid que apresenta a plataforma

pesquisada e respectivo formulário (searchDetailsForm). A propriedade dataProvider permite definir e vincular a

fonte de informação que a DataGrid apresenta. Neste caso, quer-se apresentar a plataforma pesquisada, e portanto a

fonte de informação é a propriedade GetPlatByNameResult.lastResult. Repare-se que o objecto TabNavigator, que

contém a tabela dos sensores e o formulário de detalhe das plataformas, apesar de estar incluído na maioria dos

estados, contém o formulário searchDetailsForm, que apenas está incluído nos estados searchState e

graphFromSearch. Nos restantes estados aplicáveis, o formulário incluído é o detailsForm, que contém exactamente

os mesmos dados. As Labels do formulário estão vinculadas aos atributos da plataforma seleccionada na

searchDataGrid, e por isso, os detalhes apresentados são sempre referentes à plataforma pesquisada. [...]<mx:DataGrid includeIn="searchState,graphFromSearch" ... id="searchDataGrid" dataProvider="{GetPlatByNameResult.lastResult}">

<mx:columns><mx:DataGridColumn headerText="name" dataField="name"/><mx:DataGridColumn headerText="location" dataField="location"/><mx:DataGridColumn headerText="status" dataField="status"/>

</mx:columns></mx:DataGrid><mx:TabNavigator includeIn="graphFromDetails,searchState,platDetailsState,graphFromSearch" ... >

<s:NavigatorContent label="Platforms Details" width="100%" height="100%" id="platDetailsTab">[...]<mx:Form includeIn="searchState,graphFromSearch" ... id="searchDetailsForm">

<mx:FormItem label="Id" width="174"><s:Label id="idLabel2" text="{searchedPlat.id}"/>

</mx:FormItem><mx:FormItem label="Name" width="176">

<s:Label id="nameLabel2" text="{searchedPlat.name}"/></mx:FormItem><mx:FormItem label="Location">

<s:Label id="locationLabel2" text="{searchedPlat.location}"/></mx:FormItem><mx:FormItem label="Platgroup" width="174">

<s:Label id="platgroupLabel2" text="{searchedPlat.platgroup}"/></mx:FormItem><mx:FormItem label="Status" width="174">

<s:Label id="statusLabel2" text="{searchedPlat.status}"/></mx:FormItem>

</mx:Form>[...]

</s:NavigatorContent>[...]

FIGURA 5.22 – EXCERTO DE CÓDIGO MXML REFERENTE À SEARCHDATAGRID E SEARCHDETAILSFORM


104

O diagrama de sequência da Figura 5.23 resume as actividades que dizem respeito a esta funcionalidade. O

utilizador pode começar por procurar uma plataforma escrevendo o nome da plataforma numa caixa de texto e

clicando no botão de pesquisa. Se a caixa de texto estiver vazia, são apresentadas todas as plataformas, pelo que não é

feito nenhum pedido ao servidor e o estado é alterado para o platview. Se pelo contrário, a caixa de texto não estiver

vazia, faz-se um pedido ao servidor através da operação searchPlatByName(). Se encontrada, a plataforma é retornada

e o estado é alterado para o searchState, caso contrário o estado permanece inalterável. Neste momento são criados

a tabela e formulário 16 (objectos searchDataGrid e searchDetailsForm, respectivamente) e selecciona-se

programaticamente na tabela a plataforma encontrada na pesquisa. Isto é necessário para forçar a apresentação dos

detalhes da plataforma no formulário, uma vez que as Labels que o constituem estão vinculadas à plataforma

seleccionada na tabela.

alt [searchTextBox != ‘’]

searchButton:Button

opt event.result != false

GetPlatByNameResult : CallResponder

«actor» Utilizador

Clica no botão de procura

currentState = 'searchState'

Servidor

«creates»searchDataGrid:DataGrid

searchDataGrid.selectedItem = GetPlatByNameResult.lastResult

setDataGridSensors(searchedPlat.id)

map.panTo(new LatLng(Number(searchedPlat.latitude),Number(searchedPlat.longitude)));

«creates»searchDetailsForm:Form

map.setZoom(10)

currentState = 'platView'[else]

GetPlatByName(searchTextbox.text):Platform

Flash Player

GetPlatByNameResult_resultHandler(event:ResultEvent):void

searchButton_clickHandler(event:MouseEvent):void

FIGURA 5.23 – DIAGRAMA UML DE SEQUÊNCIA REFERENTE À PROCURA DE UMA PLATAFORMA POR NOME

16 A tabela dos sensores (sensorsdatagrid) pode também ser criada neste momento, dependendo do fluxo da aplicação (e.g., se o utilizador fizer

uma busca no estado platView sem que tenha existido uma outra alteração de estado).


105

Depois, actualiza-se o array que armazena os sensores da plataforma seleccionada através da função

setDataGridSensors(), passando o id da plataforma pesquisada. Como este array está vinculado à tabela dos

sensores, esta vai apresentar os sensores relativos à plataforma pesquisada. Por fim, como o utilizador pesquisou uma

plataforma em específico, centra-se a vista do mapa na localização da plataforma seleccionada, e aumenta-se o zoom

para focar essa plataforma.

Um método mais eficiente para a busca de plataforma por nome, uma vez que se pretende reduzir o número

de comunicações com o servidor e que toda a informação das plataformas está disponível no cliente desde a sua

inicialização, é iterar o último resultado da operação GetPlatforms(), i.e., o array GetPlatformsResult.lastResult.

Assim, o handler searchButton_clickHandler ao invés de efectuar um pedido ao servidor, como apresentado no

diagrama da Figura 5.23, apenas itera o array GetPlatformsResult.lastResult até encontrar a plataforma. Se a

plataforma existir passa-se a plataforma para uma variável do tipo Platform, que está ligada à tabela searchDataGrid,

e portanto, a plataforma encontrada é apresentada nesta tabela. Todo o processo depois da alteração para o estado

searchState é o mesmo ao indicado pelo diagrama de sequência da Figura 5.23.

5.2.5 Histórico de um sensor

A aplicação permite ao utilizador consultar o histórico dos valores de qualquer sensor ao longo do tempo. Estes

valores são apresentados num gráfico, cujo eixo dos YY se referem aos valores do sensor num determinado tempo dado

pelo eixo dos XX, como aliás se pode ver pela Figura 5.24 que também ilustra o estado graphFormDetails. A Figura

5.25 ilustra a declaração de um controlo LineChart em MXML que corresponde ao gráfico usado. O controlo LineChart

representa a informação como uma série de pontos, em coordenadas cartesianas, ligados através de uma linha

contínua [56]. Cada tipo de controlo de gráfico possui uma propriedade dataProvider que especifica a variável que

contém os dados do gráfico, e uma classe Series que tem como objectivo definir qual é o atributo do dataProvider que

vai preencher cada um dos eixos [56].

FIGURA 5.24 – GRÁFICO QUE APRESENTA OS VALORES DO SENSOR PRESSURE1 DA PLATAFORMA LISBONPLAT REFERENTES AO DIA ACTUAL. O EIXO

DOS YY REPRESENTAM OS VALORES DO SENSOR, E O EIXO DOS XX A ESCALA DE TEMPO.

106

Por exemplo, no caso da Figura 5.25, o dataProvider é o resultado da operação que retorna o registo diário de um

determinado sensor: a propriedade lastResult do objecto GetSensorDayHistoricResult, que neste caso é um array

do tipo SensorHistory (ver 5.1.2), que por sua vez contém os atributos value e date. Assim, a LineSeries especifica o

atributo value como o eixo dos YY e o atributo date como eixo dos XX. Depois de definida a LineSeries, é necessário

definir os eixos do LineChart. Neste caso, pretende-se que o eixo dos YY sejam os valores do sensor, portanto, pode-se

definir um eixo vertical numérico linear. No caso do eixo horizontal, pretende-se que este apresente tempos e datas, e

por isso, pode-se definir um eixo horizontal DateTimeAxis.

Neste caso apenas se declarou uma LineSeries, mas era possível declarar mais do que uma, por exemplo, se

fosse possível/necessário seleccionar dois sensores na tabela. Podia-se então declarar uma outra LineSeries referente

ao segundo sensor seleccionado na tabela com uma propriedade dataProvider própria.

<mx:LineChart includeIn="graphFromDetails, graphFromSearch" id="sensorChart" dataProvider="{GetSensorDayHistoricResult.lastResult}" showDataTips="true" … >

<mx:series><mx:LineSeries id="lineSeries" displayName="{selectedSensor}" yField="value" xField="date" form="curve">[...]</mx:LineSeries>

</mx:series><mx:verticalAxis>

<mx:LinearAxis id="l1" displayName="Value"/></mx:verticalAxis><mx:horizontalAxis>

<mx:DateTimeAxis id="dateAxis" parseFunction="dateParseFunction" autoAdjust="true" displayLocalTime="true"alignLabelsToUnits="true" displayName="Date"/>

</mx:horizontalAxis>[...]

</mx:LineChart><mx:Legend includeIn="graphFromDetails, graphFromSearch" dataProvider="{sensorChart}" … ></mx:Legend>

FIGURA 5.25 – DEFINIÇÃO DE UM LINECHART EM MXML

É importante salientar a propriedade parseFunction do DateTimeAxis. Esta especifica uma função (ver Anexo H) que é

chamada sempre que o valor para o DateTimeAxis precisa de ser calculado [56]. Neste caso o Flex não reconhece o

formato da data retornado pelo MySQL (e.g., 2011-07-23 18:09:08) e, por isso, é necessário convertê-lo para um

objecto do tipo Date. O que se faz é começar por separar com base no espaço a hora da data usando a função split(),

obtendo um array com a hora numa posição e a data noutra. Pode-se separar cada elemento da data e da hora através

da mesma função, especificando o separador (‘-’) e (‘:’) respectivamente. Por fim, cria-se um novo objecto Date através

de cada elemento extraído. De notar que esta função é chamada por cada valor do sensor que se pretende visualizar, e

por isso, é importante mantê-la o mais curta possível para não afectar o desempenho da aplicação nesta situação. Por

esta razão é preferível formatar a data no servidor através de e.g., o comando SQL DATE_FORMAT. Este pode ser

incluído no comando SELECT executado pelas operações relacionadas com o histórico de modo a retornar a propriedade

date num formato que o Flex já reconheça:

SELECT value, DATE_FORMAT(date, '%Y/%m/%d %H:%i:%S') AS date FROM sensor_history WHERE […]

Como ilustrado pelo diagrama de máquina de estados no início da secção 5.2, a consulta do histórico dos sensores pode

ser efectuada a partir de dois estados distintos – searchState e platDetails. Em ambos, o utilizador pode carregar

numa linha da tabela de sensores, para consultar o histórico do respectivo sensor. Após o clique (ver a Figura 5.26), a

respectiva função de callback é chamada e a primeira coisa que verifica, é se a aplicação já esteve num dos estados que

apresentam o gráfico (graphFromDetails ou graphFromSearch).


107

FIGURA 5.26 – DIAGRAMA UML DE SEQUÊNCIA RELATIVO À VISULIZAÇÃO DO HISTÓRICO DE UM SENSOR

Isto faz-se verificando se o objecto xAxisList já foi instanciado, uma vez que este é criado aquando da transição para

um desses estados. Este objecto é uma DropDownList com quatro valores diferentes, que permite ao utilizador

seleccionar o intervalo de tempo que pretende visualizar: todos os valores do dia actual, mês, ano, ou desde que existe


108

um registo do sensor. No caso da transição para um dos estados que apresentam o gráfico ser efectuada pela primeira

vez, a aplicação pede por defeito o histórico do dia actual do sensor seleccionado. O pedido é efectuado através da

operação GetSensorDayHistoric(), que recebe como parâmetros o id da plataforma a que o sensor pertence, o nome

do sensor, e o dia actual do mês. Estes são depois usados para executar uma query que retorna todos os registos do

sensor desse mesmo dia. Depois de a operação estar concluída e retornar todos os valores com sucesso, o handler de

conclusão do pedido é chamado. Este começa por transitar para um dos estados graphFromDetails ou

graphFromSearch, de acordo com o estado actual (platDetails ou searchState, respectivamente), e depois cria

vários objectos, nomeadamente o LineChart, DropDownList, um HSlider, dois botões e dois objectos do tipo

DateField. Agora é necessário associar esses valores ao gráfico, e para isso usa-se novamente o bind. A Figura 5.27

apresenta a listagem referente a este handler. Define-se a fonte de informação usada para preencher o gráfico

igualando a propriedade dataProvider. Como existe a necessidade de alterar o dataProvider em runtime, é

necessário alterar essa mesma propriedade no código AS. Qualquer propriedade de um objecto definido no código

MXML, pode ser acedida e alterada programaticamente no código AS. Relembre-se que o que se está a fazer, é a

vincular o resultado da operação GetSensorDayHistoric() ao gráfico à propriedade lastResult do objecto

GetSensorDayHistoricResult. Para que tudo fique coerente, selecciona-se programaticamente a string “Today” na

DropDownList. Como se pretende visualizar os valores de apenas um dia, define-se a unidade da escala do eixo dos XX

como horas, sendo que, por defeito, o Flex ajusta automaticamente o intervalo de horas de acordo com os valores

existentes. No entanto, é também possível ajustar manualmente esse intervalo através do HSlider. No entanto, o

componente HSlider incluído por defeito na framework, apenas possui um controlo que indica o valor actual

seleccionado no slider, i.e., não permite definir um intervalo de valores, e portanto para definir dois limites seriam

necessários dois HSlider. Por isso, utilizou-se um componente HSlider de uma biblioteca livre (flexLib) que permite

definir vários controlos. Assim, definindo dois controlos que podem ser arrastados ao longo do slider, é possível

controlar um determinado intervalo dado pelos valores situados entre os dois controlos. Para além das horas, existem

outras unidades para o eixo dos XX, nomeadamente dias, meses e anos, de acordo com o item seleccionado na

DropDownList (respectivamente, Month, Year, All).

protected function GetSensorDayHistoricResult_resultHandler(event:ResultEvent):void{

if(currentState != "graphFromSearch" && currentState != "graphFromDetails"){if(currentState == "searchState")

currentState = "graphFromSearch";else

currentState = "graphFromDetails";}//Definir o dataProvider do gráfico:sensorChart.dataProvider = GetSensorDayHistoricResult.lastResult;//Por defeito mostra sempre os registos diários.xAxisList.selectedItem = "Today";dateAxis.dataUnits = "hours";//Definir os valores que o slider pode levar 00 a 24minSlider.minimum = 0;minSlider.maximum = 24;minSlider.setThumbValueAt(0,0);minSlider.setThumbValueAt(1,24);

}

FIGURA 5.27 – FUNÇÃO CALLBACK DA CONCLUSÃO DA OPERAÇÃO GETSENSORDAYHISTORIC


109

Consequentemente é necessário definir os valores possíveis do slider. No caso do registo diário, um dia tem vinte e

quatro horas, e portanto coloca-se o valor mínimo a zero e o máximo a vinte e quatro. Estes valores podem ser

alterados em runtime arrastando um ou ambos os controlos do slider. Sempre que haja alteração de valores no slider, é

chamada a respectiva função de callback que, dependo da unidade de escala, cria uma nova data e define o valor

mínimo ou máximo do eixo dos XX segundo essa data. Como a propriedade autoAdjust do DateTimeAxis foi definida

como true (ver Figura 5.25), é também sempre possível ajustar o intervalo automaticamente através do botão

autoAdjustButton, cujo handler simplesmente anula o limite do slider, para que o Flex proceder com o ajuste

automático.

Voltando ao diagrama da Figura 5.26, se a mudança de estado não for feita pela primeira vez, a função

GetSensorSelectedHistoric() é executada e a aplicação também transita de estado de acordo com diagrama de

sequência “Change to graph state” anteriormente descrito. A função GetSensorSelectedHistoric() (Anexo I) trata de

efectuar o pedido do histórico de um sensor ao servidor, de acordo com a string seleccionada na DropDownList. Por

exemplo, se o item seleccionado for “Month”, a aplicação pede ao servidor o registo mensal do sensor seleccionado

invocando a operação GetSensorMonthHistoric(), e define as unidades do eixo dos XX e os valores do slider de forma

adequada. É de salientar que nesta função, a propriedade dataProvider do gráfico não é actualizada, uma vez que aqui

apenas se faz o pedido ao servidor. Este pedido é assíncrono e pode demorar o seu tempo, por isso, a propriedade

dataProvider só é actualizada no handler da conclusão do pedido, tal como foi feito na Figura 5.27.

Apenas com as operações descritas, se o utilizador pretender visualizar e.g., o histórico dos últimos 15 dias, é

necessário pedir todo o histórico mensal. Do mesmo modo, se o utilizador pretender visualizar o histórico dos últimos 2

meses, teria que pedir o histórico anual. Como referido em 5.1.2, a operação GetBetweenSensorHistoric() retorna o

histórico de um sensor entre as duas datas passadas como parâmetro. Para isso bastou incluir os dois componentes

DateField e o botão betweenButton, cujo clique resulta na execução do pedido GetBetweenSensorHistoric(). O

componente DateField é uma simples textBox não-editável que apenas aceita datas num formato que pode ser

customizado, e que cujo clique resulta no aparecimento de um calendário (ver Fig. C do Anexo D). O utilizador pode

então escolher as datas a partir do calendário e carregar no botão para invocar a operação

GetBetweenSensorHistoric(). Quando a operação estiver concluída, basta alterar a propriedade dataProvider do

gráfico.

5.2.6 Actualização da informação

Plataformas 5.2.6.1

A actualização regular do estado das plataformas e dos sensores é o ponto mais importante da aplicação, no

que diz respeito à função de monitorização, e é feita através de um temporizador cuja contagem é iniciada após o login.

Quando a contagem chega ao fim, é executado o handler desse evento (a função updateData()), que apenas invoca a

operação GetUpdatedPlatforms(). Ou seja, a aplicação começa por receber os valores actualizados dos atributos das


110

plataformas (Figura 5.28). Quando a operação estiver concluída, o CallResponder GetUpdatedPlatformsResult trata

do resultado através da sua função de callback referente à conclusão do pedido:

GetUpdatedPlatformsResult_resultHandler() (ver listagem no Anexo J). Basicamente, esta função percorre todas

as plataformas recebidas (GetUpdatedPlatformsResult.lastResult[]) e actualiza os seus atributos na variável ligada

à tabela com todas as plataformas (GetPlatformsResult.lastResult[]). No entanto, existem certas particularidades

que são importantes analisar, nomeadamente o facto de uma plataforma poder ser criada ou apagada. Como se pode

ver pelo diagrama da Figura 5.28, a função GetUpdatedPlatformsResult_resultHandler() começa por verificar se o

estado actual é o searchState.

refreshTimer:Timer

GetUpdatedPlatforms():Platform_Update

GetUpdatedPlatformsResult:CallResponder

loop countUpdated < platformsUpdateCount

alt if(GetUpdatedPlatformsResult.lastResult[CountUpdated].task == "create" || GetUpdatedPlatformsResult.lastResult[CountUpdated].task == "delete")

opt if(currentState == “searchState”)

loop countSearchedUpdated <platformsUpdateCount

opt if(GetPlatByNameResult.lastResult.id == GetUpdatedPlatformsResult.lastResult[CountsearchedUpdated].id)

loop countPlats < platformsCount

opt GetPlatformsResult.lastResult[CountPlats].id == GetUpdatedPlatformsResult.lastResult[CountUpdated].id

ServidorFlash Player

updateData(eventArgs:TimerEvent):void

Actualiza atributos da plataforma

GetUpdatedPlatSensors():Sensor

GetPlatforms();

Actualiza atributos da plataforma

break;

break;

GetUpdatedPlatformsResult_resultHandler(event:ResultEvent):void

FIGURA 5.28 – DIAGRAMA UML DE SEQUÊNCIA REFERENTE À ACTUALIZAÇÃO DAS PLATAFORMAS


111

Isto é importante, porque a tabela do searchState está ligada à variável GetPlatByName.lastResult, que contém a

plataforma retornada pela operação GetPlatByName(), o que significa que, uma vez que as actualizações são feitas

apenas em GetPlatformsResult.lastResult[], se ocorrerem após a pesquisa (GetPlatByName()) e o utilizador

ainda estiver a monitorizar a plataforma pesquisada (a aplicação está no searchState), os seus atributos não são

actualizados. Assim, por prevenção, percorrem-se as plataformas que foram actualizadas, e verifica-se se alguma

corresponde à plataforma da busca. Se for o caso, actualiza-se essa plataforma no estado searchState, garantindo-se

que a informação fica actualizada em todos os estados.

A segunda parte da função percorre novamente todas as plataformas que foram actualizadas, mas verifica através do

atributo task, retornado pela operação GetUpdatedPlatforms(), se uma plataforma foi criada ou apagada. Como todas

as plataformas estão no objecto GetPlatformsResult.lastResult[], e a criação ou remoção de uma plataforma é

uma situação que deve ocorrer com muito pouca frequência, é preferível neste caso pedir novamente todas as

plataformas. Se este for o caso, pode-se parar o ciclo, uma vez que todas as plataformas vão ser actualizadas. Por fim,

se uma plataforma não for criada ou apagada, é porque foi actualizada e, portanto, basta verificar quais as plataformas

que foram actualizadas, e actualizar os respectivos atributos.

Sensores 5.2.6.2

Depois das plataformas, é a vez de os sensores serem actualizados através da operação

GetUpdatedPlatSensors(), que retorna todos os sensores cujos valores sofreram alterações. A actualização dos

sensores é bastante mais frequente do que a actualização das plataformas e exige mais processamento por parte da

aplicação. Além disso, é natural que a cada refrescamento da aplicação, os valores de todos os sensores se alterem, o

que significa que tipicamente todos os sensores são actualizados. Esta actualização é feita dentro de dois ciclos for

encadeados (Figura 5.29), pelo que o primeiro percorre todos os sensores que foram actualizados, e o segundo todos os

sensores que existem. Cada iteração começa por verificar se um determinado sensor sofreu alterações desde o último

refrescamento, através da comparação do id da plataforma a que pertence e do respectivo nome. Para esses sensores

actualiza-se o atributo value. Depois de todos os sensores actualizados, é necessário averiguar de que maneira é que

o estado global de uma plataforma foi afectado pelos novos valores dos sensores, e actualizá-lo se necessário. Isto é

feito pela função checkPlatStatus(), cuja listagem se encontra no Anexo K. Aqui tem-se novamente dois ciclos

encadeados, mas neste caso, o primeiro percorre todas as plataformas, e o segundo todos os sensores. O objectivo do

segundo ciclo é contar o número de sensores, cujos valores ultrapassam os thresholds, bem como verificar se

porventura a plataforma se encontra com uma falha de energia. Depois de percorridos todos os sensores de uma

plataforma, segue-se a porção de código que determina o novo estado global da plataforma. Como a aplicação é um

protótipo e não se conhecem os valores reais de bom funcionamento de cada sensor, nem tão-pouco a gravidade de um

determinado sensor ultrapassar o threshold, então estipulou-se o seguinte:

• Se uma plataforma está perante uma falha de energia, e portanto está a ser alimentada a bateria, o estado

global da plataforma passa a ser “Battery”. Este estado é identificado pelo ícone vermelho de mau estado,

juntamente com um ícone que identifica a falha de energia (raio);


112

• Se uma plataforma possui mais do que cinco sensores com valores acima ou abaixo do threshold crítico, o

estado global da plataforma passa a ser “Bad”. Este estado é identificado pelo ícone vermelho de mau estado;

• Se uma plataforma possui pelo menos um sensor cujo valor está acima ou abaixo do threshold crítico, o estado

global passa automaticamente para “Acceptable”. Este estado é identificado pelo ícone amarelo de estado

aceitável;

• Se uma plataforma possui mais de cinco sensores com valores acima ou abaixo dos threshold de

funcionamento normal, o estado da plataforma passa a ser “Acceptable”, também identificado pelo ícone

amarelo;

• Se nenhuma das situações acima se verificar, o estado global da plataforma passa a ser “Good”. Este estado é

identificado pelo ícone verde de bom estado.

GetUpdatedPlatSensorsResult:CallResponder

loop CountUpdated < sensorsUpdateCount

loop CountSensors < sensorsCount

GetPlatSensorsResult.lastResult[CountSensors].value = GetUpdatedPlatSensorsResult.lastResult[CountUpdated].value;

checkPlatStatus(platId:String):String

placeMarkers():void

updatePlatStatus(platState:String, platId:int, countPlats:int):void

Servidor

opt platforms != nullsetDataGridSensors(plat_id:String):void

opt GetPlatformsResult.lastResult[countPlats].status != platState

updatePlatStatus(platId,platState):void

GetPlatformsResult.lastResult[countPlats].status = platState;

Flash Player

GetUpdatedPlatSensorsResult_resultHandler(event:ResultEvent):void

FIGURA 5.29 – DIAGRAMA UML DE SEQUÊNCIA REFERENTE À ACTUALIZAÇÃO DOS SENSORES

Depois de determinado o novo estado global da plataforma, a aplicação de monitorização actualiza o estado de uma

plataforma localmente e remotamente na BD, através da operação updatePlatStatus() (ver Anexo L). Ambas as

actualizações (local e remota), apenas são efectuadas se o estado global da plataforma foi alterado desde o último

refrescamento. Assim, evita-se um pedido desnecessário ao servidor.

Finalmente é ainda necessário actualizar o array dos sensores da plataforma que eventualmente possa estar

seleccionada. Isto é conseguido usando a função setDataGridSensors() (explicada na secção 5.2.3), que apenas é

executada se uma plataforma estiver seleccionada. Por fim, removem-se e colocam-se novamente todas as plataformas

no mapa, com os ícones actualizados, através da função placeMarkers() (ver 5.2.2).


113

SensorDataGrid – Cor de fundo 5.2.6.3

A SensorDataGrid, para além de apresentar os sensores da plataforma seleccionada, possui a particularidade

de “pintar” as linhas da tabela de acordo com o valor do sensor, conforme ilustrado por exemplo na Figura 5.21 e na Fig.

B do Anexo D. Se o valor de um sensor é maior ou menor que o valor do threshold crítico máximo ou mínimo

respectivamente, a linha é pintada de vermelho. Por outro lado, se o valor de um sensor é maior ou menor que o valor

do threshold normal máximo ou mínimo respectivamente, a linha é pintada de amarelo. Numa situação em que o valor

esteja dentro dos limites de bom funcionamento, a cor do fundo da linha é a cor aplicada pelo tema da aplicação.

O componente DataGrid não suporta por defeito a alteração da cor de fundo de uma linha, por isso foi

necessário criar um componente que é na realidade uma subclasse da DataGrid. Aliás, em todos os diagramas UML de

sequência apresentados em que a sensordatagrid é interveniente, pode verificar-se que este objecto é na verdade do

tipo SensorDataGrid, que estende as funcionalidades do componente DataGrid (Figura 5.30). Reescreveu-se o

método drawRowBackground(), que trata do desenho do fundo das linhas de uma DataGrid, e declarou-se uma função

de callback que, se definida, determina a cor do fundo antes de este ser desenhado. A função de callback pode ser

definida como qualquer uma das outras em MXML:

<local:SensorDataGrid dataProvider="{platSensors}" rowColorFunction="calcRowColor" […] </local:SensorDataGrid>

Sempre que o método drawRowBackground() é chamado, e.g., quando um objecto SensorDataGrid é criado, ou

sempre que haja alterações na propriedade dataProvider, a cor de fundo de cada linha é calculada pela função de

callback calcRowColor (ver Anexo M). Note-se que a SensorDataGrid não apresenta uma coluna para os valores de

threshold, mas isto não significa que esses valores não estejam no dataProvider, até porque os valores de threshold

são retornados pela operação GetPlatSensors(). Portanto, esses valores estão na SensorDataGrid, apenas não estão

visíveis.

+drawRowBackground() : void

Datagrid

#drawRowBackground() : void+rowColorFunction

SensorDataGrid

{public var rowColorFunction:Function;

override protected function drawRowBackground(...):void{ //Se a função estiver definida no código MXML e existir um dataprovider if(rowColorFunction != null && dataProvider != null) { ... //Se a celula tiver um valor (item) chama a rowColorFunction para calcular a cor if(item){ color = rowColorFunction(item, rowIndex, dataIndex, color);} } super.drawRowBackground(s, rowIndex, y, height, color, dataIndex);}

FIGURA 5.30 – CLASSE SENSORDATAGRID


114

5.3 Simulador

A última etapa deste trabalho diz respeito ao desenvolvimento de uma aplicação, numa linguagem à escolha,

que permita a alteração dos dados da BD, simulando assim a chegada ao sistema de dados vindos das plataformas. Na

data de escrita deste documento, ainda não se encontram desenvolvidas plataformas, portanto é importante o

desenvolvimento desta aplicação para testar o protótipo implementado.

Optou-se por desenvolver a aplicação novamente em Flex, em parte porque se pode reutilizar algum código do

protótipo. A aplicação é composta por basicamente duas tabelas que permitem a alteração manual dos dados que

constam na BD. Uma tabela apresenta todas plataformas, e a outra, os sensores de todas as plataformas, e a

apresentação delas pode ser alternada através do clique num separador (ver Figura 5.32). O utilizador pode

manualmente adicionar/remover uma plataforma, bem como actualizar os seus atributos. Do mesmo modo, pode-se

alterar o valor de um sensor manualmente a partir da tabela dos sensores, incluindo a simulação de uma falha de

energia numa plataforma editando o campo do respectivo sensor. Todas as alterações realizadas são enviadas para a

BD.

A alteração dos dados que constam na BD pode também ser feita automaticamente de forma aleatória. A

aplicação é dotada de um temporizador, cujo tempo de contagem pode ser alterado em runtime, que dita o período da

alteração de um valor. Em cada período é aleatoriamente gerado o id de uma plataforma, um nome de sensor e o

respectivo valor. Isto significa que, com esta aplicação e a aplicação de monitorização a serem executadas em

simultâneo, pode-se simular o sistema completo e sobretudo testar a aplicação de monitorização: verificar a alteração

dos valores dos sensores, a actualização dos sensores na tabela, actualização do estado global de uma plataforma,

incluindo a colocação do marcador que identifica o estado, entre outros.

FIGURA 5.31 – APLICAÇÃO DE TESTE QUE FORNECE DADOS FICTÍCIOS À BD

A geração aleatória de todos os valores é feita pela classe SensorSimulator, criada unicamente para o efeito (Figura

5.33). Esta classe possui dois atributos do tipo Array – sensorValues e sensorNames. O primeiro armazena os valores

que podem ser gerados para um determinado sensor, e o segundo armazena os nomes dos sensores que entram na


115

simulação. No primeiro caso, é necessário incluir o nome do sensor no array, pois os valores de threshold diferem de

acordo com o tipo de sensor. Os valores armazenados neste array são na realidade ligeiramente superiores ao valor

crítico máximo de threshold do sensor, por forma a ser possível gerar um valor acima desse mesmo threshold, embora a

probabilidade seja menor. Todos os métodos da classe SensorSimulator são estáticos, pelo que não é necessário criar

uma instância da mesma.

+generatePlatId(entrada platNumber : int) : int+generateSensorName() : string+generateSensorValue(entrada sensorName : string) : Double

-sensorValues : Array-sensorNames : Array

SensorSimulator

FIGURA 5.32 – CLASSE SENSORSIMULATOR

Considere-se a função de callback correspondente ao fim da contagem do temporizador que estabelece o intervalo de

geração de valores (Figura 5.34). Sempre que o temporizador termina uma contagem, esta função é executada.

Começa-se por gerar um id de uma plataforma através do método generatePlatId(), pelo que para isso, passa-se o

número total de plataformas menos um (senão existia a probabilidade de ser gerado um id que não existe). O id

retornado é o id da plataforma cujo determinado sensor sofrerá alteração. Depois gera-se o nome do sensor que será

actualizado através do método generateSensorName(). O atributo sensorNames da classe sensorSimulator armazena

os nomes dos sensores que entram na geração de valores, pelo que o método generateSensorName()gera um nome

de um sensor do seguinte modo:

randomInt:int = int((sensorNames.length - 1) * Math.random());

Depois a função generateSensorValue() recebe o nome do sensor gerado, procura o nome do sensor no array

sensorValues, e gera um valor aleatório para esse sensor. Por fim, percorre-se todos os sensores até se encontrar o

sensor que deve sofrer a alteração do valor. Quando encontrado, actualiza-se o valor localmente e na BD através da

operação updateRandom().

private function updateRandomData(eventArgs:TimerEvent):void{//Gera um número equivalente a um determinado Id de uma plataformarandomId = SensorSimulator.generatePlatId(GetPlatformsResult.lastResult.length - 1);//Gera um nome de um sensorrandomName = SensorSimulator.generateSensorName();//Gera um valor para o sensor, dado o sensorrandomValue = SensorSimulator.generateSensorValue(randomName);//Precorrer os sensores para actualizar localmente:for(var i:int = 0; i < Number(GetPlatSensorsResult.lastResult.length); i++){

//Se o id e o nome corresponderem, altera o valor localmente:if(GetPlatSensorsResult.lastResult[i].plat_id == randomId &&

GetPlatSensorsResult.lastResult[i].sensor_name == randomName){GetPlatSensorsResult.lastResult[i].value = randomValue;trace("Actualizou localmente")break;

}}//Actualiza na BD:platAdminService.updateRandom(randomName,randomId,randomValue);trace("Actualizou na BD")

}

FIGURA 5.33 – FUNÇÃO UPDATERANDOMDATA()


117

6 Conclusão

6.1 Análise de resultados

Os objectivos propostos para este trabalho foram atingidos. O objectivo final foi alcançado, tendo sido

implementada uma aplicação de monitorização que cumpre os requisitos especificados. Além disso, este trabalho

atingiu também o objectivo intermédio, que era produzir um estudo experimental comparativo das tecnologias

relevantes para aplicações deste tipo.

Estudou-se o conceito RIA, que, como ilustra este documento, mudou radicalmente a forma como as

aplicações de internet são desenvolvidas e contribui para a convergência entre as aplicações web e desktop. Uma RIA

possui características que permitem cumprir os requisitos especificados para a aplicação de monitorização,

nomeadamente a GUI sofisticada e a redução do tráfego de rede, e por isso foi uma opção acertada. A arquitectura da

aplicação foi definida com base num estudo de várias tecnologias RIA, e na realização de diversas experiências que

seguem uma perspectiva global da aplicação, pois incluem a combinação das diferentes alternativas para cada

componente.

Nestas experiências, concluiu-se que para o cliente, o Flex facilita a implementação dos requisitos impostos,

proporcionando um IDE poderoso com uma conexão a serviços remotos completa e de fácil utilização, um número

elevado de componentes, adequados à aplicação pretendida, e que proporcionam uma interface apelativa e interactiva.

Para as tecnologias de comunicação, o Remoting/AMF além de se encaixar perfeitamente com a tecnologia usada no

cliente, proporciona uma rápida transferência de dados entre o cliente e o servidor, o que é importante dado o número

de plataformas e sensores que possam existir.

Com a existência de tantas tecnologias para o desenvolvimento de RIA, as conclusões da análise comparativa

relativa ao GUI, contribuem para o esclarecimento de qual a tecnologia mais adequada de acordo com os aspectos

avaliados, nomeadamente o aspecto da UI, a experiência oferecida ao utilizador, a carga de processamento sobre o

servidor, a facilidade de implementação das funcionalidades requeridas, entre outros. De facto, concluiu-se que as três

tecnologias em estudo (Ajax, JavaFX e Flex) possuem áreas em que se distinguem, e que todas podem ser usadas para

cumprir uma determinada tarefa. Na verdade, podem até ser utilizadas em simultâneo. Por exemplo, poderia aceder-se

à aplicação de monitorização através do portal da empresa que trata do sistema. A ideia de desenvolver todo o portal

em Flex não seria provavelmente a melhor opção. Ao invés disso, podia desenvolver-se o portal com recurso às

tecnologias que constituem o Ajax, e inserir a aplicação de monitorização Flex no portal. Além disso, o portal pode

necessitar também de uma mini aplicação em que se justifique o uso do JavaFX. Portanto, todas as tecnologias

abordadas podem coexistir, pois têm valências importantes.

Além da interface, a aplicação web é constituída também pela parte do servidor, e por isso, é importante o

estudo das tecnologias de comunicação. Foram portanto analisadas as características do SOAP, REST e Remoting/AMF,

e as vantagens e desvantagens de cada uma. Como a interoperabilidade poderia ter sido um factor importante neste


118

trabalho (dependia da escolha do cliente), estudou-se o conceito dos Web Services. Por outro lado, a velocidade de

transferência final de dados entre o cliente e o servidor é importante numa aplicação deste tipo, principalmente na

tarefa de monitorização, e por isso o Remoting/AMF foi também estudado. A análise destas tecnologias foi

complementada com a implementação de várias combinações de clientes e servidores, em linguagens diferentes, que

usaram os meios de comunicação referidos. Deste modo, obteve-se além de uma visão global, uma visão específica das

facilidades (ou dificuldades) encontradas na implementação das tecnologias de comunicação em cada uma das

linguagens. Este estudo serve também como referência, e pode de facto contribuir para a tomada de decisão acerca de

qual das tecnologias de comunicação é mais vantajosa de acordo com a circunstância, e.g., a interoperabilidade é

importante numa situação em que se pretenda desenvolver um serviço que suporte clientes de plataformas diferentes.

Neste caso, os Web Services, são a escolha acertada. Por outro lado, se a velocidade de transferência de dados é

importante e o programador estiver disposto a utilizar a plataforma Adobe no lado do cliente, o serviço Remoting/AMF

pode ser facilmente construído em inúmeras linguagens server-side.

As plataformas ainda estão em desenvolvimento e a sua distribuição geográfica e número global não está

previsto, pelo que ainda não está definido se haverão vários centros de monitorização espalhados por algumas zonas do

globo, ou apenas um a nível mundial. A opção pela implementação apresentada nesta tese, com tabelas de update

utilizando triggers na BD, constitui um esforço de optimização do desempenho do servidor, no sentido de poder

suportar o maior número de plataformas possível. Esta solução aumenta a viabilidade de um único servidor global, mas

suporta apenas um cliente. Alternativamente foi também implementada uma versão do sistema que suporta vários

clientes para o mesmo servidor (seja global ou não). Esta solução apesar de mais pesada computacionalmente para o

servidor é mais simples do ponto de vista de implementação. Consistiu apenas:

• No servidor: (1) retirar os triggers, e consequentemente a criação de tabelas de update, (2) acrescentar

um campo timestamp a cada entrada das tabelas de plataformas e sensores, e (3) adicionar uma função

ao WebService que aceita uma data de referência e retorna dados com dada posterior, tanto para

plataformas como sensores;

• No cliente: (1) no final de uma actualização guardar a hora em que esta ocorreu, e (2) invocar as novas

funções do WebService enviando a hora da actualização anterior.

Concluindo, este documento é útil para todos os que pretendem desenvolver aplicações web, nomeadamente

RIA, com requisitos semelhantes aos deste trabalho, na medida em que serve de apoio à decisão da arquitectura geral

de uma aplicação web, e à escolha de cada componente de forma individual.

6.2 Conclusões e trabalho futuro

Esta dissertação descreve o desenvolvimento de uma aplicação que permite a monitorização de plataformas

marítimas geradoras de energia. Esta aplicação é acessível através da web, mas não é uma aplicação web tradicional,

pois possui características sofisticadas semelhantes às das aplicações desktop.


119

Este trabalho começa por evidenciar a importância dos Web Services e da interoperabilidade na conjuntura

web actual devido à existência de uma infinidade de sistemas e tecnologias diferentes. Fez-se a descrição teórica de

várias tecnologias de comunicação web, onde estão incluídas as duas grandes abordagens para o desenvolvimento de

Web Services – SOAP e REST; estas são indiscutivelmente ferramentas importantes para qualquer programador. Fez-se

depois, uma breve análise à evolução da World Wide Web, onde se conclui que as aplicações web de hoje são bastante

mais sofisticadas, e que combinam vantagens das aplicações desktop e web tradicionais, proporcionando interfaces

ricas, interactivas e mais eficientes. Estas são chamadas Rich Internet Applications, e como se pode verificar, possuem

vantagens óbvias relativamente às aplicações web tradicionais, pelo que o protótipo final desenvolvido neste trabalho

foi precisamente uma RIA; esta foi de resto a escolha mais acertada, pois apenas uma RIA pode cumprir os requisitos

impostos inicialmente neste trabalho. No entanto, esta dissertação não se limita apenas em fazer o usual estudo

teórico, e partir de imediato para a implementação da aplicação final. Ao invés disso, avalia-se também várias

tecnologias intencionadas para o desenvolvimento de RIA, através da implementação de pequenas aplicações de

estudo, e portanto mostra-se como uma RIA pode ser implementada através de tecnologias como o Ajax, Flex ou do

JavaFX. A experimentação clarificou as vantagens e desvantagens de cada tecnologia no âmbito da aplicação

pretendida, bem como na sua generalidade. Depois, exemplificou-se ainda como se pode criar um serviço SOAP e REST

em PHP e Java, e consumir esse serviço com aplicações desenvolvidas em linguagens distintas. Este segundo conjunto

de experiências serviu também para avaliar a melhor opção relativamente à tecnologia de comunicação entre o cliente

e o servidor, pelo que se chegou à conclusão que para este caso, o AMF foi a escolha acertada, apesar das desvantagens

terem sido clarificadas. Além destas duas decisões, foram ainda testados três serviços de mapas diferentes, onde se

conclui que os três são bastante semelhantes e fornecem um conjunto razoável de APIs para várias linguagens.

O trabalho futuro passará principalmente pela integração da comunicação com as plataformas no servidor. O

servidor deverá ser dotado de um ou mais scripts PHP, que gerem a recepção de dados das plataformas (introduzem os

dados nas tabelas da BD), e o envio de dados para as plataformas, nomeadamente os comandos para desligar/ligar

actuadores, e comandos para desligar as leituras de determinados sensores. A comunicação entre as plataformas e o

servidor, também deve ser feita de forma a minimizar o tráfego de rede e a reduzir a carga de processamento no

servidor. O AMF aqui não é opção, e portanto das tecnologias abordadas, restam os Web Services. À partida o REST é

preferível ao SOAP, uma vez que a análise do documento XML é mais rápida e não exige a instalação de bibliotecas

adicionais. No entanto existem outras opções que podem ser avaliadas, como por exemplo, REST com HTTP e JSON para

o formato de dados.

Outra melhoria futura inclui a implementação de mais dois estados para cada plataforma – o Not Responding e

o Drifting, que indicam respectivamente que a plataforma não tem enviado dados, e que a posição geográfica da

plataforma está fora dos limites normais, podendo significar que a plataforma está à deriva. A implementação do

estado Not Responding pode ser feita analisando a última vez que a plataforma comunicou com o servidor através da

leitura de um campo timestamp da BD. Este campo seria actualizado sempre que a plataforma comunicasse com o

servidor. Se o timestamp correspondente à última comunicação da plataforma com o servidor fosse maior do que um

tempo máximo de timeout a determinar, a aplicação podia então emitir um alerta ao utilizador. O estado Drifting pode

ser implementado através da adição de dois campos na BD contendo a latitude e longitude que definem o centro


120

geográfico das localizações possíveis de uma plataforma. O cliente podia então verificar se cada plataforma estava

numa posição geográfica dentro dos limites de distância pré-definidos relativamente ao respectivo centro geográfico. A

implementação desta solução pode ser auxiliada pela técnica de geofencing do serviço de mapas.

Por fim, outras melhorias futuras incluem a incorporação de previsões meteorológicas, através da subscrição

de alertas e acesso a serviços de previsão de acesso livre.


121

Bibliografia

[1] K.-J. Lin, “Building Web 2.0,” Computer, vol. 40 Issue: 5, pp. 101-102, May 2007.

[2] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. Leach e T. Berners-Lee, June 1999. [Online]. Available:

http://ftp.ics.uci.edu/pub/ietf/http/rfc2616.pdf.

[3] D. Gourley, B. Totty, M. Sayer, S. Reddy e A. Aggarwal, HTTP: The definitive Guide, 1st ed., L. Mui, Ed., O'Reilly &

Associates, Inc., 2002.

[4] Internet Corporation for Assigned Names and Numbers, “Internet Assigned Numbers Authority,” [Online].

Available: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml.

[Acedido em 26 Outubro 2011].

[5] M. Kalin, Java Web Services: Up and Running, O'Reilly Media, Inc, 2009.

[6] S. Abeysinghe, RESTful PHP Web Services, 1st ed., Birmingham: Packt Publishing, 2008.

[7] World Wide Web consortium, April 2007. [Online]. Available: http://www.w3.org/TR/soap12-part1/.

[8] X. Feng, J. Shen e Y. Fan, “REST：An Alternative to RPC for Web Services,” em ICFIN 2009: First International

Conference on Future Information Networks, Beijing, 2009.

[9] M. Laitkorpi, J. Koskinen e T. Systä, “A UML-based Approach for Abstracting,” em Proc. of the WCRE'06:

Proceedings of the 13th Working Conference on Reverse Engineering, Pittsburgh, Pennsylvania, 2006.

[10] N.-s. Park e G.-h. Lee, “Agent-based Web Services Middleware,” em Globecom'03 IEEE Global Telecommunications

Conference, Daejeon, South Korea, 2003.

[11] R. T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures,” 2000.

[12] S. K. Chakrabarti e P. Kumar, “Test-the-REST: An Approach to Testing RESTfulWeb-Services,” em Computation

World '09: Future Computing, Service Computation, Cognitive, Adaptive, Content, Patterns, Athens, Greece, 2009 .

[13] E.Wilde e C. Pautasso, REST: From Research to Practice, Springer, 2011.

[14] B. Burke, RESTful Java with JAX-RS: Designing and Developing Distributed Web Services, 1st ed., O'Reilly Media, Inc,

2010.

[15] M. z. Muehlena, J. V. Nickersona e K. D. Swensonb, “Developing web services choreography standards—the case

of,” Decision Support Systems, vol. 40, pp. 9-29, 2005.


122

[16] R. Battle e E. Benson, “Bridging the semantic Web and Web 2.0 with Representational,” Journal of Web Semantics,

p. 61–69, November 2007.

[17] D. Flanagan, J. Farley, W. Crawford e K. Magnusson, Java Enterprise in a Nutshell: A Desktop Quick Reference, 4th

ed., O'Reilly Media Inc, 2005.

[18] Inc., Adobe Systems, "AMF 3 Specification," 2006. [Online]. Available:

http://download.macromedia.com/pub/labs/amf/amf3_spec_121207.pdf.

[19] M. Corlan, August 2011. [Online]. Available: http://corlan.org/flex-for-php-developers/.

[20] Y. Jia e B. Sun, “Refactoring of Stock Exchange Teaching system base on Flex RIA techniques,” em ICCAE '10: The

2nd International Conference on Computer and Automation Engineering (ICCAE), Singapore, 2010.

[21] P. Fraternali, G. Rossi e F. Sánchez-Figueroa, “Rich Internet Applications,” IEEE Internet Computing, vol. 14 no. 3,

pp. 9-12, May - June 2010.

[22] F. Moritz, “Rich Internet Applications (RIA): A Convergence of User Interface Paradigms of Web and Desktop

Exemplified by JavaFX,” Germany, January 2008.

[23] A. Bozzon, P. Fraternali, S. Comai e G. Toffetti, “Conceptual Modeling and Code Generation for Rich Internet

Applications,” em ICWE ’06: Procedings of the 6th international conference of Web engineering, New York, NY, USA,

2006.

[24] J. C. Preciado, M. Linaje, F. Sánchez-Figueroa e S. Comai, “Necessity of methodologies to model Rich Internet

Applications,” em Proc. of the 2005 Seventh IEEE International Symposium on Web Site Evolution (WSE’05), 2005.

[25] J. S. Zepeda e S. V. Chapa, “From Desktop Applications Towards Ajax Web Applications,” em Proc. of ICEEE 2007:

4th International Conference on Electrical and Electronics Engineering, México, 2007.

[26] T. Noda e S. Helwig, “Rich Internet Aplications, Technical Comparison and Case studies of AJAX, Flash, and Java

based RIA,” November 2005.

[27] M. Labriola, J. Tapper e M. Boles, Adobe Flex 4: Training from the source, Volume 1, Adobe Press, 2010.

[28] M. Busch e N. Koch, “Rich Internet Applications, State of Art,” Germany, December 2009.

[29] A. Debinski, B. Sakowicz e M. Kaminski, “Methods of Creating Graphical Interfaces of Web,” em Proc. of the TCSET

'10: Proceedings of the Xth Conference on Modern Problems of Radio Engineering, Telecommunications and

Computer ScienceInternational , Lviv - Slavske, Ukraine, 2010.

[30] L. Gao e Li-YongZhou, “The Improvement of RIA's Software Framework in Flex,” em Proc of the EMEIT '11:

Proceedings of the 2011 International Conference on Electronic and Mechanical Engineering and Information

Technology, Harbin, China, 2011 .


123

[31] J. Wright, “A Modelling Language for Interactive Web Applications,” em ASE '09: 24th IEEE/ACM International

Conference on Automated Software Engineering, Auckland, New Zealand, 2009.

[32] A. Mesbah e A. v. Deursen, “Migrating Multi-page Web Applications to Single-page Ajax Interfaces,” em Proc. of the

11th European Conference on Software Maintenance and Reengineering, March 2007.

[33] January 2008. [Online]. Available: http://www.theserverlabs.com/brochures/RIA_Frameworks-TSL-evaluation.pdf.

[34] J. Stallons, A. Sborten and V. Genove, Getting Started with Flex4, 1st ed., M. Treseler, Ed., O'Reilly Media, Inc.,

2010.

[35] P. Brown, Silverlight 4 in action, Silverlight 4, MVVM, And WCF RIA Services, 1st ed., J. Bleiel, Ed., Manning

Publication Co., 2010.

[36] M. Krishnan e P. Beadl, Silverlight 4 for dummies, 1st ed., Indianapolis, Indiana: Wiley Publishing, Inc., 2010.

[37] L. PremKumar e P. Mohan, Beginning JavaFX Platform: A hands-on tutorial for learning and using JavaFX™, 1st ed.,

S. Anglin, Ed., Apress, 2010.

[38] W3C, 04 August 2011. [Online]. Available: http://www.w3.org/standards/webdesign/htmlcss.

[39] P. Lubbers, B. Albers e F. Salim, Pro HTML5 programming: Powerful APIs for Richer Internet Application

Development, C. Andres, Ed., Apress, 2010.

[40] L. D. Paulson, “Building rich web applications with Ajax,” Computer, vol. 38, n.º 10, pp. 14-17, October 2005.

[41] R. Nixon, Learning PHP, MySQL, and JavaScript, 1st ed., A. Oram, Ed., O'Reilly Media Inc., 2009.

[42] Yahoo!, August 2011. [Online]. Available: http://developer.yahoo.com/maps/.

[43] Google, August 2011. [Online]. Available: http://code.google.com/intl/pt-PT/apis/maps/.

[44] Microsoft, August 2011. [Online]. Available: http://msdn.microsoft.com/en-us/library/dd877180.aspx.

[45] S. Morris, JavaFX in Action, T. Cirtin, Ed., Manning Publications Co., 2010.

[46] P. Ballard e M. Moncur, Sams TeachYourself Ajax, JavaScript and PHP all in one, 1st ed., M. Taub, Ed., Indianapolis,

Indiana: Sams Publishing, 2008.

[47] A. Trachtenberg, “PHP WebServices without SOAP,” October 2003. [Online]. Available:

http://onlamp.com/pub/a/php/2003/10/30/amazon_rest.html.

[48] B. Martin, M. Brown, A. Paller e D. Kirby, June 2011. [Online]. Available:

http://cwe.mitre.org/top25/archive/2011/2011_cwe_sans_top25.pdf.

[49] E. Merlo, D. Letarte e G. Antoniol, “SQL-Injection Security Evolution Analysis in PHP,” em WSE 2007: Proceedings of


124

the 9th IEEE International Symposium on Web Site Evolution , Paris, France, 2007.

[50] E. Merlo, D. Letarte e G. Antoniol, “Automated Protection of PHP Applications Against SQL- injection,” em CSMR

'07: Proceedings of the 11th European Conference on Software Maintenance and Reengineering , Amsterdam, the

Netherlands, 2007.

[51] P. DuBois, MySQL (Developer's Library), 4th ed., Pearson Education, Inc., 2009.

[52] D. Rosenberg e M. Stephens, Use Case Driven Object Modeling with UML: Theory and Practice, New York, Inc., 233

Spring Street, 6th Floor, USA: Apress, 2007.

[53] K. Hamilton e R. Miles, Learning UML 2.0, 1st ed., B. McLaughlin e M. T. O'Brien, Edits., 1005 Gravenstein Highway

North, Sebastopol, CA 95472: O'Reilly Media, Inc, April 2006.

[54] C. Moock, Essential ActionScript 3.0, 1st ed., S. Weiss, Ed., 1005 Gravenstein Highway North, Sebastopol, CA 95472:

O'Reilly Media Inc., 2007.

[55] Google, September 2011. [Online]. Available: http://code.google.com/intl/pt-

PT/apis/maps/documentation/flash/basics.html.

[56] Adobe Systems Incorporated, Using Adobe Flex 4, 345 Park Avenue, San Jose, California 95110, 2010.

125

Anexo A. Documento WSDL





<definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://TimeServer/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://TimeServer/" name="SIBService"> <types/> <message name="getTimeAsString"/> <message name="getTimeAsStringResponse"> <part name="return" type="xsd:string"/> </message> <message name="getTimeAsElapsed"/> <message name="getTimeAsElapsedResponse"> <part name="return" type="xsd:long"/> </message> <portType name="SEI"> <operation name="getTimeAsString"> <input message="tns:getTimeAsString"/> <output message="tns:getTimeAsStringResponse"/> </operation> <operation name="getTimeAsElapsed"> <input message="tns:getTimeAsElapsed"/> <output message="tns:getTimeAsElapsedResponse"/> </operation> </portType> <binding name="SIBPortBinding" type="tns:SEI"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/> <operation name="getTimeAsString"> <soap:operation soapAction=""/> <input> <soap:body use="literal" namespace="http://TimeServer/"/> </input> <output> <soap:body use="literal" namespace="http://TimeServer/"/> </output> </operation> <operation name="getTimeAsElapsed"> <soap:operation soapAction=""/> <input> <soap:body use="literal" namespace="http://TimeServer/"/> </input> <output> <soap:body use="literal" namespace="http://TimeServer/"/> </output> </operation> </binding> <service name="SIBService"> <port name="SIBPort" binding="tns:SIBPortBinding"> <soap:address location="http://localhost:9876/JavaTimeSoapServer"/> </port> </service></definitions>


127

Anexo B. Triggers

--Trigger for Create PlatformCREATE TRIGGER `create_update` AFTER INSERT ON `platforms` FOR EACH ROW INSERT INTO platforms_update(id,name,location,latitude,longitude,platgroup,status,visible,task) VALUES(NEW.id,NEW.name,NEW.location,NEW.latitude,NEW.longitude,NEW.platgroup, NEW.status, NEW.visible, 'create')

--Trigger for Update PlatformCREATE TRIGGER `update_platform` AFTER UPDATE ON `platforms` FOR EACH ROW INSERT INTO platforms_update(id,name,location,latitude,longitude,platgroup,status,visible,task) VALUES(NEW.id,NEW.name,NEW.location,NEW.latitude,NEW.longitude,NEW.platgroup, NEW.status,NEW.visible, 'update') ON DUPLICATE KEY UPDATE id = NEW.id, name = NEW.name, location = NEW.location, latitude = NEW.latitude, longitude = NEW.longitude, platgroup = NEW.platgroup, status = NEW.status, visible = NEW.visible, task = 'update'

--Trigger for Delete PlatformCREATE TRIGGER `delete_update` AFTER DELETE ON `Platforms` FOR EACH ROWINSERT INTO platforms_update(id,name,location,latitude,longitude,platgroup,status,visible,task) VALUES(OLD.id, OLD.name, OLD.location, OLD.latitude, OLD.longitude, OLD.platgroup, OLD.status, OLD.visible, 'delete') ON DUPLICATE KEY UPDATE id = OLD.id, name = OLD.name, location = OLD.location, latitude = OLD.latitude, longitude = OLD.longitude,

platgroup = OLD.platgroup, status = OLD.status, visible = OLD.visible, task = 'delete'

--Trigger for Update SensorCREATE TRIGGER `sensor_update` AFTER UPDATE ON `sensors` FOR EACH ROW INSERT INTO `sensors_update`(`plat_id`,`sensor_name`,`state`, `value`, `minThreshold`, `maxThreshold`, `criticalMaxThreshold`, `criticalMinThreshold`) VALUES(NEW.plat_id,NEW.sensor_name,NEW.state,NEW.value,NEW.minThreshold,NEW.maxThreshold,NEW.criticalMaxThreshold, NEW.criticalMinThreshold) ON DUPLICATE KEY UPDATE plat_id = NEW.plat_id, sensor_name = NEW.sensor_name, state = NEW.state, value = NEW.value, minThreshold = NEW.minThreshold,

maxThreshold = NEW.maxThreshold, criticalMaxThreshold = NEW.criticalMaxThreshold, criticalMinThreshold = NEW.criticalMinThreshold

--Trigger for Update Sensor HistoryCREATE TRIGGER `keep_sensor_history` AFTER INSERT ON `sensors_update` FOR EACH ROW INSERT INTO sensor_history(plat_id, sensor_name, value, date)

VALUES(NEW.plat_id, NEW.sensor_name,NEW.value,NOW())


129

Anexo C. sanitizeStringAndSQL

<?php //Processar a informação introduzida pelos utilizadores, para aumentar a segurança; function sanitizeString($str) { $str = stripslashes($str); //Remover barras; $str = htmlentities($str); //Remover partes que podem ser intrepertadas como HTML; $str = strip_tags($str); //Remove tags HTML; return $str; } //Evitar injecção na BD function sanitizeStringAndSQL($str) { $str = mysql_real_escape_string($str); //Escapar caracteres especiais $str = sanitizeString($str); //Chama a sanitizeString; return $str; }?>


130

Anexo D. Flex GUI

FIG. A – ESTADO GIANTMAP QUE APRESENTA APENAS A VISTA DO MAPA

FIG. B - ESTADO PLATDETAILS COM A PLATAFORMA DO PORTO SELECIONADA E RESPECTIVOS SENSORES NA TABELA INFERIOR. A VISTA

DE MAPA APRESENTA TODAS AS PLATAFORMAS DO MESMO GRUPO


131

FIG. C – CALENDÁRIO QUE PERMITE AO UTILIZADOR ESCOLHER AS DATAS PARA A VISUALIZAÇÃO DO HISTÓRICO


133

Anexo E. Inicialização do Mapa

//Evento chamado na preInicialização do mapa, ou seja, antes de o mapa estar desenhado;//É mais eficiente. O único método suportado é o setInitOptions;private function onMapPreinitialize(event:Event):void{

// Debug - trace("Map preinitialization on: " + getTimer() + "ms");var myMapOptions:MapOptions = new MapOptions();myMapOptions.mapType = MapType.NORMAL_MAP_TYPE //Inicializar como um tipo de mapa normal;myMapOptions.zoom = 10; //Zoom inicial 0-19 (19 ￩ o zoom máximo) (20 para vista satelite)myMapOptions.center = new LatLng(38.6457,-9.32996); //Definir o centro inicial do mapa;myMapOptions.scrollWheelZoom = true;map.setInitOptions(myMapOptions); //Inicializar com as opções escolhidas;

}

//Evento disparado quando o mapa está pronto a ser utilizado;private function onMapReady(event:MapEvent):void{

// debug - trace("Map ready on: " + getTimer() + "ms");// debug - map.addEventListener(MapMouseEvent.CLICK, onMapClick); //Adiciona um event Listener para quando houver um click;map.addEventListener(MapMouseEvent.DOUBLE_CLICK, onMapDClick); //Adiciona um event listener para quando houver um double-

click;map.addControl(new PositionControl()); //Adiciona controlos de posição;map.addControl(new ZoomControl()); //Adiciona controlos para o zoom;//Adicionar as plataformas no mapa;placeMarkers();// debug - trace("Markers placed on: " + getTimer() + "ms");

}


135

Anexo F. placeMarkers

private function placeMarkers():void{

var platCount:Number = GetPlatformsResult.lastResult.length;var markerOptions:MarkerOptions = new MarkerOptions();

for(var Count:Number = 0; Count < platCount; Count++){

//Conteúdo que vai para as InfoWindowshtml = "<b>Name:</b> " + GetPlatformsResult.lastResult[Count].name + "<br/>" +

"<b>Location:</b> " + GetPlatformsResult.lastResult[Count].location + "<br/>" +"<b>Status:</b> " + GetPlatformsResult.lastResult[Count].status + "<br/>" +"<b>PlatGroup:</b> " + GetPlatformsResult.lastResult[count].platgroup + "<br/>" +"<b>Latitude:</b> " + GetPlatformsResult.lastResult[count].latitude + "<br/>" +"<b>Longitude:</b> " + GetPlatformsResult.lastResult[count].longitude + "<br/>";

//Definir o icon de acordo com o estado global da plataformaif(GetPlatformsResult.lastResult[Count].status == "Good")

markerOptions.icon = markerFactory.DrawGoodStateMarker();else if(GetPlatformsResult.lastResult[Count].status == "Bad")

markerOptions.icon = markerFactory.DrawBadStateMarker();else if(GetPlatformsResult.lastResult[Count].status == "Acceptable")

markerOptions.icon = markerFactory.DrawAcceptableStateMarker();else

markerOptions.icon = markerFactory.DrawBatteryStateMarker();

var platMarker:Marker = new Marker(new LatLng(Number(GetPlatformsResult.lastResult[Count].latitude), Number(GetPlatformsResult.lastResult[Count].longitude)), markerOptions);

BindWindow(platMarker, html);map.addOverlay(platMarker);

}}


137

Anexo G. showPlatGroup

protected function showPlatGroup():void{

var bounds:LatLngBounds;var extendLatLng:LatLng;map.panTo(new LatLng(Number(platform.latitude),Number(platform.longitude)));map.setZoom(5); //Aumenta o zoombounds = map.getLatLngBounds(); //Bounds actuais//Calcula viewport do grupofor(var i:int = 0; i < platformsCount; i++){

//Se for do mesmo grupoif(platform.platgroup == GetPlatformsResult.lastResult[i].platgroup){

//Retira a lat/lngextendLatLng = new LatLng(Number(GetPlatformsResult.lastResult[i].latitude),

Number(GetPlatformsResult.lastResult[i].longitude));//estende os boundsbounds.extend(extendLatLng);

}}map.setCenter(bounds.getCenter());map.setZoom(map.getBoundsZoomLevel(bounds));}


139

Anexo H. dateParseFunction

private function myParseFunction(SQLDate:String):Date{//Separar o espaço que existe entre o y-m-d e a horavar split:Array = SQLDate.split(' ');//No [0] está a data e no [1] está a horavar splitDate:String = split[0];var splitTime:String = split[1];//Separar a datavar splitDateArray:Array = splitDate.split('-');//Separar a horavar splitTimeArray:Array = splitTime.split(':');//Criar a data e hora. O mês é -1, porque no Flex os meses começam a contar em 0var newDate:Date = new Date(splitDateArray[0],splitDateArray[1]-1,splitDateArray[2],

splitTimeArray[0],splitTimeArray[1],splitTimeArray[2]);

return newDate;}


141

Anexo I. getSensorSelectedHistoric

private function getSensorSelectedHistoric():void{if(xAxisList.selectedItem == "Today"){

//Pede o historico de hoje, do sensor selecionadoGetSensorMonthHistoricResult.token = platService.GetSensorMonthHistoric(

PlatData.selectedItem.id, sensordatagrid.selectedItem.sensor_name, getDay());dateAxis.dataUnits = "hours";//Definir os valores que o slider pode levar 00 a 24minSlider.minimum = 0;minSlider.maximum = 24;minSlider.value = 0;maxSlider.minimum = 0;maxSlider.maximum = 24;maxSlider.value = 24;

}else if(xAxisList.selectedItem == "Month" ){//Pede o historico do mês, do sensor selecionadoGetSensorMonthHistoricResult.token = platService.GetSensorMonthHistoric(

PlatData.selectedItem.id, sensordatagrid.selectedItem.sensor_name, getMonth());dateAxis.dataUnits = "weeks";//Definir os valores que o slider pode levar 01 a 31minSlider.minimum = 1;minSlider.maximum = 31;minSlider.value = 1;maxSlider.minimum = 1;maxSlider.maximum = 31;maxSlider.value = 31;

}else if(xAxisList.selectedItem == "Year"){//Pede o historico do ano, do sensor selecionadoGetSensorMonthHistoricResult.token = platService.GetSensorMonthHistoric(

PlatData.selectedItem.id, sensordatagrid.selectedItem.sensor_name, getYear());dateAxis.dataUnits = "months";//Definir os valores que o slider pode levar 0 a 11//No Flex 0 corresponde a JaneirominSlider.minimum = 0;minSlider.maximum = 11;minSlider.value = 0;maxSlider.minimum = 0;maxSlider.maximum = 11;maxSlider.value = 11;

}else{//Pede o historico desde que existe um registo do sensorGetSensorMonthHistoricResult.token = platService.GetSensorMonthHistoric(

PlatData.selectedItem.id, sensordatagrid.selectedItem.sensor_name);dateAxis.dataUnits = "years";//Definir os valores que o slider pode levar 2011 ao ano actualminSlider.minimum = 2011;minSlider.maximum = newDateAll.fullYear;minSlider.value = 2011;maxSlider.minimum = 2011;maxSlider.maximum = newDateAll.fullYear;maxSlider.value = newDateAll.fullYear;

}}


143

Anexo J. GetUpdatedPlatformsResult_resultHandler

protected function GetUpdatedPlatformsResult_resultHandler(event:ResultEvent):void{

if(currentState == "searchState"){

for(var CountsearchedUpdated:Number = 0; countSearchedUpdated < platformsUpdateCount; CountsearchedUpdated++){if(GetPlatByNameResult.lastResult.id == GetUpdatedPlatformsResult.lastResult[CountsearchedUpdated].id){//Actualiza-se os atributos das plataformasGetPlatByNameResult.lastResult.status = GetUpdatedPlatformsResult.lastResult[CountsearchedUpdated].status;GetPlatByNameResult.lastResult.platgroup=GetUpdatedPlatformsResult.lastResult[CountsearchedUpdated].platgroup;

[...]}

}}//Percorremos as todas as plataformas actualizadas, para actualizar os dados for(var CountUpdated:Number = 0; countUpdated < platformsUpdateCount; CountUpdated++){

if((GetUpdatedPlatformsResult.lastResult[CountUpdated].task == "create") || (GetUpdatedPlatformsResult.lastResult[CountUpdated].task == "delete")){

GetPlatformsResult.token = platService.GetPlatforms();//Como pede todas as plataformas, já não precisa de prosseguir. (+ eficiente)break;

}else{

for(var CountPlats:Number = 0; countPlats < platformsCount; CountPlats++){if(GetPlatformsResult.lastResult[CountPlats].id == GetUpdatedPlatformsResult.lastResult[CountUpdated].id){//Actualiza-se os atributos das plataformas. Igual ao que se fez acima.GetPlatformsResult.lastResult[CountPlats].name = GetUpdatedPlatformsResult.lastResult[CountUpdated].name;[...]//Ao encontrar não precisa de procurar mais, pois o ID é único, logo termina-se o ciclo (+ eficiente)break;}

}}

}//Actualizar os sensoresGetUpdatedPlatSensorsResult.token = platService.GetUpdatedPlatSensors();

}


145

Anexo K. checkPlatStatus

protected function checkPlatStatus():void{for(var platCount:Number = 0; platCount < platformsCount; platCount++){

red = 0;yellow = 0;energyBreakDown = "";//Percorre os sensores. Verificar quantos sensores estão fora dos thresholdsfor(var i:Number = 0; i < sensorsCount; i++){

if(GetPlatSensorsResult.lastResult[i].plat_id == GetPlatformsResult.lastResult[platCount].id){//Se o id corresponder//Verificar se existe falha de energiaif(GetPlatSensorsResult.lastResult[i].sensor_name == "Energy Break Down"){

energyBreakDown = GetPlatSensorsResult.lastResult[i].value;}//Verifica se está fora do threshold critico, red++if(parseFloat(GetPlatSensorsResult.lastResult[i].value) > parseFloat(GetPlatSensorsResult.lastResult[i].criticalMaxThreshold) || parseFloat(GetPlatSensorsResult.lastResult[i].value) < parseFloat(GetPlatSensorsResult.lastResult[i].criticalMinThreshold)){

red++;}//verifica se está entre os thresholds normais senão yellow++else if(parseFloat(GetPlatSensorsResult.lastResult[i].value) > parseFloat(GetPlatSensorsResult.lastResult[i].maxThreshold)

|| parseFloat(GetPlatSensorsResult.lastResult[i].value) < parseFloat(GetPlatSensorsResult.lastResult[i].minThreshold)){yellow++;

}}

}if(energyBreakDown == "True"){

updatePlatStatus("Battery", GetPlatformsResult.lastResult[platCount].id, platCount);}else if(red >= 5){

//5 Red a plataforma fica em estado criticoupdatePlatStatus("Bad", GetPlatformsResult.lastResult[platCount].id, platCount);

}else if(red != 0 || yellow >= 5){

updatePlatStatus("Acceptable", GetPlatformsResult.lastResult[platCount].id, platCount);//Senão é porque está tudo em ordem

}else

updatePlatStatus("Good", GetPlatformsResult.lastResult[platCount].id, platCount);}}


146

Anexo L. updatePlatStatus

private function updatePlatStatus(platState:String, platId:int, countPlats:int):void{

if(GetPlatformsResult.lastResult[countPlats].status != platState){//localmente:GetPlatformsResult.lastResult[countPlats].status = platState;//Na BD:platService.updatePlatStatus(platId,platState);

}}


147

Anexo M. calcRowColor

private function calcRowColor(item:Object, rowIndex:int, dataIndex:int, color:uint):uint{//Para o caso especifico da falha de energia:if(item.sensor_name == "Energy Break Down"){

if(item.value == "True")return Color.RED;

}//Se o valor estiver acima do threshold critico, pinta a vermelhoif(parseFloat(item.value) > parseFloat(item.criticalMaxThreshold) || parseFloat(item.value) < parseFloat(item.criticalMinThreshold))

return Color.RED;//Se sair dentro dos thresholds, pinta amarelo

else if(parseFloat(item.value) > parseFloat(item.maxThreshold) || parseFloat(item.value) < parseFloat(item.minThreshold))return Color.YELLOW;

elsereturn color;

}

Esta função recebe quatro parâmetros, entre os quais, o array item, que inclui os atributos dos sensores, dados

pelo dataProvider. Assim, é fácil determinar a cor de fundo da linha, através da verificação do valor actual de um

sensor. Começa-se por verificar o valor do sensor “Energy Break Down”, e retornar a cor vermelha se o valor for true.

Depois, para os outros sensores compara-se o valor com os thresholds, e retorna-se a cor apropriada. Esta cor é depois

usada pelo método drawRowBackground() que desenha cada linha da tabela, incluindo a cor de fundo.

Emanuel Fernando Passos Ramos da Mota...

Documents

Transcript of Emanuel Fernando Passos Ramos da Mota...