Um catálogo bibliográfico virtual eo seu acesso através de middleware baseado em web services

UM CATÁLOGO BIBLIOGRÁFICO VIRTUAL E O SEU ACESSO ATRAVÉS DE MIDDLEWARE BASEADO EM WEB SERVICES Helder T. Zagalo, Joaquim A. Martins, Joaquim S. Pinto, Rogerio Nascimento {[email protected]; [email protected]; [email protected]; [email protected]} Universidade de Aveiro Departamento de Electrónica e Telecomunicações Instituto de Engenharia Electrónica e Telemática de Aveiro Campus Universitário de Santiago 3810-193 Aveiro Portugal

Resumo A procura pela unificação das fontes de recursos bibliográficos não é nova, assim como a sua solução. Contudo, os diferentes modos de o conseguir encontram-se distanciados de várias décadas. Inicialmente a resposta a esse anseio foi conseguida através da união dos próprios recursos. Hoje, a resposta aparece através, não dos recursos, mas sim do seu acesso. Descrevese neste artigo, um sistema de pesquisas distribuídas e paralelas em sistemas bibliográficos, perfazendo um catálogo bibliográfico colectivo e virtual. O acesso deste mesmo sistema é caracterizado por uma duplicidade web. O primeiro, através da web tradicional dos browsers a que todos já nos habituámos. O segundo, através de uma web inovadora, os Web Services, que se encontram à espreita para saltar para a ribalta do sucesso e tratar por tu outros sistemas de middleware fortemente ancorados no panorama das plataformas de sistemas distribuídos como o CORBA. Pretende-se com o presente trabalho contribuir para a nova visão do que poderá ser amanhã o mundo dos sistemas bibliográficos ou das bibliotecas, no qual a informação bibliográfica e bibliotecária não é de todos mas é partilhada por todos. Palavras chave: Catálogos Virtuais, Sistemas Bibliográficos, Sistemas Distribuídos, Protocolo Z39.50, Middleware, Web Services, Java, .NET

I.

Introdução

A ubiquidade do acesso aos recursos é hoje uma realidade possível através do uso da Internet. Longe vão os tempos em que seria completamente impensável poder-se consultar, de forma permanente e sempre actualizada, informação comercial e institucional, proceder-se à compra de artigos, em território nacional ou estrangeiro, ou efectuar pagamentos de serviços essenciais (luz, água, electricidade, etc.) e transferências bancárias, tudo isto de forma fácil e segura na comodidade do lar, bastando para tal possuirmos um computador ligado à rede mundial de computadores. Este interesse pela ubiquidade do acesso aos recursos chegou também aos governos, que manifestam actualmente um grande interesse pela concepção e desenvolvimento de sistemas de informação que permitam conciliar as complexidades de uma paisagem informativa, caracterizada por inúmeros e diferentes recursos. Em Portugal, por exemplo, no contexto de um 1

imperativo político na Europa que consiste em fornecer a todos os cidadãos um acesso universal à informação governamental, o governo lançou, entre outros, o projecto “Biblioteca Digital de Registos da Assembleia da República” [1] para dar a saber aos cidadãos aquilo que se passa no Parlamento Português e para criar um instrumento de trabalho para historiadores e investigadores. As bibliotecas actuais não fogem à regra e por isso muitas bibliotecas espalhadas pelo mundo fornecem, já há algum tempo, acesso aos seus catálogos bibliográficos através da Internet, usando a Web ou soluções proprietárias, permitindo fazer consultas e reservar ou fazer pedidos de obras. Em qualquer das formas, são serviços de valor inestimável tanto para estudantes, professores, investigadores, bibliotecários como para a população em geral. Contudo, apesar desta oferta por parte das bibliotecas, a pesquisa bibliográfica continua a ser uma tarefa muitas vezes ingrata. A procura de recursos realmente relevantes, a adaptação a diferentes sistemas de informação, que usam diferentes linguagens de pesquisa, convenções de semântica, protocolos de comunicação e interfaces de utilizador, são algumas das dificuldades com que muitas vezes os utilizadores se deparam para levar a cabo esta tarefa [2]. O presente artigo descreve a concepção e implementação de um catálogo virtual, que pretende dar resposta a algumas das dificuldades enumeradas acima e ser uma ferramenta de elevado valor para a pesquisa bibliográfica em múltiplos sistemas bibliográficos distribuídos. Descreve-se ainda a concepção de um componente de middleware baseado em Web Services que permitirá aceder ao catálogo virtual através de uma interface programável e avaliar e testar a possibilidade de usar protocolos XML, mais simples, para aumentar a interoperabilidade entre os sistemas bibliográficos.

II.

Os Catálogos Colectivos Virtuais

Desde os anos 70 que muitas instituições, com largos repositórios distribuídos de informação bibliográfica, têm tido uma preocupação constante na unificação das suas fontes de recursos, ou seja, criando catálogos colectivos. Inicialmente, os catálogos colectivos, com destaque para o sistema público MELVYL1 (Universidade da Califórnia) e os sistemas comerciais OCLC2, RLG3 e WLN4, foram implementados em sistemas centralizados com uma única base de dados [3]. Nesta forma, o catálogo colectivo é construído procedendo-se previamente à recolha, processamento e armazenamento dos registos oriundos dos catálogos locais. Uma consequência directa desta implementação é a necessidade de actualização periódica (semanalmente, mensalmente, etc.). Mais recentemente, com a implementação do protocolo Z39.50 [4] nos sistemas bibliográficos para permitir o acesso aos mesmos, diversas instituições iniciaram estudos no sentido de poderem vir a substituir os seus catálogos colectivos centralizados por catálogos colectivos “virtuais”. O catálogo “virtual” não é mantido num único local mas criado em tempo real através da pesquisa distribuída e simultânea dos diversos catálogos locais, usando precisamente o protocolo Z39.50. Alguns exemplos de instituições que têm vindo a envidar esforços neste sentido são a Biblioteca Digital da California (CDL) [5] e a Biblioteca Nacional do Canadá [6]. Nesta implementação do catálogo colectivo elimina-se a redundância no armazenamento das referências bibliográficas e a necessidade imperativa das actualizações periódicas. 1

http://www.dbs.cdlib.org http://www.oclc.org/oclc/menu/home1.htm 3 http://www.rlg.org/toc.html 4 http://www.wln.com 2

2

As diversas iniciativas de investigação na área dos catálogos virtuais, como o vCuc – virtual Canadian union catalogue Project [7], o VEL – Virtual Electronic Library Project [8] ou a CDL – California Digital Library initiative [5], identificaram um conjunto de questões relacionadas com a implementação deste tipo de catálogo que levantam vários desafios: • A concorrência das sessões – o protocolo Z39.50, apesar de orientado à sessão e permitir na sua versão de 1995 a pesquisa concorrente, define apenas interacções entre duas máquinas (chamadas “Origem” e “Destino” no standard). O que leva à necessidade de desenvolver aplicações cliente que suportem múltiplas e concorrentes sessões com diversos servidores; • A identificação e remoção de registos duplicados – aquando de uma procura em múltiplos sistemas simultaneamente, o utilizador pode receber muitos registos duplicados. Várias bibliotecas poderão ser detentoras do mesmo título e dessa forma o utilizador recebe vários registos sobre o mesmo item; • Consistência semântica das pesquisas – os servidores e bases de dados destino suportam uma grande variedade de atributos Z39.50 e combinações desses atributos pelos quais é possível proceder à pesquisa. Muitas vezes, os implementadores atribuem semânticas diferentes aos mesmos atributos. Na procura através de múltiplos servidores, a pesquisa tem de estar conforme ao menor denominador comum, para que os resultados recebidos sejam coerentes; • Ligações a outras aplicações – geralmente a pesquisa num catálogo colectivo distribuído é conduzida no contexto de outras operações: a referenciação, a catalogação, a investigação escolar ou o empréstimo inter-biblioteca. Desta forma é necessário que o cliente Z39.50 seja capaz de transferir a informação recolhida de forma eficaz a outras aplicações. Existem actualmente alguns catálogos colectivos virtuais em funcionamento e acessíveis ao público, como por exemplo: a Deutshe Bibliothek [9], o Virtual Karlsruhe Catalogue [10] e o Virtual Canadian Union Catalogue [11]. Contudo, centram a sua funcionalidade apenas ao nível da capacidade de pesquisa distribuída simultânea, desmerecendo os restantes requisitos que devem fazer parte de um verdadeiro catálogo colectivo virtual. No nosso trabalho tentámos abordar todas as questões enumeradas acima, o mais de perto possível, e apontar possíveis soluções para as mesmas.

III. O Catálogo Virtual Baseando-nos nos mais recentes trabalhos no domínio dos catálogos colectivos virtuais, concebemos e desenvolvemos um catálogo colectivo virtual, vencendo o desafio de engenharia colocado pela necessidade de criar e gerir múltiplas sessões Z39.50 em paralelo e apresentando possíveis soluções para as outras questões levantadas acima. É objectivo deste sistema melhorar a qualidade das pesquisas efectuadas nos sistemas distribuídos, indo de encontro à questão da consistência semântica das pesquisas, e a usabilidade da informação recolhida, observando a necessidade de proceder à identificação e remoção de registos duplicados. O nosso sistema segue a ideia original de um catálogo virtual, mas apresenta uma significativa mais valia face aos catálogos virtuais existentes. Os actuais catálogos virtuais, pelo menos aqueles que se encontram acessíveis ao público, apresentam os seus resultados em catálogos separados, um para cada biblioteca pesquisada. Isto força os utilizadores destes sistemas a um trabalho árduo de selecção da informação recolhida. Em oposição, o nosso sistema apresenta os resultados num único catálogo, fazendo com que o utilizador “pense” que está a trabalhar com 3

uma única biblioteca. Todos os registos recebidos no nosso sistema, vindos das suas diversas origens, são primeiro processados e unidos antes de serem apresentados ao utilizador. Em adição, a cada registo é associada informação acerca das suas origens, sendo possível saber quais são as bibliotecas onde se encontra uma determinada obra (livro, periódico, etc.).

A. Arquitectura Na concepção da arquitectura do catálogo virtual foram pesados vários requisitos que considerámos à partida obrigatórios para a realização de um sistema eficiente e flexível. Em primeiro lugar, o sistema terá de conseguir simultaneamente atender múltiplos utilizadores e criar e manter múltiplas sessões com servidores Z39.50. Em segundo lugar, o sistema deve permitir a sua reorganização, caso seja necessária a sua utilização em situações e contextos diferenciados. Desta forma, e tal como é apresentado na figura1, o sistema compõe-se basicamente por dois módulos principais: um servidor web e um módulo de software para pesquisas distribuídas (DSS – Distributed Search System).

Figura 1 – A arquitectura geral do catálogo virtual. O servidor web faz a interface com os utilizadores, através dos seus web browsers. Este módulo é o responsável pela recepção dos pedidos de pesquisa e pela apresentação da informação ao utilizador. A escolha de um servidor web para esta tarefa é óbvia, devido ao actual contexto dos ambientes computacionais, onde o web browser tem vindo a ser adoptado como o denominador comum entre as interfaces de utilizador. Por outro lado, pelo menos de momento, um servidor web é a melhor escolha quando se trata de permitir a utilizadores finais o acesso massivo a sistemas de informação. O módulo DSS é o módulo responsável pela consulta e recolha de informação em servidores Z39.50, assim como do processamento e união dos registos recebidos. A sua arquitectura encontra-se representada na figura 2. A arquitectura do módulo DSS segue uma filosofia orientada ao componente. O que significa que o módulo em si é composto por diversos componentes independentes que podem ser usados individualmente para cumprir tarefas específicas ou podem no seu todo ser reorganizados para em conjunto construírem um módulo com outra missão.

4

Figura 2 – A arquitectura do módulo DSS. Os principais componentes que constituem o módulo DSS, são: • O Cliente Z39.50; • O Normalizador de Registos; • O Processador de Duplicados e de Registos; • O Front-End. i) O Cliente Z39.50 O Cliente Z39.50 é o componente principal deste módulo. É o responsável por fazer as pesquisas nos servidores Z39.50 e receber os registos provindos dos mesmos. Na figura 3 encontra-se representada a arquitectura deste componente, onde se podem ver os vários objectos que o compõem e os fluxos de dados e de sinalização entre os mesmos. Os objectos são: • ZSession – responsável pela implementação do protocolo Z39.50 e por isso da criação e manutenção de uma sessão com um servidor; • ZClient – responsável por toda a gestão do componente como a recepção dos pedidos de pesquisa, o controlo das sessões activas, a sinalização de entidades exteriores e o retorno dos conjuntos de registos; • ZStore – permite a guarda e agrupamento dos registos que chegam de todas as sessões. Por forma a ter-se uma ideia mais clara da relação entre estes objectos e o seu funcionamento vamos seguir a linha de execução de um pedido de pesquisa colocado ao componente. O pedido de pesquisa chega ao componente através do objecto ZClient. Para cada servidor ao qual se pretende fazer a pergunta, o objecto ZClient verifica se existe uma sessão activa, que corresponde à existência de um objecto ZSession em actividade. No caso de existir, o pedido de 5

pesquisa é-lhe imediatamente entregue, caso contrário o objecto ZSession é criado e só depois lhe é entregue o pedido.

Figura 3 – A arquitectura do Cliente Z39.50. Cada objecto ZSession envia então o pedido ao servidor a que se encontra ligado e aguarda pela chegada da sua resposta. A resposta do servidor começa por indicar a quantidade de registos encontrados para a pesquisa em questão e cabe depois ao objecto ZSession pedir a quantidade de registos que pretende. À medida que os registos vão chegando ao objecto ZSession, estes vão sendo enviados para o objecto ZStore que se encarrega de os agrupar com os restantes registos recebidos pelos demais objectos ZSession. Em simultâneo com este processo, o objecto ZClient vai acedendo ao objecto ZStore para verificar se a quantidade de registos recebidos satisfaz o pedido efectuado. Quando tal acontecer, ou quando todos os objectos ZSession sinalizarem que não têm mais registos para o pedido, o objecto ZClient sinaliza a entidade exterior que fez o pedido que a resposta ao mesmo está pronta e por isso pode recolher o conjunto de registos, que foi a resposta dos múltiplos servidores ao seu pedido de pesquisa. Para prevenir eventuais problemas com as ligações aos servidores, como a existência de servidores desligados, por exemplo, o objecto ZClient atribui um tempo máximo (timeout) para a realização da pesquisa. Findo esse tempo, e mesmo que ainda haja objectos ZSession a trabalhar na pesquisa, a pesquisa é dada como concluída. Como ilustrado, este componente executa as suas operações em modo assíncrono. Uma entidade pode pedir ao componente que este execute um pedido de pesquisa, e continuar a efectuar outras tarefas. Assim que a execução da pesquisa está terminada no componente, este sinaliza assincronamente a entidade e esta pode ir “levantar” os registos resultantes. Isto é possível porque todos os objectos dentro do componente Cliente Z39.50 possuem a sua thread de execução independente. Isso possibilita que todos os movimentos dentro do componente sejam efectuados em paralelo. Este componente pode ser usado de forma independente, integrado noutros sistemas, para servir, por exemplo, de motor de busca sobre o protocolo Z39.50. Sistemas de catalogação para bibliotecas ou aplicações proprietárias para citação bibliográfica podem ser o seu meio de

6

integração ii) O Normalizador de Registos As respostas dos servidores Z39.50 às pesquisas efectuadas chegam geralmente num formato próprio ao sistema de onde provêem. Essas respostas chegam na forma de registos, algo parecidos com os registos de uma base de dados, mas com um formato mais complexo e particular aos sistemas bibliográficos. A grande maioria dos catálogos bibliográficos usa o formato standard MARC, que consiste na conjunção do standard ISO 2709 com um conjunto de elementos de metadados, definido nas várias nuances de MARC, como o USMARC agora conhecido como MARC21 [12], o UNIMARC [13], o UKMARC [14], etc. Estas nuances, apesar de usarem o mesmo formato base (o ISO 2709), apresentam-se com conjuntos de elementos de metadados diferentes e até com planos de numeração diferentes das próprias tags. A existência desta diversidade de nuances é fruto da necessidade particular de cada país em descrever a bibliografia nos seus próprios termos. Contudo, quando num mesmo sistema se propõe juntar e tratar registos oriundos de múltiplos locais diferentes e os seus formatos são incompatíveis, isso coloca problemas óbvios na análise, extracção e apresentação da informação transportada nos mesmos. Torna-se portanto necessário proceder-se à normalização e reduzir todos os registos ao mesmo denominador. Contudo, há ainda outras razões para a conversão. Pretende-se ao desenvolver este sistema, que os registos que chegam ao utilizador sejam suficientemente simples para serem usados por pessoas comuns, por um lado, e suficientemente informativos para poderem ser usados por profissionais, por outro. Para isto o formato MARC é demasiado complexo. Por outro lado, os registos têm de poder ser reutilizados do lado do cliente, para passar a outras aplicações ou para, simplesmente, serem guardadas localmente, o que coloca o problema da descodificação e/ou codificação da norma ISO2709 e o problema de copyright com registos comprados a serviços de catalogação. Devido, precisamente, a este problema, há actualmente muitos OPACs – Online Public Access Catalogs que apresentam os resultados de pesquisas noutros formatos que não o MARC. Desta forma, decidiu-se proceder à conversão de todos os registos recebidos para Dublin Core (DC) [15] sobre XML [16]. Esta decisão está conforme à recomendação de um dos mais actuais perfis para sistemas Z39.50, que é o Bath Profile [17]. Este perfil é um ISO IRP – Internationally Recognized Profile e agrupa a experiência de vários outros perfis anteriores como o ATS-1, CENL ou DanZIG. A conversão é baseado num documento de conversão entre o MARC21 e o Dublin Core [18] localizado na LoC – Library of Congress. iii) O Processador de Duplicados e de Registos O componente “Processador de Duplicados e de Registos” tem por missão a identificação e remoção de registos duplicados, salvaguardando numa única cópia do registo todas as proveniências do mesmo, e ainda gerir e guardar os conjuntos de registos recebidos. Registos duplicados são aqueles que, apesar de não serem totalmente iguais, se referem à mesma obra. A experiência acumulada pelos diversos grupos de investigação nesta área, diz-nos que num nível mais simples, a detecção de duplicados pode ser feita recorrendo aos identificadores ISSN ou ISBN [12], mas níveis mais avançados de detecção implicam a execução de algoritmos sofisticados como os que se encontram nos sistemas OCLC e AMICUS [6]. O problema destes últimos é o seu impacto sobre os custos e o tempo de resposta. O nosso componente usa o campo

