• Nenhum resultado encontrado

Análise do desempenho de invocações à Web Services consumidos por aplicativos móveis

N/A
N/A
Protected

Academic year: 2021

Share "Análise do desempenho de invocações à Web Services consumidos por aplicativos móveis"

Copied!
40
0
0

Texto

(1)

SISTEMAS

LUIZ PAULO LASTA MOÇO

ANÁLISE DO DESEMPENHO DE INVOCAÇÕES À WEB SERVICES CONSUMIDOS POR APLICATIVOS MÓVEIS

TRABALHO DE DIPLOMAÇÃO

MEDIANEIRA 2015

(2)

ANÁLISE DO DESEMPENHO DE INVOCAÇÕES À WEB SERVICES CONSUMIDOS POR APLICATIVOS MÓVEIS

Trabalho de Diplomação apresentado à disciplina de Trabalho de Diplomação, do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas – COADS – da Universidade Tecnológica Federal do Paraná – UTFPR, como requisito parcial para obtenção do título de Tecnólogo.

Orientador: Prof. M.Sc. Ricardo Sobjak.

MEDIANEIRA 2015

(3)

AGRADECIMENTOS

Agradeço primeiramente minha família e minha namorada, em especial meus pais, que em momento algum mediram esforços para que pudesse ter a oportunidade de iniciar e concluir minha formação acadêmica.

Também uma agradeço a meus amigos que souberam me apoiar nestes anos de graduação, agradeço também imensamente ao grupo de jovens que participo e participei durante toda a graduação, também agradeço a Deus por ter me ajudado com saúde e sabedoria nos momentos mais difíceis.

Agradeço também a todos os professores que me auxiliaram na graduação sem medir esforços, seja em sala de aula ou até mesmo nos corredores e por e-mail, e um agradecimento especial ao meu orientador Prof. M.Sc. Ricardo Sobjak, por todo apoio, conselho, dicas e instruções durante o curso e principalmente na execução deste trabalho.

(4)

RESUMO

MOÇO, Luiz Paulo Lasta. Análise de desempenho de invocações à Web Services consumidos

por aplicativos móveis. Trabalho de Conclusão do Curso Superior de Tecnologia em Análise

e Desenvolvimento de Sistemas. Universidade Tecnológica Federal do Paraná. Medianeira, 2015.

Com o crescimento das aplicações desenvolvidas para dispositivos mobile, e a necessidade de interação com Web Services, surge dúvida bastante frequente na hora de se desenvolvê-los é da utilização de tecnologia XML ou JSON para a transferência de informações, qual é mais eficaz, qual tem seu desenvolvimento mais rápido e fácil. Este estudo tem como foco o desenvolvimento de uma aplicação para dispositivo móvel, Android, e de um Web Service em Java que se utilize destas duas tecnologias para que possa ser feita análise do desempenho destas tecnologias.

(5)

ABSTRACT

MOÇO, Luiz Paulo Lasta. Performance analysis of invocations to Web services consumed

by mobile applications. Completion of course work (Technology Analysis and Systems

Development), Federal Technological University of Parana. Medianeira, 2014.

With the growth of application development for mobile devices, and it’s need for interaction with Web Services, often a doubt appears about the time to develop them is the use of XML or JSON technology for transferring information, which is more effective, which is faster and easier to develop. This study focuses on the development of an application for mobile, Android, and a Java Web Service that use these two technologies so in order to analise their performance.

(6)

LISTA DE FIGURAS

Figura 1 - Representação da arquitetura da aplicação. ... 20

Figura 2 - Diagrama de classes da aplicação. ... 20

Figura 3 - Listagem de Parceiros. ... 24

Figura 4 - Criação de Pedidos. ... 24

Figura 5 - Listagem de Produtos. ... 25

Figura 6 - Tela de edição ou adição de Pedido Produto. ... 25

Figura 7 - Cadastro de Parceiros... 25

Figura 8 - Tela para escolha do tipo de sincronização. ... 26

Figura 9 - Tela para escolher a ação de sincronização. ... 26

Figura 10 – Gráfico do tempo de envio (a) e recebimento (b) dos parceiros para o servidor a partir do dispositivo móvel. ... 30

Figura 11 - Gráfico do tempo de envio (a) e recebimento (b) dos produtos para o servidor a partir do dispositivo móvel. ... 31

Figura 12 - Gráfico do tempo de envio (a) e recebimento (b) dos pedidos para o servidor a partir do dispositivo móvel. ... 32

(7)

LISTA DE QUADROS

Quadro 1- Exemplo de XML. ... 16

Quadro 2 - Exemplo de JSON. ... 17

Quadro 3 - Implementação para envio de informações utilizando-se JSON. ... 26

Quadro 4 - Implementação para envio de informações utilizando-se XML. ... 27

Quadro 5 - Implementação para recebimento de pedidos utilizando -se JSON. ... 28

Quadro 6 - Implementação para recebimento de pedidos utilizando -se XML. ... 28

Quadro 7 - Método de Post utilizando JSON. ... 29

(8)

LISTA DE TABELAS

Tabela 1 - Representação dos métodos utilizados no Web Service. ... 21 Tabela 2 - Representação dos testes. ... 23 Tabela 3 - Tabela representando o tempo gasto na leitura do banco Postgres e gravação no banco SQLite ... 32 Tabela 4 - Tabela representando o tempo gasto na leitura do banco SQLite e gravação no banco Postgres ... 32

(9)

SUMÁRIO 1 INTRODUÇÃO ... 9 1.1 OBJETIVO GERAL ... 10 1.2 OBJETIVOS ESPECÍFICOS ... 10 1.3 JUSTIFICATIVA ... 11 2 REFERENCIAL TEÓRICO ... 12 2.1 ANDROID ... 12 2.1.1 SQLite ... 12 2.2 WEB SERVICE ... 13 2.2.1 REST ... 14 2.3 REPRESENTAÇÃO DE DADOS ... 14 2.3.1 XML ... 15 2.3.2 JSON ... 16 2.4 POSTGRES ... 18 3 MATERIAL E MÉTODO ... 19 3.1 DESCRIÇÃO DO PROJETO ... 19

3.2 DESCRIÇÃO DA APLICAÇÃO ANDROID ... 21

3.3 DESCRIÇÃO DO WEB SERVICE ... 21

3.4 EXECUÇÃO DOS TESTES ... 22

