Curso de dbExpress e DataSnap - Parte XXV

Curso de dbExpress e DataSnap

Parte XXV – SOAP e WebServices – Aplicações Servidoras

Até agora vimos que a tecnologia COM permite que objetos sejam distribuídos em uma rede local. Porém o COM possui algumas limitações:

·        É um padrão proprietário;

·        Não é multi-plataforma;

·        Apresenta problemas em rede com firewalls;

SOAP

Simple Object Access Protocol – mecanismo que permite a troca de mensagens entre servidores e clientes.

·        Padrão aberto;

·        Roda no topo do protocolo HTTP;

·        Dados trafegam em XML;

·        Multi-plataforma;

Web Services (B2C vs B2B)

Quando você precisa consultar a cotação on-line do dólar, você geralmente abre um browser e acessa um determinado site que forneça a cotação em tempo real. Se você precisa consultar o CEP de uma pessoa, precisa abrir um browser e entrar no site dos correios. Se precisar consultar a disponibilidade de vôos de uma empresa área, precisa entrar em seu site. Ou seja, tudo é feito por um browser (cliente) acessando um serviço (business).

B2C

 Browser                                                                                           HTTP/ HTML                                                      Servidor

Figura. Aplicação Business to Consumer (B2C)

Uma aplicação B2B (Business to Business), ao invés de distribuir dados em formato HTML, distribui dados em formato XML. Isso permite que outras aplicações (que não somente um browser) possam se comunica com esse serviço e retirar dele informações. Essas informações podem ser colocadas em um formulário do Delphi, do Visual Basic, do Kylix, em uma página PHP, em uma planilha do Excel, etc.

Isso é, você desenvolvedor (um lado do negócio) utiliza serviços de outra empresa (o outro lado) para disponibilizar informações para o seu cliente final. Ex.: Uma agência de turismo desenvolve uma HomePage para que os usuários possam agendar viagens pelo mundo inteiro. Porém, a empresa gostaria de oferecer um pacote completo, incluindo diárias de hotel, pesquisa de preços em companhias aéreas, disponibilizada de transporte na cidade, alimentação, etc. Para isso, um atendente teria que entrar no site de cada um das empresas, anotar horários, conferir com horários e disponibilidades de vagas nos hotéis, etc. Se essas empresas disponibilizarem Web Services, a agência de turismo pode automatizar esse processo enviando requisições SOAP para cada Web Service e montando o pacote final, com base nas informações fornecidas pelo cliente.

Uma aplicação Web Service Consumer não precisa necessariamente ser um browser. Uma aplicação desse tipo pode ser escrita em praticamente qualquer linguagem, utilizando interface dedicada ao invés de um browser.

WSDL

Web Services Description Language – a WSDL descreve os métodos de um Web Service. Clientes que queiram utilizar os serviços de um Web Service devem conhecer sua interface, através da WSDL. A WSDL é semelhante a uma Type Library, a diferença é que está em formato XML.

Criando um Web Service

Clique em File|New|Other>WebServices>SOAP Server Application.

Figura. Criando um  WebService

Na caixa que aparece escolha a opção Web App Debugger executable. Em Class Name digite “Soma”.

Figura. Definindo o tipo de servidor

O Delphi perguntará se você quer criar uma interface para o módulo SOAP. Responda Yes.

Figura. Criando uma interface

Preencha as opções como mostra a figura a seguir.

Figura. Opções da interface do serviço

Aperte OK. Clique em File|Save All. Salve a unit1.pas como “uFrmMain.pas”, a unit2.pas como “uWM.pas”, deixe o nome sugerido para SomaIntf.pas e SomaImpl.pas e salve o projeto como “SomaService.dpr”. Selecione o formulário e dê a ele o nome de “FrmMain”. Selecione o WebModule e dê a ele o nome de “WM”.

Figura. WebModule da aplicação

Abra a unit SomaIntf. Declare o método Somar como mostrado a seguir.

unit SomaIntf;

interface

uses InvokeRegistry, Types, XSBuiltIns;

type

  ISoma = interface(IInvokable)

  ['{E73D574F-95D4-4B23-9526-3EBD740EA4F8}']

    function Somar(Num1: Single; Num2: Single): single; stdcall;

  end;

implementation

initialization

  InvRegistry.RegisterInterface(TypeInfo(ISoma));

end.

Como você pode ver, nossa interface ISoma descende da interface IInvokable. Repare também que nessa unit apenas definimos a interface. A implementação é feita em uma unit à parte.

IInvokable - definindo

Assim como IUnknown é a interface base para todas as interfaces COM, IInvokable é a interface base para todas as interfaces que definem Web Services. Veja sua declaração:

{$M+}

IInvokable = interface(IInterface)

end;

{$M-}

Como você pode ver, sua declaração é bastante simples. Na verdade, essa interface apenas herda de IInterface e ativa o recurso de RTTI (diretiva $M). Nesse caso RTTI se faz necessário para que as chamadas de métodos contidas em um pacote SOAP possam ser decodificadas e repassadas ao método apropriado da interface IInvokable. Ou seja, o servidor deve ser capaz de chamar um método e passar parâmetros apenas lendo os dados em string contidos no pacote SOAP.

TInvokableClass - implementando

TInvokableClass é a classe base para todas as classes que implementam interfaces IInvokable. Esta classe é semelhante a classe TInterfacedObject usada em aplicações COM.

Abra a unit SomaImpl e implemente o Web Service dessa forma:

unit SomaImpl;

interface

uses InvokeRegistry, Types, XSBuiltIns, SomaIntf;

type

  TSoma = class(TInvokableClass, ISoma)

  public

    function Somar(Num1: Single; Num2: Single): single; stdcall;

  end;

implementation

{ TSoma }

function TSoma.Somar(Num1, Num2: Single): single;

begin

  result:=Num1+Num2;

end;

initialization

  InvRegistry.RegisterInvokableClass(TSoma);

end.

Execute a aplicação. Na próxima parte, veremos como criar uma aplicação para consumir este WebService.