Este documento discute a computação distribuída e as tecnologias emergentes de Web Services e XML. Ele explica como a linguagem XML permite a troca de dados entre sistemas heterogêneos e como os Web Services podem integrar sistemas existentes de forma flexível. O documento também descreve as APIs DOM e SAX para manipulação de documentos XML.

1. Sumário
1 CORBA....................................................................................................................... 2
1.1 Benefícios da Gestão em CORBA...................................................................... 3
2 Web Services e XML(Um Novo Paradigma da Computação Distribuída)................. 5
2.1 Introdução ........................................................................................................... 5
2.2 A Linguagem XML............................................................................................. 7
2.2.1 A Sintaxe XML........................................................................................... 7
2.2.2 XML e Validação de Documentos............................................................... 8
2.3 As APIs XML ..................................................................................................... 9
2.4 XML e XSL ...................................................................................................... 10
2.5 Web Services .................................................................................................... 11
2.6 RPC ................................................................................................................... 13
3 Implementação .......................................................................................................... 19
1

2. 1 CORBA
O grupo OMG (Object Management Group) especificou a arquitectura de gestão de
objectos OMA (Object Management Architecture) [4], para a concepção e
desenvolvimento de forma normalizada de aplicações orientadas a objectos distribuídos.
As interfaces dos objectos que compõem a OMA classificam-se em: as interfaces dos
objectos aplicacionais; as interfaces dos serviços comuns, de orientação horizontal;
as interfaces das facilidades comuns, de uso geral e sem impacto na arquitectura das
aplicações; as interfaces dos domínios das aplicações; e nas interfaces do
componente chave, o ORB (Object Request Broker), que garante a
interoperabilidade entre os restantes componentes da OMA.
A norma proposta para o ORB é conhecida como a especificação CORBA [4][5][6]. Esta
descreve a sua arquitectura, incluindo as características e interfaces [7]. Com um ORB o
protocolo de comunicação é definido na especificação das interfaces dos objectos
aplicacionais, isolando os programadores dos detalhes dos protocolos de transporte,
tecnologias de rede, máquinas e sistemas operativos (Fig. 1).
Fig. 1: A arquitectura CORBA
A linguagem introduzida na CORBA para a especificação das interfaces é a OMG IDL
(Interface Description Language). Esta é do tipo declarativa e isenta de ambiguidades
2

3. permitindo apenas a expressão de tipos. Nesta podem ser encontrados tipos básicos ou
compostos similares aos das linguagens de programação (long, double, boolean, struct e
union), que servem de base à especificação dos atributos dos objectos e parâmetros dos
métodos. A definição de uma interface é iniciada com a palavra chave interface seguida
do seu nome. No corpo da interface estarão contidos os atributos e as operações
suportadas pelo objecto. Os parâmetros destas são precedidos pelas palavras chave: in
(entrada); out (saída); e inout (ambas as direcções), para indicação da direcção da
passagem do valor.
Na norma CORBA os mapeamentos das definições OMG IDL em declarações de uma
linguagem de programação particular (ex. C++) são parte essencial. Uma parte gerada é
referente ao mapeamento no lado cliente, o stub, que oferece aos clientes os mecanismos
para criação e emissão de pedidos de invocação remota; a outra parte, o esqueleto
servidor (skeleton), é referente ao mapeamento no lado servidor que oferece os
mecanismos de despacho dos pedidos para a implementação do objecto. Este tipo de
invocação baseado nos stubs e esqueletos é designado de invocação estática. Neste caso o
cliente fica “limitado” à utilização de objectos com as interfaces seleccionadas pelo
programador, o que poderá levar a problemas de incompatibilidade. Para evitar-se isto,
foram especificadas as interfaces DII (Dynamic Invocation Interface) e DSI (Dynamic
Skeleton Interface), que podem ser vistas, respectivamente, como um stub e esqueleto
genéricos e que permitem que as aplicações possam utilizar dinamicamente o sistema de
tipos. Um conceito muito importante na CORBA é o conceito de referência de um
objecto CORBA. Uma referência de objecto constitui o identificador do objecto durante
um processamento de um pedido, evitando ambiguidades na identificação e localização
de um objecto CORBA, ao nível do ORB. Significa que antes duma qualquer invocação o
objecto cliente deverá obter a referência do objecto servidor.
1.1 Benefícios da Gestão em CORBA
A grande popularidade que a CORBA atingiu como tecnologia de desenvolvimento de
aplicações de objectos distribuídos conduziu que também na área de gestão de redes já
3