4 RESULTADOS E DISCUSSÃO ... 24 4.1 APLICATIVO ANDROID ... 24 4.2 TRANSFERÊNCIA DE DADOS ... 29 5 CONSIDERAÇÕES FINAIS ... 34 5.1 CONCLUSÃO ... 34 5.2 TRABALHOS FUTUROS ... 35 6 REFERÊNCIAS BIBLIOGRÁFICAS ... 36

(10)

1 INTRODUÇÃO

Com a evolução das tecnologias para desenvolvimento de sistemas e o surgimento de novos produtos de software, cresce a necessidade de integrar serviços mantidos em sistemas legados dentro de uma instituição. A interoperabilidade entre sistemas é um fator importante para o bom funcionamento do negócio, seja no atendimento às crescentes necessidades internas da empresa, ou à adequação de fatores externos, que levam à necessidade de integração com serviços fornecidos por terceiros.

Neste sentido, surgiu a tecnologia de Web Services, com a finalidade de resolver o problema de interoperabilidade entre sistemas diferentes, seja de linguagens de programação, plataforma ou meio de disponibilização. Segundo a W3C (2004) “Web Services fornecem um meio padrão de interoperabilidade entre diferentes aplicações de software, rodando em uma variedade de plataformas e/ou frameworks”. O objetivo do Web Service é fazer com que as aplicações se comuniquem por meio da Web, utilizando uma padronização de dados e invocação de serviços.

As primeiras tecnologias de Web Service foram construídas utilizando o protocolo SOAP (Simple Object Access Protocol) na comunicação. O SOAP é um protocolo simples para troca de informações baseado em XML, que consiste em 3 partes: primeira parte é um envelope que define o que há na mensagem e como processá-la, a segunda é um conjunto de regras de codificação para expressar as instâncias dos tipos de objetos definidos pelo aplicativo, e a terceira é uma convenção para representar chamadas de procedimento remoto e respostas. O protocolo SOAP pode ser utilizado junto a outros protocolos tais como HTTP (Hypertext

Transfer Protol) e HTTPS (Hypertext Transfer Protocol Secure) (W3C, 2000).

Outra concepção para disponibilização de Web Services está baseada no estilo arquitetural REST (Representational State Transfer), o qual tem o princípio de funcionamento com base no protocolo HTTP. Na concepção do REST, os serviços são vistos como recursos, que podem ser manipulados por métodos semelhantes às ações CRUDs (Create, Retrive,

Update e Delete). Um recurso normalmente é representado por uma URL (Universal Resource Locator) como, http://www.utfpr.edu.br/profesores. Assim, pode-se visualizar que o recurso

“professores” possui uma representação e pode ser manipulado com os métodos do próprio protocolo HTTP, que basicamente são GET, POST (KALIN, 2009), entre outros métodos.

Dispositivos móveis são aparelhos que podem ser transportados de maneira fácil e, alguns podem ter uma capacidade de processamento um tanto limitada, já outros, possuem

(11)

capacidade de processamento equivalentes a microcomputadores de mesa, porém com o benefício de serem menores. Estes dispositivos ganharam importância devido a facilidade que os mesmos possuem de criarem uma apresentação, acessarem e-mail, conectarem-se a redes sociais, e até mesmo realizar tarefas sem a necessidade de se deslocar à empresa e utilizar um microcomputador, já que possuem capacidade suficiente para muitas rotinas. Com a popularização dos dispositivos móveis surgiu o Android, um sistema operacional que tem se popularizado por ser de baixo custo e de fácil operacionalidade. De acordo com os mantenedores do projeto, ele está presente em mais de um bilhão de smartphones e tablets no mundo (ANDROID, 2014).

Também há a necessidade da grande troca de informações, por isto da utilização de Web

Services junto à plataforma Android, visto que se utilizando destas duas tecnologias o cliente

com seu aplicativo rodando no Android poderá obter dados através destes Web Services desde que esteja conectado à Internet, podendo assim por exemplo realizar uma consulta de preços dos produtos por ele vendido, desde que sua empresa tenha um Web Service e a aplicação possa consumi-lo.

Este trabalho tem como objetivo avaliar o desempenho do processo de invocação de

Web Services desenvolvidos na linguagem Java utilizando as abordagens baseadas no protocolo

REST e consumidos por clientes de dispositivos móveis da plataforma Android. Será avaliado este Web Service nos dois tipos de representações produzidos, XML e JSON.

1.1 OBJETIVO GERAL

Analisar o desempenho de invocações à Web Services consumidos por aplicativos móveis.

1.2 OBJETIVOS ESPECÍFICOS

 Implementar um Web Service baseado no estilo REST com diferentes implementações, uma XML e uma JSON;

(12)

 Avaliar os resultados das requisições e comparar o desempenho das diferentes implementações.

1.3 JUSTIFICATIVA

Atualmente as empresas que possuem representantes de vendas realizando trabalho externo realizam os pedidos em seus smartphones ou tablets e necessitam enviar estas informações para que sejam então registradas estas vendas, ou receber informações atualizadas, como parceiros e produtos.

As aplicações que são feitas nos dispositivos móveis Android podem ter acesso ao banco de dados SQLite, nativo no Android, que é capaz de armazenar estas informações. Porém, informações de venda e parceiros, por exemplo, ficam em seus dispositivos, neste cenário é considerado interessante a criação do Web Service para realizar a integração dos dados, do dispositivo móvel para o banco de dados da empresa e também o caminho inverso.

Entretanto, antes de se iniciar o desenvolvimento de um Web Service surgem alguns questionamentos, como por exemplo, qual tecnologia usar: REST ou SOAP? Se utilizado REST qual tipo de transporte de dados utilizar: JSON ou XML? Para responder este questionamento levam-se alguns fatores em consideração, qual é mais rápido e qual possui tempo de desenvolvimento menor.

Diante destas dúvidas surgiu a oportunidade de desenvolver o estudo para tentar sanar estes questionamentos, utilizando-se da tecnologia de Web Service REST para integrar sistemas e também de dispositivos moveis para obtenção e envio de dados verificaremos como cada tecnologia irá se comportar.

(13)

2 REFERENCIAL TEÓRICO

Neste capítulo será abordado o referencial teórico sobre as tecnologias Android e Web

Service utilizadas para o desenvolvimento deste trabalho.

