Category Archives: SOAP

Como recuperar XML do Envelop SOAP com Axis2

E ai galera beleza?

Hoje descobri que tem uma maneira muito simples de recuperar o xml
que vem dentro do envelope SOAP (tanto de entrada como de saida) no Axis2

segue um exemplo de como fazê-lo:

import org.apache.axis2.*;
import org.apache.axis2.context.*;
public class ExampleStub {
   private InterfaceExampleStub stub = null;
   public ExampleStub(String url) throws Exception {
        try {
            stub = new InterfaceExampleStub(url);
        } catch (AxisFault e) {
            throw new Exception("Error creating a ExampleStub: "+e.getMessage(), e);
        }
    }

    public void operation() throws Exception {
        try {
            stub.operation(/* parameters */);
        } catch(Throwable t) {
            throw new Exception("Got throwable: ["+ t.getMessage(), t);
        } finally {
            try {
                OperationContext operationContext = stub._getServiceClient().getLastOperationContext();
                if (operationContext != null) {
                    MessageContext outMessageContext = operationContext.getMessageContext("Out");
                    if (outMessageContext != null) {
                        System.out.println("OUT SOAP: "+outMessageContext.getEnvelope().toString());
                    }
                    MessageContext inMessageContext = operationContext.getMessageContext("In");
                    if (inMessageContext != null) {
                        System.out.println("IN SOAP: "+ inMessageContext.getEnvelope().toString());
                    }
                }
            } catch(Throwable e) {
                System.out.println("Cannot log soap messages: "+e.getMessage());
            }
        }
    }
}

OBS.: Caso tome o seguinte erro ao tentar executar:

com.ctc.wstx.exc.WstxIOException: Attempted read on closed stream

Siga este tutorial de como resolver este prolema…

Fonte: AppDesign – Ivan K

Axis 2 – com.ctc.wstx.exc.WstxIOException: Attempted read on closed stream

Hoje eu descobri que existe um modo de recuperar o envelope SOAP em String,
utilizando o stub do Axis2, porém estava tomando o seguinte erro:

com.ctc.wstx.exc.WstxIOException: Attempted read on closed stream

então, procurando na internet descobri que é necessário adicionar uma linha no arquivo
stub gerado pelo Axis2, para poder acessar o envelope fora do contexto do stub…

procure pela linha:

org.apache.axiom.soap.SOAPEnvelope _returnEnv = _returnMessageContext.getEnvelope();

e adicione isso embaixo dela:

_returnEnv.build();

simples não?

Caso você esteja procurando como recuperar o Envelope SOAP tanto de saida como de entrada do Axis2
clique aqui!!! 😀

Abraços.

Fonte: apache.org – TAM Tenfold5

Axis 2 – org.apache.axis2.AxisFault: The given SOAPAction … does not match an operation.

E ai pessoal beleza? bom venho aqui para postar a solução de um problema que tive aqui no trabalho, que me custou alguns dias de pesquisa…

Eu estava tentando consumir um webservice de um cliente e estava tomando o seguinte erro:
org.apache.axis2.AxisFault: The given SOAPAction … does not match an operation.

porém pelo soapUI funciona perfeitamente… entao, eu tinha riscado a hipótese de ser algo com o WSDL

tentei gerar o client do axis2 com ADB e com XMLBEANS porém ambos caíram no mesmo erro…
ai finalmente descobri o motivo, o WSDL do cliente realmente tinha algo errado…
os campos soapAction estavam vazios:

<soap:operation soapAction="" style="document" /> 

então  vi que existem 3 maneiras de resolver esse problema… 1ª o cliente arrumar o WSDL dele,
o que vai depender da boa vontade dele… 2ª setar o valor da action em tempo de execução e a 3ª e ultima que é desabilitar essa soap action…

