Arquivos de sites
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> |
_________________________________