2.1 ANDROID

O Android é um sistema operacional personalizável e fácil de usar que move mais de um bilhão de dispositivos ao redor do mundo, desde smartphones e tablets a relógios, televisores, carros e, em breve, ainda mais (ANDROID, 2015).

As aplicações utilizadas em Sistemas Operacionais Android são escritas em linguagem de programação Java, “O Java é uma linguagem orientada a objetos (OO). Não é como antigamente, quando tínhamos compiladores antiquados e criávamos um arquivo-fonte monolítico com uma pilha de procedimentos” (Sierra & Bates, 2010, p. 9), e são executadas em uma máquina virtual chamada Dalvik. Segundo Lecheta (2010):

Ao desenvolver aplicações para o Android você vai utilizar a linguagem Java e todos os seus recursos normalmente, mas depois que o bytecode (.class) é compilado ele é convertido para o formato .dex (Dalvik Executable), que representa a aplicação do Android compilada. Depois disso, os arquivos .dex e outros recursos como imagens são compactados em um único arquivo com a extensão .apk (Android Package File), que representa a aplicação final, pronta para ser distribuída e instalada.

Logo é possível utilizar código JAVA, para trabalhar com o Android, e com o auxílio da SDK (Software Development Kit), transformar este código em código executável em aplicativos Android.

2.1.1 SQLite

SQLite é um banco de dados relacional embutido open source, lançado em 2000, projetado para fornecer o gerenciamento de banco de dados sem sobrecarga que muitas vezes

(14)

ocorrem com sistemas dedicados de gerenciamento de banco de dados relacionais. Tem a reputação de ser altamente portátil, fácil de usar, compacto, eficiente e confiável (Owens, 2006). A plataforma Android traz nativo o SQLite, com isto o desenvolvedor pode criar o banco de dados, criar tabelas e manipular os dados através de comandos SQL (Structured Query Language) padrões como select, insert e update. Pode-se buscar dados dentro de um banco de dados utilizando o comando conhecido como select ou query, podendo envolver uma envolver uma ou mais tabelas, podendo determinar também a coluna, cada comando é encerrado pelo símbolo “;” (Aditya & Karn, 2010).

Com isto o desenvolvedor não precisa mais focar seu tempo de desenvolvimento em maneiras de persistir os dados, como por exemplo em arquivos de texto, visto que o Android traz também bibliotecas nativas para realizar o gerenciamento do SQLite, fazendo com que a manipulação de informações, seja inserção, deleção ou alteração de dados mais rápida e menos custosa ao desenvolvedor.

Porém, caso o desenvolvedor julgue necessário existem API’s (Application

Programming Interface) próprias para manipulação de dados para Android no Java, como por

exemplo, OrmLite, SugarORM, GreenDAO eActive Android que trabalham similar ao uso do Hibernate para aplicações Java Desktop ou Web.

2.2 WEB SERVICE

Web Services são soluções utilizadas para integração de sistemas e comunicação entre

aplicações diferentes. Com esta tecnologia é possível realizar a integração de uma tecnologia nova com outra já existente, “Os Web Services fazem parte de soluções utilizadas na integração de sistemas e na comunicação entre aplicações de arquiteturas ou linguagens diferentes”

Os Web Services se utilizam de tecnologia de XML (Extensible Markup Language) e JSON (JavaScrip Object Notation) para transferência de informações podendo assim cada aplicação se utilizar de uma linguagem e podem transmitir esta informação através de XML ou JSON.

O objetivo dos Web Services é torna-los disponíveis na Internet para que seja possível obter informações e/ou enviar informações utilizando-se do protocolo HTTP, os métodos Post,

(15)

2.2.1 REST

A tecnologia REST (Representational State Transfer) define um protocolo Cliente/Servidor sem estado, ou seja, nem o cliente nem o servidor precisam guardar informações dos estados das mensagens, como por exemplo, em aplicações baseadas no protocolo HTTP guardam cookies, pois as mensagens já contêm toda informação necessária para compreensão da requisição feita pelo cliente ou servidor.

O REST se utiliza do protocolo HTTP (Post, Get, Put, Delete) para realizar suas operações. Com frequência estas operações são combinadas com operações CRUD, para persistência de dados.

No REST cada recurso é unicamente direcional, ou seja, identificado por meio de sua URI (Uniform Resource Identifier), onde cada recurso é identificado por um conjunto de caracteres, no entanto quando buscado uma URI o servidor pode enviar-lhe informações sobre vários recursos (RICHARDSON & RUBY, 2007, p.84).

Web Services REST exigem pouca infraestrutura além de HTTP padrão, suportado pela

maioria dos linguagens de programação e plataformas. Web Services REST são simples e eficaz, porque o HTTP é a interface mais amplamente disponível, e é bom o suficiente para a maioria das aplicações. Em muitos casos, a simplicidade de HTTP simplesmente supera a complexidade de a introdução de uma camada de transporte adicional .

Com isto, é possível identificar e separar cada recurso, de forma com que pode-se acessar diversos recursos, cada um terá seu identificador, e poderá executar ações especificas de acordo com a necessidade.

2.3 REPRESENTAÇÃO DE DADOS

É possível armazenar informações através de imagens, sons, lembranças, porém computadores necessitam de representações definidas de dados para que possam compreender o que está sendo passado ao mesmo. Portanto serão utilizados neste trabalho XML e JSON.

(16)

2.3.1 XML

É uma linguagem de extensível de marcação genérica, esta é capaz de descrever diversos tipos de dados, tendo como principal objetivo a facilidade de compartilhamento de informação por meio da Internet.

A principal característica do XML é sua capacidade de criar uma estrutura única conhecida por diversas linguagens, como se pode observar no Quadro 1, na estrutura de um pedido.

É uma linguagem que pode ser utilizado para descrever os dados virtualmente onde quer que exista uma necessidade para armazena-los, especialmente onde ele possa precisar ser consumida por mais de um aplicativo, XML é uma boa maneira de descrevê-los (FAWCETT; QUINN; AYERS, 2012).

XML é um conjunto de regras para projetar formatos de texto que permitem estruturar seus dados. XML não é uma linguagem de programação, e não é preciso ser um programador ou conhecedor de linguagem de programação para usá-la ou aprendê-la. XML torna mais fácil para um computador para gerar dados e ler dados (W3C, 2015).

Um elemento em XML é marcado pela tag inicial “<” e pela tag final “/> “ como XML, é uma linguagem de marcação, fica fácil para haver interoperabilidade dos dados, apenas precisando a aplicação que for utilizar conhecer estas marcações necessárias, para poder escrever em um arquivo XML ou ler de um arquivo XML.

(17)

Quadro 1 - Exemplo de XML. Fonte: Autoria própria.

2.3.2 JSON

Uma notação de objetos JavaScript é uma formatação leve de troca de dados, de fácil leitura e escrita para seres humanos e de fácil interpretação e geração para máquinas. JSON é

(18)

um formato de texto independente de linguagens pois usa convenções que são similares às linguagens C, C++, C#, Java, JavaScript, Perl, Python.

Quanto a conversão de JSON e as muitas linguagens que fazem não nativamente, estas possuem objetos e matrizes, as chaves que compõem o texto JSON, são tudo o que é necessária para interpretar se existem coleções ou listas ordenadas e aplicar todos os valores em uma forma dessa língua (SMITH, 2015). É possível observar na estrutura do Quadro 2 um pedido utilizando representação JSON.

Quadro 2 - Exemplo de JSON. Fonte: Autoria própria.

(19)

2.4 POSTGRES

SGBD (Sistemas Gerenciados de Banco de Dados), são programas que servem para que o usuário possa acessar dados sem que precise conhecer a estrutura do banco, ou como os arquivos ficam distribuídos no disco do computador.

“Um sistema de gerenciamento de banco de dados é a ferramenta que os computadores usam para obter o processamento e o armazenamento organizado dos dados” (NORTON, 1996, p. 371). “No coração de um SGBD está um programa chamado gerenciador de banco de dados” (NORTON, 1996, p. 373).

Postgres que é um sistema poderoso banco de dados open source objeto-relacional. Ele tem mais de 15 anos de desenvolvimento ativo e uma arquitetura comprovada que ela ganhou uma forte reputação de confiabilidade, integridade de dados e correção. Ele é executado em todos os principais sistemas operacionais, incluindo Linux, UNIX e Windows (PostgreSQL: About, 2015).

Com o Postgres foi possível realizar as inserções para testes e também realizar consultas para verificar se a transmissão das informações foi realizada e se foram realizadas com as informações corretas.

(20)

3 MATERIAL E MÉTODOS

Para desenvolvimento trabalho, foram utilizadas as seguintes tecnologias:

 IDE (Integrated Development Environment) Eclipse, versão Kepler: Ferramenta para desenvolvimento do aplicativo Android e do Web Service;

 JDK (Java Development Kit), versão 7: ambiente de compilação e execução do código Java;

 SDK (Software Devlopment Kit), versão 19: Ferramenta disponibilizada pela Google para compilação dos aplicativos para Android;

 Jackson: API utilizada para realizar as conversões de objetos do tipo Java para XML e JSON, e também realiza a chamada de Web Service no dispositivo móvel;

 RestTemplate: API utilizada para realizar a transferências das informações para o Web Service quando utilizado da representação JSON.

Foi desenvolvido um aplicativo Android para realização dos testes de invocação dos

Web Services, que consiste em um cadastro de agendamentos, no qual o usuário armazena estas

informações no banco de dados SQLite, nativo do Android, e um Web Service que recebe estas informações através de dois métodos similares, sendo um com implementação para XML e outro com implementação para JSON.

3.1 DESCRIÇÃO DO PROJETO

Na Figura 1 é possível observar a representação da estrutura física e lógica de interação entre os serviços implementados para realização do estudo. Foram criados dois agentes, um rodando sobre dispositivo móvel e outro sobre um servidor central, que baseados em uma arquitetura cliente/servidor. A comunicação ocorre por meio de uma rede de comunicação sobre o protocolo TCP/IP. O servidor disponibiliza um Web Service para comunicação com os clientes dispositivos móveis. Cada agente possui o seu próprio banco de dados, o servidor, centralizando todas as informações, e os dispositivos móveis para armazenar apenas os dados de sincronismo.

(21)

Figura 1 - Representação da arquitetura da aplicação. Fonte: Autoria própria.

Na Figura 2 é apresentado o diagrama de classes da aplicação, no qual é possível observar as 4 classes que representam sua abstração: Produto, Parceiro, Pedido e PedidoProduto. A partir dessas classes, gerou-se as tabelas em banco de dados, que são utilizadas para armazenar os dados para as sincronizações entre Web Service e o aplicativo Android.

Figura 2 - Diagrama de classes da aplicação. Fonte: Autoria própria.

(22)

3.2 DESCRIÇÃO DA APLICAÇÃO ANDROID

A aplicação Android baseia-se em um controle de vendas, no qual o usuário mantém em sua base de dados os clientes e produtos, que são obtidos por meio da sincronização com o Web

Service. No aplicativo pode-se criar pedidos para os diversos clientes comerciais. Os pedidos

podem conter vários produtos diferentes. As informações de novos pedidos ficam armazenados no banco de dados do dispositivo móvel e, posteriormente, sincronizados com o Web Service. Para transferência dos dados entre o dispositivo móvel e o servidor, os dados foram representados em formatos XML e JSON.

Para transformar os objetos em formato XML, foi utilizada a API Jackson, que gera uma String com o conteúdo do objeto Java, para que esta String possa então ser encapsulada na requisição que será feita ao Servidor através da API HTTP do Java.

Para transformar os objetos em formato JSON, foi utilizada atribuído a variável do tipo RestTemplate, que irá fazer a transferência das informações, uma implementação da API Jackson, que é a responsável por realizar a conversão dos objetos Java em representação JSON.

3.3 DESCRIÇÃO DO WEB SERVICE

O Web Service é baseado no estilo arquitetural REST. Implementou-se dois métodos para obtenção e envio das informações. Estes métodos baseiam-se nas representações REST e XML. Estas implementações foram realizadas sem a utilização de APIs de terceiros, foram usados apenas métodos que o Java, proporciona para disponibilização dos serviços Web.

Tabela 1 - Representação dos métodos utilizados no Web Service.

Caminho da URI

Classe do Recurso Método

HTTP

Descrição

/parceirosXML ParceiroResourceXML GET Receber todos os parceiros utilizando-se a tecnologia XML.

/parceirosXML ParceiroResourceXML POST Enviar todos os parceiros utilizando-se a tecnologia XML.

/parceiros ParceiroResource GET Receber todos os parceiros utilizando-se a tecnologia JSON.

/parceiros ParceiroResource POST Enviar todos os parceiros utilizando-se a tecnologia JSON.

(23)

/pedidosXML PedidoResourceXML GET Receber todos os pedidos utilizando-se a tecnologia XML.

/ pedidosXML PedidoResourceXML POST Enviar todos os pedidos utilizando-se a tecnologia XML.

/parceiros ParceiroResource GET Receber todos os parceiros utilizando-se a tecnologia JSON.

/parceiros ParceiroResource POST Enviar todos os parceiros utilizando-se a tecnologia JSON.

/produtosXML ProdutoResourceXML GET Receber todos os produtos utilizando-se a tecnologia XML.

/produtosXML ProdutoResourceXML POST Enviar todos os produtos utilizando-se a tecnologia XML.

/parceiros ProdutoResource GET Receber todos os produtos utilizando-se a tecnologia JSON.

/parceiros ProdutoResource POST Enviar todos os produtos utilizando-se a tecnologia JSON.

3.4 EXECUÇÃO DOS TESTES

Os testes foram realizados utilizando um aparelho Sony Xperia Z3 compact, numa rede local com 5 dispositivos conectados, o servidor de aplicação ficou hospedado em um notebook Dell Inspiron com 6 GB de memória RAM e um processador de 4 núcleos com 1.8Ghz de processamento.

Os testes foram executados de forma que sempre que fosse enviado ou recebida uma determinada carga utilizando-se a tecnologia JSON, logo em seguida era realizado o mesmo teste com a tecnologia XML.

Os testes ocorreram com 10 repetições cada teste, onde foi enviado e recebido 50, 250, 1000 e 5000 objetos. Desta forma foram realizadas 10 repetições de envio de 50 parceiros utilizando a tecnologia JSON e 50 parceiros utilizando a tecnologia XML, e assim sucessivamente até que todos fossem enviados e recebidos Parceiros, Produtos e Pedidos, tendo realizado estes testes serão descritos no trabalho as médias do envio e recebimento de cada uma destas situações.

Estes tempos descritos estão descontados os tempos de leitura e gravação em banco de dados, visto que os SGBDs, possuem cache e a primeira leitura seria mais lenta que as demais, portanto foi utilizado para testes apenas os tempos de conversão dos objetos e envio para o dispositivo móvel ou para o Web Service.

Os testes foram realizados em uma rede doméstica, onde possuía 5 dispositivos conectados, entre eles, computadores, notebooks e outros dispositivos móveis, esta rede local

(24)

estava por sua vez conectada à Internet, e os 5 aparelhos a ela conectadas estavam utilizando a Internet.

É possível observar na Tabela 2 uma exemplificação de como foram realizados os testes, para cada combinação, foi realizado um teste utilizando-se da tecnologia JSON e outros testes utilizando-se da tecnologia XML.

Tabela 2 - Representação dos testes.

Quantidade de Objetos Tipo do Objeto Repetições Tecnologia

50 Parceiro 10 XML 50 Parceiro 10 JSON 250 Parceiro 10 XML 250 Parceiro 10 JSON 1000 Parceiro 10 XML 1000 Parceiro 10 JSON 5000 Parceiro 10 XML 5000 Parceiro 10 JSON 50 Produto 10 XML 50 Produto 10 JSON 250 Produto 10 XML 250 Produto 10 JSON 1000 Produto 10 XML 1000 Produto 10 JSON 5000 Produto 10 XML 5000 Produto 10 JSON 50 Pedido 10 XML 50 Pedido 10 JSON 250 Pedido 10 XML 250 Pedido 10 JSON 1000 Pedido 10 XML 1000 Pedido 10 JSON 5000 Pedido 10 XML 5000 Pedido 10 JSON

(25)

4 RESULTADOS E DISCUSSÃO

Este capítulo contém os resultados obtidos durante o desenvolvimento do Web Service e do aplicativo Android.

4.1 APLICATIVO ANDROID

O aplicativo Android apresenta uma interface intuitiva com uma tela inicial que lista todos os parceiros cadastrados e/ou recebidos pelo Web Service (Figura 3), também existe uma tela para criação dos pedidos (Figura 4).

Figura 3 - Listagem de Parceiros. Fonte: Autoria própria.

Figura 4 - Criação de Pedido. Fonte: Autoria própria.

Nesta tela é possível adicionar os produtos a partir da listagem e editar informações a partir dos produtos do pedido já existente, como pode ser observado na Figura 5 e Figura 6.

(26)

Figura 5 - Listagem de Produtos. Fonte: Autoria própria.

Figura 6 - Tela de edição ou adição de Pedido Produto. Fonte: Autoria própria.

Existe também no aplicativo Android a possibilidade de cadastrar novos Parceiros, na Figura 7 esta a tela onde pode ser feito este cadastro.

Figura 7 - Cadastro de Parceiros. Fonte: Autoria própria.

Há também as telas que possibilitam os envios de informações, dando a possibilidade do usuário escolher entre XML e JSON. Após esta escolha o usuário tem as opções de envio ou recebimento de Parceiro, Produto e Pedido, como se observa abaixo na Figura 8 e Figura 9.

(27)

Figura 8 - Tela para escolha do tipo de sincronização.

Fonte: Autoria própria.

Figura 9 - Tela para escolher a ação de sincronização.

Fonte: Autoria própria.

Nos Quadros 3 e 4 pode-se observar as implementações para envio dos pedidos por meio do aplicativo Android via JSON e XML respectivamente.

Quadro 3 - Implementação para envio de informações utilizando-se JSON. Fonte: Autoria própria.

(28)

Quadro 4 - Implementação para envio de informações utilizando-se XML. Fonte: Autoria própria.

No Quadro 3 é possível observar a implementação do envio de informações por meio da tecnologia JSON. Para isto foi utilizada a API de RestTemplate, a qual possui métodos que auxiliam o desenvolvimento. Neste caso, foi atribuído ao objeto RestTemplate a implementação MappingJackson2HttpMessageConverter da API Jackson.

No Quadro 4 está apresentada a implementação para transferência de dados em XML, na qual foi utilizado o cliente HTTP nativo do Java para envio de informações. Para a conversão de objetos Java em XML utilizou-se a API Jackson. Com estas ferramentas foi montado um objeto do tipo HTTPPost, para que o cliente HTTP faça o envio destas informações ao Web

