MONO_020709.doc

MÁRCIO ALEXANDRE S MONTEIRO RODRIGO ALMEIDA SAMPAIO PROJETO DE PESQUISA MOBILE: APLICAÇÃO DE BUSCA UTILIZANDO WEB SERVICE WS-* E JAVA EM UMA PLATAFORMA ANDROID SALVADOR 2009

MÁRCIO ALEXANDRE S MONTEIRO RODRIGO ALMEIDA SAMPAIO PROJETO DE PESQUISA MOBILE: APLICAÇÃO DE BUSCA UTILIZANDO WEB SERVICE WS-* E JAVA EM UMA PLATAFORMA ANDROID Monografia apresentada por Márcio Alexandre S Monteiro e Rodrigo Almeida Sampaio como requisito parcial para aprovação na disciplina Projeto Final. Orientador: Prof. Osvaldo Requião Melo SALVADOR 2009

CERTIFICADO Certifico que a presente memória, MOBILE: APLICAÇÃO DE BUSCA UTILIZANDO WEB SERVICE WS-* E JAVA EM UMA PLATAFORMA ANDROID foi realizada sob minha direção por Márcio Alexandre S Monteiro e Rodrigo Almeida Sampaio, constituindo o Projeto Final do Curso do Bacharelado em Informática da Universidade Católica do Salvador – UCSal Salvador, 20 de junho de 2009. Osvaldo Requião Melo Curso de Bacharelado em Informática Universidade Católica do Salvador Salvador 20/06/2009

DEDICATÓRIA Dedicamos esse trabalho realizado a todas as pessoas que contribuíram direta e indiretamente e que nos deram força e motivação no decorrer do semestre desde que iniciamos esse projeto.

AGRADECIMENTOS Agradecemos primeiramente a Deus, posteriormente a nossa família e aos nossos amigos que sempre estiveram ao nosso lado, mesmo nas dificuldades do desenvolvimento do projeto.

RESUMO Este projeto propõe uma comparação entre dois tipos de Web Services: Ws-* e REST, construindo uma aplicação em Java para dispositivos móveis com sistema operacional Android, utililzando o Web Service WS-* para demonstrar o seu funcionamento e realizar uma comparação prática com uma aplicação exemplo previamente construída usando o Web Service REST. Palavras chaves: Android, SOA, Web Services, Java, Dispositivos Móveis. ABSTRACT

This project proposes a comparison between two types of Web Services: Ws - * and REST, building an application in Java for mobile devices with operating system Android, using the Web Service WS - * to demonstrate his operation and to accomplish a practical comparison with an application example previously built using the Web Service REST.

LISTA DE FIGURAS Figura 1.1 - Exemplo de um documento XML..............................................................6 Figura 1.2 - Exemplo do uso de atributos em um XML................................................6 Figura 1.3 - Exemplo de declaração interna de uma DTD...........................................7 Figura 1.4 - Declaração de DTD associada................................................................18 Figura 1.5 - Estilo de acesso aos serviços com WS-*................................................21 Figura 1.6 - Fluxo de comunicação do WS-*................................................................2 Figura 1.7 - Estilo de acesso aos serviços com REST...............................................23 Figura 2.1 - Exemplo de Pager ..................................................................................25 Figura 2.2 - Exemplo de Telefone Celular..................................................................26 Figura 2.3 - Exemplo de PDA.....................................................................................26 Figura 2.4 - Tablet PC Toshiba..................................................................................27 Figura 2.5 - Exemplo de Laptop.................................................................................28 Figura 3.1 - Estrutura de um sistema computacional.................................................37 Figura 4.1 - As camadas da arquitetura Android........................................................46 Figura 5.1 - Código Java e respectivo XML gerado antes da correção.....................53 Figura 5.2 - Código Java e respectivo XML gerado depois da correção....................53 Figura 5.3 - Ambiente de desenvolvimento do provedor de serviços.........................56 Figura 5.4 - Diagrama de caso de uso........................................................................57 Figura 5.5 - Diagrama de classes...............................................................................57 Figura 5.6 - Exemplo de protocolo de comunicação com REST................................59 LISTA DE TABELAS

Tabela 2.1 - Velocidades de CPU típicas...................................................................29 Tabela 2.2 - Sistemas operacionais típicos................................................................29 Tabela 2.3 - Tamanho típico de memória...................................................................30 Tabela 2.4 - Tamanho típico de disco.........................................................................30 Tabela 2.5 - Duração típica de bateria (sob utilização média)...................................31 Tabela 2.6 - Velocidades das portas de conexão.......................................................32 Tabela 2.7 - Tamanho de tela.....................................................................................33 Tabela 2.8 - Tamanho de teclado...............................................................................34 SUMÁRIO INTRODUÇÃO............................................................................................................11

1 WEB SERVICES E SOA.....................................................................................13 1.1 SOA.........................................................................................................................................13 1.4 XML.........................................................................................................................................14 1.2 SOAP.......................................................................................................................................19 1.3 WSDL......................................................................................................................................20 1.5 WEB SERVICES WS-*...................................................................................................................20 1.6 WEB SERVICES REST..................................................................................................................22 1.7 SERVIÇOS ORIENTADOS A RECURSOS E SERVIÇOS ORIENTADOS A ATIVIDADES............................................23 2 DISPOSITIVOS MÓVEIS.....................................................................................25 2.1 TIPOS DE DISPOSITIVOS MÓVEIS.......................................................................................................25 2.2 COMPONENTES DE DISPOSITIVOS MÓVEIS...........................................................................................28 2.3 MÉTODOS DE CONEXÃO...................................................................................................................35 3 SISTEMAS OPERACIONAIS..............................................................................37 3.1 DEFINIÇÃO...................................................................................................................................37 3.2 COMPONENTES DE UM SISTEMA OPERACIONAL.....................................................................................39 3.3 SERVIÇOS DE SISTEMAS OPERACIONAIS.............................................................................................43 3.4 SISTEMAS OPERACIONAIS EMBARCADOS..............................................................................................44 4 ANDROID.............................................................................................................46 4.1 DEFINIÇÃO...................................................................................................................................46 4.2 ARQUITETURA...............................................................................................................................46 4.3 ESTRUTURA DA APLICAÇÃO ANDROID.................................................................................................48 5 O PROJETO........................................................................................................51 5.1 OBJETIVO E DESCRIÇÃO DO PROJETO..................................................................................................51 5.2 SOLUÇÃO DE INTEGRAÇÃO...............................................................................................................51 5.3 APLICAÇÃO DEMONSTRATIVA............................................................................................................55 5.4 COMPARAÇÃO WS-* E WEB SERVICE REST.....................................................................................58 CONCLUSÃO.............................................................................................................61 REFERÊNCIAS...........................................................................................................62

11 INTRODUÇÃO As mudanças nos dispositivos móveis vêm sendo aceleradas, cada vez mais, devido a tendências econômicas, sociais e tecnológicas, aumentando a participação de dispositivos móveis no mercado e a busca por novos serviços para esses dispositivos. O crescimento na aquisição de dispositivos por partes de mercados emergentes, a evolução da internet, levando a novos padrões de uso e a convergência de uma diversidade de dispositivos em um dispositivo de uso geral mais poderoso, são exemplos de tendências econômicas, sociais e tecnológicas, respectivamente (BANERJEE, 2008). Segundo Taurion (2008), como não existe uma padronização para os dispositivos móveis, a situação atual de aplicações para esses dispositivos é bastante complicada. Com a chegada do sistema operacional Android, ocorrerá uma diminuição no trabalho de portar uma aplicação para outros dispositivos móveis e uma diminuição nos custos, já que o Android é um sistema operacional open source (código aberto), não sendo necessário o pagamento de licença, além de um rápido avanço no desenvolvimento de aplicações para esse tipo de dispositivo, já que o código passará a ser desenvolvido de forma aberta. Muitas vezes, os desenvolvedores não possuem critérios plausíveis para definir qual tecnologia deve ser utilizada para se criar uma determinada solução, ficando presos a familiaridades ou preferências que tem por um ou outro modelo e acabam sempre utilizando esse mesmo modelo, mesmo que não seja o mais indicado. A motivação de realizar esse projeto partiu da possibilidade de esclarecer um pouco mais sobre duas tecnologias que acabam sendo utilizadas em situações não indicadas, acarretando em um trabalho maior na implementação de uma solução. O objetivo deste projeto é realizar uma comparação entre Web Service WS-* e Web Service REST, desenvolvendo uma aplicação em Java para um dispositivo móvel com sistema operacional Android, utilizando o Web Service WS-*, para que a comparação possa ser realizada de forma prática com o sistema desenvolvido no projeto anterior, realizado por Fábio de Oliveira Sales e Kecyo Sacramento Barros, onde foi utilizado o Web Service REST. A aplicação desenvolvida neste projeto possui as mesmas características (funcionalidades, telas, etc.) da aplicação desenvolvida no projeto anterior, se diferenciando apenas no tipo de web service utilizado.

12 O trabalho é composto por cinco capítulos, sendo que os quatro primeiros apresentam a fundamentação teórica dos assuntos que estão ligados à solução do problema proposto, como web services, SOA, sistemas operacionais, dispositivos móveis e Android. O primeiro capítulo apresenta os conceitos de web services e dos elementos que estão relacionados ao seu funcionamento, como o protocolo SOAP, o WSDL e o XML que é base desses documentos. Ainda neste capítulo é definido o conceito de SOA e de dois tipos de serviços, orientado a recursos e orientado a atividades. O segundo capítulo engloba os conceitos de dispositivos móveis, abordando os seus tipos, componentes e métodos de conexão. No terceiro capítulo a abordagem é relacionada aos sistemas operacionais, definindo o seu conceito, seus componentes de uma maneira geral e alguns serviços disponibilizados para facilitar a vida dos programadores. O quarto capítulo apresenta as características do sistema operacional Android, como a sua definição, arquitetura e estrutura da aplicação Android. No quinto capítulo é apresentada a solução proposta deste projeto, especificando a aplicação que foi criada, para dar suporte à comparação entre as tecnologias, e as ferramentas utilizadas para esta criação e que dão suporte ao seu funcionamento. Além disso, apresenta a comparação entre os web services REST e WS-*. 1 SOA e Web Services

13 Este capítulo mostra o conceito da arquitetura SOA, Web Services e as tecnologias envolvidas com os dois. Inicialmente é apresentado o conceito de SOA, que será a arquitetura utilizada para o desenvolvimento do projeto. Em seguida é abordado o conceito de XML que é a base para a utilização de diversos documentos, como o SOAP e WSDL. Por fim aborda o conceito de web services e dois tipos de serviços existentes, orientado a recursos e orientado a atividades. 1.1 SOA A necessidade de criação de aplicações distribuídas (aplicações que executam seus processos em processadores diferentes) interoperáveis (aplicações que trocam dados entre si) e fracamente acoplados (com pouca dependência entre seus módulos) já existe há um tempo e tem sido satisfeita com várias tecnologias como RPC (Remote Procedure Call) e Web Services, que será abordado posteriormente. (SILVA, 2008). Segundo Silva (2008), o último passo desta evolução foi o SOA (Service Oriented Architeture – Arquitetura Orientada a Serviços), caracterizado por não ser uma linguagem, middleweare - gerenciador das interações entre aplicações e outros softwares ou a rede (Internet2 Middleware Initiative, 2008), protocolo, nem formato de dados. Na verdade o SOA é independente de tecnologia, deixando-a em segundo plano e tendo como foco principal os processos de negócio, que serão satisfeitos por serviços implementados por componentes de aplicações. Segundo Sampaio (2006), SOA é uma arquitetura onde são criadas funções chamadas de serviços, com pouca dependência, facilitando o reaproveitamento do que já foi feito. A idéia do SOA é criar serviços, (podem ser criados em qualquer linguagem, tecnologia ou plataforma) que tenham baixo acoplamento com seus clientes, atendendo a uma função de negócio específica, recebendo requisições e respondendo a elas sem detalhar o seu processo, ou seja, sem que o cliente saiba como ele foi realizado, já que qualquer componente só é utilizado dentro do código do serviço, sem que clientes tenham acesso. Os serviços não podem depender do estado de componentes externos, sempre executam unidades completas de trabalho. Na Arquitetura SOA quem disponibiliza um serviço é chamado de provedor e quem os utiliza de consumidores. Todo serviço possui uma interface publicada onde um provedor possa acessá-la. Essa interface possui somente as funções