7

Identifier do registo Dublin Core, para proceder à identificação dos duplicados. Se este campo não se encontrar preenchido no registo, a identificação é tentada através dos restantes campos. iv) O Front-End O componente “Front-End” assume no módulo uma actividade de coordenação sendo ele o responsável pela linha de execução dos pedidos de pesquisa que atravessam todos os outros componentes. A este componente é ainda acometida a responsabilidade de ser a interface do módulo com o exterior, o que faz dele o integrador dos outros componentes e permite apresentar o módulo aos sistemas exteriores também ele como um componente.

B. Desenvolvimento Para o desenvolvimento do módulo DSS foi escolhida a linguagem JAVA [19] como linguagem de programação. As suas capacidades nativas para o desenvolvimento de aplicações concorrentes e de rede assim como a sua portabilidade e possibilidades para o desenvolvimento de componentes foram determinantes para a sua escolha. Todos os componentes do módulo foram desenvolvidos como JavaBeans [20]. A implementação do protocolo Z39.50 foi feita recorrendo a um produto comercial denominado ZedJAVA [21]. Este produto consiste numa biblioteca de classes desenvolvida em Java que implementa as estruturas de dados do protocolo e fornece funcionalidades para codificar e descodificar mensagens conformes ao mesmo. Deste modo, coube a este produto a implementação da parte estática do protocolo. A parte dinâmica é parte do trabalho desenvolvido. Para a manipulação das estruturas XML foi escolhida a Java API for XML Processing version 1.1 (JAXP 1.1) [22] da Sun Microsystems. Esta API suporta as duas interfaces para manipulação do XML: o Document Object Model level 2 (DOM 2) [23] e a Simple API for XML version 2.0 (SAX 2.0) [24]. Para servidor web foi escolhido o IIS – Internet Information Services da Microsoft. Como a plataforma de desenvolvimento é o Microsoft Windows, optámos pela adopção do seu servidor web que é o que oferece melhores garantias de integração com a plataforma. Para além disso, como o módulo de pesquisas foi desenvolvido num ambiente multi-plataforma (Java), acabou por se tornar um teste à capacidade de integração destes dois sistemas. O módulo DSS consiste também ele num componente JavaBean. Através da bridge JavaBean – ActiveX da Sun Microsystems o DSS passou a ser visto como mais um ActiveX pelo servidor web. A partir daí, a sua manipulação é feita usando scripts ASP [25] no servidor.