Service.

Na parte de transferência das informações do Web Service aos clientes, pode-se observar nos quadros5 e 6 as implementações para o recebimento das informações de pedidos via JSON e via XML, respectivamente.

(29)

Quadro 5 - Implementação para recebimento de pedidos utilizando -se JSON. Fonte: Autoria própria.

Quadro 6 - Implementação para recebimento de pedidos utilizando -se XML. Fonte: Autoria própria.

No Quadro 5 é possível observar a implementação do recebimento de pedidos através da tecnologia JSON, onde foi utilizada a API de RestTemplate e da API Jackson com a implementação MappingJackson2HttpMessageConverter, assim como no envio de informações

Já no Quadro 6 se vê o envio das informações via XML e foi utilizada a API URL do Java e também a API Jackson, que neste caso além de realizar a conversão dos objetos XML em objetos Java também foi responsável por realizar a chamado do Web Service.

Nos quadros é possível perceber uma grande diferença na implementação das informações de pedido, pois no envio e recebimento dos pedidos via JSON o acesso é feito direto na lista de Pedidos, já nas manipulações feitas via XML foi necessário criar um objeto, que contém uma lista de pedidos, pois quando usada a tecnologia XML não é possível fazer a manipulação direta via Lista de objetos, mas utilizar este método de criar uma classe que contém uma lista da classe manipulada.

(30)

4.2 TRANSFERÊNCIA DE DADOS

Nos Quadros 7 e 8, estão representadas as implementações de POST, que recebem as informações dos dispositivos móveis, assim como no Android também existe uma diferença na implementação, não podendo apenas receber uma lista de pedidos.

Quadro 7 - Método de Post utilizando JSON. Fonte: Autoria própria.

Quadro 8 - Método de Post Utilizando XML. Fonte: Autoria própria.

No quadro 8 está apresentado o método utilizado para enviar as informações utilizando a tecnologia XML. Para a tecnologia XML se tem uma peculiaridade, pois não é possível o envio de uma lista de objetos de maneira simples como feita em JSON, mas é preciso encapsular esta lista em um único objeto, para que então este único objeto possa ser enviado em formato XML. Já a tecnologia JSON não possui esta limitação para envio de informações.

(31)

Foram executados os testes de transferência de dados entre o dispositivo móvel e o Web Service em REST, no lado servidor.

NURZHAN & PAULSON & REYNOLDS & IZURIETA (2009) identificaram que a utilização de JSON e mais rápida e usa menos recurso que XML, também indicam que JSON e XML possuem vantagens únicas, porém a importância do desempenho e a utilização dos recursos devem ser entendidas na tomada de decisão.

PENG & CAO & XU (2011) os resultados experimentais mostram que JSON possui desempenho melhor do que em XML, sendo serializado e sendo desserializado.

Isso demonstra que os dados representados em formato JSON tendem a ser transferidos de forma mais ágil e que consumam menos recurso que a tecnologia XML.

No primeiro teste, foram transferidos os dados sobre os parceiros enviados (Figura 10a) e recebidos (Figura 10b) pelo dispositivo móvel. Transferiram-se 50, 250, 1000 e 5000 objetos representados em XML e JSON. Percebe-se que há maior agilidade na transferência quando utilizados os dados em formato JSON.

Levando em consideração o envio de 5000 objetos do tipo Parceiro, por exemplo, ao utilizar a tecnologia JSON tempo um tempo médio de 494 milissegundos enquanto ao utilizar a tecnologia de representação XML tempo um tempo médio de 980 milissegundos.

No envio de informações é possível perceber que ao enviar 50 e 250 informações a diferença é quase imperceptível, já quando enviadas 1000 informações o tempo do XML foi mais rápido, 291 milissegundos contra 395 milissegundos, este tempo menor é pouco e pode ter sido gerado por alguma oscilação na rede no momento de se transferir os objetos do JSON, pois quando levado em consideração 5000 objetos temos uma diferença bem maior, e neste momento a representação JSON tem um ganho de aproximadamente 396 milissegundos.

Figura 10 – Gráfico do tempo de envio (a) e recebimento (b) dos parceiros para o servidor a partir do dispositivo móvel.

(32)

Fonte: Autoria própria.

No segundo teste, foram transferidos os dados sobre os produtos enviados (Figura 11a) e recebidos (Figura 11b) pelo dispositivo móvel. Transferiram-se 50, 250, 1000 e 5000 objetos representados em XML e JSON. Percebe-se que há maior agilidade na transferência quando utilizados os dados em formato JSON.

No envio de informações ao enviar 50, 250 e 1000 objetos o a diferença é menor que 100 milissegundos, porém quando analisado o recebimento de 5000 produtos tempos uma diferença de 430 milissegundos, se levarmos em consideração que foi gasto em média 505 milissegundos para se transferir os produtos utilizando JSON, temos então uma diferença de aproximadamente 85%, o que torna a tecnologia XML bastante ineficaz ao comparar com JSON.

Esta mesma análise pode se estender para o envio das informações para o Web Service do dispositivo móvel, porém esta diferença já surge em 250 produtos, uma diferença de 122 milissegundos que é quase o dobro do tempo gasto para enviar se utilizando de JSON que foi de 69 milissegundos.

Figura 11 - Gráfico do tempo de envio (a) e recebimento (b) dos produtos para o servidor a partir do dispositivo móvel.

Fonte: Autoria própria.

No primeiro teste, foram transferidos os dados sobre os parceiros enviados (Figura 12a) e recebidos (Figura 12b) pelo dispositivo móvel. Transferiram-se 50, 250, 1000 e 5000 objetos representados em XML e JSON.

É possível perceber que o JSON é mais eficaz que o XML no recebimento das informações, essa diferença que é de aproximadamente 100 milissegundos.

No envio das informações, pode-se analisar que ao enviar 250 pedidos, as duas tecnologias tiveram um aumento no tempo, gerando uma diferença maior que 1 segundo no

(33)

XML comparando 1000 produtos e 551 milissegundos na tecnologia JSON, também neste teste a tecnologia XML foi mais eficaz que a tecnologia JSON, com uma diferença de aproximadamente 1 segundo no envio de 1000 pedidos, esta diferença pode ter sido causada por uma oscilação na rede do servidor ou do aparelho, visto que em nenhum outro teste obteve-se o resultado de XML mais rápido que JSON.