4. existam algumas investigações para que esta seja a eleita para o desenvolvimento de
sistemas de gestão. As razões deste interesse advém dos inúmeros benefícios desta
estratégia resultante, em grande parte, do paradigma de orientação a objectos inerente à
CORBA [8][1][2]. Nomeadamente, a CORBA oferecerá:
o A possibilidade dos modelos de operação e gestão tornarem-se o mesmo;
o Maior facilidade de construção integração de sistemas de gestão pelo facto de ser
mais fácil construir e integrar sistemas de gestão ao nível API (Aplication Programming
Interface) do que ao nível protocolar, como é o caso do protocolo CMIP ou SNMP que
são explicitamente visíveis os seus detalhes;
o Extensibilidade da arquitectura de gestão, ou seja, com pequenas modificações ou
adições, a arquitectura de gestão será capaz de lidar e adaptar-se às novas características
das tecnologias de rede (ex. novos protocolos, ou novo equipamento activo);
o A independência das linguagens de programação, ou seja, diferentes componentes
de um sistema de gestão podem ser implementados em diferentes linguagens tirando-se
partido das melhores características de cada linguagem e das especificidades do
hardware.
4

5. 2 Web Services e XML(Um Novo Paradigma da Computação Distribuída)
2.1 Introdução
No começo dos anos 60, o modelo de computação vigente era um modelo centralizado,
com um grande computador central (mainframe) que possuía um grande poder de
processamento e tinha vários computadores de pouco ou nenhum poder de processamento
(terminais burros) conectados a ele. Nesta época, não havia nenhuma preocupação com a
padronização de protocolos e interfaces, e por isso cada fabricante tinha seus próprios
produtos e soluções que na maioria das vezes não eram compatíveis com os produtos de
outros fabricantes.
Com o passar dos anos, a necessidade de padronização foi ficando cada vez mais clara. A
diversidade de soluções dificultava a inter conexão de redes de computadores. Neste
contexto, em meados dos anos 70, começam os trabalhos de padronização da ISO, que
propôs uma arquitectura de conexão dividida em sete camadas.
O modelo de computação centralizada foi perdendo força com o surgimento e a
proliferação da Internet. Quando a Internet foi aberta para a exploração comercial, o uso
das redes de computadores se popularizou rapidamente como um meio de trocar
informações. Hoje em dia, existe um modelo de computação distribuída vigente na
Internet, com a arquitectura cliente-servidor desempenhando papel fundamental em um
ambiente de rede descentralizado, com máquinas autônomas e independentes. Este
ambiente descentralizado utiliza o protocolo TCP/IP como principal meio de
comunicação entre máquinas de arquiteturas diferentes executando sistemas operacionais
e aplicações diferentes.
Aplicações distribuídas podem ser implementadas utilizando objectos distribuídos. Estas
aplicações muitas vezes são transformadas em serviços, que podem ficar à disposição de
um grupo de usuários que utilizam estes serviços de maneira transparente. Com a
evolução da computação distribuída surgiram novos padrões para o desenvolvimento de
aplicações distribuídas orientadas ao uso em rede, como, por exemplo, CORBA
(Commom Object Request Broker Architeture) [CORBA98]. Este padrão proposto pela
OMG (Object Management Group) especifica uma arquitectura para o desenvolvimento
de aplicações distribuídas. A Microsoft tem sua proposta de objectos distribuídos que é o
5

