universidade federal do paraná fileuniversidade federal do paraná douglas tamião rodrigues serino...

Universidade Federal do Paraná

Douglas Tamião Rodrigues Serino

Phyllipy Celarius das Chagas

Web ServicesUma alternativa para problemas de alto custo computacional em dispositivos

móveis

Curitiba - PR

2013

Universidade Federal do Paraná

Douglas Tamião Rodrigues Serino

Phyllipy Celarius das Chagas

Web ServicesUma alternativa para problemas de alto custo computacional em dispositivos

móveis

Monografia apresentada junto ao curso de Ciência

da Computação, do Departamento de Informática,

do Setor de Ciências Exatas, como requisito parcial

para a obtenção do título de Bacharel.

Orientador: Prof. Dr. Bruno Müller Junior

Curitiba - PR

2013

Aos nossos pais e a todos que direta ou indiretamente

contribuiram para essa conquista.

Agradecimentos

• A Deus

• Ao nosso esforço e dedicação nos valeram muito.

• Aos professores pela paciência e dedicação

iv

Resumo

O cenário de dispositivos móveis mudou significativamente nos últimos anos. Hoje

temos uma grande variedade de smartphones e tablets com sistemas operacionais

avançados e um crescente poder computacional. Para acompanhar e possibilitar esse

crescimento, torna-se importante o uso de ferramentas para integrar os dispositivos

móveis com outros sistemas já existentes que, por vezes, são demasiadamente com-

plexos para serem executados diretamente num celular ou tablet. Nesse cenário o

uso dos chamados Web Services tem sido de grande importância, aumentando ainda

mais o poder dessa plataforma.

Palavras-chave: Android, Dispositivos móveis, Web Services.

v

Abstract

The scenario of the mobile devices has changed significantly in the past years.

Nowadays we have a huge variety of smartphones and tablets along with advanced

operating systems which has an increasing computational power. In the case of mo-

nitor and facilitate this evolution, becomes important the use of web tools to integrate

the mobile devices with systems that already exists and sometimes are so complex,

so the execution on smartphones or tablets is not interesting. In this scenario the use

of Web Services (the way the concept is called) have been very important, increasing

even more the power of these platforms.

Keywords: Android, Mobile devices, Web Services.

vi

Sumário

Agradecimentos iv

Resumo v

Abstract vi

Sumário vii

1 Introdução 1

2 Revisão bibliográfica 3

2.1 O protocolo RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Funcionamento do RPC . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 Evoluções do RPC . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.4 Sistemas Operacionais Móveis . . . . . . . . . . . . . . . . . . . 8

2.1.5 Objetivo do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Web Services e Android 12

3.1 O Sistema Operacional Android . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Estrutura de um aplicativo Android . . . . . . . . . . . . . . . . . 13

3.2 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

vii

3.2.1 O que são Web Services . . . . . . . . . . . . . . . . . . . . . . 15

3.2.2 Como funcionam os Web Services . . . . . . . . . . . . . . . . . 16

3.2.3 Protocolos e padrões utilizados . . . . . . . . . . . . . . . . . . . 17

4 Implementação de aplicativos Android 24

4.1 Bibliotecas Essenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.1 API Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.2 KSOAP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Criando um aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 Interface do usuário . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.2 Estrutura do aplicativo . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Conclusão 34

5.1 Testes realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

A Histórico de versões do Android 38

B Extensible Markup Language 39

C WSDL do trabalho prático 41

Capıtulo 1Introdução

O uso de mecanismos para mediar a comunicação entre diferentes sistemas tem

sido objeto de estudo há vários anos. Diversos mecanismos foram criados e apri-

morados com o passar dos anos. Um dos mecanismos mais utilizados hoje são os

chamados Web Services, que permite a integração entre sistemas distintos (podendo

estes serem escritos em diferentes linguagens de programação e até mesmo rodar

em diferentes sistemas operacionais) através de procedimentos executados pela In-

ternet com o uso de protocolos conhecidos e padrões pré-estabelecidos para troca de

mensagens.

Essa natureza de interoperabilidade, característica dos Web Services, permite que

os mesmos sejam utilizados a partir de qualquer plataforma, possibilitando assim o

seu uso para integrar sistemas já existentes com novos sistemas desenvolvidos para

dispositivos móveis com sistemas operacionais próprios como o Android e iOS. Esses

novos dispositivos têm como importante característica a possibilidade de acessar a

Internet e utilizar os mesmos protocolos criados para computadores tradicionais. Com

isso, torna-se possível utilizar-se dos Web Services para incrementar o já crescente

poder atribuido a tais dispositivos.

Um dos sistemas operacionais que mais tem se destacado no mercado é o Android

da Google. O sistema operacional Android foi baseado em um kernel Linux e de código

aberto. Diferentemente de outros sistemas operacionais concorrentes (como iOS da

Apple) seus aplicativos podem ser escritos em Java, permitindo o uso de diversas

bibliotecas já existentes e com funcionalidades adaptadas à plataforma móvel. Por

ter o desenvolvimento facilitado, optamos a plataforma Android para a criação de um

aplicativo capaz de consumir Web Services.

1

2

No decorrer desse trabalho apresentaremos o que são e como funcionam os Web

Services e as tecnologias que serviram como base para a sua criação. Apresentare-

mos também em mais detalhes o sistema operacional Android e mostraremos como

desenvolver um aplicativo simples capaz de buscar e consumir um Web Service, apre-

sentando, por fim, uma avaliação comparativa dos resultados obtidos em relação à

execução de procedimentos no próprio dispositivo e através de Web Services.

Capıtulo 2Revisão bibliográfica

Com a grande variedade de tecnologias existentes e o constante aumento no nú-

mero de aplicações espalhadas pela rede, viu-se a necessidade de criar mecanismos

para facilitar a interação entre essas diferentes aplicações e as diversas tecnologias

disponíveis. Para esse fim, foram criados diversos protocolos capazes de possibilitar

essa integração. Dentre eles destacamos o Remote Procedure Call (RPC), um pro-

tocolo capaz de executar um procedimento localizado em um ponto distinto de uma

determinada rede, permitindo assim que uma máquina possa executar procedimentos

implementados em outras. O RPC serviu como base para a criação de vários outros

protocolos que também visavam possibilitar, de maneira facilitada, a integração entre

aplicações localizadas em máquinas diferentes.

Este capítulo faz uma revisão histórica e apresenta os conceitos utilizados ao longo

do texto. Na seção 2.1 falaremos sobre o protocolo RPC, na seção 2.2 falaremos

brevemente sobre Web Services — uma forma de RPC acessível pela Internet — e,

por fim, na seção 2.3 falaremos sobre sistemas operacionais móveis e de que forma

podem ser usados para executar Web Services. Por fim, a seção 2.4 detalha o objetivo

do trabalho sob o prisma destes conceitos.

2.1 O protocolo RPC

O RPC foi introduzido no início dos anos 80 por Birell e Nelson [6]. Trata-se de um

protocolo que permite uma execução transparente de procedimentos localizados em

diferentes locais numa determinada rede.

Com o RPC, as chamadas a procedimentos remotos e locais são indistinguíveis

3

2.1. O protocolo RPC 4

do ponto de vista do programador. Dessa forma, quando uma máquina A deseja exe-

cutar um procedimento localizado em uma máquina B, ela faz a chamada como se o

procedimento estivesse, de fato, localizado na mesma máquina. O RPC encarrega-se

de encontrar a máquina onde o procedimento está efetivamente implementado, trans-

portar os parâmetros de entrada, realizar a chamada do procedimento propriamente

dito na máquina B e, por fim, transportar de volta à maquina A, os dados de saída

do procedimento. Esse tipo de comunicação é tradicionalmente chamada de cliente-

servidor, onde a máquina que faz a chamada é o cliente e a máquina que executa o

procedimento é o servidor. Dessa forma, procedimentos remotos podem ser imple-

mentados de maneira simples e transparente, sem a necessidade de tratar problemas

de sincronização, segurança, etc.

Na seção 2.1.1 mostraremos mais detalhadamente como se dá o funcionamento

do protocolo RPC e na seção 2.1.2 apresentaremos algumas das tecnologias desen-

volvidas com base no RPC.

2.1.1 Funcionamento do RPC

A ideia do RPC é facilitar a chamada a procedimentos remotos de forma que pos-

sam ser tratados como se fossem procedimentos tradicionais (locais).

Em sua forma mais simples, uma aplicação com RPC é um programa do tipo

cliente-servidor, onde, no cliente, existe um modulo de biblioteca chamado client-stub

que contém a assinatura do procedimento, sendo, também, responsável por localizar

o procedimento, empacotar e transportar os dados necessários para sua execução.

O programa servidor por sua vez, é onde o procedimento será realmente implemen-

tado e executado. Ele deverá possuir um módulo chamado server-stub, que será

