Artigo Clube Delphi 70 - DataSnap e SOAP

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (3)  (0)

Artigo da Revista Clube Delphi Edição 70.

Esse artigo faz parte da revista Clube Delphi Edição 70. Clique aqui para ler todos os artigos desta edição

 

Atenção: por essa edição ser muito antiga não há arquivo pdf para download desta revista. os artigos disponíveis somente em doc.

 

DataSnap e Soap

Aplicações distribuídas usando ClientDataSet, XML e Web Services

 

Quando pensamos na criação de aplicações para Internet, a primeira coisa que vem à mente é o desenvolvimento Web. Usando um browser, podemos acessar nossa aplicação a partir de qualquer local do planeta, consultar informações dinâmicas vindas de um banco de dados, fazer compras on-line, efetuar cadastros e muito mais. Usando tecnologias como ASP.NET Web Forms com o Delphi,
podemos criar aplicações Web de forma muito semelhante ao que já estamos acostumados a fazer no Desktop.

Os problemas começam a surgir quando tentamos fazer na Web as mesmas coisas que estamos acostumados a fazer com a VCL Win32. Em várias oportunidades aqui na Revista, e também nas palestras que tenho ministrado sobre desenvolvimento Web, a primeira coisa que gosto de deixar claro é: um browser não é um
formulário Delphi.
 

Considero os protocolos HTTP e HTML arcaicos para serem usados como base na construção de aplicaçôes;esses protocolos nasceram há anos, quando a Internet se limitava a consulta de informações estáticas, como imagens e textos (do tempo onde as primeiras aplicações dinâmicas sugiram como CGI-Writeln). De lá praça, tudo o que se fez, foi meramente criar tecnologias que facilitam o desenvolvimento sobre eles, mas as limitações continuam a existir. Claro, temos alguns facilitadores, mas nada como o velho e bom TForm.

Por exemplo, ao desenvolver para Web, você precisa aprender algumas coisas que até então pareciam esotéricas para quem sempre desenvolveu para Desktop: manter estado, fazer gerenciamento de sessão, processar requisições HTTP, ter uma preocupação triplicada com escalabilidade e por aí vai. Como se já não bastasse, o HTML oferece um conjunto pobre de elementos (tags) para a construção de formulários, se comparamos com a VCL. É muito mais fácil construir
uma interface rica de elementos visuais usando VCL.

Porém, a necessidade de acessar informações On-Line e centralizar o banco de dados em um local que possa ser acossado pela Internet, não nos deixa outra saída: mais cedo ou mais tarde vamos precisar construir aplicações para Web!

O que proponho neste artigo é unificar o melhor dos dois mundos: a facilidade do desenvolvimento Desktop com VCL Win32 com os benefícios que só a Internet oferece. Você aprenderá hoje, neste artigo,a criar aplicações distribuídas para Internet usando VCL ("TForm-based';ao invés de um browser), DataSnap. SOAP e Web Services. E o melhor de tudo, você verá que graças ao Delphi, esse trabalho se torna muito simples, rápido, prático e RAD.

Vantagens ao utilizar DataSnao com SOAP

Antes de começar nosso exemplo, na já tradicional metodologia passo a passo, gostaria de justificar o porquê da abordagem que estou propondo e quais as suas vantagens:

• Ao usar VCL para desenvolver para Internet, você não precisa aprender outro framework. Podemos continuar usando os mesmos controles que já usamos há anos;

• É muito simples migrar uma solução client/server para a abordagem proposta, você vai economizar tempo e código;

• Não sofreremos com as limitações impostas pelo HTTP e HTML: esqueça gerenciamento de estado, sessão, processamento de requisições e afins;

• Diferente do HTML,que a cada requisição trafega formulários completos (resfresh total da página no postback}, mesmo que você tenha solicitado a simples mudança em um controle,em nossa solução tudo o que vai trafegar por HTTP são os dados dinâmicos, em formato XML;

• Aplicações client e usando essa arquitetura são chamadas rich-dient,e\as contém basicamente código de tratamento de interface.O acesso a dados, regras de negócio, SQL, tudo fica no servidor.
Isso garante uma centralização e compartilhamento de acesso.

Usando as tecnologias abordadas neste artigo, você poderá ao final:

• Acessar seu banco de dados a partir de qualquer lugar da Internet;

• Criar aplicações distribuídas para a Internet. Você pode, por exemplo, centralizar o banco de dados e servidor de aplicação na matriz da empresa e distribuir as aplicações clientes para as filiais, que terão acesso a dados em tempo real e que se mantêm sempre atualizados.sem a necessidade de sincronização;

• Poderá ter sua aplicação oferecida como um serviço: seus clientes podem pagar um taxa, por exemplo, e acessar a aplicação através da Internet, sem a necessidade de nenhuma configuração local na empresa, tudo fica configurado e armazenado no servidor.

Arquitetura da solução

Para ter uma visão geral da arquitetura da aplicação que será criada, veja o esquema da Figura 1. Durante todo este tutorial,sempre que tiver uma dúvida de como a solução está sendo implementada e em que camada está sendo empregada determinada tecnologia, consulte essa figura. Ela será nosso "mapa".

Temos três camadas envolvidas na solução:

• C amada de Dados: o banco de dados (SGBD), nesse caso usaremos o Firebird 1.5;

 

 

Figura 1. Arquitetura da solução DataSnap SOAP

 

• Camada de lógica de negócios: responsável pela centralização do acesso a dados, que será compartilhada por todas as aplicações clientes. Inclui componentes dbExpress e eventualmente regras de negócio para processamento remoto. Também conhecido como Servidor de Aplicação;

• Camada de  Apresentação:aplicações executáveis que consistirão basicamente de TForms com componentes VCL e ClientDataSets. Essa camada jamais acessa diretamente o banco de dados.

Toda a "mágica" que veremos neste artigo se concentra na comunicação entre o servidor de aplicação e a camada cliente. Essa comunicação é feita com Web Services usando o protocolo SOAP (Simple Object Access Protocol), através de uma interface padrão chamada lAppServerSoap. Neste artigo, veremos em detalhes cada aspecto envolvido nessa comunicação.

Para construir os exemplos deste artigo, você vai precisar do seguinte:

• Delphi 6, 7, 2005 ou 2006 versão Enterprise (pois usaremos DataSnap). Neste artigo, usarei o Delphi 7;

• Internet Information Services (IIS),já distribuído com oWindows 2000, XP ou 2003. É possível ainda usar o servidor Apache.

Nota: É possível construir toda a solução proposta usando o Linux. O Kylix, a partir da versão 2, oferece suporte para a criação de aplicações distribuídas usando  DataSnap e SOAP, tanto servidor quanto o cliente. Além disso, é possível fazer uma solução híbrida, por exemplo, servidor de aplicação em uma máquina Linux e clientes em Windows (ou vice versa), a XML garante a interoperabilidade. Para ver como isso é realmente possível, consulte nosso portal do assinante em www.clubedelphi.net/portal, lá mostrei como criar uma aplicação desse tipo usando somente o Linux.

Criando o servidor de aplicação

No Delphi 7, dique em File>New>Other>WebServices>SOAP Server Application (Figura 2) para criar uma nova aplicação Web Service. Na tela que aparece escolha o tipo de servidor desejado.Para este exemplo, vamos escolher ISAPI-IIS (Figura 3), mas sinta-se a vontade para usar outro de sua preferência. Uma sugestão é usar o Web App Debugger (WAD),pois esse facilita a depuração durante a fase de desenvolvimento, depois é muito simples converter para outro tipo de servidor.

O Delphi neste momento irá perguntar se você deseja criar uma interface para o SOAP module, para este exemplo responda "não”. Mais tarde, se você quiser, pode criar uma nova interface usando a opção File>New>Other> WebServices> SOAP Server Interface.

Salve todos os arquivos do projeto, dando o nome de "uWM.pas" para a unit1 (que é o WebModule) e"SOAPServerClubeDelphi.dpr' para o projeto. Para uma melhor organização dos arquivos que vão compor esta solução, salve os arquivos do projeto em uma pasta chamada "Server".

WebModule e componentes SOAP

Vamos examinar o WebMobule que foi criado para esta aplicação e os componentes previamente configurados (aproveite para renomear o módulo para "WM"). Observe na Figura 4 que temos alguns componentes envolvidos na criação de aplicações com SOAP. Vamos examinar em detalhes cada um deles.

 HTTPSoapDispatcher - componente responsável por "escutar" solicitações SOAP e encaminhar para um componente que interprete a mensagem (nesse caso o HTTPSoapPascalIInvoker). Por exemplo,quando uma aplicação cliente chamar um método Open de um ClientDataSet, isso será enviado ao servidor de aplicação como uma chamada SOAP ao método GetRecords,que vai ser interceptada
por um HTTPSoapDispatcher,

 

 HTTPSoapPascalInvoker - esse componente recebe a mensagem SOAP e procura uma interface que possa processar a solicitação. Usando o exemplo anterior, é o HTTPSoapPascalInvoker que vai se encarregar de localizar uma implementação no código Delphi para o método GetRecords quando a solicitação for recebida.
Esse componente é referenciado na propriedade Dispatcher do HTTPSoapDispatcher.

 

WSDLHTMLPublish - gera uma página que publica a WSDL (Web Service  Definition Language) para ser visualizada por exemplo em um browser (vamos ver essa página a seguir).

Não se preocupe em entender detalhadamente todas as funcionalidades de cada um desses componentes, pois não precisamos alterar

 

Figura 2. Criando o servidor SOAP


nada em nenhum deles,o Delphi já se encarregou de configurá-los. É importante, por enquanto, apenas conhecer o papel de cada um.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?