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

Transcrição

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. 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 corelatas 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ãoseguras. 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 Header Body É o elemento principal do XML que representa a mensagem. É um mecaninsmo genérico de adição de características à mensagem SOAP em maneira descentralizada sem acordo anterior entre as partes comunicantes. 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. <soap:header> <Autentica xmlns="local"> <Usuario>usuario</Usuario> <Senha>senha</Senha> </Autentica> </soap:header> <!-- Os elementos do corpo inseridos aqui!!! --> 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. 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. <!-- Os elementos do corpo inseridos aqui!!! --> 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. 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 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. 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. 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. <Converte xmlns=" <Valor>10</Valor> <De>DEC</De> <Para>BIN</Para> </Converte> Figura 6: Uma requisição SOAP que passa um valor para ser convertido de Decimal para Binário. <ConverteResponse xmlns=" <ValorResult>1010</ValorResult> </ConverteResponse> 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. 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. 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 XML Schema Part 1: Data Types 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. 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 Version Mismatch Must Understand Invalid Request Application Faulted Figura 9: Exceções geradas pelo SOAP. A chamada usou uma versão SOAP que ela não suporta. Um elemento XML foi recebido com o atributo mustunderstand com valor 1, mas não foi entendido pelo receptor. O receptor não conseguiu processar a requisição por que ela está mal-formada ou não é suportada. O recebimento da aplicação falhou quando o processamento foi requisitado. 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. 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. 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:fault> <faultcode>400</faultcode> <faultstring>divide by zero error</faultstring> <detail> <t:dividebyzeroexception xmlns:soap=" <expression>x = 2 / 0;</expression> </t:dividebyzeroexception> </detail> </soap:fault> 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. 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: " <?xml version="1.0" encoding="utf-8"?> <Converte xmlns=" <Valor>10</Valor> <De>DEC</De> <Para>BIN</Para> </Converte> 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/ OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <ConverteResponse xmlns=" <ValorResult>1010</ValorResult> </ConverteResponse> 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 ( 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. Marcus Rommel, Novembro de 2003