Simple Object Access Protocol Entendendo o Simple Object Access Protocol (SOAP)

(1)

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.

(2)

Envelope É o elemento principal do XML que representa a_mensagem.

Header É um mecaninsmo genérico de adição de característicasà mensagem SOAP em maneira descentralizada sem acordo anterior entre as partes comunicantes.

Body

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 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>

</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>

</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

(3)

Nem todas as partes de uma mensagem SOAP interessam a um destinatário, assim como podem interessar a um ou mais intermediários no caminho da mensagem.

Quando uma aplicação SOAP (digamos A) recebe um elemento de cabeçalho ela é dita receptora e encara o cabeçalho como um contrato entre ela e quem repassou a mensagem. Dessa forma, ao repassar a mensagem para outra aplicação (B), a aplicação A deve incluir um cabeçalho similar ao atual, mas no caso, o contrato deve ser entre A e B.

Atributo actor pode ser usado como um indicador do receptor de um elemento de cabeçalho. Ele funciona como o mecanismo 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.

Atributo “mustUnderstand”

Este atributo pode ser usado para indicar se uma entrada de cabeçalho é obrigatória ou opcional para o receptor processar. O seu valor pode ser 1 ou 0. Se o atributo não for escrito, o cabeçalho se comporta como tendo o atributo e o valor 0.

Nota

Lembrando que os receptores das entradas de cabeçalho são definidas pelo atributo actor

O Corpo SOAP

O corpo da mensagem SOAP é uma parte obrigatória que guarda dados específicos de uma chamada de um método 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 corpo da mensagem incluem chamadas remotas à métodos e notificações de erros.

Ele está presente logo após o cabeçalho da mensagem, se este existir. Caso não exsita, ele deve aparecer imediatamente após a

tag de abertura do envelope.

O conteúdo do corpo da mensagem SOAP depende se ela é uma requisição ou uma resposta. Caso seja requisição, ele contém informaçõesssobre a chamada do método, se é uma resposta contém dados do resultado da chamada ao método. Nas Figuras 6 e 7 temos, respectivamente, exemplos de uma requisição e uma resposta. A requisição é feita para converter um valor e a resposta é o valor convertido.

<soap:Envelope xmlns:xsi="Schema-Instance" xmlns:xsd="Schema" xmlns:soap="Envelope"> <soap:Body> <Converte xmlns="http://conv.fractalti.com.br"> <Valor>10</Valor>

Figura 6: Uma requisição SOAP que passa um valor para ser convertido de Decimal para Binário.

<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 7: Uma resposta SOAP que retorna um valor convertido para binário. Por algum motivo a resposta pode conter erros, e o resultado apresentado será uma exceção (fault), como veremos posteriormente.

Nota

Na resposta SOAP, o elemento responsável pela resposta usa o mesmo nome do elemento de chamada (Converte) concatenado com o sufixo Response.

Tipos de Dados suportados pelo SOAP

A especificação do SOAP define o suporte aos tipos de dados 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 hierárquicas.

Tipos definidos pelo usuário também são aceitos, de forma que é possível formar estruturas de dados a partir dos dados primitivos oferecidos pela XSD. Mais uma grande vantagem do uso do SOAP, que aceita qualquer tipo que possa ser representado por um XSD Schema.

Nas Figura 8 temos uma tabela com os tipos aceitos no XSD.

boolean float timeInstant

byte int unsignedByte

double long unsignedInt

datatype Qname unsignedLong

decimal short unsignedShort

enumeration string

Figura 8: Tipos básicos de dados suportados pelo SOAP. Nota

A formação de dados mais complexos foge do escopo deste artigo, pois é uma especificação do XML. Caso haja o interesse de mais informações de como manipular este tipo de dados, visite: XML Schema Part 1: Structures

http://www.w3.org/TR/xmlschema-1/ XML Schema Part 1: Data Types http://www.w3.org/TR/xmlschema-2/

Exceções SOAP

Como os métodos acessados via SOAP não estão livres de erros, é necessária alguma forma de notificação que ocorreu um erro e onde este erro foi encontrado. Infelizmente erros (com certa freqüência) ocorrem.

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.

(4)

As exceções SOAP podem ocorrer em vários estágios do processamento de requisições de um web service. Se o erro ocorre no envio HTTP, antes da chegada no web

service, a camada do HTTP responsável pelo erro deve utilizar a

convenção do prórpio HTTP para notificá-lo.

Caso o erro ocorra na prórpia execução do aplicativo SOAP, podemos ver na Figura 9 o código gerado, o erro e a sua descrição.

Valor Nome Significado

100 Version_Mismatch A chamada usou uma versão SOAP que ela não_suporta.

200 Must_Understand

Um elemento XML foi recebido com o atributo mustUnderstand com valor “1” , mas não foi entendido pelo receptor.

300 Invalid_Request O receptor não conseguiu processar arequisição por que ela está mal-formada ou não é suportada.

400 Application_Faulted O recebimento da aplicação falhou quando o_{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.

Na Figura 10 vemos uma resposta SOAP contendo uma exceção. Note que a excessão foi gerada pela aplicação (erro 400) ao tentar-se dividir um número por 0 (zero).

<soap:Envelope xmlns:xsi="Schema-Instance" xmlns:xsd="Schema" xmlns:soap="Envelope"> <soap:Body> <soap:Fault> <faultcode>400</faultcode>

<faultstring>Divide by zero error</faultstring> <detail> <t:DivideByZeroException xmlns:soap="http://www.fractalti.com.br"> <expression>x = 2 / 0;</expression> </t:DivideByZeroException> </detail> </soap:Fault> </soap:Body> </soap:Envelope>

Figura 10: Exceção ocorrida em uma requisição SOAP.

Transportando SOAP via HTTP

Para entregar mensagens codificadas em SOAP como requisições ou como respostas, precisamos um protocolo de transporte. Claramente, por se tratar especialmente de web

services, este protocolo deve ser largamente utilizado. A escolha

óbiva seria o HTTP.

O SOAP é naturalmente levado a utilizar o modelo de requisição/resposta proposto no HTTP.

Nota

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 cabeçalho do HTTP Connection inspecione ou processe o corpo SOAP carregado no HTTP Request

HTTP Post

O comando Post do HTTP será o responsável pelo envio da mensagem SOAP. Ele contém uma URI requisitora que especifica um destino ID. O sevidor é responsável por mapear a URI para a implementação do Web Service e ativar o código intrínseco à plataforma onde o serviço irá rodar.

Ainda no cabeçalho do HTTP temos um campo com o nome do método chamado.

Seguido pelo cabeçalho, temos a própria mensagem SOAP, que é separada por uma linha em branco.

A Figura 11 temos um modelo de uma estrutura SOAP contida em uma requisição HTTP Post.

Figura 11: Estrutura do HTTP Post com uma mensagem SOAP.

Na Figura 12 vemos o exemplo da Figura 6 sendo enviado via HTTP Post.

POST /ctemp/ctemp.asmx HTTP/1.1 Host: localhost

Content-Type: text/xml; charset=utf-8 Content-Length: length

SOAPAction: "http://site.com.br"

<?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.fractalti.com.br"> <Valor>10</Valor>

Figura 12: Exemplo de requisição feita via HTTP Post.

HTTP Response

É o comando responsável por enviar a resposta de um web

service.

Agora, na Figura 13, temos uma resposta HTTP. Note que URI do destinatário não é mais necessária, apesar da estrutura manter-se igual.

(5)

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.