Baixar - Unipar

COMPARANDO APLICAÇÃO WEB SERVICE
REST E SOAP
Cleber de F. Ferreira¹, Roberto Dias Mota¹.
¹Universidade Paranaense (Unipar)
Paranavaí – PR – Brasil
[email protected], [email protected]
Resumo. Este artigo descreve o que é um Serviço, usualmente conhecido
como Web Services e compara dois tipos de arquiteturas de web services:
SOAP (Simple Object Data Protocol) e REST (Representational State
Transfer). Existem defensores de ambas as arquiteturas. No decorrer do estudo
veremos exemplos das duas arquiteturas e suas características e diferenças.
1. Introdução
Segundo Abinader Nelo e Lins (2006), Varias tecnologias surgiram nos últimos anos
destinadas ao desenvolvimento de aplicações para a Internet. Contudo estas possuem
suas limitações e particularidades, que impede a troca de informações de forma
automatizada.
O conceito de Web services, ou melhor, de serviços em uma aplicação existe já
algum tempo. Serviços, assim como componentes, são considerados blocos de
construção independentes, que coletivamente representam um ambiente de aplicação.
Entretanto, 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.
E uma das principais características é a completa autonomia em relação ao outros
serviços. Isto Significa que cada serviço é responsável por seu próprio domínio, que
limita seu alcance a uma função de negócio específico.
Já sobre a arquitetura SOAP versos REST, Apesar de terem abordagens
diferentes, são capazes de disponibilizar os mesmos serviços deixando para o
desenvolvedor a responsabilidade de escolher qual entre as duas usar.
O objetivo deste artigo, é mostrar as principais características de ambas
arquiteturas SOAP e REST, de forma relevante.
2. Metodologia
Neste trabalho foi realizada extensa revisão bibliográfica, tanto em revistas eletrônicas,
livros e site do assunto na Internet. Foi implementado posteriormente ao artigo um
protótipo simplificado para evidenciar as caraterísticas de ambas arquiteturas.
3. Desenvolvimento
3.1. O é que um Serviço ou Web Services
Temos hoje a possibilidade de reutilizar processos e não apenas códigos. Podemos
construir aplicações para determinado fim e fazer com que outras aplicações reutilizem
seus processos. Com isto, minimizamos a preocupação de usar o código da aplicação
novamente, e ao invés disso, reutilizamos aplicação como um serviço. De acordo com a
[W3C] - Word Wide Web Consortium – 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.
Em termos práticos, web service é uma arquitetura de comunicação entre
software 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. Vale salientar que a internet é a rede que conecta todas as outras redes, ou
seja, está arquitetura fornece alcance global de comunicação entre quaisquer aplicativos.
3.1.1. Benefícios do web services
Protocolos baseados em um padrão com o XML - (Extensible Markup Language),
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 pacotes;
Utiliza porta 80 do protocolo HTTP - (HyperText Transfer Protocol), o que
permite transportar as chamadas ao serviço sem que o firewall bloqueie;
Distribuição de código de forma modularizada 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, entres outros, consigam interagir e reutilizar serviços e porções de códigos
possibilitando um uso mais inteligente e eficiente dos recursos computacionais.
3.2. Arquitetura SOAP
Segundo [David Chappell e Tyler Jewell, 2002], a especificação SOAP descreve quatro
componentes principais: a formatação de convenções para encapsular dados e
orientações de rota na forma de um envelope, um transporte ou protocolo
obrigatoriamente, regras de codificação, e um mecanismo de RPC - (Remote Procedure
Call). O envelope define uma convenção para descrever o conteúdo de uma mensagem,
a qual, por sua vez tem implicações na forma como é processado. Um protocolo de
ligação proporciona um mecanismo genérico para o envio de um envelope SOAP por
meio de um protocolo de baixo nível, tais como HTTP. Regras de codificação
proporciona uma convenção para mapear vários tipos de dados da aplicação, para uma
representação baseada em tag XML. Finalmente, o mecanismo de Chamada
Procedimento Remoto – RPC, que fornece uma maneira para representar chamadas de
procedimento remoto e seus valores de retorno. Na figura 1 exibimos um exemplo de
arquitetura Web service SOAP.
Figura 1 - Java Web Services Up and Running, Martin Kalin.
De modo a facilidar o entendimento a figura 2 abaixo, chamaremos a aplicação
que solicita o serviço de AppClient, e a que provê o serviço de AppServer. Nela
podermos observar o ciclo de funcionamento do web service que utilizam a arquitetura
SOAP. Primeiro a AppClient localizado em um host, computador, notebook ou
dispositivo móvel – envia uma requisição HTTP através da rede para a AppServer que
disponibiliza o web service – localizada e um servidor ou em um simples desktop –
então AppServer devolve para a AppClient um arquivo WSDL (Web Services
Descreption Language).
Figura 2 – Exemplo de Troca de informação Entre um Cliente e Servidor usando tecnologia SOAP.
WSDL é um arquivo com formato XML, que informa para a AppClient como
utilizar o serviço. Neste arquivo do AppClient encontra-se informações como nome de
métodos, nome de parâmetros, endereço do serviço, como deve ser formatado o arquivo
de entrada e como será formatado o arquivo de saida. Concluindo enfim, todo o
conteúdo necessário para utilizar o serviço.
3.2.1. Características
As principais características da arquitetura SOAP é estabelecer um formato padrão de
mensagem que consiste em um documento XML, capaz de hospedar dados RPC e
centrados em documentos. Isto facilita o intercambio 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 de formato de mensagem
centrada em documento é muito comum;
Grande quantidade de conteúdo textual formatado em XML;
Possui seus próprios protocolos, é focado em expor peças lógicas de aplicação
(métodos) como serviços;
Descreve funções, tipo de dados;
Muitas linguagens de programação suportam SOAP de forma nativa;
Códigos binários necessita ser transformado usando base64encoded.
3.2.2. Situações onde usar SOAP
Processamento e chamadas assincronos: se aplicação precisa de um nível garantido de
confiabilidade e segurança para a troca de mensagens;
Contratos formais: ambos os lados (fornecedor e consumidor) têm que concordar
com o formato de intercambio de dados, onde SOAP fornece especificações rigidas para
esses tipo de interação;
Operações stateful: onde a aplicação precisa de informação contextual e
geranciamento de estado com coordenão e segurança
3.3. Arquitetura REST
Figura 3 - Exemplo de Troca de informação Entre um Cliente e Servidor usando tecnologia REST.
Na figura 3 acima, 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 (Java Script 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 na arquitetura REST, não existe um descritor de
funcionamento do serviço. A requisição realizada pela AppClient parte do principio que
a mesma conhece o que deve ser enviado para 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}. Desta maneira é possível
representar uma escritura complexa de informação.
Roy Fielding (2000), em seu trabalho acadêmico Architectural Styles and the
Design of Network-based Software Architectures, na Universidade da Califórnia, na sua
dissertação de doutorado estabelece os princípios orientadores para o que veio a ser
conhecido como REST, não houve muita movimentação da comunidade acadêmica,
porem agora, muitos frameworks REST estão aparecendo e continuam sendo
desenvolvidos, devido a JSR-311 do Java 6.
3.3.1. Características
Já as principais características da arquitetura REST são:
Pequenas quantidades 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 especifico de 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 base64encod.
3.3.2. Situações onde usar REST
Onde há limitação de recursos e de largura de banda;
Onde tem-se qualquer formato para o retorno e qualquer navegador pode ser
utilidao isso porque REST usa os padroes de chamada do HTTP, GET, PUT, POST,
DELETE e também pode utilizar os objetos XML, que são suportados pela grande
maioria de navegadores;
Operações totalmente sem-estado: se uma operação precisa ser continuada, o
REST não será a melhor opção, no caso, se for necessario operações de CRUD stateless
(Create, Read, Update and Delete),o REST seria a melhor alternativa;
Situações que exigem cache: se a informação pode ser armazenada em cache
adequado para tecnologia.
4. Considerações finais
Uma das vantagens do SOAP é o uso de um método de transporte “genérico”. Enquanto
que o REST faz uso de HTTP/HTTPS, o SOAP pode usar qualquer meio de transporte
existente para enviar suas requisições, deste SMTP (Simple Message, Transport,
Protocol) até mesmo JMS (Java Messaging Service). Contudo uma desvantagem
percebida no uso de XML é a sua natureza trabalhosa e o tempo necessário para analisar
o resultado apresentado. A Tecnologia REST, se sai bem em situações em que há
limitação de recursos e de largura de banda, e em operações que não precisa de estado,
já se uma operação precisa ser continuada a tecnologia SOAP é a indicada.
Lembramos que a tecnologia SOAP, é bastante madura e vem com uma
especificação definida pela W3C. Por tanto a melhor abordagem é a flexibilidade, pois
não importa qual seja o problema, no mundo do desenvolvimento web, ao fazer uso
destes padrões chega a resultados satisfatórios.
5. Referências
Albinader Neto, et al. (2006), Web Services em Java, Rio de Janeiro, Brasport.
David A. Chappell and Tyler Jewell (2002), Java Web Services: Up and Running, O
„Reilly Media; 1 edition
David A. Chappell and Tyler Jewell (2002), Java Web Services: Using java in ServiceOriented Architectures, O „Reilly Media; 1 edition
Introducing JSON (1999), disponível em:<http://www.json.org>Acesso em 25/07/2014.
REST, Learn REST: A Tutorial, disponível em: <http://rest.elkstein.org>Acesso em
15/08/2014.
Revista Devmedia, Entendendo os Padrões de Descrição de Web Services (2013),
disponível em:<http://www.devmedia.com.br> Acessado em 15/08/2014.
Revista Devmedia, Primeiros Passos com os serviços REST (2013), disponível
em:<http://www.devmedia.com.br> Acessado em 07/08/2014.
Web Services Architecture (2004), disponível em:<http://www.w3.org/TR/wsdl/>
Acesso em 10/07/2014.