SISTEMAS MULTICAMADAS VIA SOAP PARTE 1

Nos dias atuais a utilizao de sistemas multicamadas e tcnicas relacionadas, so basicamente necessrias para as empresas que dependem de solues robustas em sua rea de TI. Ento, nesta primeira parte, iremos apresentar algumas customizaes empregadas no lado do servidor e conceitos importantes sobre Web Services e o protocolo SOAP, bem como a importncia de se realizar uma modularizao (em pacotes) das regras de negcios no servidor de aplicaes (camada intermediria do modelo trs camadas) e uma demonstrao de como customizar servios de determinados clientes sem afetar a estrutura principal do servidor. WEB SERVICES E O PROTOCOLO SOAP Quem j no ouviu falar em Web Services? Os Web Services surgiram, dentre as diversas razes, para solucionar os problemas de integrao e comunicao de informaes entre ambientes heterogneos, devida falta de uma soluo padronizada e robusta (aplicaes e-bussiness). A facilidade da integrao de sistemas com os Web Services traz um ganho importantssimo para o mercado de oportunidades e competitividade. Para comprovar sero apresentados, a seguir, alguns cenrios da utilizao de Web Services que demonstram suas vantagens: Integrao no e-bussines: Uma empresa pode ter o seu mdulo de estoque integrado com o mdulo de pedidos de seu fornecedor, via Web Service, para que automaticamente sejam feitos os pedidos para a reposio dos produtos que esto em uma baixa quantidade. No importando a plataforma ou a linguagem de programao utilizada na implementao dos Web Services. Mercado de oportunidades no e-bussines: O sistema da empresa acessa automaticamente o Web Service quando h a necessidade de reposio de produtos no estoque atravs da integrao no e-bussines. Com isso as empresas podem fazer novas parcerias on-line para aumentar suas oportunidades comerciais. Acesso s Informaes distribudas: Imagine um site cujo objetivo de efetuar pesquisas de preos de softwares em vrias lojas virtuais pela internet, sendo que cada loja virtual possui um Web Service que retorna o preo e outras informaes do software requisitado. Agora, uma aplicao cliente (browser do usurio) acessa o site de pesquisas, informa alguns dados como o software a ser pesquisado e conclui a operao, enviando sua requisio para o servidor do site. A aplicao servidora processa a mensagem e localiza os servios disponveis (Web Services). Os Web Services das lojas virtuais recebem as requisies, processam e retornam as informaes referentes ao software informado. Neste ponto, a aplicao servidora do site de pesquisas, obtm todas as respostas das diversas lojas e as disponibilizam para a aplicao cliente.

O mais importante nos exemplos citados a automao empregada nos processos, onde no necessrio pegar a sada de um programa e informar como entrada para outro. Todo o processo automatizado por interfaces que descrevem seus servios, independentemente da plataforma que foi implementado, sendo reconhecido pelos clientes atravs da WSDL (Web Services Description Language). A WSDL um tipo de documento XML que alm de outras funes, descreve informaes sobre os servios avaliados, nmero e tipos de parmetros, esquema de codificao, etc. atravs destes documentos que a aplicao cliente far o acesso aos servios publicados. O site www.xmethodos.com, por exemplo, fornece uma lista de servios implementados nas mais variadas linguagens e plataformas, disponibilizando os arquivos WSDL correspondentes. A comunicao e integrao dos sistemas em um processo automatizado atravs dos Web Services tornam-se possveis graas ao o protocolo SOAP (Simple Object Access Protocol).

O SOAP define uma notao baseada em XML, para solicitar a execuo de um mtodo exposto por um objeto no servidor e tambm uma notao para definir o formato de uma resposta. Para simplificar... O protocolo SOAP mostra o caminho que deve ser realizado para executar um determinado mtodo no servidor e como as respostas devem ser entregues ao cliente. O SOAP vem incorporado ao protocolo HTTP para o transporte destas informaes, o qual a base da tecnologia dos Web Services. Por utilizar protocolos e tecnologias abertas, os Web Services vem sendo adotados por muitas empresas, trazendo benefcios e vantagens competitivas. Todos os passos realizados desde a requisio de um servio at o retorno para o cliente so codificados e decodificados por componentes com suporte ao SOAP. Esse trabalho, realizado nos bastidores, ser explicado na implementao do servidor e do cliente em nosso exemplo. Para maiores informaes sobre o protocolo SOAP e a WSDL acesse: http: //www.w3.org/TR/soap http: //www.w3.org/TR/wsdl A Figura 1 apresenta a arquitetura trs camadas via SOAP, com acesso aos servios descritos atravs do documento WSDL.

WSDL
Informaes dos Servios Publicao dos Servios

REQUISIO DE SERVIO

SERVIO XXX SERVIO YYY SERVIO ZZZ

SERVIDOR DE APLICAES

APLICAO CLIENTE

SOAP HTTP RESPOSTA

SGDB

Figura 1: As chamadas aos servios so realizadas com base no documento WSDL, codificadas em SOAP e transportadas via HTTP. MODULALIRAZAO DAS REGRAS DE NEGCIO Uma das grandes vantagens dos sistemas multicamadas a separao das regras de negcio e do cdigo de acesso aos dados, atravs de uma camada intermediria, das interfaces com o usurio (camada de apresentao). Para que seja possvel utilizarmos uma tcnica de customizaes de regras de negcios no servidor de aplicaes, utilizaremos outra vantagem que geralmente empregada no lado cliente: a modularizao da aplicao em pacotes, as chamadas packages. Iremos com isso, modularizar em pacotes as regras pertencentes a cada mdulo do sistema. Com isso, teremos em pacotes os mdulos com as regras genricas do sistema e quando determinado cliente precisar ter qualquer customizao em determinada regra, ou mesmo, possuir novas regras, cria-se um pacote especfico deste cliente e aplica-se a herana na classe genrica que implementam os servios padres. No afetaremos a estrutura do sistema! Essa tcnica de customizaes que ser explicada com detalhes na segunda parte do artigo envolver vrios elementos interessantes, como: - O carregamento dinmico de pacotes em tempo de execuo atravs de informaes na base de dados. - Registro de classes especficas que implementam suas interfaces para utilizar a customizao. - Herana e criao de mtodos abstratos.

INTERFACES Pode-se dizer que as interfaces so semelhantes s classes abstratas, pois definem um tipo que compreendem mtodos virtuais abstratos, mas tecnicamente as interfaces no so classes, pois possuem caractersticas e recursos especficos. Elas so necessrias para a implementao e uso de objetos distribudos e foram introduzidas a principio, para dar suporte a tecnologia COM. Embora tenha tido esse propsito, as interfaces no exigem COM. Nas aplicaes baseadas em DataSnap utilizando COM ou Socketes, a Borland definiu uma interface chamada IAppServer, que utiliza a notao safecall para as chamadas de mtodos. Como a conveno SOAP utiliza sdtcall, a Borland decidiu definir uma interface equivalente chamada IAppServerSoap, para comunicao com um SOAP Data Module. Voc no precisar acessar diretamente esta interface, pois os componentes ClientDataSet, DataSetProvider e o SOAP Data Module, a usam internamente. Quando criarmos nossas prprias interfaces que definiro os servios para serem publicados, estas devero ser descendentes da interface IInvokable, que a classe base das interfaces que podero definir servios para serem invocadas pela aplicao cliente, chamadas assim de invokable interfaces. Da mesma forma, ao criarmos as classes que implementaro os servios definidos nas interfaces, estas devero ser descendentes da interface IInvokableClass, que a classe base para a implementao das invokable interfaces. A Figura 2 mostra a hierarquia das interfaces e classes invokables.

IINTERFACE

TOBJECT

IINVOKABLE

definem servios implementam servios

TINVOKABLE CLASS

Interface

Interface

Interface

Classe

Classe

Classe

INVOKABLE INTERFACES

INVOKABLE CLASSES

Figura 2: Hierarquia e relacionamento entre as interfaces e as classes invokables.

