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