Embed Size (px)
DESCRIPTION
Citation preview
FÁBIO DE OLIVEIRA SALESKECYO SACRAMENTO BARROS
SOLUÇÃO DE INTEGRAÇÃO ENTRE JAVA, WEB SERVICES E ANDROID, UTILIZANDO A ARQUITETURA SOA
SALVADOR2008
FÁBIO DE OLIVEIRA SALES
KECYO SACRAMENTO BARROS
Solução de integração entre Java, Web Services e Android, utilizando a arquitetura SOA
SALVADOR2008
Monografia apresentada por Fábio de Oliveira Sales e Kecyo Sacramento Barros como requisito parcial para aprovação na disciplina Projeto Final.
Orientador: Prof. Osvaldo Requião Melo
CERTIFICADO
Certifico que a presente memória, Solução de integração entre Java, Web Services
e Android, utilizando a arquitetura SOA, foi realizada sob minha direção por FÁBIO
DE OLIVEIRA SALES e KECYO SACRAMENTO BARROS, constituindo o Projeto
Final do Curso de Bacharelado em Informática da Universidade Católica do Salvador
- UCSAL.
Salvador, 13 de Dezembro de 2008.
Osvaldo Requião Melo
Curso de Bacharelado em Informática
Universidade Católica do Salvador
Salvador
13/12/2008
DEDICATÓRIA
“Dedico este trabalho a meus pais, Adroaldo da Silva Sales e Rutiney de Oliveira
Sales, pelo amor, carinho e o enorme sacrifício que passaram para que eu pudesse
atingir meus objetivos. À minha irmã Daiane de Oliveira Sales e a todos os meus
familiares e amigos, pelo carinho e compreensão durante o período deste trabalho.
À minha namorada Kelly Evelyn de Carvalho Santos, pelo amor, incentivo e por
proporcionar momentos maravilhosos em minha vida. Ao amigo Kecyo Barros, pela
seriedade e dedicação para com este projeto”. (Fábio Sales)
“Dedico este trabalho especialmente aos meus pais, Osmar e Rita, pelo carinho,
amor e luta para poder proporcionar tudo isso. Grande parte dessa conquista é
deles. A todos os meus familiares, que sempre me apoiaram e torceram muito para
o meu sucesso. À minha namorada Mayara Alves Vidal, que foi muito compreensiva,
companheira, que me incentivou e orientou, e claro, é a menina mais dengosa do
mundo. Eu a amo muito. Aos meus tios Geraldo e Hélia, por todo apoio, ajuda e
compreensão. Muito obrigado. Ao meu colega de projeto Fábio Sales, pela enorme
ajuda e dedicação ao projeto. Sofremos mas terminamos”. (Kecyo Barros)
AGRADECIMENTOS
Agradecemos primeiramente a Deus, por nos ter dado a oportunidade de vencer
mais esta etapa de nossas vidas. Ao professor, amigo e orientador Osvaldo
Requião, pela excelente orientação dada neste trabalho. Aos colegas de classe, por
nos proporcionar momentos inesquecíveis durante o curso. Ao colega Claudio das
Virgens, por elaborar as imagens do “Sistrânsito” e a todos que contribuíram direta
ou indiretamente para a conclusão deste projeto.
RESUMO
Este trabalho propõe uma solução de integração entre as tecnologias Web Services,
Java e o sistema operacional para dispositivos móveis Android, utilizando
metodologia de desenvolvimento SOA. Além disso, constrói-se uma aplicação para
ilustrar a solução proposta, destacando-se as dificuldades e possibilidades de
implementação de uma arquitetura com estas características.
Palavras chaves: Android, SOA, Web Services, Java, Dispositivos Móveis.
ABSTRACT
This work proposes an integration solution between the technologies Web Services,
Java and the operation system for mobile devices Android, using SOA development
methodology. Also, an application is built to illustrate the proposed solution, standing
out the difficulties and possibilities to implementing an architecture with these
features.
Key-Words: Android, SOA, Web Services, Java, Mobile Devices.
LISTA DE FIGURAS
Figura 1.1 - Exemplo de um documento XML...........................................................18
Figura 1.2 - Exemplo do uso de atributos em um XML..............................................19
Figura 1.3 – XML declarando a sua DTD associada.................................................20
Figura 1.5 - Documento utilizando esquema XML da Microsoft................................21
Figura 1.6 - Fluxo de comunicação do WS-*.............................................................27
Figura 1.7 - Estilo de acesso aos serviços com REST e WS-*..................................28
Figura 3.1 - Estrutura de um sistema computacional.................................................47
Figura 4.1 - Lista das empresas da OHA...................................................................54
Figura 4.2 - Arquitetura Android.................................................................................55
Figura 5.1 - Mapeamento com JPA...........................................................................63
Figura 5.2 - Mapeamento com a JAX-RS..................................................................65
Figura 5.3 - Ambiente de desenvolvimento do provedor de serviços........................65
Figura 5.4 - Ambiente de desenvolvimento do cliente...............................................66
Figura 5.5 - Integração entre tecnologias..................................................................68
Figura 5.6 - Sistrânsito...............................................................................................69
Figura 5.7 - Consulta Sistrânsito................................................................................70
Figura 5.8 - XML Consulta RENAVAM......................................................................71
Figura 5.9 - Diagrama de caso de uso.......................................................................72
Figura 5.10 - Diagrama de classes da aplicação.......................................................73
LISTA DE TABELAS
Tabela 2.1 - Velocidades de CPU típicas..................................................................35
Tabela 2.2 - Sistemas operacionais típicos...............................................................36
Tabela 2.3 - Tamanhos de memória típicos..............................................................36
Tabela 2.4 - Tamanhos típicos de disco....................................................................37
Tabela 2.5 - Duração típica de bateria.......................................................................38
Tabela 2.6 - Velocidades das portas de conexão......................................................38
Tabela 2.7 - Tamanho de tela....................................................................................40
Tabela 2.8 - Tamanho de teclado..............................................................................40
Tabela 2.9 - Velocidade de transmissão de dados de rede local sem fio..................45
LISTA DE ABREVIATURAS E SIGLAS
2D Segunda Dimensão
3D Terceira Dimensão
AAC Advanced Audio Coding
ADT Android Development Tools
AMR Adaptive Mesh Refinement
API Application Programming Interface
B2B Business-to-business
BSD Berkeley Software Distribution
CDMA Code Division Multiple Access
CNH Carteira Nacional de Habilitação
CPU Central Processing Unit
DOM Document object model
DSL Digital Subscriber Line
DTD Document Type Definition
EBNF Extended Backus-Naur Form
EDI Electronic Data Interchange
EMS Enhanced Messaging Service
FDMA Frequency Division Multiple Access
GPS Global Positioning System
GSM Global System for Mobile Communication
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
I/O Input/Output
IDE Integrated Development Environment
IDEN Integrated Digital Enhanced Network
ISBN International Standard Book Number
JAX-RS The Java API for RESTful Web Services
JDBC Java Database Connectivity
JPA Java Persistent API
JPG Joint Photographic Experts Group
JSON JavaScript Object Notation
JSR 311 Java Specification Requests 311
LAN Local Area Network
MMS Multimedia Messaging Service
MP3 MPEG Layer 3
MPEG4 Moving Picture Experts Group 4
OHA Open Handset Alliance
PC Personal Computer
PCS Personal Communications Service
PDA Personal Digital Assistant
PNG Portable Network Graphics
RENAVAM Registro Nacional de Veículos Automotores
REST Representational State Transfer.
RJ-11 Registered Jack 11
RJ-45 Registered Jack 45
RPC Remote Procedure Call
SAX Simple API for XML
SDK Software Development Kit
Serial COM Serial Communication
SGML Standard Generalized Markup Language
SMS Short Messaging Service
SO Sistema Operacional
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
TDMA Time Division Multiple Access
UDDI Universal Description, Discovery and Integration
URI Uniform Resource Identifier
URL Uniform Resource Locator
USB Universal Serial Bus
VM Virtual Machine
W3C World Wide Web Consortium
WiFi Wireless Fidelity
WS-* Web Service asterisco
WSDL Web Services Description Language
WS-MetadataExchange Web Services Metadata Exchange
WS-RT Web Services Resource Transfer
XML Extensible Markup Language
SUMÁRIO
INTRODUÇÃO..........................................................................................................15
1 WEB SERVICES E SOA....................................................................................17
1.1 XML......................................................................................................................................... 17
1.2 SOAP....................................................................................................................................... 23
1.3 WSDL...................................................................................................................................... 24
1.4 SOA......................................................................................................................................... 25
1.5 WEB SERVICES WS-*................................................................................................................25
1.6 WEB SERVICES REST...............................................................................................................28
1.7 SERVIÇOS ORIENTADOS A RECURSOS E SERVIÇOS ORIENTADOS A ATIVIDADES...........................29
2 DISPOSITIVOS MÓVEIS...................................................................................31
2.1 TIPOS DE DISPOSITIVOS MÓVEIS................................................................................................31
2.2 COMPONENTES DE DISPOSITIVOS MÓVEIS..................................................................................35
2.3 MÉTODOS DE CONEXÃO.............................................................................................................42
3 SISTEMAS OPERACIONAIS.............................................................................46
3.1 DEFINIÇÃO................................................................................................................................ 46
3.2 COMPONENTES DE UM SISTEMA OPERACIONAL...........................................................................48
3.3 TIPOS DE SISTEMAS OPERACIONAIS...........................................................................................50
4 ANDROID...........................................................................................................54
4.1 DEFINIÇÃO................................................................................................................................ 54
4.2 ARQUITETURA............................................................................................................................ 55
4.3 ESTRUTURA DA APLICAÇÃO ANDROID.........................................................................................58
4.4 SEGURANÇA.............................................................................................................................. 61
5 O PROJETO.......................................................................................................62
5.1 OBJETIVO E DESCRIÇÃO DO PROJETO.........................................................................................62
5.2 SOLUÇÃO DE INTEGRAÇÃO.........................................................................................................62
5.3 APLICAÇÃO DEMONSTRATIVA......................................................................................................68
CONCLUSÃO............................................................................................................74
REFERÊNCIAS.........................................................................................................76
15
INTRODUÇÃO
Atualmente, as organizações estão buscando reduzir custos e obter um diferencial
em seus serviços, implicando em alta demanda para a área de tecnologia da
informação e prazos cada vez menores. O paradigma de arquitetura orientada a
serviços (SOA) surge como uma solução interessante dentro desse contexto, por
prover uma maior reutilização e eficiência na criação ou manutenção de aplicações e
funcionalidades de uma empresa (Amadei e Oliveira, 2008).
Além disso, a crescente necessidade de deslocamento dos profissionais e o
dinamismo do mundo dos negócios obrigam as grandes empresas a investirem em
portabilidade, mobilidade e usabilidade, unindo o desejo de se incluir um elemento
móvel em aplicações novas ou já existentes com a conveniência e alta
funcionalidade dos dispositivos móveis (Lee e outros, 2005).
Motivado por tendências tecnológicas, sociais e econômicas, o mercado de celulares
e dos dispositivos móveis de maneira geral cresce constantemente, impulsionando
assim a adoção de serviços para esses tipos de aparelhos (Banerjee, 2008). Apesar
disto, o cenário atual de aplicações para os dispositivos móveis é árduo, uma vez
que não existe uma padronização entre esses tipos de dispositivos, resultando em
um esforço imenso no desenvolvimento e testes de aplicações por parte dos
desenvolvedores.
A chegada do sistema operacional para dispositivos móveis Android, proposto pela
Google, possibilita, além da melhora na portabilidade (uma vez que não haverá tanto
trabalho ao se portar um aplicativo de um celular para o outro), um avanço rápido no
desenvolvimento de aplicações de ponta, principalmente pelo fato de que a maioria
do código será desenvolvida de forma aberta e colaborativa (Taurion, 2008).
O objetivo deste trabalho é propor uma solução de integração entre as tecnologias
Web Services, Java e o sistema operacional Android, utilizando a metodologia de
desenvolvimento SOA (Service Oriented Architecture – Arquitetura orientada a
serviços). Para ilustrar a solução proposta, foi desenvolvida uma aplicação baseada
nessas tecnologias.
16
A motivação para elaboração deste trabalho parte da possibilidade de se explorar
bastante as diferentes tecnologias envolvidas, uma vez que as mesmas são muito
recentes e não estão totalmente consolidadas.
Primeiramente, foram elaboradas algumas pesquisas bibliográficas a fim de se
coletar um material para dar suporte a elaboração deste trabalho e realizadas
pesquisas alternativas para trabalhar com o Android. Após isso, foram montados os
ambientes de desenvolvimento do provedor de serviços e do cliente. Em seguida, foi
definida e alimentada a base de dados que armazena as informações
disponibilizadas pelo provedor de serviços. Logo após, foram construídos o Web
Service e a aplicação cliente. Finalmente, foram efetuados alguns testes e elaborada
a solução de integração entre as tecnologias.
Além desta introdução, onde se procurou demonstrar o objetivo deste trabalho, o
contexto atual no qual essas tecnologias estão inseridas e a justificativa da
elaboração dessa monografia, o presente trabalho é constituído por cinco capítulos.
Os quatro primeiros capítulos fundamentam teoricamente o projeto, apresentando
brevemente alguns conceitos e tecnologias que dão suporte ou estão ligados
diretamente a este trabalho, tais como Web Services, sistemas operacionais,
dispositivos móveis e aspectos relacionados ao Android em particular.
No primeiro capítulo são apresentados alguns elementos que estão envolvidos na
definição e construção de um Web Service e os seus tipos, além de definir SOA e
alguns tipos de serviços. No segundo capítulo, são apresentados alguns aspectos
relacionados aos dispositivos móveis, tais como seus tipos, componentes e métodos
de conexão com redes de dados. O terceiro capítulo mostra alguns conceitos
referentes aos sistemas operacionais, como seus tipos e alguns componentes que
os constituem de maneira geral. No quarto capítulo, são abordados alguns
elementos em relação ao sistema operacional Android, como a arquitetura,
segurança e estrutura da aplicação Android. No quinto capítulo, é apresentada a
solução de integração proposta, a aplicação que demonstra a solução e as
ferramentas que dão apoio à montagem de ambiente e ao desenvolvimento. Na
conclusão deste trabalho, apresentam-se aspectos importantes e eventuais
dificuldades que ocorreram durante o desenvolvimento do projeto, além da proposta
de sugestões para trabalhos futuros.
17
1 WEB SERVICES E SOA
Este capítulo visa apresentar alguns conceitos e tecnologias estreitamente ligados a
Web Services e SOA. Inicialmente é apresentado o XML, um elemento que
desempenha um papel fundamental neste projeto, servindo como base para
diversos documentos e especificações como DTD, esquemas XML, DOM, SAX,
SOAP, WSDL entre outros. Além disso, define Web Services e SOA, apresentando
os diferentes tipos de serviços existentes.
1.1 XML
A XML (Extensible Markup Language - Linguagem de Marcação Extensível) é uma
simples e flexível linguagem de marcação de texto derivada da SGML: Standard
Generalized Markup Language - Linguagem Padronizada de Marcação Genérica
(Extensible Markup Language (XML), 2008). Conforme Deitel e outros (2003), a
SGML é uma metalinguagem, ou seja, linguagem utilizada para criação de outras
linguagens, que é usada para criar linguagens de marcação como a HTML
(HyperText Markup Language – Linguagem de Marcação de Hipertexto) e outras.
Diferentemente do HTML, que restringe o autor do documento a utilizar um conjunto
já definido de marcas, a XML oferece a liberdade para o autor descrever os dados
mais precisamente, através da criação de novas marcas (Deitel e outros, 2003).
Segundo Deitel e outros (2003), a XML nasceu em virtude da necessidade de se ter
uma nova linguagem padronizada, estruturalmente escrita e plenamente extensível.
Essa nova linguagem combina a simplicidade exigida pela comunidade web com a
extensibilidade e potência da SGML, sendo a primeira a tornar os documentos
manipuláveis por computadores e legíveis para as pessoas.
As principais características da XML são a independência dos dados, a separação
do conteúdo e sua apresentação. Por não possuir instruções de formatação, a
análise sintática é facilitada (Deitel e outros, 2003), tornando a XML uma estrutura
de referência que desempenha um papel importante no intercâmbio de uma grande
variedade de dados, seja na web ou em qualquer outro local (Extensible Markup
Language (XML), 2008).
18
1.1.1 Elementos e atributos
Os elementos e atributos formam a estrutura básica de um documento XML. As
declarações de elementos especificam a estrutura do XML, dando-lhe flexibilidade
para definir o documento de acordo com suas necessidades específicas. (Pitts-
Mouts e Kirk, 2000).
Um documento XML possui uma estrutura em forma de árvore, onde cada elemento
representa um ramo desta árvore. Além disso, cada elemento pode ser aninhado,
sendo que todos os elementos definidos no documento são aninhados abaixo da
raiz ou do elemento principal (Pitts-Mouts e Kirk, 2000).
A figura 1.1 ilustra um exemplo de elementos em um documento XML onde,
segundo Pitts-Mouts e Kirk (2000), o “<LIVRO>” é o elemento pai, definindo o
contexto do documento XML. O elemento “<CAPITULO>”, filho do elemento
“<LIVRO>”, possui como filho o elemento “<SECAO>”, que por sua vez é pai do
elemento “<PARAGRAFO>”.
Figura 1.1 - Exemplo de um documento XML (Pitts-Mouts e Kirk, 2000, p.153)
Conforme Pitts-Mouts e Kirk (2000), os atributos são responsáveis por fornecer
informações adicionais sobre um elemento XML e seu conteúdo. Se um elemento é
19
vazio, o atributo serve para fornecer um conteúdo extra. Caso contrário, ele
fornecerá informações adicionais ao conteúdo já existente.
A figura 1.2 mostra a utilização de atributos em um documento XML. O elemento
“LIVRO” possui o atributo “isbn”, que identifica o numero do ISBN (International
Standard Book Number – Número Padrão Internacional de Livro) correspondente ao
livro.
Figura 1.2 - Exemplo do uso de atributos em um XML (Pitts-Mouts e Kirk, 2000, p.153)
1.1.2 Definição de tipo de documento (DTD)
Conforme Deitel e outros (2003), um DTD tem como objetivo definir a estrutura de
um documento XML, ou seja, quais os elementos e atributos que um XML pode
conter. Não é obrigatório que um XML possua um DTD correspondente, mas é uma
prática recomendada para manter a conformidade do documento, especialmente em
transações business-to-business (B2B), nas quais são intercambiados documentos
XML.
Um XML que está em conformidade com seu correspondente DTD é considerado
válido. Caso um XML não esteja de acordo com o DTD, mas esteja sintaticamente
correto, ele é considerado um documento bem formado, porém não válido. Os
20
analisadores sintáticos responsáveis por verificar se um XML está em conformidade
com o DTD são denominados analisadores sintáticos validadores (Deitel e outros,
2003).
A figura 1.3 exemplifica um documento XML que possui uma referência externa a
um DTD (intro.dtd) no “DOCTYPE”, denominada “myMessage”, que é o nome do
elemento raiz. O elemento raiz “myMessage” possui um único elemento filho
chamado “message”. Na figura 1.4, consta a declaração do elemento “myMessage”,
que contém a especificação de conteúdo “message”, ou seja, o conteúdo permitido
para o elemento “myMessage” é o elemento filho “message”. Além disso, declara
também o elemento “message”, cujo conteúdo é do tipo “PCDATA” (Deitel e outros,
2003).
Figura 1.3 – XML declarando a sua DTD associada (Deitel e outros, 2003, p.178)
Figura 1.4 - Exemplo de DTD (Deitel e outros, 2003, p.179)
1.1.3 Esquemas XML
Os esquemas XML, assim como os DTDs, definem a estrutura de um documento
XML. Ao contrário dos DTDs, os esquemas não utilizam a gramática EBNF
21
(Extended Backus-Naur Form) e sim a própria sintaxe do XML. A principal vantagem
que se obtém é que, por serem documentos XML, os esquemas podem ser
manipulados, ou seja, pesquisados, transformados em representações diferentes
como o HTML, etc. (Deitel e outros, 2003).
Semelhantemente aos DTDs, os esquemas podem também ser usados com
analisadores sintáticos validadores a fim de validar um documento XML (Deitel e
outros, 2003).
A figura 1.5 descreve um documento esquema da Microsoft, onde o elemento
“ElementType” define um elemento, contendo atributos que descrevem seu
conteúdo, como nome, tipo de dados, entre outros. O “Schema” é o elemento raiz de
cada documento que utiliza o esquema da Microsoft, sendo que o mesmo só pode
conter elementos “ElementType” para definir elementos, “AttributeType” para definir
atributos e “description”, para descrever o elemento “Schema” (Deitel e outros,
2003).
Figura 1.5 - Documento utilizando esquema XML da Microsoft (Deitel e outros, 2003, p.210)
22
1.1.4 Modelo de objeto de documento (DOM)
Quando um documento XML é sintaticamente analisado, é possível que o mesmo
seja representado como uma estrutura hierárquica de árvore na memória. Essa
estrutura contém os elementos dos documentos, dos atributos, entre outros (Deitel e
outros, 2003).
O modelo de objeto de documento (DOM), segundo Deitel e outros (2003), é uma
recomendação padrão fornecida pelo W3C (World Wide Web Consortium -
Consórcio World Wide Web) para a construção de uma estrutura de árvore na
memória para documentos XML, onde cada elemento, atributo, etc., é representado
como um nodo dessa estrutura. Um analisador que segue essa recomendação é
denominado analisador baseado no DOM, que torna disponível uma API (Application
Programming Interface – Interface de Programação de Aplicação) que permite que
os dados de um XML sejam acessados e modificados através da manipulação dos
nodos em uma árvore DOM.
1.1.5 Simples API para XML (SAX)
A SAX foi proposta e desenvolvida em maio de 1998 por membros da XML-DEV
mailing list, que é uma lista de apoio ao desenvolvimento e implementação na área
de XML (XML-DEV mailing list, 2008). A SAX é uma maneira alternativa ao DOM de
analisar documentos XML, que utiliza um modelo baseado em eventos, ou seja,
notificações denominadas eventos são “disparadas” conforme o documento é
analisado (Deitel e outros, 2003).
Com o modelo baseado em eventos, os analisadores baseados na SAX não criam
uma estrutura baseada em árvore na memória (como no DOM). Ao invés disso, os
dados do XML são passados para a aplicação conforme são encontrados,
resultando num melhor desempenho e menor consumo de memória em relação ao
DOM (Deitel e outros, 2003).
23
1.2 SOAP
O SOAP (Simple Object Access Protocol – Protocolo Simples de Acesso à Objeto) é
um protocolo baseado no XML que fornece um simples e leve mecanismo para troca
estruturada de informações entre pontos em um ambiente descentralizado e/ou
distribuído (Simple Object Access Protocol (SOAP) 1.1, 2008). O SOAP foi
desenvolvido para realizar RPCs (Remote Procedure Call – Chamada de
Procedimento Remoto) utilizando XML sobre HTTP, evoluindo posteriormente para
um mecanismo mais geral para troca de mensagens, permitindo assim que fosse
executado em uma gama de protocolos. O fato de ser um protocolo baseado em
padrões abertos permite que o SOAP seja utilizado por qualquer sistema
operacional, inclusive fornecendo interoperabilidade (facilidade de interação) para
dispositivos que operam em sistemas operacionais distintos (Lee e outros, 2005).
O protocolo SOAP é constituído por três partes (Simple Object Access Protocol
(SOAP) 1.1, 2008):
Um envelope que define um framework (conjunto de mecanismos)
geral para expressar o que contém a mensagem, quem deve lidar com
ela, e se ela é obrigatória ou opcional;
As regras de codificação do SOAP, que definem um mecanismo de
publicação serial que pode ser usado para expressar instâncias de
tipos de dados definidos na aplicação;
A Representação de RPC, que define uma convenção que pode ser
usada para representar as chamadas de procedimento remoto e as
respostas.
Segundo Lee e outros (2005), algumas regras para construção e processamento de
mensagens são definidas pelo framework de intercâmbio de mensagens SOAP. Um
envelope SOAP contém um elemento “body” e opcionalmente um elemento
“header”. O “body” contém os dados de mensagem ou, em caso de erro, um
elemento “fault” com as mensagens de erro que foram geradas na chamada do
método. O “header” contém informações adicionais como prioridade da mensagem e
tempo de expiração, que não fazem parte da chamada ao método principal.
24
Pela sua capacidade de transportar dados formatados em XML, o SOAP se tornou
uma ferramenta útil para as empresas que trocam informações pela internet, sendo
um mecanismo alternativo ao protocolo EDI (Eletronic Data Interchange – Troca
Eletrônica de Dados), que foi utilizado por muito tempo pelas organizações (Lee e
outros, 2005).
1.3 WSDL
A WSDL (Web Services Description Language – Linguagem de Descrição de Web
Services), conforme Lee e outros (2005), é basicamente um documento de esquema
XML que fornece uma especificação para descrever um Web Service, contendo
informações sobre tipos de dados, protocolos e mensagens suportados pelo Web
Service. Resumidamente, Web Service é uma tecnologia utilizada na comunicação
entre diferentes sistemas, focando em uma interação simples e padronizada (Silva,
2008).
Um documento WSDL, segundo Lee e outros (2005), contém geralmente os
seguintes componentes:
Service Name – contém o nome do Web Service (serviço);
Port – contém a URL (Uniform Resource Locator – Alocador de
Recursos Universal), ou localização real, do Web Service;
Binding – contém o protocolo de comunicação e o transporte utilizados
pela porta;
Port Type – contém as operações que são suportadas pelo Web
Service;
Messages – contém para cada operação as mensagens de solicitação
e resposta.
25
1.4 SOA
Há algum tempo, a necessidade de se construir aplicações distribuídas (aplicações
que possuem dois ou mais processos que executam em diferentes processadores),
fracamente acopladas (pouco dependentes) e interoperáveis vem sendo satisfeita
com a utilização de diversas tecnologias como RPC e Web Services (Silva, 2008).
A arquitetura SOA (Service Oriented Architecture – Arquitetura Orientada a Serviços)
é um passo recente nesta evolução, se caracterizando por não ser um middleware -
camada de software que gerencia a interação entre aplicações e outros softwares de
rede (Internet2 Middleware Initiative, 2008), uma nova linguagem, um formato de
dados ou protocolo. Mas sim, um paradigma que tem como foco os processos de
negócio, sendo satisfeitos por implementações de serviços através de softwares
discretos, deixando a tecnologia em segundo plano (Silva, 2008).
No ramo dos negócios, pode-se dizer que a SOA, a longo prazo, permite às
organizações aproveitar as aplicações existentes na área de tecnologia da
informação para realizar a integração com os novos processos de negócio
(Gandolpho, 2008).
Segundo Silva (2008), o fato da arquitetura orientada a serviços focar nos processos
de negócio, implica na não existência de uma tecnologia exclusiva para implementar
aplicações SOA, objetivando garantir a interoperabilidade entre os diversos
softwares. Caso uma tecnologia única fosse imposta, poderia ocorrer uma situação
em que uma aplicação não se adaptasse a esta tecnologia, resultando na restrição
da interoperabilidade.
Seguindo esse raciocínio, serão descritas de forma breve, de acordo com Silva
(2008), duas linhagens de tecnologias distintas que se pode utilizar na
implementação do modelo de arquitetura SOA: O WS-* (Web Service asterisco) e o
REST (REpresentational State Transfer - Transferência de Estado
Representacional), também chamado de RESTful.
1.5 Web Services WS-*
No final dos anos 90, as aplicações distribuídas começaram a ser desenvolvidas
utilizando-se HTTP (Hypertext Transfer Protocol – Protocolo de Transferência de
26
Hipertexto) e XML. Porém, em todos os casos, esse desenvolvimento era
personalizado, definindo-se protocolos próprios que variavam de uma
implementação para outra e de uma organização para outra.
Visando-se facilitar a comunicação entre os diversos sistemas e padronizar as
distintas implementações, iniciou-se a linha de arquitetura do WS-*. A nomenclatura
WS-* faz analogia ao número extenso de especificações definidas pelos grupos de
estudo, oferecendo soluções para praticamente todos os problemas que se pode
imaginar em uma arquitetura SOA. Pode-se citar como algumas dessas
especificações a WS-MetadataExchange, que é a especificação para troca de
metadados e a WS-RT ( Web Services Resource Transfer ), que é a especificação
para transferência de recursos ( Acknowledged Member Submissions to W3C, 2008 ).
Porém, na prática, a grande maioria das aplicações dessa família utiliza alguns
recursos básicos como SOAP e WSDL.
A figura 1.6 ilustra de maneira geral como ocorre a comunicação em Web Services
desta linha. Primeiramente, é necessário descobrir aonde se encontra publicado o
serviço no qual se deseja comunicar. Essa descoberta pode ser realizada de duas
formas: Consultando a documentação do serviço existente ou acessando um
repositório UDDI (Universal Description, Discovery and Integration - Integração,
Descoberta e Descrição Universal).
27
Figura 1.6 - Fluxo de comunicação do WS-* (Silva, 2008, p. 39)
Um repositório UDDI é um registro baseado em XML, que permite que um serviço
possa ser publicado ou consultado. Esse repositório foi projetado para ser acessado
através de mensagens SOAP e fornecer os documentos WSDL referentes aos
serviços que se deseja comunicar.
Deve-se destacar a importância do documento WSDL nesta linha de Web Services,
uma vez que o mesmo define, de forma aceita universalmente, como é a interação
entre os serviços publicados e o cliente. A maturidade do padrão WSDL permite que
já existam aplicações geradoras de clientes em diversas linguagens, como Java e
C# (C Sharp), a partir de um documento WSDL.
O SOAP é o protocolo padrão para troca de mensagens entre um Web Service da
linha WS-* e o cliente, sendo transportado no corpo de algum outro protocolo,
geralmente o HTTP. O uso do HTTP é uma maneira muito eficiente de se trafegar as
mensagens SOAP, pois é suportado em um vasto conjunto de dispositivos e
plataformas, além de ser muito confiável.
28
1.6 Web Services REST
O Web Service REST surgiu de uma proposição na tese de doutorado de um dos
principais autores da especificação HTTP – Roy Fieding, tendo como principal
característica a exploração rica do protocolo HTTP, focando na manipulação de
recursos (Silva e Medeiros, 2008).
Ao contrário da linha de arquitetura do WS-*, que é baseada em um protocolo bem
definido, com regras e padrões acordados por grandes corporações de tecnologia, a
arquitetura do Web Service REST é mais flexível, permitindo que, após identificados
os recursos envolvidos nos serviços, seja definido qual será o protocolo de interação
com estes recursos. A figura 1.7 ilustra a arquitetura dos dois estilos de Web
Service.
Figura 1.7 - Estilo de acesso aos serviços com REST e WS-* (Silva, 2008, p. 43)
Diferentemente do Web Service WS-*, que faz uma requisição HTTP POST com os
dados encapsulados dentro de outro protocolo e declarando dentro da mensagem
SOAP qual a operação a ser invocada no serviço, o Web Service REST faz essa
declaração através dos métodos GET, POST, PUT ou DELETE na requisição HTTP,
permitindo ao serviço realizar operações com base no método escolhido. A decisão
29
de como utilizar esses métodos fica a critério de quem está definindo a arquitetura,
sendo que geralmente o método GET é utilizado para buscar o recurso, POST para
cadastrar, PUT para atualizar e DELETE para remover.
A troca de mensagens em um protocolo RESTful se baseia no princípio de que cada
recurso possui um URI (Uniform Resource Identifier - Identificador Uniforme de
Recursos) que referencia um recurso através dos quatro métodos HTTP. Caso seja
uma solicitação HTTP GET ou DELETE (buscar ou deletar), a solicitação para uma
URI é o suficiente, pois o método indica qual a operação será realizada e o recurso
que será manipulado. Caso seja uma solicitação POST ou PUT (cadastrar ou
atualizar), os dados necessários para a operação escolhida devem estar contidos no
corpo da requisição.
1.7 Serviços Orientados a Recursos e Serviços Orientados a
Atividades
Na medida em que se é diversificado o leque de topologias existentes, aumenta-se a
necessidade de se oferecer serviços e realizar integração entre aplicações,
plataformas e organizações diferentes. Diante desse cenário, esses diferentes tipos
de serviços precisam ser classificados (Silva, 2008).
Segundo Silva (2008), existem serviços fortemente associados à recursos, onde se
torna relevante destacar os próprios recursos existentes e as interações que serão
realizadas sobre os mesmos. Nessa faixa de serviços, uma modelagem de uma
solução orientada a recursos utilizando Web Services REST fica bastante clara e
interessante, pois com o uso das capacidades do protocolo HTTP, pode-se chegar a
uma arquitetura bastante escalável.
Além dos serviços associados a recursos, existem também os serviços orientados a
atividades, onde geralmente essas atividades são subdivididas em etapas. Como
exemplo, pode-se citar um serviço responsável por emitir um pedido de compra em
um site de e-commerce (comércio eletrônico), onde a emissão envolve varias etapas
como notificação do setor de cobrança, geração da ordem de entrega para
transportadora, etc. Nessa e em outras situações, a modelagem em torno de
recursos pode se tornar uma tarefa complexa e trabalhosa, sendo mais simples
30
definir os serviços como atividades, uma característica forte do Web Service WS-*
(Silva, 2008).
Conforme Silva (2008), qualquer serviço pode ser implementado com Web Service
WS-* ou Web Service REST, sendo que se deve considerar qual das opções melhor
se aplica as necessidades.
31
2 DISPOSITIVOS MÓVEIS
Este capítulo visa apresentar alguns aspectos relacionados a dispositivos móveis,
tais como seus componentes básicos, os tipos de dispositivos móveis existentes
atualmente e os métodos disponíveis para conexão com uma rede de dados.
2.1 Tipos de Dispositivos Móveis
Atualmente, existem no mercado diversos tipos de dispositivos destinados tanto para
os consumidores em geral quanto para usuários corporativos. Esses dispositivos
móveis possuem características como funções, portabilidade e custo que variam de
maneira relevante (Lee e outros, 2005).
Serão descritos de forma breve, conforme Lee e outros (2005), alguns desses tipos
de dispositivos.
2.1.1 Dispositivos RIM/Pagers
Os Pagers são usados principalmente por profissionais que precisam estar
acessíveis em função da sua capacidade de fazer algo ou perícia, como
profissionais de informática, de saúde, comerciantes entre outros.
Para se realizar uma chamada a um Pager, deve-se telefonar para um serviço de
mensagem e fornecer o número da pessoa no qual se quer manter contato e um
número de telefone ou mensagem que informe onde a pessoa quem ligou pode ser
encontrada. Assim, ao receber o numero de telefone ou mensagem, o proprietário
do Pager pode responder retornando a chamada.
Alguns sistemas atuais suportam a entrega de e-mail sem fio e implementam troca
de mensagens em duas vias, onde o portador do Pager pode retornar uma
mensagem curta.
32
2.1.2 Telefones celulares
Hoje em dia, existe no mercado um leque de telefones celulares destinados aos
mais variados tipos de usuários móveis como consumidores jovens, adultos e
usuários corporativos.
Pode-se observar que nos últimos anos, em termo de funcionalidade, os telefones
celulares avançaram significativamente. Dentre as múltiplas funções e serviços
oferecidos, alem dos mais básicos de telefonia, destacam-se:
Correio eletrônico sem fio;
MMS (Multimedia Messaging Service - Serviço de
Mensagens Multimídia);
SMS (Short Messaging Service - Serviço de Mensagens Curtas);
EMS (Enhanced Messaging Service - Serviço de Mensagens
Melhorado);
Rádio FM;
Câmera Fotográfica;
Acesso à internet;
Jogos.
Apesar desses recursos inovadores, os celulares possuem limitações se
comparados com outros dispositivos móveis, principalmente na interface com o
usuário.
2.1.3 PDAs
Inicialmente, pretendia-se que o PDA (Personal Digital Assistant - Assistente
Pessoal Digital) fosse uma “biblioteca pessoal eletrônica”, possuindo como
funcionalidades básicas um relógio, um calendário, uma relação de telefones para
contatos e uma lista de tarefas.
33
Porém, com os avanços de recursos como CPUs (Central Processing Unit - Unidade
Central de Processamento), sistemas operacionais e memória, os PDAs atuais
possuem outras funcionalidades como:
Correio eletrônico;
Jogos;
Acesso a internet;
Aplicações personalizadas (Java e outros).
A entrada dos dados em um PDA é realizada através de um stylus (caneta) e de tela
sensível ao toque, juntamente com um mecanismo de reconhecimento de escrita.
Um PDA possui ainda um mecanismo de sincronização, no qual o usuário possui
uma cópia local das informações armazenadas num PC (Personal Computer -
Computador Pessoal) desktop, podendo trabalhar desconectado. Quando conectado
no PC através de um cradle (base ou suporte), as atualizações são efetuadas tanto
no PDA quanto no desktop.
2.1.4 Tablet PCs
Um Tablet PC pode ser definido como um computador móvel de uso geral integrado
a uma grande tela interativa, destacando-se pela capacidade de permitir ao usuário
escrever, utilizando uma caneta, direta e confortavelmente sobre a tela.
O Tablet PC possui quase todas as funcionalidades que um PC desktop:
Correio eletrônico;
Acesso a internet;
Jogos;
Aplicações de escritório (processamento de texto, planilhas, etc.);
Multimídia;
Aplicações personalizadas (Java e outros).
34
Um PDA pode ser considerado uma espécie de Tablet PC. Porém, diferentemente
de um PDA, o Tablet PC roda um sistema operacional muito mais poderoso. Uma
desvantagem é que com muito mais recursos e um SO mais poderoso, a
inicialização do dispositivo é bem mais lenta em comparação com um PDA.
2.1.5 PCs laptop
Um PC laptop pode ser definido como um computador móvel de uso geral com uma
grande tela integrada, possuindo como principais dispositivos de entrada o mouse e
o teclado. Ao contrário de um PDA ou um Tablet PC, o laptop não possui tela
sensível ao toque ou a capacidade para entrada com stylus.
Um PC laptop possui basicamente todas as funções de um PC desktop:
Correio eletrônico;
Acesso a internet;
Jogos;
Aplicações de escritório (processamento de texto, planilhas, etc.);
Multimídia;
Aplicações personalizadas (Java e outros).
Um laptop se difere de um PC desktop principalmente pela sua portabilidade e
capacidade de hardware, que geralmente é menor. Porém, pode ser considerado
como o maior dispositivo móvel considerado atualmente portável.
2.1.6 Híbridos
Os dispositivos móveis híbridos surgiram através da combinação das funções
primárias de certos dispositivos móveis com as funcionalidades sobrepostas. Esses
dispositivos fornecem ao usuário a capacidade de ler e-mails, navegar na internet,
editar arquivos, ouvir músicas, assim como efetuar e receber chamadas telefônicas.
Embora possa ser considerada uma vantagem a combinação de inúmeras
funcionalidades dos dispositivos móveis, algumas desvantagens podem aparecer ao
se realizar isso. Por exemplo, um SmartPhone (que integra funcionalidades dos
35
PDAs com funcionalidades dos celulares) que seja do tamanho de um PDA
tradicional pode ser considerado muito grande para ser carregado confortavelmente
junto da orelha, durante uma ligação longa. De maneira inversa, um Smartphone do
tamanho de um celular pode ser considerado pequeno demais para realização de
tarefas como checagem de e-mails, edição de arquivos, etc.
2.2 Componentes de Dispositivos Móveis
Um dispositivo móvel possui inúmeros componentes típicos de um computador
como CPU, memória, portas de conexão, sistema operacional, disco, entre outros
(Lee e outros, 2005).
Serão descritos de forma breve, segundo Lee e outros (2005), alguns desses
componentes.
2.2.1 CPU
A CPU é um componente de importância fundamental para a operação de um
dispositivo móvel. A CPU é responsável por ler e executar instruções, possuindo
uma velocidade de clock máxima que determina a freqüência que essas operações
são executadas, afetando diretamente o desempenho geral do dispositivo.
Na tabela 2.1 pode-se observar aproximadamente as velocidades típicas de CPU
para alguns dispositivos móveis. Os dados não devem ser interpretados com
exatidão, já que se pretende demonstrar apenas as diferenças entre as capacidades
dos dispositivos.
Tabela 2.1 - Velocidades de CPU típicas (Lee e outros, 2005, p.52)
Tipos de dispositivo móvel Velocidades de CPU típicasDispositivo de Pager/RIM 20-40 MHz baseado em 386 da IntelTelefone celular -PDA 200-400 MHz baseado em XScale da IntelTablet PC 1 GHzPC laptop 1-2 GHz
36
2.2.2 Sistemas operacionais
É importante considerar o sistema operacional quando se desenvolve uma aplicação
móvel, pois este afeta a linguagem, as ferramentas e as tecnologias que são
utilizadas, não só no desenvolvimento da aplicação, mas também no suporte e
manutenção do mesmo.
Na tabela 2.2 pode-se observar alguns sistemas operacionais para vários
dispositivos móveis. Os dados não devem ser interpretados com exatidão, já que se
pretende demonstrar apenas as diferenças entre as capacidades dos dispositivos.
Tabela 2.2 - Sistemas operacionais típicos (Lee e outros, 2005, p.53)
Tipos de dispositivo móvel Sistemas operacionais típicosDispositivo de Pager/RIM RIM OS
Telefone celularWindows Mobile 2003 Phone Edition, Psion EPOC, Symbian OS
PDA Windows Mobile 2003, Palm OSTablet PC Windows XP Tablet Edition
2.2.3 Memória
Uma CPU de um dispositivo móvel busca e executa instruções e armazena dados
temporários no dispositivo de memória. Quanto mais memória se pode ter, melhor
será o desempenho do dispositivo móvel. Porém, o fator custo pode restringir a
necessidade de mais memória.
Na tabela 2.3 pode-se observar alguns tamanhos de memória típicos para vários
dispositivos móveis. Os dados não devem ser interpretados com exatidão, já que se
pretende demonstrar apenas as diferenças entre as capacidades dos dispositivos.
Tabela 2.3 - Tamanhos de memória típicos (Lee e outros, 2005, p.54)
Tipos de dispositivo móvel Tamanho típico de memória Dispositivo de Pager/RIM 4 MB-16 MB Flash ROMTelefone celular 56 MBPDA 64 MB SDRAM; 48 MB Flash RomTablet PC 256 MB 1 DDR SDRAMPC laptop 1 GB
37
Em alguns dispositivos móveis como o PDA, a memória é extremamente importante,
pois esses dispositivos não possuem unidade de disco rígido. Uma vantagem é que
a inicialização do dispositivo é muito mais rápida, uma vez que os dados já estão em
memória. Em contrapartida, não se tem um mecanismo de armazenamento de
dados permanente.
2.2.4 Disco
Alguns dispositivos móveis não possuem uma unidade de disco para armazenar
dados permanentemente. A falta de uma unidade de disco em um dispositivo móvel
significa que não se pode contar com a capacidade de armazenamento desses
dispositivos na mesma proporção que um laptop ou PC convencional.
Assim, a forma de armazenamento de dados em um dispositivo que não possua
unidade de disco pode ser considerada transitória, sendo que é conveniente
transferir os dados para um mecanismo confiável o mais breve possível.
A tabela 2.4 mostra alguns tamanhos típicos de disco para alguns dispositivos
móveis. Os dados não devem ser interpretados com exatidão, já que se pretende
demonstrar apenas as diferenças entre as capacidades dos dispositivos.
Tabela 2.4 - Tamanhos típicos de disco (Lee e outros, 2005, p.54)
Tipos de dispositivo móvel Tamanho típico de disco Dispositivo de Pager/RIM -Telefone celular -PDA -Tablet PC 30 GBPC laptop 30-60 GB
2.2.5 Baterias e energia
Um dispositivo móvel é dependente de uma bateria para sua alimentação
simplesmente porque a mobilidade do dispositivo está no fato do mesmo não estar
constantemente ligado à fonte de alimentação principal.
A vida da bateria varia bastante, dependendo de fatores como tecnologia utilizada,
tipo do dispositivo e do uso que dele se faz. Na tabela 2.5 pode-se observar o tempo
de duração das baterias para vários tipos de aparelhos. Os dados não devem ser
38
interpretados com exatidão, já que se pretende demonstrar apenas as diferenças
entre as capacidades dos dispositivos.
Tabela 2.5 - Duração típica de bateria (Lee e outros, 2005, p.55)
Tipos de dispositivo móvel Duração típica de bateria Dispositivo de Pager/RIM SemanasTelefone celular DiasPDA Horas/DiasTablet PC HorasPC laptop Horas
Atualmente, os dispositivos móveis utilizam baterias de íons de lítio. Futuramente
poderão ser utilizadas baterias de polímero de lítio, pois são flexíveis e podem ser
comprimidas em espaços pequenos dentro de um dispositivo móvel. Além das
baterias de polímero de lítio, poderão ser utilizadas também células de combustível,
pois são menos nocivas ao meio ambiente se comparadas com as baterias atuais e
são fontes altamente eficientes de energia.
2.2.6 Portas de conexão
Os dispositivos móveis possuem portas de conexão estrategicamente ocultas em
varias partes deles ou em uma capa adaptada, sendo que cada uma dessas portas
possui um propósito diferente em razão de suas características fundamentais.
A tabela 2.6 mostra as velocidades de várias portas de conexão. Os dados não
devem ser interpretados com exatidão, já que se pretende demonstrar apenas as
diferenças entre as capacidades das portas.
Tabela 2.6 - Velocidades das portas de conexão (Lee e outros, 2005, p.56)
Porta Velocidade típica Bluetooth 56-721 KbpsFirewire 400 MbpsInfravermelho 4 MbpsParalela 50-100 KbpsSerial COM 115-460 KbpsUSB 1.1 1.5-12 MbpsUSB 2.0 1.5-480 MbpsRJ-11 9.6-56.6 KbpsRJ-45 10-100 Mbps
39
Slots de PC Card 10-100 Mbps
A porta infravermelha sem fio (wireless) possui uma faixa de alcance bastante curta
e requer que os dispositivos estejam em linha reta entre si. Ela é bastante utilizada
na sincronização de diversos dispositivos como um laptop, um Pocket PC, entre
outros.
A porta Bluetooth é um pequeno módulo embutido em um dispositivo móvel que
utiliza ondas de rádio para se comunicar com outro dispositivo. Essa porta possui
uma faixa de alcance curta, mas não necessita que os dispositivos fiquem em linha
reta.
A porta USB (Universal Serial Bus - Barramento Serial Universal) ligada a um cabo,
além de ser usada como porta de sincronização entre dispositivos, pode ser usada
como porta do mouse e para conectar impressoras com unidades externas de
armazenamento.
A porta serial COM (Serial Communication - Comunicação em Série), principalmente
utilizada para conexão do mouse, também é utilizada para conexões de impressoras
com unidades externas de armazenamento.
A porta paralela, tradicionalmente utilizada para conexão de impressoras, é utilizada
eventualmente como porta de conexão a dispositivos externos de armazenamento
em massa.
A porta RJ-11 é uma porta para linhas discadas. Apesar de ser lenta em
comparação com algumas redes de alta velocidade e necessite de rede telefônica,
possui uma grande vantagem de funcionar em quase todos os lugares.
A porta RJ-45 é uma porta de alta velocidade para conexões cabeadas em uma
rede. Geralmente, pode-se encontrar esse tipo de porta nos Tablet PCs e laptops,
mas não em telefones celulares, dispositivos RIM e PDAs.
Os slots de PC Card são portas de alta velocidade que permitem que placas de
rede (como a padrão Wireless LAN 802/11) conectadas a cabos ou a redes sem fio
possam ser usadas em um dispositivo móvel.
40
2.2.7 Tela
A tela e a bateria são os componentes que mais contribuem no peso de um
dispositivo móvel. Ou seja, quanto maior for a tela, mais pesado se torna o
dispositivo, contribuindo para uma menor mobilidade.
Atualmente existem dois tipos de tela para os dispositivos móveis: tela plana e tela
sensível ao toque. A tabela 2.7 mostra os tamanhos de tela para vários dispositivos
móveis. Os dados não devem ser interpretados com exatidão, já que se pretende
demonstrar apenas as diferenças entre as capacidades dos dispositivos.
Tabela 2.7 - Tamanho de tela (Lee e outros, 2005, p.57)
Tipos de dispositivo móvel Tamanho típico da tela Dispositivo de Pager/RIM 7,62 cmTelefone celular 3,81 cm
PDA10,16 cm (PC handheld com até 23,87 cm)
Tablet PC 26,42 cmPC laptop 26,42 cm a 40,80 cm
2.2.8 Teclado
Um teclado padrão completo possui as dimensões de 17,78 cm x 45,72 cm, sendo
um tamanho relativamente pequeno para não ser incômodo e grande o bastante
para um adulto digitar de maneira confortável.
Na tabela 2.8, pode-se verificar os tamanhos de teclado para os diversos
dispositivos móveis. Os dados não devem ser interpretados com exatidão, já que se
pretende demonstrar apenas as diferenças entre as capacidades dos dispositivos.
Tabela 2.8 - Tamanho de teclado (Lee e outros, 2005, p.58)
Tipos de dispositivo móvel Tamanho típico da tela Dispositivo de Pager/RIM MiniaturaTelefone celular MiniaturaPDA De nenhum ao muito pequenoTablet PC MédioPC laptop De médio para o tamanho completo
41
Embora tenha sofrido algumas alterações ao longo dos anos, o teclado QWERTY
tem sido utilizado amplamente no ambiente de escritório desde a época das
máquinas de escrever.
2.2.9 Mouse, stylus, caneta e voz
Existem outros componentes, além do teclado, para a entrada de dados em
dispositivos móveis:
Mouses – geralmente incluídos em Tablet PCs e laptops;
Stylus e caneta – utilizados essencialmente para selecionar itens e
escrever, são encontrados geralmente em PDAs com tela sensível ao
toque e em Tablet PCs;
Voz – Emitir instruções por comandos de voz é um método recente,
porém ainda é pouco utilizado.
2.2.10 Periféricos
Os periféricos podem ser definidos como acessórios ou anexos separados do
hardware, mesmo que alguns periféricos sejam atualmente uma parte integrante dos
dispositivos móveis.
Dentre os vários tipos de periféricos pode-se destacar as impressoras, câmeras,
scanners biométricos, entre outros.
Os periféricos quase sempre acompanham um aplicativo ou driver que é instalado
no dispositivo. Uma das principais vantagens dos periféricos é que geralmente
estende as funcionalidades dos dispositivos móveis, tendo como uma desvantagem
o fato de tornar o dispositivo menos portátil, uma vez que afeta a altura e o peso do
mesmo.
2.3 Métodos de conexão
Para se conectar a uma rede, enviar e receber informações, um dispositivo móvel
pode utilizar uma conexão a cabo ou sem fio (Lee e outros, 2005).
Serão descritos de forma breve, segundo Lee e outros (2005), alguns desses tipos
de conexão.
42
2.3.1 Com fio
Um dispositivo móvel pode utilizar uma gama de mecanismos ligados por cabos
para conectar-se a uma rede, sendo que para isso devem possuir uma placa de
rede. Serão descritos nas seções a seguir, alguns desses mecanismos.
Conexão de rede direta. Alguns usuários estão habituados a utilizar no seu
ambiente de trabalho conexões para uma rede Ethernet 10 ou 100 Base-T
(geralmente a taxa de transferência dessas redes é de 10 Mbps ou 100 Mbps). Além
disso, em domicílio os usuários podem criar uma conexão direta de alta velocidade
(geralmente mais velozes que conexões de acesso discado) utilizando DSL ou
modems a cabo.
Cradle. Um cradle é utilizado na transferência ou sincronização de dados entre um
PDA e um computador host (hospedeiro). O cradle e o cabo de sincronização são
componentes básicos em um pacote de PDA.
Acesso discado. O acesso discado é uma das maneiras mais antigas e bem
sucedidas de se conectar a uma rede. Para se conectar, o dispositivo móvel deve
possuir um modem (podendo ser um dispositivo interno embutido em um
computador ou externo), cujo maior taxa aproximada de transferência de dados
atualmente é de 56 Kbps. Geralmente, um usuário que possui esse tipo de acesso
deve ter, alem do hardware necessário, uma conta em um provedor de serviços de
internet ou rede corporativa.
2.3.2 Sem Fio
Existem vários mecanismos sem fio que podem ser utilizados por um dispositivo
móvel para se conectar a uma rede. Serão descritos nas próximas seções, alguns
desses mecanismos.
Celular. As redes celulares são compostas por células – áreas contíguas de
cobertura de rádio chamadas, que em geral são ilustradas como hexágonos e
podem variar em tamanho de aproximadamente 100 jardas até 20 milhas.
Seguem algumas formas de acesso de rede que se inserem no modelo celular:
43
FDMA (Frequency Division Multiple Access – Divisão de freqüência por múltiplo
acesso) – Geralmente usado em redes analógicas como a AMPS (Advanced Móbile
Phone Service – Serviço Avançado de Telefone Celular), que tem o intervalo de
freqüência de 824 Mhz e 894 Mhz, onde cada canal possui a largura de 30 Khz.
TDMA (Time Division Multiple Access – Acesso Múltiplo por Divisão de Tempo) –
Nesse sistema, que trabalha nas faixas de freqüência de 800 Mhz (IS-54) e de 1.900
Mhz (IS-136), é atribuído certa fração de tempo a cada chamada em uma
determinada freqüência. O fato de cada canal de 30 Khz ser dividido em três fatias
de tempos, proporciona a esse tipo de rede trabalhar com um número de chamadas
três vezes maior do que o sistema FDMA.
GSM (Global System for Mobile Communication – Sistema global para
comunicações móveis) – Esse sistema é utilizado para telefonia celular e sistemas
PCS (Personal Communications Service – Serviços de Comunicação Pessoal),
possuindo como método de acesso o TDMA, porém é incompatível com o IS-136. O
GSM é o padrão na Austrália, Europa e na maior parte da África, América do Sul e
Ásia, onde opera nas faixas de freqüência de 900 Mhz a 1.800 Mhz.
IDEN (Integrated Digital Enhanced Network – Rede Digital Integrada Melhorada) –
Esses sistema é utilizado para telefonia celular digital, mensagens de texto, acesso
a internet, entre outros. O IDEN utiliza o TDMA e é executado pela Motorola.
CDMA (Code Division Multiple Access – Acesso Múltiplo por Divisão De Código) –
Nesse sistema é atribuído um código único para cada chamada onde, para
transmissão da chamada por diversas faixas de freqüência, é utilizado um espectro
de difusão. O CDMA pode tratar um número de oito a dez vezes maior de chamadas
se comparado ao sistema AMPS.
PCS – É um sistema sem fio semelhante ao celular digital, que possui células
menores e opera nas faixas de freqüência de 1.850 Mhz até 1.990 Mhz. O PCS é
um sistema baseado no TDMA, porém cada sinal é dividido em oito fatias de tempo
e possui uma largura de 200 Khz. Inclui serviços como e-mail, bina, tele mensagens,
entre outros.
44
Redes de dados. Juntamente com as redes celulares, as redes de dados existem
para prover serviços de dados sem fio. A principal vantagem das redes de dados em
relação às redes celulares é a faixa de cobertura. Em contrapartida, as velocidades
de transmissão de dados são muito menores.
Bluetooth. O Bluetooth é uma especificação de freqüência de rádio de curto alcance
para comunicação entre dispositivos, tendo como principal objetivo a eliminação de
fios de conexão. O Bluetooth trabalha bem dentro de um intervalo de 10 metros e
possui a taxa de transmissão de dados nominal de 1 Mbps, sendo que a taxa real
fica entre 56 kbps e 721 kbps. Essa forma de acesso possui uma tecnologia que não
exige que os dispositivos estejam em linha reta para que a comunicação seja
efetuada.
Quando múltiplos dispositivos são conectados entre si com a tecnologia Bluetooth,
pode-se formar uma PAN (Private area network – Rede de área pessoal), sendo que
um conjunto de dispositivos assim conectados é denominado piconet. Uma piconet
suporta até oito dispositivos conectados e podem existir até dez piconets em um raio
de dez metros.
Rede local sem fio. As redes locais sem fio (Wireless LAN) são freqüentemente
utilizadas em locais de trabalho para permitir que o usuário se desloque por todo o
ambiente conectado a uma rede. Para permitir essa conectividade, uma placa de
rede local sem fio deve ser acoplada a um dispositivo móvel.
Na tabela 2.9 pode-se verificar alguns padrões de rede local sem fio, como o
Wireless LAN 802.11b (conhecido como WiFi – Wireless Fidelity) , bem como suas
velocidades de transmissão de dados. Os dados não devem ser interpretados com
exatidão, já que se pretende demonstrar apenas as diferenças entre as capacidades
dos dispositivos.
Tabela 2.9 - Velocidade de transmissão de dados de rede local sem fio (Lee e outros, 2005,
p.66)
Padrão Velocidade de transmissão de dados Wireless LAN 802.11b 1 Mbps e 11 MbpsWireless LAN 802.11a 54 Mbps
Wireless LAN 802.11g54 Mbps e compatível com Wireless LAN 802.11b
45
Redes de satélite. O GPS (Global Positioning System - Sistema de Posicionamento
Global) é um dos sistemas de redes de satélite mais populares atualmente. Ele é um
sistema de navegação que se baseia em satélites que giram na orbita do planeta
transmitindo sinais. Esses sinais são captados por um dispositivo móvel que possui
um receptor GPS que os utiliza para realizar a triangulação com a posição do
dispositivo.
Atualmente, muitos dispositivos móveis multifuncionais possuem receptores GPS.
Além disso, alguns automóveis possuem sistemas de navegação GPS que ajudam
motoristas provendo serviços de localização.
46
3 SISTEMAS OPERACIONAIS
Este capítulo, além de mostrar a definição de sistemas operacionais, visa apresentar
alguns aspectos relacionados aos mesmos, tais como os tipos de sistemas
operacionais atualmente existentes e alguns componentes que geralmente fazem
parte da estrutura de um SO.
3.1 Definição
Um sistema operacional pode ser definido como uma camada intermediária entre o
hardware e o usuário final. Pode-se dizer que um sistema operacional fornece o
ambiente necessário para que o usuário possa executar programas, tendo como
objetivo principal tornar o uso de um sistema computacional conveniente e como
objetivo secundário usar o hardware do computador de forma eficiente (Silberschatz
e outros, 2000).
Um sistema operacional, de acordo com Silberschatz e outros (2000), é um
componente importante de praticamente todo sistema computacional. Um sistema
computacional é formado basicamente por quatro elementos: O hardware, o sistema
operacional, os programas aplicativos e os usuários (Figura 3.1).
47
Figura 3.8 - Estrutura de um sistema computacional (Silberschatz e outros, 2000, p.3)
O hardware (a CPU, a memória e os dispositivos de entrada e saída), segundo
Silberschatz e outros (2000), fornece os elementos básicos de programação. Os
programas aplicativos (editores de texto, compiladores, etc.) definem as maneiras
como esses elementos serão usados para resolver um determinado problema
computacional de um usuário (os usuários podem ser pessoas, aplicativos ou
computadores que estejam envolvidos no processo).
Um sistema computacional possui muitos recursos que são necessários para
resolver um determinado problema: tempo de CPU, espaço em memória,
dispositivos de I/O (Input/Output – entrada e saída), etc. Desta forma, podemos
definir também que um sistema operacional é um gerente de recursos, pois deve
decidir, entre as solicitações muitas vezes conflitantes, a alocação desses recursos
de maneira justa e eficiente (Silberschatz e outros, 2000).
48
3.2 Componentes de um Sistema Operacional
Para Silberschatz e outros (2000), um sistema operacional é constituído de
componentes (ou sub-partes) básicos que desempenham papéis fundamentais no
gerenciamento de recursos de um sistema computacional. Cada um desses
componentes é uma parte bem delineada do sistema, como entrada, saída, gerência
de memória, gerência de processos, etc. É importante ressaltar que nem todos os
sistemas operacionais possuem a mesma estrutura. Segue de forma breve, segundo
Silberschatz e outros (2000), alguns conceitos dessas estruturas.
3.2.1 Gerência de processos
Um conceito bem simples de processo é que o mesmo pode ser considerado como
um programa em execução. Pode-se citar como exemplo de um processo um
compilador, um processador de textos, uma tarefa de sistema, entre outros.
Alguns recursos do sistema computacional como memória, tempo de CPU e
arquivos são disponibilizados ao processo quando ele é criado, ou quando está em
execução. Quando o processo é finalizado, o sistema operacional poderá solicitar de
volta quaisquer recursos que possam ser utilizados novamente.
Um sistema consiste em um conjunto de processos, sendo que alguns são
processos do sistema operacional (quando executam código do sistema) e outros
são processos de usuário (quando executam código de usuário). Esses processos
podem executar concorrentemente, ou seja, cada um deles utilizará a CPU em uma
determinada faixa de tempo.
Basicamente, em relação a gerência de processos, o sistema operacional realiza as
seguintes funções:
Criação de processos de usuário e de sistema;
Suspensão e retomada dos processos;
Fornecimento de mecanismos de sincronização de processos;
Fornecimento de mecanismos de comunicação de processos;
Fornecimento de mecanismos para tratamento de deadlocks.
49
Um deadlock ocorre quando um processo fica em estado de espera por tempo
indeterminado, pois um recurso que foi solicitado por ele está sendo mantido por
outro processo em espera.
3.2.2 Gerência de memória
A memória principal é um repositório de dados rapidamente acessíveis
compartilhados por outros componentes de um sistema computacional como a CPU
e os dispositivos de I/O. Ela é definida também como um grande vetor de bytes ou
palavras, podendo chegar ao tamanho de bilhões, onde cada palavra ou byte possui
seu próprio endereço.
O processador utiliza a memória para ler instruções durante o ciclo de busca de
instruções e para ler e gravar dados durante o seu ciclo de busca de dados. Alguns
dispositivos de I/O também utilizam a memória parar ler e escrever dados.
Basicamente, em relação à gerência de memória, o sistema operacional realiza as
seguintes funções:
Mantém o controle das partes da memória que estão sendo utilizadas e
quem as utiliza;
Decide qual processo será colocado em memória quando houver
espaço disponível;
Aloca e desaloca espaço da memória.
3.2.3 Gerência de arquivos
Os computadores armazenam informações em diversos meios físicos como fita
magnética, disco magnético e discos ópticos. Esses meios, que possuem suas
próprias características e organização física, são geralmente controlados por
dispositivos como unidades de fita ou disco. Esses dispositivos também possuem
características próprias como velocidade de acesso, taxa de transferência,
capacidade, etc. O sistema operacional, visando abstrair essas características
particulares, define uma unidade lógica de armazenamento - o arquivo - para os
diversos dispositivos de armazenamento de informações.
50
Um arquivo pode ser considerado como uma coleção de informações que
geralmente representam programas e dados. Essas informações podem estar
dispostas como seqüências de bits, bytes, linhas ou registros, cujo significado é
definido pelo criador do arquivo. Além disso, os arquivos podem ser organizados em
uma estrutura de diretórios, facilitando assim o seu uso.
Em relação à gerência de arquivos, o sistema operacional realiza as seguintes
funções:
Criação e exclusão de arquivos;
Criação e exclusão de diretórios;
Fornecimento de suporte a primitivas de manipulação de arquivos e
diretórios;
Mapeamento de arquivos no armazenamento secundário;
Realização de backup de arquivos em meios de armazenamento
estáveis.
3.2.4 Gerencia do sistema de entrada e saída (I/O)
Os sistemas operacionais têm como objetivo tornar transparente ao usuário as
peculiaridades dos dispositivos de hardware específicos. Os subsistemas de entrada
e saída (I/O), responsáveis por esta função, geralmente consistem em:
Um componente de gerência de memória, incluindo armazenamento
em cache, buffering e spooling;
Uma interface geral de dispositivos;
Drivers para dispositivos de hardware específicos.
3.3 Tipos de Sistemas Operacionais
Existe uma variedade de sistemas operacionais, sendo que muitos deles não são
conhecidos. Nesta seção serão descritos de forma breve, segundo Tanenbaum
(2000), alguns desses sistemas operacionais, de acordo com o seu porte.
51
3.3.1 Sistemas Operacionais de computadores de grande porte
(Mainframe)
Conforme citado acima, esses sistemas operacionais são executados em máquinas
de grande porte – aquelas que diferem dos computadores pessoais por sua imensa
capacidade de armazenamento de disco e I/O. Os sistemas operacionais de
computadores de grande porte são utilizados basicamente para processamento
simultâneo de vários jobs (um ou mais programas), requerendo uma quantidade
relevante de I/O.
Esses sistemas geralmente oferecem três tipos de serviços: em lote (batch), onde os
jobs de rotina são processados sem a interação do usuário (como por exemplo uma
rotina de compensação de cheques de um banco); processamento de transações,
onde uma grande quantidade de pequenas requisições são administradas (como por
exemplo um processo de verificações de passagens aéreas); tempo compartilhado,
onde se permite que vários usuários executem seus jobs simultaneamente (como a
execução de consultas a um amplo banco de dados).
Podemos citar como exemplo desse tipo de sistema operacional o z/OS,
desenvolvido pela IBM, que atualmente se encontra na versão 1.10 (IBM: z/OS
Version 1 Release 10, 2008). .
3.3.2 Sistemas Operacionais para servidores
Um nível abaixo dos SOs para dispositivos de grande porte, está o nível dos
sistemas operacionais para servidores. Eles são executados em servidores, servindo
múltiplos usuários de uma vez em uma rede, compartilhando recursos de software e
hardware.
Os servidores podem fornecer diversos tipos de serviços como: serviços de
impressão, de arquivo, de web, de banco de dados, etc. Como exemplo de sistemas
operacionais para servidores pode-se citar o Windows 2003 Server, que é um
sistema operacional desenvolvido pela Microsoft,
52
3.3.3 Sistemas Operacionais de multiprocessadores
Os sistemas operacionais de multiprocessadores são uma variação dos SOs para
servidores, que possuem aspectos particulares de conectividade e comunicação
para atender um sistema composto por múltiplas unidades de processamento
(CPUs). De acordo com a maneira de como estão conectadas as múltiplas CPUs,
esses sistemas podem ser denominados computadores paralelos,
multiprocessadores ou multicomputadores.
3.3.4 Sistemas Operacionais de computadores pessoais
Os sistemas operacionais de computadores pessoais têm como principal objetivo
fornecer uma boa interface para um único usuário. Esses sistemas são bastante
conhecidos e são usados para editores de texto, acesso a internet, jogos, planilhas,
etc. Como exemplos desses sistemas operacionais pode-se citar o Windows 2000,
desenvolvido pela Microsoft, o sistema operacional do Macintosh, Mac OS X,
desenvolvido pela Apple, e o Ubuntu, que é um SO baseado em Linux.
3.3.5 Sistemas operacionais de tempo real
Esses sistemas operacionais possuem como fator crítico o tempo. Por exemplo, se
em uma indústria de fabricação de automóveis um veículo está se movendo pela
linha de montagem, e um robô soldador realiza seu trabalho no instante incorreto,
então o produto estará comprometido. Quando as ações têm de ocorrer em um
determinado instante, ou em um determinado intervalo de tempo, então temos um
sistema operacional de tempo real critico. Quando o descumprimento ocasional de
um prazo é tolerável, temos os sistemas operacionais de tempo real não critico.
O QNX Neutrino RTOS, que é um sistema operacional desenvolvido pela QNX
Software Systems, e o VxWorks, desenvolvido pela Wind River, são exemplos de
sistemas operacionais dessa categoria.
3.3.6 Sistemas operacionais embarcados
Os sistemas operacionais embarcados (ou para computador de mão) são
executados em dispositivos que muitas vezes não são considerados como
computadores, como telefones móveis, geladeiras, microondas, etc. Esses sistemas
geralmente possuem características de sistemas de tempo real e possuem
53
restrições em relação à memória, consumo de energia e outros recursos que os
tornam singulares.
São exemplos de sistemas operacionais para dispositivos embarcados o PalmOS e
o Symbiam EPOC. O PalmOS foi desenvolvido pela Palm Inc. e seu enorme
sucesso deve-se ao fato do mesmo ter sido projetado especificamente para
dispositivos PDAs, ser fácil de usar e oferecer características altamente otimizadas.
O Symbiam EPOC foi desenvolvido pela Psion, escrito em C++, e possui como
características relevantes ser mono-usuário e multitarefa (Araujo, 2003?).
3.3.7 Sistemas operacionais de cartões inteligentes
Os sistemas operacionais de cartões inteligentes (dispositivos do tamanho de um
cartão de crédito que contém um chip de CPU), geralmente sistemas proprietários,
são considerados um dos menores existentes e possuem restrições relevantes de
memória e consumo de energia. Alguns deles realizam apenas uma função, como
pagamentos eletrônicos. Porém, outros podem realizar múltiplas funções em um
mesmo cartão inteligente.
Podemos citar como exemplo desse tipo de sistema operacional o Windows for
Smart Card, que é um sistema operacional da família Windows para cartões
inteligentes, tendo como uma característica relevante o fato de oferecer uma API
para programadores que omite aspectos particulares do cartão e disponibiliza
funcionalidade independente do cartão (Araujo, 2003?).
54
4 ANDROID
Este capítulo visa, além de definir o sistema operacional para dispositivos móveis
Android, apresentar brevemente sua arquitetura, mostrar a estrutura de uma
aplicação Android e abordar alguns aspectos relacionados à segurança deste SO.
4.1 Definição
O Android é um sistema operacional para dispositivos móveis lançado pela Google,
em parceria com mais de trinta empresas (figura 4.1) de diversos ramos, como
operadoras telefônicas, fabricantes de chips, desenvolvedores de software,
formando a Open Handset Alliance (OHA). O Android é definido como a primeira
plataforma open source para dispositivos móveis, uma pilha de softwares, que inclui
um sistema operacional, middleware, e aplicativos centrais (Documentation –
Android, 2008). Segundo a OHA, um dos principais objetivos é fornecer através do
Android uma experiência vasta e melhorada para os dispositivos móveis,
semelhante ao que se têm atualmente nos equipamentos desktop, em contraste com
a limitação funcional dos aparelhos embarcados (Open Handset Alliance, 2008).
Figura 4.9 - Lista das empresas da OHA (Devmedia - Java Magazine - Android, a nova
plataforma móvel - Parte I)
55
4.2 Arquitetura
Um conjunto de componentes forma a arquitetura do sistema operacional Android
(Figura 4.2). Serão descritos brevemente a seguir, segundo What is Android?
(2008), alguns desses principais componentes.
Figura 4.10 - Arquitetura Android (What is Android?, 2008)
4.2.1 Aplicações
O Android foi lançado com um conjunto de aplicações centrais, escritas utilizando a
linguagem de programação Java. Pode-se citar como exemplo dessas aplicações
um cliente de webmail, mapas, browser, programas SMS, calendários, e outros.
4.2.2 Framework de aplicações
O mesmo framework que foi utilizado pelas principais aplicações do sistema pode
ser acessado pelos desenvolvedores que desejam construir uma aplicação Android.
A arquitetura de aplicações foi projetada de tal forma que se permite simplificar a
reutilização de componentes, ou seja, qualquer aplicação pode publicar e fazer uso
56
de funcionalidades publicadas (com exceção das restrições impostas pelo
framework).
Basicamente, as aplicações Android são formadas por um conjunto de serviços e
sistemas, incluindo:
Um rico e extensível conjunto de visões (views) que pode ser usado
para construir uma aplicação, incluindo grades, listas, caixas de texto,
botões, e um navegador web embarcado;
Provedores de conteúdo (content providers) que permitem as
aplicações acessar dados de outras aplicações, ou compartilhar seus
próprios dados;
Um gerenciador de recursos, que provê o acesso a recursos não
codificados como gráficos e arquivos de layout;
Um gerenciador de notificações que permite a todas as aplicações
exibir avisos personalizados na barra de status;
Um gerenciador de atividades que gerencia o ciclo de vida das
aplicações e fornece uma navegação simples através da pilha de
histórico.
4.2.3 Bibliotecas
O Android inclui um conjunto de bibliotecas C/C++ usadas por vários componentes
do sistema Android, sendo que essas funcionalidades são disponibilizadas aos
desenvolvedores através do framework de aplicações do Android. Seguem algumas
das principais bibliotecas:
System C library – Uma implementação do BSD (sistema operacional) derivada do
padrão C system library (libc), voltada para dispositivos embarcados baseados no
Linux.
Media Libraries – Baseado no PacketVideo's OpenCORE, as bibliotecas suportam
playback e gravação de alguns formatos populares de áudio e vídeo, bem como
imagens estáticas, incluindo MPEG4, MP3, AAC, AMR, JPG, PNG, entre outros.
57
Surface Manager – gerenciador de acesso ao subsistema de exibição e as suaves
camadas gráficas 2D e 3D.
LibWebCore – Um moderno engine (motor) para navegador web utilizado no
Android browser e em visualizadores web compactos.
SGL – O fundamental engine gráfico 2D.
3D libraries – Uma implementação baseada na API OpenGL ES 1.0. As bibliotecas
usam o acelerador de hardware 3D (quando disponível) ou o otimizado software de
renderização incluído.
FreeType – Renderização de fontes Bitmap e vetor.
SQLite – Um leve e poderoso engine para banco de dados relacionais disponível
para todas as aplicações.
4.2.4 Android Runtime (Ambiente de execução)
O Android inclui um leque de bibliotecas que fornece a maioria das funcionalidades
disponíveis nas principais bibliotecas do Java.
Com o intuito de se permitir que um dispositivo execute eficientemente múltiplas
máquinas virtuais, foi escrita a máquina virtual Dalvik. Toda aplicação do Android
roda em seu próprio processo, com sua própria instância da maquina virtual Dalvik.
A Dalvik VM executa arquivos do formato “.dex” (Dalvik executável), que é otimizado
para a utilização mínima de memória. A VM é baseada no registro, e executa
classes compiladas pelo compilador Java que foram transformadas no arquivo “.dex”
pela ferramenta “dx” incluída.
A VM Dalvik apóia-se no kernel (núcleo) Linux para as funcionalidades como o
gerenciamento de threads e memória de baixo nível.
4.2.5 Linux Kernel
O Android baseia-se na versão 2.6 do kernel Linux para prover os principais serviços
do sistema: segurança, gerenciamento de memória, gerenciamento de processos,
pilha de rede, etc. O kernel funciona também como uma camada de abstração entre
o hardware e o resto da pilha de software.
58
4.3 Estrutura da Aplicação Android
Uma aplicação Android é basicamente formada por quarto blocos: Activity,
Broadcast Intent Receiver, Service e Content Provider. Não é necessário que uma
aplicação possua os quatro blocos, mas com certeza ela será escrita com a
combinação deles (Anatomy of an Android Application, 2008).
Quando se decide quais serão os componentes necessários para a aplicação, os
mesmos devem ser listados em um arquivo XML chamado AndroidManifest. Esse é
um arquivo onde se declaram os componentes de uma aplicação, suas capacidades
e requisitos (Anatomy of an Android Application, 2008).
Será descrito a seguir, segundo Anatomy of an Android Application (2008), cada um
desses componentes.
4.3.1 Activity
As atividades são as estruturas de construção mais comuns de uma aplicação
Android. Uma activity é geralmente uma tela da aplicação, onde cada uma delas é
implementada como uma simples classe que estende a classe base Activity. A
classe mostrará uma interface de usuário composta de visões (views) e responderá
a eventos. A maior parte das aplicações consiste em múltiplas telas. Por exemplo:
uma aplicação de mensagens de texto provavelmente possui uma tela que mostra
uma lista de contatos para selecionar o destinatário da mensagem, uma segunda
tela para escrever a mensagem e outra tela para visualizar mensagens antigas ou
modificar as opções. Cada uma dessas telas poderia ser implementada como uma
atividade. A navegação de uma tela para outra é realizada pela inicialização de uma
nova activity. Em alguns casos uma activity pode retornar um valor para uma activity
anterior, como por exemplo, uma aplicação que permite um usuário escolher uma
foto poderia retornar a foto escolhida para a atividade que o chamou.
Quando uma nova tela é aberta, a tela anterior é pausada e posta no topo da pilha
de histórico. Este armazenamento prévio das telas na pilha permite que o usuário
navegue entre elas, pois o Android salva a pilha de histórico de cada aplicação
lançada desde a tela inicial. Eventualmente, quando o sistema operacional acha
59
conveniente, as telas são removidas da pilha de histórico para que as mesmas não
permaneçam consumindo recursos.
4.3.2 Intent e intent filters
O Android usa uma classe especial chamada de intent (de “intenção”) para navegar
de tela em tela. Uma intenção descreve o que uma aplicação quer fazer. As partes
mais importantes da estrutura de dados do intent são as ações e os dados sobre os
quais a aplicação vai agir. Os valores padrões para a ação são: MAIN (a porta da
frente da aplicação), VIEW, PICK, EDIT, etc. A informação é expressa como um URI.
Por exemplo, para visualizar informações de uma pessoa da lista de contatos, deve-
se criar uma intent com a ação VIEW e o conjunto de dados que define o URI que
representa aquele contato.
Existe uma classe relacionada chamada intent filter. Enquanto uma intent é
efetivamente uma solicitação para fazer algo, um intent filter é uma descrição de
qual Intent uma activity é capaz de tratar. Uma activity que está apta a mostrar
informações de um contato para uma pessoa poderia publicar uma intent filter que
informa que sabe como tratar a ação VIEW quando forem aplicados os dados que
representam aquele contato. Uma activity publica seus intent filters no arquivo XML
AndroidManifest.
A navegação de tela em tela é consumada através da resolução das intents. Para
navegar para frente, uma activity chama o método startActivity(myIntent). O sistema
procura nos intent filters por todas as aplicações instaladas e seleciona a activity que
melhor se adapta a “myIntent”. A nova atividade é informada da intent, o qual faz
com que a activity seja iniciada. O processo de resolução da intent acontece em
tempo de execução quando o método startActivity é chamado, o que oferece dois
benefícios principais:
Uma atividade pode reusar funcionalidades de outros componentes
simplesmente fazendo uma chamada no formulário de uma intenção;
Uma atividade pode ser substituída por uma nova que possui um intent
filter equivalente.
60
4.3.3 Broadcast intent receiver
Pode-se utilizar um broadcast receiver quando se quer executar algum código da
aplicação em reação a um evento externo, por exemplo, quando um dado de rede
estiver disponível, quando o telefone tocar, quando for meia noite, etc. Os
broadcasts receivers não mostram uma interface de usuário, embora eles possam
utilizar o notification manager para informar ao usuário se algo de importante
aconteceu.
Os broadcast receivers são registrados no arquivo XML AndroidManifest, mas pode-
se também registrá-los no código usando o método Context.registerReceiver(). A
aplicação não precisa estar em execução para que o broadcast receiver seja
chamado, pois o sistema, se necessário, iniciará a aplicação quando um broadcast
receiver estiver ativo. As aplicações podem também enviar seus próprios intent
broadcasts para outras através do método Context.sendBroadcast().
4.3.4 Service
Um serviço (service) é um código que possui “vida longa” e roda sem uma interface
de usuário. Um bom exemplo disso é um media player tocando sons de uma playlist.
Em um media player, provavelmente existe uma ou mais atividades que permitem o
usuário escolher as músicas e tocá-las. Entretanto, o playback da música não pode
ser tratado por uma activity, pois o usuário espera que a música continue após
mudar de tela. Nesse caso, a activity do media player poderia iniciar um serviço
utilizando o método Context.startService() para rodar em background e manter a
música tocando até que o serviço finalize. Note que se pode conectar a um serviço
(e iniciá-lo se o mesmo não estiver em execução) com o método
Context.bindService(). Quando conectado a um serviço, pode-se comunicar com ele
através de uma interface disponibilizada pelo mesmo. Para o service da música, é
possível permitir o usuário “pausar”, rebobinar, etc.
4.3.5 Content provider
As aplicações podem armazenar seus dados em arquivos, em um banco de dados
SQLite, ou em outro mecanismo que suporte este tipo de operação. Um provedor de
conteúdo (content provider), no entanto, é funcional quando se quer compartilhar
dados com outras aplicações. Um content provider é uma classe que implementa um
61
padrão de métodos para permitir que outras aplicações armazenem e recuperem os
tipos de dados que são tratados por determinado provedor de conteúdo.
4.4 Segurança
Para garantir a segurança e a privacidade dos dados dos usuários, o Google
elaborou para a plataforma Android um rico modelo de segurança, que permite aos
desenvolvedores solicitar os recursos ou acessos que suas aplicações necessitam,
além de definir novos recursos que outras aplicações precisem posteriormente. O
usuário Android tem como opção permitir ou negar uma determinada solicitação de
uma aplicação que deseja utilizar-se de um recurso do aparelho (Security, 2008).
O Android é um sistema multi-processado, onde cada aplicação roda em seu próprio
processo. Conceitos de segurança existentes no Linux como grupos de usuários e
ID (identificador) único para cada processo reforçam a segurança entre as
aplicações e o sistema. Além disso, as características de segurança são fornecidas
através de um mecanismo de permissão, que efetua as restrições sobre as
operações especificas que um determinado processo pode executar (Security and
Permissions – Android, 2008).
62
5 O PROJETO
5.1 Objetivo e descrição do projeto
O objetivo deste projeto é propor uma solução de integração entre as tecnologias
Web Service, Java e o sistema operacional para dispositivos móveis Android,
utilizando a metodologia de desenvolvimento SOA. Além disso, construir uma
aplicação para ilustrar a solução proposta. Para facilitar o entendimento, este
capítulo foi subdivido em algumas seções, que descrevem como foi montado o
ambiente de desenvolvimento, quais as ferramentas utilizadas para a depuração e
execução da aplicação que ilustra a proposta e de que forma ocorre a interação
entre os integrantes da solução.
5.2 Solução de Integração
A solução proposta nesse projeto tem como base o esquema de um sistema
cliente/servidor, onde do lado do servidor está um ou mais provedores de serviços
que são disponibilizados por Web Services e no lado do cliente está uma aplicação
móvel, construída em Java e executando em um sistema operacional Android.
5.2.1 Provedor do serviço
Uma organização que adota a metodologia de desenvolvimento SOA pode fornecer
serviços orientados a recursos ou orientados a atividades. Esses tipos de serviços
influenciam diretamente na decisão da tecnologia a ser utilizada para a
implementação dos mesmos. Como foi visto na fundamentação teórica, um Web
Service pode ser utilizado para desenvolver qualquer serviço, sendo mais
recomendado o Web Service WS-* para serviços orientados a atividades e o Web
Service REST para serviços orientados a recursos.
Diante dos fatos apresentados, foi necessário definir qual a tecnologia que seria
utilizada para a implementação de SOA. A tecnologia selecionada foi Web Services
REST, por ser uma tecnologia mais recente e menos consolidada, se comparada
com a linha de Web Services WS-*, possibilitando assim uma maior exploração e
contribuição acadêmica por parte deste projeto.
63
Existe uma série de ferramentas para se construir um Web Service REST, como o
NetBeans, o Eclipse, entre outros . A ferramenta selecionada foi o NetBeans, versão
6.1 (disponível em http://www.netbeans.org/downloads/6.1), por ser uma IDE com
excelente suporte ao desenvolvimento de aplicações. Foram levadas em
consideração questões como a facilidade de desenvolvimento de Web Services
REST, capacidade de integração com o servidor de aplicação (Glassfish) e suporte a
elaboração de diagramas por parte da IDE. O Glassfish foi utilizado como servidor
de aplicação por ser o padrão do NetBeans, ambos desenvolvidos pela Sun, já vindo
como configuração padrão para a execução do Web Service REST.
Para permitir o armazenamento e recuperação das informações acessadas pelo
Web Service, optou-se pelo banco de dados MySql 5.0 Server, por ser um banco de
dados gratuito e que atende as necessidades para esta solução. O banco de dados
Mysql pode ser obtido através do endereço eletrônico
http://dev.mysql.com/downloads/mysql/5.0.html.
O mapeamento das classes do Web Service com o banco é realizado no NetBeans
através da JPA (Java Persistent API). Esse mapeamento pode ser realizado de duas
maneiras: A primeira (e mais simples) é, a partir de uma estrutura criada no banco
de dados, gerar as classes em Java já mapeadas com JPA. Uma vantagem é que o
Netbeans consegue realizar esse procedimento automaticamente, bastando apenas
informar a conexão JDBC e as entidades nas quais se deseja mapear. A outra forma
é, a partir da criação de novas classes Java no projeto, gerar o mapeamento
automatizado com o JPA e posteriormente gerar a estrutura do banco de dados. A
figura na figura 5.1 ilustra o esquema do mapeamento com o JPA.
Figura 5.11 - Mapeamento com JPA
64
Na aplicação desenvolvida para demonstrar a solução, o mapeamento das classes
do Web Service para o banco (utilizando JPA) teve de ser feito manualmente, uma
vez que não foi possível encontrar uma maneira do NetBeans realizar o
mapeamento automático a partir de um diagrama de classes (classes já existentes),
apenas a partir das classes novas para o banco, ou do banco de dados já existente
para as classes Java. Uma vantagem do mapeamento manual é que o mesmo pode
ser customizado para determinadas situações.
Como os serviços são acessados pelo cliente através de requisições HTTP,
informando o método juntamente com a URI, foi necessário realizar o mapeamento
das URIs e métodos HTTP em classes e métodos do Web Service. Para realizar
essa tarefa foi utilizada a JAX-RS - Java API for RESTful Web Services (JSR-311),
que é um padrão de implementação dos serviços do Web Service REST.
O principal objetivo desta JSR (Java Specification Requests - Especificação para
requisições Java) é dar um melhor suporte ao desenvolvimento de serviços REST.
Na JAX-RS, um recurso web é “transformado” em uma classe “Recurso”, sendo que
as requisições ao serviço são tratadas pelos métodos desta classe. A classe
“Recurso” contém as anotações JAX-RS que indicam o mapeamento das operações
disponíveis (Silva e Buback, 2008).
Uma das capacidades que se destaca nessa JSR é a possibilidade de manipulação
de diferentes tipos de conteúdo (content-types) sem muita dificuldade por parte dos
desenvolvedores, permitindo o tratamento de diferentes formatos nos serviços. O
Jersey, que é uma implementação de referência da JSR, já disponibiliza os formatos
XML e JSON (Silva e Buback, 2008).
A figura 5.2 ilustra o mapeamento utilizando a JSR.
65
Figura 5.12 - Mapeamento com a JAX-RS
O esquema do ambiente de desenvolvimento do provedor de serviços pode ser
visualizado na figura 5.3.
Figura 5.13 - Ambiente de desenvolvimento do provedor de serviços
5.2.2 Cliente
O lado do cliente, que consome o serviço, é escrito em Java e executado sobre a
plataforma Android. Para emular essa plataforma foi utilizado o kit de
desenvolvimento de software do próprio fabricante - O SDK Android 1.0 release 1,
que inclui o sistema operacional, um emulador de dispositivo móvel e algumas APIs
para desenvolvimento de aplicações utilizando a linguagem Java. O emulador para
66
dispositivo móvel é necessário em virtude de, durante o desenvolvimento deste
projeto, não haver ainda disponível um hardware que suportasse o Android e
pudesse ser adquirido por um preço acessível. O SDK pode ser adquirido através do
endereço eletrônico http://code.google.com/android/download.html.
Para o desenvolvimento da aplicação cliente, foi utilizado o Eclipse 3.3 Europa, por
ser uma IDE gratuita e com excelente suporte ao desenvolvimento de aplicações.
Além disso, durante o desenvolvimento deste projeto, a única API oficialmente
disponível para integração do SDK Android com uma ferramenta de
desenvolvimento era direcionada ao Eclipse. Essa ferramenta de desenvolvimento
pode ser obtida através do endereço eletrônico http://www.eclipse.org/downloads/.
A interação entre o SDK Android e a ferramenta de desenvolvimento Eclipse é
realizada através do plugin ADT (Android Development Tools - Ferramentas de
Desenvolvimento Android) da Google. Esse plugin é referenciado pelo Eclipse
através da URL https://dl-ssl.google.com/android/eclipse/.
O esquema de desenvolvimento do cliente que consome o serviço pode ser
visualizado na figura 5.4.
Figura 5.14 - Ambiente de desenvolvimento do cliente
Durante o desenvolvimento do consumidor de serviços, não foi possível encontrar
uma maneira de, no Android, se transferir um objeto completo de uma tela para
outra. No desenvolvimento tradicional em Java, este procedimento é realizado
facilmente. A navegação de dados no Android é feita a partir de métodos get e set
da classe bundle, onde a mesma é adicionada no intent que chamará a tela. Para
67
contornar esse problema, cada valor do objeto teve de ser passado através dos
métodos get e set referentes a cada tipo de dados.
Para se exibir uma lista de valores na tela, foi necessário criar uma nova classe
denominada “AdapterMulta”, pois não se conseguiu encontrar uma maneira da
classe Adapter padrão do Android manipular um array de strings, apenas cursores
de banco de dados. Essa nova classe “AdapterMulta” estende a classe BaseAdapter
e sobrescreve alguns métodos.
5.2.3 Integração cliente/provedor de serviços
No ambiente de produção, o Glassfish hospeda o Web Service (provedor de
serviços). A interação entre o Web Service e o banco de dados se dá através do
objeto de mapeamento relacional TopLink, que é responsável por colocar em prática
o mapeamento definido através da JPA. A associação entre os métodos HTTP, URIs
e as classes do Web Service se dá através de componentes do projeto Jersey, que
é a implementação de referência da especificação JSR 311.
O cliente Java executa sobre o sistema operacional Android, que por sua vez pode
rodar em um dispositivo móvel ou no emulador do SDK.
A interação entre a aplicação cliente e o provedor de serviços se dá da seguinte
forma: o cliente solicita um dos serviços disponíveis pelo provedor através de uma
URI e um método HTTP. Caso a solicitação seja válida, ou seja, a URI juntamente
com o método HTTP escolhido sejam associados a um dos métodos do Web
Service, o provedor retorna um XML com o resultado da solicitação (os dados de
retorno no caso do método HTTP GET ou uma confirmação de sucesso da operação
caso sejam outros métodos). Caso ocorra algum problema na transação, um status
HTTP é retornado com uma mensagem informando o erro correspondente.
A figura 5.5 ilustra a integração entre as tecnologias envolvidas no processo.
68
Figura 5.15 - Integração entre tecnologias
5.3 Aplicação Demonstrativa
5.3.1 Descrição
A aplicação “Sistrânsito” tem como objetivo simular uma interação entre o cidadão
comum e o Departamento Estadual de Trânsito (DETRAN) de qualquer unidade da
federação. O cidadão utiliza o sistema desenvolvido na linguagem Java através de
um dispositivo móvel qualquer que possui o sistema operacional Android.
Hipoteticamente, o departamento estadual de trânsito fornece alguns serviços como
consulta às informações de veículos (dados do veículo, dados do proprietário e lista
de multas), consulta às informações de habilitação (dados do condutor e pontuação)
e um “fale conosco”, que permite ao cidadão enviar sugestões ao órgão e consultá-
las posteriormente. A organização implementa, através da tecnologia Web Services,
a metodologia de desenvolvimento SOA, transformando os processos em serviços,
garantindo a interoperabilidade dos diferentes tipos de aplicação existentes e
proporcionando o reuso no desenvolvimento de novas aplicações. Os serviços são
disponibilizados através dos métodos de um Web Service REST, desenvolvido em
Java, sendo que as informações do veículo são requisitadas através do número do
RENAVAM (Registro Nacional de Veículos Automotores) e as informações de
habilitação são solicitadas através do número do registro da carteira nacional de
habilitação (CNH).
69
5.3.2 Estrutura da aplicação
A aplicação “Sistrânsito” está dividida em três módulos principais: Habilitação,
Renavam e Fale Conosco, conforme figura 5.6.
Figura 5.16 - Sistrânsito
As pesquisas disponíveis pelo sistema (consulta de veículos, habilitação e
sugestões) seguem um fluxo padrão, onde primeiramente é executado o método
“Conectar”, tendo como objetivo adicionar o caminho da URL a um objeto do tipo
“URL” e abrir uma conexão. Logo após, o método “Requisitar” é chamado,
recebendo como parâmetro a classe no qual se deseja pesquisar. O papel desse
parâmetro é obter a estrutura do XML a partir do nome da classe. O último passo
desse fluxo é a execução do método equivalente ao conteúdo que se deseja
pesquisar, sendo responsável em dissecar o XML e atribuir cada valor ao seu
respectivo atributo da classe.
70
A figura 5.7 ilustra o retorno de uma consulta de veículo através do RENAVAM e a
figura 5.8 ilustra o XML equivalente ao retorno dessa mesma consulta.
Figura 5.17 - Consulta Sistrânsito
71
Figura 5.18 - XML Consulta RENAVAM
O módulo “Fale conosco” permite que o usuário interaja com o sistema, podendo
enviar sugestões ou críticas e posteriormente consultá-las. O cadastro da sugestão
é feito através do método “enviarFaleConosco”, que recebe como parâmetro o
objeto “faleConosco”, que possui toda a estrutura da mensagem que se deve enviar.
72
No método, são definidos o cliente HTTP, o tipo de requisição, a URL e o cabeçalho
da requisição, sendo que posteriormente é criada a estrutura do XML (que é
adicionada ao corpo da requisição) e definido o seu valor. Após isso, executa-se a
requisição a fim de se obter o “id” de retorno da transação.
5.3.3 Diagrama de caso de uso
A figura 5.9 ilustra o diagrama de caso de uso da aplicação que demonstra a
solução proposta.
Figura 5.19 - Diagrama de caso de uso
5.3.4 Diagrama de classes
A figura 5.10 ilustra o diagrama de classes da aplicação que demonstra a solução
proposta.
73
Figura 5.20 - Diagrama de classes da aplicação
74
CONCLUSÃO
A solução de integração proposta nesse trabalho acadêmico, conforme demonstrado
através da aplicação exemplo “Sistrânsito”, pode ser uma alternativa interessante
para as empresas que visam obter os benefícios proporcionados pela metodologia
de desenvolvimento SOA e agregar mobilidade ao ambiente organizacional, pelo
fato de envolver tecnologias recentes e gratuitas, além de focar na interoperabilidade
entre diferentes aplicações (papel desempenhado principalmente pelo documento
XML).
Além disso, uma das colaborações deste trabalho deve-se ao fato do mesmo
explorar conceitos e funcionalidades de tecnologias atuais, sendo uma contribuição
para os desenvolvedores que desejarem propor outras soluções baseadas nessas
tecnologias, sem ter de começar do marco inicial.
Em relação ao desenvolvimento do consumidor de serviços (cliente Android),
inúmeras dificuldades podem ser destacadas. O plugin ADT, utilizado na integração
entre o SDK Android e o Eclipse, apresenta alguns comportamentos inesperados,
como a desativação da funcionalidade de auto-complemento de código. Esse
problema só é contornado ao se reiniciar a IDE. Além disso, o emulador de
dispositivo móvel também apresenta problemas intermitentes, onde a aplicação
apresenta uma mensagem de erro informando que o módulo “phone” do emulador
parou de responder. Apesar desse problema, ao se clicar na opção de espera, a
aplicação continua executando normalmente.
O fato de o sistema operacional Android ser bastante atual dificulta a resolução
imediata de pequenos problemas relacionados ao desenvolvimento, uma vez que
nem sempre se consegue encontrar a resolução de um empecilho no site oficial do
Android, recorrendo-se então à comunidade de desenvolvedores.
Apesar das inúmeras dificuldades encontradas durante a elaboração deste trabalho,
a proposta de solução de integração entre as tecnologias Java, Web Services e o
Android, utilizando-se SOA, foi desenvolvida e apresentada, conforme o objetivo
75
proposto, podendo ser uma contribuição interessante para quem deseja explorar
mais a fundo estas tecnologias recentes.
Seguem algumas sugestões para trabalhos futuros:
Propor uma solução de integração do Android com Web Services,
focando em serviços orientados a atividades, ou seja, utilizando a linha
de Web Services WS-*;
Propor uma solução que foque na interoperabilidade entre sistemas,
permitindo a manipulação de diferentes tipos de conteúdo, como áudio,
vídeo, entre outros, ou seja, explorar outras ferramentas além da
Jersey que implementem a referência da JSR-311.
76
REFERÊNCIAS
ACKNOWLEDGED Member Submissions to W3C. Disponível na Internet. http://www.w3.org/Submission/. Acesso em 11 dez. 2008.
AMADEI, Daniel C; OLIVEIRA, Willian M. SOA na prática: Veja a realização dos princípios SOA de maneira prática. Java Magazine. ed. 62. Rio de Janeiro. 2008. p.14-24.
ANATOMY of an Android Application. Disponível na Internet. http://code.google.com/android/intro/anatomy.html . Acesso em 4 set. 2008.
ARAUJO, Regina B. Computação Ubíqua: Princípios, Tecnologias e Desafios. XXI Simpósio Brasileiro de Redes de Computadores. [2003?]. Disponível na Internet. http://www.leopoldina.cefetmg.br/moodle/file.php/23/PFC/computacao_ubiqua.pdf . Acesso em 11 dez. 2008.
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 12 dez. 2008.
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 15 nov. 2008.
DEITEL, Harvey M. e outros. XML: Como Programar. Tradução: Luiz A. Salgado e Edson Furmankiewicz. Bookman. 2003.
DEVMEDIA - Java Magazine - Android, a nova plataforma móvel - Parte I. Disponível na Internet. http://www.devmedia.com.br/articles/viewcomp.asp?comp=8431&hl=*android*. Acesso em 4 set. 2008.
DOCUMENTATION – Android. Disponível na Internet. http://code.google.com/intl/pt-br/android/documentation.html . Acesso em 4 set. 2008.
EXTENSIBLE Markup Language (XML). Disponível na Internet. http://www.w3.org/XML/ . Acesso em 15 nov. 2008.
IBM: z/OS Version 1 Release 10. Disponível na Internet. http://www-03.ibm.com/systems/z/os/zos/overview/zosnew_summary.html. Acesso em 10 dez. 2008.
INTERNET2 Middleware Initiative. Disponível na Internet. http://www.internet2.edu/middleware/. Acesso em 11 dez. 2008.
LEE, Valentino; SCHNEIDER, Heather; SCHELL, Robbie. Aplicações móveis: arquitetura, projeto e desenvolvimento. Tradução: Amaury Bentes e Deborah Rudiger. São Paulo. Pearson Education do Brasil. 2005
77
OPEN Handset Alliance. Disponível na Internet. http://www.openhandsetalliance.com . Acesso em 4 set. 2008.
PITTS-MOULTIS, Nathanya; KIRK, Cheryl. XML: Black Book. 1ª ed. São Paulo – SP: Makron Books, 2000.
SECURITY and Permissions – Android. Disponível na Internet. http://code.google.com/android/devel/security.html. Acesso em 4 set. 2008.
SECURITY. Disponível na Internet. http://code.google.com/android/kb/security.html . Acesso em 4 set. 2008.
SILBERSCHATZ, Abraham; GALVIM, Peter; GAGNE, Greg. Sistemas Operacionais: Conceitos e Aplicações. Tradução: Adriana Ceschin Rieche. Rio de Janeiro. Editora Campus. 2000.
SILVA, Bruno L. P; BUBACK, Silvano N. JSR-311 e Jersey: Web Services REST no Java EE. Java Magazine. ed. 60. Rio de Janeiro. 2008. p.72-82.
SILVA, Bruno L. P; MEDEIROS, Alexandre B. Web Services REST: Uma abordagem prática. Java Magazine. ed. 56. Rio de Janeiro. 2008. p.26-36.
SILVA, Bruno L. P. REST vs WS-*: Uma visão pragmática. Java Magazine. ed. 54. Rio de Janeiro. 2008. p.38-47.
SIMPLE Object Access Protocol (SOAP) 1.1. Disponível na Internet. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ . Acesso em 18 nov. 2008.
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 12 dez. 2008.
WHAT is Android?, Disponível na Internet. http://code.google.com/android/what-is-android.html . Acesso em 4 set. 2008.
XML-DEV mailing list. Disponível na Internet. http://www.xml.org/xml-dev. Acesso em 10 dez. 2008.
.
