por Marcus Rommel Barbosa Leopoldo
Simple Object Access Protocol
Entendendo o Simple Object Access Protocol (SOAP)
Neste artigo vamos fazer uma análise geral da base da tecnologia SOAP. Conheceremos as
suas características principais e formas de envio das mensagens, assim como a sua relação
com protocolos de redes, especificamente o HTTP.
O protocolo SOAP é um dos elementos
fundamentais dos Web Services, apesar de não ser
necessário o conhecimento do funcionamento do
protocolo para criar e consumir Web Services. O
entendimento geral do protocolo será útil para
lidar com situações de erros e problemas com a
interoperabilidade de plataformas no uso de Web
Services.
Pré-Requisitos
Para acompanhar adequadamente este artigo, o
leitor deve estar familiarizado com os seguintes
assuntos:
• Conhecimentos intermediários em XML.
• Conhecimentos básicos em protocolos de
redes de computadores, especificamente o
protocolo HTTP.
O que é SOAP?
O SOAP é um protocolo simples e leve para troca
de informação em um ambiente distribuído e
descentralizado, como é o ambiente da Internet.
Em outras palavras, SOAP habilita dois processos
(possivelmente em duas máquinas diferentes)
comunicarem entre sí desconsiderando o hardware
e a plataforma que eles estão rodando.
Um dos grandes benefícios do SOAP é que ele é
aberto e foi adotado pela grande maioria das
grandes empresas de hardware e software. A sua
especificação é aberta (ela foi submetida ao
W3C*) e provê a base para a comunicação
aplicação-aplicação: os Web Services.
Nota
O W3C (World Wide Web Consortium) cria padrões
para a Web, com o objetivo de aumentar ao máximo o
potencial da Web, com especificações, diretrizes,
softwares e ferramentas.
Ele é um protocolo que define uma gramática
XML especializada, porém flexível, que padroniza
o formato das estrututras das mensagens. As
mensagens são, por outro lado, o método
fundamental de troca de informações entre os Web
Sevices e os seus consumidores. Ao utilizar XML
para codificar mensagens o SOAP nos dá alguns
benefícios:
• XML pode ser facilmente lido por humanos,
sendo portanto, mais fácil de entender e
eliminar erros.
• XML parsers (analistas) e tecnologias co-
relatas 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.
Funcionalidades do SOAP
O SOAP nos provê algumas 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.
A seguir, algumas funcionalidades que o SOAP
não é capaz de executar:
• Coleta de lixo distribuida.
• Objetos por Referência (pois é necessária a
coleta de lixo distribuída).
• Definição de um mecanismo de autenticação.
Especificação do protocolo
A especificação do protocolo SOAP é uma nota
submetida ao W3C que está agora no mesmo
grupo dos protocolos XML. A especificação 1.1
do protocolo está dividida em 4 partes principais:
• SOAP Envelope: define uma plataforma para
descrição do que há na mensagem e como
processá-la. Ela guarda todos os dados da
mensagem e é a única parte do protocolo que
é obrigatória.
• SOAP Encoding Rules: define um mecanismo
de serialização que pode ser usado para a
troca de instâncias de tipos definidos pela
aplicação.
• SOAP RPC Style: define uma convenção que
pode ser usada para representar chamadas e
repostas remotas à procedimentos, nada mais
que a dupla requisição/resposta, que não é
obrigatória.
• Link SOAP-HTTP: define um protocolo que
liga o SOAP e o HTTP. Ele descreve como as
mensagens SOAP são transmitidas via HTTP.
Elementos da Mensagem SOAP
A mensagem SOAP é formada por 3 elementos
básicos, como visto na Figura 1.
 É o elemento principal do XML que representa a