14 importantes, com um alto nível de abstração, mantendo o baixo acoplamento com os clientes. A visão de Silva (2008) aborda brevemente o que antecede a arquitetura SOA, conceituando o que vem a ser essa nova metodologia, citando suas principais características. O foco desta visão é definir o que é o SOA, através de suas características, inclusive deixando claro o que o SOA não é. O conceito de SOA passado por Sampaio (2006), apesar de ser com um foco diferente, nos leva ao mesmo entendimento da visão de Silva (2008), porém o foco do segundo é a abordagem das características do serviço. Quando SOA começou a ser discutido dentro das empresas, era esperada mais agilidade nos processos e redução de custos com sua utilização. Um dos benefícios de utilizar SOA é o reaproveitamento das aplicações, facilitando bastante redesenhar os processos e a integração com o que já existe, acelerando o desenvolvimento de novas aplicações de negócio, tornando a TI muito mais simples para as empresas. O SOA, na verdade, é uma metodologia de desenvolvimento que não está ligado a uma tecnologia específica, mas sim a um conceito, podendo ser considerada uma evolução da arquitetura orientada a objetos (GANDOLPHO, 2008). Alguns especialistas comparam o SOA como um lego, onde suas peças vão sendo encaixadas, mas não deixando a empresa dependente de algum fornecedor específico, pregando uma filosofia de integração entre diferentes tecnologias(SOARES, 2007). Utilizando SOA, as atividades de negócio são feitas por serviços que possuem sua forma de solicitar e responder bem definidas, não importando a forma que estes serviços foram implementados, sendo necessário ser seguro, confiável, rápido e responder aos comandos de forma correta e com qualidade, tornando o SOA indicado para ambientes de TI com diversos fabricantes envolvidos (NETO, 2006). 1.2 XML A XML (Extensible Markup Language – Linguagem de Marcação Extensível) é uma linguagem bastante simples e com grande flexibilidade, desenvolvida pelo W3C (World Wide Web Consortium), para marcação de texto. O que motivou a criação da XML foram limitações encontradas no HTML (HyperText Markup Language – Linguagem de Marcação de Hipertexto), já que o mesmo só permite que o autor utilize determinadas marcas e com o passar do tempo as pessoas passaram a

15 precisar de novas e específicas marcas, tornando o HTML cada vez mais pesado e complexo. Ao contrario disso, a XML permite que o autor crie a marca que desejar, sendo mais extensível (MARCHAL, 2000). Segundo Deitel e outros (2003), a XML permite que os documentos sejam legíveis pelas pessoas e possam ser manipulados pelos computadores, já que possui um conjunto de marcas muito mais poderoso, extensível e flexível comparado ao HTML. Um dos objetivos da XML é permitir que dados sejam transferidos e manipulados através da internet de forma fácil e consistente, possibilitando que aplicações com sistema operacional, plataforma ou linguagem de construção diferente consigam manusear esses dados (PEREIRA, 2002). A XML tem como características principais a sua independência dos dados, separação do conteúdo e sua apresentação. Um documento XML não possui instruções de formatação, facilitando a análise sintática, fazendo com que a estrutura XML possa ser utilizada no intercâmbio de dados (DEITEL et al. 2003). 1.2.1 Elementos e atributos A estrutura básica de um documento XML é formada pelos elementos e atributos. Os documentos XML são compostos de elementos, porém a XML não define os elementos, deixando o autor flexível para definir os elementos de forma que atenda as suas necessidades (MARCHAL, 2000). Segundo Marchal (2000), os elementos de um documento XML são organizados em árvore, sendo cada elemento um nó desta árvore. Os elementos podem estar embutidos em outros elementos, e serão denominados filhos do elemento no qual estiver embutido. Todos os elementos do documento XML serão filhos de um elemento principal, também conhecido como raiz. Na figura 1.1 pode-se verificar um exemplo de um documento XML, onde “<LIVRO>” é a raiz. O elemento “<CAPITULO>”, que é filho de “<LIVRO>”, possui o elemento “<SEÇÃO>” como filho, que é pai do elemento “<PARAGRAFO>”:

16 Figura 1.1 - Exemplo de um documento XML (Pitts-Mouts e Kirk, 2000, p.153) Segundo Marchal (2000), os atributos são utilizados para anexar informações extras aos elementos. Quando os elementos são vazios, eles, geralmente, são colocados no documento devido ao valor de seus atributos. Na figura 1.2 pode-se verificar o mesmo documento da figura 1.1, com o elemento “<LIVRO>” possuindo o atributo “isbn” que representa o número padrão internacional de livro: Figura 1.2 - Exemplo do uso de atributos em um XML (Pitts-Mouts e Kirk, 2000, p.153) 1.2.2 Definição de tipo de documento (DTD)

17 A DTD realiza a definição da estrutura de um documento, identificando os elementos, atributos, etc. que podem ser utilizados no documento. A utilização do DTD não é obrigatória, porém é bastante indicada, pois garante a conformidade do documento, principalmente em transações business-to-business (B2B), quando eles precisam ser intercambiados. As DTDs são definidas através da gramática EBNF (Extended Backus – Naur Form) (DEITEL et al. 2003). Segundo Deitel e outros (2003), analisadores sintáticos realizam uma leitura no DTD e verificam se o documento está de acordo com aquela DTD, caso esteja, o documento é considerado válido. Caso o documento não esteja de acordo, mas esteja sintaticamente correto, ele é considerado bem formado, porém não será válido. Todos os documentos válidos são bem formados. Um documento XML referencia uma DTD na sua declaração de tipo de documento. Essa declaração pode referenciar DTDs externas ou internas ao documento. Na figura 1.3 é possível verificar uma referência interna a DTD “myMessage” (DEITEL et al. 2003). Figura 1.3 – Exemplo da declaração interna de uma DTD (Deitel e outros, 2003, p.177) Na figura 1.4 é possível verificar um documento XML que possui uma referência externa (intro.dtd), no “DOCTYPE”, a DTD “myMessage”, que é o nome do elemento raiz. O elemento “myMessage” possui um elemento filho denominado “message” (DEITEL et al. 2003). Figura 1.4 – Declaração de DTD associada (Deitel e outros, 2003, p.178)

18 1.2.3 Esquemas XML Segundo Deitel et al. (2003), os esquemas XML, assim como os DTDs, são utilizados para descrever a estrutura de documentos e podem ser utilizados como analisadores sintáticos, porém como utilizam sintaxe XML, ao contrário do DTD que utiliza gramática EBNF, é possível manipulá-los, realizando pesquisas, transformando em representações diferentes como HTML, acrescentar ou remover elementos, etc. 1.2.4 Modelo de objeto de documento (DOM) Após serem analisados sintaticamente, os documentos XML são representados em uma estrutura de árvore na memória. O DOM é uma recomendação padrão, fornecida pela W3C, para a elaboração dessa estrutura na memória (DEITEL et al. 2003). Segundo Deitel et al. (2003), os analisadores que seguem essa recomendação são conhecidos como analisador baseado no DOM, onde os elementos, atributos, se tornam nodos na árvore DOM. Esses analisadores disponibilizam uma API (Application Programming Interface – Interface de programação de aplicação), permitindo o acesso e modificação dos dados de um documento XML através da manipulação dos nodos da árvore DOM. 1.2.5 Simples API para XML (SAX) Segundo Deitel et al. (2003), a SAX, desenvolvida por membros da mailing list XML- DEV, foi lançada em maio de 1998 como uma alternativa na análise de documentos XML que utilizam um modelo baseado em eventos, que se caracteriza por “disparar” eventos enquanto o documento é analisado. Diferentemente do DOM, os analisadores baseados em SAX, chamam métodos caso encontrem alguma marcação de abertura ou finalização, por exemplo. Ao invés de criarem uma estrutura de arvore para armazenar os dados, eles passam esses dados para a aplicação no momento que são encontrados, melhorando o desempenho e diminuindo o consumo da memória em relação ao DOM (DEITEL et al. 2003). 1.3 SOAP As empresas DevelopMentor, Microsoft e UserLand Software apresentaram, em 1998, ao W3C (World Wide Web Consortium) o protocolo SOAP. A princípio ele definia uma forma para envio de procedimentos remota XML sobre HTTP, mas por

19 divergências políticas sua especificação só foi feita no ano seguinte (RECKZIEGEL, 2006). Mesmo não sendo necessário conhecer o SOAP para se criar e consumir um Web Service, este protocolo é um dos elementos mais importantes dos Web Services. O conhecimento sobre o protocolo pode ajudar em alguns problemas com a interoperabilidade entre plataformas (RECKZIEGEL, 2006). O SOAP possibilita que dois processos se comuniquem independente do hardware e da plataforma que estejam, sem nenhum vínculo com software ou linguagem de programação. A estrutura do protocolo SOAP possui duas partes principais: a primeira especifica um framework de mensagens, que pode ser um protocolo de rede, como o HTTP, por exemplo, ou um protocolo de mensagem proprietário pode servir como transportador do SOAP. A segunda possui dois componentes opcionais: regras de codificação que expressam instâncias dos tipos de dados que foram definidos pela aplicação e uma representação de RPCs e respostas (RECKZIEGEL, 2006). Segundo Dantas (2007), SOAP (Simple Object Acess Protocol) é um protocolo baseado em XML utilizado para a comunicação entre aplicações num ambiente distribuído. Foi projetado para chamar aplicações remotas utilizando RPC (Remote Procedure Call) ou troca de mensagens, sem que exista dependência de ambiente e linguagem de programação. O protocolo SOAP precisa ser transportado no corpo de outro protocolo, que na grande maioria das vezes é o HTTP, que se torna muito conveniente por ser bastante confiável, ser suportado por muitas plataformas e dispositivos e dificilmente é restringido por algum firewall (SILVA, 2008). 1.4 WSDL Segundo Reckziegel (2006), o WSDL (Web Services Description Language – Linguagem de Descrição de Web Services) realiza a descrição dos serviços externos oferecidos por uma aplicação, apontando a localização dos seus serviços, que já se encontram em um local conhecido da rede, permitindo ao cliente um acesso confiável. A leitura do WSDL é ainda mais fácil, pois é um documento em XML. Os documentos WSDL possuem, geralmente, os seguintes componentes (LEE et. al., 2005):