a 2ª opção é fazendo o seguinte:
AlgumaCoisaServiceStub stub = new AlgumaCoisaServiceStub(); //é gerado pelo axis2
stub._getServiceClient().getOptions().setAction(“http://suaaction&#8221;);

eu acho que a action é manipulada diferentemente para cada versão do soap, para especificar a versão utilize:
stub._getServiceClient().getOptions().setSoapVersionURI(org.apache.axiom.soap.SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI);
(ou a versão SOAP12 da constante).

e a 3º opção é fazer o seguinte:
AlgumaCoisaServiceStub stub = new AlgumaCoisaServiceStub(); //é gerado pelo axis2
stub._getServiceClient().getOptions().setProperty(org.apache.axis2.Constants.Configuration.DISABLE_SOAP_ACTION, true);

Bom… espero que esse post tenha ajudado vocês 😀
se resolver, irá poupar algumas boas horas de pesquisa 😀

Fonte: StackOverflow – Michael Sharek / mstewart

Criando um Web Service em Java utilizando Apache Axis2 e Eclipse

Web services são componentes da aplicação que se comunicam utilizando protocolos abertos. Usando Web Services nós podemos disponibilizar nossas funcionalidades da aplicação para qualquer um. Neste tutorial provê instruções passo a passo para desenvolver Web Services utilizando Web Services Axis2 / SOAP / WSDL e a IDE Eclipse. Vamos começar.

1. Configurando o Ambiente de Desenvolvimento

1.1 Primeiro você precisa configurar o ambiente de desenvolvimento. Os passos a seguir são necessários se você deseja criar um Web Service utilizando Axis2 e a IDE Eclipse.

Algumas versões do eclipse alguns problemas de compatibilidade com Axis2. Este tutorial é testado com Apache Axis2 1.5.2, Eclipse Helios e Apache Tomcat 6.

1) Apache Axis2 Distribuição Binary – Download
2) Apache Axis2 Distribuição WAR – Download
3) Apache Tomcat – Download
4) Eclipse IDE – Download
5) Java instalado no seu computador – Download

1.2. Então você precisa setar as variáveis de ambiente para o Java e Tomcat. Segue as variáveis que devem ser adicionadas:

JAVA_HOME : Sete o valor do diretório do jdk (ex.: C:\Program Files\Java\jdk1.6.0_21)
TOMCAT_HOME : Sete o valor do diretório da sua instalação do Tomcat(ex.: D:\programs\apache-tomcat-6.0.29)
PATH : Sete o valor do diretório bin do seu jdk (ex.: C:\Program Files\Java\jdk1.6.0_21\bin)

1.3. Agora você precisa adicionar o ambiente de execução no eclipse. Vá em Windows > Preferences > Server > Runtime Environments.

Selecione o Apache Tomcat v6.0 e na próxima tela, procure o diretório da instalação do Apache e clique em finish.

1.4. Então clique em Web Service > Axis2 Preferences e procure o diretório do Apache Axis2.

2. Criando o Web Service utilizando a abordagem Bottom-Up (de baixo para cima)

2.1 Primeiro crie um novo Dynamic Web Project (File > New > Other…) e selecione Web > Dynamic Web Project.

2.2 Sete o Apache Tomcat como o Target Runtime e clique em Modify para instalar o Axis2 Web Services no Project Facet.

2.3 Selecione o Axis2 Web Services

2.4 Clique em OK e Próximo. Então você pode escolher as pastas e clique em Finalizar quando estiver feito.

3. Criando a Classe Web Service

Agora você pode criar uma classe Java que você queira expor como Web Service. Eu vou criar uma nova classe chamada FirstWebService e criar um método public chamado addTwoNumbers que recebe 2 inteiros como parâmetro e retorna a adição dos mesmos.

3.1 Clique com o botão direito em  MyFirstWebService no Project Explorer e selecione New > Class e dê  um nome adequado ao pacote e a classe. Eu coloquei o nome do pacote de com.sencide e FirstWebService ao nome da classe.

package com.sencide;
public class FirstWebService {
 public int addTwoNumbers(int firstNumber, int secondNumber){
  return firstNumber + secondNumber;
 }
}

3.2 Agora, selecione File > New > Other e escolha Web Service.

3.3 Selecione a classe FirstWebService como service implementation e para ter certeza que a configuração está correga, clique em Server runtime.