Envelope
mensagem.
É um mecaninsmo genérico de adição de características
Header à mensagem SOAP em maneira descentralizada sem
acordo anterior entre as partes comunicantes.
Contém a codificação atual de uma chamada a um
método e todos os argumentos de entrada ou uma
Body
resposta codificada que contém o resultado de uma
chamada a um método
Figura 1: Elementos da mensagem SOAP.
A partir de agora chamaremos os 3 elementos de Envelope,
Cabeçalho e Corpo do protocolo respectivamente.
Na Figura 2 vemos a estrutura da mensagem SOAP.
Figura 2: Estrutura da mensagem SOAP.
O Envelope SOAP
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 meneira é por quê administradores de sistemas podem
configurar seus firewalls para filtrar as mensagens baseados nas
informações dos cabeçalhos, sem consultar o XML.
A Figura 3 ilustra a formatação de um envelope SOAP.
<soap:Envelope
xmlns:xsi="Schema-Instance"
xmlns:xsd="Schema"
xmlns:soap="Envelope">
<soap:Body>
<!-- Os elementos do corpo inseridos aqui!!! -->
</soap:Body>
</soap:Envelope>
Figura 3: Exemplo de formatação de envelope SOAP.
O Cabeçalho SOAP
O cabeçalho SOAP é uma parte opcional da mensagem. O
conceito é similar aos Meta Tags dos documentos HTML. Eles
definem meta-dados que pode prover um contexto para a
mensagem ou redirecionar o processamento da mensagem.
Veja na Figura 4 a formatação de um cabeçalho SOAP.
<soap:Envelope
xmlns:xsi="Schema-Instance"
xmlns:xsd="Schema"
xmlns:soap="Envelope">
<soap:Header>
<Autentica xmlns="Local">
<Usuario>usuario</Usuario>
<Senha>senha</Senha>
</Autentica>
</soap:Header>
<soap:Body>
<!-- Os elementos do corpo inseridos aqui!!! -->
</soap:Body>
</soap:Envelope>
Figura 4: Exemplo de formatação de cabeçalho SOAP.
Uma utilização típica do cabeçalho SOAP é na área de
autenticação, onde as credenciais requeridas para o acesso ao
método são codificadas. Ele também é muito usado em
gerenciamento de transações, pagamentos etc.
Se uma mensagem contém um cabeçalho, este deve ser o
primeiro elemento a aparecer na mensagem após a tag de
abertura do envelope e todos os elementos filhos do cabeçalho
(na Figura 3 o Usuario e a Senha) são definidos como
cabeçalhos separados e chamados entradas de cabeçalho
(header entries), que devem usar namespaces XML para
qualificar seus nomes.
Atributos SOAP globais
Existem 3 atributos no SOAP que podem ser utilizados na
mensagem:
• encodingStyle: pode ser usado para indicar o estilo de
codficação
• mustUnderstand e actor: podem ser utilizados para indicar
como e quem irá processar as entradas.
Atributo “encodingStyle”
O encodingStyle é um atributo global que pod ser usado para
indicar regras de serialização usadas nas mensagens SOAP. Ele
pode aparecer em qualquer elemento, e seu escopo é todo o
conteúdo do elemento, assim como os elementos filhos.
O valor deste atributo é uma lista de uma ou mais URI
identificando as regras de serialização ou deserialização,
indicadas na ordem da mias específica para a mais abrangente.
Temos na Figura 5 exemplos de valores para o atributo
encodingStyle.
“http://www.xml.it/schemas”
“http://www.xml.it/schemas http://schemas.eu.com.br”
“”
Figura 5: Valores válidos para o atributo encodingStyle.
O valor vazio (a terceira linha da Figura 5) explicitamente indica
que não há requisição de encodingStyle para o elemento
contido. Isso pode ser usado para “descodificar” uma requisição
feita à um elemento pai.
Atributo “actor”
Algumas aplicações SOAP são chamadas de intermediárias pois
têm a capacidade de receber e encaminhar uma mensagem
SOAP. Uma mensagem SOAP pode sair de um remetente para
um destinatário e, potencialmente, passar por várias aplicações
SOAP intermediárias.
Nota
Tanto as aplicações SOAP intermediárias como as destinatárias são
identificadas via URI
Nem todas as partes de uma mensagem SOAP interessam a um <soap:Envelope
destinatário, assim como podem interessar a um ou mais xmlns:xsi="Schema-Instance"
intermediários no caminho da mensagem. xmlns:xsd="Schema"
xmlns:soap="Envelope">
<soap:Body>
Quando uma aplicação SOAP (digamos A) recebe um elemento <ConverteResponse xmlns="http://site.com.br">
de cabeçalho ela é dita receptora e encara o cabeçalho como um <ValorResult>1010</ValorResult>
contrato entre ela e quem repassou a mensagem. Dessa forma, </ConverteResponse>
</soap:Body>
ao repassar a mensagem para outra aplicação (B), a aplicação A </soap:Envelope>
deve incluir um cabeçalho similar ao atual, mas no caso, o
Figura 7: Uma resposta SOAP que retorna um valor convertido para binário.
contrato deve ser entre A e B.
Por algum motivo a resposta pode conter erros, e o resultado
Atributo actor pode ser usado como um indicador do receptor
apresentado será uma exceção (fault), como veremos
de um elemento de cabeçalho. Ele funciona como o mecanismo
posteriormente.
de hops representado pelo campo Connection do cabeçalho do
HTTP. O seu valor é uma URI, que se for vazio, informa que o
receptor é o destinatário. Nota
Na resposta SOAP, o elemento responsável pela resposta usa o mesmo
nome do elemento de chamada (Converte) concatenado com o sufixo
Atributo “mustUnderstand” Response.
Este atributo pode ser usado para indicar se uma entrada de
cabeçalho é obrigatória ou opcional para o receptor processar.
Tipos de Dados suportados pelo SOAP
O seu valor pode ser 1 ou 0. Se o atributo não for escrito, o A especificação do SOAP define o suporte aos tipos de dados
cabeçalho se comporta como tendo o atributo e o valor 0. baseado no XSD, a especificação do XML Schema Definition.
Esta especificação define padrões para a descrição de tipos
primitivos de dados assim como estruturas complexas e
Nota hierárquicas.
Lembrando que os receptores das entradas de cabeçalho são definidas
pelo atributo actor
Tipos definidos pelo usuário também são aceitos, de forma que é
possível formar estruturas de dados a partir dos dados primitivos
O Corpo SOAP oferecidos pela XSD. Mais uma grande vantagem do uso do
O corpo da mensagem SOAP é uma parte obrigatória que SOAP, que aceita qualquer tipo que possa ser representado por
guarda dados específicos de uma chamada de um método um XSD Schema.
particular, tais como o nome do método e parâmetros de entrada,
saída e resultados produzidos pelo método. As utilizações do Nas Figura 8 temos uma tabela com os tipos aceitos no XSD.
corpo da mensagem incluem chamadas remotas à métodos e
notificações de erros. boolean float timeInstant