Figura 12 - Gráfico do tempo de envio (a) e recebimento (b) dos pedidos para o servidor a partir do dispositivo móvel.

Fonte: Autoria própria.

Na Tabela 3 é possível ver o tempo gasto para realizar as consultas no banco de dados Postgres e após o envio gravar no banco de dados SQLite. Na Tabela 4 é possível identificar o caminho inverso: o tempo gasto para realizar a consulta no banco de dados SQLite e gravar no banco de dados Postgres. Os tempos estão expressos em milissegundos.

Tabela 3 - Tabela representando o tempo gasto na leitura do banco Postgres e gravação no banco SQLite

Tecnologia JSON XML

Quantidade 50 250 1000 5000 50 250 1000 5000

Produtos 362,4 1734,3 6518,2 33412,9 353 1698 6730,2 825,8 Parceiros 363,8 1669,1 6519,5 33200,5 423,5 1762,6 7142,9 33003,4 Pedidos 737,1 3312,1 12711,8 63267,1 1787,8 9598,2 36743,2 167959,3

Tabela 4 - Tabela representando o tempo gasto na leitura do banco SQLite e gravação no banco Postgres

Tecnologia JSON XML

Quantidade 50 250 1000 5000 50 250 1000 5000

Produtos 362,4 1734,3 6518,2 33412,9 427,5 703,9 1797,9 4134,8 Parceiros 416,6 706,6 1570,1 4079,6 429,3 1649,3 7071,4 4042,4 Pedidos 1281,1 1711,8 3009,4 7283,5 1391,5 2160,5 4071,6 12451,8

Após análise da Tabela 3 e Tabela 4 é importante salientar a grande diferença de tempo para leitura e gravação em banco de dados comparado com o tempo gasto na transferência

(34)

destas informações. Ao analisar o tempo gasto para enviar 5000 objetos do tipo Produto, do

Android para o Web Service gasta-se em média 155 milissegundos utilizando JSON e 413

milissegundos utilizando XML. Porém observa-se que o processo de gravação destes mesmos objetos no banco de dados Postgres durou em média 6 segundos e 1 segundo e 700 milissegundos nas mesmas tecnologias, respectivamente.

Também esta diferença grande de tempo para leitura e gravação nos bancos de dados PostgreSQL e SQLite é explicada pela diferença de dados na base, pois quanto mais informações nas tabelas, maior o tempo para realizar a consulta e gravação nas mesmas.

(35)

5 CONSIDERAÇÕES FINAIS

Este capítulo aborda as considerações finais sobre o desenvolvimento do trabalho de diplomação.

5.1 CONCLUSÕES

Após o desenvolvimento deste trabalho pode-se verificar que a tecnologia JSON mostrou-se mais eficaz em relação a tecnologia XML. A tecnologia JSON se demonstrou mais rápida em tempo de desenvolvimento, isto sem deixar de mencionar que foi utilizada a API RestTemplate.

A tecnologia JSON se mostrou aproximadamente 7% mais eficaz em relação a tecnologia XML, e em momentos extremos ela se mostrou até mais, valores na casa de 85%, fazendo com que está se tornasse mais rápida na hora de transmitir os arquivos.

Também foi possível identificar que devido a variações na Internet, não é possível realizar uma progressão aritmética onde quanto maior a quantidade de objetos a serem transmitidos maior tempo a transmissão irá levar.

Em situações em que a rede estiver com maior tráfego de dados irá acarretar numa demora como podemos observar na Figura 12, que tem o envio de informações utilizando a tecnologia JSON, maior que o tempo gasto utilizando-se da tecnologia XML.

Baseando-se neste estudo, é possível pode afirmar que ao desenvolver a aplicação

Android e o Web Service utilizando a tecnologia JSON com a API RestTemplate e a API

Jackson, o desenvolvimento foi mais rápido e assertivo do que quando utilizado XML com as bibliotecas HTTP nativa do Java e a API Jackson.

Com isto se conclui que é válida a preocupação e o questionamento sobre qual tecnologia de Web Service utilizar, pois foi possível afirmar que JSON é mais rápido, como se observa nas Figuras 10, 11 e 12. Entretanto, deve-se também observar que o tempo para leitura e gravação das informações, seja no banco de dados Postgres ou SQLite é bem maior que o tempo de transferência dos mesmos dados como é visto nas Tabelas 1 e 2.

(36)

5.2 TRABALHOS FUTUROS

Na abordagem utilizada neste trabalho a construção de Web Services utilizando tecnologia REST se demonstrou mais eficaz se utilizando tecnologias JSON comparado a XML, como trabalho futuro pode ser abordado outra tecnologia de Web Service ou até mesmo a tecnologia REST, porém utilizar formas de segurança.

Também realizar o trabalho se utilizando de rede de Internet ao invés de se utilizar de rede local, também realizar testes ignorando caches que possam ser gerados na rede, trabalhar com diferentes versões de Android e ver se estas versões se comportam da mesma maneira.

Também pode-se realizar trabalhos que estudem a utilização de recursos da máquina, como memória, processamento e leitura ou gravação no disco rígido.

(37)

6 REFERÊNCIAS BIBLIOGRÁFICAS

ANDROID. Disponível em: <http://www.android.com/meet-android/>. Acesso em: 20 mar. 2014. 2014.

FAWCETT, J.; QUINN, L. R. E.; AYERS, D. Beginning XML. Indianapolis: John Wiley & Sons, 2012.

JSON. Disponível em: <http://www.json.org/json-pt.html>. Acesso em 14 ago. 2014, 18:25. KALIN, M. Java Web Services Up and Running. Estados Unidos: O’Reilly Media, Inc., 2009.

LECHETA, R. R. Google Android: aprenda a criar aplicações para dispositiveis móveis

com o Android SDK. 2. ed. São Paulo: Editora Novatec, 2010.

NORTON, P. Introdução à Informática, Pearson Makron Books, 1996. OWENS, M. The Definitive Guide to SQLite. Estados Unidos: Apress, 2006.

PERACCI, R. F.; BESSA, G. M. A. Utilizando web services para intregração de sistemas, Juiz de Fora, 2014.

RICHARDSON, L.; RUBY, S. RESTful Web Services. Estados Unidos: O’Really Media Inc., 2007.