20 • Service Name – identifica o nome do Web Service; • Port – possui a localização real do Web Service - URL (Uniform Resource Locator – Alocador de Recursos Universal); • Binding – contém o protocolo de comunicação e o transporte utilizados pela porta; • Port Type – identifica quais as operações suportadas pelo Web Service; • Messages – possui as mensagens de solicitação e resposta para cada operação. 1.5 Web Service WS-* As aplicações distribuídas, no final da década de 90, começaram a ser construídas utilizando HTTP (Hypertext Transfer Protocol – Protocolo de Transferência de Hipertexto) e XML, mas eram feitas de forma personalizada por cada desenvolvedor, definindo protocolos próprios que variavam a cada nova implementação e entre as organizações (SILVA, 2008). Com a necessidade de padronizar e facilitar a comunicação entre os sistemas e empresas, foi iniciada a linhagem WS-*, que leva esse nome devido a extensa quantidade de especificações definidas por grupos de estudos dessa área (SILVA,2008). Segundo Silva (2008), no surgimento da linhagem WS-* as suas especificações teóricas foram feitas de forma muito mais rápida do que as implementações práticas, gerando um grande material de regras de utilização sem que essas regras tivessem sido utilizadas na prática. Boa parte dessa documentação não foi validada devido ao extenso uso em aplicações reais e muitas especificações precisaram ser revistas diversas vezes, para que as regras complexas passassem a ser serviços úteis. Entretanto o WS-* disponibiliza soluções para qualquer problema imaginável em arquitetura SOA, mas a grande maioria das aplicações utiliza apenas os recursos básicos, como SOAP e WSDL. Com a utilização de SOAP, geralmente, é feita uma requisição HTTP POST, encapsulando os dados em outro protocolo. (SILVA, 2008). A figura 1.5 mostra como é feito o acesso aos serviços com WS-*:

21 Figura 1.5 – Estilo de acesso aos serviços com WS-*. (SILVA, 2008). O primeiro passo na comunicação é saber onde o serviço desejado está localizado, realizando uma pesquisa ao UDDI (Universal Description Discovery and Integration – Descrição Universal, Descoberta e Integração), que é um repositório baseado em XML, onde os serviços são publicados e consultados. O UDDI é acessado através de mensagens, liberando o documento de especificação dos serviços chamado de WSDL (Web Service Description Language). Neste documento são definidas precisamente, as operações que o serviço disponibiliza, especificando de forma universal as formas de interação entre clientes e serviços, garantindo que qualquer cliente que conheça o padrão estabelecido possa se comunicar de forma correta. Após possuir o WSDL, a comunicação pode ser realizada entre o cliente e o web service utilizando o SOAP, que é protocolo padrão para a comunicação com essa linha de web services (SILVA, 2008). A figura 1.6 ilustra como esse processo é realizado:

22 Figura 1.6 - Fluxo de comunicação do WS-* (Silva, 2008, p. 39) 1.6 Web Service REST Segundo Silva (2008), o web service REST surgiu de uma proposta da tese de doutorado de um dos principais autores do protocolo HTTP, Roy Fielding. Essa tecnologia iniciou com um pequeno conjunto de especificações de fácil compreensão, instruindo como seriam os serviços dessa linha. Com o tempo a utilização de REST aumentou e um melhor entendimento ajudou na identificação de pontos de difícil decisão na arquitetura. Esse aumento na utilização da tecnologia gerou o aparecimento dos padrões de implementação para cobrir pontos abstratos. Só após os primeiros sucessos os esforços para especificação precisa e padronizações começaram, possibilitando a reutilização de idéias, aumentando o nível de abstração. Devido ao progresso, grupos de estudo do IETF (Internet Engineering Task Force), que realizam a padronização dos serviços REST, foram criados (SILVA, 2008). O web service REST utiliza extensamente os recursos do HTTP, declarando a operação através dos métodos GET, PUT, POST ou DELETE. Normalmente o método GET é utilizado para buscar o recurso, PUT para atualizar, POST para cadastrar, e DELETE para remover, mas essas funções são definidas pelo desenvolvedor da arquitetura, que além disso estabelece o protocolo de conversação com os serviços (SILVA, 2008). A figura 1.7 demonstra a forma de acesso aos serviços do Web Service REST:

23 Figura 1.7 – Estilo de acesso aos serviços com REST (SILVA, 2008). Segundo Silva (2008), para realizar a troca de mensagens parte-se do princípio que cada recurso possui uma URI (Uniform Resource Identifier – Identificador Uniforme de Recursos). Para acessar esses recursos é feita uma chamada para a URI correspondente ao recurso desejado. Se for utilizado o método GET ou DELETE (busca e exclusão), apenas o método já é suficiente, pois já define a operação e o recurso a ser manipulado, caso seja POST ou PUT (cadastro e atualização), precisa colocar os dados necessários da operação no corpo da requisição. 1.7 Serviços orientados a atividades e serviços orientados a recursos Com a diversificação das topologias de implementações existentes, aumenta a necessidade de disponibilizar serviços, fazer a integração entre aplicações, plataformas e empresas, fazendo com que serviços de diversos tipos precisem ser criados e classificados (SILVA, 2008). Segundo Silva (2008), existem serviços que são fortemente associados a recursos. Esses serviços precisam ter os recursos e as manipulações sobre estes recursos bem definidas, sendo bastante interessante a criação de uma solução utilizando Web Service REST, explorando as capacidades do protocolo HTTP, conseguindo uma arquitetura com alta escalabilidade. Por outro lado, existem serviços que possuem o foco em atividades, como por exemplo, num processo de compra pela internet onde um serviço emite os pedidos de compra. Antes de realizar a emissão, o serviço realizará diversas etapas, como notificar o sistema de cobrança, enviar e-mail de confirmação para o usuário, etc. Essas etapas também podem ser modeladas como recursos, mas isso tornaria o

24 trabalho muito mais complexo, sendo mais fácil implementar os serviços como atividades, que é uma característica dos serviços WS-* (SILVA, 2008). Segundo Silva (2008), pode-se utilizar o Web Service REST ou o WS-* para a implementação de qualquer serviço, verificando apenas qual deles se aplica melhor a solução que será desenvolvida. 2 Dispositivos Móveis

25 Este capítulo apresenta alguns conceitos a respeito de dispositivos móveis, abordando os tipos, seus componentes e os métodos de conexão com os mesmos. 2.1 Tipos de dispositivos móveis Existem inúmeros tipos de dispositivos no mercado atualmente, voltados tanto para os consumidores corporativos quanto para os consumidores em geral. As funções, portabilidade, e custo variam consideravelmente entre cada um deles. Com essas diferenças os dispositivos móveis podem ser classificados como dispositivos RIM/Pagers, telefones celulares, PDAs, Tablet PCs, Pcs Laptops e híbridos (LEE et. al., 2005). Esses grupos de classificação serão detalhados abaixo: 2.1.1 Dispositivos RIM/Pagers Este é um dispositivo eletrônico que foi muito utilizado durante os anos 1980 e 1990. Ele utiliza transmissões de radio para interligar um centro de controle de chamadas e destinatários. Os primeiros pagers funcionavam da seguinte forma: O usuário recebia um bip sonoro que indicava o recebimento de uma mensagem. Logo após ele deveria telefonar para o centro de controle de chamadas para receber as mensagens de um operador. Os pagers mais novos já recebiam mensagens digitais e em alguns modelos já enviavam também (WIKIPEDIA, 2007?). É possível visualizar o exemplo de um Pager na figura 2.1: Figura 2.1 – Exemplo de Pager (WIKIPEDIA, 2007?). 2.1.2 Telefones celulares É um dispositivo de computação móvel que inicialmente tinha uma tela pequena e quase nenhum recurso. Atualmente já dispõe de aparelhos de memória expansível, tecnologia Bluetooth, suporte ao Java etc. Os aparelhos mais modernos são chamados de Smartphones que alem da funcionalidade básica de telefone tem funcionalidades dos PDAs (JOHNSON, 2007).

26 Figura 2.2 – Exemplo de Telefone Celular 2.1.3 PDAs O PDA (Personal Digital Assistant - Assistente Digital Pessoal) é um dispositivo de tamanho reduzido que foi projetado inicialmente para ser um organizador pessoal que fazia cálculos. Com a evolução ele ganhou diversas outras funcionalidades, como ferramentas de produtividade, sincronização de dados, acesso Wi-Fi (Wireless Fidelity) e outras (QUEIRÓS, 2008). Figura 2.3 – Exemplo de PDA 2.1.4 Tablet PCs Um Tablet PC pode ser definido como um pequeno notebook, que possui sua tela com sensibilidade ao toque. Utilizado como um computador de mão, possui praticidade de inserção de dados. Seu formato se assemelha a uma prancheta, por isso recebe o nome de Tablet PC. A tela possibilita o reconhecimento da escrita do usuário através de canetas especiais, também utilizadas em palmtops (AYRES, 2007).

27 Na figura 2.4 é possível visualizar o exemplo de um Tablet PC: Figura 2.4 – Tablet PC Toshiba (WIKIPEDIA, 2009?). 2.1.5 PCs laptop O PC laptop (também conhecido como notebook) é um computador móvel e leve, para ser transportado facilmente e utilizado em diversos locais. Normalmente, esse tipo de dispositivo possui uma tela LCD (cristal líquido) e como dispositivos de entrada de dados, um mouse e um teclado. O PC laptop possui todos os recursos de um desktop, diferenciando apenas na sua portabilidade. Se verificado no dicionário, existe uma pequena diferença no conceito de notebook e laptop, onde o notebook é considerado, aproximadamente, do tamanho de um caderno e maior do que um PC Laptop, porém na linguagem popular as duas nomenclaturas são utilizadas para os mesmos dispositivos (WIKIPEDIA, 2007?). Na figura 2.5 é possível visualizar o exemplo de um PC Laptop: Figura 2.5 – Exemplo de Laptop (WIKIPEDIA, 2007?). 2.1.6 Híbridos

28 A combinação de algumas funções de certos dispositivos móveis resultou em novos dispositivos móveis, com funcionalidades sobrepostas, conhecidos como híbridos. Embora seja possível realizar a combinação de diversas funções, algumas desvantagens também podem ser encontradas, como por exemplo, o aumento de tamanho do telefone celular para poder suportar novas funções pode deixar a função básica de comunicação telefônica menos confortável ou caso o telefone celular possua um tamanho pequeno, a tela pode ser desagradável para realizar determinadas funções que eram realizadas em outros dispositivos com telas maiores (LEE et. al. 2005). 2.2 Componentes de dispositivos móveis Os dispositivos móveis possuem diversos componentes que também são encontrados nos computadores, como uma CPU, sistema operacional, memória, disco, baterias e fonte de alimentação, portas de conexão, tela, teclado, mouse e um conjunto de periféricos (LEE et. al., 2005). Alguns desses componentes serão descritos. 2.2.1 CPU Segundo Lee et. al. (2005) a CPU possui grande importância para a operação de um dispositivo móvel. A CPU determina a frequência máxima de leitura e execução das instruções. De um modo geral, quanto mais rápida for a CPU, mais caro será o dispositivo móvel, pois o desenvolvimento de CPUs mais avançadas é mais caro. Na tabela 2.1 é possível observar a velocidade aproximada da CPU para alguns dispositivos móveis. Tabela 2.1 – Velocidades de CPU típicas (LEE et. al., 2005, p.52). Tipos de dispositivos móveis Velocidade de CPU típicas Dispositivo de Pager/RIM 20-40 baseado em 386 Intel Telefone celular - PDA 200-400 baseado em XScale da Intel Tablet PC 1 GHz PC laptop 1-2 GHz 2.2.2 Sistema Operacional

29 Antes de implementar uma aplicação móvel, é preciso verificar o sistema operacional do dispositivo para o qual irá desenvolver, pois o ele influencia na linguagem, ferramentas e tecnologias que o desenvolvedor irá utilizar e no suporte e manutenção da aplicação (LEE et. al. 2005). Na tabela 2.2 é possível verificar alguns sistemas operacionais para alguns tipos de dispositivos móveis. Tabela 2.2 – Sistemas operacionais típicos (LEE et. al. 2005, p.53). Tipos de dispositivo móvel Sistemas operacionais típicos Dispositivo de Pager/RIM RIM OS Windows Móbile 2003 Phone Edition, Psion Telefone celular EPOC, Symbian OS PDA Windows Mobile 2003, Palm OS Tablet PC Windows XP Tablet Edition 2.2.3 Memória Segundo Lee et. al. (2005), a CPU de um dispositivo móvel guarda informações temporárias e realizar a busca e execução de suas instruções na memória. O ideal é possuir tanta quanto for possível para se obter um melhor desempenho, mas deve- se considerar o custo. Segundo Lee et. al. (2005), nos PDAs, a memória é ainda mais importante, já que o mesmo não possui disco rígido e depende dessa memória para armazenar dados. Essa característica possibilita uma inicialização mais rápida do dispositivo em comparação a um computador normal, mas por outro lado, não permite o armazenamento de dados permanentemente. Na tabela 2.3 são apresentados alguns tamanhos de memória que normalmente são encontrados em alguns dispositivos. Tabela 2.3 – Tamanho típico de memória (LEE et. al. 2005, p.54). Tipos de dispositivos móveis Tamanho típico de memória Dispositivo de Pager/RIM 4 MB-16 MB Flash ROM Telefone celular 56 MB PDA 64 MB SDRAM; 48 MB Flash ROM Tablet PC 256 MB 1 DDR SDRAM