IMPLEMENTAO DO SERVIDOR Vamos iniciar um novo projeto de Web Services, usando File | New -> Other -> Web Services -> Soap Server Application (Figura 3). A seguir escolha o tipo de aplicao Web. Eu escolhi o Web App Debbugger Executable (WAD), que um servidor web integrado ao Delphi e que dispensa a instalao de outros servidores, como o IIS e o Apache. importante lembrar que o WAD tem o propsito apenas de realizar a depurao de sua aplicao web, e para distribuir o aplicativo, voc dever converter sua aplicao para uma das suportadas extenses: ISAPI, CGI ou Apache. Para finalizar esta etapa, voc dever digitar um Class Name, que identificar o caminho de sua aplicao no servidor. Informei o nome de ActiveServer.

Figura 3 Criao de um servidor de aplicaes SOAP.

A seguir, responda que voc no deseja criar uma interface para o servidor neste momento. Foi criado um formulrio, que tem o simples propsito de registrar o nosso servidor, mas que em nosso projeto conter procedimentos e funes fundamentais para o carregamento e liberao dos pacotes utilizados e um WebModule, que contm componentes responsveis pela implementao do servidor, descritos a seguir: THTTPSoapDispatcher: Este componente tem o papel de receber as requisies e encaminhar para o objeto especificado em sua propriedade Dispatcher. HTTPSoapPascalInvoker: Recebe as requisies do THTTPSoapDispathcer e transformaas em chamadas de interface Pascal. WSDLHTMLPublish: Utilizado para extrair a definio WSDL dos servios das interfaces registradas.

Vamos salvar a aplicao, usando File|Save All; salve o formulrio como uFmAppServer.pas, o WebModule como uWmSoap.pas e o projeto como SoapServer.dpr. Iremos adicionar um Soap Server Data Module, usando File | New -> Other -> Web Services -> Soap Server Data Module. Salve-o como uDMSoap.pas. As Figuras 4 e 5 apresentam os objetos principais da aplicao servidora. O SoapDataModule um mdulo de dados especial, baseado em servidores de aplicaes SOAP. Ele implementa as invokable interfaces IAppServer e IAppServerSoap, e recebe todas as chamadas enviadas pelo objeto HTTPSoapPascalInvoker. Em aplicaes SOAP, os componentes de acesso aos dados so centralizados no SoapDataModule, mas em nosso caso, no seguiremos este caminho, pois esses componentes estaro em seus mdulos de dados separados em suas devidas packages. Como iremos utilizar os componentes DataSetProviders nos mdulos de dados, teremos que adicionar cdigo extra na criao e destruio de nosso objeto DMSoap, para que os mesmos sejam registrados e exportados para a aplicao cliente quando necessrios.

Isto devido, pois eles no estaro no SoapDataModule como nas aplicaes tradicionais e que faria o registro automaticamente. Lembre-se que estaremos modularizando nossa aplicao servidora para conseguirmos ter a independncia das regras de negcio e as customizaes necessrias. Nota: Em nosso exemplo, veremos como ser realizado o registro dos DataSetProviders localizados nas packages de tempo de execuo.

Figura 4 Data Module SOAP

Figura 5 Web Module SOAP

Figura 6 Formulrio principal da aplicao servidora Iremos agora criar uma interface para o nosso servidor de aplicaes que definir uma funo que verificar se a conexo com o banco de dados foi estabelecida e se os packages foram carregados. Use File | New -> Other -> Web Services -> Soap Interface Server. Agora, voc dever informar um nome para o servio e para as unidades que sero criadas com a definio da interface e da classe correspondente, conforme apresenta a Figura 7.

Figura 7 Criao de um novo Web Service. Aps confirmar a criao do novo servio, clique em File|Save All; salve as unidades como uConexaoIntf.pas e uConexaoImpl.pas. Agora j podemos definir o nosso servio na interface, mas antes vamos analisar as unidades criadas, comeando pela uConexaoImpl.pas:

{ Invokable interface IConexao } unit uConexaoIntf; interface

uses InvokeRegistry, Types, XSBuiltIns; type { Invokable interfaces must derive from IInvokable } IConexao = interface(IInvokable) ['{D2F9D1BA-6A6F-4432-B23F-D883CC83E04A}'] { Methods of Invokable interface must not use the default } { calling convention; stdcall is recommended } end; implementation initialization { Invokable interfaces must be registered } InvRegistry.RegisterInterface(TypeInfo(IConexao)); end.

Nesta unidade foi declarado uma interface chamada IConexao que descendente da Interface IInvokable, portanto uma invokable interface e poder ser utilizada pelos clientes para a requisio de servios. Observe agora o cdigo da seo initialization. Sempre que definirmos interfaces, classes de implementaes ou excees na criao de Web Services, temos que fazer o registro das mesmas, que realizado pelo objeto global InvRegistry, localizado na unit InvokeRegistry. Este objeto contm o mtodo especfico para cada tipo de declarao. Neste caso, o mtodo chamado RegisterInterface, para o registro da interface IConexao. Vejamos agora a unidade uConexaoImpl.pas:

{ Invokable implementation File for TConexao which implements IConexao } unit uConexaoImpl; interface uses InvokeRegistry, Types, XSBuiltIns, ConexaoIntf; type { TConexao } TConexao = class(TInvokableClass, IConexao) public end; implementation initialization { Invokable classes must be registered } InvRegistry.RegisterInvokableClass(TConexao); end.

Observe que a foi declarado uma classe chamada TConexao, que descendente da classe TInvokableClass e que implementa a interface IConexao. Na seo initialization, observe o mtodo utilizado para registrar as invokable class, definido pelo objeto global InvRegistry, chamado RegisterInvokableClass. Agora podemos voltar a unidade que define a interface IConexo e finalmente declarar o nosso primeiro servio, como mostra o cdigo abaixo:

IConexao = interface(IInvokable) ['{BD1A9264-26F5-4490-BEC2-D40CEE77325C}'] function ConexaoAtiva: boolean; stdcall;

Declare este mesmo mtodo na classe TConexo e pressione Ctrl+Shift+C com o cursor dentro da declarao da classe para que o mtodo possa ser implementado. Podemos neste momento executar a aplicao para registrar o nosso servidor na lista de servidores disponveis do Web App Debugger e visualizarmos a publicao do nosso mtodo, pois as implementaes deste e dos outros servios do servidor tero sua continuidade na prxima edio. Clique em Tools | Web App Debugger e inicie o servidor no boto Start. Em seguida, clique na URL ao lado e voc visualizar uma lista com os servidores registrados, como mostra a Figura 8:

Figura 8 Lista de Servidores Registrados Selecione o SoapServer.ActiveServer e pressione Enter. Ser gerada uma pgina com informaes sobre o seu servidor, realizada pelo componente WSDLHTMLPublish. Observe a lista das interfaces registradas, onde encontramos a interface IConexao com a declarao do mtodo ConexaoAtiva, conforme mostra a Figura 9. Voc pode visualizar o documento WSDL, criado pelo componente WSDLHTMLPublish. Lembre-se que atravs deste documento que as aplicaes tero conhecimento dos servios registrados e podero realizar suas requisies.

Figura 9 A Interface IConexao e definio da funo ConexaoAtiva. CONSIDERAES Nesta primeira parte, foram vistos alguns conceitos e caractersticas importantes sobre a utilizao de Web Services e tecnologias relacionadas. Na segunda parte, ser dadas continuidade em nosso servidor de aplicaes, com todas as funcionalidades previstas na introduo do artigo. Todas as tcnicas utilizadas sero detalhadas e mencionaremos situaes importantes que o desenvolvedor poder aplicar em situaes reais. Na aplicao cliente, mostraremos os passos para configurar e utilizar as funcionalidades providas pelo nosso servidor. No final do projeto, teremos um sistema multicamadas via SOAP, modularizado e com suporte a possveis customizaes das regras de negcio. No perca!

Autor: Cristiano Testa de Assumpo Bacharel em Sistemas de Informaes (Universidade da Regio de Joinville Univille) Desenvolvedor Delphi em Sistemas Multicamadas e para Web. Atua na equipe de desenvolvimento de uma soluo ERP da Sys Developer Software Ltda. contatos: cristiano_testai@developer.inf.br cristiano_testai@hotmail.com