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

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

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á

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.

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

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.

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.

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

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.

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.

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

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

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

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 :

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.

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

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>.

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.

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.

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

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:

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: