Netscape DevEdge

Skip to: [content] [navigation]

Busca

Web Services, SOAP e Aplicações Web

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

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 seguir tem-se um exemplo de uma RPC, usando HTTP para o transporte:

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:

O cabeçalho Header define:

O elemento Body define:

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.

Cenário1: Acesso a Web Services através do Navegador

Os navegadores são as principais ferramentas utilizadas para a busca de informação na Internet. Portanto é interessante (pra não dizer necessário) que eles possam acessar Web Services com a mesma facilidade que qualquer outra aplicação desenvolvida no lado do servidor (escrita em linguagens como C++, PHP, JAVA) o faria. Nesta sessão, daremos uma visão geral das soluções que os browsers Mozilla e IE já trazem como resposta para este novo desafio, que é o acesso a Web Services, via browser, usando SOAP.

Cenário 2: Cliente acessando Web Services no servidor.

Vamos apresentar agora um segundo cenário de utilização de SOAP e Web Sevices. Neste novo modelo, em vez de existir um browser realizando chamadas SOAP, temos uma aplicação cliente (definida em JAVA, C++, ou outra linguagem) enviando estas chamadas para um serviço no servidor.

Nossa aplicação cliente pode acessar diretamente um Web Service, seja ele um EJB (Enterprise Java Bean) ou mesmo uma aplicação JAVA. O Web Service processa a chamada (possivelmente acessando o seu Banco de Dados) e retorna uma resposta ao cliente.

A figura abaixo nos fornece uma visão geral deste processo: A aplicação cliente, após localizar o serviço remoto(definido por um documento WSDL), invoca os seus serviços através de RPC. O Web Service recebe a chamada, a processa e envia uma resposta. É válido lembrar, que ambos (cliente e Web Service) "conversam" usando SOAP em cima de HTTP.

Fig 3. Aplicação cliente acessando diretamente um Web Service.

JAX-RPC

A especificação J2EE da Sun Microsytems, define um conjunto de API's para acessar WebServices em um ambiente distribuído. Este conjunto de API's, conhecido como JAX-RPC, permite realizar chamadas de RPC, utilizando-se SOAP. JAX-RPC foi desenvolvido com o objetivo de “esconder” a complexidade de SOAP. Dessa forma, não é necessário escrever uma chamada SOAP explicitamente. Podemos usar esta API para montarmos as chamadas RPC, codificando em JAVA.

JAX-RPC baseia-se em um documento WSDL para a descrição de um Web Service. Dessa forma, um cliente pode acessar a descrição (WSDL) do serviço remoto, e realizar as chamadas.

JAX-RPC não limita que o cliente e o Web Service sejam desenvolvidos na plataforma JAVA. Um cliente JAVA pode fazer chamadas a um serviço desenvolvido em uma plataforma não-JAVA , assim como um serviço implementado em JAVA pode ser acessado por uma aplicação não-JAVA.

Referências

Cenário 3: Acessando Web Services no lado servidor

Neste último cenário temos um aplicação cliente acessando uma aplicação no servidor. Esta, por sua vez, faz chamadas a diversos Web Services em diferentes máquinas, processa as respostas destes serviços e, por fim, envia uma resposta ao cliente. Um exemplo interessante seria, por exemplo, um site que faz a cotação de preços de livros em várias lojas virtuais pela Internet. Vamos nos referir a este site, como site de cotações.

No nosso exemplo, supomos que cada loja virtual possua seu próprio Web Service. Este Web Service deve receber o pedido para uma determinada cotação(tipo de produto) e enviar uma resposta contendo o preço do produto.

Uma aplicação cliente (no caso o browser) acessa o site de cotações. Em seguida, o usuário do sistema preenche um formulário HTML contendo o dados sobre os livros a serem pesquisados. Ao terminar, os dados são enviados através de uma requisição (POST) ao servidor. No servidor, uma aplicação recebe a requisição, localiza os serviços disponíveis (Web Services), com base numa lista pré-estabelecida, e envia as mensagens (SOAP), contendo as requisições de preço do produto(livro).

O serviço(Web Service) da loja virtual, recebe o pedido e o processa. Caso seja um pedido válido, e a loja contenha aquele livro em seu estoque, o serviço retorna uma mensagem (SOAP) contendo a cotação do livro no corpo da resposta. A aplicação servidora recebe então as resposta das diversas lojas (subentende-se serviços), processa os dados recebidos e envia um formulário HTML para o browser do usuário, contendo todas as cotações para aquele determinado livro.

A figura abaixo ilustra o funcionamento deste sistema:

Fig 4. Sistema de pesquisa em lojas virtuais - Aplicação no servidor acessando diversos Web Services.

A grande vantagem desse modelo, portanto, é que a informação pode estar distribuída pela WEB, podendo facilmente ser acessada e filtrada de acordo com nossas necessidades. Sendo somente necessário localizarmos os diversos serviços (Web Services) e construirmos as chamadas de forma correta.

Referências

  • XML Schema homepage
  • SOAP 1.1
  • HTTP
  • Web Services Description Language (WSDL)
  • Web Services Architecture
  • Web Services for application integration
  • JAX-RPC
  • WebService Behavior
  • Mozilla SOAP API
  • A+O