Executando verificação de segurança...
5

#3 | Nota do Dia! | Mensagem SOAP


Olá pessoal! Antes de tudo, eu acho que ainda não me apresentei para vocês.

Para quem não me conhece, eu sou o Eládio Tchiinhemba, vivo em Luanda (Angola) e sou programador.

Nos artigos anteriores, falei sobre, Web Services e SOAP, então não podia deixar de fora o assunto de hoje (Mensagem SOAP).


Falar de SOAP e falar também das tecnologias envolvidas, e a tecnologia que merece o destaque hoje em nosso artigo é a Extensible Markup Language, também conhecida como XML.

XML é uma linguagem de marcação criada pela W3C em meados da década de 1990.

Como já vimos na #1 | Nota do Dia! | Web Services, os Web Services foram criados para que aplicações diferentes possam comunicar. Contudo, a pergunta é:

Como é que duas aplicações diferentes podem conversar (trocar informações)? Sabendo que elas são diferentes tanto em plataforma quanto em linguagem!

A resposta é não podem. Tal coisa só se torna possível se existir algo em comum entre elas.

Por exemplo: A tua Avó fala Kimbundo e o teu filho fala Nihongo(Japonês), sabemos que ambos não poderão conversar se não existir algo que os dois possam entender, esse meio de entendimento poderia ser um tradutor como o Google Tradutor, um dicionário ou mesmo um intérprete.

Com os Web Services é a mesma coisa, para eles conversarem, ou seja, trocar informações, eles precisam de algo em comum. O termo Object na sigla SOAP faz referência ao objecto que é trocado pelos Web Services, e a este objeto nós chamamos de Mensagem SOAP que é nada mais nada menos do que um documento escrito em linguagem XML.

Os Web Services usam uma arquitetura chamada de arquitetura SOAP (além de arquitetura, SOAP também é um protocolo) para troca de mensagens escritas em linguagem XML ou seja para trocar informações entre aplicações.

Por ambas aplicações terem o XML como linguagem em comum, isso facilita a separação de conteúdo.

Utilizando o XML não tem limitação para a criação de tags.

Por ambas aplicações possuírem uma linguagem em comum isso torna a integração entre aplicações muito mais fácil.

Atenção: O XML pode ser usado dentro ou fora do SOAP, com ou sem SOAP, mas o SOAP sempre será usado com XML.

Estrutura SOAP

O SOAP Message possui uma estrutura única que deve ser seguida.

<soap:Envelope>
  <soap:Header>
  </soap:Header>
  <soap:Body>
  </soap:Body>
</soap:Envelop>

O SOAP Envelop é o primeiro elemento do documento e é usado para encapsular toda a mensagem SOAP.

O SOAP Header é o elemento que possui todas as informações de atributos e metadados da requisição.

SOAP Body é o elemento que contém os detalhes da mensagem.

Exemplo de uma Mensagem SOAP

<soap:Envelop xmlns:soap="<http://www.w3.org/2003/5/soap-envelop>">
    <soap:Header>
    </soap:Header>
    <soap:Body>
        <m:MetodoEndereco xmlns:m="<http://www.exemplo.org/endereco>">
            <m:Cidade>Luanda</m:Cidade>
            <m:Rua>Comandante Kanhangulo</m:Rua>
            <m:Distrito>Luanda</m:Distrito>
            <m:Numero>+244937289044</m:Numero>
        </m:MetodoEndereco>
    </soap:Body>
</soap:Envelop>

Bem, por hoje é tudo!

OBS: Por favor, faça questão de deixar o seu ponto de vista nos comentários! Assim nos tornamos mais consistentes. E caso este conteúdo esteja de certa forma passando uma ideia errada, por favor sinta-se a vontade em corrigir. Será muito útil para mim e para a comunidade.

Glossário


  • XML - Extensible Markup Language
  • W3C - World Wide Web Consortium
  • SOAP - Simple Object Access Protocol
Carregando publicação patrocinada...
3

Já trabalhei muito com SOAP na época em que estava no auge do hype. Tudo tinha que ser feito com "web services" (<sarcasm>mais ou menos o que ocorre com "API REST + JSON" hoje em dia</sarcasm>).

E vou te falar que não gostei muito não. Tudo era desnecessariamente complicado, pesado, com trocentas ferramentas/libs proprietárias, muitas incompatíveis entre si. Graças a todos os deuses isso caiu em desuso, e hoje a adoção de API's RESTful - apesar de também não ser perfeito - é algo que eliminou, ou pelo menos minimizou bastante, esse problemas.

Só pra citar alguns exemplos, olha o trabalho que dava apenas para ver o XML sendo gerado. E tem também este artigo, que tem um tom de sátira, mas com muitas verdades escancaradas (como apontar para o fato de que "S significa simples", mas era extremamente complexo).

Dependendo do volume, os XML's gerados podiam ficar tão grandes, ou a quantidade deles podia levar a processamentos tão demorados, que alguns fornecedores chegaram a oferecer hardware especializado em parsing de XML. Sério.

Uma simples autenticação exigia várias linhas de código só pra adicionar um header. Sendo que, por usar HTTP, ele poderia muito bem usar maneiras mais simples.

Acho que a ideia até era boa, mas a implementação não agradou e muita gente foi percebendo que toda aquela complexidade nem sempre se justificava. Além de ter muitas promessas não cumpridas (UDDI, alguém?) :-)

Aliás, essa é uma bronca que tenho da W3C, muitas vezes eles complicam sem necessidade. Tem até esta sátira aqui sobre isso.


Enfim, minha experiência com SOAP não foi boa. Ainda bem que surgiu o REST, que é bem mais simples e tranquilo de implementar. Como já disse, não é perfeito, mas eliminou muitos dos problemas que citei.

1

Eu concordo plenamente. Na verdade, escrevi sobre isso apenas por questões de criação de conteúdo e registro. 😂😂😂

Quem sabe lá para frente alguém procure sobre esse assunto e encontre o conteúdo aqui no Tabnews.