Your SlideShare is downloading. ×
Mono15122008.doc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Mono15122008.doc

1,712
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,712
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
47
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. FÁBIO DE OLIVEIRA SALES KECYO SACRAMENTO BARROS SOLUÇÃO DE INTEGRAÇÃO ENTRE JAVA, WEB SERVICES E ANDROID, UTILIZANDO A ARQUITETURA SOA SALVADOR 2008
  • 2. FÁBIO DE OLIVEIRA SALES KECYO SACRAMENTO BARROS Solução de integração entre Java, Web Services e Android, utilizando a arquitetura SOA 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 SALVADOR 2008
  • 3. 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
  • 4. 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)
  • 5. 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.
  • 6. 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.
  • 7. 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.
  • 8. LISTA DE FIGURAS FIGURA 1.1 - EXEMPLO DE UM DOCUMENTO XML (PITTS-MOUTS E KIRK, 2000, P.153)................................................................................................................18 FIGURA 1.2 - EXEMPLO DO USO DE ATRIBUTOS EM UM XML (PITTS-MOUTS E KIRK, 2000, P.153).....................................................................................................19 FIGURA 1.3 – XML DECLARANDO A SUA DTD ASSOCIADA (DEITEL E OUTROS, 2003, P.178)..............................................................................................20 FIGURA 1.4 - EXEMPLO DE DTD (DEITEL E OUTROS, 2003, P.179)...................20 FIGURA 1.5 - DOCUMENTO UTILIZANDO ESQUEMA XML DA MICROSOFT (DEITEL E OUTROS, 2003, P.210)............................................................................21 FIGURA 1.6 - FLUXO DE COMUNICAÇÃO DO WS-* (SILVA, 2008, P. 39)...........26 FIGURA 1.7 - ESTILO DE ACESSO AOS SERVIÇOS COM REST E WS-* (SILVA, 2008, P. 43).................................................................................................................28 FIGURA 3.8 - ESTRUTURA DE UM SISTEMA COMPUTACIONAL (SILBERSCHATZ E OUTROS, 2000, P.3).................................................................46 FIGURA 4.9 - LISTA DAS EMPRESAS DA OHA (DEVMEDIA - JAVA MAGAZINE - ANDROID, A NOVA PLATAFORMA MÓVEL - PARTE I)........................................53 FIGURA 4.10 - ARQUITETURA ANDROID (WHAT IS ANDROID?, 2008)..............54 FIGURA 5.11 - MAPEAMENTO COM JPA................................................................62 FIGURA 5.12 - MAPEAMENTO COM A JAX-RS......................................................64 FIGURA 5.13 - AMBIENTE DE DESENVOLVIMENTO DO PROVEDOR DE SERVIÇOS..................................................................................................................64 FIGURA 5.14 - AMBIENTE DE DESENVOLVIMENTO DO CLIENTE......................65 FIGURA 5.15 - INTEGRAÇÃO ENTRE TECNOLOGIAS..........................................67 FIGURA 5.16 - SISTRÂNSITO...................................................................................68 FIGURA 5.17 - CONSULTA SISTRÂNSITO..............................................................69
  • 9. FIGURA 5.18 - XML CONSULTA RENAVAM...........................................................70 FIGURA 5.19 - DIAGRAMA DE CASO DE USO.......................................................71 FIGURA 5.20 - DIAGRAMA DE CLASSES DA APLICAÇÃO..................................72
  • 10. LISTA DE TABELAS TABELA 2.1 - VELOCIDADES DE CPU TÍPICAS (LEE E OUTROS, 2005, P.52). .34 TABELA 2.2 - SISTEMAS OPERACIONAIS TÍPICOS (LEE E OUTROS, 2005, P.53) 35 TABELA 2.3 - TAMANHOS DE MEMÓRIA TÍPICOS (LEE E OUTROS, 2005, P.54) 35 TABELA 2.4 - TAMANHOS TÍPICOS DE DISCO (LEE E OUTROS, 2005, P.54). . .36 TABELA 2.5 - DURAÇÃO TÍPICA DE BATERIA (LEE E OUTROS, 2005, P.55)....37 TABELA 2.6 - VELOCIDADES DAS PORTAS DE CONEXÃO (LEE E OUTROS, 2005, P.56)..................................................................................................................37 TABELA 2.7 - TAMANHO DE TELA (LEE E OUTROS, 2005, P.57).......................39 TABELA 2.8 - TAMANHO DE TECLADO (LEE E OUTROS, 2005, P.58)...............39 TABELA 2.9 - VELOCIDADE DE TRANSMISSÃO DE DADOS DE REDE LOCAL SEM FIO (LEE E OUTROS, 2005, P.66)....................................................................43
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. SUMÁRIO INTRODUÇÃO...........................................................................................................15 1 WEB SERVICES E SOA..........................................................................................17 1.1 XML............................................................................................................................................................17 1.2 SOAP..........................................................................................................................................................22 1.3 WSDL.........................................................................................................................................................24 1.4 SOA............................................................................................................................................................24 1.5 WEB SERVICES WS-*........................................................................................................................................25 1.6 WEB SERVICES REST.........................................................................................................................................27 1.7 SERVIÇOS ORIENTADOS A RECURSOS E SERVIÇOS ORIENTADOS A ATIVIDADES...........................................................................29 2 DISPOSITIVOS MÓVEIS.........................................................................................30 2.1 TIPOS DE DISPOSITIVOS MÓVEIS.............................................................................................................................30 2.2 COMPONENTES DE DISPOSITIVOS MÓVEIS...................................................................................................................34 2.3 MÉTODOS DE CONEXÃO........................................................................................................................................40 3 SISTEMAS OPERACIONAIS..................................................................................45 3.1 DEFINIÇÃO......................................................................................................................................................45 3.2 COMPONENTES DE UM SISTEMA OPERACIONAL.............................................................................................................46 3.3 TIPOS DE SISTEMAS OPERACIONAIS...........................................................................................................................49 4 ANDROID.................................................................................................................53 4.1 DEFINIÇÃO......................................................................................................................................................53 4.2 ARQUITETURA...................................................................................................................................................54 4.3 ESTRUTURA DA APLICAÇÃO ANDROID........................................................................................................................57 4.4 SEGURANÇA.....................................................................................................................................................60 5 O PROJETO.............................................................................................................61 5.1 OBJETIVO E DESCRIÇÃO DO PROJETO..........................................................................................................................61 5.2 SOLUÇÃO DE INTEGRAÇÃO.....................................................................................................................................61 5.3 APLICAÇÃO DEMONSTRATIVA.................................................................................................................................67 CONCLUSÃO............................................................................................................73 REFERÊNCIAS..........................................................................................................75
  • 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 analisadores sintáticos responsáveis por verificar se um XML está em conformidade
  • 20. 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 (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
  • 21. 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). 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
  • 23. 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. 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).
  • 24. 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. 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 -
  • 25. 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 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
  • 26. 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). 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
  • 27. 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. 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.
  • 28. 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 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.
  • 29. 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 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.
  • 30. 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.
  • 31. 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.
  • 32. 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).
  • 33. 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
  • 34. 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ípicas Dispositivo de Pager/RIM 20-40 MHz baseado em 386 da Intel Telefone celular - PDA 200-400 MHz baseado em XScale da Intel Tablet PC 1 GHz PC laptop 1-2 GHz 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
  • 35. 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ípicos Dispositivo de Pager/RIM RIM OS Windows Mobile 2003 Phone Edition, Telefone celular Psion EPOC, Symbian OS PDA Windows Mobile 2003, Palm OS Tablet 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 ROM Telefone celular 56 MB PDA 64 MB SDRAM; 48 MB Flash Rom Tablet PC 256 MB 1 DDR SDRAM PC laptop 1 GB 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
  • 36. 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 GB PC 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 interpretados com exatidão, já que se pretende demonstrar apenas as diferenças entre as capacidades dos dispositivos.
  • 37. 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 Semanas Telefone celular Dias PDA Horas/Dias Tablet PC Horas PC 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 Kbps Firewire 400 Mbps Infravermelho 4 Mbps Paralela 50-100 Kbps Serial COM 115-460 Kbps USB 1.1 1.5-12 Mbps USB 2.0 1.5-480 Mbps RJ-11 9.6-56.6 Kbps RJ-45 10-100 Mbps Slots de PC Card 10-100 Mbps
  • 38. 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.
  • 39. 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 cm Telefone celular 3,81 cm PDA 10,16 cm (PC handheld com até 23,87 cm) Tablet PC 26,42 cm PC 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 Miniatura Telefone celular Miniatura PDA De nenhum ao muito pequeno Tablet PC Médio PC laptop De médio para o tamanho completo
  • 40. 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.10Perifé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.
  • 41. 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: 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
  • 42. 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. 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
  • 43. 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 Mbps Wireless LAN 802.11a 54 Mbps 54 Mbps e compatível com Wireless LAN Wireless LAN 802.11g 802.11b
  • 44. 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.
  • 45. 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).
  • 46. 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). 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
  • 47. 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. 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.
  • 48. 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. 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 é
  • 49. 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.
  • 50. 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,
  • 51. 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
  • 52. 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?).
  • 53. 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)
  • 54. 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
  • 55. 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.
  • 56. 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.
  • 57. 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
  • 58. 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.
  • 59. 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
  • 60. 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).
  • 61. 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.
  • 62. 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
  • 63. 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.
  • 64. 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
  • 65. 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 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.
  • 66. 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.
  • 67. 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).
  • 68. 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.
  • 69. 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
  • 70. 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.
  • 71. 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.
  • 72. Figura 5.20 - Diagrama de classes da aplicação
  • 73. 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
  • 74. 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.
  • 75. 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
  • 76. 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. .