30 PC laptop 1 GB 2.2.4 Disco Nem todos os dispositivos móveis possuem um disco rígido para armazenamento de dados permanentemente. Os PDAs, em geral, são um exemplo de dispositivo móvel sem disco rígido, não permitindo que se tenha uma capacidade de armazenamento com as de um computador de mesa ou laptop. O armazenamento, nesses dispositivos que não possuem discos, pode ser considerado transitório, onde geralmente os dados são transferidos para um sistema confiável quando possível. (LEE et. al. 2005). Na tabela 2.4 são apresentados tamanhos típicos de discos para dispositivos móveis. Tabela 2.4 – Tamanho típico do disco (LEE et. al. 2005, p.54). Tipos de dispositivos móveis Tamanho típico do disco Dispositivo de Pager/RIM - Telefone celular - PDA - Tablet PC 30 GB PC laptop 30 – 60 GB 2.2.5 Baterias e energias Segundo Lee et. al. (2005) as baterias são muito importantes para os dispositivos móveis, pois como o próprio nome diz, eles precisam de mobilidade, não podendo ligado à fonte de energia principal constantemente. Segundo Lee et. al. (2005), a duração da bateria varia de acordo com o dispositivo móvel, do uso que se faz dele e da tecnologia da própria bateria. Atualmente são utilizadas baterias de íons de lítio, mas futuramente baterias de polímero de lítio poderão ser utilizadas, pois são flexíveis e podem ser comprimidas em pequenos espaços dentro de um dispositivo móvel. Células de combustível também poderá ser

31 uma opção, pois são muito eficientes e agridem menos o meio ambiente em relação às baterias atuais. Na tabela 2.5 pode-se verificar a duração de baterias para alguns dispositivos móveis. Tabela 2.5 – Duração típica de bateria (sob utilização média) (LEE et. al. 2005, p.55). Tipos de dispositivos móveis Duração típica de baterias Dispositivo de Pager/RIM Semanas Telefone celular Dias PDA Horas/Dias Tablet PC Horas PC laptop Horas 2.2.6 Portas de conexão As portas de conexão estão normalmente ocultas em diversas partes do dispositivo móvel ou através de uma capa adaptada. Dispositivos como o Tablet PC e PCs laptop, normalmente, possuem diversas portas de conexão devido a possuírem um tamanho maior, entretanto os dispositivos menores, normalmente, não possuem portas ou então eles possuem uma capa externa adaptada acrescentando as portas de conexão. Na tabela 2.6 são apresentadas velocidades típicas de portas de conexão. Tabela 2.6 – Velocidades das portas de conexão (LEE et. al. 2005, p.56). Porta Velocidade típica Bluetooth 56 -721 Kbps Firewire 400 Mbps Infravermelho 4 Mbps Paralela 50 – 100 Kbps COM serial 115 – 460 Kbps USB 1.1 1.5 – 12 Mbps

32 USB 2.0 1.5 – 480 Mbps RJ-11 9.6 – 56.6 Kbps RJ-45 10 – 100 Mbps Slots de PC Card 10 – 100 Mbps Segundo Lee et. al. (2005) as portas têm características fundamentais, fazendo com que cada uma tenha um propósito levemente diferente. A porta infravermelha, por exemplo, é geralmente utilizada para sincronizar Pocket PC, um PC laptop e um computador de mesa, tendo a necessidade de os dispositivos estarem próximos um do outro, pois possui baixo alcance, e em linha reta entre si. A porta Bluetooth é um modulo de rádio embutido nos dispositivos móveis realizando a comunicação com outros dispositivos através de ondas de rádio. O seu alcance é relativamente curto, porém não necessita que os dispositivos estejam em linha reta entre si. A porta USB (Universal Serial Bus – Barramento Serial universal), pode ser conectada a um mouse, impressoras, unidades de armazenamento externas e na sincronização entre dispositivos. A porta COM serial normalmente é utilizada para a conexão de um mouse, mas também pode ser utilizada para conectar uma impressora ou unidades de armazenamento externas. A porta Paralela normalmente é utilizada para a conexão de impressoras. Ocasionalmente é utilizada na conexão com dispositivos de armazenamento de massa. A porta RJ-11 é utilizada na conexão com linha telefônica. Possui uma velocidade baixa quando comparada com linhas de rede de alta velocidade, porém funciona em quase todos os lugares. A porta RJ-45 é de alta velocidade e permite conexões cabeadas para uma rede. Normalmente são encontradas em Tablet PCs e PCs laptop, mas não em dispositivos RIM, telefones celulares e PDAs. Os slots de PC card são de alta velocidade e possibilitam que placas de rede conectadas a cabos ou redes sem fio sejam utilizadas no dispositivo móvel. 2.2.7 Tela

33 Segundo Lee et. al. (2005), a grande a maioria, ou até mesmo todos, dos dispositivos móveis possuem telas planas. A tela é um dos componentes que mais influencia no peso do dispositivo, quanto maior a tela, maior será o peso do dispositivo e menor será sua mobilidade. Na tabela 2.7 são apresentados tamanhos de tela utilizados em alguns dispositivos móveis. Os dados não devem ser considerados exatos. Tabela 2.7 – Tamanho de tela (LEE et. al. 2005, p.57). Tipos de dispositivos móveis Tamanho típico de tela Dispositivo de Pager/RIM 7,62 cm Telefone celular 3,81 cm PDA 10,16 cm Tablet PC 26,42 cm PC laptop 26,42 cm a 40,80 cm 2.2.8 Teclado O teclado padrão com o tamanho 17,78 cm x 45,72 cm é considerado grande para um adulto digitar confortavelmente e pequeno para não incomodar (LEE et. al. 2005). Na tabela 2.8 são apresentados tamanhos de teclado para alguns dispositivos móveis. Tabela 2.8 – Tamanho de teclado (LEE et. al. 2005, p.58). Tipos de dispositivos móveis Tamanho típico de teclado Dispositivo de Pager/RIM Miniatura Telefone celular Miniatura PDA De nenhum ao muito pequeno Tablet PC Médio PC laptop De médio a tamanho completo 2.2.9 mouse, stylus, caneta e voz

34 Outros mecanismos são utilizados, além do teclado, para a inserção de dados em dispositivos móveis: o mouse, que normalmente é encontrado em Tablet PCs e PCs laptop, o stylus e a caneta que são apontadores para escrever e selecionar itens, muito utilizados em PDAs com tela sensível ao toque e em Tablet PCs. Além desses mecanismos também é possível passar instruções através da voz, (LEE et. al. 2005). 2.2.10 Periféricos Segundo Lee et. al. (2005), existem diversos acessórios e anexos que podemos classificar como periféricos. O periférico é um item separado do hardware, porém muitos já passaram a fazer parte integrante dos dispositivos móveis. São exemplos de periféricos: • Impressoras • Câmeras • Scanners de código de barras • Scanners biométricos • Scanners de localização Os periféricos normalmente são anexados ao dispositivo móvel, necessitando a instalação de um driver no dispositivo em que vai ser utilizado. Apesar de acrescentar funcionalidade ao dispositivo, um periférico pode também dificultar sua mobilidade, já que interfere na altura e no peso do dispositivo (LEE et. al. 2005). 2.3 Métodos de conexão Segundo Lee et. al. (2005), a conexão dos dispositivos móveis a uma rede para enviar e receber informações pode ser feita através de cabos ou até mesmo sem fio. Estaremos abordando alguns mecanismos para realizar essa conexão. 2.3.1 Com fio Segundo Lee et. al. (2005), existem diversas formas para um dispositivo móvel se conectar a uma rede através de cabos. Por exemplo: • Conexão de rede direta – é necessário que o dispositivo possua uma placa de rede. Os Tablet Pcs e PCs laptop, normalmente já possuem essa placa. Esse tipo de conexão, em geral, possui uma taxa de transferência dos dados de 10 Mbps ou 100 Mbps. • Cradle – é utilizado na conexão entre um PDA e um computador. O usuário coloca o PDA no cradle e o mesmo é conectado ao

35 computador através de um cabo, possibilitando a conexão entre os dois dispositivos. • Acesso discado – é umas das formas mais antigas para a conexão em uma rede. É necessário que o dispositivo possua um modem embutido ou externo. Esse tipo de conexão, em geral, transfere dados a 56 Kbps. 2.3.2 Sem fio Segundo Lee et. al. (2005), alguns dispositivos móveis utilizam conexões de rede sem fio para se comunicar. Existem diversos mecanismos para que estes dispositivos possam realizar essa comunicação. Por exemplo: • Redes de Celular – as redes de celulares possuem conjuntos de áreas com cobertura de rádio conhecida como células. Essas áreas têm um tamanho limitado e enquanto o usuário estiver dentro dela, conseguirá enviar e receber dados. Caso o usuário se desloque de uma célula para outra, a rede, automaticamente, passa o usuário para uma nova célula, no caso de ser uma boa cobertura, sem que a transmissão ou recebimento de dados seja interrompido. • Redes de dados – da mesma forma que as redes de celulares, as redes de dados disponibilizam serviços de dados sem fio, com a vantagem de possuir uma cobertura maior do que a de celulares, porém com a velocidade de transmissão muito menor. • Bluetooth – essa tecnologia permite a conexão a diversos dispositivos eletrônicos, como celulares, impressoras, PCs laptop. Como um mecanismo para conexão sem fio, o Bluetooth tem o objetivo de eliminar os cabos, porém os dispositivos precisam estar próximos para funcionar bem. • Rede local sem fio – normalmente são utilizadas em escritórios, possibilitando que usuários estejam conectados em qualquer lugar do edifício. Esse tipo de rede já é utilizado em locais aberto ao público, como hotéis e aeroportos para fornecer acesso sem fio à internet. • Redes de satélite – o uso mais conhecido desse tipo de rede é o GPS (Global Positioning System – Sistema de posicionamento

36 Global) que utiliza satélites do departamento de defesa dos Estados Unidos. O dispositivo móvel precisa ter um receptor de GPS que capta os sinais dos satélites para identificar o posicionamento daquele dispositivo. É necessário existir uma linha de visão entre o dispositivo e o satélite. 3 Sistemas Operacionais Este capítulo inicia com a definição do que é um sistema operacional, em seguida aborda os seus componentes e os serviços que são disponibilizados por um sistema operacional na tentativa de facilitar a utilização dos usuários. 3.1 Definição Um sistema operacional é a interface entre o usuário e o hardware do computador, fornecendo um ambiente, para a execução de programas, conveniente. Um sistema operacional é de grande importância e está presente em praticamente todos os sistemas de computação. Um sistema de computação possui, basicamente, quatro componentes: hardware, sistema operacional, programas aplicativos e usuários. Na figura 3.1 podemos ver de forma abstrata esses componentes (SILBERSCHATZ E OUTROS, 2000).