6. DCOM. Porém, todas estas propostas levaram ao desenvolvimento de sistemas
fortemente acoplados, onde é necessário um pré-acordo entre as organizações para
determinar o tipo de dados e a interface dos métodos. Como resultado tem-se agora um
cenário onde os sistemas das organizações consistem em uma mistura de soluções
particulares, executando sob uma variedade de plataformas. Integrar sistemas existentes
com novo software é uma tarefa complicada, além dos rígidos formatos de dados e
interfaces não serem facilmente adaptados aos novos requisitos. Desenvolvedores são
desafiados com software escrito em diferentes linguagens, para diferentes sistemas
operacionais, diferentes redes, e hardwares. Assim, faz-se necessário a criação de padrões
para a especificação de um meio de compartilhar informações em um ambiente de
aplicações heterogéneos como a Internet. A linguagem XML foi criada como uma
ferramenta para tornar este compartilhamento de informações possível.
Nos últimos, anos a indústria tem visto uma evolução de novos padrões para melhorar a
integração entre organizações. TCP/IP e HTTP definem protocolos necessários para uma
rede publica e mundial. A tecnologia Java permite a criação de aplicações independentes
de plataforma. XML complementa Java permitindo a criação de dados independentes de
plataforma específica. Porém, as organizações não podem simplesmente abandonar seus
investimentos em tecnologia e nos seus sistemas actuais. O requerimento de integrar
software legado com novas soluções tem levado à criação de novos produtos e padrões
que permitem aplicações existentes trabalhar junto de uma forma fracamente acoplada.
Esta integração flexível entre sistemas pode ser alcançada somente com a criação de um
padrão para a troca de dados independente de plataforma. Uma forma de se alcançar esta
integração é através da utilização de Web Services, que permite de integrar sistemas já
existentes com novos sistemas.
6

7. 2.2 A Linguagem XML
XML ( EXtensible Markup Language ) ou linguagem extensível de marcação, é uma
linguagem designada para descrever e estruturar informações. Como uma linguagem de
marcação, XML se assemelha com a linguagem HTML, possuindo marcações para
descrever os dados. Porém, estas marcações não são pré-definidas na linguagem,
tornando possível a criação de marcações de acordo com necessidades específicas.
XML é uma recomendação da W3C (World Wide Web Consortium) e o seu
desenvolvimento e especificação tem sido supervisionado pelo XML Working Group.
XML é uma especificação pública, ou seja, não é propriedade de nenhuma companhia. O
desenvolvimento de XML começou em 1996 e é um padrão W3C desde Fevereiro de
1998.
2.2.1 A Sintaxe XML
Um arquivo XML é um arquivo texto, composto por marcações aninhadas e delimitadas.
A primeira linha descreve a versão do documento. A próxima linha descreve o elemento
raiz. As próximas linhas definem os elementos derivados do elemento raiz. A listagem a
seguir mostra um exemplo de arquivo XML :
<?xml version="1.0"?>
<computador marca= “DELL”>
<preço> 3000,00 </preço>
<hd un=“GB”> 20 </hd>
<memória> 128 </memória>
<monitor marca= “LG”> 15
</monitor>
</computador>
Um elemento XML localiza-se entre de uma marcação de início e uma marcação de fim,
incluindo a própria marcação. Serve para delimitar conteúdo e todo documento XML
deve possuir pelo menos um elemento raiz.
7

8. Elementos possuem correspondência com outros elementos, podendo ter uma relação de
pai ou filho, formando assim forma uma estrutura de árvore. Um elemento pode ter um
conteúdo outro elemento (contém outros elementos) além de conteúdos misturados
(contém texto e outros elementos), conteúdo simples (texto) ou ainda conteúdo vazio
(não contém informação).
Documentos XML geralmente possuem correspondência com uma tabela em uma base
de dados. Pode-se utilizar, por exemplo, os nomes dos campos da tabela como nomes de
elementos.
Elementos XML podem conter atributos. Um atributo armazena informação adicional
sobre elementos, informação que não faz parte dos dados do elemento. XML Namespaces
são atributos especiais de elementos que servem para evitar conflitos de nomes de
elementos, desde que estes nomes não sejam pré-definidos (palavras reservadas).
Quando um namespace é definido na marcação de início de um elemento , todos os
elementos filhos com o mesmo prefixo estarão associados ao mesmo namespace. Os
endereços utilizados para identificar um namespace não são utilizados pelo parser para
processar informações. A principal finalidade destes endereços é fornecer um único nome
ao namespace. Comumente , um namespace é utilizado como um ponteiro para uma
página Web que contém informações a seu respeito .
2.2.2 XML e Validação de Documentos
Um documento XML “bem formado” é um documento que está em conformidade com as
regras sintáticas. Um documento XML “válido” é um documento bem formado e que está
em conformidade com as regras de um DTD ( Document Type Definition ou Definição do
Tipo do Documento). Um DTD define os elementos permitidos em um documento XML
. O propósito de um DTD é definir a estrutura do documento com uma lista de elementos
possíveis. Com o uso de uma definição de documento, cada arquivo XML pode carregar
uma descrição do seu próprio formato. Deste modo, grupos independentes podem
concordar em usar um DTD comum para a troca de informação. Uma aplicação pode usar
um DTD para verificar se os dados que recebeu são válidos.
O ponto principal de um documento DTD é a declaração de elementos e da estrutura do
8

9. documento XML. É possível declarar um elemento ou um conjunto de elementos como
uma expressão regular, permitindo a definição da ocorrência de um determinado
elemento.
2.3 As APIs XML
Um módulo de software capaz de ler documentos e fornecer acesso a seu conteúdo e
estrutura é chamado de XML parser e a interface de programação, incluindo os nomes
dos métodos e atributos é uma API XML. Desenvolvedores são livres para implementar
suas próprias APIs, levando em consideração os padrões aceitos pela indústria. Fazendo
isto, um desenvolvedor pode escrever uma API que pode ser executada em diferentes
ambientes sem maiores modificações.
Existem varias interfaces de programação (APIs) desenvolvidas ou em desenvolvimento
para a manipulação de XML, porém, as duas principais especificações que estão se
tornando padrões industriais são : SAX e DOM.
A XML DOM (Document Object Model) é uma API abstrata para documentos XML. Ela
define uma maneira na qual um documento XML pode ser acessado e manipulado. Como
uma especificação da W3C (World Wide Web Consortium), ela fornece uma API padrão
para uma variedade de aplicações. DOM foi projetado para ser utilizado com qualquer
linguagem de programação ou sistema operacional. Para arquivos extensos isto pode se
tornar um problema. Se um grande arquivo está sendo transmitido via rede, pode não ser
conveniente esperar o término de download do arquivo para começar a manipulá-lo. SAX
( Simple API for XML) não requer que um documento completo esteja na memória para
processá-lo, pois o acesso ao conteúdo do documento é feita de forma seqüencial.
Diferente de DOM, onde o arquivo é percorrido seguindo uma estrutura de árvore. Além
disso, SAX é uma interface baseada em eventos.
Um parser XML é um processador que lê um documento XML e determina a estrutura e
propriedades dos dados. Se o parser vai além das regras de validação para um XML bem
formado e valida o documento com um DTD, o parser é dito ser um validador XML.
9

10. 2.4 XML e XSL
XML utiliza marcações que não são pré-definidas, assim não são interpretadas pelo
browser.
Ou seja, o browser não sabe como apresentar os elementos XML. Para contornar este
problema, é necessário um mecanismo que descreva como um documento XML deve ser
apresentado. Deste modo, foi desenvolvido pelo W3C a tecnologia XSL ( Extensible
StyleSheet Language) .
XSL é uma linguagem que serve basicamente para formatar XML. Esta linguagem pode
filtrar e ordenar elementos XML, endereçar partes específicas de documentos XML,
formatar dados baseados em seu valor e pode direcionar a saída de um documento para
ser formatado em vídeo, papel ou ainda em voz . Esta separação entre apresentação e
conteúdo torna a linguagem XML mais aperfeiçoada para o desenvolvimento de sistemas
baseados na Web. Assim, XML é uma linguagem que está rapidamente se tornando um
padrão mundial de compartilhamento de informações. Vários fabricantes estão
disponibilizando produtos baseados em XML entre eles Microsoft, HP, IBM, Sun e
Oracle. XML permite que as informações sejam armazenadas em lugares distintos ao do
modelo de apresentação dos dados (XSL). Isto permite que se diferencie os dados e
apresentação, o que em HTML não era possível. Outra área onde XML está sendo cada
vez mais utilizado é em comércio eletrônico. Neste caso, requisições de compra podem
ser feitas utilizando-se o formato XML, bem como pesquisas de preço.
Sendo uma meta-linguagem, XML também torna possível a criação de novas linguagens
que padronizam o tratamento de qualquer tipo de informação, como pó exemplo a
apresentação de dados(XSL), a transferência de dados(SOAP), a comunicação entre
aplicações(WSDL), a descrição de relacionamento entre dados(Xpointer, Xlink), a
descrição de aplicações (AppML) entre outros.
Para a implementação de serviços Web, XML fornece um meio de troca de informações a
respeito de interfaces, tipos de parâmetros e resultados, devido à sua natureza
independente de linguagem ou plataforma específica.
10

