SOAP.NET

O Microsoft SOAP Toolkit, que pode ser usado para chamar um WebService, pode também ser utilizado para criar um WebService, embora isto seja um pouco trabalhoso.

por Mauro Sant'Anna

O Microsoft SOAP Toolkit, que pode ser usado para chamar um WebService, pode também ser utilizado para criar um WebService, embora isto seja um pouco trabalhoso. Uma alternativa mais produtiva é o Visual Studio.NET, que contém um suporte específico para a criação de WebServices, tornando a tarefa muito simples. Você pode solicitar o Visual Studio.NET em CD no site da Microsoft. O software ainda está em beta, mas achei-o razoavelmente estável.

O Visual Studio.NET roda sob Windows 98/ME, Windows NT e Windows 2000. O suporte a WebServices, no entanto, exige o Internet Information Server 5.0, disponível apenas no Windows 2000.

Caso você queira desenvolver um WebService no mesmo computador que tenha o servidor Web, você precisa instalar o Visual Studio sobre um Windows 2000 que já possua o Internet Information Server (IIS) previamente instalado. Preste bastante atenção, pois o Windows 2000 Professional não instala o IIS na instalação padrão. O micro deve ter um mínimo de 128 Mb de memória, embora o recomendável seja 256 Mb.

Um exemplo de uso

Para exemplificar o uso do SOAP, usarei o Visual Studio.NET Beta 1 e linguagem C# (lê-se “ce Sharp”), a nova linguagem da Microsoft inspirada no C++. Inicialmente pediremos “File | New | Project” e selecionamos “Visual C# Projects | Web Service”:

Figura 1: Criando um Web Service em C#

Cada WebService tem dois arquivos associados: um com extensão “asmx” e outro um fonte em linguagem de alto nível. No nosso exemplo é “.cs”, escrito em C#.

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”, uma espécie de diretiva de compilação resolvida em tempo de execução. Note o atributo[WebMethod] nos métodos que serão acessados via SOAP. O parêmetro Description é opcional, mas irá ajudar a quem quiser testar o WebService. Veja um fragmento de código a seguir:

Listagem 1:Implementação da Classe Contas

public class Contas : System.Web.Services.WebService { . . . [WebMethod(Description="Soma dois números")] public double Soma(double A, double B) { return A + B; } [WebMethod(Description="Multiplica dois números")] public double Produto(double A, double B) { return A * B; } . . . } 

Podemos testar nosso WebService chamando sua “página” a partir de um navegador com a URL “http://www.meusite.com/MeuServico.asmx”. Esta página permitirá tanto testar os métodos através de “HTTP GET” no navegador (na própria URL), como também visualizar a documentação e o “contrato XML” do serviço, também conhecido como “SDL”. Veja a página de teste:

Figura 2: Testando o Web Service

Você pode entrar números para teste. Neste caso, teremos a chamada de outra página, passando os parâmetros através do método “HTTP GET”, na linha da URL:

Figura 3: Chamando outra página

Você pode também visualizar o “contrato SDL”, no formato XML:

Figura 4:Visualização do contrato SDL

O mais interessante, contudo, é chamar o WebService a partir de outro aplicativo. O Visual Studio.NET tem a capacidade de gerar classes “proxy” automaticamente a partir da informação do SDL. Desta forma, podemos usar esta classe no computador remoto como se estivéssemos no próprio computador que implementa a classe proxy. Esta classe é chamada de “Web Reference”.

Vamos criar um novo projeto, neste caso um “aplicativo Windows”:

Figura 5: Criando um Aplicativo Windows

Devemos depois clicar com o botão direito sobre o “Solution Explorer” e adicionar uma “Web Referece”. Uma caixa de diálogo como a seguinte vai aparecer:

Figura 6: Adicionando uma Web Reference

O lado esquerdo é um navegador Web. Podemos usá-la para navegar em páginas comuns até achar alguma que contenha um “WebService”. A página mostrada, disponível também em qualquer navegador, permite testar o WebService. No lado direito aparecem os WebServices disponíveis. O botão “Add Reference” cria a classe “proxy” que permite chamar o WebService.

A classe “proxy” criada contém métodos correspondentes aos WebMethods. Os nomes dos métodos são os mesmos, os argumentos e tipos de retorno têm os tipos declarados no contrato. Isto garante que a chamada seja feita corretamente. Veja um exemplo de chamada da classe:

Listagem 1: Chamando o WebService

// Cria a classe Proxy localhost.WebService1 C = new localhost.WebService1(); // Chama o método double R = C.Soma(10, 30); // Exibe o resultado label3.Text = R.ToString(); 

Seqüência de acontecimentos

Quando criamos a classe no cliente, nada acontece no servidor. Na chamada ao WebMethod, é gerado um pedido “SOAP” em XML que é enviado ao servidor Web. O servidor Web “desempacota” pedido, cria um objeto da classe associada ao WebService e chama o método. O resultado é empacotado em XML e enviado ao cliente. O objeto criado no servidor é descartado. O cliente “desempacota” o resultado e o devolve para quem chamou o método.

Conclusão

O SOAP é uma maneira simples e eficaz de chamar funções via Web. Ele é robusto, fácil de usar e pode vir a ser a base tecnológica de uma série de serviços disponibilizados via Web.

Ele não é um substituto de padrões de objeto mais sofisticados como COM+ ou CORBA, que devem continuar a ser utilizados em redes locais, mas é imbatível em situações mais simples e via Web.