Web Service

Dioclécio Moreira Camelo

Curso de Especialização de Sistemas de informação e aplicações Web

Manaus, setembro de 2002

Web Services

Objetos distribuidos
Com o advento das redes de computadores, o paradigma das aplicações distribuídas
nasceu. Em sua primeira instância, as aplicações centradas em um servidor sendo
inicializadas pelo cliente através desta interligação. Esta tecnologia disponibilizou
flexibilidade para o desenvolvimento de sistemas centralizados. Esta conhecida como
cliente-servidor pode foi denominada de arquitetura de duas camadas.
Buscando uma escalabilidade maior e uma tolerância maior a falhas foi introduzida
mais uma camada entre os dados e o cliente, denominando-a de camada de
negócios.Esta fica responsável por atender a demanda dos clientes, processá-las e
projetar seus resultados em um banco de dados. Buscando uma melhor distribuição
para estas aplicações, criou-se a necessidade de distribuir o processamento entre o
cliente e o servidor. Partindo deste princípio criou-se os RPCs (Remote Procedure
Call), estes por sua vez solicitam a execução de processos remotos hospedados nos
servidores. Esse primeiro conceito de middleware possibilitou a execução de uma
mesma aplicações em plataformas diferentes, somente disponibilizando uma interface,
ou seja encapsulando todas as regras de negócio do sistema.
Esses middlewares inicialmente implementados sob o paradigma de programação
estruturada foram implantados em diversos sistemas. Com o advento da programação
orientada a objetos surgiram novos middlewares que se enquadravam sob este
paradigma. Os mais conhecidos no mercado são: CORBA, DCOM e RMI.
Cada uma dessas tecnologias possui suas vantagens e desvantagens, porém, através de
algumas limitações e necessidades que serão abordadas em seguida surgiu o
middleware denominado de WebService.

Dioclécio Camelo – CESF/FUCAPI

Web Services

As tecnologias de objetos distribuidos

CORBA
A tecnologia CORBA é uma solução aberta de objetos distribuídos desenvolvida pela
OMG (Object Managemant Group) para se tornar padrão no mercado. A OMG é um
consórcio composto por diversas indústrias no mercado com o interesse de fazer uso
de um padrão de comunicação que viabilise suas aplicações para diversas plataformas
e situações.
A primeira vantagem do CORBA é que a implementação do cliente e do servidor
pode ser feita em quaisquer linguagem. Isso só é possivel por causa de um alto nivel
de abstração conseguido através de um arquivo chamado IDL (Interface Definition
Language). Este arquivo possui o mapeamento dos métodos implementados no
servidor, em uma linguagem específica. A comunicação entre objetos, clientes e
servidores se dá através dos chamados ORBs (Object Request Brokers), estes por sua
vez se responsabilizam pela tradução das solicitções e respostas. O IDL por sua vez
possui a grande limitação de ter que suportar somente os tipos de dados comuns a
todas as aplicações, caso contrário esta precisará ser explicitada em seu código.
Segundo os fabricantes, se o desenvolvedor preferir performance em suas aplicações,
o CORBA é uma das soluções mais recomendadas. Contudo, sua alta complexidade
de implementação não o torna tão atrativo para pequenas soluções.

RMI
Remote Method Invocation, esta tecnologia habilita a comunicação entre aplicações
Java-Java, estas por sua vez se comunicam através da JVM (Java Virtual Machine),
possivelmente em plataformas diferentes. Uma aplicação Java pode chamar esses
objetos remotos somente armazenando suas referências, apontando para a máquina
que o armazena. Através de um processo conhecido como serialização, o objeto
remoto pode estar situado tanto em um servidor como em outro cliente, encapsulando
toda a comunicação entre os objetos. O RMI faz uso de um protocolo desenvolvido
especialmente para este tipo de comunicação, o chamado JRMP (Java Remote
Method Protocol).
Para o desenvolvimento de clientes remotos, o uso de uma IDL não se faz necessário,
tendo em vista que o próprio servidor é usado para difundir os objetos implementados.

Dioclécio Camelo – CESF/FUCAPI

Web Services

Isso faz com que a implementação de aplicações se torne muito mais simples, em
relação ao CORBA. Por outro lado, você somente deve usar aplicações Java em
ambos os lados da comunicação, o que limita bastante o leque de necessidades a ser
alcançado. E mais um detalhe importante, o uso de serviços de comunicação
disponíveis em CORBA não são implementados em RMI, o que limita mais ainda as
vantagens da tecnologia.

DCOM
Distributed Component Object Model (DCOM) é uma tecnologia desenvolvida pela
Microsoft para distribuir objetos pela rede. O DCOM faz uso de uma tecnologia já
utilizada pela Microsoft conhecida como COM (Component Object Model). Um
servidor DCOM publica seus métodos para o cliente através de multiplas interfaces,
escritas em IDL similar ao C++. O compilador IDL cria os stubs e os skeletons similar
ao compilador CORBA, mas seu registro fica implantado no registro do próprio
sistema operacional.
O protocolo utilizado para a comunicação entre objetos, para esta tecnologia, é
denominado ORPC (Object Remote Procedure Call). Esse protocolo faz uso do ping
para permanecer com os objetos ativos, sabendo da atividade do cliente em tempo de
execução. E como o RMI, o DCOM suporta o coletor de objecto distribuídos,
conhecido como garbage collection.
Algumas empresas implementaram o DCOM junto com a Microsoft provendo
portabilidade, como é o caso da Apple, Unix e VMS.

Dioclécio Camelo – CESF/FUCAPI

Web Services

Conclusão das tecnologias

Conforme demonstrado, todos os middlewares trabalham em soluções similares. A
diferença entre as tecnologias está em seus recursos, bem como em sua complexidade.
Como cada tecnologia opera de forma diferente, uma aplicação DCOM não pode se
comunicar com outra em RMI e assim por diante. Em contrapartida é recomendada
para essas tecnologias a limitação em uma intranet, em casos raros o uso de firewalls
para encriptar suas solicitações através da internet, o que reduz a performance e a
consistência da comunicação.

Dioclécio Camelo – CESF/FUCAPI

Web Services

O que é um Web Service

Um webservice (ou serviço Web) é uma aplicação publicada, localizada e chamada
através da internet. Sua função é de encapsular, contratar funções e objetos remotos
oferecidos via um protocolo padrão e conhecido.
Entre uma aplicação distribuída e um webservice não existem muitas diferenças,
contudo a forma como seus dados são manipulados e como as camadas de
comunicação se comportam se dá de uma forma bastante peculiar.
Desde que o a arquitetura de Web Service representa um novo paradigma para
aplicações distribuídas, esta consiste em três componentes básicos, conforme o quadro
abaixo:
» Um service broker que atua na localização entre o provedor do serviço e o
requisitor.
» Um service provider que publica seus serviços para o service broker.
» E um requisitor do serviço que atua solicitando o serviço para um service broker
que encontra um provedor disponível e repassa o perdido para o provedor.

Esse tipo de middleware faz uso da porta HTTP para se comunicar. Como os firewalls
convencionais e proxies não bloqueiam esta porta não existem grandes restrições para
o uso deste tipo de aplicação em redes de longas distâncias.

Dioclécio Camelo – CESF/FUCAPI

Web Services

Comunicação em camadas
A comunicação entre aplicações de webservice fazem uso de 4 camadas que
empacotam a requisição e a resposta entre um servidor e um cliente. As camadas
utilizadas são:
» XML (Extensible Markup Language)
» SOAP (Simple object Access Protocol)
» WSDL (Web Services Definition Language)
» UDDI (Universal Discovery Description Integration)

A figura abaixo demonstra a sobreposição destas camadas.

XML
A base desta comunicação é o XML. Este por sua vez trata-se de uma linguagem
similar ao HTML, uma linguagem em formato texto baseada em delimitadores
(conhecidos como TAGs) que estabelece um denominador comum para comunicação
interaplicações. Através do XML é possivel estabelecer os objetos, métodos,
parâmetros, dados e seus respectivos tipos que serão interpretados pela aplicação
destino.

SOAP
SOAP é um protocolo que estabelece a comunicação em um ambiente heterogêneo de
funções de forma indepente. Sua função na cadeia é basicamente definir mecanismos
que expressem o modelo semântico das aplicações, e o modelo em que os dados são
decodificados.
Por ser bastante simples sua formação consiste na seguinte formatação:

Dioclécio Camelo – CESF/FUCAPI

Web Services

» Cabeçalho
» Corpo
O cabeçalho contem todas as informações necessárias para autenticação da aplicação
e formas de encriptação, se necessário. Já o corpo contém as últimas informações
disponibilizadas pelo requisitor.

WSDL
O WSDL descrve os serviços disponibilizados à rede através de uma semântica XML,
este provê a documentação necessária para se chamar um sistema distribuido e o
procedimento necessário para que esta comunicação se estabeleça. Enquanto o SOAP
especifica a comunicação entre um cliente e um servidor, o WSDL descreve os
serviços oferecidos.
Segundo Gunzer, o WSDL descreve uma função similar ao IDL do CORBA ou a
implementação de uma interface remota em Java RMI. Em sua documentação, esta
camada possui seis elementos importantes, divididos em dois grupos: definição
abstrata e definição concreta, conforme demonstrados abaixo:
» Definição abstrata
types - tipo de dados relevantes que são enviados e recebidos dentro da
mensagem;
message - depois de definido o tipo, definimos os dados que serão
comunicados pelo sistema;
port - este trata de uma série de operações relacionadas à mensagem. Ex.
entrada, saída e tratamento de excessões.
» Definição concreta
bindings - este faz o mapeamento da implementação com a interface descrita
em XML.
services - um serviço está relacionado ao ports. Este indica se o elemento um
nome ou sub-elementos que aparece diversas vezes.

Dioclécio Camelo – CESF/FUCAPI

Web Services

Exemplo de WSDL:
<defiitions>
<import/>
<types>
</types>
<messages>
</messages>
<portType>
</portType>
<binding>
</binding>
<service>
</service>
</definitions>

UDDI
Universal Description, Discovery, and Integration é um padrão desenvolvido para
prover informações em forma de diretório de seus negócios e seus webserviços. Este
representa um service broker que habilita as requisições a serviços para que seja
encontrado um provedor do serviço.
Segundo Gunzer, o UDDI foi desenvolvido como uma lista telefônica, que suporta a
taxonomia para as páginas amarelas, páginas brancas e páginas verdes.

Dioclécio Camelo – CESF/FUCAPI

Web Services

Exemplo prático

Criação de um servidor Web Service em Delphi 6.0

Inicialmente é necessário criar um Web Service pelo File | New, conforme o quadro
abaixo.

É necessário escolher o tipo de webservice, é recomendado escolher o item CGI

Stand-alone executable, conforme o quadro abaixo:

Aparecerão os componentes necessários para que implementação transcorra sem a

necessidade de componentes adicionais.

Dioclécio Camelo – CESF/FUCAPI

Web Services

Recomenda-se salvar todos os arquivos de forma a permitir a implementação das

classes remotas que se deseja disponibilizar para o cliente. No exemplo descrito foram
salvos como: uTeste (unit) e Teste (Project).
Para a classe de teste foi criada uma nova Unit, à partir do menu File | New |
Unit:

Foi criada a interface IClasse e seus métodos. Para a definição de um número GUID,
bastou clicar as teclas Ctrl + Shift + G, servindo como identificação única para o
webservice. Em seguida Interface foi explicitada pela classe TClasse, conforme
código abaixo:

unit uTClasse;
interface
uses
InvokeRegistry;
type
IClasse = interface(IInvokable)
['{0B12F394-F06B-48CA-9681-79CCF7A29994}']
function Resposta: Integer; stdcall;
function Pergunta: String; stdcall;
end;

TClasse = class(TInvokableClass, IClasse)

public
function Resposta: Integer; stdcall;
function Pergunta: String; stdcall;

Dioclécio Camelo – CESF/FUCAPI

Web Services

end;

implementation

{ TClasse }

function TClasse.Pergunta: String;

begin
result := 'Essa é uma pergunta de teste?';
end;

function TClasse.Resposta: Integer;

begin
result := 2002;
end;

initialization
InvRegistry.RegisterInterface(typeInfo(IClasse));
InvRegistry.RegisterInvokableClass(TClasse);
end.
Segundo Swart, é recomendado acrescer as linhas de registro de classes conforme
linhas abaixo, para que a classe possa ser publicada automaticamente ao chamado do
componente de publicação WSDL.

initialization
InvRegistry.RegisterInterface(typeInfo(IClasse));
InvRegistry.RegisterInvokableClass(TClasse);

Após a implementação, foi necessário somente criar o executável e publicá-lo em uma

área permitida a execução em um servidor Web. Em seguida, para expor a interface
SOAP do objeto remoto bastou acessar o seguinte endereço, como exemplo:
http://127.0.0.1/cgi-bin/teste.exe/wsdl/iClasse

É importante ressaltar que se você estiver com o executável hospedado em um

servidor na internet, substitua o IP pelo endereço correto.

A interface explicitada sobre a classe criada apresenta-se em seguida:

Dioclécio Camelo – CESF/FUCAPI

Web Services

<?xml version="1.0"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema" name="IClasseservice"
targetNamespace="http://www.borland.com/soapServices/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<message name="PerguntaRequest"/>
<message name="PerguntaResponse">
<part name="return" type="xs:string"/>
</message>
<message name="RespostaRequest"/>
<message name="RespostaResponse">
<part name="return" type="xs:string"/>
</message>
<portType name="IClasse">
<operation name="Pergunta">
<input message="PerguntaRequest"/>
<output message="PerguntaResponse"/>
</operation>
<operation name="Resposta">
<input message="RespostaRequest"/>
<output message="RespostaResponse"/>
</operation>
</portType>
<binding name="IClassebinding" type="IClasse">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="Pergunta">
<soap:operation soapAction="urn:uTClasse-IClasse#Pergunta"/>
<input>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:uTClasse-IClasse"/>
</input>

Dioclécio Camelo – CESF/FUCAPI

Web Services

<output>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:uTClasse-IClasse"/>
</output>
</operation>
<operation name="Resposta">
<soap:operation soapAction="urn:uTClasse-IClasse#Resposta"/>
<input>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:uTClasse-IClasse"/>
</input>
<output>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:uTClasse-IClasse"/>
</output>
</operation>
</binding>
<service name="IClasseservice"/>
</definitions>

Criação do Cliente em Delphi 6.0

É importante ressaltar neste ponto que à partir do momento em que a interface da
classe está publicada na web é possível instanciá-la por outras linguagens, conforme
descrito anteriormente. Para fins de demonstração, utilizou-se a mesma ferramenta
visando a continuidade no entendimento da aplicação.
Para criar um cliente do WebService descrito anteriormente, basta criar um formulário
qualquer através do menu File | New | Application. Inserir dois botões e um
campo de edição para que o resultado dos métodos fique visível. Conforme
demonstrado abaixo:

Nota-se que no exemplo demonstrado foi acrescido o componente HTTPRIO,

encontrado na barra de componentes WebServices.

Dioclécio Camelo – CESF/FUCAPI

Web Services

Ao selecionar o componente dentro do formulário, é possível editar seus atributos

através do Object Inspector. Desta forma, Swart recomenda que a URL demonstrada
anteriormente seja colocada sob o atributo WSDLLocation. Ao fazer isso, o
componente irá se conectar ao objeto remoto e interpretar sua estrutura. É necessário
escolher em Service a opção IClasseservice e em Port a opção IClassePort, seguindo
esta seqüência para que o componente reconheça a correlação entre essas opções.

Contudo, para que o Delphi reconheça a existência de uma classe remota é necessário
fazer uso de uma ferramenta de importação de webservice, acionado pelo File | New |
Web Service Importer:

Dioclécio Camelo – CESF/FUCAPI

Web Services

Logo, basta definir o mesmo endereço eletrônico para o declarado anteriormente, na

opção de WSDL or XML (...).

Em seguida, será criada uma Unit semelhante ao implementada no servidor, contendo

somente a declaração da estrutura disponível pela interface WSDL.
Unit uTClasseImportada;

interface

uses Types, XSBuiltIns;

type

IClasse = interface(IInvokable)
['{D0038055-68C2-4C33-B82F-ED4E0FEE1A90}']
function Pergunta: WideString; stdcall;
function Resposta: WideString; stdcall;
end;

implementation

Dioclécio Camelo – CESF/FUCAPI

Web Services

uses InvokeRegistry;

initialization
InvRegistry.RegisterInterface(TypeInfo(IClasse), 'urn:uTClasse-
IClasse', '');

end.

Basta utilizar esta Unit no formulário que está sendo implementado e instanciar o
objeto remoto conforme o código abaixo:

unit uForm;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
Forms,
Dialogs, Rio, SoapHTTPClient, StdCtrls;

type
TForm1 = class(TForm)
Edit1: TEdit;
Button1: TButton;
Button2: TButton;
HTTPRIO1: THTTPRIO;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Form1: TForm1;

implementation

uses uTClasseImportada;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);

var
Teste : IClasse;
begin
Teste := HTTPRIO1 as IClasse;
Edit1.Text := teste.Pergunta;
end;

procedure TForm1.Button2Click(Sender: TObject);

var
Teste : IClasse;
begin
Teste := HTTPRIO1 as IClasse;
Edit1.Text := teste.Resposta;

Dioclécio Camelo – CESF/FUCAPI

Web Services

end;

end.

O retorno da função é demonstrado abaixo:

Dioclécio Camelo – CESF/FUCAPI

Web Services

Conclusão
Por se tratar de uma tecnologia relativamente nova, algumas ferramentas RAD ainda
não suportam esse middleware. Em versões mais novas do Java, Delphi e C# já
possuem funcionalidades dentro de seus respectivos enfoques. Porém, com a corrida a
novos horizontes, fabricantes da indústria do software estão se mobilizando para
voltar suas ferramentas de desenvolvimento para os recursos que a web tem a
disponibilizar. A Microsoft estabeleceu uma tecnologia correlata, dentro da visão
deste próprio fabricante conhecida como .NET (Dot NET). A proposta é
disponibilizar ferramentas que auxiliem no desenvolvimento de Web Services e sua
interação com as "diversas" plataformas Windows (Desktop, palm, servidores, etc.).
Para esta tecnologia em ascensão existem:
• Facilidade de implementação em ferramentas RAD, ex. Delphi;
• Facilidade de publicação, pois é necessário ter somente um servidor Web que
suporte a execução de CGIs;
• Facilidade de manutenção, pois à partir de uma interface pré-estabelecida pode
se modificar o funcionamento do componente, mudando inclusive suas regras
de negócio;
• Facilidade de uso através de firewalls e proxies;
• Aumento na escalabilidade das aplicações;
• Independência de linguagem para implementação, como o CORBA. Podendo
ter servidor em C e clientes em Java, Visual Basic, Object Pascal, etc.
Desvantagens:
• Ausência de encriptação na comunicação entre cliente e servidor. Para se ter
encriptação é preciso fazer uso do SSL, disponível em servidores Web;
• Aumento no overhead para abrir as mensagens e empacotá-las;
• Baixa performance, inclusive em intranets.
• Fragilidade de interface, após ter sido usada a interface em um cliente, sua
semântica não pode ser alterada, pois isso implica em mudanças no cliente.

Dioclécio Camelo – CESF/FUCAPI

Web Services

Bibliografia
GUNZER, Hartwig. White Paper: Introduction to Web Services. Borland - Março
2002.
SWART, Bob. Delphi 6 Web Services: SOAP. The Delphi Magazine Issue 72 -
Agosto 2001.
Endereço eletrônico: http://www.thedelphimagazine.com/Samples/1273/1273.htm
WebServices.org
Endereço eletrônico: http://www.webservices.org

Dioclécio Camelo – CESF/FUCAPI