11. 2.5 Web Services
Web Services são conjuntos de aplicações auto-descritivas que podem ser publicadas,
localizadas e invocadas através da Web. Estas aplicações podem ser desde simples
processos, como troca de mensagens, até complexas transações industriais, como a
compra de mercadorias. Uma vez que um Web Service é publicado, outras aplicações (ou
outros Web Services) podem acessá-los e invocá-los, tanto para a obtenção de dados
como interação com serviços que uma organização oferece.
Diferente de outras tecnologias, Web Services não são acessados através de
protocolos
específicos de modelação de objectos, como IIOP, RMI ou DCOM. São acessados
através de protocolos e formatos de dados independentes de plataforma como
HTTP, XML e SOAP. A interface de um Web Service é acessível através de uma
mensagem XML padronizada. São descritos utilizando um padrão formal chamado
descrição de serviço, que envolve os detalhes necessários para a interacção com o
serviço, incluindo o formato das mensagens, tipos de dados e localização. A interface
encapsula os detalhes de implementação do serviço, permitindo a sua utilização
independente de plataforma de hardware ou software na qual está implementado o
serviço.
Os Web Services possuem uma arquitetura baseada na interação de três categorias:
• provedor do serviço (service provider),
• provedor de registro (registry provider ou registry broker) e
• o cliente do serviço ( service requestor).
Estas categorias envolvem as operações de procura (find) , publicação (publish) e
acoplamento (bind) do serviço. O provedor publica o serviço com a operação publish. O
cliente do serviço utiliza a operação find para obter uma descrição de serviço do provedor
de registro e usa esta descrição para, dinamicamente, acessar e interagir (bind) com o
provedor do serviço. A figura 2 ilustra esta arquitetura
11

12. Fig. 2: Arquitetura e Integração de Web Services
A interacção entre Web Services pode ser feita estaticamente ou dinamicamente em
tempo de execução. Um solicitante de um serviço descreve as características do serviço
procurado e utiliza o provedor de registro para localizar um serviço apropriado. Uma vez
localizado o serviço, a informação na descrição do serviço é utilizada para a interacção
entre cliente e servidor. A descoberta, a invocação dinâmica de serviços (publish, find,
bind) e uma colaboração baseada em mensagens permite o desenvolvimento de
aplicações distribuídas fracamente acopladas com um enorme grau de interoperabilidade.
Web Services é uma tecnologia que se constitui de outras tecnologias e padrões que estão
sendo desenvolvidas há pouco tempo. Estes padrões especificam meios de troca de
mensagens entre serviços (SOAP), busca de serviços em registros (UDDI) e configuração
dinâmica de clientes baseadas em descrições de serviços (WSDL). A figura 2 retrata a
interoperabilidade e padrões na qual são desenvolvidos Web Services:
Outras padrões ainda não definidos
Universal Description Discovery Integration ( UDDI )
Web Services Description Language ( WSDL )
Simple Object Access Protocol ( SOAP )
Extensible Markup Language ( XML )
Protocolos Internet ( TCP/IP , HTTP, SMTP )
Fig. 3: Pilha de protocolos que compõe Web Services
12

13. Nos próximos itens, são abordadas as formas de comunicação que permitem a
implementação de Web Services .
2.6 RPC
RPC (Remote Procedure Call) é um conjunto de regras para a construção de sistemas
distribuídos. Estas regras especificam meios de codificar e decodificar informação
transmitida entre duas aplicações. Efetivamente, RPC fornece um mecanismo para
definição de interfaces que podem ser invocadas através de uma rede .
Uma operação RPC possui uma assinatura( o nome da operação) , seus parâmetros de
entrada, resultados e exceções que podem acontecer. A assinatura de uma operação é
encapsulada em uma estrutura chamada IDL (Interface Definition Language).
Chamar um procedimento que está localizado em um sistema remoto requer especificar
qual sistema contatar, como codificar os parâmetros, como receber a resposta e como
decodificar a resposta para utilização em um sistema específico .
Uma das primeiras especificações para construção de sistemas distribuídos foi feita em
1990 pela OSF (Open Software Foundation) com DCE (Distributed Computing
Environment). Dois outros produtos de desenvolvimento de aplicações distribuídas que
surgiram em seguida foram CORBA(OMG) e DCOM(Microsoft). Estes produtos
especificam mecanismos que forçam a utilização de um protocolo específico para a
comunicação entre as aplicações .
3.2 SOAP
SOAP (Simple Object AccessProtocol) originou-se da idéia de um mecanismo de RPC
baseado em XML originalmente proposto por Dave Winer em 1998. A idéia evoluiu e
hoje SOAP é uma especificação da W3C proposta por organizações como Userland,
Ariba, Microsoft, IBM, Compaq, HP, Lótus, SAP, entre outras.
SOAP é um protocolo baseado em XML que permite a comunicação entre aplicações
utilizando-se HTTP. Atualmente, aplicações comunicam-se através de objetos
distribuídos como CORBA e DCOM. HTTP não foi designado para isto. Utilizar RPC na
13

14. Internet também representa um problema de segurança. Firewalls e proxys normalmente
irão bloquear este tipo de fluxo na rede. Uma melhor forma de comunicação entre
aplicações seria a utilização de HTTP, uma vez que este protocolo é suportado por todos
os servidores Web, browsers e firewalls.
A sintaxe de uma mensagem SOAP é simples. Esta deve ser codificada no padrão XML e
contém as seguintes partes :
o SOAP Envelope : define o conteúdo da mensagem e os vários namespaces que
são usados pelo resto da mensagem, incluindo xmlns:SOAP-ENV(SOAP
Evelope), xmlns:xsi (Xml Schema for Instances) e xmlns:xsd (Xml Schema for
Datatypes)
o SOAP Header (opcional): contém informação a respeito de autenticação,
transação e pagamento.
o SOAP Body : contém informação a respeito de métodos e parâmetros a serem
chamados ou respostas enviadas. Quando SOAP é utilizado como RPC, esta parte
possui um único elemento que contém o nome do método, parâmetros e a
identificação do serviço.
Mensagens SOAP podem ser enviadas utilizando outros protocolos de transporte, como
por exemplo SMTP. A figura 3 contém um exemplo de uma requisição SOAP/HTTP
utilizada como RPC :
14

15. Uma mensagem SOAP/HTTP é geralmente processada por uma aplicação que está em
um servidor Web. Quando a aplicação recebe uma requisição, esta primeiro confere a
existência do campo SOAPAction na requisição. Se possuir tal campo, a requisição é
direcionada para a SOAP Engine, responsável por processar a parte XML da mensagem e
usar o endereço do serviço especificado para executar uma varredura em seu registro
local ( este registro contém informações a respeito dos serviços disponíveis no servidor ).
Então, é utilizado reflexão para localizar e invocar o método especificado no serviço e
retornar a resposta.
Uma resposta SOAP é retornada em um documento XML estruturado como em uma
requisição, exceto quando contém o resultado do método requisitado.
A segurança no envio de mensagens SOAP é um tópico importante. Em um nível mais
baixo, mensagens SOAP podem ser trocadas pela rede utilizando HTTPS ao invés de
HTTP. Como HTTPS utiliza SSL no seu transporte, fica garantida a proteção contra
possíveis intervenções.
Além disso, o cliente e servidor podem verificar cada um suas respectivas identidades.
15

16. Embora HTTPS resolva o problema de proteção das mensagens contra possíveis
invasores, este não ajuda muito quando se necessita da segurança necessária para a
autenticação de usuários de Web Services específicos. Estes serviços irão fornecer algum
tipo de combinação de usuário/senha durante a fase inicial de registro no serviço e então
esta será utilizada para acessos futuros. Os serviços UDDI são um tipo de Web Services
que requerem um registro
POST /soap/servlet/rpcrouter HTTP/1.0
Host: localhost:8070
Content-Type: text/xml
Content-Length: 461
SOAPAction: ""
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:getRate xmlns:ns1="urn:xmethods-exchange" SOAPENV:
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<country1 xsi:type="xsd:string">USA</country1>
<country2 xsi:type="xsd:string">japan</country2>
</ns1:getRate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
inicial antes da utilização de seus serviços de publicação. Não há ainda um padrão de
autenticação para Web Services , mas tal padrão deverá surgir em pouco tempo devido
trabalho de organizações como Microsoft e Verisign.
O apoio industrial ao protocolo SOAP está aumentando a cada dia com o lançamento de
produtos que suportam este protocolo pelas maiores organizações. Enquanto cada um
destes produtos possuem suas próprias capacidades, todos são capazes de produzir e
16

17. processar mensagens SOAP. Isto significa que não importa como a aplicação foi
implementada , ou onde está localizada, ou ainda em qual linguagem foi implementada, o
que interessa é que a interoperabilidade entre aplicações está garantida.
3.3 WSDL
WSDL (Web Services Description Language) é uma linguagem baseada em XML
projectada para descrever Web Services, como o que um serviço pode fazer, onde está
localizado e como invocá-lo. Uma descrição de serviço contém uma definição abstrata
para um conjunto de operações e mensagens, um protocolo de integração para estas
operações e uma localização específica na rede.
Sendo baseado em XML, um documento WSDL é dividido em secções constituídas por
elementos. O elemento <definition> contém informações a respeito de um ou mais
serviços.
Dentro deste elemento, encontram-se outros quatro elementos:
• <message> e <portType> : define quais operações o serviço fornece.
• <type> : este elemento opcional serve para definir tipos de dados estruturados .
• <binding> : designa como as operações são invocadas.
• <service> : explicita onde o serviço está localizado.
Um documento WSDL pode ser dividido em documentos distintos, um que se refere à
implementação de um serviço e outro que se refere à interface do serviço. Neste caso, o
documento de implementação conterá um elemento <service> e um elemento <import>
que apontará para o documento WSDL com a definição da interface do serviço. No
documento que define a interface serão encontrados os elementos
< types>, <message>, <portType> e <binding>.
17

18. 3.4 UDDI
UDDI (Universal Description Discovery and Integration) é uma iniciativa da indústria
que permite às organizações publicar e buscar informações a respeito de Web Services. É
composto por um grupo de registros baseados na Web que fornecem informações a
respeito de uma organização ou entidade. Estes registros são executados em múltiplos
servidores (operadores) e podem ser usados por qualquer um que queira tornar disponível
informações a respeito de negócios ou entidades, ou ainda por qualquer um que queira
buscar estas informações.
A informação definida em uma descrição de serviço encontrada em um documento
WSDL é complementar à informação encontrada em um registro UDDI. Este fornece
suporte para vários tipos de descrições de serviços, ou seja, UDDI não possui suporte
direto para WSDL ou outro mecanismo de descrição de serviços.
Os quatro tipos de dados encontrados em um registro UDDI são :
o businessService : fornece informações sobre uma organização e pode conter um
ou mais businessService.
o businessEntity: fornece informações técnicas e descrições de serviço . Pode conter
um ou mais bindingTemplate.
o bindingTemplate : contém uma referência a um ou mais tModels.
o tModel: utilizado para definições de especificações técnicas de serviço.
A informação fornecida por um registro UDDI pode ser comparada à uma lista telefônica.
As páginas brancas (white pages), fornecem informações tais como nome da organização,
contato e identificadores. As páginas amarelas (yellow pages) são compostas por um
índice de serviços e produtos e as páginas verdes (green pages) contém informações a
respeito de translações, descrições de serviço e invocação de aplicações.
UDDI é uma especificação em constante desenvolvimento. É coordenada por
UDDI.ORG, que é composta por vários membros da indústria, como Microsoft, IBM e
Ariba. Esta especificação fornece uma API para consulta e publicação de serviços em
registros UDDI.
18

19. A consulta e publicação em registros UDDI é executada utilizando-se mensagens no
formato SOAP . Estas operações são baseadas na especificação de uma API proposta por
UDDI.ORG e possui mensagens especificas para a busca, publicação e alteração de
registros.
3 Implementação
Nesta seção é mostrado um exemplo de implementação que tem como objectivo principal
exemplificar as características da utilização de Web Services e XML. Através do
exemplo, é exposto o modo como a integração destas tecnologias permite a criação de
uma aplicação que através de uma função de alto nível, como o planejamento de uma
viagem a um determinado lugar, executa operações de baixo nível com Web Services,
como a consulta de aluguer de carros, reservas em hotéis e passagens de aviões. Estes
serviços podem ser seleccionados em tempo de execução baseados no seu custo,
qualidade, viabilidade e segurança.
Outra característica interessante que deve-se notar é a separação da apresentação e
conteúdo que é possível alcançar com o uso de XML e XSL.
As ferramentas utilizadas para a implementação do exemplo são disponibilizadas como
freeware e são as seguintes:
o Apache Jakarta Tomcat 3.2.1 – servidor Web de código aberto , também
implementa a especificação Java Servlet API 2.2 , ou seja , actua como um servlet
container. [JSP01]
o Apache SOAP 2.0 – implementação do protocolo SOAP para Java , inclui
suporte para a especificação SOAP 1.1 e integra o servidor web.
o Apache Xerces 1.2 – este parser XML de código aberto para Java implementa as
especificações XML mais recentes , bem como DOM e SAX .
o Apache Xalan Java – implementa a especificação XSL 1.0 e também a linguagem
Xpath 1.0 .
o IBM WSTK 2.4 – Web Services ToolKit da IBM, fornece ferramentas úteis no
processo de desenvolvimento e publicação de Web Services.
19

