Corbawebserves

342 views
237 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
342
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Corbawebserves

  1. 1. Sumário1 CORBA....................................................................................................................... 2 1.1 Benefícios da Gestão em CORBA...................................................................... 32 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 ................................................................................................................... 133 Implementação .......................................................................................................... 19 1
  2. 2. 1 CORBAO grupo OMG (Object Management Group) especificou a arquitectura de gestão deobjectos OMA (Object Management Architecture) [4], para a concepção edesenvolvimento 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 dosobjectos aplicacionais; as interfaces dos serviços comuns, de orientação horizontal;as interfaces das facilidades comuns, de uso geral e sem impacto na arquitectura dasaplicações; as interfaces dos domínios das aplicações; e nas interfaces docomponente chave, o ORB (Object Request Broker), que garante ainteroperabilidade entre os restantes componentes da OMA.A norma proposta para o ORB é conhecida como a especificação CORBA [4][5][6]. Estadescreve a sua arquitectura, incluindo as características e interfaces [7]. Com um ORB oprotocolo de comunicação é definido na especificação das interfaces dos objectosaplicacionais, isolando os programadores dos detalhes dos protocolos de transporte,tecnologias de rede, máquinas e sistemas operativos (Fig. 1).Fig. 1: A arquitectura CORBAA 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. 3. permitindo apenas a expressão de tipos. Nesta podem ser encontrados tipos básicos oucompostos similares aos das linguagens de programação (long, double, boolean, struct eunion), que servem de base à especificação dos atributos dos objectos e parâmetros dosmétodos. A definição de uma interface é iniciada com a palavra chave interface seguidado seu nome. No corpo da interface estarão contidos os atributos e as operaçõessuportadas 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 dapassagem do valor.Na norma CORBA os mapeamentos das definições OMG IDL em declarações de umalinguagem 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 mecanismospara criação e emissão de pedidos de invocação remota; a outra parte, o esqueletoservidor (skeleton), é referente ao mapeamento no lado servidor que oferece osmecanismos de despacho dos pedidos para a implementação do objecto. Este tipo deinvocação baseado nos stubs e esqueletos é designado de invocação estática. Neste caso ocliente fica “limitado” à utilização de objectos com as interfaces seleccionadas peloprogramador, o que poderá levar a problemas de incompatibilidade. Para evitar-se isto,foram especificadas as interfaces DII (Dynamic Invocation Interface) e DSI (DynamicSkeleton Interface), que podem ser vistas, respectivamente, como um stub e esqueletogenéricos e que permitem que as aplicações possam utilizar dinamicamente o sistema detipos. Um conceito muito importante na CORBA é o conceito de referência de umobjecto CORBA. Uma referência de objecto constitui o identificador do objecto duranteum processamento de um pedido, evitando ambiguidades na identificação e localizaçãode um objecto CORBA, ao nível do ORB. Significa que antes duma qualquer invocação oobjecto cliente deverá obter a referência do objecto servidor.1.1 Benefícios da Gestão em CORBAA grande popularidade que a CORBA atingiu como tecnologia de desenvolvimento deaplicações de objectos distribuídos conduziu que também na área de gestão de redes já 3
  4. 4. existam algumas investigações para que esta seja a eleita para o desenvolvimento desistemas de gestão. As razões deste interesse advém dos inúmeros benefícios destaestraté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 sermais fácil construir e integrar sistemas de gestão ao nível API (Aplication ProgrammingInterface) do que ao nível protocolar, como é o caso do protocolo CMIP ou SNMP quesão explicitamente visíveis os seus detalhes; o Extensibilidade da arquitectura de gestão, ou seja, com pequenas modificações ouadições, a arquitectura de gestão será capaz de lidar e adaptar-se às novas característicasdas tecnologias de rede (ex. novos protocolos, ou novo equipamento activo); o A independência das linguagens de programação, ou seja, diferentes componentesde um sistema de gestão podem ser implementados em diferentes linguagens tirando-separtido das melhores características de cada linguagem e das especificidades dohardware. 4
  5. 5. 2 Web Services e XML(Um Novo Paradigma da Computação Distribuída)2.1 IntroduçãoNo 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 deprocessamento 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 apadronização de protocolos e interfaces, e por isso cada fabricante tinha seus própriosprodutos e soluções que na maioria das vezes não eram compatíveis com os produtos deoutros fabricantes.Com o passar dos anos, a necessidade de padronização foi ficando cada vez mais clara. Adiversidade de soluções dificultava a inter conexão de redes de computadores. Nestecontexto, em meados dos anos 70, começam os trabalhos de padronização da ISO, quepropôs uma arquitectura de conexão dividida em sete camadas.O modelo de computação centralizada foi perdendo força com o surgimento e aproliferação da Internet. Quando a Internet foi aberta para a exploração comercial, o usodas redes de computadores se popularizou rapidamente como um meio de trocarinformações. Hoje em dia, existe um modelo de computação distribuída vigente naInternet, com a arquitectura cliente-servidor desempenhando papel fundamental em umambiente de rede descentralizado, com máquinas autônomas e independentes. Esteambiente descentralizado utiliza o protocolo TCP/IP como principal meio decomunicação entre máquinas de arquiteturas diferentes executando sistemas operacionaise aplicações diferentes.Aplicações distribuídas podem ser implementadas utilizando objectos distribuídos. Estasaplicações muitas vezes são transformadas em serviços, que podem ficar à disposição deum grupo de usuários que utilizam estes serviços de maneira transparente. Com aevolução da computação distribuída surgiram novos padrões para o desenvolvimento deaplicações distribuídas orientadas ao uso em rede, como, por exemplo, CORBA(Commom Object Request Broker Architeture) [CORBA98]. Este padrão proposto pelaOMG (Object Management Group) especifica uma arquitectura para o desenvolvimentode aplicações distribuídas. A Microsoft tem sua proposta de objectos distribuídos que é o 5
  6. 6. DCOM. Porém, todas estas propostas levaram ao desenvolvimento de sistemasfortemente acoplados, onde é necessário um pré-acordo entre as organizações paradeterminar o tipo de dados e a interface dos métodos. Como resultado tem-se agora umcenário onde os sistemas das organizações consistem em uma mistura de soluçõesparticulares, executando sob uma variedade de plataformas. Integrar sistemas existentescom novo software é uma tarefa complicada, além dos rígidos formatos de dados einterfaces não serem facilmente adaptados aos novos requisitos. Desenvolvedores sãodesafiados com software escrito em diferentes linguagens, para diferentes sistemasoperacionais, diferentes redes, e hardwares. Assim, faz-se necessário a criação de padrõespara a especificação de um meio de compartilhar informações em um ambiente deaplicações heterogéneos como a Internet. A linguagem XML foi criada como umaferramenta 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 aintegração entre organizações. TCP/IP e HTTP definem protocolos necessários para umarede publica e mundial. A tecnologia Java permite a criação de aplicações independentesde plataforma. XML complementa Java permitindo a criação de dados independentes deplataforma específica. Porém, as organizações não podem simplesmente abandonar seusinvestimentos em tecnologia e nos seus sistemas actuais. O requerimento de integrarsoftware legado com novas soluções tem levado à criação de novos produtos e padrõesque 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 umpadrão para a troca de dados independente de plataforma. Uma forma de se alcançar estaintegração é através da utilização de Web Services, que permite de integrar sistemas jáexistentes com novos sistemas. 6
  7. 7. 2.2 A Linguagem XMLXML ( EXtensible Markup Language ) ou linguagem extensível de marcação, é umalinguagem designada para descrever e estruturar informações. Como uma linguagem demarcação, XML se assemelha com a linguagem HTML, possuindo marcações paradescrever 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 seudesenvolvimento e especificação tem sido supervisionado pelo XML Working Group.XML é uma especificação pública, ou seja, não é propriedade de nenhuma companhia. Odesenvolvimento de XML começou em 1996 e é um padrão W3C desde Fevereiro de1998.2.2.1 A Sintaxe XMLUm 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 elementoraiz. As próximas linhas definem os elementos derivados do elemento raiz. A listagem aseguir 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 XMLdeve possuir pelo menos um elemento raiz. 7
  8. 8. Elementos possuem correspondência com outros elementos, podendo ter uma relação depai ou filho, formando assim forma uma estrutura de árvore. Um elemento pode ter umconteú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 basede dados. Pode-se utilizar, por exemplo, os nomes dos campos da tabela como nomes deelementos.Elementos XML podem conter atributos. Um atributo armazena informação adicionalsobre elementos, informação que não faz parte dos dados do elemento. XML Namespacessão atributos especiais de elementos que servem para evitar conflitos de nomes deelementos, 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 oselementos filhos com o mesmo prefixo estarão associados ao mesmo namespace. Osendereços utilizados para identificar um namespace não são utilizados pelo parser paraprocessar informações. A principal finalidade destes endereços é fornecer um único nomeao namespace. Comumente , um namespace é utilizado como um ponteiro para umapágina Web que contém informações a seu respeito .2.2.2 XML e Validação de DocumentosUm documento XML “bem formado” é um documento que está em conformidade com asregras 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 doTipo 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 elementospossíveis. Com o uso de uma definição de documento, cada arquivo XML pode carregaruma descrição do seu próprio formato. Deste modo, grupos independentes podemconcordar em usar um DTD comum para a troca de informação. Uma aplicação pode usarum 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. 9. documento XML. É possível declarar um elemento ou um conjunto de elementos comouma expressão regular, permitindo a definição da ocorrência de um determinadoelemento.2.3 As APIs XMLUm módulo de software capaz de ler documentos e fornecer acesso a seu conteúdo eestrutura é chamado de XML parser e a interface de programação, incluindo os nomesdos métodos e atributos é uma API XML. Desenvolvedores são livres para implementarsuas próprias APIs, levando em consideração os padrões aceitos pela indústria. Fazendoisto, um desenvolvedor pode escrever uma API que pode ser executada em diferentesambientes sem maiores modificações.Existem varias interfaces de programação (APIs) desenvolvidas ou em desenvolvimentopara a manipulação de XML, porém, as duas principais especificações que estão setornando padrões industriais são : SAX e DOM.A XML DOM (Document Object Model) é uma API abstrata para documentos XML. Eladefine uma maneira na qual um documento XML pode ser acessado e manipulado. Comouma especificação da W3C (World Wide Web Consortium), ela fornece uma API padrãopara uma variedade de aplicações. DOM foi projetado para ser utilizado com qualquerlinguagem de programação ou sistema operacional. Para arquivos extensos isto pode setornar um problema. Se um grande arquivo está sendo transmitido via rede, pode não serconveniente 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 paraprocessá-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émdisso, SAX é uma interface baseada em eventos.Um parser XML é um processador que lê um documento XML e determina a estrutura epropriedades dos dados. Se o parser vai além das regras de validação para um XML bemformado e valida o documento com um DTD, o parser é dito ser um validador XML. 9
  10. 10. 2.4 XML e XSLXML utiliza marcações que não são pré-definidas, assim não são interpretadas pelobrowser.Ou seja, o browser não sabe como apresentar os elementos XML. Para contornar esteproblema, é necessário um mecanismo que descreva como um documento XML deve serapresentado. Deste modo, foi desenvolvido pelo W3C a tecnologia XSL ( ExtensibleStyleSheet Language) .XSL é uma linguagem que serve basicamente para formatar XML. Esta linguagem podefiltrar 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 paraser formatado em vídeo, papel ou ainda em voz . Esta separação entre apresentação econteúdo torna a linguagem XML mais aperfeiçoada para o desenvolvimento de sistemasbaseados na Web. Assim, XML é uma linguagem que está rapidamente se tornando umpadrão mundial de compartilhamento de informações. Vários fabricantes estãodisponibilizando produtos baseados em XML entre eles Microsoft, HP, IBM, Sun eOracle. XML permite que as informações sejam armazenadas em lugares distintos ao domodelo de apresentação dos dados (XSL). Isto permite que se diferencie os dados eapresentação, o que em HTML não era possível. Outra área onde XML está sendo cadavez mais utilizado é em comércio eletrônico. Neste caso, requisições de compra podemser 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 linguagensque padronizam o tratamento de qualquer tipo de informação, como pó exemplo aapresentação de dados(XSL), a transferência de dados(SOAP), a comunicação entreaplicações(WSDL), a descrição de relacionamento entre dados(Xpointer, Xlink), adescrição de aplicações (AppML) entre outros.Para a implementação de serviços Web, XML fornece um meio de troca de informações arespeito de interfaces, tipos de parâmetros e resultados, devido à sua naturezaindependente de linguagem ou plataforma específica. 10
  11. 11. 2.5 Web ServicesWeb 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 simplesprocessos, como troca de mensagens, até complexas transações industriais, como acompra de mercadorias. Uma vez que um Web Service é publicado, outras aplicações (ououtros Web Services) podem acessá-los e invocá-los, tanto para a obtenção de dadoscomo interação com serviços que uma organização oferece.Diferente de outras tecnologias, Web Services não são acessados através deprotocolosespecíficos de modelação de objectos, como IIOP, RMI ou DCOM. São acessadosatravés de protocolos e formatos de dados independentes de plataforma comoHTTP, XML e SOAP. A interface de um Web Service é acessível através de umamensagem XML padronizada. São descritos utilizando um padrão formal chamadodescrição de serviço, que envolve os detalhes necessários para a interacção com oserviço, incluindo o formato das mensagens, tipos de dados e localização. A interfaceencapsula os detalhes de implementação do serviço, permitindo a sua utilizaçãoindependente de plataforma de hardware ou software na qual está implementado oserviç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) eacoplamento (bind) do serviço. O provedor publica o serviço com a operação publish. Ocliente do serviço utiliza a operação find para obter uma descrição de serviço do provedorde registro e usa esta descrição para, dinamicamente, acessar e interagir (bind) com oprovedor do serviço. A figura 2 ilustra esta arquitetura 11
  12. 12. Fig. 2: Arquitetura e Integração de Web ServicesA interacção entre Web Services pode ser feita estaticamente ou dinamicamente emtempo de execução. Um solicitante de um serviço descreve as características do serviçoprocurado e utiliza o provedor de registro para localizar um serviço apropriado. Uma vezlocalizado o serviço, a informação na descrição do serviço é utilizada para a interacçãoentre 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 deaplicaçõ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ãosendo desenvolvidas há pouco tempo. Estes padrões especificam meios de troca demensagens entre serviços (SOAP), busca de serviços em registros (UDDI) e configuraçãodinâmica de clientes baseadas em descrições de serviços (WSDL). A figura 2 retrata ainteroperabilidade e padrões na qual são desenvolvidos Web Services:Outras padrões ainda não definidosUniversal 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. 13. Nos próximos itens, são abordadas as formas de comunicação que permitem aimplementação de Web Services .2.6 RPCRPC (Remote Procedure Call) é um conjunto de regras para a construção de sistemasdistribuídos. Estas regras especificam meios de codificar e decodificar informaçãotransmitida entre duas aplicações. Efetivamente, RPC fornece um mecanismo paradefiniçã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 deentrada, 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 especificarqual sistema contatar, como codificar os parâmetros, como receber a resposta e comodecodificar a resposta para utilização em um sistema específico .Uma das primeiras especificações para construção de sistemas distribuídos foi feita em1990 pela OSF (Open Software Foundation) com DCE (Distributed ComputingEnvironment). Dois outros produtos de desenvolvimento de aplicações distribuídas quesurgiram em seguida foram CORBA(OMG) e DCOM(Microsoft). Estes produtosespecificam mecanismos que forçam a utilização de um protocolo específico para acomunicação entre as aplicações .3.2 SOAPSOAP (Simple Object AccessProtocol) originou-se da idéia de um mecanismo de RPCbaseado em XML originalmente proposto por Dave Winer em 1998. A idéia evoluiu ehoje 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çõesutilizando-se HTTP. Atualmente, aplicações comunicam-se através de objetosdistribuídos como CORBA e DCOM. HTTP não foi designado para isto. Utilizar RPC na 13
  14. 14. Internet também representa um problema de segurança. Firewalls e proxys normalmenteirão bloquear este tipo de fluxo na rede. Uma melhor forma de comunicação entreaplicações seria a utilização de HTTP, uma vez que este protocolo é suportado por todosos servidores Web, browsers e firewalls.A sintaxe de uma mensagem SOAP é simples. Esta deve ser codificada no padrão XML econté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, comopor exemplo SMTP. A figura 3 contém um exemplo de uma requisição SOAP/HTTPutilizada como RPC : 14
  15. 15. Uma mensagem SOAP/HTTP é geralmente processada por uma aplicação que está emum servidor Web. Quando a aplicação recebe uma requisição, esta primeiro confere aexistê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 eusar o endereço do serviço especificado para executar uma varredura em seu registrolocal ( 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 eretornar a resposta.Uma resposta SOAP é retornada em um documento XML estruturado como em umarequisiçã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 maisbaixo, mensagens SOAP podem ser trocadas pela rede utilizando HTTPS ao invés deHTTP. Como HTTPS utiliza SSL no seu transporte, fica garantida a proteção contrapossíveis intervenções.Além disso, o cliente e servidor podem verificar cada um suas respectivas identidades. 15
  16. 16. Embora HTTPS resolva o problema de proteção das mensagens contra possíveisinvasores, este não ajuda muito quando se necessita da segurança necessária para aautenticação de usuários de Web Services específicos. Estes serviços irão fornecer algumtipo de combinação de usuário/senha durante a fase inicial de registro no serviço e entãoesta será utilizada para acessos futuros. Os serviços UDDI são um tipo de Web Servicesque requerem um registroPOST /soap/servlet/rpcrouter HTTP/1.0Host: localhost:8070Content-Type: text/xmlContent-Length: 461SOAPAction: ""<SOAP-ENV:Envelopexmlns: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 deautenticação para Web Services , mas tal padrão deverá surgir em pouco tempo devidotrabalho de organizações como Microsoft e Verisign.O apoio industrial ao protocolo SOAP está aumentando a cada dia com o lançamento deprodutos que suportam este protocolo pelas maiores organizações. Enquanto cada umdestes produtos possuem suas próprias capacidades, todos são capazes de produzir e 16
  17. 17. processar mensagens SOAP. Isto significa que não importa como a aplicação foiimplementada , ou onde está localizada, ou ainda em qual linguagem foi implementada, oque interessa é que a interoperabilidade entre aplicações está garantida.3.3 WSDLWSDL (Web Services Description Language) é uma linguagem baseada em XMLprojectada 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 abstratapara um conjunto de operações e mensagens, um protocolo de integração para estasoperações e uma localização específica na rede.Sendo baseado em XML, um documento WSDL é dividido em secções constituídas porelementos. O elemento <definition> contém informações a respeito de um ou maisserviç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, odocumento 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. Nodocumento que define a interface serão encontrados os elementos< types>, <message>, <portType> e <binding>. 17
  18. 18. 3.4 UDDIUDDI (Universal Description Discovery and Integration) é uma iniciativa da indústriaque 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 arespeito de uma organização ou entidade. Estes registros são executados em múltiplosservidores (operadores) e podem ser usados por qualquer um que queira tornar disponívelinformações a respeito de negócios ou entidades, ou ainda por qualquer um que queirabuscar estas informações.A informação definida em uma descrição de serviço encontrada em um documentoWSDL é complementar à informação encontrada em um registro UDDI. Este fornecesuporte para vários tipos de descrições de serviços, ou seja, UDDI não possui suportedireto 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 arespeito de translações, descrições de serviço e invocação de aplicações.UDDI é uma especificação em constante desenvolvimento. É coordenada porUDDI.ORG, que é composta por vários membros da indústria, como Microsoft, IBM eAriba. Esta especificação fornece uma API para consulta e publicação de serviços emregistros UDDI. 18
  19. 19. A consulta e publicação em registros UDDI é executada utilizando-se mensagens noformato SOAP . Estas operações são baseadas na especificação de uma API proposta porUDDI.ORG e possui mensagens especificas para a busca, publicação e alteração deregistros.3 ImplementaçãoNesta seção é mostrado um exemplo de implementação que tem como objectivo principalexemplificar as características da utilização de Web Services e XML. Através doexemplo, é exposto o modo como a integração destas tecnologias permite a criação deuma aplicação que através de uma função de alto nível, como o planejamento de umaviagem 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. Estesserviç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 econteú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 comofreeware 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. 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 umainterface 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íse a cidade de destino, a data de ida e a data de retorno. Pode-se opcionalmente escolherque tipos de serviços deseja-se consultar. Após a definição dos parâmetros, o usuáriosubmete o formulário para processamento no servidor. No servidor estão hospedadas asaplicações cliente que executarão as consultas.Existem duas maneiras de se construir um cliente de um Web Service: estaticamente edinamicamente. Quando se tem conhecimento prévio da localização e interface de umserviço, não é necessário realizar uma consulta a um registro UDDI para determinar estasinformações. O cliente que acessa este serviço já possui conhecimento prévio dainterface, localização e tipos dos parâmetros que devem ser utilizados, que são 20
  21. 21. implementados no desenvolvimento da aplicação. Este tipo de cliente seleciona o serviçoestaticamente. 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 einterfaces do serviços com base em uma consulta e dinamicamente seleciona os serviçosque deseja a cessar em tempo de execução. No exemplo são utilizados Web Services acessados dinâmica e estaticamente.Com base nos parâmetros que são enviados para o servidor, é feita uma série de consultasaos serviços disponibilizados na Web. Estes serviços são disponibilizados pororganizações em todo mundo.A primeira consulta é a chamada a um serviço Web que fornece a taxa de conversão demoedas entre dois países. Este serviço aceita dois parâmetros como entrada, que são osnomes dos países e retorna uma resposta que é a taxa de conversão de moedas entre estesdois países.Como já se conhece a localização e a interface do serviço, o cliente já está configuradopara chamar o método, bastando apenas se ter um parâmetro que é o país que se desejaobter a taxa de conversão.Para invocar um serviço Web com um cliente Java , são importados os pacotesnecessários para preparar uma chamada remota SOAP (org.apache.soap.*). Esta chamadaremota é feita através de um objeto Call . Cada parâmetro é representado por um objetoParameter com o nome do argumento, o tipo do argumento, o seu valor e o tipo decodificaçã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. Paraisto são setados a URL, o nome do método e a identificação do método bem como seusargumentos. A resposta é então retornada em um objecto RESPONSE. O trecho decódigo abaixo mostra este procedimento: 21
  22. 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 edisponibilidade de vôos. Esta consulta é feita através de uma chamada SOAP-RPC a umserviço que tem como parâmetros de entrada a data de ida e retorno , bem como as siglasdos aeroportos de destino e retorno. Na tabela 1 podemos ver o texto em formato XMLque é enviado para o provedor do serviço e na tabela 2 tem-se a resposta da requisição: 22

×