PostgreSQL: About. Disponível em: < http://www.postgresql.org/about/ >. Acesso em: 30 nov. 2015.

SMITH, B. Beginning JSON. California: Apress, 2015.

W3C. Simple Object Access Protocol (SOAP) 1.1. Disponível em:

< http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ > . Acesso em: 19 mar. 2014. 2000. W3C. Simple Object Access Protocol (SOAP) 1.1. Disponível em:

< http://www.w3.org/standards/xml/core > . Acesso em: 26 nov. 2015.

W3C. Web Services Architecture. Disponível em: < http://www.w3.org/TR/ws-arch/ >. Acesso em: 02 fev. 2014. 2004.

(38)
(39)

APÊNDICE A – Dados de tranferência de informações

Tabela 5 - Recebimento de produtos

JSON XML 50 250 1000 5000 50 250 1000 5000 Repetições 10 10 10 10 10 10 10 10 Média Total 413,3 1803,4 6673,5 33918,8 423 1796,7 6950,2 1761,9 Média Sincronização 50,9 69,1 155,3 505,9 70 98,7 220 936,1 Desvio Padrão 40,29 137,95 133,82 697,20 16,57 39,52 129,68 190,60 Variância 1623,41 19029,84 17907,25 486091,36 274,4 1561,81 16817,96 36329,49 CV 2% 1% 1% 0% 4% 2% 2% 11%

Fonte: autoria própria. CV: Coeficiente de variação.

Tabela 6 - Recebimento de Parceiros

JSON XML 50 250 1000 5000 50 250 1000 5000 Repetições 10 10 10 10 10 10 10 10 Média 428,6 1751 6643,8 33693,9 507,8 1869,2 7362,7 37227,8 Média Sincronização 64,8 81,9 124,3 493,4 84,3 106,6 219,8 4224,4 Desvio Padrão 48 47,2 171,4 1054,8 55,8 74,9 565,3 1000,6 Variância 2304 2225,6 29392,6 112629,9 3113,16 5608,16 319591,61 1001245,16 CV 11% 3% 3% 3% 11% 4% 8% 3%

Fonte: autoria própria. CV: Coeficiente de variação.

Tabela 7 - Recebimento de Pedidos

JSON XML 50 250 1000 5000 50 250 1000 5000 Repetições 10 10 10 10 10 10 10 10 Média 2141,5 8998,2 34751,7 176581,1 2082,6 9912,7 37162,6 168978,5 Média Sincronização 354,1 329,4 479,6 1605 294,8 314,5 419,4 1019,2 Desvio Padrão 15,1 129,5 827,3 6264,5 86,9 655,1 1266,9 628,2 Variância 227,8 16778,9 684478,4 39244373,3 7549,4 429104 1605108,4 394608,2 CV 7% 1% 0% 0% 4% 7% 3% 0%

Fonte: autoria própria. CV: Coeficiente de variação.

(40)

Tabela 8 - Envio de Produtos JSON XML 50 250 1000 5000 50 250 1000 5000 Repetições 10 10 10 10 10 10 10 10 Média 413,3 1803,4 6673,5 33918,8 511,2 895,3 2211,4 5031,8 Média Sincronização 50,9 69,1 155,3 505,9 83,7 191,4 413,5 897 Desvio Padrão 40,3 137,9 133,8 697,2 46,5 55,8 267,9 314,2 Variância 1623,41 19029,84 17907,25 486091,36 2161,56 3110,01 71756,44 98699,36 CV 2% 1% 1% 0% 9% 6% 12% 6%

Fonte: autoria própria. CV: Coeficiente de variação.

Tabela 9 - Envio de Parceiros

JSON XML 50 250 1000 5000 50 250 1000 5000 Repetições 10 10 10 10 10 10 10 10 Média 495,2 940,1 1965,5 4668,9 507,8 1869,2 7362,7 37227,8 Média Sincronização 78,6 233,5 395,4 589,3 78,5 219,9 291,3 4224,4 Desvio Padrão 19,3 77,3 203,7 356,6 55,8 74,9 565,3 1000,6 Variância 373,6 5981,3 41483,5 127177,9 3113,16 5608,16 319591,61 1001245,16 CV 4% 8% 10% 8% 11% 4% 8% 3%

Fonte: autoria própria. CV: Coeficiente de variação.

Tabela 10 - Envio de Pedidos

JSON XML 50 250 1000 5000 50 250 1000 5000 Repetições 10 10 10 10 10 10 10 10 Média 1457,6 3740 4486,4 9113,5 1547,7 3778,3 4470,7 13844,5 Média Sincronização 176,5 2028,2 1477 1830 156,2 1617,8 399,1 1392,7 Desvio Padrão 55,4 65,0 146,2 174,0 82,1 65,8 467,0 580,8 Variância 3069,24 4225,2 21381,24 30290,85 6742,41 4334,41 218078,01 337386,45 CV 2% 2% 1% 1% 5% 2% 10% 4%

Fonte: autoria própria. CV: Coeficiente de variação.

Referências

Documentos relacionados

Outras possíveis causas de paralisia flácida, ataxia e desordens neuromusculares, (como a ação de hemoparasitas, toxoplasmose, neosporose e botulismo) foram descartadas,

Figure III. 37: Water vapor-liquid interfacial tension.. 38: Ethanol vapor-liquid interfacial tension. Interfacial tension was calculated using these coefficients in

Diante dos resultados encontrados nesta pesquisa, verificou-se que o espaço articular coxofemoral, assim como a dor articular do quadril não sofrem influência direta

No final, os EUA viram a maioria das questões que tinham de ser resolvidas no sentido da criação de um tribunal que lhe fosse aceitável serem estabelecidas em sentido oposto, pelo

The DCF model using the Free Cash Flow to the Firm (FCFF) method, estimates in the first place the Enterprise Value of the company, that represents the value of all future cash

Our contributions are: a set of guidelines that provide meaning to the different modelling elements of SysML used during the design of systems; the individual formal semantics for

Tiago Carreira, que tomou a palavra para manifestar o seu agrado pelo facto de ter feito parte da Assembleia, e ainda pelo facto de todos os membros da mesma e do executivo

O que significa criar e interagir na esfera social escolar? Essa e muitas outras perguntas ainda nos incomodam quando reconhecemos que a atividade verbal, examinada