Protocolo de Transporte Padrão – SOAP

O SOAP surgiu no ano de 1998, apresentado ao World Wide Web Consortium (W3C) pelas empresas DevelopMentor, Microsoft e UserLand Software como um “Internet Draft”. Inicialmente, este protocolo definia um mecanismo para transmissão de procedimentos remotos XML sobre HTML. Devido a divergências políticas, sua especificação em 1998 não ocorreu, mas sim em dezembro de 1999.

É um dos principais elementos dos Web Services, apesar de não ser necessário o conhecimento do seu funcionamento para se criar e consumir um Web Service. Porém, o entendimento geral do protocolo é útil para se lidar com eventuais situações de erros e problemas com a interoperabilidade entre plataformas no uso de Web Services.

O protocolo se encontra na versão 1.2. Dividida em duas partes principais: A primeira parte da especificação define um framework de mensagens. Protocolos de rede variados, como HTTP, SMTP, FTP, RMI/IIOP ou um protocolo de mensagem proprietário servem como carregadores das mensagens SOAP. A segunda define três componentes opcionais: um conjunto de regras de codificação para expressar instâncias dos tipos de dados definidos pela aplicação, uma convenção para representar RPCs e respostas e um conjunto de regras para usar SOAP com HTTP/1.1.

Segundo W3C, as duas especificações se classificam da seguinte maneira:

. Service Oriented Architecture Protocol: no caso geral, uma mensagem SOAP representa a informação necessária para invocar um serviço ou analisar o resultado de uma chamada e contém informações específicas da definição da interface do serviço.

. Service Object Access Protocol: representação opcional do SOAP RPC, a mensagem SOAP representa um método de invocação de um objeto remoto, e a serialização da lista de argumentos do método que precisam ser movidos do ambiente local para o ambiente remoto.

Em outras palavras, SOAP possibilita dois processos (possivelmente em duas máquinas diferentes) comunicarem entre si, desconsiderando o hardware e a plataforma que eles estão rodando.

Não está vinculado a nenhuma plataforma de hardware, software ou linguagem de programação. É considerado superficial, pois contém menos recursos que outros protocolos de computação distribuídos.

Um dos grandes benefícios do SOAP é que ele é aberto e foi adotado pela maioria das grandes empresas de hardware e software.
A sua especificação provê a base para a comunicação aplicação-aplicação:
os Web Services. Construído no topo de padrões abertos como HTTP e XML, facilita o aprendizado, por parte dos desenvolvedores e o suporte das infra-estruturas.

Ele é um protocolo que define uma gramática XML especializada, porém flexível, que padroniza o formato das estruturas das mensagens. As mensagens são, por outro lado, o método fundamental de troca de informações entre os Web Services e os seus consumidores. Ao utilizar XML para codificar mensagens o SOAP nos dá alguns benefícios, segundo Rommel:

. XML pode ser facilmente lido por usuários, portanto, mais fácil de entender e eliminar erros.

. XML parsers (analistas) e tecnologias correlatas são mundialmente disponíveis.

. XML é um padrão aberto.

. XML inclui várias tecnologias que podem fortalecer o SOAP.

. Simplificação da especificação, diferente de outros protocolos binários como COM, DCOM e CORBA.

Principais vantagens da utilização do protocolo SOAP, em relação a outros sistemas de comunicação, segundo Simone da Silva Amorim:

. Pode atravessar firewalls com facilidade.

. Os dados do SOAP são estruturados usando XML. Portanto, as mensagens podem ser compreendidas por quase todas as plataformas de hardware, sistemas operacionais e linguagens de programação.

. Pode ser usado, potencialmente, em combinação com vários protocolos de transporte de dados, como HTTP, SMTP e FTP.

. O SOAP mapeia satisfatoriamente para o padrão de solicitação / resposta HTTP.

. Pode ser usado tanto de forma anônima como com autenticação (nome/senha).

Principais desvantagens:

. Falta de interoperabilidade entre ferramentas de desenvolvimento do SOAP. Embora o SOAP tenha amplo suporte, ainda existem problemas de incompatibilidades entre diferentes implementações do SOAP.

. Mecanismos de Segurança Imaturos. O SOAP não define mecanismo para criptografia do conteúdo de uma mensagem SOAP, o que evitaria que outros tivessem acesso ao conteúdo da mensagem.

. Não existe garantia quanto à entrega da mensagem. Quando uma mensagem estiver sendo transferida, se o sistema falhar, ele não saberá como reenviar a mensagem.

. Um cliente SOAP não pode enviar uma solicitação a vários servidores, sem enviar a solicitação a todos os servidores.

O fato das aplicações permitirem que o SOAP seja usado com o HTTP permite transpor barreiras como firewalls com facilidade, permitindo que os softwares que aceitem SOAP estejam disponíveis internamente e externamente na rede. Esta característica pode ser vista como vantagem e também como desvantagem, já que pode causar um sério problema de segurança, onde as aplicações do SOAP seriam acessíveis por partes não autorizadas.

Resumindo, SOAP é um protocolo leve, o que faz ele ter poucos recursos e de fácil entendimento. Mas, por outro lado, nos faz ter uma preocupação maior com relação a segurança e transporte das mensagens.

Funcionalidades do SOAP

O SOAP nos provê as seguintes funcionalidades:

. Interoperabilidade entre sistemas utilizando linguagens e protocolos padronizados largamente difundidos, como XML e HTTP.

. Permite a comunicação entre sistemas protegidos por firewalls, sem precisar abrir portas adicionais e possivelmente não seguras. Ele utiliza (na maioria dos servidores) a porta 80.

. SOAP descreve completamente cada elemento na mensagem, facilitando o entendimento e a proteção contra erros.

E, algumas funcionalidades que o SOAP não é capaz de executar:

. Coleta de lixo distribuída.

. Objetos por Referência (pois é necessária a coleta de lixo distribuída).

Estrutura

De acordo com o W3Schools, a estrutura da mensagem SOAP é definida em um documento XML que contém os seguintes elementos:

<SOAP-ENV:envelope>
<!— Elemento raiz do SOAP e define que essa é uma mensagem SOAP–>
<SOAP-ENV:header>
<!—Especifica informações especificas como autenticação (opcional)–>
</SOAP-ENV:header>
<SOAP-ENV:body>
<!—O elemento BODY contém o corpo da mensagem–>
<SOAP-ENV:fault>
<!—O elemento FAULT contém os erros que podem ocorrer–>
</SOAP-ENV:fault>
</SOAP-ENV:body>
</SOAP-ENV:envelope>

Envelope (obrigatório): é responsável por definir o conteúdo da mensagem;

encodingStyle: atributo que tem como objetivo especificar como as informações devem ser codificadas.

<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>

</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Header (opcional): contém os dados do cabeçalho;

<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”>
<a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

actor: especifica o receptor que deve processar o elemento do cabeçalho.

<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”
SOAP-ENV:actor=”http://www.mauricioreckziegel.com/soap/authenticator”>
<a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>

musUnderstand: especifica se uma entrada de cabeçalho é obrigatória ou opcional (booleano).

<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”
SOAP-ENV:mustUndestrand=”1”>
<a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>

. Body (obrigatório): contém a codificação atual de uma chamada a um método e todos os argumentos de entrada ou uma resposta codificada que contém o resultado de uma chamada de um método.

. Fault: contém as informações dos erros ocorridos no envio da mensagem. Apenas nas mensagens de resposta do servidor.

O envelope SOAP é a parte obrigatória de uma mensagem SOAP. Ele funciona como um recipiente de todos os outros elementos da mensagem, possivelmente o cabeçalho e o corpo, assim como os namespaces de cada um. Assim como o nome e o endereço de uma carta entregue pelo correio, o envelope SOAP precisa das informações específicas do protocolo de transporte que está ligado a ele, com o intuito de garantir a chegada ao local certo. Especificamente no HTTP, temos um cabeçalho que se chama SOAPAction, indicador do endereço de entrega da mensagem. Um dos principais motivos de implementarmos o cabeçalho desta maneira é porque administradores de sistemas podem configurar seus firewalls para filtrar as mensagens baseadas nas informações dos cabeçalhos, sem consultar o XML.

