COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com 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 Service- Oriented 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.