Web Services - SOAP
Autor: Guido Gabriel | Publicado: 2012-04-13T23:36:00-03:00



Introdução aos Web Services

Os web services surgiram como uma evolução dos modelos de
computação distribuída.

O que é o modelo distribuído?&nbsp;

É&nbsp;integração de softwares em ambientes
locais homogêneos.



O objetivo dos web services é a integração entre aplicações além das redes
locais e em ambientes heterogêneos.

SOAP&nbsp;(Simple Object Access Protocol) é um protocolo para Web Services.

Web services, de forma genérica, é uma tecnologia de
integração de sistemas empregada, principalmente, em ambientes heterogêneos.

A troca de dados entre os sistemas deve ser feita no formato
XML.

Exemplo: correios disponibilizam um web service para o
cálculo do serviço do frete.

Simplificando, web service é uma espécie de método: recebe
valores na forma de parâmetros, executa um determinado processamento e devolve
um resultado.

&nbsp;&nbsp;



Padrões de
desenvolvimento de web services

Atualmente, existem dois padrões de desenvolvimento de web
services: SOAP e REST ou RESTfull.

Este resumo abordará somente o padrão SOAP.





SOAP:
é o protocolo padrão para transmissão de dados dentro da arquitetura de web
services proposta pelo W3C. O SOAP é um protocolo baseado no XML e segue o
modelo “request-response” do HTTP.&nbsp;

WSDL
(Web services description language): é um arquivo XML, cuja finalidade é
descrever detalhadamente um web service. Essa descrição especifica as operações
que compõem o web service e define de forma clara como deve ser o formato de
entrada e saída de cada operação. Veja na figura 1.1 o WSDL pode ficar
armazenado tanto no provedor de web services quanto no UDDI.

Obs.: WSDL descreve web services e não serviços SOAP.

UDDI
(universal description, Discovery and integration): o UDDI é um mecanismo que
visa atender tanto o cliente quanto ao provedor. Ele tem de fornecer ao
provedor de web services meios para que os web services sejam registrados e
publicados. Isso permitirá que os web services sejam pesquisados e localizados
pelos clientes. Outra finalidade do UDDI é o armazenamento de arquivos WSDL.

Obs.: o UDDI é um diretório de serviços web
descrito por WSDL.

Cliente:
software que consumirá web services, ou seja, utilizará as operações
disponibilizadas por um determinado web service. No entanto, é importante que
se deixe claro que, na figura 1.1, o cliente está sendo representado em várias
etapas de seu ciclo de vida. Ali, vemos desde sua preexistência, quando um determinado
desenvolvedor obtém o arquivo WSDL, até o momento em que o software já&nbsp; está em operação fazendo solicitações e
recebendo os resultados dos web services, ambos no formato XML.

Provedor
de web services: é um servidor de aplicações ou um web container,
dependendo do caso, em que o web service ficará armazenado. Ele pode armazenar
também arquivos WSDL.

Obs.: qualquer informação trocada entre as partes é em
formato XML.





Sequência das operações dos componentes:



Registra
e publica o web service: web services ficam armazenados junto com os
descritores WSDL. Quando criamos um web service, iremos disponibilizá-lo para
uso em um provedor de web services. O web service e o WSDL devem ser publicados
para que os clientes o localizem, ou seja, o cliente precisa saber o endereço
do web service ou seu URI (uniform resource identifier), que é um endereço
semelhante ao URL. Assim, depois de criar, devemos registrar e publicar o web
service em um diretório de registro web, também conhecido como UDDI.
Obtém
informações sobre o web service: quando um desenvolvedor precisa de um web
service, ele pesquisará em diretórios de registro de web services (UDDI) pelo
tipo de web service que deseja. Em outras palavras, o UDDI fornece o endereço
URI do web service e de seu WSDL.
Efetua
download do WSDL: o WSDL pode estar disponível para download tanto no UDDI
quanto no provedor de web services. De posse do WSDL e do URI do web service,
você pode criar um cliente para fazer chamada ao web service.
Envia
solicitação XML: a chamada será feita por meio do URI do web service
enviando solicitações no formato XML.
Recebe
resposta XML: o web service pode ou não enviar um resultado ao solicitante,
se enviar será em XML.



A explicação dada, baseia-se na orientação do W3C, no
entanto, na prática, não funciona desta maneira. Normalmente a figura do UDDI
não existe, a comunicação entre cliente e provedor ocorre sem intermediações.



A arquitetura projetada pelo W3C especifica que as
solicitações e respostas XML possam trafegar por meio de qualquer protocolo
como HTTP, FTP, SMTP, TCP puro. Mas o que vemos na pratica é o XML trafegando
somente através do HTTP. HTTP é dominante na web, qualquer plataforma suporta
ele.

Existem duas formas de envio de mensagens para que o cliente
possa efetuar solicitações a um web service:



One-Way
messaging: forma de envio de mensagem unilateral. O cliente envia a
solicitação sem se preocupar com a resposta. Web service executará o
processamento e não responderá.
Request-response
messaging: o envio é bilateral. Cliente faz solicitação, WebService executa
processamento e devolve um resultado. Podemos trabalhar de duas formas:

Síncrona
Assíncrona






MAIS SOBRE SOAP

SOAP é uma tecnologia construída com base em XML e HTTP.

SOAP foi projetado para invocar aplicações remotas através
de RPC (remote procedure calls) ou troca de mensagens, em um ambiente independente
de plataforma e linguagem de programação. 

Última versão do SOAP é 1.2.

SOAP normalmente
utiliza HTTP.



Uma mensagem SOAP consiste dos seguintes elementos:



Envelope:
toda mensagem SOAP deve contê-lo. É o elemento
raiz do documento XML. O&nbsp;Envelope&nbsp;pode
conter declarações de namespaces e
também atributos adicionais (como&nbsp;estilo
de codificação)
Header: 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&nbsp;Header&nbsp;deve ser o primeiro
elemento do&nbsp;Envelope.
Body:
Este elemento é obrigatório e contém
o payload, ou a informação a ser transportada
para o seu destino final. O elemento&nbsp;Body&nbsp;pode conter um elemento opcional&nbsp;Fault, usado para carregar mensagens
de status e erros retornadas pelos "nós" ao processarem a mensagem.









Figura. Estrutura de uma mensagem SOAP.





SOAP e RPC



Atualmente as aplicações
se comunicam usando&nbsp;Remote Procedure Calls&nbsp;(RPC) usando
objetos como DCOM e CORBA, mas o HTTP não foi projetado para esse tipo de
aplicação. O RPC apresenta problemas de compatibilidade e segurança, por isso
firewall e servidores proxy normalmente bloqueiam esse tipo de tráfego, o
protcolo RPC roda na porta 135 TCP.

Como a melhor maneira de
se comunicar entre as aplicações é através de HTTP, e o HTTP é suportado por
todos os navegadores de internet e servidores, foi desenvolvido o SOAP para
fazer isso.

&nbsp;SOAP foi
desenhado para encapsular e transportar chamadas de RPC. Para isso utiliza XML,
sob HTTP.



Como acontece
as chamadas RPC no SOAP?

Processo de uma chamada RPC:&nbsp;Antes de serem enviadas pela rede, as chamadas de RPC (emitidas
pela aplicação cliente) são encapsuladas (ou&nbsp;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&nbsp;serializada&nbsp;e
enviada pela rede. Na máquina cliente, esta resposta é desencapsulada e é
repassada para a aplicação cliente.




Fonte: livro Web Services SOAP em Java




Questões de concursos





FGV 2009 MEC

Um&nbsp;Web Service&nbsp;é definido pela&nbsp;W3C&nbsp;como um sistema de&nbsp;software&nbsp;projetado para fornecer interoperabilidade entre máquinas em uma determinada rede. Dentro do contexto dos&nbsp;Web Services&nbsp;assinale a alternativa correta.&nbsp;a) A&nbsp;UDDI&nbsp;(Universal Description, Discovery, and Integration) é uma linguagem baseada em&nbsp;XML&nbsp;que descreve o que um&nbsp;Web Service&nbsp;pode fazer, onde ele reside e como chamá-lo.&nbsp;

b)&nbsp;SOAP&nbsp;(Simple Object Access Protocol) é um protocolo, baseado em&nbsp;XML, para troca de informação estruturada com&nbsp;Web Services&nbsp;em redes de computadores.&nbsp;

c) A interoperabilidade entre os&nbsp;Web Services&nbsp;e aplicações é garantida devido ao uso obrigatório da linguagem&nbsp;Java&nbsp;na implementação das aplicações.&nbsp;

d)&nbsp;SOA&nbsp;(Simple Object Access) é uma plataforma de arquitetura orientada a serviços, utilizada como base para suportar os&nbsp;Web Services.

e) A&nbsp;WSDL&nbsp;(Web Services Description Language) é uma especificação para publicar e localizar informações sobre&nbsp;Web Services.





Comentário:&nbsp;

Letra a)

"É uma linguagem baseada em&nbsp;XML&nbsp;que descreve o que um&nbsp;Web Service&nbsp;pode fazer, onde ele reside e como chamá-lo" é uma característica do WSDL.



Letra b)

Resposta correta.



Letra c)

Não é obrigatório a utilização da linguagem JAVA para implementação de web services. Uma dos benefícios dos Web Services é justamente ser independente de linguagens, plataformas, arquitetura, etc.



Letra d)

SOA é&nbsp;Service-oriented architecture. Arquitetura orientada a serviços.&nbsp;




Letra e)


"Uma especificação para publicar e localizar informações sobre&nbsp;Web Services"&nbsp;é a definição de UDDI.