Web Services, SOAP e Aplicações Web (parte 1)

Quando a Internet começou a se popularizar, por volta do meio dos anos 90, as tecnologias presentes permitiam você conectar-se a um site e baixar o conteúdo deste

Por | @oficinadanet Programação
Introdução
Quando a Internet começou a se popularizar, por volta do meio dos anos 90, as tecnologias presentes permitiam você conectar-se a um site e baixar o conteúdo deste. O HTML (Hiper Text Markup Language) era a linguagem "de-facto" que permitia a apresentação da informação presente na rede. Nos últimos anos, porém, novas tecnologias e frameworks de desenvolvimento estão surgindo, permitindo uma maior integração entre os diversos aplicativos e serviços disponíveis na internet. Este novo modelo em crescimento deve tratar tarefas complexas, como o gerenciamento de transações, através da disponibilização de serviços distribuídos que utilizem interfaces de acesso simples e bem definidas. Esses serviços ou aplicativos distribuídos são conhecidos como Web Services.

Para ilustrar a utilização de Web Services em uma situação real, imaginemos um site de vendas pela Internet, que necessita validar o crédito do comprador antes de proceder com a venda. O sistema então acessa um serviço (Web Service) que cuida de todos os passos necessários à verificação de crédito: Checa o histórico das compras efetuadas pelo consumidor na empresa, checa a situação de crédito do consumidor no sistema público, etc.

O Web Service obtém estes dados e retorna a situação de crédito deste consumidor para o site. Este é apenas um exemplo, entre tantos, de utilização de Web Services.
Neste artigo, teremos uma visão geral do protocolo SOAP - padrão de comunicação com Web Services - além da descrição de alguns cenários propícios à utilização de Web Services e SOAP.

SOAP e Web Services
Web Services são identificados por uma URI(Unique Resource Identifier), e são descritos e definidos usando XML. Um dos motivos que tornam Web Services atrativos é o fato deste modelo ser baseado em tecnologias standards, em particular XML e HTTP. Web Services são usados para disponibilizar serviços interativos na WEB, podendo ser acessados por outras aplicações. SOAP (Simple Object Access Protocol) está se tornando padrão para a troca de mensagens entre aplicações e Web Services, já que é uma tecnologia construída com base em XML e HTTP.

SOAP é um procolo projetado para invocar aplicações remotas através de RPC (Remote Procedure Calls - Chamadas Remotas de Procedimento) ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programação. SOAP é, portanto, um padrão normalmente aceito para utilizar-se com Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização de uma linguagem (XML) e mecanismo de transporte (HTTP) padrões.
Características de SOAP

    * Definido pelo consórcio W3C. Veja maiores detalhes da versão atual SOAP 1.1.
    * Protocolo baseado em XML para a troca de informações em um ambiente distribuído;
    * Padrão de utilização com Web Services;
    * Normalmente utiliza HTTP como protocolo de transporte;
    * Uma mensagem SOAP (veja fig.1) consiste basicamente dos seguintes elementos:

o Envelope: Toda mensagem SOAP deve contê-lo. É o elemento raiz do documento XML. O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação (encoding style).Um "encoding style" define como os dados são representados no documento XML.

o Header: É um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário (É importante lembrar que, ao trafegar pela rede, a mensagem normalmente passa por diversos pontos intermediários, até alcançar o destino final). Quando utilizado, o Header deve ser o primeiro elemento do Envelope.

o Body: Este elemento é obrigatório e contém o payload, ou a informação a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "nós" ao processarem a mensagem.

Web Services, SOAP e Aplicações Web (parte 1)
Fig 1. Estrutura de uma mensagem SOAP.

SOAP e RPC
Entre outras utilizações, SOAP foi desenhado para encapsular e transportar chamadas de RPC, e para isto utiliza-se dos recursos e flexibilidade do XML, sob HTTP.

RPCs ou chamadas remotas de procedimento, são chamadas locais a métodos de objetos (ou serviços) remotos. Portanto, podemos acessar os serviços de um objeto localizado em um outro ponto da rede, através de uma chamada local a este objeto. Cada chamada ou requisição exige uma resposta.