20. o JDK – Java Development Kit , necessário para executar o servidor e as classes
que formam a aplicação.
Para exemplificar o uso de Web Services e XML, tem-se um sistema que fornece uma
interface com o usuário como mostrado na figura 4 :
Fig. 4: Interface do usuário da aplicação.
Esta interface possui um formulário que permite a definição de quatro parâmetros : o país
e a cidade de destino, a data de ida e a data de retorno. Pode-se opcionalmente escolher
que tipos de serviços deseja-se consultar. Após a definição dos parâmetros, o usuário
submete o formulário para processamento no servidor. No servidor estão hospedadas as
aplicações cliente que executarão as consultas.
Existem duas maneiras de se construir um cliente de um Web Service: estaticamente e
dinamicamente. Quando se tem conhecimento prévio da localização e interface de um
serviço, não é necessário realizar uma consulta a um registro UDDI para determinar estas
informações. O cliente que acessa este serviço já possui conhecimento prévio da
interface, localização e tipos dos parâmetros que devem ser utilizados, que são
20

21. implementados no desenvolvimento da aplicação. Este tipo de cliente seleciona o serviço
estaticamente. Porém, nem sempre é possível o conhecimento prévio destas informações.
Deste modo, é necessário uma consulta à um registro UDDI para obter estas informações,
que estão definidas em um documento WSDL. Então o cliente determina a localização e
interfaces do serviços com base em uma consulta e dinamicamente seleciona os serviços
que deseja a cessar em tempo de execução. No exemplo são utilizados Web Services a
cessados dinâmica e estaticamente.
Com base nos parâmetros que são enviados para o servidor, é feita uma série de consultas
aos serviços disponibilizados na Web. Estes serviços são disponibilizados por
organizações em todo mundo.
A primeira consulta é a chamada a um serviço Web que fornece a taxa de conversão de
moedas entre dois países. Este serviço aceita dois parâmetros como entrada, que são os
nomes dos países e retorna uma resposta que é a taxa de conversão de moedas entre estes
dois países.
Como já se conhece a localização e a interface do serviço, o cliente já está configurado
para chamar o método, bastando apenas se ter um parâmetro que é o país que se deseja
obter a taxa de conversão.
Para invocar um serviço Web com um cliente Java , são importados os pacotes
necessários para preparar uma chamada remota SOAP (org.apache.soap.*). Esta chamada
remota é feita através de um objeto Call . Cada parâmetro é representado por um objeto
Parameter com o nome do argumento, o tipo do argumento, o seu valor e o tipo de
codificação do argumento, como demonstrado abaixo :
Vector params = new Vector();
params.addElement( new Parameter( "country1", String.class, “MOZAMBIQUE”, null
) );
params.addElement( new Parameter( "country2", String.class, “AFRICA DO SUL”,
null ) );
Para enviar a chamada do método, é executado o método invoke() do objeto Call. Para
isto são setados a URL, o nome do método e a identificação do método bem como seus
argumentos. A resposta é então retornada em um objecto RESPONSE. O trecho de
código abaixo mostra este procedimento:
21

22. call.setParams( params );
call.setTargetObjectURI("urn:xmethods-CurrencyExchange" );
call.setMethodName( "getRate" );
Response response = call.invoke(new URL( "http://services.xmethods.net/soap" ), ""
);
A seguir é efetuada uma consulta a um serviço para obter preços de passagem de avião e
disponibilidade de vôos. Esta consulta é feita através de uma chamada SOAP-RPC a um
serviço que tem como parâmetros de entrada a data de ida e retorno , bem como as siglas
dos aeroportos de destino e retorno. Na tabela 1 podemos ver o texto em formato XML
que é enviado para o provedor do serviço e na tabela 2 tem-se a resposta da requisição:
22