IV. Middleware de Acesso Baseado em Web Services O protocolo Z39.50 (ANSI/NISO Z39.50-1995 / ISO 23950) é um protocolo do nível de aplicação que define interacções entre duas máquinas: um cliente e um servidor. Este permite a uma aplicação cliente submeter pedidos de pesquisa a um servidor que procura as suas bases de dados, identificando registos de acordo com determinados critérios e devolvendo todos ou alguns dos registos encontrados. Este protocolo possui uma versatilidade que lhe permite mesmo oferecer serviços fora do domínio estrito das aplicações bibliográficas. Contudo, apesar de tudo o que o protocolo Z39.50 tem para oferecer, não é raro ouvir entre as comunidades bibliográficas os seguintes comentários: “É demasiado complexo para implementar ...”, “Não funciona ...”, “Não é necessário agora que temos a web ...”, etc. Estas críticas são em larga medida devidas às diversas implementações do protocolo e não devido 8

ao protocolo em si. De facto, o protocolo Z39.50 é um protocolo complexo, bastante flexível e poderoso, mas devido a isso mesmo há muitas vezes, da parte de quem o implementa, diferentes interpretações das suas funcionalidades. Em alguns casos, os implementadores não implementam o protocolo em toda a sua extensão, limitando-se a implementar um subconjunto das suas funcionalidades, de acordo com os seus principais interesses. Perante tal cenário, é fácil perceber o porquê de tantas críticas ao protocolo. Na realidade, os sistemas que dialogam neste protocolo possuem uma interoperabilidade bastante pobre. Por esta razão apareceram perfis como o Bath Profile, assim como outros que o antecederam, tentando dar novas oportunidades ao protocolo. Conclui-se desta forma que a simplicidade e a interoperabilidade são chaves mestras que conseguem promover um protocolo ao nível de uma grande estrela, como é o exemplo do protocolo HTTP, ou ao nível do anonimato. Baseando-nos nesta assunção e no trabalho desenvolvido no catálogo virtual, pensamos que a chave para a interoperabilidade dos sistemas de informação bibliográfica reside precisamente na adopção de protocolos de acesso e de formatos de registos mais simples. Esta foi a motivação para a concepção e desenvolvimento de um componente de middleware, usando Web Services [26] que permitisse o acesso de modo simplificado ao catálogo virtual por parte de outras aplicações e sistemas.

A. Os Web Services O principal objectivo de qualquer plataforma de middleware é a redução da complexidade na integração de sistemas e por conseguinte criar uma homogeneidade artificial no seio de um conjunto de sistemas heterogéneos. Exemplos de plataformas de middleware são: o CORBA – Common Object Request Broker [27], o J2EE – Java 2 Enterprise Edition [28] ou o COM – Component Object Model da Microsoft [29]. Os Web Services por outro lado foram já classificados de “middleware para o middleware” [30]. Isto porque não só acomodam a diversidade e a heterogeneidade em aplicações, sistemas operativos e plataformas de hardware mas também noutros sistemas de middleware. De facto, é convicção de alguns especialistas neste domínio que os Web Services se apresentam como a grande promessa para a próxima geração de middleware. A plataforma de Web Services usa a ubiquidade da infra-estrutura da Internet para aplicar soluções de middleware com maturidade e provas dadas, com a vantagem de usar protocolos Web já existentes e standards abertos baseados em XML. Isso é visível nas três áreas em que se divide: • Protocolos de Comunicação – dos quais sobressai o protocolo SOAP – Simple Object Access Protocol [31], uma especificação do W3C; • Descrição de Serviços – na qual encontramos outro standard definido pelo W3C, o WSDL – Web Services Description Language [32]; • Descoberta de Serviços – que conta com o protocolo UDDI – Universal Description, Discovery and Integration directory [33]. Desta forma, retendo a imagem dos Web Services como um meio de aproximar diferentes aplicações e sistemas, estamos convictos que a adopção destes por parte da comunidade bibliotecária traria como consequência um aumento significativo da interoperabilidade entre os seus sistemas, permitindo pelo menos melhorar significativamente os serviços já existentes, como o acesso aos registos bibliográficos e a informação relacionada com o estado das obras, ou ainda

9

o serviço de empréstimo inter-biblioteca que é um serviço de extrema importância no contexto actual da partilha de recursos.