responsável por receber a solicitação vinda do client-stub.

Figura 2.1: Modelo de comunicação cliente-servidor com RPC[6].


A figura 2.1 mostra os passos tomados da execução de uma chamada a procedi-

mento remoto com RPC. Quando o processo cliente faz a chamada ao procedimento

o client-stub associado a este procedimento empacota os parâmetros informados.

Como o processo cliente e o client-stub estão localizados no mesmo espaço de ende-

reçamento, a passagem de parâmetros é feita da mesma forma que um procedimento

local. Uma vez empacotados, os dados são enviados até o server-stub associado ao

procedimento, bloqueando o processamento do cliente até a chegada da resposta do

servidor. O server-stub, por sua vez, encarrega-se de desempacotar os dados, exe-

cutar o procedimento e enviar como resposta os dados de saída do mesmo. Por fim,

após receber a resposta do servidor, o cliente é desbloqueado.

Com o RPC, o programa cliente faz a chamada do procedimento exatamente da

mesma forma como em um procedimento local. Cabe então aos stubs realizar o tra-

balho de encontrar e executar o procedimento chamado.

O RPC serviu como base para a construção de diversos protocolos e mecanismos

mais evoluídos para acesso a meios distribuídos. Na próxima seção falaremos sobre

alguns desses mecanismos e de que forma seus conceitos foram aplicados na criação

de Web Services.

2.1.2 Evoluções do RPC

Com base no RPC, outros protocolos foram criados para resolver o problema da

chamada a sub-rotinas remotamente. Dentre esses novos protocolos, destacamos o

Common Object Request Broker Architecture (CORBA) e o Distributed Component

Object Model (DCOM).

O CORBA é uma arquitetura criada pelo Object Management Group (OMG) para

simplificar a troca de dados entre sistemas heterogêneos e orientados a objeto [6].

Embora a CORBA pareça ser uma excelente solução para sistemas heterogêneos,

ela não é tão simples de ser utilizada. As primeiras versões da especificação CORBA

deixaram muitas áreas abertas à interpretação dos fornecedores, dessa forma, im-

plementações de muitos fornecedores começaram a conflitar umas com as outras,

dificultando a interação entre elas[19].

O DCOM, criado pela Microsoft, segue o mesmo princípio do CORBA, porém apre-

senta uma grave limitaçao: só pode ser executado em sistemas Windows, tornando-o

inadequado à grande maioria das aplicações [19].


No final dos anos 80 foi proposta a chamada World Wide Web [2], um sistema ca-

paz de interligar documentos através da Internet. Esses documentos eram interligados

através de hyperlinks e identificados por uma Uniform Resource Identifier (URI), um

sistema de identificação global e único de recursos na Internet, e localizados através

do Uniform Resource Locator (URL) que representa o endereço onde o documento

está localizado. Uma URL é uma string composta pelo nome do protocolo utilizado,

nome da máquina onde o documento esta localizado, caminho do documento na má-

