Aquele blog de SOA

Pessoal, para iniciar uma série de posts técnicos sobre web services, neste post vou falar um pouco sobre o SOAP (Simple Object Access Protocol), que é uma das siglas mais famosas quando falamos de Web Services. Todo mundo usa, todo mundo fala, mas, no fundo no fundo, o que é SOAP? Para começar, hoje vou falar sobre o Modelo de processamento SOAP!

SOAP é o protocolo de troca de mensagens usado pelos Web Services. Ele define um modelo de processamento, onde existem sempre dois papeis: initial sender e ultimate receiver. O initial sender é responsável pela criação e envio da mensagem SOAP, já e o ultimate receiver é o destinatário final da mensagem, ou seja, o responsável por ler e processar o conteúdo da mensagem. Existe também um terceiro papel opcional chamado intermediary node que, como o nome já sugere, é um nó intermediário que recebe e reenvia a mensagem para o ultimate receiver ou para outro intermediary node. Geralmente, estes nós intermediários tem a função de acrescentar algum valor no caminho de processamento da mensagem. Pode ser usado, por exemplo, para logging, autenticação, autorização e outros.

Para que este modelo de processamento possa ser implementado. A especificação SOAP define um formato padrão para suas mensagens chamado de SOAP envelope. Os envelopes são definidos no formato XML e iniciam com a tag (env:Envelope). Cada envelope possui um cabeçalho e um corpo. Ambos podendo conter um conjunto de sub-elementos livres de padronização, isto é, blocos de elementos XML  baseado em seus próprios XML Schema. O SOAP header estabelece um espaço para adicionar metadados ao conteúdo da mensagem sem influenciar no seu processamento. O SOAP header pode ser processado e modificado por nós intermediários permitindo assim uma flexibilidade horizontal do protocolo. Aqui surgem algumas questões. Como saber quais elementos XML deverão ser lidos e processados por cada nó intermediário? Para isso, a especificação SOAP define o atributo role que deverá conter a identificação do nó intermediário responsável por processar o trecho. A figura abaixo mostra uma mensagem SOAP contendo header e body. O header contém três blocos. O primeiro bloco (p:oneBlock) deverá ser lido pelo nó intermediário que responda pela identificação http://example.com/Log, o segundo bloco (q:anotherBlock) será processado pelo próximo nó no caminho da mensagem, e o último bloco (r:aThirdBlock) será processado pelo ultimate receiver da mensagem.

O modelo de processamento SOAP define as ações que são tomadas quando um SOAP node recebe uma mensagem SOAP. A especificação SOAP 1.2 esclarece como este processamento deve ser realizado:

1. Determina os roles que o SOAP node desempenha verificando o atributo role de todos os blocos do header do envelope
2. Identifica os blocos assinalados como obrigatórios verificando se contém o atributo mustUnderstand=”1” e o atributo role igual a um dos roles identificados no passo anterior
3. Gera uma falha MustUnderstand se um ou mais blocos identificados no passo anterior não puder ser processado pelo SOAP node, ou seja, não for compreensível
4. Processa o header e se o nó é um ultimate receiver processa o body da mensagem também
5. Se o nó estiver atuando como intermediary node, então remove o bloco XML do header e passa a mensagem adiante

Observe que quando um intermediary node processa a mensagem ele retirar o bloco processado do header da mensagem e passa a mensagem adiante. Portanto, os intermediary nodes tem permissão para alterar o header da mensagem, embora não possam processar o body. Isso pode parecer estranho, mas este é um dos pontos que traz grande flexibilidade ao protocolo SOAP. Um intermediary node além de retirar o bloco processado pode adicionar outros blocos no header e de certa forma interferir no caminho da mensagem. Podemos concluir que o protocolo SOAP é bastante robusto e permite pontos de flexibilidade. Para maiores informações consulte a especificação SOAP 1.2 publicada no site do W3C. Deixe seu comentário e até a próxima pessoal.