3.4 Selecione Web Service runtime como Axis2 (o default é Axis) e clique em Ok.

3.5 Clique em Next e certifique-se que selecionou a opção Generate a default service.xml file.

3.6 Clique em Next e em Start Server e depois que o servidor for startado você pode finalizar, se você não quizer publicar o Web service no teste de repositório UDDI.

Você pode ir ao link http://localhost:8888/MyFirstWebService/services/listServices para visualizar o seu serviço rodando que foi implantado pleo Axis2. Você pode visualizar o WSDL clicando no link FirstWebService.

A Porta utilizada na URL deve ser de acordo com a porta utilizada pelo seu TomCat !!!

Nós precisamos utilizar o Eclipse toda vez que nós quisermos rodar o serviço, se nós não criarmos o arquivo .aar (Axis Archive) e implantar dentro do servidor (Tomcat). Bom, vamos ver como podemos criar isso.

4. Criando o arquivo .aar (Axis Archive) e implantando o serviço

4.1 Vá ao seu workspace do Eclipse, na pasta MyFirstWebService e lá você pode encontrar seu Web service dentro da pasta de serviços. Vá até este diretório pelo prompt de comando e dê o seguinte comando. Ele vai criar o arquivo FirstWebService.aar lá.

jar cvf FirstWebService.aar com META-INF

4.2 Então copie o arquivo axis2.war, você pode encontralo dentro da pasta do Apache Axis2 (Que você fez o download no primeiro passo) para o diretório webapps do Apache Tomcat. Agora pare o  servidor Apache Tomcat que você está rodando na IDE Eclipse.

4.3 Utilizando o prompt de comando, starte o Apache Tomcat (Vá ao diretório bin e rode o arquivo startup.bat). Agora nós vamos ter um diretório chamado axis2 dentro do diretório webapps. Agora se você acessar o http://localhost:8080/axis2/ você poderá ver a página inicial da Aplicação Web do Axis2.

4.4 clique no link Administration e faça o login utilizando o usário: admin e a senha: axis2. Aqui você pode ver o link do serviço upado no topo esquerdo e lá você pode efetuar o upload do arquivo FirstWebService.aar que criamos.  Isto é igual copiar manualmente o arquivo FirstWebService.aar para o diretório webapps\axis2\WEB-INF\services.

4.5 Agora quando você listar os serviços pelo http://localhost:8080/axis2/services/listServices você deverá conseguir ver o nosso novo serviço adicionado.

5. Criando um cliente Web Service

5.1 Selecione File > New > Other… e escolha Web Service > Web Service Client

5.2 Insira o endereço (WSDL) do nosso serviço (http://localhost:8080/axis2/services/FirstWebService?wsdl) no campo Service definition. Então configure servidor como fizemos anteriormente e clique em finish.

5.3 Isso gerará duas novas classes chamadas FirstWebServiceStub.java e FirstWebServiceCallbackHandler.java. Agora nós podemos criar uma lcasse de teste para o cliente utilizar o nosso web service. Crie uma nova classe chamada TestClient.java e cole o seguinte código.

package com.sencide;
import java.rmi.RemoteException;
import com.sencide.FirstWebServiceStub.AddTwoNumbers;
import com.sencide.FirstWebServiceStub.AddTwoNumbersResponse;
public class TestClient {
 public static void main(String[] args) throws RemoteException {
  
  FirstWebServiceStub stub = new FirstWebServiceStub();
  AddTwoNumbers atn = new AddTwoNumbers();
  atn.setFirstNumber(5);
  atn.setSecondNumber(7);
  AddTwoNumbersResponse res = stub.addTwoNumbers(atn);
  System.out.println(res.get_return());
  
 }
}

Agora nós podemos rodar o código acima como java application e vamos ter a saída “12” desde que adicionarmos “7” e “5”.

Faça o download do projeto do Eclipse com o Exemplo acima clicando aqui!!! (Senha : sara)

Fonte: Sencide – Saranga Rathnayaka

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>

_________________________________

Fonte: iMasters – Mauricio Reckziegel