37 Figura 3.1 - Estrutura de um sistema computacional (Silberschatz e outros, 2000, p.3) Segundo Silberschatz e outros (2000), a CPU (Central Processing Unit – Unidade Central de Processamento), memória e dispositivos de entrada e saída compõem, basicamente, o hardware, disponibilizando os recursos básicos de computação. Os programas aplicativos determinam a forma de utilização dos recursos de hardware para a solução dos problemas do usuário. Como pode existir mais de um usuário (pessoas, máquinas, outros computadores) ou mais de um programa aplicativo tentando resolver problemas diferentes, o sistema operacional gerencia a utilização do hardware entre eles, fornecendo um ambiente para a utilização adequada dos recursos. Segundo Silberschatz e outros (2000), o sistema operacional pode ser considerado como um alocador de recursos. Como um sistema de computação possui muitos recursos para a solução de problemas, é necessário que o sistema operacional gerencie a alocação desses recursos a determinados programas e usuários conforme seja necessário. Como pode haver mais de um pedido ao mesmo recurso o sistema operacional decide para qual pedido será alocado o recurso, para que seja possível o funcionamento do sistema de computação, com eficiência e justiça. Uma definição, um pouco diferente, que pode ser dada ao sistema operacional é a de programa de controle, focando suas funções no controle de dispositivos de entrada e saída e programas de usuário, evitando erros e o mau uso do computador.

38 De uma forma geral, não existe uma definição que seja totalmente adequada aos sistemas operacionais, sendo mais fácil defini-lo pelo que ele faz do que pelo que ele é. Sabe-se que um sistema operacional está sempre executando no computador com o objetivo de facilitar a tarefa computacional (SILBERSCHATZ E OUTROS, 2000). Segundo Tanenbaum (2003), mesmo muitos usuários já tendo uma experiência com um sistema operacional, é difícil definir exatamente o que ele é. Basicamente, um sistema operacional realiza duas funções: estender a máquina e gerenciar recursos. Como uma máquina estendida o sistema operacional oculta a verdadeira integração com o hardware, passando apenas uma visão simples e de forma agradável ao usuário, disponibilizando uma máquina estendida ou virtual que seja mais fácil de utilizar do que o hardware. Como gerenciador de recursos o sistema operacional realiza uma alocação ordenada e controlada de processadores, memórias, e dispositivos de entrada e saída entre os programas que solicitam esses recursos, tendo como principal função controlar quem utiliza os recursos, garantir as requisições de recursos e evitar conflitos entre os diversos usuários e programas. 3.2 Componentes do sistema operacional Segundo Silberschatz e outros (2000) pode-se desenvolver um sistema grande e de alta complexidade separando-o em partes bem delineadas do sistema, possuindo entradas, saídas e funções bem definidas. Nem todos os sistemas possuem uma mesma estrutura, mas muitos deles possuem os componentes que serão definidos em seguida de acordo com Silberschatz e outros (2000). 3.2.1 Gerência de processos Podemos considerar um processo como um programa que está em execução, mas essa definição será ampliada após um maior aprofundamento do conceito de processo. No momento podemos entender um processo como um programa de usuário de tempo compartilhado. Os processos necessitam de recursos para realizar suas tarefas, como tempo de CPU, memória, arquivos e dispositivos de entrada e saída. Esses recursos podem ser disponibilizados no momento da sua criação ou alocados em tempo de

39 execução. Após o encerramento do processo, o sistema operacional solicita de volta os recursos que possam reutilizados. A execução de um processo é realizada pela CPU, de forma seqüencial, executando uma instrução após a outra até o fim do processo, dessa forma, mesmo que dois processos estejam associados ao mesmo programa (normalmente um programa utiliza diversos processos para sua execução), eles podem ser diferenciados como duas sequências de execução. As seguintes funções são atribuídas ao sistema operacional na gerencia de processos: • Criar e excluir processos de usuário e de sistema • Parar e reiniciar processos • Disponibilizar mecanismos para sincronização de processos • Disponibilizar mecanismos para a comunicação de processos • Disponibilizar mecanismos para o tratamento de deadlocks Um deadlock se caracteriza quando um processo entra em estado de espera, aguardando um recurso que não será disponibilizado, pois está alocado para um outro processo também em estado de espera. 3.2.2 Gerência de memória principal A memória principal é utilizada para armazenar dados que são acessados de forma rápida pela CPU e por dispositivos de entrada e saída. No ciclo de busca de instruções, o processador realiza a leitura dessas instruções na memória principal, além de realizar a gravação e leitura de dados, nesta mesma memória, durante o ciclo de busca de dados. Também são feitas leituras e gravações de dados na memória, durante as operações de entrada e saída. Normalmente, a memória principal, é o único dispositivo com grande armazenamento endereçado e acessado diretamente pela CPU. Antes que a CPU processe os dados no disco ou execute instruções, esses dados e instruções precisam ser passados para a memória. Para a execução de um programa, é necessário que ele seja mapeado para os endereços reais da memória e depois carregado na mesma. Durante a execução o programa vai realizando acessos as instruções e aos dados a partir da memória. Ao terminar sua execução o seu espaço na memória fica disponível para que outros programas possam ser executados.

40 Para que a CPU tenha uma melhor utilização e maior velocidade nas suas respostas aos usuários, diversos programas são mantidos na memória simultaneamente. Existem diversos formas para a gerência da memória, dependendo de diversos fatores, como o projeto de hardware do sistema, por exemplo. As seguintes funções são atribuídas ao sistema operacional no gerenciamento da memória: • Manter os registros das partes da memória que estão sendo utilizadas e quem está utilizando • Decidir qual processo será carregado na memória quando houver disponibilidade • Alocar e desalocar os espaços da memória. 3.2.3 Gerência de arquivos Existem diversos meios físicos onde um computador pode armazenar dados. São mais comuns: a fita magnética, disco magnético e disco ótico. Esses meios possuem diferentes características e organização física, além de cada um ser controlado por um dispositivo diferente que também possui suas características próprias, como a velocidade de acesso, capacidade, taxa de transferência de dados e método de acesso, por exemplo. Para que o uso do sistema de computação possa ser feito de forma interessante, o sistema operacional abstrai a diferença entre os dispositivos de armazenamento, disponibilizando uma visão lógica uniforme. Um arquivo é o conjunto de informações relacionadas que foram definidas por um criador e normalmente representam programas e dados. O sistema operacional realiza o gerenciamento do meio de armazenamento, como fitas e discos, e dos dispositivos que os controlam, possibilitando a criação de uma visão abstrata do arquivo. O arquivo é mapeado no meio físico pelo sistema operacional, que depois realiza o acesso a esses arquivos através dos dispositivos de armazenamento. Normalmente os arquivos são organizados em diretórios, facilitando assim o seu uso. São atribuídas as seguintes funções ao sistema operacional na gerência de arquivos: • Criação e exclusão de arquivos • Criação e exclusão de diretórios • Disponibilizar suporte para manipulação de arquivos e diretórios

41 • Mapear arquivos • Fazer backup de arquivos 3.2.4 Gerência do sistema de entrada e saída O sistema operacional tem a função de abstrair, do usuário, alguns detalhes dos dispositivos de hardware específicos. Apenas o driver (controlador do dispositivo) do dispositivo conhece as suas peculiaridades. 3.2.5 Gerência de armazenamento secundário Um sistema de computação tem como principal função a execução de programas que, assim como os dados que acessam, estão na memória principal (armazenamento primário) no momento da execução, porém como essa memória não tem capacidade para armazenar todos os programas e dados, além de perder todas as informações quando é desconectada da energia, é necessária a disponibilização de um armazenamento secundário. Normalmente são utilizados discos para esse tipo de armazenamento. Os programas e dados são armazenados nesses discos até que sejam carregados na memória, tornando a gerência do armazenamento em disco bastante importante para o bom funcionamento do sistema de computação, já que esse armazenamento é utilizado com grande frequência. São atribuídas ao sistema operacional as seguintes funções na gerência de armazenamento secundário: • Gerência de espaço livre • Armazenamento • Escalonamento de disco 3.2.6 Redes Um sistema distribuído é um conjunto de processadores que se comunicam através de linhas de comunicação, como por exemplo, uma rede, possibilitando que dois sistemas diferentes e separados fisicamente sejam transformados em um único sistema, disponibilizando ao usuário diversos recursos mantidos pelo sistema. Os recursos compartilhados possibilitam maior velocidade na computação, maior funcionalidade, disponibilidade de dados e confiabilidade. Os sistemas operacionais, geralmente, utilizam os acessos à rede como mecanismo para acessar arquivos, sem se preocupar com os detalhes da rede, que são controlados pelo driver do dispositivo de rede.

42 3.2.7 Sistemas de proteção Como podem existir diversos usuários executando diversos processos em concorrência, é necessário que o processo seja protegido das ações dos outros. Existem mecanismos para que recursos como, arquivos, segmentos de memória, CPU, entre outros, sejam utilizados apenas por processos que tenham autorização do sistema operacional. Qualquer forma de controle de acesso de programas, usuários ou processos aos recursos de um sistema de computação é considerada uma proteção. Com a utilização da proteção é possível aumentar a confiabilidade verificando erros nas interfaces entre subsistemas, evitando que um subsistema funcionando corretamente possa ser prejudicado por outro com problemas de funcionamento. Os recursos não conseguem se defender do uso feito por usuários não autorizados, por isso eles necessitam de uma proteção. 3.2.8 Sistema interpretador de comandos O interpretador de comandos é a interface entre o usuário e o sistema operacional. Em alguns sistemas operacionais o interpretador se encontra no kernel (núcleo do sistema operacional), em outros são considerados um programa que executa apenas quando um trabalho começa ou quando um usuário entra no sistema, no caso dos sistemas de tempo compartilhado. O interpretador de comandos é um dos programas sistema mais importantes para um sistema operacional. Os comandos, normalmente, são passados para o sistema operacional através de instruções de controle. Ao se iniciar um novo trabalho ou um usuário se conectar a um sistema de tempo compartilhado, é realizada a leitura e a interpretação das instruções de controle por um programa que executa de forma automática. Esse programa, normalmente, é chamado de shell e tem o objetivo de pegar o próximo comando e executá-lo. Normalmente os sistemas operacionais possuem um interpretador de comandos (shell) amigável, facilitando a utilização dos usuários, como por exemplo, o sistema de janelas e menus baseado em mouse do Windows, que identifica uma ação de abrir um programa, selecionar um arquivo ou diretório, apenas pela posição do ponteiro do mouse e um clique. Outros sistemas operacionais possuem um shell

43 mais complicado, onde é necessário digitar comandos específicos para realizar as tarefas desejadas. 3.3 Serviços de sistemas operacionais Segundo Silberschatz e outros (2000), além de disponibilizar um ambiente para a execução de programas, o sistema operacional também oferece alguns serviços para os programas e os usuários destes programas. Esses serviços são disponibilizados para facilitar o trabalho dos programadores e variam de um sistema operacional para o outro, mas existem alguns serviços em comum entre eles que serão detalhados em seguida segundo Silberschatz e outros (2000). • Execução de programa: o sistema precisa poder carregar um programa na memória e executá-lo, além de poder encerrá-lo normalmente ou retornando erro. • Operações de entrada e saída: os programas que estão em execução podem precisar utilizar dispositivos de entrada e saída, mas para melhor eficiência e segurança os usuários, normalmente, não podem controlar esses dispositivos diretamente. O sistema operacional deve disponibilizar mecanismos para realizar essas operações. • Manipulação do sistema de arquivos: os programas precisam realizar a criação, exclusão, leitura e gravação de arquivos. • Comunicações: os processos necessitam trocar informações entre si. Essa troca pode ocorrer entre processos de um mesmo computador ou de computadores diferentes. Essa comunicação pode ser feita através de uma memória compartilhada entre os dois processos ou por troca de mensagens, onde o sistema operacional move pacotes de informações entre os processos. • Detecção de erros: como podem ocorrer erros no hardware da CPU e da memória, em dispositivos de entrada e saída e no programa de usuário, o sistema operacional precisa realizar uma ação para cada tipo de erro, garantindo a computação concorrente e consistente. 3.4 Sistemas operacionais embarcados Um sistema operacional embarcado é caracterizado por executar em dispositivos, como telefones móveis, microondas, maquinas de lavar, vídeo games, etc. Esse tipo

44 de dispositivo possui restrições quanto aos recursos de memória, processamento, consumo de energia, entre outros recursos que os tornam peculiares, por isso os sistemas operacionais devem ser customizáveis, privilegiando atividades dedicadas (LACERDA, 2009). Alguns exemplos de sistemas operacionais embarcados, utilizados em dispositivos móveis: • Windows Mobile: sistema operacional da Microsoft, que foi criado para executar nos dispositivos móveis como Pocket PCs, Smartphones, PDAs e aparelhos de multimídia em geral. O Windows Mobile foi projetado para executar grande parte do que se pode realizar numa versão do Windows para PC (Personal Computer – Computador Pessoal), já possuindo um conjunto de aplicações comumente utilizadas no PC, como Word, Excel, Power Point, Windows Media Player (WIKIPEDIA, 2008?). • Symbian OS: sistema operacional que foi desenvolvido com base no sistema EPOC. O Symbian é um sistema leve, barato e aberto, que permite a instalação de softwares de terceiros, que podem ser criados em diversas linguagens como, Symbian C/C++, JavaME, FlashLite, Perl, Phyton, entre outras. O Symbian não possui uma interface gráfica definida, sendo possível que o fabricante do dispositivo customize essa interface (VIVASEMFIO, 2009). • Palm OS: sistema operacional criado pela Palm Inc. que é utilizado em smartphones e PDAs. O Palm OS gerencia todas as funções do dispositivo, controlando a tela, teclas, sistema de sincronismo, reconhecimento de escrita, etc., além de possuir diversos aplicativos importantes na utilização de um dispositivo móvel como, agenda, contatos, tarefas, bloco de notas e programas de configuração. Esse sistema passou a ser da empresa ACCESS e teve seu nome alterado para Garnet OS (PALMBRASIL, 2008?).

45 4 ANDROID Neste capítulo abordaremos a definição do sistema operacional ANDROID, detalhando os componentes de sua arquitetura e da estrutura de uma aplicação nesta plataforma. 4.1 Definição A criação de aplicações para dispositivos móveis cresceu bastante com o passar do tempo, passando a ser bastante presente em muitas empresas que desejam levar suas soluções, ou até mesmo criar novas, para os ambientes móveis. Em 2007 a Google, em parceria com o Open Handset Alliance, um grupo de mais de trinta empresas, lançou a primeira plataforma open source (com o código disponível) para o desenvolvimento em dispositivos móveis, denominado Android (RABELLO, 2008). Segundo What is Android? (2008), esta plataforma inclui um sistema operacional, middleware e aplicações fundamentais. 4.2 ARQUITETURA A arquitetura do Android possui diversas camadas, como é demonstrado na Figura 4.1. Essas camadas serão detalhadas segundo Rabello (2008).

46 Figura 4.1 – As camadas da arquitetura Android (RABELLO, 2008). 4.2.1 Aplicações Esta camada possui diversas aplicações padrões desenvolvidas com a linguagem Java, como por exemplo: cliente de e-mail, programa de SMS, calendário, mapas, navegador, gerenciador de contatos. 4.2.2 Framework de Aplicação Nesta camada se encontram os componentes que permitem a reutilização de código para novas aplicações, onde qualquer aplicação pode publicar suas funções para que outras aplicações façam uso delas. São exemplos de alguns componentes que fazem parte do Framework de Aplicação: • Um grande conjunto de componentes gráficos, como listas, grids, caixas de textos, botões e um navegador web. • Provedores de conteúdo, possibilitando que aplicações acessem e compartilhem dados com outras aplicações. • Gerenciador de recursos que possibilita acesso a recursos não codificados, a exemplo de strings, gráficos e arquivos de layout. • Gerenciador de notificação, permitindo a criação de mensagens de alerta e que todas as aplicações possam exibi-las na barra de status.

47 • Gerenciador de atividade que controla o ciclo de vida das aplicações, gerenciando os recursos que foram previamente alocados, verificando se ainda continuam sendo utilizados ou se já podem ser desalocados para liberar memória. 4.2.3 Bibliotecas Android utiliza uma coleção de bibliotecas escritas em C/C++, que são disponiblizadas aos desenvolvedores através do framework de aplicação. São elas: Biblioteca de Sistema C: é a otimização da biblioteca C padrão para dispositivos que suportam a plataforma Linux. Bibliotecas de Mídias: para execução e gravação de diversos formatos de áudio e vídeo e até mesmo imagens. Gerenciador de superfície: realiza o controle do acesso ao display do dispositivo e das camadas gráficas 2D e 3D de diversas aplicações. LibWebCore: moderna ferramenta para dar poder ao navegador web da plataforma Android ou até mesmo outro qualquer que seja desenvolvido. SGL: engine para os gráficos 2D. 3D libraries: baseada no OpenGL, utilizam aceleração de hardware e um otimizado software para renderização em 3D. FreeType: renderização das fontes vetoriais e bitmaps. SQLite: uma leve e poderosa engine para banco de dados relacional. 4.2.4 Ambiente de Execução O ambiente de execução possui a máquina virtual Dalvik, que foi desenvolvida para que os dispositivos pudessem suportar diversas máquinas com eficiência. As aplicações Android executam dentro do seu próprio processo, com sua própria instância nesta máquina virtual. Os arquivos executados pela Dalvik (extensão “.dex”) são otimizados para utilizar o mínimo de memória possível. 4.2.5 Kernel Linux O Kernel Linux é base da arquitetura, disponibilizando serviços do núcleo, como segurança, gerenciamento de memória, de processos, pilhas de redes, etc. Segundo What is Android? (2008), essa camada ainda funciona como uma abstração entre o hardware e o resto da pilha de software. 4.3 Estrutura de aplicação

48 Existem quatro componentes que fazem parte de uma aplicação Android: Activity, Intent, Intent Filter, Intent Receiver, Service e Content Provider. A aplicação não precisa possuir todos componentes, utilizando apenas os que sejam necessários para a construção da aplicação. Esses componentes serão conceituados segundo Anatomia de uma Aplicação Android (2008): 4.3.1 Activity O componente Activity (Atividade), normalmente representa uma tela da aplicação. Uma atividade é criada através de uma classe que estende a classe de base Activity. Essa classe será a interface com o usuário através de views (Visões) e estará respondendo a eventos. A Activity é o componente mais comum em uma aplicação Android. As aplicações, geralmente, possuem diversas telas, como por exemplo, uma aplicação de mensagens de texto que deve ter uma tela para a lista de contatos, outra para escrever a mensagem, uma para visualizar mensagens antigas, uma para alterar ou visualizar configurações, etc. Para cada uma dessas telas deverá ser criada uma atividade. A alteração de uma tela para outra significa a inicialização de uma nova atividade, podendo ocorrer de uma atividade retornar algum dado para outra. Ao abrir uma nova tela, a anterior é armazenada é uma pilha de histórico, sendo possível que o usuário possa navegar entre as telas que estejam nessa pilha. Quando as telas não forem mais ser utilizadas elas são retiradas da pilha. 4.3.2 Intent, Intent Filters e Intent Receiver A Intent é uma classe especial que o Android utiliza para realizar mudanças entre telas. Ela descreve o que a aplicação deseja fazer. A sua estrutura de dados tem duas partes com maior importância, que é a ação e os dados sobre o que vai ser feito. Na ação, os valores normalmente são: main, view, pick, edit, etc. Já o dado é expressado como uma URI (Uniform Resource Indicator). Por exemplo, quando se deseja visualizar as informações de um contato é criada uma Intent com a ação view (visão) e os dados definindo a URI correspondente a pessoa que se deseja consultar. Enquanto a Intent é uma requisição para se fazer algo, a Intent Filter é uma classe relacionada que possui a descrição das intenções que uma atividade consegue tratar. Uma Activity que consegue mostrar as informações de contato de uma

49 pessoa, publica um Intent Filter informando que sabe tratar a ação view quando os dados representarem aquela pessoa. A Intent Receiver é utilizada quando se deseja executar uma código na sua aplicação a partir de algum acontecimento externo, como por exemplo, o telefone tocar, dados estiverem disponíveis na rede ou quando for um determinado horário. O alerta ao usuário é feito através do Notification Manager. Não é necessário que sua aplicação esteja executando para que a Intent Receiver seja chamada, caso seja necessário o sistema inicia sua aplicação quando a Intent Receiver for chamada. 4.3.3 Service Um serviço é um código que possui vida longa. Um exemplo de serviço é quando um usuário utiliza algum tocador de música. Nesta aplicação existirão diversas atividades permitindo ao usuário escolher suas músicas e conseguir tocá-las, mas quando o usuário troca de tela é preciso que a música continue tocando, por isso o playback da música não pode ser tratado por uma atividade. O tocador irá iniciar um serviço para executar em background e poder manter a música tocando. O serviço de playback permanecerá executando até que se encerre. Um serviço ainda possibilita uma conexão com ele, permitindo que o usuário se comunique através de uma interface. Neste caso o serviço poderia disponibilizar que o usuário parasse ou recomeçasse a música por exemplo. 4.3.4 Content Provider O Content Provider (provedor de conteúdo) é utilizado quando se deseja compartilhar os dados da sua aplicação com outras aplicações. É uma classe que implementa métodos padrões necessários para que outras aplicações consigam guardar e obter as informações daquele provedor de conteúdo.

50 5 O PROJETO 5.1 Objetivo e descrição Nosso projeto propõe uma comparação entre dois tipos de web services. Para realizar essa comparação foi desenvolvida uma solução de integração entre uma aplicação Android e um web service ws-* utilizando a arquitetura SOA. Estamos dando continuidade a um projeto anterior onde foi proposto uma mesma solução de integração, porém foi utilizado o web service REST. O objetivo desse projeto é fazer uma comparação entre as duas soluções identificando vantagens e desvantagens na utilização desses dois tipos de web services: WS-* e REST. 5.2 Solução de Integração A solução será baseada na arquitetura cliente-servidor, onde, do lado do servidor haverá um web service do modelo ws-* contendo várias funções de consulta e armazenamento de informações. Do lado cliente existe uma aplicação móvel, feita em Java que é executada em um sistema operacional Android. 5.2.1 Provedor de serviço Como o projeto anterior que estamos dando continuidade utilizou a linha REST de web service que tem como característica o fornecimento de serviços orientado a recursos, utilizaremos a linha WS-*. Este tipo tem como característica o fornecimento de serviços orientado a atividades. Mais tarde demonstraremos uma

51 comparação entre as duas linhagens com as características identificadas entre a aplicação do projeto anterior e a aplicação deste trabalho. Para diminuir a interferência de outras variáveis no processo de comparação do nosso projeto utilizamos as mesmas ferramentas e tecnologias para desenvolver nossa aplicação. Com isso, a ferramenta selecionada foi o NetBeans 6.5 (disponível em http://www.netbeans.org/downloads/6.5/), que, apesar de ser uma versão mais nova do que a utilizada no projeto anterior, não afetará na nossa comparação. Da mesma forma que o NetBeans traz uma grande facilidade para o desenvolvimento de web services REST, trás também a mesma facilidade no desenvolvimento do tipo WS-*. A capacidade de integração com o servidor de aplicação (Glassfish) e a de elaboração de diagramas são outras características que foram levadas em consideração no projeto anterior para utilização dessa ferramenta. O servidor de aplicação utilizado foi o Glassfish, o qual não foi necessário fazer qualquer configuração adicional para execução do web service WS-*. Como servidor de banco de dados foi utilizado o MySql 5.1.30 que veio junto com a aplicação XAMPP (disponível em http://www.apachefriends.org/pt_br/xampp- windows.html) o qual será utilizado pelo web service para armazenamento e recuperação de informações. Para realizar o mapeamento das classes Java com o banco de dados foi utilizado a JPA (Java Persistence API). Com ela é possível fazer o mapeamento de duas formas: A partir de uma estrutura criada no banco de dados, gerar as classes em Java já mapeadas com JPA ou pode ser feito a partir de classes Java gerar o mapeamento automatizado com o JPA e depois gerar a estrutura do banco de dados. Nesse projeto foram utilizadas as duas formas de mapeamento. Uma no momento da geração da estrutura do banco de dados, a partir das classes mapeadas com JPA do projeto anterior e outra no momento da geração de classes Java a partir dessa estrutura do banco de dados para o nosso projeto. As associações entre as entidades tiveram que ser feitas manualmente, pois a geração automática dessas entidades não contemplou o relacionamento. Na criação do web service foi utilizado o JAX-WS (Java API for XML Web Services) que é o padrão de implementação de web services ws-* e segue a referência da JSR 224. Esta API tem como objetivo simplificar bastante o desenvolvimento de serviços web que utilizam tecnologia Java. Para suportes habituais no controle de

52 serviços gerados em interfaces endpoint e nas ligações de dados o JAX-WS utiliza JAXB 2.0.(SPINOLA, 2008). O JAXB (Java Architecture for XML Binding) é uma API que tem como objetivo a ligação entre classes Java e esquemas XML. Na versão 1.0 era possível apenas realizar o mapeamento de esquemas XML em classes Java. Somente a partir da versão 2.0 foi possível realizar o mapeamento no sentido inverso, ou seja, de classes Java em esquemas XML (THE JAVA EE 5 Tutorial, 2008). Uma dificuldade encontrada com a utilização do JAXB, foi que no momento da consulta das multas de um veículo, os dados das multas estavam organizados de forma indesejada no XML gerado inicialmente pelo JAXB, fazendo com que cada multa daquele veículo fosse passada como uma lista de multas. Por esse motivo foi necessário realizar o mapeamento da classe Java para XML manualmente, utilizando as anotações do JAXB. Na tabela 5.1 é possível verificar o código Java e o XML com a organização indesejada e na tabela 5.2 o código Java modificado e o XML com o problema corrigido. Foi suprimido parte do código para facilitar o entendimento. @Entity ... @Table(name = "veiculo") <return> public class Veiculo implements Serializable { <ideVeiculo>1</ideVeiculo> ... < listaMulta > @OneToMany(mappedBy="veiculo", <dataMulta>2009-05-09T00:00:00-03:0 fetch=FetchType.LAZY, 0</dataMulta> cascade={CascadeType.ALL}) <ideMulta>1</ideMulta> private List<Multa> listaMulta; <numValor>677.99</numValor> ... </ listaMulta> public List<Multa> getListaMulta() { < listaMulta> return listaMulta; <dataMulta>2009-05-09T00:00:00-03:0 } 0</dataMulta> ... <ideMulta>4</ideMulta> <numValor>150.0</numValor> </ listaMulta> < listaMulta > <dataMulta>2009-05-09T00:00:00-03: 00</dataMulta> <ideMulta>7</ideMulta> <numValor>65.44</numValor> </ listaMulta> ... </return> ... Figura 5.1 – Código Java e respectivo XML gerado antes da correção. .@Entity ... @Table(name = "veiculo") <return>

53 public class Veiculo implements Serializable { <ideVeiculo>1</ideVeiculo> ... <listaMulta> @OneToMany(mappedBy="veiculo", <multa> fetch=FetchType.LAZY, <dataMulta>2009-05-09T00:00:00-0 cascade={CascadeType.ALL}) 3:00</dataMulta> private List<Multa> listaMulta; <ideMulta>1</ideMulta> ... <numValor>677.99</numValor> @XmlElement( name="multa" ) </multa> @XmlElementWrapper( name="listaMulta" ) <multa> public List<Multa> getListaMulta() { <dataMulta>2009-05-09T00:00:00-03 return listaMulta; :00</dataMulta> } <ideMulta>4</ideMulta> ... <numValor>150.0</numValor> </multa> <multa> <dataMulta>2009-05-09T00:00:00-03 :00</dataMulta> <ideMulta>7</ideMulta> <numValor>65.44</numValor> </multa> </listaMulta> ... </return> ... Figura 5.2 – Código Java e respectivo XML gerado depois da correção 5.2.2 Cliente A aplicação cliente, que consome o web service, foi desenvolvido na linguagem Java para executar na plataforma Android. Foi utilizado o kit de desenvolvimento do fabricante – O SDK Android 1.0 release 2, que possui todo o conjunto de ferramentas necessárias para o desenvolvimento, incluindo o emulador de dispositivo móvel, sistema operacional e APIs para o desenvolvimento na linguagem Java. Por não possuirmos um aparelho com o Android utilizamos o próprio emulador do SDK. Esse kit de desenvolvimento pode ser baixado no endereço eletrônico http://developer.android.com/sdk/1.0_r2/index.html. Foi utilizado para o desenvolvimento a IDE MyEclipse 6.5 que é uma ferramenta que trás vários recursos que ajuda bastante o desenvolvedor. Ela é baseada no eclipse tendo a mesma aparência e funcionalidades, porém não é gratuita. Pode ser adquirido no endereço: http://www.myeclipseide.com/module-htmlpages-display- pid-4.html . Foi possível utilizar o mesmo plugin disponível para o eclipse, ou seja, o ADT (Android Development Tools - Ferramentas de Desenvolvimento Android) da Google, já que o MyEclipse é, na verdade, o Eclipse com algumas adaptações. Para

54 adquirir o plugin foi necessário atualizar a IDE através do endereço: https://dl- ssl.google.com/android/eclipse/ . Para facilitar a comparação foi aproveitada toda a parte da aplicação do projeto anterior exceto a parte de comunicação com o web service. As telas são iguais porém o mecanismo de acesso ao serviço é diferente. Enquanto para consumir os serviços REST foi necessário apenas fazer uso dos métodos HTTP, na nossa solução foi necessário incluir uma biblioteca chamada ksoap2. Como foi falado anteriormente, ela que é responsável por abstrair toda a complexidade na comunicação com o serviço web. 5.2.3 Integração cliente/provedor de serviços O web service (provedor de serviços) está sob o Glassfish. O serviço é integrado ao banco de dados por um objeto de mapeamento relacional chamado TopLink que é quem realiza efetivamente o mapeamento com o JPA. A integração entre o cliente e o servidor ocorre da seguinte forma: o cliente cria um objeto soap (SoapObject) que contem a função a ser chamada no web service e os parâmetros a serem passados. Após isso é criado um envelope que ira serializar o objeto soap (SoapSerializationEnvelope). Então é criado um objeto de transporte (HttpTransport) que se encarregara de transportar o envelope contendo o objeto soap. Logo, o web service retorna um XML contendo os dados da requisição. 5.3 Aplicação demonstrativa 5.3.1 Descrição O SISTRANSITO é uma aplicação desenvolvida em Java para rodar em dispositivos moveis com sistema operacional Android. Ela torna possível a disponibilização de serviços do DETRAN (Departamento Estadual de Transito) para a população via aparelhos moveis. Serviços como consulta às informações de veículo (dados do veiculo, dados do proprietário e lista de multas), consulta às informações de habilitação (dados do condutor e pontuação) e fale conosco, que permite à população o envio e consulta de sugestões e criticas ao órgão. Vale ressaltar que esses serviços são apenas hipotéticos. A implementação da metodologia de desenvolvimento SOA é feita através de web services, garantindo a interoperabilidade entre aplicações diferentes, realizando a transformação de processos em serviços. Os serviços são disponibilizados através de um web service WS-*. Através do RENAVAM (Registro Nacional de Veículos Automotores) é feita a

55 busca das informações do veiculo e a consulta dos dados de habilitação é realizada a partir do número da CNH (Carteira Nacional de Habilitação). 5.3.2 Estrutura da aplicação Inicialmente a aplicação disponibiliza um menu com as opções habilitação, renavam e fale conosco que são seus três principais módulos como mostra na figura 5.3. Figura 5.3 - Sistrânsito Para efetuar uma consulta ou um cadastro é instanciada uma classe chamada WebService que contem os métodos disponíveis na aplicação servidora. Esse método faz todo o processo de conexão com o serviço e chama uma função auxiliar que irá converter o SOAP em um objeto correspondente. Posteriormente retorna o resultado, que será mostrado na tela do dispositivo, caso necessário. 5.3.3 Diagrama de caso de uso Para demonstrar a solução proposta esta abaixo na figura 5.4 o diagrama de caso de uso:

56 Figura 5.4 - Diagrama de caso de uso 5.3.4 Diagrama de classes A figura 5.5 demonstra a solução proposta através do diagrama de classes: Figura 5.5 - Diagrama de classes

57 5.4 Comparações entre WS-* e REST Existem diversas características que diferenciam o WS-* do Web Service REST. Cada uma das linhagens, com suas características, se torna mais indicado para determinado tipo de desenvolvimento. É muito importante verificar qual o tipo de web service é o mais indicado antes de iniciar o desenvolvimento. Não é aconselhável que se utilize um único tipo de web service para o desenvolvimento de todas as aplicações, correndo o risco de aumentar a dificuldade e o tamanho do trabalho. 5.4.1 Documentação O WS-*, antes mesmo das aplicações práticas, já possuía um mundo de especificações teóricas, definindo diversas regras que nem se quer haviam sido utilizadas de forma prática. A documentação do WS-* é bastante extensa, tornando essa linhagem, de certa forma, burocrática. Por outro lado o Web Service REST surgiu com apenas algumas especificações de fácil compreensão e só após os primeiros sucessos com a utilização desse web service é que se iniciaram esforços para a padronização. 5.4.2 Comunicação O processo de comunicação no WS-* envolve basicamente três etapas. Quando a aplicação que consome o web service deseja acessar um serviço, primeiramente, ela realiza uma consulta ao UDDI (Universal Description Discovery and Integration – Descrição Universal, Descoberta e Integração), que é um repositório onde os serviços são publicados e consultados. Esse repositório envia o WSDL (Web Service Description Language), especificando as operações disponibilizadas pelo serviço, especificando de forma universal as formas de interação entre clientes e serviços. Após possuir a especificação do serviço a aplicação cliente (que consome o web service) especifica qual a operação e os parâmetros dessa operação e envia uma mensagem com essas informações encapsuladas no protocolo SOAP, que normalmente, trafega sobre HTTP, ao web service. Em relação a aplicação do projeto anterior, foi necessário acrescentar a biblioteca “ksoap2” para poder realizar esse tipo de comunicação, com o protocolo SOAP, que não é necessário no web service REST. Os serviços na linhagem WS-* possuem o foco em atividades, ou seja, as etapas que o serviço realiza até concluir são modeladas como atividades.

58 O Web service REST utiliza extensamente os recurso do HTTP. Enquanto no WS-* é necessário especificar, no protocolo SOAP, a operação que vai ser realizada, o REST utiliza os métodos GET, PUT, POST e DELETE do próprio HTTP. O fato de utilizar apenas os métodos do protocolo HTTP acarreta numa limitação deste tipo de web service, que mesmo sendo comum a comunicação através do HTTP, pode-se encontrar aplicações que não realizem esse tipo de comunicação. Para a realização de trocas de mensagens é preciso que cada recurso tenha uma URI (Uniform Resource Identifier – Identificador Uniforme de Recursos). Para realizar um acesso ao recurso é feita uma chamada para a URI correspondente ao recurso desejado, utilizando um dos métodos do protocolo HTTP. Os serviços do Web Service REST são fortemente associados a recursos. Uma parte fundamental da arquitetura REST é a definição do protocolo de comunicação, definindo o mapeamento dos recursos, métodos de requisição, status HTTP e o seu correspondente significado. Na figura 5.6 é possível verificar o exemplo de um protocolo de comunicação com REST na busca de produtos em um site de compras. O recurso “Produto” indica uma instância a um produto específico, enquanto o recurso “Produtos” indica uma instância a lista completa de produtos. Figura 5.6 – Exemplo de protocolo de comunicação com REST (SILVA, 2008, p.45). Como podemos ver na tabela, essa linha de web service desfruta do status do próprio HTTP para indicar o resultado da chamada ao serviço. Já no WS-* fica a

59 critério do programador implementar parâmetros de retorno nas funções para obter o status da chamada. Como podemos ver na tabela, essa linha de web service desfruta do status do próprio HTTP para indicar o resultado da chamada ao serviço. Já no WS-* fica a critério do programador implementar parâmetros de retorno nas funções para obter o status da chamada. A necessidade de encapsular as informações no protocolo SOAP, causa uma perda de desempenho ao WS-*, já que uma parte do conteúdo é desprezada por fazer parte apenas do encapsulamento. Além disso, o SOAP possui mecanismos de segurança imaturos, que não possuem criptografia do conteúdo, facilitando o acesso de outros ao conteúdo da mensagem e não garantindo a entrega da mesma, caso ocorra um erro o sistema não saberá reenviar a mensagem. A comunicação no Web Service REST é realizada de forma mais simples, onde os serviços recebem apenas o que é necessário e, consequentemente, só retornam o que é necessário. O Web Service REST utiliza o HTTP de forma parecida como no desenvolvimento de aplicações web, tendo a diferença de o retorno ser um XML ao invés de HTML, facilitando a sua utilização. Por outro lado, a comunicação utilizando o WS-* leva vantagem devido a utilização do documento WSDL. Esse documento facilita bastante a comunicação, já que especifica todas as operações que o serviço possui e ainda as formas de interação entre os clientes e os serviços. Fica clara a facilidade que esse documento pode trazer com a possibilidade de se consultar um serviço no protocolo UDDI e conhecer os parâmetros que o serviço está esperando, o que será retornado pelo serviço e como serão esses dados. Se pensarmos em um ambiente com diversos serviços, que provavelmente tenham sido desenvolvidos por pessoas diferentes, conseguiremos enxergar ainda melhor as vantagens trazidas pela especificação do WSDL. CONCLUSÃO

60 A comparação realizada neste projeto, pode ser de grande utilidade para desenvolvedores que necessitem implementar web services e não conheçam exatamente as vantagens que cada um dos dois tipos apresentados possuem ou simplesmente, tenham uma das linhagens como preferência, ignorando vantagens que possam ter com uma simples análise de características entre os tipos de web services apresentados. A colaboração deste projeto está exatamente na realização desta análise, contribuindo com um melhor conhecimento dessas tecnologias, que são relativamente recentes, além de explorar os conceitos e a utilização prática das tecnologias envolvidas na utilização do web service, como o SOA, por exemplo. Uma das dificuldades que tivemos, foi que não encontramos um mecanismo para obtenção do resultado da comunicação com o serviço. Por exemplo, numa consulta ao banco de dados, caso não fosse encontrado um veiculo para um determinado RENAVAM será retornado NULL, e caso existisse esse veiculo será retornado o próprio objeto. Na implementação REST não haveria esse problema, pois é possível usufruir do status que o protocolo HTTP dispõe juntamente com seu significado. Não é possível substituir o WS-* pelo REST e vice-versa. As duas tecnologias possuem características que precisam ser consideradas antes de implementar uma solução. No ambiente desenvolvido neste projeto, com um dispositivo móvel, pode ser mais interessante a utilização do web service REST, já que o envio e recebimento de dados, nesse tipo de dispositivo, podem ter um custo elevado. Porém se o ambiente for muito complexo, com uma grande quantidade de serviços, já é interessante considerar a possibilidade de utilizar o WS-*, devido a sua melhor especificação dos serviços, através do WSDL. REFERÊNCIAS

61 ANATOMIA de uma aplicação Android. Disponível na internet. <http://www.plusgsm.com.br/forums/archive/index.php/t-74675.html>. Acesso em 25 mai. 2009. AYRES, Marcelo. Tablet PC é notebook pequeno com tela sensível ao toque. Disponível na Internet. <http://tecnologia.uol.com.br/produtos/ultnot/2007/11/21/ult2880u472.jhtm>. Acesso em 06 ago. 2009. BANERJEE, Atanu. Considerações Arquiteturais para um Mundo de Dispositivos. 2008. Disponível na Internet. <http://www.microsoft.com/brasil/msdn/arquitetura/Journal/journal14_cap01.mspx>. Acesso em 09 jun. 2009. DANTAS, Daniel C. Toscana. Simple Object Acess Protocol (SOAP). 2007. Dinsponível na Internet. <http://www.gta.ufrj.br/grad/07_2/daniel/index.html>. Acesso em 19 mar. 2009. DEITEL, Harvey M. e outros. XML: Como Programar. Tradução: Luiz A. Salgado e Edson Furmankiewicz. Bookman. 2003. GANDOLPHO, Cibele. Cresce uso de SOA. 2008. Disponível na Internet. <http://info.abril.com.br/corporate/soa/cresce-uso-de-soa.shtml>. Acesso em 18 mar. 2009. INTERNET2 Middleware Initiative. Disponível na Internet. <http://www.internet2.edu/ middleware/>. Acesso em 20 abr. 2009. JOHNSON, Thienne M. Java para dispositivos móveis. 2007. Disponível na Internet. <http://books.google.com.br/books? id=YPnhdne0N0MC&pg=PA22&dq=programacao+ %2B+celulares&ei=Gy98StX4CaCGygTm5PG7DA#v=onepage&q=&f=false>. Acesso em 07 ago. 2009. LACERDA, Wilian Soares. Sistemas Embarcados. 2009. Disponível na internet. <http://www.dcc.ufla.br/~lacerda/download/palestras/sis_embarcados/palestra_siste mas_embarcados.ppt#256,1>. Acesso em 05 de jun. 2009. LEE, Valentino; SCHNEIDER, Heather; SCHELL, Robbie. Aplicações movies: Arquitetura, projeto e desenvolvimento. Tradução: Amaury Bentes e Deborah Rudiger. São Paulo, 2005. MARCHAL, Benoit. XML conceitos e aplicações. Tradução: Daniel Vieira. São Paulo. Editora Berkeley. 2000. NETO, Rodolpho Ugolini. Arquitetura Orientada a Serviços – SOA Infra-estrutura para a Inovação. 2006. Disponível na internet. <http://www.pr.senai.br/posgraduacao/uploadAddress/Introducao%20ao%20SOA %5B31574%5D.pdf>. Acesso em 19 mar. 2009. PALMBRASIL. Palm OS ou Garnet OS. [2008?]. Disponível na internet. <http://www.palmbrasil.com.br/palm-os-webos/vocabulario/98-pqr/541-palm-os-ou- garnet-os>. Acesso em 17 jun. 2009.

62 PEREIRA, Dani Edson. O que é esse tal de XML afinal?. 2002. Disponível na Internet. <http://www.apostilando.com/download.php?cod=198&categoria=XML>. Acesso em 02 jun. 2009. PITTS-MOULTIS, Nathanya; KIRK, Cheryl. XML: Black Book. 1ª ed. São Paulo – SP: Makron Books, 2000. QUEIRÓS, Ricardo. Programação para Dispositivos Móveis em Windows Mobile 6. 1ª ed. FCA – Editora de Informática. 2008. RABELLO, Ramon Ribeiro. Android: um novo paradigma de desenvolvimento móvel. Web Mobile. Ed. 18. 2008. p.6-13. RECKZIEGEL, Maurício. Descrevendo um Web Service – WSDL. 2006. Disponível na Internet. <http://imasters.uol.com.br/artigo/4422/webservices/descrevendo_um_web_service_ -_wsdl/>. Acesso em 31 mar. 2009. RECKZIEGEL, Maurício. Protocolo de Transporte Padrão. 2006. Disponível na Internet. <http://imasters.uol.com.br/artigo/4379/webservices/protocolo_de_transporte_padrao _-_soap/>. Acesso em 19 mar. 2009. SAMPAIO, Cleuton. SOA e Web Services em Java, Rio de Janeiro, 2006. SILBERSCHATZ, Abraham; GALVIN, Peter; GAGNE, Greg. Sistemas operacionais. Tradução: Adriana Ceschin Rieche. Rio de Janeiro, 2000. SILVA, Bruno L. P. REST vs WS-*: Uma visão pragmática. Java Magazine. ed. 54. Rio de Janeiro. 2008. p.38-47. SILVA, Bruno L.P. WS-*: Implementando web services na prática, com os padrões WS-I. Java Magazine. Ed. 55. Rio de Janeiro. 2008. p.24-31. SOARES, Edileuza. SOA é a nova onda de TI. 2007. Disponível na internet. <http://wnews.uol.com.br/site/noticias/materia_especial.php? id_secao=17&id_conteudo=425>. Acesso em 18 mar. 2009. SPINOLA, Eduardo. Desenvolvendo Web Services utilizando JAX-WS. 2008. Disponível na Internet. <http://www.devmedia.com.br/articles/viewcomp.asp? comp=2374>. Acesso em 15 mai. 2009. TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 2. ed. Tradução: Ronaldo A.L. Gonçalves e Luís A. Consularo. São Paulo. Prentice Hall. 2003. TAURION, Cezar. 2008. Android & Linux & OpenSource. Disponível na Internet. <http://www2.eletronica.org/artigos/eletronica-digital/android-linux-opensource>. Acesso em 09 jun. 2009. THE JAVA EE 5 Tutorial. Binding between XML and Java Classes. 2008. Disponível na Internet. <http://java.sun.com/javaee/5/docs/tutorial/doc/bnazf.html>. Acesso em 10 jun. 2009. VIVASEMFIO. Symbian. 2009. Disponível na Internet. <http://www.vivasemfio.com/blog/category/symbian_os/>. Acesso em 05 jun. 2009.

63 WHAT is Android, 2008. Disponível na Internet. <http://code.google.com/android/what-is-android.html>. Acesso em 1 abr. 2009. WIKIPEDIA. Laptop. [2007]. Disponível na Internet. <http://pt.wikipedia.org/wiki/Laptop>. Acesso em 06 ago. 2009. WIKIPEDIA. Pager. [2007]. Disponível na Internet. <http://pt.wikipedia.org/wiki/Pager>. Acesso em 20 jul. 2009. WIKIPEDIA. Tablet PC. [2009]. Disponível na Internet. <http://pt.wikipedia.org/wiki/Tablet_PC>. Acesso em 06 ago. 2009. WIKPEDIA. Windows Mobile. [2008?] Disponível na internet. <http://pt.wikipedia.org/wiki/Windows_Mobile>. Acesso em 05 jun. 2009.

MONO_020709.doc

by peterbuck

Accessibility

Upload Details

Usage Rights

1 Embed 2

Statistics

MONO_020709.doc Document Transcript

MONO_020709.doc

by peterbuck

Accessibility

Upload Details

Usage Rights

1 Embed 2

Statistics

MONO_020709.doc Document Transcript

Let LinkedIn power your SlideShare experience

Let LinkedIn power your SlideShare experience

Customize SlideShare content based on your interests

Keep up to date when your LinkedIn contacts post on SlideShare