B. Arquitectura e Desenvolvimento Qualquer processo de mudança implica sempre uma fase inicial penosa de inércia, seja este numa comunidade ou num âmbito particular, sobretudo quando tem como consequência o corte radical com o que está fortemente estabelecido. No domínio específico das bibliotecas, onde ao longo dos anos se têm feito investimentos avultados, em sistemas de catalogação e de consulta, e se têm instalado múltiplos interesses, a inércia às mudanças é ainda maior. Por esta razão, apresentamos aqui uma solução intermédia que não implica qualquer corte com o que está estabelecido ou qualquer mudança na forma de pensar por parte de quem gere e mantém os sistemas bibliográficos. Consiste numa solução que situando-se de fora das bibliotecas, depende destas para oferecer o seu serviço mas em sentido contrário, as bibliotecas nem sequer necessitam de ter conhecimento da sua existência. Trata-se de um serviço que agregado ao catálogo virtual oferece a possibilidade de consulta de múltiplos sistemas bibliográficos, em simultâneo ou não, através de uma interface programática na forma de um Web Service. Na figura 4 encontra-se apresentada de forma esquemática a arquitectura deste serviço, chamado aqui de Web Service de Acesso Bibliográfico.

Figura 4 – Arquitectura do Web Service de Acesso Bibliográfico. Este serviço aparece nesta arquitectura como um componente incrustado no servidor web. Na realidade o acesso ao serviço é feito via servidor web que ao detectar que se pretende aceder ao serviço específico de consulta bibliográfica via Web Service, agulha o pedido para o componente que o implementa. Por forma a proceder às pesquisas, o componente acede por sua vez ao módulo DSS do catálogo virtual. A ferramenta utilizada para implementação do Web Service foi o Visual Studio .NET, onde o componente foi implementado na forma de um ASP.NET [34] em linguagem C#. O acesso do Web Service ao módulo DSS foi pacífico, uma vez que o DSS se apresenta no sistema como um ActiveX.

10

V.

Conclusões

Iniciámos este artigo a falar das motivações que levaram à construção de um catálogo colectivo virtual, passando em revista alguns conceitos sobre catálogos virtuais e desafios da sua implementação. De seguida, descreveu-se a arquitectura do nosso catálogo virtual e a forma que tomou o seu desenvolvimento. Finalmente, descreveu-se um sistema de acesso a esse catálogo, usando protocolos standard abertos baseados em XML, e as razões por detrás do seu surgimento. Os catálogos virtuais continuam a ser um domínio de investigação com elevado interesse nos meios bibliotecários. Existem ainda muitas questões em aberto, para as quais os investigadores continuam à procura de soluções. Também as pessoas desta área, com menor formação nos domínios das tecnologias da informação, começam a perceber que o potencial à volta do conceito de catálogo colectivo virtual é bastante elevado e que poderá contribuir para uma nova visão daquilo que é considerado tradicionalmente o espaço bibliotecário. O uso de novas plataformas de middleware, como o caso da plataforma Web Services, poderá também ela contribuir para uma maior aproximação dos sistemas computacionais que gerem e mantêm a infra-estrutura bibliotecária. A aproximação destes sistemas terá certamente como consequência a criação de um universo de facilidades bibliotecárias, muito para além daquilo que os utilizadores estão hoje habituados. Tornando-se possível a integração de serviços de consulta, tanto da informação bibliográfica como da informação de empréstimo, numa biblioteca virtual que encapsula e representa múltiplas bibliotecas físicas. Como trabalho futuro, perspectiva-se o estudo e modelação da informação que deverá fluir entre múltiplos sistemas bibliotecários, usando uma plataforma integradora de serviços web, por forma a conseguir-se um cenário globalizante entre estes sistemas, mas garantindo a segurança e a privacidade da informação pertencente a cada um deles.

VI. Referências [1]

[2] [3] [4] [5] [6] [7] [8] [9]

