Web Services em aplicações Android e iOS

Quando a prática do desenvolvimento de software passou a fazer parte do dia a dia das organizações não era comum a prática da reutilização de código. Quantos de nós desenvolvedores não construímos diversas vezes a mesma coisa?

Com o passar do tempo a questão da reutilização de código ganhou a devida atenção das organizações e também dos desenvolvedores. Componentes começaram a ser construídos para que diversas aplicações os utilizassem sem a necessidade de "reinventar a roda".

Ainda sim, existiam diversos problemas quando, por exemplo, a tecnologia mudava e o componente construído no passado perdia seu valor. Contudo, o surgimento da ideia de serviço (web service) elevou o conceito de reutilização a um novo patamar.

O conceito de web service solucionou dois grandes problemas no mundo do desenvolvimento de software. Primeiro, permitiu que aplicações —independentemente de plataforma — trocassem informações. Segundo, mudou o conceito que temos sobre reutilização.

O conceito de serviços em uma aplicação existe faz algum tempo. Serviços, assim como componentes, são considerados blocos de construção independentes, os quais coletivamente representam um ambiente de aplicação. No entanto, diferente de componentes tradicionais, serviços têm algumas características únicas que lhes permitem participar como parte de uma arquitetura orientada a serviços. Uma destas características é a completa autonomia em relação a outros serviços. Isto significa que cada serviço é responsável por seu próprio domínio, o que tipicamente significa limitar seu alcance para uma função de negócio específica.

Este enfoque de projeto resulta na criação de unidades isoladas de funcionalidades de negócio ligadas fracamente entre si. Isto é possível por causa da definição de uma estrutura padrão de comunicação. Devido à independência que esses serviços desfrutam dentro desta estrutura, a lógica de programação que encapsulam não tem necessidade de obedecer a nenhuma outra plataforma ou conjunto de tecnologias.

Hoje, temos a possibilidade de reutilizar processos e não apenas códigos. Podemos construir uma aplicação para um determinado fim e fazer com que outras aplicações reutilizem seus processos. Isso minimiza a preocupação de usar o código da aplicação novamente, e ao invés disso, reutilizar a aplicação como um serviço.

Mas, como definir web service? Em suma, todos estão acostumados a ouvir que web service é uma maneira de fazer com que aplicações construídas em diferentes plataformas possam trocar informações.

De acordo com a World Wide Web Consortium (W3C) – organização internacional que rege os padrões de tecnologia utilizada na internet – web service é um software projetado para suportar interação máquina-a-máquina interoperáveis sobre uma rede, utilizando uma interface de formato processável. Para saber mais verifique o link Web Services Architecture na área Links deste artigo.

Na prática, web service é uma arquitetura de comunicação entre softwares que sejam da mesma plataforma ou não. A característica marcante dessa arquitetura é que a comunicação sempre é realizada em rede e deve estar sempre disponível (always on). Vale destacar que a internet é a rede que conecta todas as outras redes, ou seja, esta arquitetura fornece alcance global de comunicação entre quaisquer aplicativos.

Os principais benefícios dos Web Services são:

· Protocolos baseados em um padrão como XML, permitindo a geração automática tanto do código cliente quanto do código servidor;

· Utilização de protocolos baseados em texto, o que permite tráfego suave através de firewalls que fazem verificações de pacote;

· Utilização de porta 80 do protocolo HTTP, o que permite transportar as chamadas ao serviço sem que o firewall bloqueie estas portas;

· Distribuição de código de forma modularizada e que permite fácil manutenção e correção de erros, sem os problemas verificados com as versões binárias de arquiteturas distribuídas;

· Com a modularização atingida no item interior, torna-se possível que dispositivos de diferentes arquiteturas como computadores, handhelds, telefones celulares, set-top boxes, entre outros, consigam interagir e reutilizar serviços e porções de código possibilitando um uso mais inteligente e eficiente dos recursos computacionais.

Atualmente existem dois tipos de protocolos de web service: SOAP (Simple Object Data Protocol) e REST (Representational State Transfer). Existem defensores de ambos os protocolos, contudo, no mundo mobile o protocolo REST tem a preferência. Indiferente à preferências, neste artigo veremos exemplos de ambos os protocolos, afinal, como desenvolvedores, é possível que trabalhemos com todas elas.

A Figura 1 apresenta o diagrama de funcionamento de um web service utilizando SOAP.

abrir imagem em nova janela

Figura 1. Funcionamento de Web Service com SOAP.

A fim de facilitar o entendimento da Figura 1, chamaremos a aplicação que solicita o serviço de AppClient e a que provê o serviço de AppServer.

Nela podemos observar o seguinte ciclo de funcionamento de web services que utilizam o protocolo SOAP. Primeiro a AppClient – localizada em um computador, notebook ou dispositivo móvel – envia uma requisição HTTP através da rede para a AppServer que disponibiliza o web service – localizada em um servidor ou em um simples desktop – então a AppServer devolve para a AppClient um arquivo WSDL (Web Services Description Language).

WSDL é um arquivo com formato XML (Extensible Markup Language) que informa para a AppClient como utilizar o serviço. Neste arquivo a AppClient encontrará informações como nomes de métodos, nomes de parâmetros, endereço do serviço, como deve ser formatado o arquivo de entrada e como será formatado o arquivo de saída, enfim, todo o conteúdo necessário para utilizar o serviço. Para saber mais sobre WSDL acesse o link W3C Web Services Description Language na seção Links.