quina e nome do documento (protocolo://maquina/caminho/recurso). Os protocolos

mais utilizados na web são o HyperText Transfer Protocol (HTTP), HyperText Transfer

Protocol Secure(HTTPS) e File Transfer Protocol (FTP). Numa tentativa de criar um

padrão de RPC para a Web, o W3C definiu o modelo de Web Services, que funcio-

nam com base em trocas de mensagens no formato XML através de um conjunto de

protocolos pré-definidos.

Na proxima seção falaremos sobre Web Services e apresentaremos os protocolos

utilizados nesse modelo.

2.1.3 Web Services

Web Service é uma aplicação de software identificada por uma URI que pode

ser acessada remotamente por meio de protocolos como o HTTP, e tem por objetivo

facilitar a integração entre sistemas [19].

Para tornar possível a integração entre diversas aplicações e plataformas, os Web

Services adotam determinados padrões de troca de mensagens e formatos dos paco-

tes:

• Web Services Description Language (WSDL) - Trata-se de uma Interface

Description Language (IDL) e tem por objetivo fornecer uma descrição padro-

nizada do serviço, informando a assinatura do serviço, bem como os dados de

entrada e saída necessários.

• Universal Descriptor, Discovery and Integration (UDDI) - O UDDI é um repo-

sitório das assinaturas de procedimentos que associa a assinatura com o local

onde o procedimento pode ser encontrado. Os UDDI geralmente podem ser

públicos, privados ou semi privados. Quando público qualquer máquina pode

examinar as informações publicadas no registro. No caso de privado, ele fica

protegido e apenas os usuários internos podem fazer uso. E no caso de semi


privado além dos usuários internos, fica também disponível aos parceiros de

negócio.

• Simple Object Access Protocol (SOAP) - protocolo criado e padronizado pelo

W3C, ele é utilizado para a definição do formato das mensagens, de forma que

possam ser utilizadas a partir de qualquer sistema.

• Extensible Markup Language (XML) - linguagem utilizada pelo SOAP, WSDL

e UDDI. Ela possui a sua gramática descrita em esquemas, ou seja, diz quais

são as tags permitidas e as relações entre elementos definidos por elas. Por

ser amplamente utilizada nos Web Services como linguagem principal. Mais

detalhes sobre a estrutura do XML no Apêndice B.

O funcionamento dos Web Services é muito semelhante ao do RPC. Temos um

cliente que faz a requisição do serviço, um servidor onde o serviço está hospedado e

um repositório que contém informações sobre localização e descrição dos Web Ser-

vices disponíveis. A figura 2.2 mostra esses três componentes e as interações entre

eles:

• O servidor publica a assinatura dos seus procedimentos no repositório.

• O cliente busca, no repositório, a localização do procedimento que deseja exe-

cutar.

• O cliente conecta-se ao servidor e executa, através de protocolos padrões, o

procedimento desejado.


Figura 2.2: Modelo de relacionamento entre as entidades que compõem um Web

Service.

O uso de métodos padrões para localização e execução permite que os Web Ser-

vices possam ser utilizados independentemente da plataforma em que são implemen-

tados, podendo ser executados até mesmo por programas escritos em uma linguagem

ou numa plataforma diferente.

Essa facilidade de integração permitiu o acesso à partir de uma grande variedade

de sistemas e dispositivos. Atualmente, com a constante e acelerada evolução dos

dispositivos móveis (tais como smartphones, tablets, etc), os Web Services passaram

a ser utilizados também por essas plataformas.

Na seção seguinte iremos apresentar uma importante plataforma que pode ser

utilizada para consumir web services: são os sistemas operacionais para dispositivos

móveis (smartphones, tablets), mais especificamente o sistema Android da Google.

2.1.4 Sistemas Operacionais Móveis

O cenário dos celulares mudou radicalmente com o passar dos anos, há pouco

mais de uma década era difícil imaginar que celulares fossem ser mais úteis que ape-

nas fazer ligações e enviar mensagens − além de servir como uma calculadora básica


− tampouco pensar que seriam mais poderosos que alguns computadores.

Com o passar do tempo foram surgindo os smartphones, cujo público alvo eram

os profissionais que têm a necessidade de ler e enviar e-mails, acessar informações

via internet, entre outras atividades, do local onde estivessem.

Com a constante evolução das tecnologias, o uso de smartphones tornou-se bas-

tante comum, e com a popularidade desses dispositivos surgiram sistemas operacio-

nais destinados exclusivamente a esse tipo de aparelhos. Entre os principais sistemas

operacionais criados para esse fim, destacam-se o iOS da Apple, Windows Phone da

Microsoft e o Android da Google, entre outros.

Na próxima seção apresentaremos o sistema operacional Android, uma plataforma

que tem crescido de forma bastante acelerada e hoje é uma das plataformas mais

utilizada em dispositivos móveis tais como smartphones e tablets [3].

2.1.4.1 Android

O Android é um sistema operacional para dispositivos móveis (tais como smartpho-

nes e tablets). Foi criado pela Android Inc. e atualmente é desenvolvido e mantido pela

Google Inc.[10] no projeto Android Open Source Project (AOSP)[17].

O Android é uma das plataformas móveis mais vendidas em todo mundo e conta

com uma grande comunidade de desenvolvedores que criam novas aplicações ou

complementos que estendem as funcionalidades do sistema. Para auxiliar e incentivar

o desenvolvimento, a Google disponibiliza um Software Development Kit (SDK), que

conta com uma série de funções já implementadas, facilitando, assim, o trabalho de

desenvolvimento de aplicações.

O sistema baseia-se em numa pilha de softwares de código livre que vão desde

um núcleo, baseado numa versão modificada de um kernel Linux, atá uma máquina

virtual responsável por executar aplicativos [Fig2.3].

A base da pilha consiste de uma versão do Kernel Linux 2.6 modificada para aten-

der às necessidades de gerenciamento de energia, memória e drivers.

Na camada seguinte, encontramos um conjunto bibliotecas Java que permitem ao

dispositivo lidar com as mais diversas variedades de dados. Esta camada contem um

módulo chamado Android Runtime, no qual roda uma máquina virtual chamada Dalvik

Virtual Machine (DVM) onde são executados todos os aplicativos.


No terceiro nível temos a camada do framework de aplicações. Aqui se encontram

os programas responsáveis pelo gerenciamento das funções básicas do dispositivo,

como alocação de recursos, monitoramento e escalonamento de processos ou pro-

gramas.

Figura 2.3: Modelo de camadas do sistema operacional Android[14].

Por fim, na camada mais elevada da pilha, temos as aplicações propriamente ditas.

Diferente de outros sistemas operacionais, as aplicações para Android são escritas em

Java e são executadas pela DVM.

Nesse trabalho nos limitaremos a estudar a camada mais elevada da pilha (a de

aplicações) e como se dá o processo de desenvolvimento de aplicaçoes para o An-

droid, utilizando as API’s de desenvolvimento fornecidas pelo Google (Android SDK).

Na próxima seção falaremos sobre o objetivo do trabalho baseado nos conceitos

mencionados neste capítulo.

2.1.5 Objetivo do trabalho

Nesse trabalho mostraremos de que forma é possível a construir um aplicativo

Android capaz de aproveitar as vantagens oferecidas pelo conceito dos Web Services


através de sua conexão com a Internet.

A organização deste trabalho é a seguinte: no capítulo 3 apresentaremos mais

detalhadamente como se da o funcionamento de aplicações no Android e faremos

uma apresentação das ferramentas de desenvolvimento fornecidas pelo Google para

a criação de aplicativos. Em seguida mostraremos o funcionamento mais detalhado

de um Web Service e como ele pode ser executado. No capítulo 4 mostraremos

como pode-se, utilizando as ferramentas fornecidas pelo Google, criar um aplicativo

para android que seja capaz de executar um Web Service. Faremos também uma

análise do desempenho do aplicativo criado para executar um algoritmo de cálculo de

números primos e comparar com o desempenho do mesmo algoritmo executado no

android. Por fim, no capítulo 5 apresentaremos uma conclusão a partir dos resultados

obtidos.

Capıtulo 3Web Services e Android

Com o crescente número de dispositivos móveis atuais (que por vezes possuem

um poder computacional limitado) e a crescente demanda por serviços e aplicações

que interagem entre si, o uso de Web Services se torna de grande importância para

manter (ou até mesmo possibilitar) a integração entre esses serviços — devido aos

vários modelos disponíveis de diferentes fabricantes. Nesse contexto, aplica-se o mo-

delo de computação chamado cliente-servidor, onde o Web Service age como um

servidor que será responsável pelo processamento de determinada tarefa e por en-

viar os dados pertinentes ao cliente, que por sua vez deverá apenas renderizar as

informações obtidas, deixando, dessa forma, o processamento por conta do servidor.

Na seção 3.1 falaremos sobre o sistema operacional Android e na secão 3.2 expli-

caremos mais detalhadamente o funcionamento dos Web Services e dos protocolos

utilizados para consumí-los.

3.1 O Sistema Operacional Android

O Android foi construído para poder ser executado em dispositivos com pouca me-

mória e baixo poder computacional. Para isso, na base da pilha que compõe o sistema

(Fig. 2.3) existe um kernel Linux versão 2.6 modificado para atender às necessidades

de gerenciamento de energia, memória e ambiente de execução.

Diferente dos outros sistemas, como o iOS ou Symbian, as aplicacões Android são

escritas em Java e rodam numa máquina virtual. Para esse propósito, o Android pos-

sui, em uma de suas camadas, uma máquina virtual chamada Dalvik Virtual Machine

(DVM), responsável pela execução dos aplicativos. Dentro da DVM o código escrito

12

3.1. O Sistema Operacional Android 13

em Java é convertido para um código binario próprio da DVM.

Os aplicativos, em geral, têm seu ciclo de vida baseado em eventos, e o sistema

operacional fornece pequenos módulos para o tratamento deles, de forma que quando

uma determinada ação é feita pelo usuário o sistema dispara o evento associado.

Cada aplicativo roda em um espaço próprio (sandbox) e pode ser composta por

vários componentes: Activities, Services, Broadcast receivers e Content Providers.

Esses componentes podem interagir entre si dentro de um aplicativo e também com

outros aplicativos através de processos chamados Intents.

Na próxima seção descreveremos um pouco mais detalhadamente a estrutura de

um aplicativo Android e seus principais componentes.

3.1.1 Estrutura de um aplicativo Android

A estrutura de um aplicativo Android é composta de quatro componentes: Activi-

ties, Services, BroadcastReceiver e ContentProvider. Nem todos esses componentes

são obrigatórios em um aplicativo, porém para que exista uma interface gráfica é ne-

cessária ao menos uma Activity.

Activity é o componente da aplicação reponsável pela interface gráfica através da

qual o usuário interage com o sistema. De modo geral, cada Activity é uma janela, de

forma que cada aplicativo pode conter várias Activities com funcionalidades indepen-

dentes.

Toda Activity é derivada da classe android.app.Activity, e tem seu ciclo de vida

controlado por um conjunto de métodos, dentre os quais destacam-se [7]

• onCreate()- Inicia a ActivityO servidor publica a assinatura dos seus procedi-

mentos no repositório.

• onDestroy()- Encerra a Activity.

• onResume()- Dá continuidade a uma Activity pausada

• onPause()- Salva o estado atual da Activity e a coloca em background.

Content Provider é um componente da aplicação responsável pelo gerencia-

mento de acessos a um conjunto de dados e por fornecer um mecanismo para se-

gurança dos dados. Pode ser usado, entre outras coisas, para compartilhar dados

entre duas aplicações distintas [13].

3.2. Web Services 14

Content Provider é usado para armazenar e recuperar dados nas aplicações An-

droid. Estes “provedores” podem também ser usados para compartilhar dados entre

múltiplas aplicações, desde que as mesmas possuam as permissões corretas para

acessar os dados. O Android já possui content providers padrões para, por exemplo,

imagens, vídeos, contatos e configurações, as quais podem ser encontradas no an-

droid.provider.package. Uma aplicação consulta um ContentResolver, o qual retorna

o ContentProvider apropriado.

Todos os Content Providers são acessados como um banco de dados com uma

Uniform Resource Identifier (URI) para determinar o provedor, o nome de um campo e

o tipo do dado desse campo. Aplicações acessam somente os Content Providers via

ContentResolver, nunca diretamente [7].

Broadcast Receiver é um componente que responde a eventos do sistema envi-

ados em broadcast. Muitos dos sinais broadcast são originários do próprio sistema

− por exemplo, um aviso que o ecrã foi desligado, a bateria está fraca, ou que uma

foto foi capturada. Aplicativos também podem enviar avisos broadcast − por exemplo,

avisar às outras aplicações que algum dado foi baixado no aparelho e está disponível

para elas o usarem. Apesar dos Broadcast Receivers não possuírem uma inter-

face com o usuário, eles podem criar uma barra de notificação de status para alertar

o usuário quando um evento ocorre. Portanto, um Broadcast Receiver é apenas um

“gateway” para outros componentes [7].

Services são componentes que podem executar operações de longa durabilidade

em background e não fornecem ao usuário uma interface gráfica. Um service pode

ser iniciado por uma aplicação, e continuará sendo executado mesmo que o usuário

alterne entre aplicações distintas. É possível ainda que outras aplicações possam

fazer uso de um service para interagir com ele e até mesmo executar operações entre

processos (fazendo uso do protocolo RPC) [13].

Com isso apresentamos as estruturas básicas que compõem um aplicativo An-

droid. Nas sessões seguintes, apresentaremos mais detalhadamente o funcionamento

de Web Services e os padrões utilizados para garantir a interoperabilidade.

3.2 Web Services

O RPC, e outras tecnologias dele derivadas, forneceu uma boa solução para me-

diar a integração entre aplicações localizadas em diferentes endereços em sistemas


distribuídos. O funcionamento dessas tecnologias, no entanto, dependem de uma sé-

rie de fatores como plataforma, linguagem de programação utilizada, tipo de conexão,

etc.

Web services vão além dessas tecnologias. Eles permitem uma integração trans-

parente e que não depende de plataformas e outros fatores que antes eram essenciais.

Neste capítulo faremos um estudo sobre Web Services. Mostraremos como funci-

onam, quais suas principais características e o formato dos protocolos definidos como

padrões para o seu funcionamento.

3.2.1 O que são Web Services

A ideia por trás dos Web Services é a de criar uma forma de executar serviços

através da Internet, de forma que tais serviços possam ser executados a partir de

qualquer dispositivo capaz de enviar e receber mensagens utilizando algum protocolo

de comunicação para a Internet (por exemplo o protocolo HTTP).

Existem várias definições para Web Services. O W3C define Web Services como

sendo aplicações criadas para dar suporte à interoperabilidade entre sistemas através

da internet. Suas interfaces podem ser definidas, descritas e descobertas na forma

mensagens no formato de Extensible Markup Language (XML) [6]. Toda interação

com Web Services é feita através de mensagens baseadas em XML que seguem

padrões pré-estabelecidos. O uso desses padrões permite que os serviços possam

ser acessados a partir de qualquer plataforma.

Assim como no RPC, Web Services funcionam como uma aplicação do tipo Cliente-

Servidor cuja arquitetura é formada basicamente por três componentes: um cliente (

Service Requester), um servidor ( Service Provider) e um registro ( Service Registry)

dos procedimentos, ou serviços, disponíveis [15]. Em Web Services, os serviços são

descritos no registro através de uma IDL própria - O WSDL - e podem ser localizados

dentro do registro com a utilização do UDDI. Por fim, a comunicação entre o cliente e o

servidor é feita através da troca de pacotes no formato definido pelo protocolo SOAP.

Essa forma simplificada de interação baseada em troca de mensagens em formatos

padrões permite que os Web Services possam ser utilizados a partir de qualquer tec-

nologia capaz de enviar e receber mensagens através da Web.

Na próxima seção explicaremos um pouco mais detalhadamente como é o funcio-

namento dos Web Services.


3.2.2 Como funcionam os Web Services

Primeiramente, para ser acessado, o Web Service precisa estar disponível num

servidor de dados acessível através de protocolos da web. Para executar o serviço, o

cliente deverá, primeiramente, localizá-lo através do UDDI e, através do WSDL obter

uma assinatura do procedimento (nome, parâmetros de entrada e retorno). Depois

de obter os dados do procedimento, o cliente deverá criar uma mensagem no formato

SOAP e enviá-la ao servidor (o envio é feito, em geral, através do protocolo HTTP). O

servidor irá receber a mensagem, executar o procedimento e enviar uma mensagem

com retorno , também no formato SOAP, para o cliente.

O funcionamento dos Web Services pode ser descrito como interações entre os

seus três componentes principais: Service Requester, Service Provider e Service

Registry. Essas interações envolvem publicação, localização e ligação entre os com-

ponentes. Como mostra a figura 3.1.

Figura 3.1: Exemplo do fluxo de execucao de um WS [15].

Em um cenário típico, o Service Provider hospeda uma implementação do Web

Service de forma que ele seja acessível através da Internet. Para identificar o serviço

desejado, o Service Requester realiza uma operação de busca no Service Registry.

Essa busca é feita com o uso do UDDI, que fornece um catálogo com a descrição

e localização dos serviços disponíveis. Dessa forma o Service Requester obtém o

endereço e o WSDL necessários para conectar-se ao Service Provider e invocar o


Web Service com os parâmetros necessários.

Uma vez que a conexão entre Service Provider e Service Requester tenha sido

estabelecida, o Service Requester envia, através de algum protocolo de comunicação

(em geral via HTTP), um envelope SOAP para o Service Provider, que irá desempa-

cotar os dados e executar o serviço solicitado. Ao fim da execução o Service Provider

poderá, ou não, enviar uma nova mensagem informando os resultados da operação

ou possíveis erros que possam ter ocorrido. A figura 3.2 demonstra as interações en-

tre um Service Requester, Service Registry e Service Provider durante a execução de

um Web Service.

Figura 3.2: Interações entre as principais entidades na execução de um Web Service.

Nas próximas seções explicaremos com mais detalhes os protocolos e padrões

utilizados pelos Web Services. Na seção 3.2.3.1 mostraremos o protocolo SOAP, na

seção 3.2.3.2 explicaremos o WSDL e, por fim, na seção 3.2.3.3 explicaremos o UDDI.

3.2.3 Protocolos e padrões utilizados

Nesta seção faremos uma descrição dos principais protocolos utilizados em Web

Services. Na seção 3.2.3.1 mostraremos o protocolo SOAP, na seção 3.2.3.2 mostra-


remos o WSDL e, finalmente, na seção 3.2.3.3 o UDDI.

3.2.3.1 SOAP

Devido a natureza de interoperabilidade dos sistemas web, foi necessário o desen-

volvimento de um protocolo padrão específico para a troca de mensagens e "Remote

Procedure Calls"(RPC)[8]. Esse protocolo chama-se Simple Object Access Protocol

(SOAP). Baseado em XML, e com um “design” simples (semelhante a um envelope),

faz-se útil para uma grande variedade de aplicações que precisam realizar trocas de

mensagens e integração de sistemas.

No seu núcleo, uma mensagem SOAP tem uma estrutura muito simples e flexível,

contém um cabeçalho e um corpo. Embora seu cabeçalho seja opcional, ele con-

tém informações relevantes de como tratar a mensagem, tais quais como roteamento,

configurações de entrega, autenticação, etc. Cada envelope possui apenas um cabe-

çalho. Já o corpo contém a mensagem a ser entregue e processada, tudo que puder

ser expressado na sintaxe de XML pode fazer parte do corpo da mensagem.[8]

As mensagens SOAP, em geral, seguem o estilo de mensagens RPC. Permitem

mensagens de requisição, enviadas pelo cliente e mensagens de respostas recebidas

do servidor. As mensagens de requisição contém os dados da chamada do proce-

dimento, como nome e parâmetros de entrada. As mensagens de resposta, por sua

vez, possuem os parâmetros de saída do procedimento. O protocolo, no entanto, não

exige uma resposta para cada requisição realizada, e, da mesma forma, pode exis-

tir uma mensagem com os parametros de saída sem que o cliente tenha feito uma

requisição[6].

Há várias versões de especificação do SOAP colocadas em produção, a mais co-

mum delas é a 1.2, resultante de uma força tarefa realizada pelo W3C para padronizar

este protocolo baseado em XML para os serviços web [6].

As regras para empacotar uma requisição RPC em um envelope SOAP são sim-

ples.A chamada ao método é representada em uma estrutura com os parâmetros de

entrada e saída modeladas naquela estrutura.

Os nomes e ordem dos parâmetros devem corresponder com os nomes e ordem

dos parâmetros do método a ser invocado.

Em relação ao transporte, SOAP não se preocupa com o protocolo usado para as

trocas de mensagens, tornando-se, dessa forma, extremamente flexível [6].


3.2.3.2 WSDL

O WSDL foi criado pela IBM, Microsoft e Ariba ao fundir o “Microsoft’s SOAP Con-

tract Language (SCL)” e “Service Description Language” juntos ao IBM’s Network Ac-

cessible Service Specification Language (NASSL).

Ele é um arquivo em formato XML que descreve o Web Service em questão, ele diz

qual o propósito do Web Service e principalmente as interfaces do serviço, tais como

os tipos de dados que precisa receber para processar e devolver, ou não, a resposta.

A estrutura de uma Interface WSDL é composta pela parte abstrata (figura 3.3) e

a parte concreta (figura 3.4).

Na figura 3.3, ou seja, na parte abstrata, temos as mensagens e operações que

definem um Web Service, o desenvolvedor ao ler esse documento já pode identificar

o que ele precisa enviar e sabe o que receber para qual operação desejar utilizar.

Figura 3.3: Estrutura da parte abstrata de uma interface WSDL [8].

Na figura 3.4 temos a parte concreta do WSDL, ela descreve a configuração da

conexão e da comunicação, como deve ser o formato das mensagens SOAP e quais


os namespaces.

Figura 3.4: Estrutura da parte concreta de uma interface WSDL [8].

A estrutura do WSDL é interessante não só por que descreve como os serviços

interagem, mas também que as operações além de serem chamadas às vezes po-

dem chamar outras, ou seja, o serviço pode se comportar como um cliente também.

Outro ponto importante é essa separação do abstrato do concreto, enquanto o pri-

meiro contém as interfaces o segundo contém a localização do serviço e o protocolo

de comunicação a ser usado.


Há uma correlação entre SOAP e WSDL, se uma das mensagens definidas em

WSDL é mudada, então a InterfaceBinding contém todas as informações necessá-

rias para automaticamente construir as mensagens SOAP, o fato de WSDL e SOAP

usarem esta codificação XML facilita totalmente a padronização de Web Services, por

isso o W3C trabalha para documentar esse padrão, que ele serve muito mais do que

apenas uma descrição de assinaturas para métodos e configuração, mas que cobre

também aspectos de segurança, garantia de entrega, interação de transações e muito

mais [8].

3.2.3.3 UDDI

O Universal Description, Discovery and Integration comumente chamado por UDDI,

como o próprio nome diz serve como uma forma unificada e sistematizada de publi-

car ou também localizar serviços web, ele funciona como uma lista telefônica só que

para Web Services, O "Browser-accessible UDDI Business Registry (UBR)"é o regis-

tro acessado via browser, ele veio a público rapidamente logo após a especificação

sobre UDDI ser anunciada pela Microsoft, IBM e Ariba, ele integra de forma inteli-

gente os outros dois protocolos anteriormente citados, ele utiliza SOAP para a troca

de mensagens e WSDL para a descrição de como se comunicar.

A estrutura do registro de um serviço é composta por duas informações bási-

cas, que são a definição da informação que cada serviço oferece, a chave de como

criptografá-lo e uma API para consulta e update para o registro, que descreve como a

informação pode ser acessada e atualizada.

O UDDI como dito anteriormente funciona como uma lista telefônica, e portanto

nada mais justo que organizar a estrutura das informações da seguinte forma:

• Páginas brancas- possuem os nomes e detalhes do contato.

• Páginas amarelas- possuem os serviços organizados por tipo e regras de ne-

gócio.

• Páginas verdes- possuem dados técnicos sobre os serviços.

Nas "páginas brancas", temos a businessEntity, e ela pode ter uma ou mais ser-

viceEntity, porém cada serviceEntity não pode ter mais de uma businessEntity, e

as duas podem ter uma ou mais categoryBag para classificar a businessEntity ou


a serviceEntity. As entidades são identificadas através de UUID (Universal Unique

Identifiers) que garante uma ID única para cada uma[6].

A figura 3.5, mostra uma businessEntity, ela possui o seu atributo de tag que é

único, diz o código de internacionalização do XML, dados da empresa e de contatos

dentro da empresa para quaisquer dúvidas.

Figura 3.5: Estrutura de uma interface UDDI [8].

Web Services possuem uma série de vantagens, tais como deixar um proces-

samento pesado a cargo de um servidor específico para tal tarefa, permitir acesso

facilitado através de browser de Internet, facilidade para desenvolver um cliente in-

dependentemente da arquitetura do servidor, por conta de sua inteligibilidade ao ser

humano e às conformidades especificadas nos documentos WSDL, distribuir proces-

samento para outros nós, entre outros.


Porém, os Web Services possuem também algumas desvantagens, como por

exemplo a privacidade, o servidor do Web Service pode armazenar seus dados e

utilizá-los para algum fim de interesse próprio, como base para dados estatísticos.

Outro ponto relevante é a disponibilidade, é muito difícil ter a garantia de que um Web

service do qual somos dependentes esteja sempre disponível, ou então que não esteja

congestionado devido a requisições de outros usuários.

Capıtulo 4Implementação de aplicativos Android

Neste capítulo apresentaremos a API de desenvolvimento Android fornecida pelo

Google e como pode ser feita a implementação de um aplicativo Android capaz de

consumir um Web Service. Na seção 4.1 mostraremos as bibliotecas necessárias

para a criação do aplicativo e para consumir web services. Na seção 4.2 mostraremos

como criar um aplicativo que irá utilizar Web Services para fazer cálculos de números

primos remotamente.

4.1 Bibliotecas Essenciais

Para criação e envio de mensagens SOAP utilizaremos a KSOAP2, uma biblioteca

Java de uso livre, desenvolvida pela comunidade de desenvolvimento com foco no sis-

tema operacional Android. Iniciaremos apresentando o Android SDK, um conjunto de

ferramentas criado pelo Google para uso das API’s Android. Em seguida mostraremos

a estrutura do aplicativo, e quais os passos e configurações necessárias para fazer a

implementação do aplicativo e consumo do Web Service utilizando Ksoap2.

Na seção 4.1.1 apresentaremos a API de desenvolvimento Android fornecida pelo

Google. Na seção 4.1.2 apresentaremos a biblioteca KSOAP2 utilizada para consumir

Web Services.

24

4.2. Criando um aplicativo 25

4.1.1 API Android

O Google fornece uma série de API’s destinadas ao desenvolvimento de aplica-

tivos para a plataforma. A medida que o desenvolvimento do sistema operacional

evolui, surgem novas API’s com novas funcionalidades, de forma que cada versão do

sistema possui sua própria API. Neste trabalho utilizaremos a versão 2.3 do sistema,

chamada Ginger Bread [Apêndice A].

4.1.2 KSOAP2

Para criar um cliente capaz de consumir um Web Service com o Android, é ne-

cessário a utilização de uma biblioteca chamada KSOAP2. Com essa biblioteca é

possível criar os envelopes SOAP com os dados necessários (parâmetros e endereço

do Web Service) e fazer a chamada própriamente dita do serviço.

Na próxima seção mostraremos como criar um aplicativo Android e como utilizar a

KSOAP2 para consumir um Web Service.

4.2 Criando um aplicativo

Nesta seção mostraremos como criar um aplicativo simples, capaz de executar um

Web service. A idéia é demonstrar como é possível utilizar Web services para realizar

tarefas com um alto custo computacional que, por muitas vezes, pode ser inviável num

dispositivo móvel, seja por limitações de processamento e memória ou por questões

de economia de energia.

Como exemplo, desenvolvemos um aplicativo para fazer a contagem de números

primos em um determinado intervalo (de zero até n, onde n é um parâmetro informado

pelo usuário). Para a identificação de números primos, utilizamos o algoritmo “ Crivo

de Erastótenes” [1].

4.2.1 Interface do usuário

A base para as interfaces gráficas no Android é a classe View. Todos os elementos

visíveis ao usuário num aplicativo são derivados dessa classe. O Android fornece

alguns padrões de views pré-definidos como botões, campos de inserção de texto,


etc. As views de um aplicativo podem ser definidas por um XML no qual cada nó

representa uma view.

Figura 4.1: Exemplo de definição de uma view referente a uma caixa de edição de

texto.

A figura 4.1 mostra um exemplo de definição de uma view, na qual é especificado

o tipo EditText, uma view pré-definida pelo Android para representar caixas de texto.

Dentro dela, informamos alguns campos importantes, como o id (propriedade atra-

vés da qual a view sera identificada dentro do código), inputType (propriedade que

seleciona o tipo de dados que essa view irá receber, no caso será textos, podendo

também ser valores numéricos) e valores referentes ao layout e posicionamento da

view (layoutWidth, layoutHeigth, etc).

No código Java, essa view pode ser instanciada através do metodo findViewById,

encontrado na API, como mostra a figura 4.2.

Figura 4.2: Exemplo de código para instanciar uma view previamente definida.


Figura 4.3: Exemplo de código para o evento de Click do botao btnExecutar.

4.2.2 Estrutura do aplicativo

A interface do aplicatico criado é bastante simples. Consiste basicamente de um

campo de texto, onde o usuário deverá informar o parâmetro de entrada, um seletor

onde o usuário poderá escolher o local de execução do serviço (no próprio aparelho

ou via Web Service) e um botão que, quando pressionado, irá executar o cálculo dos

números primos. A figura 4.4 mostra a interface gráfica do aplicativo.

Figura 4.4: Interface renderizada do aplicativo.

A estrutura criada para montar a interface foi implementada como na figura 4.5


Figura 4.5: Hierarquia definida para as views no aplicativo desenvolvido.

A interface do aplicativo é criada com o uso de views. Cada componente da tela

é uma view independente e pode conter, dentro de si, outras views. Na figura 4.5

vemos o uso de uma view base chamada RelativeLayout, trata-se de um tipo de layout

onde a posição dos elementos é definida em relação às demais views que compõem

a tela. Sobre a view RelativeLayout, temos um campo de edição de textos (EditText1),

um botão (Button) e um seletor (RadioGroup), sobre o qual existem outras três views

representando as opções. Todas esses tipos de view e várias outras estão disponíveis

na API.

A utilização do aplicativo deverá ser feita da seguinte maneira:

1. O usuário deverá informar no campo de texto, um número n, de forma que o

aplicativo identifique os primeiros números primos no intervalo de zero a n.

2. O usuário deverá escolher uma entre três opções de execução: local (nesse

caso o algoritmo será executado no próprio dispositivo), Servidor compartilhado

(executar o algoritmo num Web service hospedado num servidor comum, com

pouco poder computacional) ou Servidor dedicado (executar num Web Service

hospedado num servidor dedicado, com um maior poder computacional).

3. Depois de informado o parâmetro n e o local de execução, o usuário deve pres-

sionar o botão “Executar”. O aplicativo irá fazer os cálculos necessários e exibir


uma mensagem na tela informando o número de primos contados e o tempo de

execução (ou eventuais erros que possam vir a ocorrer). Também será gerado

um log em um arquivo de texto, que será utilizado posteriormente para análises

estatísticas.

O algorítmo 4.1 define a interface implementada segundo a hierarquia sugerida

para o aplicativo na figura 4.5:

Algorítmo 4.1: XML de definição da interface do aplicativo

1 <Rela t iveLayout xmlns:andro id=" h t t p : / / schemas . andro id . com/ apk / res / andro id "

2 xm lns : too l s = " h t t p : / / schemas . andro id . com/ t o o l s "

3 and ro id : l ayou t_w id th =" match_parent "

4 and ro i d : l a you t_he igh t = " match_parent "

5 t o o l s : c o n t e x t = " . M a i n A c t i v i t y " >

6 <Ed i tTex t

7 a n d r o i d : i d = "@+ i d / ed i tTex t1 "

8 and ro id : l ayou t_w id th =" wrap_content "

9 and ro i d : l a you t_he igh t = " wrap_content "

10 a n d r o i d : l a y o u t _ a l i g n P a r e n t L e f t = " t r ue "

11 and ro id : l ayou t_a l i gnPa ren tR igh t = " t r ue "

12 andro id : layou t_a l ignParen tTop=" t rue "

13 android:ems=" 10 "

14 andro id : inpu tType=" t e x t " >

15 <requestFocus / >

16 < / Ed i tTex t>

17 <Button

18 a n d r o i d : i d = "@+ i d / btnExecutar "



21 a n d r o i d : l a y o u t _ c e n t e r H o r i z o n t a l = " t r ue "

22 a n d r o i d : l a y o u t _ c e n t e r V e r t i c a l = " t r ue "

23 a n d r o i d : t e x t = " Executar " / >

24 <RadioGroup

25 a n d r o i d : i d = "@+ i d / radioGroup2 "



28 andro id : layou t_be low="@+ i d / ed i tTex t1 " / >

29 <RadioButton

30 a n d r o i d : i d = "@+ i d / rad io0 "



33 android:checked=" t rue "

34 a n d r o i d : t e x t = " Local " / >


35 <RadioButton




39 a n d r o i d : t e x t = "WS − Compart i lhado " / >

40 <RadioButton




44 a n d r o i d : t e x t = "WS − Dedicado " / >

45 < / RadioGroup>

46 < / Re la t i veLayout>

Na primeira linha, temos a definição da view principal que define o tipo de layout

utilizado. Dentro dela, encontramos as demais views e as definições de suas proprie-

dades.

Na ação de clique do botão Executar, o aplicativo deverá recuperar o parâmetro

passado na EditText, convertê-lo para um valor numérico e fazer a chamada do ser-

viço. Isto é feito no algorítmo 4.2 :

Algorítmo 4.2: Método OnCreate da Activity e tratamento da ação de clique do botão

1 @Override

2 protected void onCreate ( Bundle savedInstanceState ) {

3 super . onCreate ( savedInstanceState ) ;

4 setContentView (R. l ayou t . a c t i v i t y _ m a i n ) ;

5 t x t = ( Ed i tTex t ) f indViewById (R. i d . ed i tTex t1 ) ;

6 rad io = ( RadioGroup ) f indViewById (R. i d . radioGroup2 ) ;

7 btnLoca l = ( Button ) f indViewById (R. i d . btnExecutar ) ;

8 btnLoca l . se tOnCl i ckL is tener (new View . OnCl ickL is tener ( ) {

9

10 @Override

11 public void onCl ick ( View v ) {

12

13 / / base para contagem de tempo (em ms)

14 long t ime = System . c u r r e n t T i m e M i l l i s ( ) ;

15 Long TotalPr imosCalculados ;

16

17 / / Recuperar o parametro informado na caixa de tex to

18 long param = Long . parseLong ( t x t . getText ( ) . t o S t r i n g ( ) ) ;

19

20 /∗ Recuperar o index selecionado do radioGroup ∗ /

21 i n t rad ioBut ton ID = rad io . getCheckedRadioButtonId ( ) ;


22 selectedRadio = ( RadioButton ) f indViewById ( rad ioBut ton ID ) ;

23 i n t i dx = rad io . indexOfChi ld ( selectedRadio ) ;

24

25 /∗ A v a l i a r index para escolher o metodo ∗ /

26 i f ( i dx == 0 ) {

27 TotalPr imosCalculados = Calcu loLoca l ( param ) ;

28 } else i f ( i dx ==1) {

29 TotalPr imosCalculados = CalculoWSCompartilhado ( param ) ;

30 } else {

31 TotalPr imosCalculados = CalculoWSCompartilhado ( param ) ;

32 }

33

34 long endTime = System . c u r r e n t T i m e M i l l i s ( ) − t ime ;

35

36 }

37 } ) ;

38 }

No algorítmo 4.2, definimos o método OnCreate, que é executado no momento

da criação da Activity (ou seja, quando o aplicativo é iniciado). Dentro dele fazemos

o tratamento do parâmetro passado e da opção de execução escolhida. Definimos

também o método de OnClick do botão Executar. No momento do clique é chamada

uma subrotina para executar o algoritmo.

Algorítmo 4.3: Método utilizado para fazer a chamada ao Web service.1 / / executa o WS no server compart i lhado

2 public Long CalculoWSCompartilhado ( Long param ) {

3 Helper h = new Helper ( ) ;

4 h . SetMethod ( " ContaPrimos " ) ;

5 h . SetAct ion ( " h t t p : / / tempur i . org / ContaPrimos " ) ;

6 h . SetNamespace ( " h t t p : / / tempur i . org / " ) ;

7 h . SetURL ( " h t t p : / / p h y l l i p y . somee .com/ c r i v o . asmx" ) ;

8 return h . Ca l lSe rv i ce ( param ) ;

9 }

O algorítmo 4.3 mostra o uso de um helper criado para facilitar a utilização da

biblioteca KSOAP2. Aqui definimos algumas propriedades essenciais para a chamada

do serviço:

• Método- essa propriedade define o nome do método que deverá ser executado

no Web Service.

• Namespace- Namespace definido no Web Service no momento de sua criação.


• Action- Essa propriedade é, na verdade, uma combinação do Namespace com

o Método.

• URL- endereço do local onde o Web service está hospedado. Esse endereço

será utilizado para fazer a troca de mensagens.

O metodo CallService implementa os métodos necessários para a criação do

envelope SOAP e comunicação com o Web service.

Algorítmo 4.4: Implementação das funcionalidades necessárias para consumir o Web

service.

1 protected Long doInBackground ( Long arg0 ) {

2 i n t MSG_TIMEOUT = 150000;

3 SoapObject request = new SoapObject ( th is . Namespace , th is . Method ) ;

4

5 / / Adic iona a propr iedade " param " r e f e r e n t e ao parametro do ws

6 request . addProperty ( " param " , arg0 ) ;

7

8 / / Cr ia o envelope SOAP versao 1.1

9 SoapSer ia l i za t ionEnve lope envelope = new SoapSer ia l i za t ionEnve lope (

SoapEnvelope .VER11) ;

10

11 / / f l a g para ws .NET

12 envelope . dotNet = true ;

13

14 / / Cr ia o envelope com os dados da requ is i cao

15 envelope . setOutputSoapObject ( request ) ;

16

17 t ry {

18 / / Metodo que c r i a a conexao HTTP com o ws

19 HttpTransportSE andro idHt tpTranspor t = new HttpTransportSE ( th is .URL,

MSG_TIMEOUT) ;

20

21 / / executa a chamada do serv i co

22 andro idHt tpTranspor t . c a l l ( th is . Act ion , envelope ) ;

23

24 / / recuperar o SOAP de re to rno do WS

25 SoapObject resultsRequestSOAP = ( SoapObject ) envelope . bodyIn ;

26

27 / / recuperar o resu l tado da operacao e retorna−l o

28 S t r i n g re = resultsRequestSOAP . ge tProper tyAsSt r ing ( 0 ) ;

29 return Long . parseLong ( re ) ;

30 } catch ( Except ion e ) {


31 e . p r in tS tackTrace ( ) ;

32 }

33

34 / / Caso apresente erro , re to rna ra zero

35 return new Long ( 0 ) ;

36 }

O código 4 mostra a implementação e emprego dos objetos necessários para con-

sumir um Web Service. Na primeira linha, vemos a criação de um objeto SoapObject,

uma classe da biblioteca KSoap2 que tem por objetivo montar um pacote SOAP. Os

parâmetros necessários para a criação do pacote são: o namespace do serviço que

será executado e o nome do método desejado. Após a criação do pacote, adicio-

namos a propriedade param. Essa propriedade é referente ao parametro que deve

ser passado para o Web service (é importante que o nome fornecido seja o mesmo

do parametro escrito na descrição do Web service). A adesão da propriedade é feita

através do método addProperty do SoapObject.

Depois de criar o pacote, deve colocá-lo em um envelope e serializá-lo. Isso é

feito com o auxílio da classe SoapSerializationEnvelope, aqui informamos ao objeto a

versão SOAP desejada (em nosso caso 1.1).

Por fim, utilizamos a classe HttpTransportSE para criar a conexão entre o aplica-

tivo e o Web Service utilizando o protocolo HTTP. O envio da requisição é feito através

do método call, informando como parâmetros a ação que deverá ser executada (Ac-

tion) e o envelope contendo o pacote SOAP. A resposta da chamada fica armazenado

na propriedade bodyIn do envelope, de forma que as propriedades de retorno podem

ser acessadas com o uso do metodo getPropertyAsString(index) que retornará o va-

lor da propriedade indicada. Esse valor será o retorno do Web Service e deve ser

interpretado de acordo com cada serviço.

Com o uso da biblioteca Ksoap2, o consumo de Web services a partir de dispo-

sitivos móveis com o sistema operacional Android pode ser feito de forma bastante

simples e rápida. No capítulo seguinte mostraremos alguns dos resultados obtidos na

execução dos Web services.

Mostraremos também uma comparação de desempenho para rodar o algoritmo

Crivo de Erastótenes com processamento local (no aparelho) e através de Web servi-

ces.

Capıtulo 5Conclusão

O uso de Web services pode ser uma ótima alternativa para a execução de progra-

mas com elevado custo computacional em dispositivos móveis que possuem recursos

limitados. Com eles, podemos utilizar outras fontes de processamento para tratar pro-

blemas mais complexos. Para isso basta que o dispositivo utilizado possua acesso à

rede (seja via Wifi, 3G ou qualquer outra tecnologia análoga).

Neste capítulo mostraremos alguns dos resultados obtidos com a aplicação de-

senvolvida durante o trabalho.

5.1 Testes realizados

Neste trabalho demonstramos o uso de Web Services para realizar duas tarefas.

A primeira é fazer uma contagem dos n primeiros primos, um problema simples mas

que por vezes pode exigir um tempo considerável para ser executado. A segunda

tarefa é calcular a matriz resultante da multiplicação de duas matrizes quadradas de

ordem n, um problema de custo computacional elevado e que, ao contrário do primeiro

problema, exige a necessidade de enviar uma grande quantidade de dados através da

rede.

Para comparar o desempenho, implementamos o calculo de duas formas:

1. executando localmente

2. executando através de um Web service em um servidor compartilhado

34

5.1. Testes realizados 35

O Web Service foi implementado utilizando a tecnologia .NET da Microsoft (o

WSDL referente ao Web Service criado pode ser visto no apêndice C ).

Os testes locais foram executados em um celular Motorola com processador de

1Ghz e 512mb de memória RAM. O servidor compartilhado utilizado possui um pro-

cessador de 2.5Ghz e 2Gb de memória (estes recursos são compartilhados entre os

demais usuários do servidor).

Para os testes do primeiro problema foram utilizados diversos valores para n, va-

riando de 1.000 a 2.000.000. Para cada valor selecionado, o aplicativo foi executado

nas duas opcões disponíveis. Notamos que, inicialmente, o desempenho para proces-

samento local é superior, sugerindo que o tempo de processamento é menor do que

o necessário para comunicar-se e trocar mensagens com o Web Service. Essa dife-

rença muda à medida que o parâmetro de entrada aumenta, de forma que a execução

através de web services pode chegar a ser até 10 vezes mais rápida em relação à

local [Figura 5.1].

Figura 5.1: Gráfico comparando desempenho para cálculo de primos.

Para o teste de multiplicação de matrizes, foram utilizadas matrizes quadradas

de ordem n, com n variando de 50 a 500. O objetivo deste teste era verificar se o

uso de Web Services ainda é vantajoso quando o custo de envio das mensagens é

muito elevado. Nesse caso o tamanho dos dados enviados nas mensagens aumenta

significativamente conforme o parâmetro de entrada.

O Web Service responsável pela multiplicação de matrizes recebe como parâme-

tro um inteiro que indica a ordem da matriz e um array de bytes contendo as matrizes

5.2. Trabalhos futuros 36

de entrada codificadas e devolve um array de bytes contendo a matriz resultante codi-

ficada.

A Figura 5.2 mostra os resultados obtidos na execução do segundo problema.

Observamos que mesmo com a necessidade de enviar uma grande quantidade de

dados pela rede, o uso de Web Services ainda se mostra vantajoso em relação ao

processamento local (no dispositivo) para matrizes de ordem elevada.

Figura 5.2: Gráfico comparando desempenho para multiplicação de matrizes.

Os resultados obtidos mostraram que o uso de Web Services pode ser uma boa

alternativa para problemas de alto custo computacional em dispositivos móveis. Além

disso podem ser usados também com seu proposito original de servir como forma de

integração entre sistemas. Nesse caso, integrando dispositivos movéis com uma série

de sistemas já existentes, dentre os quais podemos destacar instituições financeiras

que usam Web Services para efetuar transações através da internet, integração com

sistemas de bancos de dados remotos, entre outras.

5.2 Trabalhos futuros

Um outro tipo de serviço que está em ascensão e pode ser utilizado como meca-

nismo de integração de dispositivos Android com sistemas remotos são os chamados

RestFul Web Services. Em trabalhos futuros podem ser analisadas as diferenças de

desempenho com o uso de Web Services e RestFul Web Services.

Referências Bibliográficas

[1] Crivo de erastótenes. [Online; Acessado em 17-jan-2013].. Disponível em http:

//pt.wikipedia.org/wiki/Crivo_de_Erastotenes.

[2] Worldwideweb: Proposal for a hypertext project (em inglês). [Online; Acessado

em 26-fev-2013].. Disponível em www.w3.org/Proposal.html.

[3] Android deteve 70 do mercado mundial de smartphones em

2012, 2012. [Online; Acessado em: 6/3/2013].. Disponí-

vel em http://mobileexpert.com.br/mercado-telecom/materias/2198/

android-deteve-70-do-mercado-mundial-de-smartphones-em-2012.

[4] Open Handset Alliance. Industry leaders announce open platform for mo-

bile devices. [Online; Acessado em: 20-fev-2013].. Disponível em http://www.

openhandsetalliance.com/press_110507.html.

[5] Open Handset Alliance. Open handset alliance releases android sdk. [Online;

Acessado em: 11-dez-2012].. Disponível em http://www.openhandsetalliance.

com/press_111207.html.

[6] Gustavo Alonso e Fabio Casati. Web Services. Concepts, Architecture and appli-

cations. SPRINGER, 2010.

[7] Stefan Brahler. Analysis of the android architeture. 2010.

[8] Francisco Curbera, Matthew Duftler, Rania Khalaf, William Nagy, Nirmal Mukhi, e

Sanjiva Weerawarana. Unraveling the web services web, an introduction to soap,

wsdl, and uddi. 2002.

[9] D. Menasce e V. Almeida. Capacity Planning for Web Services. Prentice Hall,

2001.

37

http://pt.wikipedia.org/wiki/Crivo_de_Erastotenes

http://pt.wikipedia.org/wiki/Crivo_de_Erastotenes

www.w3.org/Proposal.html

http://mobileexpert.com.br/mercado-telecom/materias/2198/android-deteve-70-do-mercado-mundial-de-smartphones-em-2012

http://mobileexpert.com.br/mercado-telecom/materias/2198/android-deteve-70-do-mercado-mundial-de-smartphones-em-2012

http://www.openhandsetalliance.com/press_110507.html




Referências Bibliográficas 38

[10] Ben Elgin. Google Buys Android for Its Mobile Arsenal. Bloomberg Businessweek,

2005.

[11] eLinux.org Embedded Linux Wiki. Android kernel features, 2012. [Online;

acessado em 22-dez-2012].. Disponível em http://elinux.org/Android_Kernel_

Features.

[12] Roy Thomas Fielding. Architectural styles and the design of network-based

software architectures. 2000. Disponível em http://www.ics.uci.edu/~fielding/

pubs/dissertation/top.htm.

[13] Google Inc. Android guides, 2012. [Online; Acessado em: 29-nov-2012].. Dispo-

nível em http://developer.android.com/guide/components/index.html.

[14] Google Inc. Android software development kit (sdk)., 2012. [Online; acessado em

7-dez-2012].. Disponível em http://source.android.com/about/index.html.

[15] Heather Kreger. Web Services Conceptual architecture. IBM Software Group,

2001.

[16] David Luckham. The Power of Events: An Introduction to Complex Event Proces-

sing in Distributed Enterprise Systems. Addison-Wesley, 2002.

[17] Android Open Source Project. About the android open source project, 2012.

[Online; acessado em 11-dez-2012].. Disponível em http://source.android.com/

about/index.html.

[18] Rick Rogers, John Lombardo, Zigurd Mednieks, e Blake Meike. Android Applica-

tion Development: Programming with the Google SDK. OReilly Media, 2009.

[19] Mike Kopack Stephen Potts. Aprenda 24 Horas Web Services. Editora Campus,

2003.

[20] Doug Tidwell, James Snell, e Pavel Kulchenko. Programming Web Services with

SOAP. O’Reilly, 2001.

[21] W3C. Programação orientada a eventos. [Online; Acessado em: 02-fev-

2013].. Disponível em http://pt.wikipedia.org/wiki/Programac~ao_orientada_a_

eventos.

[22] W3C. Web service description language - wsdl, 2001. [Online; Acessado em:

17-set-2012].. Disponível em http://www.w3.org/TR/wsdl.

http://elinux.org/Android_Kernel_Features

http://elinux.org/Android_Kernel_Features

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

http://developer.android.com/guide/components/index.html

http://source.android.com/about/index.html



http://pt.wikipedia.org/wiki/Programa�~ao_orientada_a_eventos

http://pt.wikipedia.org/wiki/Programa�~ao_orientada_a_eventos

http://www.w3.org/TR/wsdl

Referências Bibliográficas 39

[23] W3C. Extensible markup language (xml), 2007. [Online; Acessado em: 17-set-

2012].. Disponível em http://www.w3.org/TR/xml11.

[24] W3C. Simple object access protocol - soap, 2007. [Online; Acessado em: 17-set-

2012].. Disponível em http://www.w3.org/TR/soap/.

http://www.w3.org/TR/xml11

http://www.w3.org/TR/soap/

Apêndices

Apendice AHistórico de versões do Android

Tabela A.1: Histórico de versões do Android

41

Apendice BExtensible Markup Language

A Extensible Markup Language, comumente chamada por XML, surgiu da neces-

sidade de uma padronização para a troca de dados entre os computadores/sistemas

com alto nível de portabilidade e que pudesse fornecer uma inteligibilidade às pes-

soas.

Basicamente, a XML organiza os dados de forma estruturada em um documento

XML usando tags ao estilo da HTML, o vocabulário usado pelas tags é definido pelo

usuário de acordo com sua necessidade, e deve ser respeitado algumas regras gra-

maticais no documento XML, que são:

• A tag inicial é a “raiz”.

• Cada tag deve possuir a tag final correspondente.

• É Case Sensitive, ou seja, diferencia maiúsculas de minúsculas.

• Cada valor de atributo de tag deve estar entre aspas.

• As tags devem estar aninhadas corretamente.

• É necessário ter cuidado com caracteres especiais.

• No cabeçalho deve conter a seguinte linha: <?xml version=’1.0’ ?>.

Dessa forma, um documento que respeita essas regras é considerado um docu-

mento consistente. Caso uma ou mais regras não sejam respeitadas, os erros retor-

narão na hora da análise do documento.

Esse documento é apenas um dos componentes que integram a XML, vejamos

abaixo outros exemplos de componentes:

42

43

• Parser XML - Recebe como insumo um documento XML e faz a leitura dos dados

e os retorna de forma organizada ao programa que o chamou, esse, por sua vez,

pode organizar os dados em sua estrutura na forma que desejar, e usar ou não

o dado recebido.

• Document Type Definition - Comumente chamado apenas por DTD, é respon-

sável por especificar quais são as tags passíveis de uso e as relações entre

elas, apesar de ainda ser facilmente encontrado, seu uso é desencorajado para

projetos novos, pois vem sendo substituído pelo Esquema XML desde 2001.

• Esquema XML - Basicamente funciona como o DTD, porém possui algumas

outras funcionalidades ao invés de apenas validar as tags e especificar seus

relacionamentos, como, por exemplo, declarar o tipo do atributo e a faixa de

valores que ele pode assumir. Sem mencionar o fato que essa validação é feita

fora do programa por um Parser XML, dessa forma evita a reescrita de código

sempre que for usá-lo por outros programas.

• Namespace- O namespace fica contido no esquema, ele serve para que tags

que possuem o mesmo nome, porém de projetos/áreas diferentes, conflitem com

as do projeto/programa principal.

Portanto, sendo um padrão que é mantido pelo W3C foi bem recebido pelo mer-

cado pela usa simplicidade para a padronização de troca de informações entre siste-

mas e aplicações de forma ágil, tornando-se “de fato” uma referência.

Apendice CWSDL do trabalho prático

Algorítmo C.1: WSDL do trabalho prático

1 <?xml version=" 1.0 " encoding=" u t f −8" ?>

2 < w s d l : d e f i n i t i o n s xmlns:tm=" h t t p : / / m i c roso f t . com/ wsdl / mime / tex tMatch ing / "

xmlns:soapenc=" h t t p : / / schemas . xmlsoap . org / soap / encoding / " xmlns:mime="

h t t p : / / schemas . xmlsoap . org / wsdl / mime / " xmlns : tns=" h t t p : / / tempur i . org / "

xmlns:soap=" h t t p : / / schemas . xmlsoap . org / wsdl / soap / " xmlns:s=" h t t p : / /www.

w3 . org /2001/XMLSchema" xmlns:soap12=" h t t p : / / schemas . xmlsoap . org / wsdl /

soap12 / " xm lns :h t tp= " h t t p : / / schemas . xmlsoap . org / wsdl / h t t p / "

targetNamespace=" h t t p : / / tempur i . org / " xmlns:wsdl= " h t t p : / / schemas . xmlsoap

. org / wsdl / ">

3 <wsd l : t ypes>

4 <s:schema elementFormDefault= " q u a l i f i e d " targetNamespace=" h t t p : / /

tempur i . org / ">

5 <s:e lement name=" ContaPrimos ">

6 <s:complexType>

7 <s:sequence>

8 <s:e lement minOccurs=" 1 " maxOccurs=" 1 " name=" param " type="

s : l ong " / >

9 < / s:sequence>

10 < / s:complexType>

11 < / s:e lement>

12 <s:e lement name=" ContaPrimosResponse ">

13 <s:complexType>

14 <s:sequence>

15 <s:e lement minOccurs=" 1 " maxOccurs=" 1 " name=" ContaPrimosResult "

type=" s : l ong " / >

16 < / s:sequence>

17 < / s:complexType>

18 < / s:e lement>

44

45

19 < / s:schema>

20 < / wsd l : t ypes>

21 <wsdl:message name=" ContaPrimosSoapIn ">

22 < w s d l : p a r t name=" parameters " element= " tns:ContaPrimos " / >

23 < / wsdl:message>

24 <wsdl:message name=" ContaPrimosSoapOut ">

25 < w s d l : p a r t name=" parameters " element= " tns:ContaPrimosResponse " / >

26 < / wsdl:message>

27 <wsdl :por tType name=" crivoSoap ">

28 <wsd l :ope ra t i on name=" ContaPrimos ">

29 < w s d l : i n p u t message=" tns:ContaPrimosSoapIn " / >

30 <wsd l :ou tpu t message=" tns:ContaPrimosSoapOut " / >

31 < / wsd l :ope ra t i on >

32 < / wsdl :por tType>

33 <wsd l :b ind ing name=" cr ivoSoap " type=" tns :c r i voSoap ">

34 <soap:b ind ing t r a n s p o r t = " h t t p : / / schemas . xmlsoap . org / soap / h t t p " / >


36 <soap:opera t ion soapAct ion=" h t t p : / / tempur i . org / ContaPrimos " s t y l e ="

document " / >

37 < w s d l : i n p u t >

38 <soap:body use=" l i t e r a l " / >

39 < / w s d l : i n p u t >

40 <wsd l :ou tpu t>

41 <soap:body use=" l i t e r a l " / >

42 < / wsd l :ou tpu t>


44 < / wsd l :b ind ing >

45 <wsd l :b ind ing name=" crivoSoap12 " type=" tns :c r i voSoap ">

46 <soap12:b inding t r a n s p o r t = " h t t p : / / schemas . xmlsoap . org / soap / h t t p " / >


48 <soap12:operat ion soapAct ion=" h t t p : / / tempur i . org / ContaPrimos " s t y l e ="

document " / >

49 < w s d l : i n p u t >

50 <soap12:body use=" l i t e r a l " / >

51 < / w s d l : i n p u t >

52 <wsd l :ou tpu t>

53 <soap12:body use=" l i t e r a l " / >

54 < / wsd l :ou tpu t>


56 < / wsd l :b ind ing >

57 < wsd l : se rv i ce name=" c r i v o ">

58 < w s d l : p o r t name=" cr ivoSoap " b ind ing=" tns :c r i voSoap ">

59 <soap:address l o c a t i o n =" h t t p : / /www. p h y l l i p y . somee .com/ c r i v o . asmx" / >

60 < / w s d l : p o r t >

46

61 < w s d l : p o r t name=" crivoSoap12 " b ind ing=" tns :cr ivoSoap12 ">

62 <soap12:address l o c a t i o n =" h t t p : / /www. p h y l l i p y . somee .com/ c r i v o . asmx" /

>

63 < / w s d l : p o r t >

64 < / wsd l : se rv i ce >

65 < / w s d l : d e f i n i t i o n s >

universidade federal do paraná fileuniversidade federal do paraná douglas tamião rodrigues serino...

Documents