Ele está presente logo após o cabeçalho da mensagem, se este byte int unsignedByte
existir. Caso não exsita, ele deve aparecer imediatamente após a double long unsignedInt
tag de abertura do envelope.
datatype Qname unsignedLong
O conteúdo do corpo da mensagem SOAP depende se ela é uma decimal short unsignedShort
requisição ou uma resposta. Caso seja requisição, ele contém
enumeration string
informaçõesssobre a chamada do método, se é uma resposta
contém dados do resultado da chamada ao método. Figura 8: Tipos básicos de dados suportados pelo SOAP.

Nas Figuras 6 e 7 temos, respectivamente, exemplos de uma Nota

requisição e uma resposta. A requisição é feita para converter A formação de dados mais complexos foge do escopo deste artigo,
pois é uma especificação do XML. Caso haja o interesse de mais
um valor e a resposta é o valor convertido.
informações de como manipular este tipo de dados, visite:
XML Schema Part 1: Structures
<soap:Envelope http://www.w3.org/TR/xmlschema-1/
xmlns:xsi="Schema-Instance" XML Schema Part 1: Data Types
xmlns:xsd="Schema" http://www.w3.org/TR/xmlschema-2/
xmlns:soap="Envelope">
<soap:Body>
<Converte xmlns="http://conv.fractalti.com.br">
<Valor>10</Valor>
Exceções SOAP
<De>DEC</De> Como os métodos acessados via SOAP não estão livres de erros,
<Para>BIN</Para> é necessária alguma forma de notificação que ocorreu um erro e
</Converte> onde este erro foi encontrado. Infelizmente erros (com certa
</soap:Body>
</soap:Envelope> freqüência) ocorrem.
Figura 6: Uma requisição SOAP que passa um valor para ser convertido de
Decimal para Binário.
Estes erros ou exceções, que ocorrem em um web service devem
ser retornados ao consumidor de alguma maneira, e é aí que
entra a exceção SOAP.

Nota
A especificação oficial do SOAP usa o termo fault (falha) ao invés de
exception (exceção). Foi dada preferência ao termo exceção por estar
em sintonia com a terminologia usada na maioria das lingüagens de
programação.
As exceções SOAP podem ocorrer em vários estágios do Nota
processamento de requisições de um web service. As aplicações SOAP intermediárias não são as mesmas que os
intermediários do HTTP . Ou seja, não podemos esperar que o
Se o erro ocorre no envio HTTP, antes da chegada no web cabeçalho do HTTP Connection inspecione ou processe o corpo SOAP
service, a camada do HTTP responsável pelo erro deve utilizar a carregado no HTTP Request
convenção do prórpio HTTP para notificá-lo.
HTTP Post
Caso o erro ocorra na prórpia execução do aplicativo SOAP, O comando Post do HTTP será o responsável pelo envio da
podemos ver na Figura 9 o código gerado, o erro e a sua mensagem SOAP. Ele contém uma URI requisitora que
descrição. especifica um destino ID. O sevidor é responsável por mapear a
URI para a implementação do Web Service e ativar o código
Valor Nome Significado intrínseco à plataforma onde o serviço irá rodar.
Version A chamada usou uma versão SOAP que ela não
100 Ainda no cabeçalho do HTTP temos um campo com o nome do
Mismatch suporta.
método chamado.
Um elemento XML foi recebido com o atributo
Must
200 mustUnderstand com valor “1” , mas não foi
Understand Seguido pelo cabeçalho, temos a própria mensagem SOAP, que
entendido pelo receptor.
é separada por uma linha em branco.
O receptor não conseguiu processar a
Invalid
300 requisição por que ela está mal-formada ou não A Figura 11 temos um modelo de uma estrutura SOAP contida
Request
é suportada. em uma requisição HTTP Post.
Application O recebimento da aplicação falhou quando o
400
Faulted processamento foi requisitado.
Figura 9: Exceções geradas pelo SOAP.