Uma vez que a AppClient processa o arquivo XML, envia uma requisição HTTP contendo um arquivo XML com as informações necessárias para que a AppServer execute a operação desejada. Após a execução da operação solicitada, a AppServer envia à AppClient um arquivo XML informando o resultado da operação que deve conter desde uma simples mensagem até um conjunto de informações complexas.

A Figura 2 apresenta o diagrama de funcionamento de um Web Service utilizando REST.

Figura 2. Funcionamento de Web Service com REST.

A fim de facilitar o entendimento da Figura 2, utilizaremos a mesma nomenclatura utilizada para explicar a Figura 1.

Na Figura 2 a AppClient envia uma requisição (HTTP Request) contendo as informações necessárias para executar uma determinada operação para a AppServer. A AppServer processa a requisição e devolve para a AppClient uma resposta (HTTP Response) contendo um arquivo XML ou uma String JSON (JavaScript Object Notation) contendo desde uma simples mensagem a um conjunto de informações complexas. O JSON trata-se de um formato leve para intercâmbio de dados.

Como podemos observar, no protocolo REST não existe um descritor de funcionamento do serviço. A requisição realizada pela AppClient parte do princípio que a mesma conhece o que deve ser enviado para a AppServer, facilitando assim o processo de implementação.

JSON é um texto que representa um objeto. Este é formatado da seguinte maneira: { texto : valor, texto : valor, …, texto : valor }. Assim é possível representar uma escritura complexa de informações. Para saber mais sobre JSON acesse o link Introducing JSON na seção Links.

Neste contexto, este artigo irá apresentar o conceito de web service, explicando para que ele serve e como utilizá-lo em dispositivos móveis. Para isso, apresentaremos a estrutura completa do uso de web services, desde a exposição de um web service por um aplicativo até seu consumo por um aplicativo mobile.

SOAP vs REST

A seguir veremos algumas das principais diferenças sobre esses protocolos. Apesar de abordagem diferente, ambas são capazes de disponibilizar os mesmos serviços deixando para o desenvolvedor a responsabilidade de escolher qual delas utilizar.

As principais características do protocolo SOAP são:

· A especificação SOAP estabelece um formato padrão de mensagem que consiste em um documento XML capaz de hospedar dados RPC e centrados em documentos. Isto facilita o intercâmbio de dados de modelos síncronos (pedido e resposta) e assíncronos (orientado a processo). Com o WSDL estabelecendo um formato de descrição padrão para aplicações, o uso do formato de mensagem centrada em documentação é muito mais comum;

· Grande quantidade de conteúdo textual formatado em XML;

· Possui seus próprios protocolos, é focado em expor peças lógicas da aplicação (métodos) como serviços;

· Descreve funções, tipos de dados;

· Muitas linguagens de programação suportam SOAP de forma nativa;

· Código binário necessita ser transformado usando base64encoded.

Já as principais características do protocolo REST são:

· Pequena quantidade de conteúdo textual formatado em XML ou JSON;

· Na maioria dos casos opera sobre protocolo HTTP;

· É focado em expor recursos da aplicação de forma pública, ou seja, por meio de métodos conhecidos;

· Não é necessário suporte específico da linguagem, uma vez que, os dados são transmitidos usando um XML simples ou uma string JSON;

· Código binário NÃO necessita ser transformado usando base64encode.

Implementando web services

Antes de usar um dispositivo mobile para consumir um web service, é imprescindível que exista um web service para consumir. No cotidiano do desenvolvedor é comum encontrar um projeto que já disponibilize um web service, contudo isto não é uma regra. Muitas vezes o desenvolvedor vai precisar definir e/ou até implementar um web service em uma terceira aplicação antes de utilizar seus dados em um dispositivo móvel.

Juntos implementaremos um web service para lidar com dados de uma classe chamada Pessoa, utilizando tanto o protocolo SOAP quanto o protocolo REST. Este serviço disponibilizará três operações conforme apresentado na Tabela 1.

Tabela 1. Descrição das operações do web service Pessoa.

Para implementarmos nosso web service, vamos configurar um ambiente de desenvolvimento simples, utilizando IDE (Integrated Development Environment) Eclipse Juno, Java como linguagem de programação, JDK 1.6 (Software Development Kit) e Apache Tomcat 7.0.39 como servidor de aplicação. Na área Links deste artigo é possível encontrar os links para baixar todo conteúdo necessário para configurar o ambiente.

O primeiro passo na configuração do ambiente é a instalação do JDK. No site da Oracle é possível encontrar um instalador para os sistemas operacionais mais comuns. Após baixar e instalar o JDK teremos que instalar o Tomcat.

Baixe o Tomcat e descompacte-o em qualquer diretório. Para testar se ele está servidor funcionando corretamente, entre no diretório bin e via prompt de comando execute o arquivo configtest.

Baixe o eclipse e descompacte-o em qualquer diretório; acione o executável do eclipse; escolha um diretório para ser o workspace padrão e então será apresentada a tela padrão de boas vindas do Eclipse.

Acione o menu Window > Preferences ou Eclipse > Preferences (No caso de estar em um Mac OS X) e configure o JDK de acordo com a ...