Processo de uma chamada RPC: Antes de serem enviadas pela rede, as chamadas de RPC (emitidas pela aplicação cliente) são encapsuladas (ou serializadas) segundo o padrão SOAP. O serviço remoto, ao receber a mensagem faz o processo contrário, desencapsulando-a e extraindo as chamadas de método. A aplicação servidora então processa esta chamada, e envia uma resposta ao cliente. O processo então se repete: a resposta é também serializada e enviada pela rede. Na máquina cliente, esta resposta é desencapsulada e é repassada para a aplicação cliente.

A especificação SOAP (definida pela W3C) define as seguintes informações, como necessárias em toda chamada de RPC:

    * A URI do objeto alvo;
    * O nome do método;
    * Os parâmetros do método (requisição ou resposta);
    * Uma assinatura do método opcional;
    * Um cabeçalho (header) opcional.

A seguir tem-se um exemplo de uma RPC, usando HTTP para o transporte:

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

   xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
   5



xmlns:m="Some-URI">
DIS




As primeiras 4 linhas do exemplo definem o cabeçalho HTTP, incluindo dados como o tamanho do pacote, o tipo dos dados transmitidos, etc. Note que, em seguida, aparece um campo chamado SOAPAction. Ele é usado para informar o propósito da requisição HTTP SOAP. Seu valor é uma URI, identificando esta intenção. Toda requisição HTTP SOAP deve conter este campo de cabeçalho.

A presença do campo SOAPAction definido pode ser utilizado por firewalls, para filtrar as requisições SOAP feitas usando HTTP. Por exemplo, um pacote poderia ser filtrado (bloqueado) caso a mensagem não possuísse este campo definido, ou com um valor previamente especificado.

Como exemplo, temos:
SOAPAction: "http://myecommerce.org/abc#Mensagem"
SOAPAction: "myapp.sdl"

O elemento Envelope especifica:

    * A URI http://schemas.xmlsoap.org/soap/envelope/ identifica o namespace utilizado por esta requisição SOAP. É o namespace padrão para todas as mensagens SOAP.
    * O estilo de codificação (encodingStyle) é definido pela URI http://schemas.xmlsoap.org/soap/encoding/ , e identifica o estilo de codificação definido na seção 5 da especificação SOAP.

O cabeçalho Header define:

    * Um atributo chamado Transaction que define um namespace (URI) para o elemento.
    * O atributo mustUnderstand=1 que especifica que o cabeçalho deve ser processado pelo receptor da mensagem.
    * O valor 5, que deve ser um valor compreendido pelos serviços que processam esta mensagem.

O elemento Body define:

    * Uma chamada de método GetLastTradePrice e seu respectivo namespace.
    * O elemento DIS especifica um parâmetro contido na chamada de método GetLastTradePrice.

Documento WSDL
De que forma um cliente de um Web Service sabe qual formato dos métodos a serem chamados, qual parâmetros a serem passados? Como cliente e serviço sabem como processar uma requisição?

Para solucionar estes tipos de perguntas é que foi criado um documento, que utiliza uma linguagem chamada WSDL. WSDL ou Web Service Description Language é uma linguagem baseada em XML, utilizada para descrever um Web Service. Um Web Service deve, portanto, definir todas as suas interfaces, operações, esquemas de codificação, entre outros neste documento.
Um documento WSDL define um XML Schema para descrever um Web Service.

Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do Web Service pode ser feita em qualquer linguagem de programação. Normalmente são utilizadas linguagem construídas para interação com a WEB, como por exemplo Java Servlets ou ASP, que, em seguida, chamam um outro programa ou objeto.

Basicamente, quando o cliente deseja enviar uma mensagem para um determinado Web Service, ele obtém a descrição do serviço (através da localização do respectivo documento WSDL), e em seguida constrói a mensagem, passando os tipos de dados corretos (parâmetros, etc) de acordo com a definição encontrada no documento. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado, a fim de que possa ser processada. O Web Service, quando recebe esta mensagem valida-a conforme as informações contidas no documento WSDL. À partir de então, o serviço remoto sabe como tratar a mensagem, sabe como processá-la (possivelmente enviando-a para outro programa) e como montar a resposta ao cliente.

Uma descrição mais detalhada foge ao escopo deste artigo e pode ser encontrada em: Web Services Description Language (WSDL) Version 1.2
Apresentação de alguns cenários de utilização de SOAP com Web Services.
2

Mais sobre:
Share Tweet
DESTAQUESRecomendadoMais compartilhados
Comentários
AINDA NÃO SE INSCREVEU?

Vem ver os vídeos legais que
estamos produzindo no Youtube.