Embed Size (px)
DESCRIPTION
Citation preview
MÁRCIO ALEXANDRE S MONTEIRO
RODRIGO ALMEIDA SAMPAIO
PROJETO DE PESQUISA
MOBILE: APLICAÇÃO DE BUSCA UTILIZANDO WEB SERVICE WS-*
E JAVA EM UMA PLATAFORMA ANDROID
SALVADOR2009
MÁRCIO ALEXANDRE S MONTEIRO
RODRIGO ALMEIDA SAMPAIO
PROJETO DE PESQUISA
MOBILE: APLICAÇÃO DE BUSCA UTILIZANDO WEB SERVICE WS-*
E JAVA EM UMA PLATAFORMA ANDROID
SALVADOR2009
Monografia apresentada por Márcio Alexandre S Monteiro e Rodrigo Almeida Sampaio como requisito parcial para aprovação na disciplina Projeto Final.
Orientador: Prof. Osvaldo Requião Melo
CERTIFICADO
Certifico que a presente memória, MOBILE: APLICAÇÃO DE BUSCA UTILIZANDO
WEB SERVICE WS-* E JAVA EM UMA PLATAFORMA ANDROID foi realizada sob
minha direção por Márcio Alexandre S Monteiro e Rodrigo Almeida Sampaio, constituindo o
Projeto Final do Curso do Bacharelado em Informática da Universidade Católica do Salvador
– UCSal
Salvador, 20 de junho de 2009.
Osvaldo Requião Melo
Curso de Bacharelado em Informática
Universidade Católica do Salvador
Salvador
20/06/2009
DEDICATÓRIA
Dedicamos esse trabalho realizado a todas as pessoas que contribuíram direta e
indiretamente e que nos deram força e motivação no decorrer do semestre desde
que iniciamos esse projeto.
AGRADECIMENTOS
Agradecemos primeiramente a Deus, posteriormente a nossa família e aos nossos
amigos que sempre estiveram ao nosso lado, mesmo nas dificuldades do
desenvolvimento do projeto.
RESUMO
Este projeto propõe uma comparação entre dois tipos de Web Services: Ws-* e
REST, construindo uma aplicação em Java para dispositivos móveis com sistema
operacional Android, utililzando o Web Service WS-* para demonstrar o seu
funcionamento e realizar uma comparação prática com uma aplicação exemplo
previamente construída usando o Web Service REST.
Palavras chaves: Android, SOA, Web Services, Java, Dispositivos Móveis.
ABSTRACT
This project proposes a comparison between two types of Web Services: Ws - * and
REST, building an application in Java for mobile devices with operating system
Android, using the Web Service WS - * to demonstrate his operation and to
accomplish a practical comparison with an application example previously built using
the Web Service REST.
LISTA DE FIGURAS
Figura 1.1 - Exemplo de um documento XML.........................................................166
Figura 1.2 - Exemplo do uso de atributos em um XML............................................176
Figura 1.3 - Exemplo de declaração interna de uma DTD.......................................177
Figura 1.4 - Declaração de DTD associada.........18Error: Reference source not found
Figura 1.5 - Estilo de acesso aos serviços com WS-*...............................................21
Figura 1.6 - Fluxo de comunicação do WS-*...........................................................222
Figura 1.7 - Estilo de acesso aos serviços com REST...............................................23
Figura 2.1 - Exemplo de Pager ..................................................................................25
Figura 2.2 - Exemplo de Telefone Celular..................................................................26
Figura 2.3 - Exemplo de PDA.....................................................................................26
Figura 2.4 - Tablet PC Toshiba..................................................................................27
Figura 2.5 - Exemplo de Laptop.................................................................................28
Figura 3.1 - Estrutura de um sistema computacional.................................................37
Figura 4.1 - As camadas da arquitetura Android.......................................................46
Figura 5.1 - Código Java e respectivo XML gerado antes da correção.....................53
Figura 5.2 - Código Java e respectivo XML gerado depois da correção..............Error:
Reference source not found53
Figura 5.3 - Ambiente de desenvolvimento do provedor de serviços........................56
Figura 5.4 - Diagrama de caso de uso.......................................................................57
Figura 5.5 - Diagrama de classes..............................................................................57
Figura 5.6 - Exemplo de protocolo de comunicação com REST...............................59
LISTA DE TABELAS
Tabela 2.1 - Velocidades de CPU típicas..................................................................29
Tabela 2.2 - Sistemas operacionais típicos...............................................................29
Tabela 2.3 - Tamanho típico de memória..................................................................30
Tabela 2.4 - Tamanho típico de disco........................................................................30
Tabela 2.5 - Duração típica de bateria (sob utilização média)...................................31
Tabela 2.6 - Velocidades das portas de conexão......................................................32
Tabela 2.7 - Tamanho de tela....................................................................................33
Tabela 2.8 - Tamanho de teclado..............................................................................34
SUMÁRIO
INTRODUÇÃO..........................................................................................................11
1 WEB SERVICES E SOA....................................................................................13
1.1 SOA......................................................................................................................................... 13
1.4 XML......................................................................................................................................... 14
1.2 SOAP ....................................................................................................................................... 1 9
1.3 WSDL ...................................................................................................................................... 2 0
1.5 WEB SERVICES WS-* ................................................................................................................ 2 0
1.6 WEB SERVICES REST ............................................................................................................... 2 2
1.7 SERVIÇOS ORIENTADOS A RECURSOS E SERVIÇOS ORIENTADOS A ATIVIDADES ........................... 2 3
2 DISPOSITIVOS MÓVEIS ................................................................................... 2 5
2.1 TIPOS DE DISPOSITIVOS MÓVEIS................................................................................................25
2.2 COMPONENTES DE DISPOSITIVOS MÓVEIS..................................................................................28
2.3 MÉTODOS DE CONEXÃO ............................................................................................................. 3 5
3 SISTEMAS OPERACIONAIS .............................................................................37
3.1 DEFINIÇÃO ................................................................................................................................ 37
3.2 COMPONENTES DE UM SISTEMA OPERACIONAL ........................................................................... 39
3.3 SERVIÇOS DE SISTEMAS OPERACIONAIS....................................................................................43
3.4 SISTEMAS OPERACIONAIS EMBARCADOS.....................................................................................44
4 ANDROID...........................................................................................................46
4.1 DEFINIÇÃO................................................................................................................................ 46
4.2 ARQUITETURA............................................................................................................................ 46
4.3 ESTRUTURA DA APLICAÇÃO ANDROID.........................................................................................48
5 O PROJETO.......................................................................................................51
5.1 OBJETIVO E DESCRIÇÃO DO PROJETO.........................................................................................51
5.2 SOLUÇÃO DE INTEGRAÇÃO.........................................................................................................51
5.3 APLICAÇÃO DEMONSTRATIVA......................................................................................................55
5.4 COMPARAÇÃO WS-* E WEB SERVICE REST..............................................................................58
CONCLUSÃO............................................................................................................61
11
REFERÊNCIAS ................................................................................. 62 INTRODUÇÃO
As mudanças nos dispositivos móveis vêm sendo aceleradas, cada vez mais, devido
a tendências econômicas, sociais e tecnológicas, aumentando a participação de
dispositivos móveis no mercado e a busca por novos serviços para esses
dispositivos. O crescimento na aquisição de dispositivos por partes de mercados
emergentes, a evolução da internet, levando a novos padrões de uso e a
convergência de uma diversidade de dispositivos em um dispositivo de uso geral
mais poderoso, são exemplos de tendências econômicas, sociais e tecnológicas,
respectivamente (BANERJEE, 2008).
Segundo Taurion (2008), como não existe uma padronização para os dispositivos
móveis, a situação atual de aplicações para esses dispositivos é bastante
complicada. Com a chegada do sistema operacional Android, ocorrerá uma
diminuição no trabalho de portar uma aplicação para outros dispositivos móveis e
uma diminuição nos custos, já que o Android é um sistema operacional open source
(código aberto), não sendo necessário o pagamento de licença, além de um rápido
avanço no desenvolvimento de aplicações para esse tipo de dispositivo, já que o
código passará a ser desenvolvido de forma aberta.
Muitas vezes, os desenvolvedores não possuem critérios plausíveis para definir qual
tecnologia deve ser utilizada para se criar uma determinada solução, ficando presos
a familiaridades ou preferências que tem por um ou outro modelo e acabam sempre
utilizando esse mesmo modelo, mesmo que não seja o mais indicado. A motivação
de realizar esse projeto partiu da possibilidade de esclarecer um pouco mais sobre
duas tecnologias que acabam sendo utilizadas em situações não indicadas,
acarretando em um trabalho maior na implementação de uma solução.
O objetivo deste projeto é realizar uma comparação entre Web Service WS-* e Web
Service REST, desenvolvendo uma aplicação em Java para um dispositivo móvel
com sistema operacional Android, utilizando o Web Service WS-*, para que a
comparação possa ser realizada de forma prática com o sistema desenvolvido no
projeto anterior, realizado por Fábio de Oliveira Sales e Kecyo Sacramento Barros,
onde foi utilizado o Web Service REST. A aplicação desenvolvida neste projeto
possui as mesmas características (funcionalidades, telas, etc.) da aplicação
12
desenvolvida no projeto anterior, se diferenciando apenas no tipo de web service
utilizado.
O trabalho é composto por cinco capítulos, sendo que os quatro primeiros
apresentam a fundamentação teórica dos assuntos que estão ligados à solução do
problema proposto, como web services, SOA, sistemas operacionais, dispositivos
móveis e Android.
O primeiro capítulo apresenta os conceitos de web services e dos elementos que
estão relacionados ao seu funcionamento, como o protocolo SOAP, o WSDL e o
XML que é base desses documentos. Ainda neste capítulo é definido o conceito de
SOA e de dois tipos de serviços, orientado a recursos e orientado a atividades. O
segundo capítulo engloba os conceitos de dispositivos móveis, abordando os seus
tipos, componentes e métodos de conexão. No terceiro capítulo a abordagem é
relacionada aos sistemas operacionais, definindo o seu conceito, seus componentes
de uma maneira geral e alguns serviços disponibilizados para facilitar a vida dos
programadores. O quarto capítulo apresenta as características do sistema
operacional Android, como a sua definição, arquitetura e estrutura da aplicação
Android. No quinto capítulo é apresentada a solução proposta deste projeto,
especificando a aplicação que foi criada, para dar suporte à comparação entre as
tecnologias, e as ferramentas utilizadas para esta criação e que dão suporte ao seu
funcionamento. Além disso, apresenta a comparação entre os web services REST e
WS-*.
13
1 SOA e Web ServicesEste capítulo mostra o conceito da arquitetura SOA, Web Services e as tecnologias
envolvidas com os dois. Inicialmente é apresentado o conceito de SOA, que será a
arquitetura utilizada para o desenvolvimento do projeto. Em seguida é abordado o
conceito de XML que é a base para a utilização de diversos documentos, como o
SOAP e WSDL. Por fim aborda o conceito de web services e dois tipos de serviços
existentes, orientado a recursos e orientado a atividades.
1.1 SOAA necessidade de criação de aplicações distribuídas (aplicações que executam seus
processos em processadores diferentes) interoperáveis (aplicações que trocam
dados entre si) e fracamente acoplados (com pouca dependência entre seus
módulos) já existe há um tempo e tem sido satisfeita com várias tecnologias como
RPC (Remote Procedure Call) e Web Services, que será abordado posteriormente.
(SILVA, 2008).
Segundo Silva (2008), o último passo desta evolução foi o SOA (Service Oriented
Architeture – Arquitetura Orientada a Serviços), caracterizado por não ser uma
linguagem, middleweare - gerenciador das interações entre aplicações e outros
softwares ou a rede (Internet2 Middleware Initiative, 2008), protocolo, nem formato
de dados. Na verdade o SOA é independente de tecnologia, deixando-a em segundo
plano e tendo como foco principal os processos de negócio, que serão satisfeitos por
serviços implementados por componentes de aplicações.
Segundo Sampaio (2006), SOA é uma arquitetura onde são criadas funções
chamadas de serviços, com pouca dependência, facilitando o reaproveitamento do
que já foi feito. A idéia do SOA é criar serviços, (podem ser criados em qualquer
linguagem, tecnologia ou plataforma) que tenham baixo acoplamento com seus
clientes, atendendo a uma função de negócio específica, recebendo requisições e
respondendo a elas sem detalhar o seu processo, ou seja, sem que o cliente saiba
como ele foi realizado, já que qualquer componente só é utilizado dentro do código
do serviço, sem que clientes tenham acesso. Os serviços não podem depender do
14
estado de componentes externos, sempre executam unidades completas de
trabalho. Na Arquitetura SOA quem disponibiliza um serviço é chamado de provedor
e quem os utiliza de consumidores. Todo serviço possui uma interface publicada
onde um provedor possa acessá-la. Essa interface possui somente as funções
importantes, com um alto nível de abstração, mantendo o baixo acoplamento com os
clientes.
A visão de Silva (2008) aborda brevemente o que antecede a arquitetura SOA,
conceituando o que vem a ser essa nova metodologia, citando suas principais
características. O foco desta visão é definir o que é o SOA, através de suas
características, inclusive deixando claro o que o SOA não é. O conceito de SOA
passado por Sampaio (2006), apesar de ser com um foco diferente, nos leva ao
mesmo entendimento da visão de Silva (2008), porém o foco do segundo é a
abordagem das características do serviço. Quando SOA começou a ser discutido dentro das empresas, era esperada mais
agilidade nos processos e redução de custos com sua utilização. Um dos benefícios
de utilizar SOA é o reaproveitamento das aplicações, facilitando bastante
redesenhar os processos e a integração com o que já existe, acelerando o
desenvolvimento de novas aplicações de negócio, tornando a TI muito mais simples
para as empresas. O SOA, na verdade, é uma metodologia de desenvolvimento que
não está ligado a uma tecnologia específica, mas sim a um conceito, podendo ser
considerada uma evolução da arquitetura orientada a objetos (GANDOLPHO, 2008).
Alguns especialistas comparam o SOA como um lego, onde suas peças vão sendo
encaixadas, mas não deixando a empresa dependente de algum fornecedor
específico, pregando uma filosofia de integração entre diferentes
tecnologias(SOARES, 2007).
Utilizando SOA, as atividades de negócio são feitas por serviços que possuem sua
forma de solicitar e responder bem definidas, não importando a forma que estes
serviços foram implementados, sendo necessário ser seguro, confiável, rápido e
responder aos comandos de forma correta e com qualidade, tornando o SOA
indicado para ambientes de TI com diversos fabricantes envolvidos (NETO, 2006).
1.2 XML
15
A XML (Extensible Markup Language – Linguagem de Marcação Extensível) é uma
linguagem bastante simples e com grande flexibilidade, desenvolvida pelo W3C
(World Wide Web Consortium), para marcação de texto. O que motivou a criação da
XML foram limitações encontradas no HTML (HyperText Markup Language –
Linguagem de Marcação de Hipertexto), já que o mesmo só permite que o autor
utilize determinadas marcas e com o passar do tempo as pessoas passaram a
precisar de novas e específicas marcas, tornando o HTML cada vez mais pesado e
complexo. Ao contrario disso, a XML permite que o autor crie a marca que desejar,
sendo mais extensível (MARCHAL, 2000).
Segundo Deitel e outros (2003), a XML permite que os documentos sejam legíveis
pelas pessoas e possam ser manipulados pelos computadores, já que possui um
conjunto de marcas muito mais poderoso, extensível e flexível comparado ao HTML.
Um dos objetivos da XML é permitir que dados sejam transferidos e manipulados
através da internet de forma fácil e consistente, possibilitando que aplicações com
sistema operacional, plataforma ou linguagem de construção diferente consigam
manusear esses dados (PEREIRA, 2002).
A XML tem como características principais a sua independência dos dados,
separação do conteúdo e sua apresentação. Um documento XML não possui
instruções de formatação, facilitando a análise sintática, fazendo com que a
estrutura XML possa ser utilizada no intercâmbio de dados (DEITEL et al. 2003).
1.2.1 Elementos e atributosA estrutura básica de um documento XML é formada pelos elementos e atributos.
Os documentos XML são compostos de elementos, porém a XML não define os
elementos, deixando o autor flexível para definir os elementos de forma que atenda
as suas necessidades (MARCHAL, 2000).
Segundo Marchal (2000), os elementos de um documento XML são organizados em
árvore, sendo cada elemento um nó desta árvore. Os elementos podem estar
embutidos em outros elementos, e serão denominados filhos do elemento no qual
estiver embutido. Todos os elementos do documento XML serão filhos de um
elemento principal, também conhecido como raiz.
16
Na figura 1.1 pode-se verificar um exemplo de um documento XML, onde “<LIVRO>”
é a raiz. O elemento “<CAPITULO>”, que é filho de “<LIVRO>”, possui o elemento
“<SEÇÃO>” como filho, que é pai do elemento “<PARAGRAFO>”:
Figura 1.1 - Exemplo de um documento XML (Pitts-Mouts e Kirk, 2000, p.153)
Segundo Marchal (2000), os atributos são utilizados para anexar informações extras
aos elementos. Quando os elementos são vazios, eles, geralmente, são colocados
no documento devido ao valor de seus atributos.
Na figura 1.2 pode-se verificar o mesmo documento da figura 1.1, com o elemento
“<LIVRO>” possuindo o atributo “isbn” que representa o número padrão internacional
de livro:
17
Figura 1.2 - Exemplo do uso de atributos em um XML (Pitts-Mouts e Kirk, 2000, p.153)
1.2.2 Definição de tipo de documento (DTD)A DTD realiza a definição da estrutura de um documento, identificando os
elementos, atributos, etc. que podem ser utilizados no documento. A utilização do
DTD não é obrigatória, porém é bastante indicada, pois garante a conformidade do
documento, principalmente em transações business-to-business (B2B), quando eles
precisam ser intercambiados. As DTDs são definidas através da gramática EBNF
(Extended Backus – Naur Form) (DEITEL et al. 2003).
Segundo Deitel e outros (2003), analisadores sintáticos realizam uma leitura no DTD
e verificam se o documento está de acordo com aquela DTD, caso esteja, o
documento é considerado válido. Caso o documento não esteja de acordo, mas
esteja sintaticamente correto, ele é considerado bem formado, porém não será
válido. Todos os documentos válidos são bem formados.
Um documento XML referencia uma DTD na sua declaração de tipo de documento.
Essa declaração pode referenciar DTDs externas ou internas ao documento. Na
figura 1.3 é possível verificar uma referência interna a DTD “myMessage” (DEITEL et
al. 2003).
Figura 1.3 – Exemplo da declaração interna de uma DTD (Deitel e outros, 2003, p.177)
Na figura 1.4 é possível verificar um documento XML que possui uma referência
externa (intro.dtd), no “DOCTYPE”, a DTD “myMessage”, que é o nome do elemento
raiz. O elemento “myMessage” possui um elemento filho denominado “message”
(DEITEL et al. 2003).
18
Figura 1.4 – Declaração de DTD associada (Deitel e outros, 2003, p.178)
1.2.3 Esquemas XMLSegundo Deitel et al. (2003), os esquemas XML, assim como os DTDs, são
utilizados para descrever a estrutura de documentos e podem ser utilizados como
analisadores sintáticos, porém como utilizam sintaxe XML, ao contrário do DTD que
utiliza gramática EBNF, é possível manipulá-los, realizando pesquisas,
transformando em representações diferentes como HTML, acrescentar ou remover
elementos, etc.
1.2.4 Modelo de objeto de documento (DOM)Após serem analisados sintaticamente, os documentos XML são representados em
uma estrutura de árvore na memória. O DOM é uma recomendação padrão,
fornecida pela W3C, para a elaboração dessa estrutura na memória (DEITEL et al.
2003).
Segundo Deitel et al. (2003), os analisadores que seguem essa recomendação são
conhecidos como analisador baseado no DOM, onde os elementos, atributos, se
tornam nodos na árvore DOM. Esses analisadores disponibilizam uma API
(Application Programming Interface – Interface de programação de aplicação),
permitindo o acesso e modificação dos dados de um documento XML através da
manipulação dos nodos da árvore DOM.
1.2.5 Simples API para XML (SAX)Segundo Deitel et al. (2003), a SAX, desenvolvida por membros da mailing list XML-
DEV, foi lançada em maio de 1998 como uma alternativa na análise de documentos
XML que utilizam um modelo baseado em eventos, que se caracteriza por “disparar”
eventos enquanto o documento é analisado.
19
Diferentemente do DOM, os analisadores baseados em SAX, chamam métodos
caso encontrem alguma marcação de abertura ou finalização, por exemplo. Ao invés
de criarem uma estrutura de arvore para armazenar os dados, eles passam esses
dados para a aplicação no momento que são encontrados, melhorando o
desempenho e diminuindo o consumo da memória em relação ao DOM (DEITEL et
al. 2003).
1.3 SOAPAs empresas DevelopMentor, Microsoft e UserLand Software apresentaram, em
1998, ao W3C (World Wide Web Consortium) o protocolo SOAP. A princípio ele
definia uma forma para envio de procedimentos remota XML sobre HTTP, mas por
divergências políticas sua especificação só foi feita no ano seguinte (RECKZIEGEL,
2006).
Mesmo não sendo necessário conhecer o SOAP para se criar e consumir um Web
Service, este protocolo é um dos elementos mais importantes dos Web Services. O
conhecimento sobre o protocolo pode ajudar em alguns problemas com a
interoperabilidade entre plataformas (RECKZIEGEL, 2006).
O SOAP possibilita que dois processos se comuniquem independente do hardware e
da plataforma que estejam, sem nenhum vínculo com software ou linguagem de
programação. A estrutura do protocolo SOAP possui duas partes principais: a
primeira especifica um framework de mensagens, que pode ser um protocolo de
rede, como o HTTP, por exemplo, ou um protocolo de mensagem proprietário pode
servir como transportador do SOAP. A segunda possui dois componentes opcionais:
regras de codificação que expressam instâncias dos tipos de dados que foram
definidos pela aplicação e uma representação de RPCs e respostas (RECKZIEGEL,
2006).
Segundo Dantas (2007), SOAP (Simple Object Acess Protocol) é um protocolo
baseado em XML utilizado para a comunicação entre aplicações num ambiente
distribuído. Foi projetado para chamar aplicações remotas utilizando RPC (Remote
Procedure Call) ou troca de mensagens, sem que exista dependência de ambiente e
linguagem de programação.
O protocolo SOAP precisa ser transportado no corpo de outro protocolo, que na
grande maioria das vezes é o HTTP, que se torna muito conveniente por ser
20
bastante confiável, ser suportado por muitas plataformas e dispositivos e dificilmente
é restringido por algum firewall (SILVA, 2008).
1.4 WSDLSegundo Reckziegel (2006), o WSDL (Web Services Description Language –
Linguagem de Descrição de Web Services) realiza a descrição dos serviços
externos oferecidos por uma aplicação, apontando a localização dos seus serviços,
que já se encontram em um local conhecido da rede, permitindo ao cliente um
acesso confiável. A leitura do WSDL é ainda mais fácil, pois é um documento em
XML. Os documentos WSDL possuem, geralmente, os seguintes componentes (LEE et.
al., 2005):
Service Name – identifica o nome do Web Service;
Port – possui a localização real do Web Service - URL (Uniform Resource
Locator – Alocador de Recursos Universal);
Binding – contém o protocolo de comunicação e o transporte utilizados
pela porta;
Port Type – identifica quais as operações suportadas pelo Web Service;
Messages – possui as mensagens de solicitação e resposta para cada
operação.
1.5 Web Service WS-*As aplicações distribuídas, no final da década de 90, começaram a ser construídas
utilizando HTTP (Hypertext Transfer Protocol – Protocolo de Transferência de
Hipertexto) e XML, mas eram feitas de forma personalizada por cada desenvolvedor,
definindo protocolos próprios que variavam a cada nova implementação e entre as
organizações (SILVA, 2008).
Com a necessidade de padronizar e facilitar a comunicação entre os sistemas e
empresas, foi iniciada a linhagem WS-*, que leva esse nome devido a extensa
quantidade de especificações definidas por grupos de estudos dessa área
(SILVA,2008).
Segundo Silva (2008), no surgimento da linhagem WS-* as suas especificações
teóricas foram feitas de forma muito mais rápida do que as implementações práticas,
gerando um grande material de regras de utilização sem que essas regras tivessem
21
sido utilizadas na prática. Boa parte dessa documentação não foi validada devido ao
extenso uso em aplicações reais e muitas especificações precisaram ser revistas
diversas vezes, para que as regras complexas passassem a ser serviços úteis.
Entretanto o WS-* disponibiliza soluções para qualquer problema imaginável em
arquitetura SOA, mas a grande maioria das aplicações utiliza apenas os recursos
básicos, como SOAP e WSDL.
Com a utilização de SOAP, geralmente, é feita uma requisição HTTP POST,
encapsulando os dados em outro protocolo. (SILVA, 2008). A figura 1.5 mostra como
é feito o acesso aos serviços com WS-*:
Figura 1.5 – Estilo de acesso aos serviços com WS-*. (SILVA, 2008).
O primeiro passo na comunicação é saber onde o serviço desejado está localizado,
realizando uma pesquisa ao UDDI (Universal Description Discovery and Integration –
Descrição Universal, Descoberta e Integração), que é um repositório baseado em
XML, onde os serviços são publicados e consultados. O UDDI é acessado através
de mensagens, liberando o documento de especificação dos serviços chamado de
WSDL (Web Service Description Language). Neste documento são definidas
precisamente, as operações que o serviço disponibiliza, especificando de forma
universal as formas de interação entre clientes e serviços, garantindo que qualquer
cliente que conheça o padrão estabelecido possa se comunicar de forma correta.
Após possuir o WSDL, a comunicação pode ser realizada entre o cliente e o web
service utilizando o SOAP, que é protocolo padrão para a comunicação com essa
linha de web services (SILVA, 2008).
A figura 1.6 ilustra como esse processo é realizado:
22
Figura 1.6 - Fluxo de comunicação do WS-* (Silva, 2008, p. 39)
1.6 Web Service RESTSegundo Silva (2008), o web service REST surgiu de uma proposta da tese de
doutorado de um dos principais autores do protocolo HTTP, Roy Fielding. Essa
tecnologia iniciou com um pequeno conjunto de especificações de fácil
compreensão, instruindo como seriam os serviços dessa linha. Com o tempo a
utilização de REST aumentou e um melhor entendimento ajudou na identificação de
pontos de difícil decisão na arquitetura. Esse aumento na utilização da tecnologia
gerou o aparecimento dos padrões de implementação para cobrir pontos abstratos.
Só após os primeiros sucessos os esforços para especificação precisa e
padronizações começaram, possibilitando a reutilização de idéias, aumentando o
nível de abstração. Devido ao progresso, grupos de estudo do IETF (Internet
Engineering Task Force), que realizam a padronização dos serviços REST, foram
criados (SILVA, 2008).
O web service REST utiliza extensamente os recursos do HTTP, declarando a
operação através dos métodos GET, PUT, POST ou DELETE. Normalmente o
método GET é utilizado para buscar o recurso, PUT para atualizar, POST para
cadastrar, e DELETE para remover, mas essas funções são definidas pelo
desenvolvedor da arquitetura, que além disso estabelece o protocolo de
conversação com os serviços (SILVA, 2008).
23
A figura 1.7 demonstra a forma de acesso aos serviços do Web Service REST:
Figura 1.7 – Estilo de acesso aos serviços com REST (SILVA, 2008).
Segundo Silva (2008), para realizar a troca de mensagens parte-se do princípio que
cada recurso possui uma URI (Uniform Resource Identifier – Identificador Uniforme
de Recursos). Para acessar esses recursos é feita uma chamada para a URI
correspondente ao recurso desejado. Se for utilizado o método GET ou DELETE
(busca e exclusão), apenas o método já é suficiente, pois já define a operação e o
recurso a ser manipulado, caso seja POST ou PUT (cadastro e atualização), precisa
colocar os dados necessários da operação no corpo da requisição.
1.7 Serviços orientados a atividades e serviços orientados a recursosCom a diversificação das topologias de implementações existentes, aumenta a
necessidade de disponibilizar serviços, fazer a integração entre aplicações,
plataformas e empresas, fazendo com que serviços de diversos tipos precisem ser
criados e classificados (SILVA, 2008).
Segundo Silva (2008), existem serviços que são fortemente associados a recursos.
Esses serviços precisam ter os recursos e as manipulações sobre estes recursos
bem definidas, sendo bastante interessante a criação de uma solução utilizando
Web Service REST, explorando as capacidades do protocolo HTTP, conseguindo
uma arquitetura com alta escalabilidade.
Por outro lado, existem serviços que possuem o foco em atividades, como por
exemplo, num processo de compra pela internet onde um serviço emite os pedidos
de compra. Antes de realizar a emissão, o serviço realizará diversas etapas, como
24
notificar o sistema de cobrança, enviar e-mail de confirmação para o usuário, etc.
Essas etapas também podem ser modeladas como recursos, mas isso tornaria o
trabalho muito mais complexo, sendo mais fácil implementar os serviços como
atividades, que é uma característica dos serviços WS-* (SILVA, 2008).
Segundo Silva (2008), pode-se utilizar o Web Service REST ou o WS-* para a
implementação de qualquer serviço, verificando apenas qual deles se aplica melhor
a solução que será desenvolvida.
25
2 Dispositivos MóveisEste capítulo apresenta alguns conceitos a respeito de dispositivos móveis,
abordando os tipos, seus componentes e os métodos de conexão com os mesmos.
2.1 Tipos de dispositivos móveisExistem inúmeros tipos de dispositivos no mercado atualmente, voltados tanto para
os consumidores corporativos quanto para os consumidores em geral. As funções,
portabilidade, e custo variam consideravelmente entre cada um deles. Com essas
diferenças os dispositivos móveis podem ser classificados como dispositivos
RIM/Pagers, telefones celulares, PDAs, Tablet PCs, Pcs Laptops e híbridos (LEE et.
al., 2005). Esses grupos de classificação serão detalhados abaixo:
2.1.1 Dispositivos RIM/PagersEste é um dispositivo eletrônico que foi muito utilizado durante os anos 1980 e 1990.
Ele utiliza transmissões de radio para interligar um centro de controle de chamadas
e destinatários.
Os primeiros pagers funcionavam da seguinte forma: O usuário recebia um bip
sonoro que indicava o recebimento de uma mensagem. Logo após ele deveria
telefonar para o centro de controle de chamadas para receber as mensagens de um
operador. Os pagers mais novos já recebiam mensagens digitais e em alguns
modelos já enviavam também (WIKIPEDIA, 2007?).
É possível visualizar o exemplo de um Pager na figura 2.1:
Figura 2.1 – Exemplo de Pager (WIKIPEDIA, 2007?).
2.1.2 Telefones celularesÉ um dispositivo de computação móvel que inicialmente tinha uma tela pequena e
quase nenhum recurso. Atualmente já dispõe de aparelhos de memória expansível,
tecnologia Bluetooth, suporte ao Java etc. Os aparelhos mais modernos são
26
chamados de Smartphones que alem da funcionalidade básica de telefone tem
funcionalidades dos PDAs (JOHNSON, 2007).
Figura 2.2 – Exemplo de Telefone Celular
2.1.3 PDAsO PDA (Personal Digital Assistant - Assistente Digital Pessoal) é um dispositivo de
tamanho reduzido que foi projetado inicialmente para ser um organizador pessoal
que fazia cálculos. Com a evolução ele ganhou diversas outras funcionalidades,
como ferramentas de produtividade, sincronização de dados, acesso Wi-Fi (Wireless
Fidelity) e outras (QUEIRÓS, 2008).
Figura 2.3 – Exemplo de PDA
2.1.4 Tablet PCsUm Tablet PC pode ser definido como um pequeno notebook, que possui sua tela
com sensibilidade ao toque. Utilizado como um computador de mão, possui
praticidade de inserção de dados. Seu formato se assemelha a uma prancheta, por
27
isso recebe o nome de Tablet PC. A tela possibilita o reconhecimento da escrita do
usuário através de canetas especiais, também utilizadas em palmtops (AYRES,
2007).
Na figura 2.4 é possível visualizar o exemplo de um Tablet PC:
Figura 2.4 – Tablet PC Toshiba (WIKIPEDIA, 2009?).
2.1.5 PCs laptopO PC laptop (também conhecido como notebook) é um computador móvel e leve,
para ser transportado facilmente e utilizado em diversos locais. Normalmente, esse
tipo de dispositivo possui uma tela LCD (cristal líquido) e como dispositivos de
entrada de dados, um mouse e um teclado. O PC laptop possui todos os recursos de
um desktop, diferenciando apenas na sua portabilidade.
Se verificado no dicionário, existe uma pequena diferença no conceito de notebook e
laptop, onde o notebook é considerado, aproximadamente, do tamanho de um
caderno e maior do que um PC Laptop, porém na linguagem popular as duas
nomenclaturas são utilizadas para os mesmos dispositivos (WIKIPEDIA, 2007?).
Na figura 2.5 é possível visualizar o exemplo de um PC Laptop:
28
Figura 2.5 – Exemplo de Laptop (WIKIPEDIA, 2007?).
2.1.6 HíbridosA combinação de algumas funções de certos dispositivos móveis resultou em novos
dispositivos móveis, com funcionalidades sobrepostas, conhecidos como híbridos.
Embora seja possível realizar a combinação de diversas funções, algumas
desvantagens também podem ser encontradas, como por exemplo, o aumento de
tamanho do telefone celular para poder suportar novas funções pode deixar a função
básica de comunicação telefônica menos confortável ou caso o telefone celular
possua um tamanho pequeno, a tela pode ser desagradável para realizar
determinadas funções que eram realizadas em outros dispositivos com telas maiores
(LEE et. al. 2005).
2.2 Componentes de dispositivos móveisOs dispositivos móveis possuem diversos componentes que também são
encontrados nos computadores, como uma CPU, sistema operacional, memória,
disco, baterias e fonte de alimentação, portas de conexão, tela, teclado, mouse e um
conjunto de periféricos (LEE et. al., 2005). Alguns desses componentes serão
descritos.
2.2.1 CPUSegundo Lee et. al. (2005) a CPU possui grande importância para a operação de um
dispositivo móvel. A CPU determina a frequência máxima de leitura e execução das
instruções. De um modo geral, quanto mais rápida for a CPU, mais caro será o
dispositivo móvel, pois o desenvolvimento de CPUs mais avançadas é mais caro. Na
tabela 2.1 é possível observar a velocidade aproximada da CPU para alguns
dispositivos móveis.
29
Tabela 2.1 – Velocidades de CPU típicas (LEE et. al., 2005, p.52).
Tipos de dispositivos móveis Velocidade de CPU típicas
Dispositivo de Pager/RIM 20-40 baseado em 386 Intel
Telefone celular -
PDA 200-400 baseado em XScale da Intel
Tablet PC 1 GHz
PC laptop 1-2 GHz
2.2.2 Sistema Operacional Antes de implementar uma aplicação móvel, é preciso verificar o sistema
operacional do dispositivo para o qual irá desenvolver, pois o ele influencia na
linguagem, ferramentas e tecnologias que o desenvolvedor irá utilizar e no suporte e
manutenção da aplicação (LEE et. al. 2005). Na tabela 2.2 é possível verificar alguns
sistemas operacionais para alguns tipos de dispositivos móveis. Tabela 2.2 – Sistemas operacionais típicos (LEE et. al. 2005, p.53).
Tipos de dispositivo móvel Sistemas operacionais típicos
Dispositivo de Pager/RIM RIM OS
Telefone celular Windows Móbile 2003 Phone Edition, Psion EPOC, Symbian OS
PDA Windows Mobile 2003, Palm OS
Tablet PC Windows XP Tablet Edition
2.2.3 MemóriaSegundo Lee et. al. (2005), a CPU de um dispositivo móvel guarda informações
temporárias e realizar a busca e execução de suas instruções na memória. O ideal é
possuir tanta quanto for possível para se obter um melhor desempenho, mas deve-
se considerar o custo.
Segundo Lee et. al. (2005), nos PDAs, a memória é ainda mais importante, já que o
mesmo não possui disco rígido e depende dessa memória para armazenar dados.
30
Essa característica possibilita uma inicialização mais rápida do dispositivo em
comparação a um computador normal, mas por outro lado, não permite o
armazenamento de dados permanentemente.
Na tabela 2.3 são apresentados alguns tamanhos de memória que normalmente são
encontrados em alguns dispositivos.
Tabela 2.3 – Tamanho típico de memória (LEE et. al. 2005, p.54).
Tipos de dispositivos móveis Tamanho típico de memória
Dispositivo de Pager/RIM 4 MB-16 MB Flash ROM
Telefone celular 56 MB
PDA 64 MB SDRAM; 48 MB Flash ROM
Tablet PC 256 MB 1 DDR SDRAM
PC laptop 1 GB
2.2.4 DiscoNem todos os dispositivos móveis possuem um disco rígido para armazenamento de
dados permanentemente. Os PDAs, em geral, são um exemplo de dispositivo móvel
sem disco rígido, não permitindo que se tenha uma capacidade de armazenamento
com as de um computador de mesa ou laptop. O armazenamento, nesses
dispositivos que não possuem discos, pode ser considerado transitório, onde
geralmente os dados são transferidos para um sistema confiável quando possível.
(LEE et. al. 2005).
Na tabela 2.4 são apresentados tamanhos típicos de discos para dispositivos
móveis.
Tabela 2.4 – Tamanho típico do disco (LEE et. al. 2005, p.54).
Tipos de dispositivos móveis Tamanho típico do disco
Dispositivo de Pager/RIM -
Telefone celular -
PDA -
31
Tablet PC 30 GB
PC laptop 30 – 60 GB
2.2.5 Baterias e energiasSegundo Lee et. al. (2005) as baterias são muito importantes para os dispositivos
móveis, pois como o próprio nome diz, eles precisam de mobilidade, não podendo
ligado à fonte de energia principal constantemente.
Segundo Lee et. al. (2005), a duração da bateria varia de acordo com o dispositivo
móvel, do uso que se faz dele e da tecnologia da própria bateria. Atualmente são
utilizadas baterias de íons de lítio, mas futuramente baterias de polímero de lítio
poderão ser utilizadas, pois são flexíveis e podem ser comprimidas em pequenos
espaços dentro de um dispositivo móvel. Células de combustível também poderá ser
uma opção, pois são muito eficientes e agridem menos o meio ambiente em relação
às baterias atuais.
Na tabela 2.5 pode-se verificar a duração de baterias para alguns dispositivos
móveis.
Tabela 2.5 – Duração típica de bateria (sob utilização média) (LEE et. al. 2005, p.55).
Tipos de dispositivos móveis Duração típica de baterias
Dispositivo de Pager/RIM Semanas
Telefone celular Dias
PDA Horas/Dias
Tablet PC Horas
PC laptop Horas
2.2.6 Portas de conexãoAs portas de conexão estão normalmente ocultas em diversas partes do dispositivo
móvel ou através de uma capa adaptada. Dispositivos como o Tablet PC e PCs
laptop, normalmente, possuem diversas portas de conexão devido a possuírem um
tamanho maior, entretanto os dispositivos menores, normalmente, não possuem
32
portas ou então eles possuem uma capa externa adaptada acrescentando as portas
de conexão.
Na tabela 2.6 são apresentadas velocidades típicas de portas de conexão.
Tabela 2.6 – Velocidades das portas de conexão (LEE et. al. 2005, p.56).
Porta Velocidade típica
Bluetooth 56 -721 Kbps
Firewire 400 Mbps
Infravermelho 4 Mbps
Paralela 50 – 100 Kbps
COM serial 115 – 460 Kbps
USB 1.1 1.5 – 12 Mbps
USB 2.0 1.5 – 480 Mbps
RJ-11 9.6 – 56.6 Kbps
RJ-45 10 – 100 Mbps
Slots de PC Card 10 – 100 Mbps
Segundo Lee et. al. (2005) as portas têm características fundamentais, fazendo com
que cada uma tenha um propósito levemente diferente. A porta infravermelha, por
exemplo, é geralmente utilizada para sincronizar Pocket PC, um PC laptop e um
computador de mesa, tendo a necessidade de os dispositivos estarem próximos um
do outro, pois possui baixo alcance, e em linha reta entre si.
A porta Bluetooth é um modulo de rádio embutido nos dispositivos móveis realizando
a comunicação com outros dispositivos através de ondas de rádio. O seu alcance é
relativamente curto, porém não necessita que os dispositivos estejam em linha reta
entre si.
33
A porta USB (Universal Serial Bus – Barramento Serial universal), pode ser
conectada a um mouse, impressoras, unidades de armazenamento externas e na
sincronização entre dispositivos.
A porta COM serial normalmente é utilizada para a conexão de um mouse, mas
também pode ser utilizada para conectar uma impressora ou unidades de
armazenamento externas.
A porta Paralela normalmente é utilizada para a conexão de impressoras.
Ocasionalmente é utilizada na conexão com dispositivos de armazenamento de
massa.
A porta RJ-11 é utilizada na conexão com linha telefônica. Possui uma velocidade
baixa quando comparada com linhas de rede de alta velocidade, porém funciona em
quase todos os lugares.
A porta RJ-45 é de alta velocidade e permite conexões cabeadas para uma rede.
Normalmente são encontradas em Tablet PCs e PCs laptop, mas não em
dispositivos RIM, telefones celulares e PDAs.
Os slots de PC card são de alta velocidade e possibilitam que placas de rede
conectadas a cabos ou redes sem fio sejam utilizadas no dispositivo móvel.
2.2.7 TelaSegundo Lee et. al. (2005), a grande a maioria, ou até mesmo todos, dos
dispositivos móveis possuem telas planas. A tela é um dos componentes que mais
influencia no peso do dispositivo, quanto maior a tela, maior será o peso do
dispositivo e menor será sua mobilidade.
Na tabela 2.7 são apresentados tamanhos de tela utilizados em alguns dispositivos
móveis. Os dados não devem ser considerados exatos.Tabela 2.7 – Tamanho de tela (LEE et. al. 2005, p.57).
Tipos de dispositivos móveis Tamanho típico de tela
Dispositivo de Pager/RIM 7,62 cm
Telefone celular 3,81 cm
PDA 10,16 cm
Tablet PC 26,42 cm
34
PC laptop 26,42 cm a 40,80 cm
2.2.8 TecladoO teclado padrão com o tamanho 17,78 cm x 45,72 cm é considerado grande para
um adulto digitar confortavelmente e pequeno para não incomodar (LEE et. al.
2005).
Na tabela 2.8 são apresentados tamanhos de teclado para alguns dispositivos
móveis.
Tabela 2.8 – Tamanho de teclado (LEE et. al. 2005, p.58).
Tipos de dispositivos móveis Tamanho típico de teclado
Dispositivo de Pager/RIM Miniatura
Telefone celular Miniatura
PDA De nenhum ao muito pequeno
Tablet PC Médio
PC laptop De médio a tamanho completo
2.2.9 mouse, stylus, caneta e vozOutros mecanismos são utilizados, além do teclado, para a inserção de dados em
dispositivos móveis: o mouse, que normalmente é encontrado em Tablet PCs e PCs
laptop, o stylus e a caneta que são apontadores para escrever e selecionar itens,
muito utilizados em PDAs com tela sensível ao toque e em Tablet PCs. Além desses
mecanismos também é possível passar instruções através da voz, (LEE et. al.
2005).
2.2.10 Periféricos Segundo Lee et. al. (2005), existem diversos acessórios e anexos que podemos
classificar como periféricos. O periférico é um item separado do hardware, porém
muitos já passaram a fazer parte integrante dos dispositivos móveis. São exemplos
de periféricos:
Impressoras
35
Câmeras
Scanners de código de barras
Scanners biométricos
Scanners de localização
Os periféricos normalmente são anexados ao dispositivo móvel, necessitando a
instalação de um driver no dispositivo em que vai ser utilizado. Apesar de
acrescentar funcionalidade ao dispositivo, um periférico pode também dificultar sua
mobilidade, já que interfere na altura e no peso do dispositivo (LEE et. al. 2005).
2.3 Métodos de conexãoSegundo Lee et. al. (2005), a conexão dos dispositivos móveis a uma rede para
enviar e receber informações pode ser feita através de cabos ou até mesmo sem fio.
Estaremos abordando alguns mecanismos para realizar essa conexão.
2.3.1 Com fioSegundo Lee et. al. (2005), existem diversas formas para um dispositivo móvel se
conectar a uma rede através de cabos. Por exemplo:
Conexão de rede direta – é necessário que o dispositivo possua
uma placa de rede. Os Tablet Pcs e PCs laptop, normalmente já
possuem essa placa. Esse tipo de conexão, em geral, possui uma
taxa de transferência dos dados de 10 Mbps ou 100 Mbps.
Cradle – é utilizado na conexão entre um PDA e um computador. O
usuário coloca o PDA no cradle e o mesmo é conectado ao
computador através de um cabo, possibilitando a conexão entre os
dois dispositivos.
Acesso discado – é umas das formas mais antigas para a conexão
em uma rede. É necessário que o dispositivo possua um modem
embutido ou externo. Esse tipo de conexão, em geral, transfere
dados a 56 Kbps.
2.3.2 Sem fioSegundo Lee et. al. (2005), alguns dispositivos móveis utilizam conexões de rede
sem fio para se comunicar. Existem diversos mecanismos para que estes
dispositivos possam realizar essa comunicação. Por exemplo:
36
Redes de Celular – as redes de celulares possuem conjuntos de
áreas com cobertura de rádio conhecida como células. Essas áreas
têm um tamanho limitado e enquanto o usuário estiver dentro dela,
conseguirá enviar e receber dados. Caso o usuário se desloque de
uma célula para outra, a rede, automaticamente, passa o usuário
para uma nova célula, no caso de ser uma boa cobertura, sem que
a transmissão ou recebimento de dados seja interrompido.
Redes de dados – da mesma forma que as redes de celulares, as
redes de dados disponibilizam serviços de dados sem fio, com a
vantagem de possuir uma cobertura maior do que a de celulares,
porém com a velocidade de transmissão muito menor.
Bluetooth – essa tecnologia permite a conexão a diversos
dispositivos eletrônicos, como celulares, impressoras, PCs laptop.
Como um mecanismo para conexão sem fio, o Bluetooth tem o
objetivo de eliminar os cabos, porém os dispositivos precisam estar
próximos para funcionar bem.
Rede local sem fio – normalmente são utilizadas em escritórios,
possibilitando que usuários estejam conectados em qualquer lugar
do edifício. Esse tipo de rede já é utilizado em locais aberto ao
público, como hotéis e aeroportos para fornecer acesso sem fio à
internet.
Redes de satélite – o uso mais conhecido desse tipo de rede é o
GPS (Global Positioning System – Sistema de posicionamento
Global) que utiliza satélites do departamento de defesa dos Estados
Unidos. O dispositivo móvel precisa ter um receptor de GPS que
capta os sinais dos satélites para identificar o posicionamento
daquele dispositivo. É necessário existir uma linha de visão entre o
dispositivo e o satélite.
37
3 Sistemas OperacionaisEste capítulo inicia com a definição do que é um sistema operacional, em seguida
aborda os seus componentes e os serviços que são disponibilizados por um sistema
operacional na tentativa de facilitar a utilização dos usuários.
3.1 DefiniçãoUm sistema operacional é a interface entre o usuário e o hardware do computador,
fornecendo um ambiente, para a execução de programas, conveniente. Um sistema
operacional é de grande importância e está presente em praticamente todos os
sistemas de computação. Um sistema de computação possui, basicamente, quatro
componentes: hardware, sistema operacional, programas aplicativos e usuários. Na
figura 3.1 podemos ver de forma abstrata esses componentes (SILBERSCHATZ E
OUTROS, 2000).
Figura 3.1 - Estrutura de um sistema computacional (Silberschatz e outros, 2000, p.3)
Segundo Silberschatz e outros (2000), a CPU (Central Processing Unit – Unidade
Central de Processamento), memória e dispositivos de entrada e saída compõem,
basicamente, o hardware, disponibilizando os recursos básicos de computação. Os
38
programas aplicativos determinam a forma de utilização dos recursos de hardware
para a solução dos problemas do usuário. Como pode existir mais de um usuário
(pessoas, máquinas, outros computadores) ou mais de um programa aplicativo
tentando resolver problemas diferentes, o sistema operacional gerencia a utilização
do hardware entre eles, fornecendo um ambiente para a utilização adequada dos
recursos.
Segundo Silberschatz e outros (2000), o sistema operacional pode ser considerado
como um alocador de recursos. Como um sistema de computação possui muitos
recursos para a solução de problemas, é necessário que o sistema operacional
gerencie a alocação desses recursos a determinados programas e usuários
conforme seja necessário. Como pode haver mais de um pedido ao mesmo recurso
o sistema operacional decide para qual pedido será alocado o recurso, para que seja
possível o funcionamento do sistema de computação, com eficiência e justiça.
Uma definição, um pouco diferente, que pode ser dada ao sistema operacional é a
de programa de controle, focando suas funções no controle de dispositivos de
entrada e saída e programas de usuário, evitando erros e o mau uso do computador.
De uma forma geral, não existe uma definição que seja totalmente adequada aos
sistemas operacionais, sendo mais fácil defini-lo pelo que ele faz do que pelo que
ele é. Sabe-se que um sistema operacional está sempre executando no computador
com o objetivo de facilitar a tarefa computacional (SILBERSCHATZ E OUTROS,
2000).
Segundo Tanenbaum (2003), mesmo muitos usuários já tendo uma experiência com
um sistema operacional, é difícil definir exatamente o que ele é. Basicamente, um
sistema operacional realiza duas funções: estender a máquina e gerenciar recursos.
Como uma máquina estendida o sistema operacional oculta a verdadeira integração
com o hardware, passando apenas uma visão simples e de forma agradável ao
usuário, disponibilizando uma máquina estendida ou virtual que seja mais fácil de
utilizar do que o hardware. Como gerenciador de recursos o sistema operacional
realiza uma alocação ordenada e controlada de processadores, memórias, e
dispositivos de entrada e saída entre os programas que solicitam esses recursos,
tendo como principal função controlar quem utiliza os recursos, garantir as
requisições de recursos e evitar conflitos entre os diversos usuários e programas.
39
3.2 Componentes do sistema operacionalSegundo Silberschatz e outros (2000) pode-se desenvolver um sistema grande e de
alta complexidade separando-o em partes bem delineadas do sistema, possuindo
entradas, saídas e funções bem definidas. Nem todos os sistemas possuem uma
mesma estrutura, mas muitos deles possuem os componentes que serão definidos
em seguida de acordo com Silberschatz e outros (2000).
3.2.1 Gerência de processosPodemos considerar um processo como um programa que está em execução, mas
essa definição será ampliada após um maior aprofundamento do conceito de
processo. No momento podemos entender um processo como um programa de
usuário de tempo compartilhado.
Os processos necessitam de recursos para realizar suas tarefas, como tempo de
CPU, memória, arquivos e dispositivos de entrada e saída. Esses recursos podem
ser disponibilizados no momento da sua criação ou alocados em tempo de
execução. Após o encerramento do processo, o sistema operacional solicita de volta
os recursos que possam reutilizados.
A execução de um processo é realizada pela CPU, de forma seqüencial, executando
uma instrução após a outra até o fim do processo, dessa forma, mesmo que dois
processos estejam associados ao mesmo programa (normalmente um programa
utiliza diversos processos para sua execução), eles podem ser diferenciados como
duas sequências de execução.
As seguintes funções são atribuídas ao sistema operacional na gerencia de
processos:
Criar e excluir processos de usuário e de sistema
Parar e reiniciar processos
Disponibilizar mecanismos para sincronização de processos
Disponibilizar mecanismos para a comunicação de processos
Disponibilizar mecanismos para o tratamento de deadlocks
Um deadlock se caracteriza quando um processo entra em estado de espera,
aguardando um recurso que não será disponibilizado, pois está alocado para um
outro processo também em estado de espera.
40
3.2.2 Gerência de memória principalA memória principal é utilizada para armazenar dados que são acessados de forma
rápida pela CPU e por dispositivos de entrada e saída. No ciclo de busca de
instruções, o processador realiza a leitura dessas instruções na memória principal,
além de realizar a gravação e leitura de dados, nesta mesma memória, durante o
ciclo de busca de dados. Também são feitas leituras e gravações de dados na
memória, durante as operações de entrada e saída. Normalmente, a memória
principal, é o único dispositivo com grande armazenamento endereçado e acessado
diretamente pela CPU. Antes que a CPU processe os dados no disco ou execute
instruções, esses dados e instruções precisam ser passados para a memória.
Para a execução de um programa, é necessário que ele seja mapeado para os
endereços reais da memória e depois carregado na mesma. Durante a execução o
programa vai realizando acessos as instruções e aos dados a partir da memória. Ao
terminar sua execução o seu espaço na memória fica disponível para que outros
programas possam ser executados.
Para que a CPU tenha uma melhor utilização e maior velocidade nas suas respostas
aos usuários, diversos programas são mantidos na memória simultaneamente.
Existem diversos formas para a gerência da memória, dependendo de diversos
fatores, como o projeto de hardware do sistema, por exemplo.
As seguintes funções são atribuídas ao sistema operacional no gerenciamento da
memória:
Manter os registros das partes da memória que estão sendo
utilizadas e quem está utilizando
Decidir qual processo será carregado na memória quando houver
disponibilidade
Alocar e desalocar os espaços da memória.
3.2.3 Gerência de arquivosExistem diversos meios físicos onde um computador pode armazenar dados. São
mais comuns: a fita magnética, disco magnético e disco ótico. Esses meios possuem
diferentes características e organização física, além de cada um ser controlado por
um dispositivo diferente que também possui suas características próprias, como a
41
velocidade de acesso, capacidade, taxa de transferência de dados e método de
acesso, por exemplo. Para que o uso do sistema de computação possa ser feito de
forma interessante, o sistema operacional abstrai a diferença entre os dispositivos
de armazenamento, disponibilizando uma visão lógica uniforme.
Um arquivo é o conjunto de informações relacionadas que foram definidas por um
criador e normalmente representam programas e dados. O sistema operacional
realiza o gerenciamento do meio de armazenamento, como fitas e discos, e dos
dispositivos que os controlam, possibilitando a criação de uma visão abstrata do
arquivo.
O arquivo é mapeado no meio físico pelo sistema operacional, que depois realiza o
acesso a esses arquivos através dos dispositivos de armazenamento. Normalmente
os arquivos são organizados em diretórios, facilitando assim o seu uso.
São atribuídas as seguintes funções ao sistema operacional na gerência de
arquivos:
Criação e exclusão de arquivos
Criação e exclusão de diretórios
Disponibilizar suporte para manipulação de arquivos e diretórios
Mapear arquivos
Fazer backup de arquivos
3.2.4 Gerência do sistema de entrada e saídaO sistema operacional tem a função de abstrair, do usuário, alguns detalhes dos
dispositivos de hardware específicos. Apenas o driver (controlador do dispositivo) do
dispositivo conhece as suas peculiaridades.
3.2.5 Gerência de armazenamento secundárioUm sistema de computação tem como principal função a execução de programas
que, assim como os dados que acessam, estão na memória principal
(armazenamento primário) no momento da execução, porém como essa memória
não tem capacidade para armazenar todos os programas e dados, além de perder
todas as informações quando é desconectada da energia, é necessária a
disponibilização de um armazenamento secundário. Normalmente são utilizados
discos para esse tipo de armazenamento. Os programas e dados são armazenados
nesses discos até que sejam carregados na memória, tornando a gerência do
42
armazenamento em disco bastante importante para o bom funcionamento do
sistema de computação, já que esse armazenamento é utilizado com grande
frequência.
São atribuídas ao sistema operacional as seguintes funções na gerência de
armazenamento secundário:
Gerência de espaço livre
Armazenamento
Escalonamento de disco
3.2.6 RedesUm sistema distribuído é um conjunto de processadores que se comunicam através
de linhas de comunicação, como por exemplo, uma rede, possibilitando que dois
sistemas diferentes e separados fisicamente sejam transformados em um único
sistema, disponibilizando ao usuário diversos recursos mantidos pelo sistema. Os
recursos compartilhados possibilitam maior velocidade na computação, maior
funcionalidade, disponibilidade de dados e confiabilidade. Os sistemas operacionais,
geralmente, utilizam os acessos à rede como mecanismo para acessar arquivos,
sem se preocupar com os detalhes da rede, que são controlados pelo driver do
dispositivo de rede.
3.2.7 Sistemas de proteçãoComo podem existir diversos usuários executando diversos processos em
concorrência, é necessário que o processo seja protegido das ações dos outros.
Existem mecanismos para que recursos como, arquivos, segmentos de memória,
CPU, entre outros, sejam utilizados apenas por processos que tenham autorização
do sistema operacional.
Qualquer forma de controle de acesso de programas, usuários ou processos aos
recursos de um sistema de computação é considerada uma proteção.
Com a utilização da proteção é possível aumentar a confiabilidade verificando erros
nas interfaces entre subsistemas, evitando que um subsistema funcionando
corretamente possa ser prejudicado por outro com problemas de funcionamento. Os
recursos não conseguem se defender do uso feito por usuários não autorizados, por
isso eles necessitam de uma proteção.
43
3.2.8 Sistema interpretador de comandosO interpretador de comandos é a interface entre o usuário e o sistema operacional.
Em alguns sistemas operacionais o interpretador se encontra no kernel (núcleo do
sistema operacional), em outros são considerados um programa que executa
apenas quando um trabalho começa ou quando um usuário entra no sistema, no
caso dos sistemas de tempo compartilhado. O interpretador de comandos é um dos
programas sistema mais importantes para um sistema operacional.
Os comandos, normalmente, são passados para o sistema operacional através de
instruções de controle. Ao se iniciar um novo trabalho ou um usuário se conectar a
um sistema de tempo compartilhado, é realizada a leitura e a interpretação das
instruções de controle por um programa que executa de forma automática. Esse
programa, normalmente, é chamado de shell e tem o objetivo de pegar o próximo
comando e executá-lo.
Normalmente os sistemas operacionais possuem um interpretador de comandos
(shell) amigável, facilitando a utilização dos usuários, como por exemplo, o sistema
de janelas e menus baseado em mouse do Windows, que identifica uma ação de
abrir um programa, selecionar um arquivo ou diretório, apenas pela posição do
ponteiro do mouse e um clique. Outros sistemas operacionais possuem um shell
mais complicado, onde é necessário digitar comandos específicos para realizar as
tarefas desejadas.
3.3 Serviços de sistemas operacionais Segundo Silberschatz e outros (2000), além de disponibilizar um ambiente para a
execução de programas, o sistema operacional também oferece alguns serviços
para os programas e os usuários destes programas. Esses serviços são
disponibilizados para facilitar o trabalho dos programadores e variam de um sistema
operacional para o outro, mas existem alguns serviços em comum entre eles que
serão detalhados em seguida segundo Silberschatz e outros (2000).
Execução de programa: o sistema precisa poder carregar um
programa na memória e executá-lo, além de poder encerrá-lo
normalmente ou retornando erro.
44
Operações de entrada e saída: os programas que estão em
execução podem precisar utilizar dispositivos de entrada e saída,
mas para melhor eficiência e segurança os usuários, normalmente,
não podem controlar esses dispositivos diretamente. O sistema
operacional deve disponibilizar mecanismos para realizar essas
operações.
Manipulação do sistema de arquivos: os programas precisam
realizar a criação, exclusão, leitura e gravação de arquivos.
Comunicações: os processos necessitam trocar informações entre
si. Essa troca pode ocorrer entre processos de um mesmo
computador ou de computadores diferentes. Essa comunicação
pode ser feita através de uma memória compartilhada entre os dois
processos ou por troca de mensagens, onde o sistema operacional
move pacotes de informações entre os processos.
Detecção de erros: como podem ocorrer erros no hardware da CPU
e da memória, em dispositivos de entrada e saída e no programa de
usuário, o sistema operacional precisa realizar uma ação para cada
tipo de erro, garantindo a computação concorrente e consistente.
3.4 Sistemas operacionais embarcadosUm sistema operacional embarcado é caracterizado por executar em dispositivos,
como telefones móveis, microondas, maquinas de lavar, vídeo games, etc. Esse tipo
de dispositivo possui restrições quanto aos recursos de memória, processamento,
consumo de energia, entre outros recursos que os tornam peculiares, por isso os
sistemas operacionais devem ser customizáveis, privilegiando atividades dedicadas
(LACERDA, 2009).
Alguns exemplos de sistemas operacionais embarcados, utilizados em dispositivos
móveis:
Windows Mobile: sistema operacional da Microsoft, que foi
criado para executar nos dispositivos móveis como Pocket
PCs, Smartphones, PDAs e aparelhos de multimídia em
geral. O Windows Mobile foi projetado para executar grande
parte do que se pode realizar numa versão do Windows para
45
PC (Personal Computer – Computador Pessoal), já
possuindo um conjunto de aplicações comumente utilizadas
no PC, como Word, Excel, Power Point, Windows Media
Player (WIKIPEDIA, 2008?).
Symbian OS: sistema operacional que foi desenvolvido com
base no sistema EPOC. O Symbian é um sistema leve,
barato e aberto, que permite a instalação de softwares de
terceiros, que podem ser criados em diversas linguagens
como, Symbian C/C++, JavaME, FlashLite, Perl, Phyton,
entre outras. O Symbian não possui uma interface gráfica
definida, sendo possível que o fabricante do dispositivo
customize essa interface (VIVASEMFIO, 2009).
Palm OS: sistema operacional criado pela Palm Inc. que é
utilizado em smartphones e PDAs. O Palm OS gerencia
todas as funções do dispositivo, controlando a tela, teclas,
sistema de sincronismo, reconhecimento de escrita, etc.,
além de possuir diversos aplicativos importantes na utilização
de um dispositivo móvel como, agenda, contatos, tarefas,
bloco de notas e programas de configuração. Esse sistema
passou a ser da empresa ACCESS e teve seu nome alterado
para Garnet OS (PALMBRASIL, 2008?).
46
4 ANDROIDNeste capítulo abordaremos a definição do sistema operacional ANDROID,
detalhando os componentes de sua arquitetura e da estrutura de uma aplicação
nesta plataforma.
4.1 DefiniçãoA criação de aplicações para dispositivos móveis cresceu bastante com o passar do
tempo, passando a ser bastante presente em muitas empresas que desejam levar
suas soluções, ou até mesmo criar novas, para os ambientes móveis. Em 2007 a
Google, em parceria com o Open Handset Alliance, um grupo de mais de trinta
empresas, lançou a primeira plataforma open source (com o código disponível) para
o desenvolvimento em dispositivos móveis, denominado Android (RABELLO, 2008).
Segundo What is Android? (2008), esta plataforma inclui um sistema operacional,
middleware e aplicações fundamentais.
4.2 ARQUITETURAA arquitetura do Android possui diversas camadas, como é demonstrado na Figura
4.1. Essas camadas serão detalhadas segundo Rabello (2008).
47
Figura 4.1 – As camadas da arquitetura Android (RABELLO, 2008).
4.2.1 AplicaçõesEsta camada possui diversas aplicações padrões desenvolvidas com a linguagem
Java, como por exemplo: cliente de e-mail, programa de SMS, calendário, mapas,
navegador, gerenciador de contatos.
4.2.2 Framework de AplicaçãoNesta camada se encontram os componentes que permitem a reutilização de código
para novas aplicações, onde qualquer aplicação pode publicar suas funções para
que outras aplicações façam uso delas.
São exemplos de alguns componentes que fazem parte do Framework de Aplicação:
Um grande conjunto de componentes gráficos, como listas, grids,
caixas de textos, botões e um navegador web.
Provedores de conteúdo, possibilitando que aplicações acessem e
compartilhem dados com outras aplicações.
Gerenciador de recursos que possibilita acesso a recursos não
codificados, a exemplo de strings, gráficos e arquivos de layout.
Gerenciador de notificação, permitindo a criação de mensagens de
alerta e que todas as aplicações possam exibi-las na barra de status.
48
Gerenciador de atividade que controla o ciclo de vida das aplicações,
gerenciando os recursos que foram previamente alocados, verificando
se ainda continuam sendo utilizados ou se já podem ser desalocados
para liberar memória.
4.2.3 BibliotecasAndroid utiliza uma coleção de bibliotecas escritas em C/C++, que são
disponiblizadas aos desenvolvedores através do framework de aplicação. São elas:
Biblioteca de Sistema C: é a otimização da biblioteca C padrão para dispositivos
que suportam a plataforma Linux.
Bibliotecas de Mídias: para execução e gravação de diversos formatos de áudio e
vídeo e até mesmo imagens.
Gerenciador de superfície: realiza o controle do acesso ao display do dispositivo e
das camadas gráficas 2D e 3D de diversas aplicações.
LibWebCore: moderna ferramenta para dar poder ao navegador web da plataforma
Android ou até mesmo outro qualquer que seja desenvolvido.
SGL: engine para os gráficos 2D.
3D libraries: baseada no OpenGL, utilizam aceleração de hardware e um otimizado
software para renderização em 3D.
FreeType: renderização das fontes vetoriais e bitmaps.
SQLite: uma leve e poderosa engine para banco de dados relacional.
4.2.4 Ambiente de ExecuçãoO ambiente de execução possui a máquina virtual Dalvik, que foi desenvolvida para
que os dispositivos pudessem suportar diversas máquinas com eficiência. As
aplicações Android executam dentro do seu próprio processo, com sua própria
instância nesta máquina virtual. Os arquivos executados pela Dalvik (extensão
“.dex”) são otimizados para utilizar o mínimo de memória possível.
4.2.5 Kernel LinuxO Kernel Linux é base da arquitetura, disponibilizando serviços do núcleo, como
segurança, gerenciamento de memória, de processos, pilhas de redes, etc.
Segundo What is Android? (2008), essa camada ainda funciona como uma
abstração entre o hardware e o resto da pilha de software.
4.3 Estrutura de aplicação
49
Existem quatro componentes que fazem parte de uma aplicação Android: Activity,
Intent, Intent Filter, Intent Receiver, Service e Content Provider. A aplicação não
precisa possuir todos componentes, utilizando apenas os que sejam necessários
para a construção da aplicação. Esses componentes serão conceituados segundo
Anatomia de uma Aplicação Android (2008):
4.3.1 Activity O componente Activity (Atividade), normalmente representa uma tela da aplicação.
Uma atividade é criada através de uma classe que estende a classe de base
Activity. Essa classe será a interface com o usuário através de views (Visões) e
estará respondendo a eventos. A Activity é o componente mais comum em uma
aplicação Android.
As aplicações, geralmente, possuem diversas telas, como por exemplo, uma
aplicação de mensagens de texto que deve ter uma tela para a lista de contatos,
outra para escrever a mensagem, uma para visualizar mensagens antigas, uma para
alterar ou visualizar configurações, etc. Para cada uma dessas telas deverá ser
criada uma atividade. A alteração de uma tela para outra significa a inicialização de
uma nova atividade, podendo ocorrer de uma atividade retornar algum dado para
outra. Ao abrir uma nova tela, a anterior é armazenada é uma pilha de histórico,
sendo possível que o usuário possa navegar entre as telas que estejam nessa pilha.
Quando as telas não forem mais ser utilizadas elas são retiradas da pilha.
4.3.2 Intent, Intent Filters e Intent Receiver A Intent é uma classe especial que o Android utiliza para realizar mudanças entre
telas. Ela descreve o que a aplicação deseja fazer. A sua estrutura de dados tem
duas partes com maior importância, que é a ação e os dados sobre o que vai ser
feito. Na ação, os valores normalmente são: main, view, pick, edit, etc. Já o dado é
expressado como uma URI (Uniform Resource Indicator). Por exemplo, quando se
deseja visualizar as informações de um contato é criada uma Intent com a ação view
(visão) e os dados definindo a URI correspondente a pessoa que se deseja
consultar.
Enquanto a Intent é uma requisição para se fazer algo, a Intent Filter é uma classe
relacionada que possui a descrição das intenções que uma atividade consegue
tratar. Uma Activity que consegue mostrar as informações de contato de uma
50
pessoa, publica um Intent Filter informando que sabe tratar a ação view quando os
dados representarem aquela pessoa.
A Intent Receiver é utilizada quando se deseja executar uma código na sua
aplicação a partir de algum acontecimento externo, como por exemplo, o telefone
tocar, dados estiverem disponíveis na rede ou quando for um determinado horário. O
alerta ao usuário é feito através do Notification Manager. Não é necessário que sua
aplicação esteja executando para que a Intent Receiver seja chamada, caso seja
necessário o sistema inicia sua aplicação quando a Intent Receiver for chamada.
4.3.3 Service Um serviço é um código que possui vida longa. Um exemplo de serviço é quando
um usuário utiliza algum tocador de música. Nesta aplicação existirão diversas
atividades permitindo ao usuário escolher suas músicas e conseguir tocá-las, mas
quando o usuário troca de tela é preciso que a música continue tocando, por isso o
playback da música não pode ser tratado por uma atividade. O tocador irá iniciar um
serviço para executar em background e poder manter a música tocando. O serviço
de playback permanecerá executando até que se encerre. Um serviço ainda
possibilita uma conexão com ele, permitindo que o usuário se comunique através de
uma interface. Neste caso o serviço poderia disponibilizar que o usuário parasse ou
recomeçasse a música por exemplo.
4.3.4 Content ProviderO Content Provider (provedor de conteúdo) é utilizado quando se deseja
compartilhar os dados da sua aplicação com outras aplicações. É uma classe que
implementa métodos padrões necessários para que outras aplicações consigam
guardar e obter as informações daquele provedor de conteúdo.
51
5 O PROJETO5.1 Objetivo e descriçãoNosso projeto propõe uma comparação entre dois tipos de web services. Para
realizar essa comparação foi desenvolvida uma solução de integração entre uma
aplicação Android e um web service ws-* utilizando a arquitetura SOA. Estamos
dando continuidade a um projeto anterior onde foi proposto uma mesma solução de
integração, porém foi utilizado o web service REST. O objetivo desse projeto é fazer
uma comparação entre as duas soluções identificando vantagens e desvantagens
na utilização desses dois tipos de web services: WS-* e REST.
5.2 Solução de IntegraçãoA solução será baseada na arquitetura cliente-servidor, onde, do lado do servidor
haverá um web service do modelo ws-* contendo várias funções de consulta e
armazenamento de informações. Do lado cliente existe uma aplicação móvel, feita
em Java que é executada em um sistema operacional Android.
5.2.1 Provedor de serviçoComo o projeto anterior que estamos dando continuidade utilizou a linha REST de
web service que tem como característica o fornecimento de serviços orientado a
52
recursos, utilizaremos a linha WS-*. Este tipo tem como característica o
fornecimento de serviços orientado a atividades. Mais tarde demonstraremos uma
comparação entre as duas linhagens com as características identificadas entre a
aplicação do projeto anterior e a aplicação deste trabalho.
Para diminuir a interferência de outras variáveis no processo de comparação do
nosso projeto utilizamos as mesmas ferramentas e tecnologias para desenvolver
nossa aplicação. Com isso, a ferramenta selecionada foi o NetBeans 6.5 (disponível
em http://www.netbeans.org/downloads/6.5/), que, apesar de ser uma versão mais
nova do que a utilizada no projeto anterior, não afetará na nossa comparação. Da
mesma forma que o NetBeans traz uma grande facilidade para o desenvolvimento
de web services REST, trás também a mesma facilidade no desenvolvimento do tipo
WS-*. A capacidade de integração com o servidor de aplicação (Glassfish) e a de
elaboração de diagramas são outras características que foram levadas em
consideração no projeto anterior para utilização dessa ferramenta. O servidor de
aplicação utilizado foi o Glassfish, o qual não foi necessário fazer qualquer
configuração adicional para execução do web service WS-*.
Como servidor de banco de dados foi utilizado o MySql 5.1.30 que veio junto com a
aplicação XAMPP (disponível em http://www.apachefriends.org/pt_br/xampp-
windows.html) o qual será utilizado pelo web service para armazenamento e
recuperação de informações.
Para realizar o mapeamento das classes Java com o banco de dados foi utilizado a
JPA (Java Persistence API). Com ela é possível fazer o mapeamento de duas
formas: A partir de uma estrutura criada no banco de dados, gerar as classes em
Java já mapeadas com JPA ou pode ser feito a partir de classes Java gerar o
mapeamento automatizado com o JPA e depois gerar a estrutura do banco de
dados. Nesse projeto foram utilizadas as duas formas de mapeamento. Uma no
momento da geração da estrutura do banco de dados, a partir das classes
mapeadas com JPA do projeto anterior e outra no momento da geração de classes
Java a partir dessa estrutura do banco de dados para o nosso projeto. As
associações entre as entidades tiveram que ser feitas manualmente, pois a geração
automática dessas entidades não contemplou o relacionamento.
Na criação do web service foi utilizado o JAX-WS (Java API for XML Web Services)
que é o padrão de implementação de web services ws-* e segue a referência da
53
JSR 224. Esta API tem como objetivo simplificar bastante o desenvolvimento de
serviços web que utilizam tecnologia Java. Para suportes habituais no controle de
serviços gerados em interfaces endpoint e nas ligações de dados o JAX-WS utiliza
JAXB 2.0.(SPINOLA, 2008).
O JAXB (Java Architecture for XML Binding) é uma API que tem como objetivo a
ligação entre classes Java e esquemas XML. Na versão 1.0 era possível apenas
realizar o mapeamento de esquemas XML em classes Java. Somente a partir da
versão 2.0 foi possível realizar o mapeamento no sentido inverso, ou seja, de
classes Java em esquemas XML (THE JAVA EE 5 Tutorial, 2008).
Uma dificuldade encontrada com a utilização do JAXB, foi que no momento da
consulta das multas de um veículo, os dados das multas estavam organizados de
forma indesejada no XML gerado inicialmente pelo JAXB, fazendo com que cada
multa daquele veículo fosse passada como uma lista de multas. Por esse motivo foi
necessário realizar o mapeamento da classe Java para XML manualmente,
utilizando as anotações do JAXB. Na tabela 5.1 é possível verificar o código Java e
o XML com a organização indesejada e na tabela 5.2 o código Java modificado e o
XML com o problema corrigido. Foi suprimido parte do código para facilitar o
entendimento.
@Entity@Table(name = "veiculo")public class Veiculo implements Serializable { ... @OneToMany(mappedBy="veiculo", fetch=FetchType.LAZY, cascade={CascadeType.ALL}) private List<Multa> listaMulta; ... public List<Multa> getListaMulta() { return listaMulta; } ...
...<return> <ideVeiculo>1</ideVeiculo> < listaMulta > <dataMulta>2009-05-09T00:00:00-03:00</dataMulta> <ideMulta>1</ideMulta> <numValor>677.99</numValor> </ listaMulta> < listaMulta> <dataMulta>2009-05-09T00:00:00-03:00</dataMulta> <ideMulta>4</ideMulta> <numValor>150.0</numValor> </ listaMulta> < listaMulta > <dataMulta>2009-05-09T00:00:00-03:00</dataMulta> <ideMulta>7</ideMulta> <numValor>65.44</numValor> </ listaMulta> ... </return>...
54
Figura 5.1 – Código Java e respectivo XML gerado antes da correção.
.@Entity@Table(name = "veiculo")public class Veiculo implements Serializable { ... @OneToMany(mappedBy="veiculo", fetch=FetchType.LAZY, cascade={CascadeType.ALL}) private List<Multa> listaMulta; ... @XmlElement( name="multa" ) @XmlElementWrapper( name="listaMulta" ) public List<Multa> getListaMulta() { return listaMulta; } ...
...<return> <ideVeiculo>1</ideVeiculo> <listaMulta> <multa> <dataMulta>2009-05-09T00:00:00-03:00</dataMulta> <ideMulta>1</ideMulta> <numValor>677.99</numValor> </multa> <multa> <dataMulta>2009-05-09T00:00:00-03:00</dataMulta> <ideMulta>4</ideMulta> <numValor>150.0</numValor> </multa> <multa> <dataMulta>2009-05-09T00:00:00-03:00</dataMulta> <ideMulta>7</ideMulta> <numValor>65.44</numValor> </multa> </listaMulta> ...</return>...
Figura 5.2 – Código Java e respectivo XML gerado depois da correção
5.2.2 ClienteA aplicação cliente, que consome o web service, foi desenvolvido na linguagem Java
para executar na plataforma Android. Foi utilizado o kit de desenvolvimento do
fabricante – O SDK Android 1.0 release 2, que possui todo o conjunto de
ferramentas necessárias para o desenvolvimento, incluindo o emulador de
dispositivo móvel, sistema operacional e APIs para o desenvolvimento na linguagem
Java. Por não possuirmos um aparelho com o Android utilizamos o próprio emulador
do SDK. Esse kit de desenvolvimento pode ser baixado no endereço eletrônico
http://developer.android.com/sdk/1.0_r2/index.html.
Foi utilizado para o desenvolvimento a IDE MyEclipse 6.5 que é uma ferramenta que
trás vários recursos que ajuda bastante o desenvolvedor. Ela é baseada no eclipse
tendo a mesma aparência e funcionalidades, porém não é gratuita. Pode ser
55
adquirido no endereço: http://www.myeclipseide.com/module-htmlpages-display-pid-
4.html .
Foi possível utilizar o mesmo plugin disponível para o eclipse, ou seja, o ADT
(Android Development Tools - Ferramentas de Desenvolvimento Android) da
Google, já que o MyEclipse é, na verdade, o Eclipse com algumas adaptações. Para
adquirir o plugin foi necessário atualizar a IDE através do endereço: https://dl-
ssl.google.com/android/eclipse/ .
Para facilitar a comparação foi aproveitada toda a parte da aplicação do projeto
anterior exceto a parte de comunicação com o web service. As telas são iguais
porém o mecanismo de acesso ao serviço é diferente. Enquanto para consumir os
serviços REST foi necessário apenas fazer uso dos métodos HTTP, na nossa
solução foi necessário incluir uma biblioteca chamada ksoap2. Como foi falado
anteriormente, ela que é responsável por abstrair toda a complexidade na
comunicação com o serviço web.
5.2.3 Integração cliente/provedor de serviçosO web service (provedor de serviços) está sob o Glassfish. O serviço é integrado ao
banco de dados por um objeto de mapeamento relacional chamado TopLink que é
quem realiza efetivamente o mapeamento com o JPA.
A integração entre o cliente e o servidor ocorre da seguinte forma: o cliente cria um
objeto soap (SoapObject) que contem a função a ser chamada no web service e os
parâmetros a serem passados. Após isso é criado um envelope que ira serializar o
objeto soap (SoapSerializationEnvelope). Então é criado um objeto de transporte
(HttpTransport) que se encarregara de transportar o envelope contendo o objeto
soap. Logo, o web service retorna um XML contendo os dados da requisição.
5.3 Aplicação demonstrativa5.3.1 DescriçãoO SISTRANSITO é uma aplicação desenvolvida em Java para rodar em dispositivos
moveis com sistema operacional Android. Ela torna possível a disponibilização de
serviços do DETRAN (Departamento Estadual de Transito) para a população via
aparelhos moveis. Serviços como consulta às informações de veículo (dados do
veiculo, dados do proprietário e lista de multas), consulta às informações de
habilitação (dados do condutor e pontuação) e fale conosco, que permite à
56
população o envio e consulta de sugestões e criticas ao órgão. Vale ressaltar que
esses serviços são apenas hipotéticos. A implementação da metodologia de
desenvolvimento SOA é feita através de web services, garantindo a
interoperabilidade entre aplicações diferentes, realizando a transformação de
processos em serviços. Os serviços são disponibilizados através de um web service
WS-*. Através do RENAVAM (Registro Nacional de Veículos Automotores) é feita a
busca das informações do veiculo e a consulta dos dados de habilitação é realizada
a partir do número da CNH (Carteira Nacional de Habilitação).
5.3.2 Estrutura da aplicaçãoInicialmente a aplicação disponibiliza um menu com as opções habilitação, renavam
e fale conosco que são seus três principais módulos como mostra na figura 5.3.
Figura 5.3 - Sistrânsito
Para efetuar uma consulta ou um cadastro é instanciada uma classe chamada
WebService que contem os métodos disponíveis na aplicação servidora. Esse
método faz todo o processo de conexão com o serviço e chama uma função auxiliar
57
que irá converter o SOAP em um objeto correspondente. Posteriormente retorna o
resultado, que será mostrado na tela do dispositivo, caso necessário.
5.3.3 Diagrama de caso de usoPara demonstrar a solução proposta esta abaixo na figura 5.4 o diagrama de caso
de uso:
Figura 5.4 - Diagrama de caso de uso
5.3.4 Diagrama de classesA figura 5.5 demonstra a solução proposta através do diagrama de classes:
58
Figura 5.5 - Diagrama de classes
5.4 Comparações entre WS-* e RESTExistem diversas características que diferenciam o WS-* do Web Service REST.
Cada uma das linhagens, com suas características, se torna mais indicado para
determinado tipo de desenvolvimento. É muito importante verificar qual o tipo de web
service é o mais indicado antes de iniciar o desenvolvimento. Não é aconselhável
que se utilize um único tipo de web service para o desenvolvimento de todas as
aplicações, correndo o risco de aumentar a dificuldade e o tamanho do trabalho.
5.4.1 DocumentaçãoO WS-*, antes mesmo das aplicações práticas, já possuía um mundo de
especificações teóricas, definindo diversas regras que nem se quer haviam sido
59
utilizadas de forma prática. A documentação do WS-* é bastante extensa, tornando
essa linhagem, de certa forma, burocrática.
Por outro lado o Web Service REST surgiu com apenas algumas especificações de
fácil compreensão e só após os primeiros sucessos com a utilização desse web
service é que se iniciaram esforços para a padronização.
5.4.2 Comunicação O processo de comunicação no WS-* envolve basicamente três etapas. Quando a
aplicação que consome o web service deseja acessar um serviço, primeiramente,
ela realiza uma consulta ao UDDI (Universal Description Discovery and Integration –
Descrição Universal, Descoberta e Integração), que é um repositório onde os
serviços são publicados e consultados. Esse repositório envia o WSDL (Web Service
Description Language), especificando as operações disponibilizadas pelo serviço,
especificando de forma universal as formas de interação entre clientes e serviços.
Após possuir a especificação do serviço a aplicação cliente (que consome o web
service) especifica qual a operação e os parâmetros dessa operação e envia uma
mensagem com essas informações encapsuladas no protocolo SOAP, que
normalmente, trafega sobre HTTP, ao web service. Em relação a aplicação do
projeto anterior, foi necessário acrescentar a biblioteca “ksoap2” para poder realizar
esse tipo de comunicação, com o protocolo SOAP, que não é necessário no web
service REST.
Os serviços na linhagem WS-* possuem o foco em atividades, ou seja, as etapas
que o serviço realiza até concluir são modeladas como atividades.
O Web service REST utiliza extensamente os recurso do HTTP. Enquanto no WS-*
é necessário especificar, no protocolo SOAP, a operação que vai ser realizada, o
REST utiliza os métodos GET, PUT, POST e DELETE do próprio HTTP. O fato de
utilizar apenas os métodos do protocolo HTTP acarreta numa limitação deste tipo de
web service, que mesmo sendo comum a comunicação através do HTTP, pode-se
encontrar aplicações que não realizem esse tipo de comunicação. Para a realização
de trocas de mensagens é preciso que cada recurso tenha uma URI (Uniform
Resource Identifier – Identificador Uniforme de Recursos). Para realizar um acesso
ao recurso é feita uma chamada para a URI correspondente ao recurso desejado,
utilizando um dos métodos do protocolo HTTP.
60
Os serviços do Web Service REST são fortemente associados a recursos. Uma
parte fundamental da arquitetura REST é a definição do protocolo de comunicação,
definindo o mapeamento dos recursos, métodos de requisição, status HTTP e o seu
correspondente significado. Na figura 5.6 é possível verificar o exemplo de um
protocolo de comunicação com REST na busca de produtos em um site de compras.
O recurso “Produto” indica uma instância a um produto específico, enquanto o
recurso “Produtos” indica uma instância a lista completa de produtos.
Figura 5.6 – Exemplo de protocolo de comunicação com REST (SILVA, 2008, p.45).
Como podemos ver na tabela, essa linha de web service desfruta do status do
próprio HTTP para indicar o resultado da chamada ao serviço. Já no WS-* fica a
critério do programador implementar parâmetros de retorno nas funções para obter o
status da chamada.
Como podemos ver na tabela, essa linha de web service desfruta do status do
próprio HTTP para indicar o resultado da chamada ao serviço. Já no WS-* fica a
critério do programador implementar parâmetros de retorno nas funções para obter o
status da chamada.
A necessidade de encapsular as informações no protocolo SOAP, causa uma perda
de desempenho ao WS-*, já que uma parte do conteúdo é desprezada por fazer
parte apenas do encapsulamento. Além disso, o SOAP possui mecanismos de
61
segurança imaturos, que não possuem criptografia do conteúdo, facilitando o acesso
de outros ao conteúdo da mensagem e não garantindo a entrega da mesma, caso
ocorra um erro o sistema não saberá reenviar a mensagem. A comunicação no Web
Service REST é realizada de forma mais simples, onde os serviços recebem apenas
o que é necessário e, consequentemente, só retornam o que é necessário. O Web
Service REST utiliza o HTTP de forma parecida como no desenvolvimento de
aplicações web, tendo a diferença de o retorno ser um XML ao invés de HTML,
facilitando a sua utilização.
Por outro lado, a comunicação utilizando o WS-* leva vantagem devido a utilização
do documento WSDL. Esse documento facilita bastante a comunicação, já que
especifica todas as operações que o serviço possui e ainda as formas de interação
entre os clientes e os serviços. Fica clara a facilidade que esse documento pode
trazer com a possibilidade de se consultar um serviço no protocolo UDDI e conhecer
os parâmetros que o serviço está esperando, o que será retornado pelo serviço e
como serão esses dados. Se pensarmos em um ambiente com diversos serviços,
que provavelmente tenham sido desenvolvidos por pessoas diferentes,
conseguiremos enxergar ainda melhor as vantagens trazidas pela especificação do
WSDL.
CONCLUSÃOA comparação realizada neste projeto, pode ser de grande utilidade para
desenvolvedores que necessitem implementar web services e não conheçam
exatamente as vantagens que cada um dos dois tipos apresentados possuem ou
simplesmente, tenham uma das linhagens como preferência, ignorando vantagens
que possam ter com uma simples análise de características entre os tipos de web
services apresentados.
A colaboração deste projeto está exatamente na realização desta análise,
contribuindo com um melhor conhecimento dessas tecnologias, que são
62
relativamente recentes, além de explorar os conceitos e a utilização prática das
tecnologias envolvidas na utilização do web service, como o SOA, por exemplo.
Uma das dificuldades que tivemos, foi que não encontramos um mecanismo para
obtenção do resultado da comunicação com o serviço. Por exemplo, numa consulta
ao banco de dados, caso não fosse encontrado um veiculo para um determinado
RENAVAM será retornado NULL, e caso existisse esse veiculo será retornado o
próprio objeto. Na implementação REST não haveria esse problema, pois é possível
usufruir do status que o protocolo HTTP dispõe juntamente com seu significado.
Não é possível substituir o WS-* pelo REST e vice-versa. As duas tecnologias
possuem características que precisam ser consideradas antes de implementar uma
solução. No ambiente desenvolvido neste projeto, com um dispositivo móvel, pode
ser mais interessante a utilização do web service REST, já que o envio e
recebimento de dados, nesse tipo de dispositivo, podem ter um custo elevado.
Porém se o ambiente for muito complexo, com uma grande quantidade de serviços,
já é interessante considerar a possibilidade de utilizar o WS-*, devido a sua melhor
especificação dos serviços, através do WSDL.
REFERÊNCIAS
ANATOMIA de uma aplicação Android. Disponível na internet. <http://www.plusgsm.com.br/forums/archive/index.php/t-74675.html>. Acesso em 25 mai. 2009.
AYRES, Marcelo. Tablet PC é notebook pequeno com tela sensível ao toque. Disponível na Internet. <http://tecnologia.uol.com.br/produtos/ultnot/2007/11/21/ult2880u472.jhtm>. Acesso em 06 ago. 2009.
63
BANERJEE, Atanu. Considerações Arquiteturais para um Mundo de Dispositivos. 2008. Disponível na Internet. <http://www.microsoft.com/brasil/msdn/arquitetura/Journal/journal14_cap01.mspx>. Acesso em 09 jun. 2009.
DANTAS, Daniel C. Toscana. Simple Object Acess Protocol (SOAP). 2007. Dinsponível na Internet. <http://www.gta.ufrj.br/grad/07_2/daniel/index.html>. Acesso em 19 mar. 2009.
DEITEL, Harvey M. e outros. XML: Como Programar. Tradução: Luiz A. Salgado e Edson Furmankiewicz. Bookman. 2003.
GANDOLPHO, Cibele. Cresce uso de SOA. 2008. Disponível na Internet. <http://info.abril.com.br/corporate/soa/cresce-uso-de-soa.shtml>. Acesso em 18 mar. 2009.
INTERNET2 Middleware Initiative. Disponível na Internet. <http://www.internet2.edu/middleware/>. Acesso em 20 abr. 2009.
JOHNSON, Thienne M. Java para dispositivos móveis. 2007. Disponível na Internet. <http://books.google.com.br/books?id=YPnhdne0N0MC&pg=PA22&dq=programacao+%2B+celulares&ei=Gy98StX4CaCGygTm5PG7DA#v=onepage&q=&f=false>. Acesso em 07 ago. 2009.
LACERDA, Wilian Soares. Sistemas Embarcados. 2009. Disponível na internet. <http://www.dcc.ufla.br/~lacerda/download/palestras/sis_embarcados/palestra_sistemas_embarcados.ppt#256,1>. Acesso em 05 de jun. 2009.
LEE, Valentino; SCHNEIDER, Heather; SCHELL, Robbie. Aplicações movies: Arquitetura, projeto e desenvolvimento. Tradução: Amaury Bentes e Deborah Rudiger. São Paulo, 2005.
MARCHAL, Benoit. XML conceitos e aplicações. Tradução: Daniel Vieira. São Paulo. Editora Berkeley. 2000.
NETO, Rodolpho Ugolini. Arquitetura Orientada a Serviços – SOA Infra-estrutura para a Inovação. 2006. Disponível na internet. <http://www.pr.senai.br/posgraduacao/uploadAddress/Introducao%20ao%20SOA%5B31574%5D.pdf>. Acesso em 19 mar. 2009.
PALMBRASIL. Palm OS ou Garnet OS. [2008?]. Disponível na internet. <http://www.palmbrasil.com.br/palm-os-webos/vocabulario/98-pqr/541-palm-os-ou-garnet-os>. Acesso em 17 jun. 2009.
PEREIRA, Dani Edson. O que é esse tal de XML afinal?. 2002. Disponível na Internet. <http://www.apostilando.com/download.php?cod=198&categoria=XML>. Acesso em 02 jun. 2009.
PITTS-MOULTIS, Nathanya; KIRK, Cheryl. XML: Black Book. 1ª ed. São Paulo – SP: Makron Books, 2000.
64
QUEIRÓS, Ricardo. Programação para Dispositivos Móveis em Windows Mobile 6. 1ª ed. FCA – Editora de Informática. 2008.
RABELLO, Ramon Ribeiro. Android: um novo paradigma de desenvolvimento móvel. Web Mobile. Ed. 18. 2008. p.6-13.
RECKZIEGEL, Maurício. Descrevendo um Web Service – WSDL. 2006. Disponível na Internet. <http://imasters.uol.com.br/artigo/4422/webservices/descrevendo_um_web_service_-_wsdl/>. Acesso em 31 mar. 2009.
RECKZIEGEL, Maurício. Protocolo de Transporte Padrão. 2006. Disponível na Internet. <http://imasters.uol.com.br/artigo/4379/webservices/protocolo_de_transporte_padrao_-_soap/>. Acesso em 19 mar. 2009.
SAMPAIO, Cleuton. SOA e Web Services em Java, Rio de Janeiro, 2006.
SILBERSCHATZ, Abraham; GALVIN, Peter; GAGNE, Greg. Sistemas operacionais. Tradução: Adriana Ceschin Rieche. Rio de Janeiro, 2000.
SILVA, Bruno L. P. REST vs WS-*: Uma visão pragmática. Java Magazine. ed. 54. Rio de Janeiro. 2008. p.38-47.
SILVA, Bruno L.P. WS-*: Implementando web services na prática, com os padrões WS-I. Java Magazine. Ed. 55. Rio de Janeiro. 2008. p.24-31.
SOARES, Edileuza. SOA é a nova onda de TI. 2007. Disponível na internet. <http://wnews.uol.com.br/site/noticias/materia_especial.php?id_secao=17&id_conteudo=425>. Acesso em 18 mar. 2009.
SPINOLA, Eduardo. Desenvolvendo Web Services utilizando JAX-WS. 2008. Disponível na Internet. <http://www.devmedia.com.br/articles/viewcomp.asp?comp=2374>. Acesso em 15 mai. 2009.
TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 2. ed. Tradução: Ronaldo A.L. Gonçalves e Luís A. Consularo. São Paulo. Prentice Hall. 2003.
TAURION, Cezar. 2008. Android & Linux & OpenSource. Disponível na Internet. <http://www2.eletronica.org/artigos/eletronica-digital/android-linux-opensource>. Acesso em 09 jun. 2009.
THE JAVA EE 5 Tutorial. Binding between XML and Java Classes. 2008. Disponível na Internet. <http://java.sun.com/javaee/5/docs/tutorial/doc/bnazf.html>. Acesso em 10 jun. 2009.
VIVASEMFIO. Symbian. 2009. Disponível na Internet. <http://www.vivasemfio.com/blog/category/symbian_os/>. Acesso em 05 jun. 2009.
WHAT is Android, 2008. Disponível na Internet. <http://code.google.com/android/what-is-android.html>. Acesso em 1 abr. 2009.
65
WIKIPEDIA. Laptop. [2007]. Disponível na Internet. <http://pt.wikipedia.org/wiki/Laptop>. Acesso em 06 ago. 2009.
WIKIPEDIA. Pager. [2007]. Disponível na Internet. <http://pt.wikipedia.org/wiki/Pager>. Acesso em 20 jul. 2009.
WIKIPEDIA. Tablet PC. [2009]. Disponível na Internet. <http://pt.wikipedia.org/wiki/Tablet_PC>. Acesso em 06 ago. 2009.
WIKPEDIA. Windows Mobile. [2008?] Disponível na internet. <http://pt.wikipedia.org/wiki/Windows_Mobile>. Acesso em 05 jun. 2009.