Joaquim Sousa Pinto, Helder Troca Zagalo, Joaquim Arnaldo Martins, Rui José Pereira Costa, "Portuguese Parliamentary Records Digital Library", In Ahmed K. Elmagarmid, Willian J. McIver Jr, "The Ongoing March Toward Digital Government", Computer, Vol. 34, Nº 2, p. 38, IEEE Computer Society, February 2001. Sandra D. Payette, Oya Y. Rieger, “Z39.50: The User’s Perspective”, D-Lib Magazine, Abril de 1997. Andrew Wells, Judith Pearce, Linda Groom, Bronwyn Lee, “Connecting and Sharing: the Emerging Role of Z39.50 in Library Networks”, VALA Conference, Melbourne, 28-30 de Janeiro, 1998. “Information Retrieval (Z39.50): Application Service Definition and Protocol Specification”, Library of Congress – Z39.50 International Standard Maintenance Agency, Julho de 1995. (http://lcweb.loc.gov/z3950/agency) Karen Coyle, “The Virtual Union Catalog: A Comparative Study”, D-Lib Magazine, Março de 2000. Carrol Lunau, Fay Turner, “Issues Related to the Use of Z39.50 to Emulate a Centralized Union Catalog”, National Library of Canada, Abril de 1997. Carrol Lunau, “virtual Canadian union catalogue Pilot Project: Final Report”, National Library of Canada, 24 de Junho de 1998. (http://www.nlc-bnc.ca/resource/vcuc/vcfinrep.pdf) “The Virtual Electronic Library (VEL) Project: Report on Phase I”, Committee on Institutional Cooperation, Junho de 2000. (http://www.cic.uiuc.edu/cli/libraryVELphaseIrpt.htm) Die Deutshe Bibliothek (http://z3950gw.dbf.ddb.de)

11

[10] KVK - Karlsruhe Virtual Catalogue (http://www.ubka.uni-karlsruhe.de/hylib/en/kvk.html) [11] The Virtual Canadian Union Catalogue (http://www.nlc-bnc.ca/vcuc-cccv/indexe.htm) [12] “Marc 21 Concise Format for Bibliographic Data”, Library of Congress – Network Development and MARC Standards Office, 1999. (http://lcweb.loc.gov/marc) [13] “Unimarc Manual: Bibliographic Format 1994”, IFLA, 1999. (http://www.ifla.org/VI/3/p1996-1/sec-uni.htm) [14] “UKMARC Manual”, 4th Edition, The British Library National Bibliographic Service, 1996. (http://www.bl.uk/services/bsds/nbs/publications/ukmarc.html) [15] “Dublin Core Metadata Element Set Version 1.1”, Dublin Core Metadata Initiative, 1999. (http://purl.org/DC/documents/rec-dces-19990702.htm) [16] “Extensible Markup Language (XML) 1.0”, W3C, February 1998. (http://www.w3.org/TR/REC-xml) [17] The Bath Group, “The Bath Profile: An International Z39.50 Specification for Library Applications and Resource Discovery”, Release 1.1, The Bath Profile Editorial Team, Junho de 2000. [18] “MARC to Dublin Core Crosswalk”, Library of Congress – Network Development and MARC Standards Office, Fevereiro de 2001. [19] James Gosling, Bill Joy, Guy Steele, Gilad Bracha, “The Java Language Specification”, 2nd Edition, Sun Microsystems, 2000. (http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html) [20] “JavaBeans API Specification”, Sun Microsystems, 1997. (http://java.sun.com/products/javabeans/docs/) [21] “ZedJava – Java Software for Access to Z39.50 Information Services”, Crossnet Systems Limited, UK. (http://www.crxnet.com/zjava.html) [22] “Java API for XML Processing version 1.1 (JAXP 1.1)”, Sun Microsystems, February 2001. (http://java.sun.com/xml/jaxp-1_1-spec.pdf) [23] “Document Object Model (DOM) Level 2 Core Specification – Version 1.0”, The World Wide Web Consortium (W3C), November 2000. (http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/) [24] “Simple API for XML (SAX) version 2.0”, Megginson Technologies, May 2000. (http://www.megginson.com/SAX/index.html) [25] Jim Buyens, "Web Database Development Step by Step", Microsoft Press, 2000. [26] Scott Short, "Building XML Web Services for the Microsoft® .NET Platform", Microsoft Press, 2002. [27] Robert Orfali, “, Dan Harkey, Jeri Edwards, “The Essential Distributed Objects Survival Guide”, John Wiley & Sons, 1996. [28] “J2EE™ - Java™ 2 Platform, Enterprise Edition”, Sun Microsystems, 2001. [29] Dale Rogerson, "Inside COM", Microsoft Press, 1996. [30] Steve Vinoski, "Where is Middleware?", Internet Computing, IEEE Computer Society, Vol. 6, Nº 2, pp. 83-85, March/April 2002. [31] "SOAP Version 1.2 - W3C Working Draft", W3C, Dec. 2001. (http://www.w3.org/TR/soap12-part0/) [32] "Web Services Description Language (WSDL) 1.1", W3C, March 2001. (http://www.w3.org/TR/wsdl.html) [33] "UDDI Version 2.0 Data Structure Reference", UDDI.ORG, June 2001. (http://www.uddi.org) [34] Stephen Walther, "ASP.NET Unleashed", SAMS Publishing, 2001.

12