SOAP e WebServices

O SOAP é um protocolo elaborado para facilitar a chamada remota de funções via Internet, permitindo que dois programas se comuniquem de uma maneira tecnicamente muito semelhante à invocação de páginas Web.

por Mauro Sant'Anna

O SOAP é um protocolo elaborado para facilitar a chamada remota de funções via Internet, permitindo que dois programas se comuniquem de uma maneira tecnicamente muito semelhante à invocação de páginas Web.

O protocolo SOAP tem diversas vantagens sobre outras maneiras de chamar funções remotamente como DCOM, CORBA ou diretamente no TCP/IP:

É simples de implementar, testar e usar.

• É um padrão da indústria, criado por um consórcio da qual a Microsoft é parte, adotado pela W3C (http://www.w3.org/TR/SOAP/) e por várias outras empresas.
• Usa os mesmos padrões da Web para quase tudo: a comunicação é feita via HTTP com pacotes virtualmente idênticos; os protocolos de autenticação e encriptação são os mesmos; a manutenção de estado é feita da mesma forma; é normalmente implementado pelo próprio servidor Web.
• Atravessa “firewalls” e roteadores, que “pensam” que é uma comunicação HTTP.
• Tanto os dados como as funções são descritas em XML, o que torna o protocolo não apenas fácil de usar como também muito robusto.
• É independente do sistema operacional e CPU.
• Pode ser usado tanto de forma anônima como com autenticação (nome/senha).

Os pedidos SOAP podem ser feitos em três padrões: GET, POST e SOAP. Os padrões GET e POST são idênticos aos pedidos feitos por navegadores Internet. O SOAP é um padrão semelhante ao POST, mas os pedidos são feitos em XML e permitem recursos mais sofisticados como passar estruturas e arrays. Independente de como seja feito o pedido, as respostas são sempre em XML. O XML descreve perfeitamente os dados em tempo de execução e evita problemas causados por inadvertidas mudanças nas funções, já que os objetos chamados têm a possibilidade de sempre validar os argumentos das funções, tornando o protocolo muito robusto.

O SOAP define também um padrão chamado WSDL, que descreve perfeitamente os objetos e métodos disponíveis, através de páginas XML acessíveis através da Web. A idéia é a seguinte: quem publicar um serviço, cria também estas páginas. Quem quiser chamar o serviço, pode usar estas páginas como “documentação” de chamada e também usadas antes de chamar as funções para verificar se alguma coisa mudou.

O SOAP pode ser facilmente implementado em virtualmente qualquer ambiente de programação. Existem atualmente diversos “kits” de desenvolvimento SOAP para vários sistemas operacionais e linguagens de alto nível. A própria Microsoft tem um “kit” para o Visual Studio 6 em http://msdn.microsoft.com/soap/default.asp.

O SOAP é uma parte importante da arquitetura .NET da Microsoft e tem um extenso suporte no Visual Studio.NET. Um WebService é um conjunto de métodos WebMethods logicamente associados e chamados através de SOAP. Os WebMethods são funções chamadas remotamente através de SOAP. Cada WebService tem dois arquivos associados: um com extensão “asmx” e outro com extensão “cs” se você estiver usando a linguagem C#.

Na arquitetura .NET os WebServices são implementados sempre em uma classe derivada de “System.Web.Services.WebService”. Nesta classe adicionamos as funções (métodos) que serão chamados via SOAP. A diferença entre um WebMethod e um método comum é a presença de um “atributo WebMethod”, uma espécie de diretiva de compilação. A página SDL é gerada automaticamente pelas ferramentas de programação.

Do ponto de vista do programador, um WebService é uma página ASP.NET “glorificada”, que mapeia automaticamente pedidos via Web a métodos de uma linguagem de alto-nível.

Criando um Web Service

Veja a seguir uma seqüência de criação de um WebService que faz algumas contas simples. Inicialmente criamos um aplicativo WebService no Visual Studio.NET Beta 2:

Figura 1: Criando novo web service

Este é um projeto ASP.NET comum. Na prática você provavelmente irá também acrescentar páginas ASP.NET comuns.

A seguir escrevemos o código do serviço:

Figura 2: Código no editor

Veja o código digitado:

Listagem 1: Código do serviço

[WebMethod]
public double Sum(double A, double B) {
return A + B;
}
[WebMethod]
public double Multiply(double A, double B) {
return A * B;
}

Note o atributo [WebMethod], que sinaliza ao sistema de runtime que este é um método chamado via HTTP. Nem todos os métodos precisam ser WebMethods.

Todo WebService deve ser identificado de forma única no Universo. A maneira de fazer isto é fornecer uma URI baseada em um domínio Internet registrado por você ou pela sua empresa. Esta URI deve ser fornecida em um atributo antes da declaração da classe:

[WebService(Namespace="http://www.meudominio.com.br/WebServices/")]

Após pedirmos “Build”, podemos imediatamente acessar o serviço através de um navegador Web. Peça “Debug | Start Without Debugging”. As rotinas de suporte a WebServices irão criar automaticamente uma página para testar o WebService:

Figura 3: Página de teste do webservice

Selecione algum método, Sum, por exemplo:

Figura 4: Página de execução do método Sum

Preencha alguns valores e veja a saída do teste:

Figura 5: Resultado do método Sum

Podemos interrogar pegar a descrição do serviço como XML através do padrão “WSDL”. Esta é a maneira que será usada pelo Visual Studio.NET para criar automaticamente uma classe “proxy” que chamará o WebService:

Figura 6: Descrição do serviço como XML

Observe que o VS.NET Beta 1 usava o padrão “SDL” correspondente ao “SOAP Toolkit 1.0”, baseado em uma especificação temporária do protocolo. O Beta 2 utiliza o padrão definitivo e ligeiramente diferente chamado “WSDL”, correspondente ao SOAP Toolkit 2.0.

Consumindo um Web Service

Para consumir um WebService, o Visual Studio.NET pode criar uma classe “proxy” a partir de informação obtida interrogando o SDL. Vamos criar um novo projeto “WinForms” para chamar o WebService:

Figura 7: Criando nova aplicação windows

Adicione dois TextBox, um Button e um ListBox:

Figura 8: Layout do form

Clique com o botão direito sobre o projeto e peça “Add Web Reference...”:

Figura 9: Referenciando o web service

Entre com a URL do WebService, http://localhost/Contas/Service1.asmx, no caso. A janela que aparece à esquerda é um navegador Web que pode ser utilizado normalmente para navegação e localização dos WebServices, listados à direita:

Figura 10: Informando o caminho do web service

Clique “Add Reference”. O Visual Studio.NET criará uma classe “proxy” no projeto. Esta classe tem a mesma sintaxe de uma classe .NET, mas na verdade está invocando um WebService.

Veja o projeto com a “Web Reference”:

Figura 11: Estrutura do projeto após a adição da referência

Se você tiver curiosidade, esta é a classe criada:

Figura 12: Código da classe criada

O código que chama o WebService é o seguinte:

Listagem 2: Código para utilizar o serviço

// Soma
private void button1_Click(object sender, System.EventArgs e) {
double N1 = Convert.ToDouble(textBox1.Text);
double N2 = Convert.ToDouble(textBox2.Text);
localhost.Service1 Contas = new localhost.Service1();
double R = Contas.Sum(N1, N2);
listBox1.Items.Add(R.ToString());
}
// Produto
private void button2_Click(object sender, System.EventArgs e) {
double N1 = Convert.ToDouble(textBox1.Text);
double N2 = Convert.ToDouble(textBox2.Text);
localhost.Service1 Contas = new localhost.Service1();
double R = Contas.Multiply(N1, N2);
listBox1.Items.Add(R.ToString());
}

Veja o programa rodando e chamando o WebService:

Figura 13: Programa em execução

Note que criamos um objeto da classe proxy e chamamos seus métodos para usá-la. O objeto Cotasusado para chamar o WebService funciona de forma muito semelhante a um navegador Internet, mas sem interpretar documentos HTML. Ele pode armazenar cookies, fazer autenticação e encriptação, ter um nome como “user agent” e usar um servidor de proxy.

Na segunda parte, mostrarei o uso de WebServices “de verdade” na Internet e também como criarWebServices mais complexos.