O elemento fault da mensagem SOAP define 4 subelementos

(que são obrigatórios):
• faultcode: É o código da exceção gerada.
• faultstring: É um texto resumindo o motivo do erro, é bom
que ele gere pelo menos a natureza do erro.
• faultactor: Informa quem foi o causador do erro. Similar ao
atributo actor, ele informa a URI de quem causou o erro.
Apenas a aplicação destinatária deve conter o faultactor
• detail: Informa erros específicos da aplicação, ele estará no
cabeçalho ou no corpo da mensagem dependendo do tipo
de erro.

Nota
O erro 400 (Application Failed) é apresentado no elemento detail.
Figura 11: Estrutura do HTTP Post com uma mensagem SOAP.
Na Figura 10 vemos uma resposta SOAP contendo uma
exceção. Note que a excessão foi gerada pela aplicação (erro Na Figura 12 vemos o exemplo da Figura 6 sendo enviado via
400) ao tentar-se dividir um número por 0 (zero). HTTP Post.

<soap:Envelope POST /ctemp/ctemp.asmx HTTP/1.1

xmlns:xsi="Schema-Instance" Host: localhost
xmlns:xsd="Schema" Content-Type: text/xml; charset=utf-8
xmlns:soap="Envelope"> Content-Length: length
<soap:Body> SOAPAction: "http://site.com.br"
<soap:Fault>
<faultcode>400</faultcode> <?xml version="1.0" encoding="utf-8"?>
<faultstring>Divide by zero error</faultstring> <soap:Envelope
<detail> xmlns:xsi="Schema-Instance"
<t:DivideByZeroException xmlns:xsd="Schema"
xmlns:soap="http://www.fractalti.com.br"> xmlns:soap="Envelope">
<expression>x = 2 / 0;</expression> <soap:Body>
</t:DivideByZeroException> <Converte xmlns="http://conv.fractalti.com.br">
</detail> <Valor>10</Valor>
</soap:Fault> <De>DEC</De>
</soap:Body> <Para>BIN</Para>
</soap:Envelope> </Converte>
</soap:Body>
Figura 10: Exceção ocorrida em uma requisição SOAP. </soap:Envelope>
Figura 12: Exemplo de requisição feita via HTTP Post.
Transportando SOAP via HTTP
Para entregar mensagens codificadas em SOAP como HTTP Response
requisições ou como respostas, precisamos um protocolo de É o comando responsável por enviar a resposta de um web
transporte. Claramente, por se tratar especialmente de web service.
services, este protocolo deve ser largamente utilizado. A escolha
óbiva seria o HTTP. Agora, na Figura 13, temos uma resposta HTTP. Note que URI
do destinatário não é mais necessária, apesar da estrutura
O SOAP é naturalmente levado a utilizar o modelo de manter-se igual.
requisição/resposta proposto no HTTP.
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://site.com.br">
<ValorResult>1010</ValorResult>
</ConverteResponse>
</soap:Body>
</soap:Envelope>
Figura 13: Exemplo de requisição feita via HTTP Post.

Outras vias de transporte

Apesar de preferido, o HTTP não é uma forma obrigatória de
envio de mensagens SOAP.

Também é possível transportar o SOAP via outros protocolos,

tais como FTP e SMTP.

Conclusão
SOAP é o elemento principal da infraestrutura dos Web Services
e um fator determinante para o funcionamento dos mesmos,
independente de plataformas, sistemas operacionais, modelos de
objetos e lingüagens de programação, auxiliando muito a
interoperabilidade entre objetos e componentes distribuídos.

Este protocolo acaba com a disputa entre lingüagens, garantindo

que o programador possa desenvolver no ambiente que seja
mais adequado às suas necessidades.

Apesar de ser uma tecnologia recente, SOAP já tem um lugar

significativo na internet, sendo portanto, uma excelente escolha
para desenvolvimento de Web Services.

Marcus Rommel é desenvolvedor da Fractal TI (www.fractalti.com.br)

e atualmente trabalha com a plataforma .NET com ênfase no
desenvolvimento de aplicações WEB com ASP.NET e C#, assim
como aplicações Windows Forms com o uso do C#.
mailto: mrommel@fractalti.com.br

O autor permite a cópia e distribuição total ou parcial deste artigo desde

que sejam citados o autor, a fonte e o ano de publicação.
Marcus Rommel, Novembro de 2003