Elemento

Namespace / URI

Envelope

http://schemas.xmlsoap.org/soap/envelope

Serializador

http://schemas.xmlsoap.org/soap/encoding

SOAP-ENV

http://schemas.xmlsoap.org/soap/envelope

SOAP-ENC

http://schemas.xmlsoap.org/soap/encoding

Xsi

http://www.w3.org/1999/XMLSchema-instance

Xsd

http://www.w3.org/1999/XMLSchema

Tabela. Namespaces / URI padrões do SOAP


Figura. Envelope

Concluindo, segundo Marcus Rommel, o SOAP é o elemento principal da infra-estrutura dos Web Services e um fator fundamental para o funcionamento dos mesmos, independente de plataformas, sistemas operacionais, modelos de objetos e linguagens de programação, auxiliando muito a interoperabilidade entre objetos e componentes distribuídos. Este tem um papel muito importante e acaba com a disputa entre linguagens, garantindo que o programador possa desenvolver no ambiente que seja mais adequado às suas necessidades. Além de todas essas qualidades, o fato também de não ser preciso o seu conhecimento para sua utilização fazem do SOAP uma excelente escolha para o desenvolvimento de Web Services.

O fato de não ser preciso o seu conhecimento para a manipulação dos Web Services facilita a vida de qualquer programador. Visto que a maioria das linguagens já trazem classes implementadas deste protocolo, facilitando ainda mais a sua utilização.

Tipos de dados

Tipo de Valor

Tipo

Exemplo

xsd:int 32-bit signed integer -12
xsd:Boolean A Boolean value, 1 or 0 1
xsd:string String of characters Hello word
xsd:float or xsd:double Signed floating point number -12.100
xsd:timeInstant Date/time 2006-05-20T00:00:04-09:00
SOAP-ENC:base64 Base64-encoded binary aFKDS87ds9Kds38aWQR9tx

Tabela. Valores escalares suportados pelo protocolo.

SOAP também suporta tipos de dados arrays e structs. 

SOAP em HTTP

O SOAP teoricamente atua sobre qualquer protocolo de transporte, mas, sem dÚvida nenhuma o http é o protocolo mais utilizado para a utilização de Web Services.
Através do comando Post do HTTP é possível o envio das mensagens SOAP, utilizando-se da URI requisitora que especifica um destino ID. No cabeçalho do http, também temos um campo com o nome do método a ser chamado.

POST /rpcrouter HTTP/1.1
Host: 127.0.0.1
Content-Type: text/xml; charset=utf-8
Content-Length: 559
SOAPAction: “http://mauricio.com”
<?xml version=”1.0” encoding=”utf-8“?>
<soap:Envelope
xmlns:xsi=”Schema-Instance
xmlns:xsd=”Schema
xmlns:soap=”Envelope“>
<soap:Body>
<Converte xmlns=”http://conv.com.br“>
<Valor>5</Valor>
<De>DEC</De>
<Para>BIN</Para>
</Converte>
</soap:Body>
</soap:Envelope>

Através do HTTP Response é que obtemos uma resposta da solicitação SOAP. Note que alguns itens já não são mais necessários.

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version=”1.0” encoding=”utf-8“?>
<soap:Envelope
xmlns:xsi=”Schema-Instance
xmlns:xsd=”Schema
xmlns:soap=”Envelope“>
<soap:Body>
<ConverteResponse xmlns=”http://mauricio.com“>
<ValorResult>101</ValorResult>
</ConverteResponse>
</soap:Body>
</soap:Envelope>

_________________________________

Fonte: iMasters – Mauricio Reckziegel

Anúncios

About Gustavo Amaro

+ Formado em Tecnologia e Análise de Sistemas + MBA em Desenvolvimento de Aplicações JAVA – SOA

Posted on 1 de Outubro de 2012, in Integração, SOAP, Web Service and tagged , , , , , . Bookmark the permalink. Deixe um comentário.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

%d bloggers like this: