Sistema UDDI para serviços WEB

(1)

Luís Fernando Jordan

Desenvolvendo um Protótipo do UDDI

(2)

UNIVERSIDADE FEDERAL DE SANTA CATARINA

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

CURSO DE CIÊNCIAS DA COMPUTAÇÃO

Luís Fernando Jordan

Desenvolvendo um protótipo do UDDI

Trabalho de Conclusão de Curso apresentado ao Curso de Ciências Da Computação da Universidade Federal de Santa Catarina como

requisito para a obtenção do grau de Bacharel em Ciência da Computação. Orientador: João Bosco Mangueira Sobral.

Banca: João Bosco M. Sobral, Dr

Rosvelter João Coelho da Costa, Dr Rodrigo Campiolo, Bel

Palavras-Chave: XML, SOAP, WSDL, UDDI, SAAJ, XML:DB, XPATH E XUPDATE.

(3)

AGRADECIMENTOS

Agradeço a minha família pelo suporte fornecido, minha namorada pela paciência e compreensão, e aos meus amigos que me acompanharam no Surf quando eu precisava esfriar a cabeça.

(4)

SUMÁRIO

RESUMO ... 05

ABSTRACT ... 06

1 INTRODUÇÃO ... 07

1.1 APRESENTAÇÃO ... 07

1.2 A JUSTIFICATIVA DA ESCOLHA DO PROBLEMA ... 07

1.3 FORMULAÇÃO DO PROBLEMA E DELIMITAÇÃO DO MESMO ... 08

1.4 IMPORTÂNCIA DO TEMA PESQUISADO ... 09

1.5 TRABALHOS RELACIONADOS ... 09 1.6 OBJETIVOS ... 09 1.7 ESTRUTURA DO TRABALHO ... 10 2 FUNDAMENTAÇÃO TEÓRICA ... 11 2.1 SOAP E EXEMPLOS ...12 2.2 WSDL E EXEMPLOS ...15 3 O UDDI ... 17 3.1 NÍVEIS DO UDDI ...19 3.2 O MODELO DE INFORMAÇÃO ...19 3.2.1 O ELEMENTO BUSINESSENTITY ... 21 3.2.2 O ELEMENTO BUSINESSSERVICE ... 22 3.2.3 O ELEMENTO BINDINGTEMPLATE ... 23 3.2.4 O ELEMENTO TMODEL ... 25 3.2.5 O ELEMENTO PUBLISHASSERTION ... 26 3.3 IDENTIFICADORES E CATEGORIAS ... 26 3.4 INTERNACIONALIZAÇÃO ... 29

3.5 UDDI NODES E REGISTRIES ... 30

4 AS APIS DO UDDI ... 31

4.1 UDDI INQUIRY API ... 32

4.2 UDDI PUBLICATION API ... 34

(5)

4.4 UDDI CUSTODY TRANFER API ... 36

4.5 UDDI SUBSCRIPTION API ... 36

4.6 UDDI REPLICATION API ... 36

4.7 UDDI SUBSCRIPTION LISTENER API ... 36

4.8 UDDI VALUE SET API ... 37

5 DESCRIÇÃO DO PROTÓTIPO ... 38 5.1 SAAJ ... 41 5.2 XINDICE ... 43 5.3 XML:DB ... 44 5.4 XPATH ... 45 5.5 XUPDATE ... 47 5.6 A IMPLEMENTAÇÃO ... 48 6 CONCLUSÕES ... 50 7 BIBLIOGRAFIA ... 52 8 ANEXOS ... 54

(6)

Resumo

Este trabalho tem como objetivo o aprofundamento nas tecnologias envolvidas na criação de Web Services, dando ênfase no UDDI. O “Universal Description, Discovery and Integration” é uma especificação que define a criação de um registro central, que compõe a Arquitetura Orientada a Serviços criada pelos Web Services, juntamente com fornecedores e consumidores de serviços. A principal motivação desta especificação é solucionar o problema de publicação e busca de serviços, eliminando o espaço existente entre fornecedores e consumidores. Algumas das tecnologias abordadas neste trabalho são o XML, SOAP, WSDL, SAAJ, XML:DB, XPath e XUpdate. Todas elas são utilizadas para criar um protótipo da especificação, que implemente as funções básicas de um registro UDDI. A criação do protótipo visa adquirir mais conhecimento sobre esta arquitetura que promete integrar com eficiência sistemas heterogêneos.

(7)

Abstract

This work is intented to study deeper the technologies behind Web Services, focusing on UDDI. The “Universal Description, Discovery and Integration” is an especification that define the creation of a central registry, that combined with producers and consumers, result on the Service Oriented Architecture of Web Services. The primary motivation of this especification is to remove the gap between producers and consumers, solving the problem of publishing and finding services. Some technologies discussed on this work are XML, SOAP, WSDL, SAAJ, XML:DB, XPath e XUpdate. All these are used to build a prototype, implementing the basic functions of an UDDI registry. This creation intends to make a profound study of this architecture, which principal goal is to integrate diferent types of systems.

(8)

CAPÍTULO 1

INTRODUÇÃO

1.1 Apresentação (Histórico sobre o Problema)

Este trabalho é sobre Web Services, que serão referenciados como Serviços na Web ao longo deste. O foco principal trata do problema da publicação e busca desses serviços em um registro central. Existem algumas formas de se resolver este problema tais como ebXML (http://www.ebXML.org) e WS-Inspection (http://www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html). Entretanto, neste trabalho aborda-se o “Universal Description, Discovery and Integration” (UDDI) (OASIS, 2004).

Por se tratar de um projeto inicial, o trabalho aqui apresentado é baseado na especificação UDDI (BELLWOOD, 2002), a partir do qual é construído um protótipo do repositório do modelo de informação UDDI.

1.2 A justificativa da escolha do problema

O contexto da Web, nos últimos anos, evoluiu do fornecimento de páginas (estáticas ou dinâmicas), para o fornecimento de serviços. Pode-se caracterizar um serviço como uma abstração de um conjunto de operações providas a clientes, as quais permitem aos mesmos realizarem uma determinada função (SIMON, 1996:395). O paradigma dos Serviços Web proporciona a construção de aplicações distribuídas que fornecem tais serviços. A aceitação desse paradigma, perante os mais diferentes tipos de desenvolvedores de software para a Web (devido à sua independência de plataforma e linguagem) e a oferta de diversos produtos que possibilitam a criação destes serviços, mostram que este paradigma

(9)

promete se tornar um padrão, mudando a forma de se oferecer serviços na Internet e em outras redes. Um componente importante na arquitetura orientada a Serviços Web é o repositório UDDI. Esse repositório desempenha o papel de intermediário entre o fornecedor de serviços e os consumidores destes. Sua existência e a sua correta utilização tornam a arquitetura orientada a serviços mais completa, criando um meio para que fornecedores possam publicar seus serviços e que consumidores consigam procurar e buscar serviços de forma prática e rápida. O desenvolvimento de um protótipo do UDDI tem como finalidade estudar como este sistema funciona, adquirindo o conhecimento necessário para o entendimento maior de um sistema com Serviços Web.

1.3 Formulação do Problema e delimitação do mesmo

Não havendo o conhecimento prévio da localização de serviços na Web, como um serviço pode ser encontrado? O meio mais natural é que exista um sistema que localize estes serviços, possibilitando a pesquisa por meio de um browser ou automaticamente durante a execução da aplicação. Um sistema UDDI é proposto para resolver este problema. A arquitetura do UDDI consiste, basicamente, de um modelo de dados, APIs para publicação e busca, um conjunto de sites operadores, que são organizações que hospedam uma implementação da especificação UDDI.

Embora o UDDI facilite a descoberta de serviços, existem algumas limitações para o mesmo. A mais significante é a imaturidade da especificação. O UDDI ainda não é muito utilizado por falta de conhecimento, e registros públicos que implementam a última versão da especificação ainda estão em testes. Uma outra limitação é que registros UDDI descrevem serviços, mas não os avaliam quanto à sua qualidade (QoS) (DEITEL, 2003:160).

(10)

1.4 Importância do Tema Pesquisado

A criação de um repositório UDDI é muito valiosa no sentido da criação de repositórios privados, onde uma instituição pode manter todos os seus serviços publicados em um único local, possibilitando que usuários da rede interna os possam descobrir e utilizar. Outra importância é que o conhecimento adquirido na implementação da especificação UDDI possibilita a criação de um outro tipo de negócio, os Registrar. Um Registrar é uma organização que auxilia na criação de informações de negócios e descrição de Serviços Web, publicando-as em um repositório. Portanto, um Registrar não armazena informações sobre um serviço, ele simplesmente realiza o serviço de “marketing” para fornecedores de serviços.

1.5 Trabalhos Relacionados

A literatura existente sobre UDDI e outras tecnologias de descoberta de serviços mostra atualmente uma variedade de publicações sobre o tema, como pode ser visto em DEITEL (2003, p.164).

1.6 Objetivos

• Estudar como o Modelo de Informação é organizado; • Implementar as APIs de publicação e busca do UDDI;

• Organizar um protótipo funcional do UDDI, considerando a sua especificação oficial, versão 3.0.

(11)

1.7 Estrutura do Trabalho

Este trabalho será dividido em quatro partes. A primeira consiste no aprofundamento teórico do que é um sistema UDDI. A segunda parte consiste na criação do projeto do repositório para o protótipo. A terceira etapa é a implementação e testes do projeto. A última é composta pela avaliação dos resultados obtidos, conclusões e sugestão de trabalhos futuros.

(12)

CAPÍTULO 2

FUNDAMENTAÇÃO TEÓRICA

Os Serviços Web estão criando um novo paradigma no fornecimento e utilização de serviços em rede. O motivo deste sucesso é a proposta de integrar qualquer sistema independente das suas características. O que torna esta proposta viável é a utilização do XML. O Extensible Markup Language (XML) é uma linguagem que utiliza tags como o HTML e se tornou o padrão em troca de informações entre sistemas de informação heterogêneos, pois ela é independente de plataforma, sistema operacional e linguagem de programação. É uma linguagem rígida na sua formatação para evitar ambigüidades e sua característica de armazenar informações sem codificação possibilita visualizar as informações armazenadas como um texto comum. Aproveitando-se destas características do XML, foi criado o SOAP (SOAP, 2003). O Simple Object Access Protocol (SOAP) é um protocolo de comunicação muito simples, que especifica meios para enviar e receber informações descritas em XML, através de protocolos como o http, https, smtp e outros. A grande vantagem do SOAP é utilizar tecnologias bem difundidas e maduras, possibilitando sua utilização por qualquer tipo de sistema. O SOAP trouxe a facilidade da comunicação, permitindo a criação de serviços e sua disponibilidade para qualquer usuário. A idéia de fornecer e utilizar pedaços de programas remotos como se fossem serviços não é nenhuma novidade. Existem tecnologias como CORBA, RPC e RMI que também possibilitam a criação de uma arquitetura baseada em serviços, mas nenhuma delas realmente abrange todas as plataformas e linguagens. Esta liberdade de escolha tem feito a diferença, elevando esta arquitetura a um novo nível, ganhando mais espaço entre programadores e empresas do ramo. Mas somente disponibilizar os serviços através do SOAP não era o bastante, pois havia a falta de um documento que possibilitasse descrever os serviços, informando sua funcionalidade, sua localização, como iniciar a comunicação e o que esperar como resposta. A partir

(13)

desta necessidade foi criada a WSDL (CHRISTENSEN, 2001). A Web Service Description Language (WSDL) é uma linguagem criada com o intuito de descrever Serviços Web, trazendo todas as informações relativas ao serviço, partindo de informações gerais como a descrição do serviço até informações técnicas como a localização do serviço e o protocolo de rede utilizado.

Para tornar a arquitetura dos Serviços Web completa, falta somente uma tecnologia e é justamente esta o motivo de estudo deste trabalho, o UDDI.

Antes de iniciar o estudo do UDDI, segue abaixo uma explicação mais detalhada e alguns exemplos de pacotes contendo SOAP e documentos WSDL.

2.1 SOAP e exemplos

Atualmente na versão 1.2, o SOAP é um protocolo superficial que permite a comunicação em um ambiente descentralizado. Ele é independente de hardware de rede e de protocolos, sendo geralmente utilizado sobre o http por este ser o mais utilizado e por passar facilmente por firewalls. A especificação do SOAP é dividida em duas partes: encapsulamento de mensagens e de RPC (Remote Procedure Call). O encapsulamento de mensagens é utilizado para a troca de informações descritas em XML, podendo conter qualquer tipo de documento descrito nesta linguagem. A outra parte da especificação descreve como fazer chamadas de procedimentos remotos utilizando o SOAP. Usar o SOAP para fazer RPC é sua utilização mais comum e a qual tem mais suporte no mercado. Ferramentas, como o JAX-RPC, tornam transparente para o programador como é realizado o RPC, necessitando de somente uma interface do serviço para gerar tanto a parte do servidor quanto a do cliente.

Uma outra especificação relacionada é a “SOAP Messages with Attachments” (BARTON, 2000), que define um meio para enviar anexos com a mensagem SOAP. Esta especificação não define tipos de codificação, empregando o padrão MIME, que é o mesmo utilizado nos e-mails, possibilitando

(14)

enviar outros documentos XML, documentos de texto, fotos, arquivos binários e outros. A figura abaixo apresenta um pacote SOAP juntamente com seus anexos.

Figura 2.1: Mensagem SOAP (Fonte: Java Web Service Tutorial).

Ignorando os anexos, a mensagem SOAP é composta pelo elemento raiz Envelope, que possui dois elementos filhos chamados Header e Body. O elemento Envelope é uma analogia ao envelope de carta que contém cabeçalho e conteúdo. O elemento Header é o cabeçalho da mensagem, podendo ser utilizado para enviar informações de controle. O Body é o elemento que leva a carga útil da mensagem, sendo esta um RPC ou não. A seguir está um exemplo de RPC através do SOAP utilizando o http.

(15)

POST /rpcrouter HTTP/1.1 Host: 127.0.0.1

Content-Type: text/xml; charset: “utf-8” Content-Length: 287 SOAPAction: “http://www.mydomain.org/services/GetDateTime <SOAP-ENV:Envelope xmlns:SOAP-ENV = “http://schemas.xmlsoap.org/soap/envelope/”> </SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:GetDateTime xmlns:ns1 = “urn:TimeService”> <format>long</format> </ ns1:GetDateTime> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Exemplo 2.1: Solicitação de um RPC através do SOAP.

HTTP/1.1 200 OK

Content-Type: text/xml; charset: “utf-8” Content-Length: 342 <SOAP-ENV:Envelope xmlns:SOAP-ENV = “http://schemas.xmlsoap.org/soap/envelope/”> </SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:GetDateTimeResponse xmlns:ns1 = “urn:TimeService”> <return xsi:type=”xsd:string”>

Fri Jan 23 18:27:55 EDT 2004 </return>

</ ns1:GetDateTimeResponse> </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Exemplo 2.2: Resposta de um RPC através do SOAP.

2.2 WSDL e exemplos

A linguagem WSDL tem como objetivo principal a definição de um meio para que Serviços Web possam ser descritos de forma neutra, especificando de

(16)

forma clara uma interface externa com quem um sistema ir-se-á comunicar. É o documento WSDL que indica para um consumidor as regras que ele deve seguir para poder usufruir um serviço. Neste trabalho, o conceito do WSDL será muito importante, mas não haverá necessidade de se conhecer as definições dos elementos de um documento deste tipo, pois este apenas será referenciado. Segue abaixo o exemplo WSDL do RPC anterior.

<?xml version="1.0" ?> <definitions name="urn:TimeService" targetNamespace="urn:timeService-getDateTime" xmlns:tns="urn:timeService-getDateTime" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <message name="GetDateTime">

<binding name="TimeServiceBinding" type="tns:TimeService"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getDateTime"> <soap:operation soapAction="getDateTime"/> <input> <soap:body use="encoded" namespace="urn:timeService-getDateTime" encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="encoded" namespace="urn:timeService-getDateTime"

(17)

encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> <service name="TimeServiceService">

<port name="TimeService" binding="tns:TimeServiceBinding"> <soap:address

location="http://localhost:8080/axis/servlet/AxisServlet"/> </port>

</service> </definitions>

Exemplo 2.3 – Documento WSDL descrevendo o RPC dos exemplos 2.1 e 2.2.

CAPÍTULO 3

O UDDI

Este capítulo descreve o terceiro elemento que completa a arquitetura dos Serviços Web. O UDDI (Universal Discovery, Description and Integration) pode ser

(18)

considerado o elemento menos essencial desta arquitetura, mas sua utilização a torna muito mais completa e eficiente. Utilizando as tecnologias descritas no capítulo anterior, torna-se possível criar os serviços e utilizá-los. Mas, partindo da situação em que ocorram consumidores interessados, há produtores disponibilizando seus serviços e respectivas descrições em arquivos WSDL. Porém, existe um vazio entre eles, pois desconhecem a existência uns dos outros. Neste panorama se faz necessária a existência de um mecanismo de publicação e busca, que auxilie na descoberta entre ambas as partes, criando um passo anterior à utilização do serviço. É para solucionar este problema que existe o UDDI. Ele é um repositório onde são armazenadas as informações sobre serviços e as entidades que os fornecem. Com isto, ocorre a centralização destas informações, auxiliando os produtores a exporem seus serviços e aos consumidores localizarem o que desejam.

A arquitetura dos Serviços Web é segue o conceito de SOA (service oriented architecture), que é a arquitetura orientada a serviços. Este conceito define três papéis e suas funções:

• Requisitante de serviços • Provedor de Serviço • Broker de serviço

O UDDI faz o papel de broker de serviço, que possibilita ao requisitante encontrar o provedor de um serviço. Segue abaixo uma figura que descreve esta arquitetura dos Serviços Web, apresentando os papéis e a comunicação entre eles.

(19)

Figura 3.1: Arquitetura Orientada a Serviços dos Serviços Web.

Pode-se descrever o funcionamento desta arquitetura nos três passos seguintes: O primeiro diz respeito à publicação, onde o fornecedor de serviços entra em contato com o UDDI, se registra, informa os serviços disponíveis e onde encontrá-los. O segundo passo é realizado pelo Consumidor, que utiliza os métodos de busca fornecidos pelo UDDI para encontrar as informações desejadas sobre entidades e serviços. De posse das informações necessárias, o consumidor pode prosseguir para o último estágio, onde se comunica diretamente com o fornecedor, utilizando um de seus serviços.

A interação entre o UDDI e os demais elementos também é realizada através do protocolo SOAP, sendo ele próprio um Serviços Web. Mas sua especificação já define alguns pontos básicos deste serviço, sendo o protocolo utilizado o http (ou https quando há necessidade de criptografia), sendo que, neste caso, ao contrário da maioria dos Serviços Web, não se utiliza RPC. Sua comunicação é realizada através de mensagens descritas na API do UDDI. Esta API descreve, para cada método, a estrutura XML que deve estar contida dentro do elemento Body no pacote SOAP, assim como a estrutura que será retornada. A API e seus métodos são descritos e exemplificados em um capítulo adiante. Mas antes de ver a API, é necessário saber a estrutura em que os dados são descritos em um UDDI.

(20)

3.1 Níveis de UDDI

Para facilitar a compreensão de como é organizado o UDDI, e quais informações são armazenadas, é realizada uma analogia entre o repositório e uma lista telefônica. Da mesma maneira que em uma lista, o UDDI deve seguir rígido para que as informações sejam dispostas de uma forma que facilite uma pesquisa. Abaixo, seguindo com a analogia, tem-se uma divisão do UDDI por cores de páginas:

• Páginas Brancas (White Pages): são apresentadas nesta seção as informações gerais referentes as empresas, contendo por exemplo seu nome, descrição, pessoas para contato e outras;

• Páginas Amarelas (Yellow Pages): as empresas apresentadas nas Páginas Brancas estão aqui divididas por taxonomias padronizadas, que dividem essas empresas e seus serviços por industria, categoria ou por região geográfica;

• Páginas Verdes (Green Pages): nesta seção são apresentadas as informações técnicas sobre os serviços, informando sua localização, de que forma acessá-los e onde podem ser encontradas informações adicionais sobre serviços.

3.2 O Modelo de Informação

O tópico anterior apresenta quais são as informações armazenadas em um registro. Para que estas sejam facilmente manipuladas, devem estar armazenadas de forma organizada, seguindo o padrão especificado pelo Modelo de Informação do UDDI. Este modelo é formado por vários elementos XML relacionados entre si. O topo da hierarquia é formado pelo businessEntity, que apresenta os dados referentes ao negócio ou organização, contendo nome, descrição, contatos, identificadores e um conjunto de businessService. O businessService apresenta

(21)

um serviço, contendo nome, descrição, identificadores e um conjunto de bindingTemplate. O bindingTemplate por sua vez, traz informações de onde encontrar o serviço e um apontador para um tModel, que contém informações de como proceder para utilizar o serviço. A figura 3.2 demonstra esta hierarquia.

Figura 3.2: O Modelo de Informação UDDI.

Apesar do UDDI ser utilizado para descrever Serviços Web e seus provedores, seu modelo de informação permite que outros tipos de serviços e organizações sejam descritos. Por exemplo, poderia ser armazenada em um UDDI uma empresa que realiza pesquisas. Um de seus serviços é fazer uma pesquisa pelo telefone a um número determinado de pessoas. O vínculo de ligação deste serviço poderia ser o número do telefone da empresa. A especificação permite que exemplos como este sejam perfeitamente armazenados em um registro UDDI.

(22)

O businessEntity é o elemento raiz que encapsula todas as informações referentes a uma “empresa”. Apesar deste elemento se chamar businessEntity, ele foi criado para descrever uma empresa, uma universidade, uma entidade, ou seja, qualquer fornecedor de serviços. Cada elemento deste tipo armazenado em um UDDI, apresenta um atributo chamado businessKey, que contém uma chave única que identifica cada businessEntity em um UDDI. Elementos filhos do businessEntity representam as diversas informações como o nome e descrição da “empresa”, pessoas para contato, identificadores, categorias e URLs para mais informações. Além dos elementos anteriores, outro elemento é o businessServices, que representa todos os serviços desta “empresa”. Segue abaixo um exemplo. <businessEntity businessKey="B93E74D0-DCAD-11D7-A0CA-000629DC0A53"> <discoveryURLs> <discoveryURL useType="businessEntity"> http://jordan.products.com </discoveryURL> </discoveryURLs>

<name xml:lang="en">Jordan web products</name> <name xml:lang="pt">Jordan produtos para web</name> <description xml:lang="en">

All that you need to increase your work using the web. </description>

Tudo para aumentar sua produção através da web. </description>

The manager of the company.</description> <personName>Luís Fernando Jordan</personName> <phone useType="">99695026</phone>

<email useType="">jordan@jordan.products.com</email> <address>

<addressLine>Rua Ben-te-vi, 222.</addressLine> <addressLine>Village I</addressLine>

<addressLine>Lagoa da Conceição</addressLine> <addressLine>Florianópolis, Brasil.</addressLine> </address>

(23)

</contact> </contacts> <businessServices> </businessServices> <categoryBag> <keyedReference tModelKey="UUID:4E49A8D6-D5A2-4FC2-93A0-411D8D19E88”

keyName="Santa Catarina" keyValue="BR-SC"> </keyedReference>

<keyedReference tModelKey="UUID:1FF729F2-1948-46CF-B660-31EC107F1663"

keyName="Computer Systems Design and Related Services" keyValue="5415">

</keyedReference> </categoryBag>

</businessEntity>

Exemplo 3.1: Exemplo de um businessEntity.

O elemento businessServices destacado está incompleto. Este elemento tem como função agrupar todos os elementos businessService.

3.2.2 O elemento businessService

Este elemento encapsula todas as informações referentes a um serviço. Este elemento apresenta dois atributos chamados businessKey e serviceKey. O serviceKey é o identificador único que cada serviço possui. O businessKey é a chave que representa a qual empresa este serviço pertence. Este atributo pode diferir do atributo de mesmo nome do elemento pai businessEntity em que este está inserido. Isso indica que este é uma projeção de um serviço de outra empresa. Desta forma, há possibilidade de se adicionar serviços de outras empresas na sua lista. Alguns dos elementos filhos do businessEntity também estão presentes no businessService, são eles: name, description e categoryBag. Um dos filhos do elemento businessService é o bindingTemplates, que representa

(24)

um conjunto de elementos bindingTemplate. A seguir, um exemplo de um elemento businessService.

<name xml:lang="en">UDDI Business Registry</name> <description xml:lang="en">

UDDI for all !!! </description> <bindingTemplates> </bindingTemplates> <categoryBag> <keyedReference tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6634"

keyName="Database software" keyValue="43.16.15.01.00"> </keyedReference>

</categoryBag> </businessService>

Exemplo 3.2: Exemplo de um businessService.

3.2.3 O elemento bindingTemplate

As informações técnicas dos serviços são fornecidas através do elemento bindingTemplate, que contém dois atributos, serviceKey e bindingKey, que são as chaves do businessService e do bindingTemplate, respectivamente. Um de seus elementos filhos é o accessPoint, que é um dos elementos mais importantes deste modelo de informação. O accessPoint possui um atributo opcional chamado useType que, quando presente, identifica o significado do conteúdo do elemento. Alguns dos tipos já definidos pelo UDDI são:

• endPoint: define que o conteúdo é a URL do endpoint do Serviços Web, ou seja, o ponto de ligação do serviço;

• bindingTemplate: define que o elemento contém um bindingKey para outro elemento bindingTemplate. Isto possibilita que se reutilize uma descrição técnica para mais de um serviço;

(25)

• hostingRedirector: indica que o acessPoint só poderá ser descoberto fazendo uma pesquisa em outro UDDI;

• wsdlDeployment: indica que o elemento contém um endereço que aponta para um arquivo WSDL que fornece todas as informações de ligação, como o endpoint.

Outros valores podem ser acrescentados a esta lista, para possibilitarem que este elemento represente outros tipos de informações.

Além do accessPoint e de outros elementos já conhecidos, o bindingTemplate contém um elemento de muita importância chamado tModelInstanceDetails, que apresenta um conjunto de tModelInstanceInfo. Este conjunto é chamado de “technical fingerprint”, pois representa todas as especificações técnicas referentes a um serviço. Os elementos tModelInstanceInfo podem ser elementos simples, contendo apenas um atributo que possui uma chave primária de um tModel, ou possuir uma estrutura bem elaborada. Mas o objetivo principal é vincular uma especificação a um serviço, fornecendo qualquer informação adicional relacionada a esta especificação, que é representada em um tModel. O exemplo mais comum é um serviço conter uma chave para um tModel que represente seu protocolo de transporte, e dependendo deste protocolo, informações como documentos relacionados e parâmetros necessários à utilização desse. <bindingTemplate bindingKey="B0522540-DCAF-11D7-A0CA-000629DC0A53" serviceKey="B0330480-DCAF-11D7-A0CA-000629DC0A53"> <accessPoint useType="endPoint"> https://jordan.products/uddi/publishing </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="UUID:68DE9E80-AD09-469D-8A37- 088422BFBC36"> </tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate>

(26)

Exemplo 3.3: exemplo de um bindingTemplate.

O exemplo acima é bem simples, mas representa a idéia do bindingTemplate. As duas informações contidas acima são o endereço do endpoint e o protocolo utilizado, onde o protocolo é representado pelo tModel referenciado pela chave contida no atributo tModelKey.

3.2.4 O elemento tModel

O último dos elementos chaves deste modelo de informação é o Technical Model, geralmente referenciado como tModel. Observa-se que o tModel tem um papel importante ao definir o “technical fingerprint”, promovendo a compreensão entre sistemas diferentes. Isto é comum nos Serviços Web, pois sistemas heterogêneos precisam concordar com diversas regras de representação de dados antes de trocarem informações. Mas o objetivo do tModel é mais amplo, pois este foi criado para abstrair diferentes informações como conceitos, especificações, meios de transporte, protocolos em geral e os diversos namespaces existentes em um UDDI. Com o intuito de promover a reutilização de informações, o tModel não está contido no eixo central que representa os outros elementos principais, onde existe um relacionamento de elemento pai e filho. Desta maneira, um UDDI armazena uma grande quantidade de tModel que são referenciados por diversos elementos. É importante frisar que o elemento tModel armazena seu nome e uma breve descrição. Os documentos que descrevem com detalhes conceitos e especificações complexas não são armazenados. Estes documentos são referenciados no elemento filho overviewDoc, não sobrecarregando o banco de dados do UDDI. Além destes elementos filhos, o tModel também armazena identificadores e categorias que serão discutidos adiante.

(27)

3.2.5 O elemento publisherAssertion

Além dos elementos anteriores, o modelo de informação representado pela Figura 3.2 apresenta um quinto elemento, chamado publisherAssertion. Este elemento não apresenta tanta importância quanto os anteriores pois não carrega tanta semântica e é utilizado em poucos casos. O propósito deste elemento é representar a ligação entre diversos elementos businessEntity. Esta ligação é utilizada quando, por exemplo, uma organização deseja explicitar a ligação existente entre suas empresas, ou ainda, quando uma empresa multinacional representa cada uma de suas filiais como empresas isoladas e utiliza o publisherAssertion para caracterizar a ligação entre elas.

3.3 Identificadores e Categorias

Além de centralizar a publicação e busca, o UDDI apresenta outra característica interessante que são as facilidades de busca. Devido ao grande número de registros e à quantidade de informações contidas dentro desses, um repositório como o UDDI deve fornecer meios que permitam aos usuários realizarem consultas especializadas, tornando o processo fácil e rápido, minimizando o número de acessos ao repositório e a quantidade de informações trafegadas na rede. Para isso, a especificação do UDDI define os elementos XML identifierBag e categoryBag.

Através do elemento identifierBag, tanto empresas quanto especificações podem adicionar seus identificadores que os tornam únicos, como por exemplo, adicionar o número CNPJ de uma empresa brasileira no seu registro do UDDI. Estes identificadores são úteis quando utilizados para refinar uma busca, mas também tornam o modelo de informação mais rico, possibilitando que os dados armazenados mostrem com mais realismo as empresas e especificações descritas.

(28)

Exemplo 3.4: Exemplo de um identifierBag.

Este exemplo apresenta um identifierBag que indica que a empresa “My Company” é identificada no D-U-N-S pelo número “12-345-6789”.

O elemento categoryBag permite que empresas, serviços, vínculos e especificações possam ser registradas em múltiplas categorias, classificados por tipos de indústrias, produtos, serviços, códigos geográficos e outros, todos baseados em taxionomias padronizadas. Com isto, a utilização do UDDI possibilita realizar uma pesquisa que envolva centenas de empresas e milhares de serviços, focando somente naquelas que se encontram no Brasil, e que fornecem serviços na área ambiental. O UDDI contempla, inicialmente, três categorias de negócios:

• NAICS – “North American Industry Classification System”, que provê classificação para indústrias;

• UNSPSC – “Universal Standard Produts and Services Classification”, que provê classificação de produtos e serviços;

• ISO 3166 – “International Organization for Standardization”, que mantém a norma 3166 para uma taxionomia padronizada de regiões geográficas. Além disto, a especificação permite que classificadores possam ser organizados em grupos, estendendo sua utilização. Isto pode ser utilizado de diversas maneiras e os casos seguintes exemplificam sua utilização.

O primeiro caso é utilizar grupos para criar campos de atuação, oferecendo serviços diferentes para cada região.

(29)

<keyedReferenceGroup

tModelKey=”uddi:uddi.org:ubr:categorizationgroup:unspsc_geo3166> <keyedReference

tModelKey=”uddi:uddi.org:ubr:categorization:unspsc”

keyName=”UNSPSC:Medical Equipment and Accessories and Supplies” keyValue=”42.00.00.00.00”/> <keyedReference tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” keyName=”GEO:Germany” keyValue=”DE”/> </keyedReferenceGroup> <keyedReferenceGroup tModelKey=”uddi:uddi.org:ubr:categorizationgroup:unspsc_geo3166”> <keyedReference tModelKey=”uddi:uddi.org:ubr:categorization:unspsc”

keyName=”UNSPSC:Medical Equipment and Accessories and Supplies” keyValue=”42.00.00.00.00”/> <keyedReference tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” keyName=”GEO:France” keyValue=”FR”/> </keyedReferenceGroup> </categoryBag>

Exemplo 3.5: Exemplo de um categoryBag.

Outro caso é quando uma categoria exige um conjunto de informações, onde elas isoladas não possibilitam uma classificação. O exemplo a seguir apresenta como representar coordenadas baseadas na latitude e longitude, através de uma categoryBag.

<categoryBag> <keyedReferenceGroup tModelKey=”uddi:uddi.org:ubr:categorizationGroup:wgs84”> <keyedReference tModelKey=”uddi:uddi.org:ubr:categorization:wgs84:latitude” keyName=”WGS 84 Latitude” keyValue=”+49.682700”/> <keyedReference

(30)

tModelKey=”uddi:uddi.org:ubr:categorization:wgs84:longitude” keyName=”WGS 84 Longitude” keyValue=”+008.295200”/> </keyedReferenceGroup> </categoryBag>

Exemplo 3.5: Outro exemplo de um categoryBag.

Tanto os identificadores quanto as classificações são representados por tModels. Por este motivo, estender o UDDI é uma tarefa simples, necessitando somente adicionar tModels que representem identificadores e classificações de qualquer tipo.

3.4 Internacionalização

A especificação do UDDI apresenta de diversas maneiras que a palavra “Universal” da sigla UDDI não está lá sem motivo. Ela se preocupa com a internacionalização, fornecendo meios para que nomes e descrições sejam fornecidas em diversas línguas e que diferenças culturais como a forma de descrever um endereço sejam respeitadas. Na questão dos endereços, a especificação não obriga a divisão em país, estado, cidade e outros. O sistema é simples; um endereço é um conjunto de linhas de endereço, deixando a cargo de cada um o que incluir em cada uma delas.

<businessEntity . . . > ...

<name xml:lang="ja"> </name> <name xml:lang="en">NIPPON FLOWERS</name> <name xml:lang="en">NF</name>

(31)

</businessEntity>

Exemplo 3.6: Exemplo de internacionalização.

No exemplo acima, identifica-se a possibilidade de especificar um nome em diversas línguas, em regiões diferentes ou somente descrever algo de diversas maneiras.

3.5 UDDI nodes e registries

Existem alguns conceitos por trás do UDDI que são interessantes destacar. Um “UDDI node” é um Serviços Web, ou um conjunto deles, que representa um ou mais APIs do UDDI. Um node pertence a exatamente um “UDDI Registry”. Os registries representam um conjunto desses nodes que, coletivamente, administram os dados armazenados, realizando inclusões, exclusões e buscas.

CAPÍTULO 4

As APIs do UDDI

No capítulo anterior foi descrito como são organizados os dados em um repositório UDDI. Com o intuito de definir meios para que esta estrutura seja preenchida com dados e que estes possam ser pesquisados de maneira eficaz, a especificação do UDDI descreve com detalhes as mensagens SOAP entre o repositório e seus usuários. O conjunto de especificações destas mensagens são chamadas de APIs e cada uma assume funções necessárias para que o repositório UDDI funcione corretamente. Listadas abaixo estão todas as APIs,

(32)

divididas em dois grupos, classificando aquelas que são implementadas por nodos UDDI e as implementadas pelo cliente:

• Node API Sets

o UDDI Inquiry o UDDI Publication o UDDI Security

o UDDI Custody Transfer o UDDI Subscription o UDDI Replication

• Client API Sets

o UDDI Subscription Listener

o UDDI Value Set

As APIs Inquiry e Publication serão mais abordadas por serem as principais, sendo as demais, como referidas pela especificação, opcionais.

4.1 UDDI Inquiry API

A API Inquiry é responsável pela especificação dos métodos de busca realizados no repositório UDDI. Esta API não requer autenticação; portanto é acessível a todos sem a necessidade de se registrar no UDDI. Abaixo estão representados os três padrões de consulta (query patterns) pertencentes a esta API:

• browse – este tipo de busca é a primeira utilizada. A partir de dados gerais, este padrão geralmente retorna um grande número de casos encontrados, os quais podem ser selecionados com o intuito de refinar a pesquisa. As cinco estruturas do modelo de informação, mostradas no capítulo anterior, são suportadas por este padrão, permitindo consumidores de serviços realizarem uma ampla busca de empresas e seus negócios, serviços, vínculos ou tModels. Como o número de casos é grande, a informação retornada referente a cada um é pequena, consistindo da chave única de

(33)

cada estrutura, seu nome e uma pequena descrição. Este padrão é representado pelos métodos que possuem o nome “find_xyz” onde xyz é o nome da estrutura a ser pesquisada;

• drill-down – utilizado quando se deseja uma descrição completa de uma estrutura já conhecida. Esse padrão é usado em conjunto com o anterior, porque requer a chave única de cada elemento (identification key), obtida durante a operação do padrão browse, a qual é passada como argumento em uma pesquisa drill-down. As informações retornadas podem descrevem completamente empresas e seus serviços, possibilitando a decisão sobre consumir ou não um deles; ou trazerem informações técnicas de como se comunicar com o Serviços Web. Este padrão é representado pelos métodos “get_xyz” onde xyz é o tipo de estrutura da qual se deseja obter mais informações;

• invocation pattern – utilizado por um sistema que deseja estar sempre atualizado quanto à localização de um serviço. Sempre que ocorre uma falha de conexão com um endpoint, um sistema realiza uma consulta que utiliza os moldes anteriores, obtendo uma estrutura bindingTemplate, comparando com suas informações e atualizando-as se for necessário. Para realizar pesquisas nos moldes acima, a Inquiry API fornece os seguintes métodos:

• find_binding: retorna um elemento bindingDetail, contendo informações

sobre vínculos de um ou mais serviços;

• find_business: retorna informações gerais de diversas organizações,

como seu nome e pequena descrição;

• find_relatedBusinesses:retorna elementos businessEntity

relacionados com a organização fornecida;

• find_service: retorna um elemento serviceList que contém

(34)

• find_tModel: retorna informações gerais sobre os diversos tModels encontrados;

• get_bindingDetail: retorna o bindingTemplate correspondente a chave única fornecida;

• get_businessDetail: retorna o elemento businessEntity que apresenta a chave única fornecida;

• get_operationalInfo: retorna informações relacionadas de qualquer elemento representado pela sua chave única. Estas informações podem ser, por exemplo, a data em que a estrutura foi inserida no repositório ou a data da sua última atualização;

• get_serviceDetail: retorna o elemento businessService que possui a chave fornecida;

• get_tModelDetail: retorna o tModel dono da chave única fornecida.

4.2 UDDI Publication API

A API de publicação é responsável pelos dados armazenados no registro. É sua função especificar os métodos responsáveis pela publicação, atualização e eventual remoção de informações. Esta API, diferente da anterior, necessita que seus usuários sejam identificados, possibilitando o controle das informações que serão publicadas e aquelas que serão removidas. Desta forma, o registro pode assegurar que informações de um usuário não sejam alteradas ou perdidas pela má utilização desta API, por parte de outro usuário. A especificação do UDDI define a utilização do protocolo “https” para que a autenticação e tráfego de dados sejam feitos de forma segura. Os métodos abaixo formam a API de publicação:

• add_publisherAssertions: adiciona estruturas publishAssertion ao

registro;

(35)

• delete_business: remove uma empresa do registro;

• delete_publisherAssertions: remove uma asserção do registro; • delete_service: remove um serviço;

• delete_tModel: oculta um tModel, não permitindo que ele seja

encontrado por um método find_tModel. O tModel não é removido, sendo suas referências mantidas e suas informações disponíveis através do método get_tModelDetail. Não existe nenhum método especificado para apagar um tModel;

• get_assertionStatusReport: ajuda a administrar as asserções, informando o status de cada uma;

• get_publisherAssertions: obtém uma lista de todas as

publishAssertions;

• get_registeredInfo: obtém uma lista dos empresas e tModels

gerenciados no registro;

• save_binding: publica ou atualiza vínculos no registro;

• save_business: utilizado para publicar ou atualizar elementos businessEntity. Como os elementos que representam serviços e vínculos são filhos do elemento businessEntity, este método pode publicar e atualizar todos os três elementos de uma só vez;

• save_tModel: publica e atualiza tModels no registro;

• set_publisherAssertions: publica de uma só vez um conjunto de asserções. Todas as asserções antigas são removidas quando este método é utilizado.

4.3 UDDI Security API

Para utilizar os métodos da API de publicação, é necessário enviar junto com as demais informações um elemento chamado authInfo que identifica um

(36)

usuário. A API de segurança especifica meios para obter esta autorização através do fornecimento de tokens. Ela define dois métodos:

• discard_authToken: indica que o token obtido não será mais necessário e que o registro deve recusar qualquer método que forneça este token;

• get_authToken: solicita um token de autorização, informando o nome do usuário e sua senha. O retorno do método é o elemento authInfo que será utilizado para acessar os métodos restritos.

O registro pode não utilizar esta API, mas deve sempre fornecer um meio para que o elemento authInfo possa ser obtido.

4.4 UDDI Custody Transfer API

Um usuário utilizando a API de publicação possui todos os direitos sobre os elementos businessEntity e tModel inseridos por ele em um nodo UDDI. Caso o usuário deseje transferir esses direitos a outro usuário ou transferir estes elementos para outro nodo, ele deve utilizar a Custody Transfer API. Esta API fornece métodos como get_transferToken e transfer_entities.

4.5 UDDI Subscription API

Um usuário pode utilizar esta API para ser notificado sobre mudanças no registro UDDI em que está inscrito. Desta forma, pode-se requisitar, por exemplo, uma notificação sempre que uma empresa ou serviço for publicado, visando obter parceiros ou consumir novos serviços.

(37)

4.6 UDDI Replication API

Esta API define os métodos para a replicação dos dados armazenados e para mantê-los de forma coerente.

4.7 UDDI Subscription Listener API

Esta API já não faz parte das APIs implementadas pelos nodos UDDI. Ela é representada através de um tModel, que especifica a interface que um cliente deve implementar caso deseje receber notificações de um nodo UDDI que utiliza a Subscription API para enviar notificações das mudanças requisitadas.

4.8 UDDI Value Set API

No capítulo anterior foi apresentado o conceito de identificadores e categorias no UDDI. Estes conceitos estão ligados aos elementos keyedReference e keyedReferenceGroup que, basicamente, armazenam uma referência para um tModel e um par de valores que representam o nome e valor de uma chave. Sempre que estes elementos são armazenados, eles podem ser validados para certificar que o par de valores faz sentido para um determinado valor. Para que esta validação seja efetuada, o UDDI fornece a Value Set API. Esta API opcional pode ser implementada por um cliente que está habilitado a verificar os dados, informando ao registro se os dados estão corretos ou não.

(38)

CAPÍTULO 5

Descrição do protótipo

Foi apresentada nos capítulos anteriores a arquitetura dos Serviços Web, em especial o elemento responsável pela publicação e busca de serviços chamando UDDI. Como o objetivo deste trabalho é implementar um protótipo de registro UDDI, este capítulo contempla a estrutura deste protótipo e as tecnologias envolvidas na sua criação.

O protótipo utiliza a linguagem de programação Java™, que foi escolhida por ser uma linguagem orientada a objetos com uma ampla disponibilidade de tecnologias e ferramentas relacionadas com XML e Serviços Web. Estas características foram fundamentais na criação da estrutura, na criação dos endpoints e na comunicação com o banco de dados escolhido.

A estrutura da implementação foi idealizada para conter dois módulos básicos. O primeiro módulo é responsável pela comunicação com o cliente, leitura

(39)

e processamento da mensagem e, por fim, envio de uma requisição para o segundo módulo. O segundo recebe a requisição e a trata, comunicando-se com o banco de dados ou outra forma de armazenamento. Esta divisão visa permitir diferentes formas de armazenamento, como banco de dados relacionais, orientados a objetos, nativos XML e outros, modificando apenas um dos módulos. Segue abaixo a figura que representa o primeiro módulo do protótipo.

Figura 5.1: Primeiro módulo do protótipo.

O funcionamento deste módulo começa a partir do recebimento de uma mensagem enviada por um cliente. Esta mensagem, que representa um método das APIs do UDDI, pode ser recebida por um dos dois endpoints presentes neste protótipo. Um deles representa a API de busca e utiliza o protocolo http, não exigindo autenticação do cliente. O segundo representa a API de publicação, utilizando o protocolo https para proteger os dados trafegados. Para implementar estes endpoints foi utilizada a tecnologia SAAJ fornecida pela Sun Microsystems , com o pacote JWSDP (SUN MICROSYSTEMS, 2004). Existem outras tecnologias que fornecem meios mais rápidos e práticos para se criar Serviços Web em Java, ocultando do programador conceitos relacionados com este tipo de serviços. Porém, estas tecnologias utilizam o padrão de RPC sobre SOAP para criar e utilizar serviços, tornando inviável sua utilização em um protótipo do UDDI.

(40)

Após utilizar o SAAJ para receber a mensagem, esta passa por um objeto, cujo único objetivo é identificar o método e repassar a mensagem para quem realizará seu processamento. Portanto, existe uma camada que possui um objeto para cada método da API. Cada um deles processa a mensagem e envia uma requisição para o próximo módulo, que possui os dados publicados.

O segundo módulo tem a função de implementar a interface que une as duas partes do protótipo e administrar as informações publicadas. A interface define os diversos métodos das APIs, processando a requisição. Este módulo pode ser implementado baseado em qualquer tecnologia de armazenamento. Nesta implementação, foi utilizado o banco de dados nativo XML Xindice (APACHE, 2004). Segue abaixo a figura que descreve o segundo módulo implementado.

Figura 5.2: Estrutura do segundo módulo.

Este módulo possui a implementação da interface, onde cada método utiliza os dados recebidos para formular uma requisição ao banco de dados. Esta requisição não é transmitida diretamente ao banco. Existe um objeto que é responsável pela comunicação com o Xindice, pela criação das Collection responsáveis pelo armazenamento dos dados e pelo papel intermediário que liga a implementação da interface com o banco de dados. Para se comunicar com o

(41)

Xindice, foi utilizada a API XML:DB (XML:DBa, 2004), que padroniza a comunicação com bancos de dados nativos XML da mesma forma que o JDBC para banco de dados relacional. Isto permite interagir da mesma maneira com diferentes fabricantes e produtos. Mas o XML:DB apenas fornece métodos para inserir e retirar documentos em XML, deixando a cargo do produto as tecnologias para realizar pesquisas nestes documentos e atualizá-los. O Xindice particularmente fornece o XPath e o XUpdate para realizar estas funções.

A união dos dois módulos apresentados cria uma estrutura que possibilita a interação com o cliente, o processamento da mensagem e a publicação e busca dos dados, possibilitando que todos os passos do registro UDDI sejam executados.

5.1 SAAJ

O SAAJ (SOAP with Attachments API for Java) (SUN MICROSYSTEMS, 2004) é uma API que padroniza o envio de documentos XML através da especificação SOAP1.1 e SOAP with Attachments. Esta API pode ser usada para criar serviços e clientes, encapsulando todos os conceitos envolvidos no envio de mensagens SOAP como objetos. Por exemplo, um objeto SOAPMessage representa uma mensagem SOAP, fornecendo métodos para retornar o cabeçalho ou corpo da mesma. Após obter o corpo da mensagem representado por um objeto SOAPBody, podem ser acrescentados os dados XML que são desejados para envio. Segue abaixo uma figura que apresenta os objetos que podem ser criados utilizando esta API.

(42)

Figura 5.3: Diagrama de relacionamento do SAAJ.

Existem outros objetos que são utilizados somente na criação de clientes, como é o caso do SOAPConectionFactory e SOAPConection. Estes dois possibilitam utilizar o método call que invoca um Serviços Web através de dois parâmetros que fornecem a localização do serviço e a SOAPMessage que deve ser enviada.

Esta API exige do programador um conhecimento de XML e SOAP para a criação e utilização de Serviços Web, mas apresenta uma estrutura bem organizada e de fácil utilização. Uma descrição mais detalhada com códigos de exemplo pode ser encontrada no “Java Web Service Tutorial” (SUN MICROSYSTEMS, 2004).

(43)

O Xindice é um banco de dados nativo XML criado pela Apache Software Foundation (http://www.apache.org/), atualmente na versão estável 1.0, mas com a versão 1.1 beta três disponível. A versão 1.1 pode ser encontrada em três formatos: código fonte, versão compilada e aplicação web. Desta forma, o Xindice pode ser utilizado como um servidor standalone ou como uma aplicação em um container web. A versão web possui uma instalação simples e é chamada de embedded. É um produto de código aberto que fornece meios para organizar e armazenar dados em XML. Sua utilização é recomendada para armazenar um volume grande de dados, divididos em diversos documentos, pois é advertido que o Xindice pode não funcionar para documentos muito grandes. A comunicação com o Xindice pode ser feita através de três APIs diferentes:

• A primeira é utilizada por programas escritos na linguagem Java e utiliza a API XML:DB. Esta é a forma principal e mais abordada pelos exemplos. Esta API pode ser encontrada em dois tipos: uma que utiliza o Xindice XML-RPC API e outra que utiliza a Core Server API, funcionando somente na mesma máquina virtual;

• A segunda API é o Xindice XML-RPC API que é utilizada por outras linguagens de programação diferentes de Java e utiliza como base a Core Server API;

• A Core Server API é a API mais básica do Xindice, sendo utilizada internamente pelo banco de dados, e acessada somente por programas rodando na mesma máquina virtual.

Este produto ainda encontra-se em desenvolvimento, apresentando diversos bugs e ausência quase que completa de documentação, prejudicando sua utilização. Apesar disto, tem sido muito bem aceito, visto que já existem ferramentas que o utilizam para armazenar seus dados e o número de sites e listas de discussões sobre o assunto.

(44)

O XML:DB (XML:DBa, 2004) é uma especificação que se propõe a padronizar a comunicação com banco de dados nativos XML, possibilitando que aplicações troquem de banco de dados sem ter que reimplementar todos os métodos de acesso. Criada pelo XML:DB Initiative (www.xmldb.org), esta especificação visa difundir este novo tipo de tecnologia facilitando seu uso por programadores. Ela define uma API que faz o mesmo papel do JDBC para banco de dados relacionais. O principal conceito desta API são as Collections que armazenam um conjunto de Resources. Estes Resources são geralmente documentos XML e arquivos binários que são armazenados no banco. As Collections formam uma estrutura hierárquica da mesma forma que uma estrutura de diretórios, mas sua função não é apenas organizacional pois fornecem alguns tipos de serviços. Os itens abaixo apresentam alguns destes serviços:

• XPathQueryService – este é um dos principais serviços, pois permite executar XPath queries, realizando pesquisas nos Resources contidos na Collection;

• XUpdateQueryService – permite executar XUpdate queries, atualizando os Resources;

• CollectionManagementService – permite adicionar e remover Collections do banco de dados.

Além desses existem outros tipos de serviços, sendo que cada implementação pode fornecer seus próprios tipos de serviços. É claro que a utilização de serviços proprietários implica vincular a implementação a um determinado produto ou fabricante.

(45)

O XML é uma linguagem que define meios para armazenar dados mas não define como encontrá-los. Desta maneira, há necessidade de fazer um parse em todo o documento, avaliando elemento por elemento para tentar encontrar a informação desejada. Para facilitar este processo foi criada a XML Path Language (XPath) (CLARK,2004), que possibilita obter os dados desejados de forma eficiente. Ela não é uma linguagem estrutural como o XML, sendo baseada em strings e expressões.

Esta linguagem classifica os elementos em diversos tipos e cria uma estrutura em árvore. Um conceito necessário para compreender o XPath é o context node. Este conceito representa o ponto de partida de uma busca. Por exemplo, se a busca tem como local de procura todo um documento, o context node será o elemento raiz. Mas se o local de procura for somente um elemento e seus descendentes, este elemento será o context node.

Para realizar uma pesquisa em cima de árvore Xpath (árvore formada por esta linguagem, utilizando sua classificação de elementos), o XPath utiliza o conceito de Locations Paths para definir a localização e o tipo de informação que deve ser retornada. Um Location Path é estruturado da seguinte maneira:

axis :: nodeTest [ predicate ]

Um axis indica quais os nodos que devem ser incluídos na busca, relativos ao context node. Alguns exemplos de axis são:

• self – o próprio context node;

• parent – os elementos país do context node; • child – os elementos filhos do context node;

• descendant-or-self - o próprio context node e seus descendentes; • attribute – atributos pertencentes ao context node;

• namespace – namespaces pertencentes ao context node.

Node tests são elementos utilizados para indicar o que será retornado da pesquisa:

(46)

• * - seleciona todos os nodos do mesmo tipo do nodo principal; • node() – seleciona todos os nodos independentes do seu tipo;

• nome do nodo – seleciona todos os nodos que possuem o nome do nodo. Por último, existe o predicate, que é opcional e oferece a semântica condicional. Sua utilização indica que os nodos definidos no node test só serão retornados se cumprirem as condições especificadas no predicate.

A partir destes locations paths, pode-se executar uma query tendo estes como parâmetro, e obtendo como retorno um conjunto de respostas. Segue abaixo alguns locations paths com seus significados:

• /self ::node() – retorna o context node. Este location path é abreviado por um ponto (.) ;

• /parent::node() – retorna o elemento pai do context node. É abreviado por dois pontos (..) ;

• /descendant-or-self::node()/ - retorna o context node e todos o nodos descendentes dele. É abreviado por duas barras (//) ;

• //body – retorna todos os nodos que possuem o nome body;

• /books/book/translation[. = ‘Japanese’]/../title – este

location path realiza uma procura em todos os elementos book, filhos do elemento books e netos do context node, comparando o conteúdo do elemento translation com o string ‘Japanese’. Ao encontrar um elemento que satisfaça a condição, é retornado o elemento title, filho do elemento book;

• /books/book/translation[. = ‘Japanese’]/@edition –

parecido com o anterior, este location path retorna, ao invés do

elemento title, o valor do atributo edition do elemento translation. 5.5 XUpdate

(47)

O XUpdate (XML:DBb,2004) é uma linguagem criada pela XML:DB Initiative que oferece maneiras práticas para atualizarem documentos XML. Ela é inteiramente descrita em linguagem XML bem formada e utiliza a linguagem XPath para selecionar os elementos que serão atualizados. É uma linguagem descritiva que oferece uma sintaxe muito simples. Segue abaixo alguns exemplos representados

pelo conteúdo da query e seu resultado:

Figura 5.4: Inserção de um elemento. Figura 5.5: Atualização de um elemento.

Mais exemplos e explicações sobre o XUpdate podem ser encontrados em : http://www.xmldb.org/xupdate/

http://www.xmldb.org/xupdate/xupdate-wd.html

http://www.xmldatabases.org/projects/XUpdate-UseCases/ 5.6 A Implementação

(48)

Na implementação do protótipo, foi utilizado o IDE Eclipse (ECLIPSE, 2004) e o pacote “Java Web Service Developer Pack” (SUN MICROSYSTEMS, 2004), viabilizando o desenvolvimento e teste do registro. O Eclipse foi responsável pela edição do código, trazendo facilidades de organização e de geração automática. Sua utilização foi fundamental na otimização do desenvolvimento, acelerando o processo e possibilitando a realização de alguns testes. O pacote de desenvolvimento de Serviços Web disponibilizado pela SUN, foi utilizado de muitas maneiras. Diversas bibliotecas de classe contidas no pacote foram utilizadas, entre elas, pacotes do SAAJ e pacotes referentes à manipulação de documentos XML. Outra utilidade do JWSDP foi disponibilizar documentação e exemplos referentes às diversas tecnologias nele contidas. Além disto, este pacote disponibiliza um container Web e um Banco de Dados nativo XML. O container Web fornecido é uma das versões do Tomcat, desenvolvido pela Apache Software Foundation, que possibilita instalações e testes de aplicativos Web. Portanto, os Servlets utilizados na criação dos endpoints do registro UDDI, foram instalados neste container. Servlets são as classes em Java responsáveis por receber e responder requisições de rede, sendo o HTTPServlet o tipo mais comum, pois trabalha com pacotes http. O Banco de Dados nativo XML distribuído juntamente com o JWSDP, é a versão Web do Xindice, fornecendo esta ferramenta que foi utilizada para armazenar os dados do registro.

Com a plataforma de desenvolvimento completa, o passo seguinte foi criar os dois pontos de acesso aos serviços, que representam a API de publicação e de busca. A criação destes foi simplificada utilizando um Java package que contém apenas uma classe, fornecido com os exemplos do SAAJ, no JWSDP. Esta classe é abstrata e estende a interface HTTPServlet. Seu funcionamento é basicamente retirar o conteúdo SOAP contido num pacote http e criar um objeto SOAPMessage que representa o envelope, o cabeçalho e o corpo da mensagem. Após a criação deste objeto, a classe invoca o método abstrato de nome onMessage, que contém como parâmetro o objeto SOAPMessage criado, retornando um objeto de mesmo tipo. Portanto, criar um ponto de acesso consiste em apenas estender esta classe, implementando o método onMessage, processando a mensagem fornecida e devolvendo outra como resposta.

Os pontos de acesso do repositório realizam somente a captura da mensagem e seu encaminhamento para um objeto chamado Dispatcher. Cada API possui um objeto deste tipo e sua função é identificar o método e repassar para o objeto responsável pelo método em questão. Com o intuito de passar para a próxima etapa, somente alguns desses métodos forma implementados. Cada método obtinha as informações da mensagem e fornecia estas como parâmetro do método invocado na interface. Para obter esta interface, foi utilizado um objeto “getter” que lê os arquivos de configuração, identificando a classe do segundo módulo que implementa a interface em questão. É através deste processo que ocorre a ligação entre os dois módulos.

O segundo módulo foi implementado utilizando persistência com Banco de Dados nativo XML, usando o Xindice do JWSDP. Para isto, o objeto que implementa a interface, baseado nos parâmetros fornecidos, realiza consultas Xpath e atualiza documentos com o XUpdate através do objeto XindiceImpl. Este