iMasters | Por uma internet mais criativa e dinâmica

Terça-feira, 18/07/2006 - 12:58 - Por Mauricio Reckziegel
Seções relacionadas:

• WebServices

• Imprimir
• Indicar
• Digg it
• Del.icio.us
• Twitter
• 1 comentários

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>

Bibliografia

[AMORIM] AMORIM, Simone da Silva. A Tecnologia Web Services e sua Aplicação num Sistema de Gerencia de Telecomunicações. 2004. http://libdigi.unicamp.br/document/?code=vtls000332721

[BRODGEN2002] BROGDEN, Bill; MINNICK, Chris. Guia doDesenvolvedor JAVA. Desenvolvendo E-Commerce com JAVA, XML e JSP. Pearson Education do Brasil. 2002

[HENDRICKS2002] HENDRICKS, M.; GALBRAITH, B., et al., Profissional Java Web Services. Rio de Janeiro: Alta Books, 2002.

[ROMMEL] ROMMEL, Marcus. Simple Object Access Protocol - Entendendo o Simple Object Access Protocol (SOAP) http://www.msdnbrasil.com.br/secure/sharepedia/arquivos/SOAP.pdf

[W3S] W3Schools, SOAP Tutorial. http://www.w3schools.com/soap/default.asp

Todos os artigos de Mauricio Reckziegel

19/12/2006 - O estado da Segurança Web 06/10/2006 - Criptografia em PHP e WebServices 04/09/2006 - Web Services e PHP: Google em qualquer site, com a sua cara. 15/08/2006 - Construindo Web Services em PHP 02/08/2006 - Descrevendo, descobrindo e integrando Web Services - UDDI 25/07/2006 - Descrevendo um Web Service - WSDL 18/07/2006 - Protocolo de Transporte Padrão - SOAP 29/06/2006 - Regras úteis do XML 23/06/2006 - Entendendo os WebServices

1 comentários publicados

• 1. Parabéns

  Segunda-feira, 04/12/2006, por Marcelo .

  O autor esta de parabéns pelo texto. Ótima qualidade das informações.

  Responder comentário

Poste um comentário

(clique se não for cadastrado)

Login: Senha: Titulo: digite aqui seu comentário Site/blog: Enviar Receber notificação de novos comentários

Sobre o autor

Mauricio Reckziegel é programador há 4 anos e desenvolve sistemas para web especificamente, trabalhando mais com a linguagem PHP. Estudante de Sistemas de Informações na Universidade Regional do Noroeste do Estado do Rio Grande do Sul, Unijui - Campus Santa Rosa e, no momento, desenvolve a monografia em cima da arquitetura WebServices.

Indique para um amigo

Escreva aqui sua mensagem! ok

Tags relacionadas

photoshop internet lançamento celular 3g microsoft mercado design apple linux seguranca desenvolvimento criação ti tecnologia yahoo crescimento tendência google brasil mobile web php gerência empresa iphone

TI SHOP Produtos iMasters

• Lançamento: CD-ROM Treinamento Aplicado de SQL - Lançamento! Treinamento Aplicado de SQL - Aprenda a trabalhar com SQL com bancos de dados Oracle e SQL Server. São mais de 100 tópicos explicados por Mauro Pichilliani, um articulistas mais lidos do iMasters. Aproveite! Apenas R$ 69,90 no TI SHOP.
• Lançamento: Livro iMasters "O Encontro de 2 Mundos"- Este livro conta com 56 crônicas de profissionais mais admirados e influentes do mercado brasileiro de Internet. Aproveite o preço especial para leitores do iMasters. Apenas R$ 40,00 e envio imediato!
• DVD Curso Completo de Photoshop - Do conceito à finalização Lançamento! Curso Completo de Photoshop, em DVD, com mais de 230 aulas dividas em 4 módulos: conceito, básico, avançado e finalização. Apenas R$ 69,50 no TI SHOP - Frete com 50% de desconto
• DVD Javascript Starter - Curso Completo Com mais de 9 horas de vídeo-aulas, é um curso completo sobre Javascript. Ideal para quem deseja aprender a linguagem. Apenas R$ 64,90 no TI SHOP - Frete com 50% de desconto!